Redirect mapping template: plan and QA a site migration

Start with a reviewable map

Keep one row per old URL. In addition to the source and destination, record the reason for the move, the expected status, the final URL observed during testing, and a decision. The last fields make the sheet useful after implementation: a rule can technically work and still send visitors to the wrong page.

old_url,new_url,reason,expected_status,observed_final_url,decision
https://shop.example.test/blue-mug,https://shop.example.test/products/blue-mug,product URL changed,301,,pending
https://shop.example.test/guides/care,https://shop.example.test/pages/mug-care,guide moved,301,,pending
https://shop.example.test/sale-2021,,campaign expired,410,,review
https://shop.example.test/old-category,https://shop.example.test/collections/ceramics,category renamed,301,,pending

All rows and domains here are hypothetical. The first two rows propose one-to-one replacements. The third has no destination because the campaign has expired and there may be no useful equivalent. The fourth proposes a category destination, but still needs a human to confirm that the new collection serves the old URL’s purpose.

Use a stable CSV header and keep the source URL exactly as it was publicly used. A path-only sheet may be easier to read when every URL stays on one host, but full URLs help when the migration changes domain, protocol or subdomain. Quote values containing commas or line breaks, and double embedded quote marks according to CSV rules.

Google’s site-move guidance recommends mapping old URLs to their corresponding new destinations and testing the redirects. Its redirect documentation explains how permanent redirects communicate a move. Those references support the migration process; they do not decide which replacement is relevant for your individual pages.

Choose destinations deliberately

Build the old URL inventory from sources that represent different parts of the site: the current sitemap, analytics landing pages, Search Console exports, internal links, backlinks you know matter, and the existing redirect rules. Deduplicate after normalising obvious variants, but preserve meaningful differences such as case-sensitive paths or query parameters until the server’s routing behaviour is understood.

Then classify each row before assigning a target:

• Direct replacement: the same product, article or service has a new URL. Map the old page to that equivalent.
• Consolidated content: several old pages were intentionally combined. Send each to the surviving page only if that page covers the visitor’s old task.
• Removed with no substitute: do not reflexively send every retired URL to the homepage. Decide whether a relevant category, a helpful successor or an honest gone response is appropriate.
• Unclear or disputed: leave the decision pending and assign an owner. A blank destination is safer in a planning sheet than a confident but unrelated guess.

Include a reason that a reviewer can evaluate, such as “same product, new handle” or “three articles consolidated into this guide.” “SEO” is not a reason. If a proposed target only shares a keyword or broad topic, check whether a visitor following the old link would actually find what they expected.

For every permanent move, plan for the old URL to point straight to the final destination. Do not map old A to intermediate B if B already redirects to C. The redirect-chain guide covers flattening existing hops; this worksheet is for choosing and verifying the migration map itself.

QA the map before launch

Before writing rules, run a spreadsheet review that catches omissions and collisions:

1. Check coverage. Compare your source list with the old sitemap, key landing pages and known externally linked URLs. Mark excluded URLs with a reason rather than silently dropping them.
2. Check destination validity. Request each proposed new URL, or sample by route family where the list is large. Confirm it exists and represents the intended content.
3. Find duplicate sources. One old URL should not have competing rows with different targets. Resolve protocol, hostname, slash and query handling explicitly.
4. Find loops and chains. A target that also appears as a source may create a chain. A source mapped to itself is not a useful move.
5. Review non-redirect decisions. A 404 or 410 can be appropriate when there is no useful replacement, but make that an intentional product decision and check internal links that still point there.

Export only approved source and destination pairs before using the generator; do not paste the six-column review CSV or rows with no destination. For path-based server rules, supply the old request path and the intended replacement URL. You can format those pairs with the redirect generator. It formats pairs for several common configurations and flags simple source-to-target chains in the submitted list. It does not determine whether a mapping is semantically correct, inspect the whole old URL inventory, or apply the rules to your server. Keep the spreadsheet as the decision record; generated output is an implementation aid. The Nginx configuration examples explain path matching and query-string decisions.

Test the published redirects and record the result

After deployment, check the old URLs from outside your logged-in browser. For each row, compare the observed chain and final URL with the proposed destination. A useful migration pass asks:

• Does the old address return the intended permanent redirect, rather than a temporary move or an error?
• Does it reach the expected final URL without an unnecessary second hop, loop or cross-domain surprise?
• Does the final page return successfully, and is it indexable when it is meant to be?
• Do internal navigation, canonical links and the new sitemap point directly to the destination instead of relying on the redirect?

The bulk URL status checker accepts a URL list and reports status, redirect hops, final URL, and selected indexing signals for each checked destination. For a migration, run the old URLs after launch and compare the results with the map’s expected status and destination. It can report what its requests observed; it cannot confirm that a destination is the right editorial replacement or that a search engine has processed the move.

Fill in observed_final_url and decision as you review. Use concise values such as approved, fix target, remove rule or retest, and keep a note when a result differs from the expected route. Then update the rule source and internal links, deploy the correction, and rerun the affected rows.

Do not close the migration sheet just because every old URL returns some response. The job is complete when each important old address has a deliberate outcome, each redirect lands on the intended page, and the site’s own links lead visitors directly to the new structure.

Questions

Keep reading