How Do I Review Search Results After a Site Redesign?

What is this review for?

This guide is for owners receiving a launch report or investigating a change after launch. It completes the website redesign review by defining what a useful result record should explain.

Evidence: c-inspectc-move

What does the report actually demonstrate?

Evidence: c-inspectc-move

Our recommendation is to use these narrower descriptions in a launch report. They make progress visible without exaggerating what has been proved. A missing observation is a question to resolve, not a reason to replace it with confidence.

Evidence: c-inspectc-move

Why distinguish a live test from indexed evidence?

Google's URL Inspection documentation distinguishes information about its indexed version from a live test of potential indexability. Google URL Inspection documentation.

Ask the report author to label the observation and its date. An indexed record may describe an earlier version; a live test answers a different question about the current URL. You need that distinction before comparing either record with the launch change.

The existence of a tool result does not settle the business outcome. Ask whether the page shown in the evidence is the page the customer is supposed to use.

Evidence: c-inspectc-move

What makes before-and-after evidence useful?

Our recommendation is to preserve the comparison conditions. Record the pages, date range, channel and metric being compared. Explain changes in service availability, campaigns or measurement that might complicate the interpretation.

If the report changes its query set, date range or definition of an inquiry between updates, ask for that change to be explained before comparing totals. This is a recommendation for interpretable reporting, not a platform-prescribed measurement formula.

For manually observed AI answers, preserve the exact question, platform, time and relevant context alongside the response. State the limits of the observation. A single response can be worth investigating without representing all users or all future responses.

A hypothetical owner might see fewer inquiries after a redesign while the booking form also changed. Another owner might see a different AI answer without a change in inquiries. These situations call for different investigations. Neither should be reduced to “AI visibility went down” without the supporting evidence.

Evidence: c-inspectc-move

What deserves immediate attention?

Our recommendation is to separate a confirmed customer-facing problem from an unexplained trend. A broken contact path, incorrect service statement or missing important answer gives the team a specific issue to investigate and correct. A trend needs a careful explanation of scope and comparison.

Google advises that ranking fluctuations can occur while a site move is processed and does not prescribe a fixed crawl frequency. That is context for interpreting a move, not a reason to dismiss a confirmed defect. Google site-move guidance.

Use the URL review if customers land on the wrong destination. Use the access review if public pages may retain restrictions. Use the schema review if page descriptions disagree with accepted facts.

Evidence: c-inspectc-move

What should the next update contain?

Ask for a finding, the evidence supporting it, its scope and the next decision. If the cause is uncertain, the report should say what would help distinguish the plausible explanations.

Our recommendation is to keep corrections and outcome claims separate. “The incorrect contact destination was corrected and checked” is useful. “The redesign recovered our AI leads” needs a different record. Do not let an improvement in one observation stand in for every result the project hoped to achieve.

A useful follow-up can be small: identify the affected page, state the observed problem, record what was corrected and say which outcome remains unmeasured. That gives the next reviewer a clear starting point without turning a technical correction into a revenue claim.

Evidence: c-inspectc-move

How would you read a mixed launch report?

Consider a hypothetical report that says the new service page loads, a search tool has an older record, an AI answer mentions a competitor and inquiries feel quieter. Those statements may all deserve attention, but they do not form a single explanation. Our recommendation is to separate them into observations before asking whether the redesign caused a change. This scenario demonstrates a review method; it contains no measured client result.

Begin with the delivered page. Identify its address, observation time and the customer task checked. If the report says the page is working, ask whether that includes the service answer and the contact journey or only that something loaded. A page can be available while the wrong inquiry destination remains in place. Record the actual observation instead of allowing “live” to stand in for every acceptance condition.

Next, identify the search record. For Google URL Inspection, distinguish the indexed-version information from a live test as Google's documentation requires. If the record describes an earlier page, the reviewer should say so. The owner should not compare that older evidence with today's design screenshot as if they were observations of the same version. Ask what new observation would help resolve the specific indexing question.

Then examine the captured AI answer. Keep the question, response, platform and time together. Note whether the observation has a comparison captured under equivalent conditions or whether it stands alone. A competitor's appearance can prompt a useful investigation, but it does not by itself demonstrate that the redesign removed your business from a stable set of results. Keep the reported fact narrower than the suspected explanation.

Finally, review the inquiry statement. Ask what the business recorded and how it defines an inquiry. A staff impression can be a reason to investigate, but it is not interchangeable with a consistent record. The report should state what is known about the customer's discovery path and what is not. The meeting can then assign separate next actions for a broken journey, an indexing question, an AI observation and an inquiry trend.

Evidence: c-inspectc-move

What makes a comparison fair enough to interpret?

Our recommendation is to write down the comparison before interpreting it. Name the page group, observation period, channel and definition of the measure. If the redesign moved pages or changed how inquiries are recorded, explain how those changes affect the comparison. Do not silently compare a former service page with a broader new page while describing the result as the performance of an unchanged page.

For example, a report might compare all inquiries before launch with only completed booking requests afterward. That change in definition deserves explanation before the owner concludes that interest declined. The appropriate response is to clarify the records and decide which comparison is meaningful. This example is about measurement consistency, not an assertion that any specific analytics system behaves this way.

Check changes outside the website as well. A business might change service availability, pause a campaign or alter the way staff log customer calls. These possibilities should be investigated only where they are relevant; they are not reasons to dismiss every website concern. Ask which changes are actually documented and how they affect interpretation. Keep confirmed context separate from speculative explanations.

A useful report can show an imperfect comparison if its limits are clear. It might say that the page set changed or that a measurement definition was introduced after launch. That makes the evidence usable for a narrower question. It does not justify presenting a precise redesign effect when the supporting comparison cannot isolate one.

Evidence: c-inspectc-move

How do you distinguish a confirmed defect from an uncertain trend?

A confirmed defect has a specific expected behavior and an observed mismatch. Suppose the contact button on the public service page sends visitors to an unrelated destination. The business can identify the intended destination, the reviewer can record the observed one, and the technical owner can investigate the difference. That is a concrete correction task even if there is no complete report about inquiries.

An uncertain trend has a pattern that needs explanation. A change in recorded inquiries or a different observed AI answer may be meaningful, but the report still needs scope, context and comparison conditions. Assigning a cause because the change occurred after launch skips that work. Our recommendation is to list plausible explanations and identify the next observation that would help distinguish them.

Do not make the uncertain trend a reason to postpone the confirmed defect. Give the responsible team the exact page, intended action and observed failure. Once corrected, repeat the relevant customer journey and keep the result. Describe what was repaired without extending the conclusion to unmeasured outcomes. A fixed button can be reported as a fixed button without becoming a claim that leads recovered.

Likewise, do not assume that fixing the defect explains the entire trend. If inquiry records remain concerning, continue that investigation using the appropriate comparison. The owner should receive a correction record and a separate explanation of the unresolved business question. Those can move forward together without one pretending to settle the other.

Evidence: c-inspectc-move

What if nobody preserved a before-launch baseline?

Say that clearly at the start of the report. Our recommendation is to establish the current state and identify any reliable earlier records that are actually available. Do not manufacture a baseline from memory or present an old screenshot as a complete performance record. A screenshot may show prior wording or layout while leaving traffic, indexing and customer behavior unknown.

Useful current-state work still exists. Review important public destinations, confirm the accepted service answers and check the contact journey. Record current observations with their dates and conditions so later reports have a clear reference. This work can uncover specific issues even when it cannot establish what changed across the entire launch.

If older evidence is recovered, label its scope carefully. An earlier indexed record, a prior page export and a saved AI answer are different forms of evidence. Explain what each one captures and whether it is comparable to the new observation. Do not combine them into a broad success or failure score merely because they all predate the redesign.

The honest conclusion may be that the site now has a documented review baseline, while the size or cause of any earlier visibility change remains unknown. That is a useful outcome for managing the next decision. It is not proof of improvement, and it should not be turned into an unsupported percentage in a client update or marketing claim.

Evidence: c-inspectc-move

How should an owner assign the next investigation?

Frame the task around a question that someone can answer. “Find out why AI does not like the redesign” is too broad. “Confirm whether this public service page still carries the intended indexing instruction” identifies a specific page and technical question. “Confirm whether the new page still describes leasing-only support” identifies a business-content question. Different questions may belong to different people.

For each task, record the observation that triggered it, the expected output and the responsible owner. Ask the reviewer to state what evidence would close the question and what would leave it open. That prevents a tool run or a screenshot from being treated as completion when it does not address the original concern.

Use the cluster's other guides to keep the work focused. The URL guide handles destinations; the access guide handles intended public visibility; the content guide handles retained answers; the schema guide handles agreement between facts and structured descriptions. The report should connect their findings without forcing them into a single visibility score.

Evidence: c-inspectc-move

What would an honest follow-up sound like?

A useful follow-up separates completed corrections from open observations. It might explain that an incorrect destination was found, the intended route was confirmed and the repaired journey was checked. It would then state that indexing or inquiry changes have not yet been established by the available evidence. This is suggested reporting language, not a claim that those actions occurred on a particular website.

Include the exact page and the date of the observation, with a link to the underlying record where appropriate. Explain whether the check covered a specific journey or a broader inventory. If a new issue appears, record it separately rather than quietly changing the meaning of the original finding. The owner should be able to follow how the conclusion developed.

End with the next decision. That may be acceptance of a corrected route, confirmation of a business fact or a request for a comparable observation. A report that makes that decision clear is more useful than a confident summary that collapses delivery, indexing, citations and inquiries into one unsupported result.

Evidence: c-inspectc-move