How to Map Old URLs to New URLs in a Redirect Mapping Spreadsheet

Redirects fail silently. A developer pushes three hundred 301s on migration day, the site goes live, and nobody notices that forty of them point to URLs that themselves redirect — creating chains that bleed link equity with every hop. The mistake almost always traces back to the same root cause: the redirect mapping spreadsheet was built without a clear method, or not built at all until the last moment. A well-structured map, prepared before any redirect is implemented, is what separates a clean migration from a months-long SEO recovery project.

If you're looking for expert help in this area, explore how our technical SEO services can drive measurable results for your business.

What a Redirect Mapping Spreadsheet Actually Is

A redirect mapping spreadsheet is a structured document — most commonly a Google Sheet or Excel file — that lists every URL on an existing site alongside the destination URL it should resolve to after a migration, rebrand, or structural change. At its simplest, it is two columns: source and destination. In practice, a production-ready map needs several more.

The document serves three audiences simultaneously. Developers need it to implement rules in the correct format for the server or CMS. SEOs need it to confirm that high-value pages are mapped to genuinely equivalent content. Project managers need it as the audit trail — the record of every decision made and when. If the spreadsheet cannot serve all three, it will be rebuilt three times by three different people, introducing inconsistencies each time.

When You Need One

The most common triggers are website migrations (new domain, new CMS, or new URL structure), site mergers or acquisitions, HTTPS migrations where non-canonical HTTP URLs still receive inbound links, and section-level restructures such as moving a blog from /news/ to /blog/. Any scenario where a URL that has accumulated inbound links or organic rankings is changing requires a mapped redirect — not an ad hoc one added on the day.

The Column Structure That Actually Works

Generic advice says "use two columns — old URL and new URL." That is true, and also insufficient. Here is the column structure Indexed uses for client migrations, with the reasoning behind each field.

The Match Type column is the one most teams omit and most developers wish they had. A prefix redirect for /old-category/ covers dozens of child pages in a single rule; an exact match covers only one. Conflating the two leads to either over-broad rules that catch unintended URLs or under-broad rules that leave hundreds of pages unmapped.

Building the Map: the Right Order of Operations

The sequence in which you build a redirect map matters as much as the columns you include. Working backwards from implementation day is the most common mistake.

Step 1 — Crawl the Live Site Before Anything Changes

Use Screaming Frog SEO Spider or a comparable crawler to export every indexable URL on the current site. This becomes the authoritative source list — the left column of the spreadsheet. Do not rely on a sitemap alone; sitemaps frequently omit orphaned pages that still carry inbound links.

Step 2 — Enrich with Link and Traffic Data

Export inbound link counts per URL from your backlink tool and merge them into the crawl export. Then pull 90-day organic sessions per landing page from Google Analytics or Search Console and add that as a second signal. Any URL with external referring domains or meaningful organic traffic is high-priority regardless of how obscure its content appears.

Step 3 — Map Destinations by Content Equivalence, Not URL Similarity

This is the judgement call that no automation fully handles. The destination URL should be the page on the new site with the most equivalent content — not simply the nearest URL string. A product page at /products/blue-widget-v1/ might map correctly to /shop/widgets/blue/, but it should never be mapped to the homepage just because no equivalent page exists. If there is genuinely no equivalent, a 410 (Gone) is cleaner than a redirect to an irrelevant destination. Sending equity to a mismatched page does not preserve it; it dilutes the destination.

Step 4 — Run a Chain Check Before Handing Off

Before the spreadsheet reaches a developer, check every destination URL against the source column. If any destination URL also appears as a source URL, you have a chain. Chains are not fatal, but each additional hop reduces the equity passed. Google's own documentation notes that it follows redirect chains but recommends keeping them as short as possible. The fix is to collapse the chain: point the original source directly at the final destination.

What Your Map Must Document That Most Guides Ignore

Every guide covers the source-to-destination column pair. Very few cover the decision record — and that omission causes problems six months after launch when a new team member asks why a page redirects to an apparently unrelated destination, or when the client wants to know whether a particular redirect is still needed.

The Notes column should capture at minimum: who approved the mapping for that URL, the date it was agreed, and the logic used. For high-priority pages, a one-sentence justification ("nearest equivalent product page; original page discontinued in rebrand") is sufficient. This transforms the spreadsheet from a technical handoff into a living document that the whole organisation can interrogate without needing to reconstruct decisions from email threads.

Version-Control the Spreadsheet

Google Sheets' built-in version history is adequate for most projects. For larger migrations involving multiple agencies or contractors, exporting a dated CSV snapshot at each major decision point — pre-migration, post-implementation, post-QA — creates an unambiguous audit trail. This matters when a site is sold or replatformed again in future: the redirect history tells the incoming team which URLs have ever carried equity, even if those URLs no longer exist.

Post-Live QA: Closing the Loop on the Map

A redirect map that is never validated against live server responses is a planning document, not a technical control. Within 48 hours of a migration going live, the Status column should be populated with real data.

The quickest method is to paste the Source URL column into Screaming Frog's List mode and run a crawl. The tool returns the actual HTTP status code for each URL. Any source URL returning 200 (instead of 301), 404, or 500 is a failed redirect that needs immediate attention. Any destination URL returning a status other than 200 is a broken target.

Cross-reference the results against the Priority Tier column. Fix Tier 1 (high inbound links, high organic traffic) errors before everything else. A single unmapped URL with fifty referring domains losing equity for a fortnight is a meaningful SEO cost; a Tier 3 URL with no links missing a redirect for the same period is not.

Search Console as the Ongoing Signal

The Coverage report in Google Search Console will surface any URLs that Googlebot encounters returning unexpected status codes in the weeks following migration. Set up a weekly review of the report for the first two months. New 404 errors appearing after the initial QA pass often indicate internal links on the new site that were not updated to point to new URLs, rather than redirect failures — but the spreadsheet is the reference document that confirms which category each error falls into.

FAQ

How many URLs can one redirect mapping spreadsheet handle?

There is no practical upper limit on rows, but spreadsheets with more than around 10,000 URLs benefit from being split by site section — one sheet per category or subdirectory. This makes it easier to assign ownership across team members and to run section-level QA. For very large migrations (100,000+ URLs), many teams export the spreadsheet into a database or use a dedicated migration management tool, but the column logic remains identical.

Should I use 301 or 302 redirects in the map?

Use 301 (permanent) for any URL that will never return to its original form — which covers the vast majority of migration scenarios. Use 302 (temporary) only if you intend to revert the redirect within a defined timeframe, such as a short-term A/B test or a seasonal campaign page. From an SEO perspective, 301s pass link equity; 302s do not consistently. If in doubt, 301 is the correct default for migration work.

What should I do with pages that have no equivalent on the new site?

Resist the reflex to redirect them to the homepage. A homepage redirect from an irrelevant page is a soft 404 in Google's eyes — the server returns 200 but the content does not match the intent of the original URL. If a page has no genuine equivalent, serve a 410 (Gone) to signal intentional removal, or create a minimal equivalent page on the new site if the traffic or link equity justifies the effort. Document the decision in the Notes column either way.

How long should redirects stay in place after a migration?

At minimum, until Googlebot has re-crawled all migrated URLs and updated its index — typically two to four months for a site of average size. In practice, there is almost no cost to keeping 301s live indefinitely: the server overhead is negligible and removing them reintroduces the risk of 404s from inbound links that were never updated at source. The default recommendation is to leave them in place permanently unless a specific technical reason requires removal.

What to Do This Week

If a migration is on your roadmap within the next quarter, the redirect mapping spreadsheet should be started now — not on the week of launch. Here are the specific first steps to take this week:

• Crawl the current site today. Run Screaming Frog against the live domain and export all indexable URLs to a CSV. This is your source list. If you wait until the new site is built, you risk crawling a staging environment that does not reflect all live URLs.
• Pull inbound link data per URL. Export a referring-domains-per-URL report from Ahrefs or your backlink tool of choice. Sort descending. The top fifty URLs by referring domain count are your Tier 1 priorities — the pages where a missing redirect has the highest SEO cost.
• Create the spreadsheet with all nine columns listed above — even if most cells are empty at this stage. Getting the structure right before data entry prevents column-merging later.
• Book a mapping session with both the SEO lead and the content owner. Destination decisions for Tier 1 URLs need both technical and editorial judgement. A developer working alone will map by URL similarity; an SEO working alone may not know which new pages are genuinely equivalent in content. Both perspectives are needed in the same session.
• Add the QA step to the launch checklist now. The Screaming Frog List-mode validation check should be a named task with a named owner and a 48-hour post-launch deadline — not something that gets added retrospectively when traffic drops.

A redirect mapping spreadsheet built before migration work begins is one of the clearest examples in technical SEO of prevention being cheaper than cure. The hours invested in a structured map are a small fraction of the hours typically spent diagnosing and recovering from an unmapped migration six months later.

Related Reading

• What Are Common SEO Mistakes? — Technical errors that compound during migrations and how to avoid them.
• Why Does SEO Still Matter in 2026? — The case for investing in technical foundations when AI is reshaping search.
• What Is Topical Authority and How Do You Build It? — How site architecture decisions affect your authority signals over time.
• Entity SEO: How to Build Knowledge Graph Authority — Why consistent URL structures matter for entity recognition in Google's Knowledge Graph.
• Content SEO: How to Create Content That Ranks, Converts and Gets Cited by AI — The content layer that sits above your technical foundations.