A redirect map translates an old website address into a deliberate destination on the new site. It should be detailed enough for a developer to implement and for a reviewer to challenge. This guide focuses on that mapping document: identifying source URLs, deciding equivalents, handling exceptions and testing rules. It applies to service websites, publication archives and domain changes as well as online shops.
Define the mapping boundary
List the hosts, paths and asset types affected by the move. A domain change may involve historic subdomains, downloadable guides and old campaign addresses as well as current pages. Record which systems serve them. A redirect implemented in the application will not help an address intercepted by a separate hosting rule before the application runs.
Agree which version of the site the map describes and when it will be frozen for implementation. Assign someone to record content changes made after that point. Otherwise, an editor can create a new page on the old site that never enters the migration inventory, even when the original mapping work was complete.
Keep raw addresses and comparison keys separate
Combine crawl results, sitemap exports, known incoming links and available request records. Keep the original URL in a dedicated field. Create a separate comparison key if you need to group variations, and document how it is generated. Lowercasing every path or removing every query string can merge addresses that the existing application treats differently.
Classify parameters by their function. A campaign parameter may only affect attribution, while a document identifier determines which content appears. Ask the application owner about uncertain cases. The map should preserve meaningful distinctions and specify how irrelevant variations will behave without inventing a rule from appearance alone.
Give every source an explicit disposition
Use categories such as unchanged, moved equivalent, merged, retained archive and removed without replacement. Not every row needs a redirect. An unchanged address may need confirmation that the new server still returns the intended content; an obsolete page may have no honest destination.
Google's site-move documentation recommends mapping old addresses to their new equivalents and avoiding irrelevant mass redirects. Treat destination relevance as an editorial decision. Redirecting every retired article to a service homepage can leave visitors without the information they requested, even if the rule executes successfully.
| Map field | Purpose |
|---|---|
| Exact source | Preserve the address that must be handled. |
| Disposition and destination | State whether the content stays, moves, merges or ends. |
| Reason and approver | Explain why the destination answers the original request. |
| Expected response | Give the implementer a testable result. |
| Observed result | Record the response and final page after implementation. |
Resolve merges before generating rules
Suppose two hypothetical guides about preparing a project brief are being combined. Identify the useful material from both and approve the consolidated page before mapping their old URLs to it. An empty destination with the right title is not an adequate replacement. Record any anchors or downloads that existing readers may still need.
Keep uncertain rows in an exception queue with an owner. Flag missing destinations, several plausible replacements and content that has not yet been approved. Do not quietly assign those rows to a generic category to make the spreadsheet appear finished. An unresolved mapping is a visible launch dependency.
Translate the map into predictable rules
Google's redirect guidance distinguishes permanent moves from temporary redirects. Select the response according to the actual move and implement it at an appropriate server layer. Document rule order, because a broad pattern can capture an address before a more specific exception is evaluated.
Use patterns only where the relationship is genuinely consistent. A directory rename may support one rule; an editorial reorganisation often requires individual mappings. Include examples that should match and examples that must not match. Review case, encoded characters, trailing slashes and query behaviour against the site's actual routing conventions.
Test complete requests and final content
Run each mapped source through the intended production rule set and capture the status, destination and redirect sequence. Check for loops and unnecessary intermediate hops. Open representative final pages to verify their content and intended indexing settings. A final successful response does not prove that the destination is relevant or ready.
Test unmapped addresses too. A catch-all rule can hide missing content by redirecting unknown URLs to a real page. Include deliberately nonexistent paths and confirm they behave as intended. Separately check that internal links now use final addresses, so normal browsing does not depend on the migration rules.
Maintain the map after launch
Keep the approved mapping and test evidence under version control or equivalent change tracking. Review incoming requests to old addresses and investigate missing cases. Google advises retaining redirects for at least a year; continued visitor use may justify keeping them longer. Include the domain and hosting arrangements needed to make that possible.
When a destination changes again, update earlier sources towards the appropriate final page and retest affected rules. Record who owns this maintenance after the migration project closes. The map remains a description of public URL behaviour, not a disposable spreadsheet whose usefulness ends on launch day.
Visuosofts' SEO migration services are relevant when a move needs a reviewable redirect specification. Read the content pruning decision checklist before deciding which pages to retire. Contact Visuosofts with the old and proposed URL structures to discuss the mapping work.
