A shiny homepage proves almost nothing after a website relaunch.
The first post-migration audit should establish four things in order: the production site can be reached, important pages can be crawled and indexed, old URLs lead to relevant new destinations, and the journeys producing enquiries or revenue still work and can be measured.
The four routes, in order
- The production site can be reached
Freeze the launch state first, then confirm the live site responds as released.
- Important pages can be crawled and indexed
Check the rendered production output for escaped staging controls: noindex, wrong-host canonicals, blocked resources.
- Old URLs lead to relevant new destinations
Test every important old-to-new pair as a route, hop by hop, to a page that keeps the original job.
- Enquiry and revenue journeys work and can be measured
Complete the real form, call, booking or purchase, then test measurement separately.
TL;DR
- Freeze the launch state before helpful people erase the evidence; do not reconstruct a baseline from post-launch data.
- Sample by blast radius: twenty important URL pairs with recorded outcomes beat twenty thousand rows with no repair order.
- A customer action and its analytics event are separate tests. Do not infer lost demand from missing events.
- The relaunch is a strong suspect for any decline. It is not a confession.
That order matters. A traffic graph cannot reveal that a staging noindex reached production. A rank tracker cannot tell you that an old service page now redirects to the homepage. A successful homepage load cannot prove that every product, location or article template works. An analytics event cannot prove that a form reached sales.
A relaunch is an incident until its critical routes are proven. The first audit is a controlled attempt to distinguish a site that is changing from a site that is failing.
Freeze the launch before helpful people erase the evidence
Capture what went live before developers begin making sensible, urgent and poorly documented repairs. Otherwise the next deployment destroys the evidence and the team ends up debating memory. Record:
Save a crawl of the production site as launched. Preserve response headers and rendered output for a small critical sample. If no pre-launch crawl or performance export exists, state that plainly. Do not reconstruct a “before” state from post-launch data and call it a baseline.
Google says significant site changes can produce temporary ranking fluctuations while its systems recrawl and reindex moved URLs. Its guidance indicates that most pages on a small or medium site may take a few weeks to move, with larger sites taking longer (Google site-move guidance). That is permission to expect movement. It is not permission to ignore a broken implementation.
Choose the routes capable of changing the business
The first sample should be commercially biased, not statistically decorative. Include the homepage; pages closest to enquiries or revenue; strongest historic organic landing pages; one URL from every important template; important paid-campaign destinations; a small set of old URLs carrying links, demand or customer bookmarks; and one checkout, booking, form or phone route for each meaningful conversion type.
The sample does not replace the full audit. It finds failures with the largest blast radius before somebody spends the morning polishing metadata. I would rather inspect twenty important URL pairs with recorded outcomes than scan twenty thousand URLs with no repair order. Coverage comes next. Incident triage looks first for the fault that changes everything below it.
For ecommerce, one broken product or checkout template can matter more than thousands of valid editorial pages. For a service company, a functioning homepage cannot compensate for a form that silently drops the enquiry. Growth strategy should determine sampling priority.
Test old and new URLs as a pair
Every important old URL needs an intended destination, and every destination needs to preserve the useful job of the original page. For each sampled pair, record:
| Field | Evidence required |
|---|---|
| Old URL | Exact address from the approved inventory |
| Initial response | Status and response headers |
| Redirect route | Every hop in order |
| Final URL | Destination and final status |
| Intent match | Whether the destination completes the old page’s useful job |
| Content state | Whether expected content appears in rendered production output |
| Internal route | Whether menus and page links point directly to the final URL |
| Owner | Person responsible for repair and retest |
An old product page sent to a useful parent category may be defensible after the product disappears. A retired service URL sent to an unrelated homepage is not preservation. It is a missing-page problem wearing a 301.
Google advises against redirecting many old URLs to one irrelevant destination because this can confuse users and may be treated as a soft 404. Its migration guidance recommends testing redirects and retaining permanent redirects for at least a year; customer bookmarks and external links may justify keeping them longer (Google site-move guidance). Google also notes that long redirect chains make crawling less efficient (Google crawl-error guidance).
If an important old URL loops, remains live accidentally, chains through several addresses, reaches an irrelevant page or ends in an error, repair the route before diagnosing rank loss.
Check whether staging escaped into production
The next route is crawler eligibility: can important pages be discovered, fetched, rendered and understood under the signals the production site emits? Inspect the rendered page and HTTP response. Check:
A sitemap is a submitted list, not proof of indexability.
Google’s migration guidance tells site owners to remove temporary noindex controls and update canonical annotations to new URLs when redirects become active. Google also says it may skip rendering and JavaScript execution after encountering noindex, which makes JavaScript removal of an original noindex unreliable (Google JavaScript SEO guidance).
Use Search Console URL Inspection on representative critical pages and run a live test after repair. Keep the claim ceiling: the test checks the present URL against several eligibility conditions; it does not guarantee indexing or ranking (Google URL Inspection guidance).
A template-wide noindex, wrong-host canonical or blocked essential resource is a repair-now incident. One intentionally excluded filter URL is not. The desired state is not 100% index coverage. Google’s Page indexing documentation notes that canonical important pages are the useful target while duplicates and deliberate exclusions may correctly remain unindexed (Google Page indexing guidance).
Prove the customer journey independently of analytics
A website can be accessible to search systems and commercially broken. It can also work for customers while analytics claims nothing happened. Run the priority journeys on the production website from relevant devices and browsers:
- submit the real enquiry form through an approved test identity;
- tap and call the published number where a safe test route exists;
- complete booking steps;
- complete or appropriately sandbox a test purchase;
- inspect confirmation screens and messages;
- verify email, CRM, booking or payment receipt;
- confirm the handoff reaches the responsible team.
Then test measurement separately. Google Analytics DebugView displays events and user properties as Analytics collects them, making it useful for troubleshooting tags. Google notes that privacy controls or consent settings may prevent events appearing there (Google Analytics DebugView).
A missing event is a measurement finding until the customer action is tested too. Do not report a conversion collapse because the tag stopped firing. Do not declare success because the event fired while the form failed to reach sales. This is where website design, conversion rate optimisation and performance marketing meet. The page, interface, handoff and observation are separate parts of one route. Every part needs its own test.
Keep paid traffic out of a broken destination
Organic search may take time to reveal a migration failure. Google Ads and social media can send traffic into it immediately. Check every important campaign destination against the new canonical and redirect map. Confirm tracking parameters survive the route, landing content matches the advert, consent behaviour remains expected and conversion actions complete.
If a high-intent journey is broken, pause or redirect the affected campaign deliberately rather than paying to accelerate evidence collection through customer disappointment. The trade-off is lost short-term traffic. I accept it when the destination cannot fulfil the promise.
Do not pause the entire acquisition system because one low-priority article is imperfect. Use the critical-route classification. The response should match the blast radius. This is a useful release principle beyond SEO: marketing distribution should not outrun production verification.
Just relaunched and not sure which routes actually survived? We run the four-route audit on production, by blast radius, and hand back an incident ledger rather than a colour-coded crawl.
Read Search Console through migration groups
Once access, indexing controls, redirects and commercial journeys pass, interpret search behaviour. Group pages according to the change: old versus new host where relevant; changed versus unchanged URLs; commercial versus editorial templates; product, category, service and location groups; sections launched at different times; and redirected, consolidated and retained URLs.
Search Console’s Performance report can compare periods and segment information by page, query, device, country and search appearance. Google recommends weekly or monthly aggregation for clearer long-term comparisons where daily patterns might obscure the signal (Google Search Console comparison guidance). Look for relationships: are old-URL impressions falling while mapped new URLs begin appearing? Did one changed template decline while unchanged sections remained stable? Did impressions hold while clicks changed? Did relevant demand move across the market or only for this property? Are canonical, exclusion or error patterns concentrated in the affected group?
Search Console generally assigns Performance data to the canonical URL, which means a canonical change can move the reporting bucket as well as the search result (Google Search Console dimensions). Do not call a URL-level disappearance a loss until canonical and redirect evidence agree.
Let the finding choose the response
The audit should produce an owner, evidence and action state, not a wall of warnings.
| Finding | Immediate response | Claim to avoid |
|---|---|---|
| Critical templates error, carry unintended noindex or canonicalise elsewhere | Repair immediately; consider rollback when failure is release-wide and rollback is safer | Do not wait for rankings to confirm visible technical failure |
| Valuable old URLs loop, chain, remain live unexpectedly or reach irrelevant destinations | Correct the mapping and retest the full route | Do not call a redirect successful because the first response is 301 |
| Customer action works but analytics or call/form events fail | Repair measurement and mark the affected reporting window | Do not infer lost demand from missing events |
| Routes and controls pass while visibility moves gradually | Monitor mapped page groups against available baselines | Do not rewrite content radically to calm an expected fluctuation |
| Unchanged pages and market demand also decline | Open a separate traffic-drop investigation | Do not force every decline into the migration explanation |
| Paid traffic reaches a broken critical route | Pause or reroute the affected distribution until the journey passes | Do not preserve spend merely to avoid disturbing the report |
Google’s traffic-drop guidance distinguishes technical issues, algorithmic changes, security or spam problems, seasonality and changing interests. It recommends examining the shape and dimensions of the decline before settling on a cause (Google traffic-drop guidance). The relaunch is a strong suspect. It is not a confession.
Use a migration incident ledger
For every material issue, record the incident identifier and affected URL group; first observation and source evidence; the customer, crawler, measurement or revenue route affected; severity and rollback threshold; accountable owner; intended repair; release identifier and time; retest steps and result; the reporting window contaminated by the issue; and the next review point.
Keep screenshots and exports where interfaces or live states may change. Never overwrite the captured failure with its repaired state. The ledger prevents several common mistakes: multiple people repair the same symptom, a later deployment reintroduces the fault, the team forgets which data window is unreliable, and recovery is credited to whichever content edit happened last.
It also improves AI readiness in a practical sense. An AI-assisted engineering or marketing workflow can only reason reliably from clean incident records, explicit route states and bounded claims. Feeding it an undated crawl export and a frightened traffic graph automates confusion.
Refuse the first plausible story
Post-launch pressure rewards fast explanations. Traffic fell because of the migration. Enquiries fell because rankings moved. Rankings moved because redirects changed. The sequence sounds reasonable and may be wrong at every join. Use an evidence ladder:
- Observed: the exact URL, action, status, event or report changed.
- Classified: the failure belongs to access, routing, indexability, customer action, measurement or search performance.
- Scoped: the affected template, section, device, market or reporting window is identified.
- Hypothesised: a cause is proposed with competing explanations retained.
- Tested: a controlled repair or comparison changes the relevant observation.
- Resolved: the critical route passes and the incident remains stable through the agreed review point.
Do not jump from observation to cause because launch day supplies an emotionally satisfying suspect.
My stop rule: no speculative content rewrite while a critical technical or commercial route remains unverified. Changing headings during an unresolved canonical incident adds another moving variable and destroys interpretability.
The relaunch is complete when the routes survive
The first post-migration audit does not need to explain every ranking movement. It must establish that the production site can carry customers, crawlers and measurement through the paths the business depends on.
Freeze the launch state. Test the critical URL pairs. Inspect indexing controls in rendered production output. Complete the customer journey. Verify the measurement independently. Segment search evidence according to what changed. Record every incident and retest.
There is a reasonable boundary: temporary search fluctuation can continue after every controllable route passes. That is when monitoring becomes more useful than frantic repair. Patience is warranted only after implementation has earned it.
A homepage can look perfect while the business underneath it is disappearing one broken route at a time. Prove the routes. Then celebrate the relaunch.
Good to know
FAQs
Four routes, in order: the production site can be reached; important pages can be crawled and indexed under the signals production emits; old URLs reach relevant new destinations; and the enquiry or revenue journeys work and can be measured. Rankings come after all four.
Google says significant site changes can cause temporary fluctuations while it recrawls and reindexes moved URLs, with most pages on a small or medium site taking a few weeks and larger sites longer. That is a reason to expect movement, not a reason to ignore a broken route.
Usually not. Google advises against sending many old URLs to one irrelevant destination because it confuses users and may be treated as a soft 404. Each important old URL needs a destination that continues the original page’s useful job.
Not until the customer action and the measurement have been tested separately. A missing analytics event is a measurement finding until the real form, call or purchase has been completed on production. Test the journey, then test the tag.
Next step
Relaunched and still holding your breath?
We freeze the launch state, test the four routes on production and hand back an incident ledger with owners, retests and the data windows you cannot trust.