Field guide · problem diagnosis
Traffic changed after the migration. What failed?
Search traffic can fluctuate after a major move, but uncertainty is not a reason to leave technical problems untouched. Rather than reporting that rankings have dropped, test whether important old landing pages still reach their intended counterparts and whether search engines are allowed to discover those pages.
Who this is for: Help an owner of a newly migrated site distinguish expected search fluctuation from an actual technical regression requiring an owner response.
Editorial preview — facts, worked examples and publication approval are still being checked.
The practical problem
An evidence-first triage ladder separates observed crawl and routing failures from expected short-term reprocessing. It demands the exact affected URLs, response headers, canonical targets and release owners before proposing a remedy.
What you will be able to check
- Select five high-value legacy URLs and confirm their redirect destinations against the signed-off map.
- Inspect final HTML, robots rules, canonical targets and sitemap inclusion on each destination.
- Compare source and destination Search Console URL states and rank technical defects ahead of generic traffic explanations.
Reproducible scenario
Worked example: Traffic changed after the migration. What failed?
A hypothetical services website has just moved to a new domain. The marketing dashboard shows fewer search visits during the first week, while the technical team notices that some old article paths redirect correctly and others end on an unpublished destination. It would be premature to call all change an algorithmic penalty or all fluctuation normal. The triage starts from specific URL classes and the approved migration map.
Starting assumptions
- The source-to-destination mapping sheet and a prelaunch sample of important old URLs are available.
- The team can access real old-host redirects, destination HTTP responses and current Search Console data after the authorised cutover.
Decisions and checks
Partition the observed change by original URL class and landing-page value
Compare important old services, categories and articles with their destination counterparts, not just domain-wide traffic totals. A lost service page may deserve urgent technical action even when aggregate traffic movement is modest.
What to verify: A prioritized URL-level sample identifies which sources now redirect, error or reach an unexpected destination.
Test routing and indexability before explaining rankings
Request source URLs and follow the HTTP chain, then inspect destination canonical, robots rules, content and links. A migrated page that still has staging noindex requires a technical fix; a correct URL experiencing temporary volatility is a different diagnosis.
What to verify: The issue log separates observed redirect/canonical errors from unproven assumptions about crawling or ranking.
Escalate confirmed defects while monitoring the broader transition
Assign exact defective paths to release owners, fix the narrow rule and repeat the same test. Track later Search Console observations separately; a corrected redirect can be verified now, while search recovery timing cannot be guaranteed.
What to verify: A dated before-and-after technical receipt explains what was fixed and what remains to be measured.
Expected output: The triage should produce an actionable fault list with owners and verified corrections rather than a vague traffic-loss explanation. It distinguishes the immediate technical state of migrated pages from slower search-engine processing and preserves evidence for future recovery decisions.
The post migration indexability triage scenario is fictional technical training material, not a completed customer audit.
Start with URLs, not a dashboard percentage
A 20% traffic decline is a symptom, not a cause. Look for whether the loss is concentrated in a particular old directory, page type, language or device. Compare a representative sample of actual legacy landing pages and their new destinations before editing templates.
Google explains that site moves can involve temporary ranking fluctuations while both old and new URLs are revisited. That general behaviour does not excuse missing redirects, incorrect canonical tags or development-stage blocks in the deployed site.
Reference: official · 2026-11-07
Test the simplest technical failures first
Request the old URL and record its response code, Location header, final path and whether the destination serves useful content. Confirm robots.txt and page-level noindex are consistent with the intended public launch. Check internal navigation and the XML sitemap for the new canonical URL.
Avoid changing multiple migration variables at once merely to make a report look better. A failure in the redirect map needs a different owner and fix from a failed template canonical or a missing regional alternate link.
Reference: official · 2026-11-07
Make recovery measurable
Give each affected URL class an owner, expected behaviour, fix reference and retest date. If a defect is found, use an identical before-and-after sample to show whether the technical problem was removed.
Continue monitoring the transition through Search Console, but report facts separately from projections. A technically corrected redirect can be confirmed immediately; the timing and extent of any search-performance recovery cannot be promised.
Reference: official · 2026-11-07
Decision aid
Decision table: Post-migration indexing problems: what to check
| Issue to assess | Recommended owner decision | Verification evidence |
|---|---|---|
| Important old page redirects to a blocked destination | Treat the destination's robots/indexability error as an immediate release defect. | Save final HTTP and rendered meta robots output. |
| Old page leads to a new category with unrelated content | Review mapping relevance and replace the destination rather than accepting a 301 alone. | Compare original user job and final page content. |
| Old and new URLs work but search clicks fluctuate | Monitor verified GSC trends without diagnosing a technical failure from one chart. | Inspect URL sample, coverage and temporal context. |
What a passing test looks like
These checks describe the evidence that should exist after a real implementation. They are not reports of tests already completed on a customer website.
Partition the observed change by original URL class and landing-page value
Expected result: A prioritized URL-level sample identifies which sources now redirect, error or reach an unexpected destination.
Keep as evidence: Record a dated URL-level HTTP and rendered HTML sample with reviewer signoff for partition the observed change by original url class and landing-page value.
Test routing and indexability before explaining rankings
Expected result: The issue log separates observed redirect/canonical errors from unproven assumptions about crawling or ranking.
Keep as evidence: Record a dated URL-level HTTP and rendered HTML sample with reviewer signoff for test routing and indexability before explaining rankings.
Escalate confirmed defects while monitoring the broader transition
Expected result: A dated before-and-after technical receipt explains what was fixed and what remains to be measured.
Keep as evidence: Record a dated URL-level HTTP and rendered HTML sample with reviewer signoff for escalate confirmed defects while monitoring the broader transition.
Scope and limitations
This scenario contains no real migration performance data. Search Console reporting and site move timing are variable; no first-week click trend is proof of a specific cause. Only actual URL responses and source-to-target content comparisons can identify the technical defects described here.
Sources and verification
These references explain documented technical behaviour. The worked decisions are illustrative until checked on your own installation.
- official reference — Google's site-move guide describes expected fluctuations, noindex and robots pitfalls, incorrect redirects and post-move monitoring. Recorded: 2026-11-07