Field guide · technical workflow
Your redirect map is only useful when every important route has a test
The migration launch meeting usually centres on the new website. The risk often sits with the old one: the product pages, articles and category paths that already attract demand. An explicit URL map turns those hidden dependencies into engineering decisions that can be checked before and after a move.
Who this is for: Help a head of digital distinguish a genuinely testable migration redirect plan from a spreadsheet of unverified destination guesses.
Editorial preview — facts, worked examples and publication approval are still being checked.
The practical problem
A source-to-destination acceptance register shows the original URL, intended successor, decision reason, required redirect, expected canonical and check status. It comes with example rows clearly labelled as illustrative, so a team can replace them with its own crawler and Search Console exports.
What you will be able to check
- Merge current crawl, XML sitemap, analytics landing pages and Search Console URL evidence into a deduplicated source inventory.
- Assign one approved successor or explicit removal decision to each priority URL, including important media assets.
- Run HTTP redirect, canonical, indexability, internal-link and sitemap tests in a staging environment.
- Record cutover owner, baseline evidence, post-launch check date and failure/rollback response.
Reproducible scenario
A migration where the missing pages were never in the new navigation
Suppose an illustrative specialist retailer is moving from a legacy CMS to a newly designed website. The new navigation highlights six core services, but Search Console exports show older service-detail pages, an industry guide and a downloadable technical PDF still attract visitors. No source or destination in this example belongs to a real client. The practical lesson is that a launch inventory must include the old site's useful search landings, not just the pages the design team intends to show in the new menu.
Starting assumptions
- A dated export of old URLs exists from the XML sitemap, a crawl and the site's own Search Console or analytics data.
- The destination site has approved new routes and content, but old-to-new equivalence and final HTTP redirects have not yet been tested.
Decisions and checks
Merge crawl, sitemap and search landing evidence into one legacy URL inventory
The migration owner deduplicates paths, normalises the intended hostname carefully and records page type, search contribution and any inbound-link importance. Older pages outside the latest menu still enter the map if they serve buyers. A media PDF gets its own row instead of being silently ignored because it is not an HTML page.
What to verify: A source inventory with stable original URLs and evidence of how each page was discovered, even when the destination site has no obvious matching menu item.
Classify every priority source URL by actual destination meaning
The reviewer identifies a directly equivalent new service page, a genuinely relevant consolidated guide, or a deliberate retirement decision. They do not automatically redirect every obsolete item to the homepage. Where a destination merges material from several sources, its visible content is inspected to ensure it actually answers those older visitor needs.
What to verify: A signed map of source URL, successor, content-equivalence rationale, desired status code and any unresolved exception requiring an owner decision.
Test both the redirect response and the final destination before release
A 301 to a new route is necessary for many moved URLs but is not sufficient: the destination might be blocked, soft-404, canonicalised elsewhere or missing important material. The acceptance sample checks each hop, final 200 page, canonical, sitemap ownership and actual navigation. The same tests are repeated after DNS or hosting cutover.
What to verify: A versioned test report showing the HTTP chain and rendered destination HTML against approved expectations, plus the name and date of the release reviewer.
Preserve recovery evidence and monitor source and destination after launch
The team keeps a before-state crawl, the mapping CSV and high-value URL list so it can investigate changes without guessing. Search Console transition signals may fluctuate while URLs are reprocessed. Missing redirects and accidental noindex are diagnosed as technical defects; later traffic changes are reported as observations rather than guaranteed outcomes.
What to verify: A post-cutover sample with exact URL failures, fixes and follow-up checks for the old and new search properties.
Expected output: The output is a usable migration acceptance register and a release go/no-go decision. It protects the difficult-to-see source content alongside visible core pages, identifies genuinely missing destinations and makes redirect behaviour testable. The site should not be marked migrated merely because the new homepage responds. It should be approved only after the selected high-value source URLs reach relevant, crawlable destination pages and known exceptions have named owners.
The example retailer, URLs and source traffic are illustrative. The worksheet's example.com rows are placeholders, not real redirect rules or verified customer results.
The page you forget is the page you lose track of
A new site can launch with an excellent homepage and still fail to replace an old category page that attracted commercial buyers. Begin with evidence of the old site's real landing pages and important inbound links rather than a developer's new navigation list. Old URLs that are not visible in the latest menu may still be commercially valuable.
Google's site-move guidance recommends compiling important old URLs from sitemaps, logs, analytics and Search Console, then mapping them to relevant destinations. This is a starting point for a disciplined inventory; it does not make a spreadsheet complete or prove that any redirect has been deployed.
Reference: official · 2026-11-07official · 2026-11-07
Map decisions, not just strings
For each source URL, record its purpose, priority, destination and expected final HTTP behaviour. A live equivalent should generally move to a genuinely matching page. A consolidated topic may have a shared successor if its meaning remains relevant. Missing or deliberately removed content needs its own considered response; redirecting every old page to the homepage obscures problems.
Check whether the new page has a self-referencing canonical, remains crawlable and is linked from the new site's navigation. Avoid chains where possible and test both the direct old-to-new response and the final HTML. The acceptance criteria should tell a developer exactly what correct looks like.
Reference: official · 2026-11-07official · 2026-11-07
Rehearse before changing DNS
The companion mapping worksheet includes example source types: content, product, image and intentionally retired URL. Replace them with real exports and add an owner and test status. A staging server can demonstrate much of the routing behaviour, but record which rules can only be proven once the production host and redirects are active.
After cutover, run the same priority URLs and compare observed responses with the approved map. Watch for temporary search fluctuations without automatically attributing every movement to the migration. Keep the before-and-after crawl and decision log so that any recovery work starts from specific evidence.
Reference: official · 2026-11-07official · 2026-11-07
Decision aid
Four different old-URL outcomes need four different decisions
| Old URL type | Content and routing choice | What the tester must capture |
|---|---|---|
| Old service page has a genuinely equivalent new service route | Map to that specific new service; preserve the visitor's original task with a relevant permanent redirect. | Old response and Location header, final service content, canonical and internal links. |
| Two overlapping legacy how-to guides become one substantial replacement | Consolidate only when the new guide demonstrably covers both source topics; record the combined intent. | Source outlines, destination coverage, two old redirect chains and final unique content. |
| Important old technical PDF still receives direct references | Preserve the file or provide an appropriate relevant successor; do not discard it with unused assets. | Downloaded file behaviour, legacy URL requests, external references and sitemap/link updates. |
| Retired page has no useful successor and content is intentionally removed | Document a genuine removal response rather than a blanket redirect to an unrelated homepage. | Approved retirement reason and final 404/410 or other justified response. |
| Old category redirects to a new route that itself redirects again | Review whether a direct mapping can safely replace the unnecessary intermediate hop. | Full chain including each status and Location header, final canonical and content equivalence. |
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.
Reconcile all high-value source URLs against crawls, sitemaps and owned search evidence
Expected result: The migration inventory contains important URLs even when they are absent from the new navigation design.
Keep as evidence: Archived source URL inventory with crawl export, GSC landing-page evidence and a list of exceptions.
Verify that every selected redirect reaches a materially relevant successor
Expected result: Each source path has an approved direct or consolidated replacement that actually answers the user's original need.
Keep as evidence: Signed mapping rows, reviewed source/destination content and an HTTP redirect test run.
Inspect final HTML and robots state on destination URLs
Expected result: The intended production pages are crawlable, have correct canonicals and are linked internally after routing changes.
Keep as evidence: Before/after HTTP headers, rendered metadata, representative sitemap and internal-link crawl.
Repeat a fixed URL sample on the authorised production host after cutover
Expected result: The measured HTTP behaviour matches the accepted map; failures are actionable rather than inferred from traffic charts.
Keep as evidence: Timestamped production test results with URL-level status, release owner and remediation ticket.
Questions worth resolving
Can an old page be redirected to the new homepage if there's no exact match?
Not simply because the old page no longer exists in navigation. A redirect should take the visitor somewhere meaningfully relevant to the original subject. If the content has been consolidated, inspect the replacement and record that editorial decision. If nothing useful remains, an honest not-found response can be more appropriate than a blanket homepage redirect that behaves like a soft error.
Does a complete 301 redirect sheet guarantee that traffic won't fall after a migration?
No. A spreadsheet cannot prove rules are deployed, destination pages are indexable or visitors reach equivalent content. Even technically sound site moves can experience search fluctuations while Google reprocesses URLs. The strongest controllable safeguards are a documented source inventory, destination-content review, staged acceptance tests, and production verification with timely troubleshooting.
Scope and limitations
This planning exercise assumes access to both source and destination sites and a reasonable sample of actual search landing evidence. It does not check live redirects, private Search Console accounts, page performance or real buyer conversions. The correct use of 301, 404, 410, canonicals and sitemap entries varies by the particular URL history and replacement content. A final release requires named owners, current HTTP tests and business approval; this guide cannot substitute for an actual migration audit.
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 guidance documents preparing an old-to-new URL map, using relevant permanent redirects and monitoring source and destination URLs. Recorded: 2026-11-07
- official reference — This official technical reference is used as a supplementary source for canonical, crawl, commerce or SEO implementation decisions discussed in the guide. Recorded: 2026-11-07