Before moving a site, decide where every important old URL should lead. The destination should fulfill the reason someone followed the original link. A technically functioning redirect to an unrelated page can still be a bad migration outcome.
Start with a reviewable map, then implement the approved decisions. The map needs an old URL, its intended successor, a reason for that relationship, and an owner for exceptions. Treat an unresolved destination as unfinished work. A spreadsheet filled with the new homepage is not a completed mapping exercise.
Google's site-move guidance, checked September 9, 2026, recommends permanent server redirects where possible, direct destinations instead of chains, updated internal links, and relevant replacements. It warns against sending many unrelated old URLs to a single irrelevant destination. The worksheet below turns that guidance into an editorial and engineering handoff.
Assemble the inventory before choosing replacements
Collect URLs from the current content system, sitemaps, available traffic records, and known inbound links. Record where each row came from. A crawl alone may miss an old landing page that still receives campaign clicks but is absent from the current navigation.
Include downloads and other linked assets. A guide can survive the migration while its workbook quietly disappears. Give those assets their own rows, with the page that introduces them. Also identify URLs that should stay unchanged; preserving a useful established path can be simpler than creating another redirect.
In a fictional 120-page site move, the team might identify 95 unchanged pages, 15 renamed guides, six consolidated pages, and four retired offers. Those numbers describe mapping decisions, not an SEO forecast. The six consolidations deserve a content review: does each destination actually contain the material an old visitor expects?
Give the sheet enough columns to resolve disagreement
Use the following fields. Keep the implementation status separate from the editorial decision so a developer cannot accidentally treat an unapproved suggestion as a launch instruction.
| Field | What belongs there |
|---|---|
| Old URL and current purpose | The exact path and the job it performs |
| Decision | Keep, move, consolidate, retire, or unresolved |
| Proposed destination | An exact URL, not a section name |
| Reason and evidence | Why the replacement serves the original visitor |
| Owner and approval | Who accepted the content decision |
| Implementation and verification | Configured rule, observed response, final destination, test date |
Avoid putting multiple old URLs in one cell. Each old path should have its own observable result even if several converge on a genuinely consolidated resource. Keep a separate note for common patterns that engineering can implement together.
Work through three difficult rows
Imagine an old guide at /guides/first-manager now has a fuller successor at /careers/first-management-role. The topic and audience match. The reviewer checks that the new guide retains the original practical advice and approves that destination.
A second URL, /offers/summer-workshop, promoted an event that has ended. Sending visitors to the homepage hides what happened. The team should decide whether a useful event archive belongs at the original path or whether the content should be retired. A new unrelated workshop is not automatically the same resource.
A third URL, /templates/offer-sheet.xlsx, has been replaced by a new workbook with changed assumptions. Here the content owner must review the file itself. Does the new download still do the promised calculation? Does the introducing page explain the change? An accurate filename alone does not prove equivalence.
These decisions benefit from product or editorial judgment before any redirect rule is written. Engineering should not have to infer the meaning of historical content from a slug.
Test the route and the destination
For each implemented row, record the first response, every intermediate hop, and the final response. Then inspect the actual destination content. A successful status code only establishes that a server returned something; it does not establish that the expected guide or file arrived.
Use representative pattern checks and explicit checks for high-value exceptions. If a broad rule changes /blog/ to /learn/, test a normal article, a nested path, a trailing-slash variant, and a known retired page. Check that the rule cannot accidentally capture an asset path or a similarly named product route.
Review internal links against the approved new destinations. The migration map can also identify campaign links and externally managed profiles that need their own owner. Put inaccessible systems on the exception list instead of claiming the whole migration is finished.
Define completion and recovery
Before launch, name the person who can reverse a bad rule, preserve the prior configuration, and decide which failures require intervention. After launch, compare observed errors with the mapping decisions, not merely with an aggregate traffic chart.
Close a row when its approved behavior is observed and its destination fulfills the intended task. Keep unresolved historical paths visible for follow-up. Pair this map with the technical launch review so content, routes, and conversion paths are checked together.
For the next implementation step, use Review a missing-page response before calling it a 404.