SEO Site Migration and Redirect Mapping

What a Redirect Map Has to Contain

A site migration keeps its rankings when every old URL that earned traffic or links resolves to the right new page. The redirect map is the file that makes that happen, and it is a spreadsheet before it is a server configuration.

Five columns are enough:

Google's guidance on redirects treats a permanent redirect as the signal that the target should be canonical, and recommends keeping redirects in place for as long as possible. That makes the status column a decision, not a default. A page removed without a successor is a 410 or a 404, and it should be recorded as such rather than pointed at the home page.

Build the URL Inventory

Start with four sources and merge them into one list. Each one misses something the others catch.

• A crawl of the old site: Pages that are linked internally and reachable from the navigation. This is the largest list and the easiest to gather.
• The XML sitemap: Pages the site intended to be indexed, including ones that are no longer linked.
• The Search Console 404 report: URLs that real visitors and crawlers requested after they stopped working. This is the only source that records demand for pages which no longer exist anywhere on the site.
• Analytics landing pages: The URLs that actually received organic sessions in the last 12 months, ranked by sessions.

Deduplicate the merged list on the normalised path before anything else. The same page usually appears with and without a trailing slash, in upper and lower case and with campaign parameters attached, and each variant looks like a separate URL until it is cleaned.

Normalise URLs Before Matching

Matching full URLs wastes precision. The protocol, the host and the query string differ between the old and new site by definition, so they add noise to every comparison.

1. Strip the protocol and host: Reduce https://www.example.com/pricing/teams to /pricing/teams.
2. Decide on the trailing slash: Pick one convention and apply it to both columns. A mismatch here turns an exact match into a fuzzy one.
3. Lowercase the path: Case-sensitive servers treat /Pricing and /pricing as different pages.
4. Drop tracking parameters: Remove utm_ values and session identifiers, keeping only parameters that change the content, such as a product identifier.

Text Standardisation in Flookup applies these steps across the column in one pass, so both lists reach the matching step in the same shape.

Match Old Paths to New Paths

With clean paths on both sides, the comparison is between page slugs rather than between two unrelated domains. Three passes cover the list:

1. Exact match first: A VLOOKUP or XLOOKUP on the normalised path resolves every page that kept its slug. These rows need no review.
2. Fuzzy match the remainder: Run Fuzzy Match on the unmatched paths with a threshold around 80 per cent. Slugs that gained a word, changed a category or dropped an abbreviation land here. The fuzzy matching guide explains how the score is calculated.
3. Look the full URL back up: The fuzzy step returns a matched path. Use it to retrieve the original destination URL from the new-site column:
   =VLOOKUP(E2, D:B, 2, FALSE)

Review the fuzzy band by hand. A slug such as /blog/csv-tools matching /blog/csv-editor may be correct, while /pricing matching /pricing-enterprise sends a general visitor to the wrong plan. The map is a proposal until a person has read those rows.

Prioritise by Traffic and Links

Not every URL deserves the same review effort. Sort the map by organic sessions and by the number of external links pointing at the old URL. The top of that sort is where a mistake costs the most, and it is usually a small share of the list.

Three groups are worth separating:

• Pages with sessions and links: Review each one by hand and confirm the destination is the closest equivalent, not just the same category, even when the category label looks obvious.
• Pages with links but no sessions: These still pass authority through the redirect, so a wrong destination quietly sends link equity to an unrelated page.
• Pages with neither: Bulk-accept the fuzzy suggestions and spot-check a sample. If nothing links to the page and nobody visits it, the cost of an imperfect destination is low.

Validate the Map Before Launch

A map that looks correct in the sheet can still fail on the server. Four checks catch most of it before the DNS change:

1. Every destination returns 200: A redirect to a page that itself returns 404 is worse than a direct 404, because it hides the problem behind a valid status code.
2. One hop only: Old URL to new URL, not old to staging to new. Chains slow crawlers and dilute the signal.
3. No loops: Check that no destination appears in the old URL column. A pair that points at each other produces a redirect error.
4. No catch-all to the home page: Sending every unknown URL to the home page tells search engines that the content is gone and leaves the visitor without the page they wanted. Use a 404 or a targeted redirect.

Test the rules on a staging host with the production paths, then compare the status codes against the map. A script that requests each old URL and records the final status and destination turns this into a reviewable column, and it is the check that catches the rule that never fired.

After Launch

Keep the map in the sheet after deployment. It becomes the record of what changed, and it answers the first question of every post-migration report.

Monitor the Page Indexing report in Search Console for new 404s and soft 404s over the following weeks. A page that starts returning 404 after launch usually means a redirect rule was missed, a slug was renamed twice or an internal link still points at the old path. Fix those in the map and the internal link, not by widening a catch-all rule.

Update internal links to point at the new URLs directly. A redirect handles external links and bookmarks, but an internal link that still uses the old path adds a hop for every crawl and every visitor.