Redirect map failures are the single most common reason a website redesign loses search traffic. The design is not the problem. The copy is not usually the problem. The problem is that a redesign changes addresses, and search engines have spent years attaching everything they know about your business to those addresses. Move a page without telling anyone where it went, and you have not moved it. You have deleted it.
A URL redirection rule is the mechanism that tells a browser and a crawler where a page now lives. A redirect map is the document that decides what every one of those rules should be, before a single one is written. It is a spreadsheet, or a CSV in version control, with one row for every address that existed before the rebuild and one decision for each. It is unglamorous, it is the first thing cut when a launch date slips, and it is the artefact that determines whether the first month after launch is a recovery or a post-mortem.
Our website redesign SEO migration checklist walks the whole rebuild in sequence — baseline, content parity, staging checks, launch-day runbook, 30-day monitoring. This article takes one step of that checklist and gives it the depth it deserves. If you are costing the work, our guides to SEO cost in the UK and SEO budget planning cover the money, and our SEO pricing models guide covers the contract. This one is about the spreadsheet that saves the project.
Table of contents
- What a Redirect Map Actually Protects
- Five Sources Every Redirect Map Must Draw From
- The Redirect Map Schema: One Row Per Old URL
- How a Redirect Map Chooses Each Destination
- Status Codes: 301, 302, 307 and 308 Compared
- Building the Redirect Map Without Losing a Fortnight
- Testing the Redirect Map Before Anyone Sees It
- Implementing the Redirect Map on Your Platform
- Chains, Loops and the Silent Latency Costs
- Launch Day: Putting the Redirect Map Live
- The First 30 Days: Proving the Redirect Map Worked
- Redirect Map Mistakes That Cost the Most Traffic
- Edge Cases That Break Otherwise Good Migrations
- Retiring the Redirect Map: When to Stop Redirecting
- Redirect Map Questions Teams Ask Most
- References and Further Reading
What a Redirect Map Actually Protects
Before arguing about columns and tooling, it is worth being precise about what is at stake, because the answer is not “SEO” in the abstract. It is a specific, measurable asset that took years to accumulate and can be destroyed in an afternoon.
Search equity is attached to addresses, not designs
Every link another site has ever pointed at you names an address. Every ranking a search engine has assigned you is assigned to an address. Every bookmark, every citation in a supplier’s PDF, every campaign URL in an old newsletter — all addresses. A redesign that keeps your brand, your copy and your products but changes your addresses has, from a crawler’s point of view, replaced your entire website with a new one that nobody has ever linked to. The redirect map is the instrument that transfers the accumulated value across, row by row.
The three migrations hiding inside one redesign
Most teams think they are doing one project. They are usually doing three at once: a design migration, an information-architecture migration, and — very often — a platform migration. The design change is harmless on its own. The architecture change is where URLs move. The platform change is where URL conventions move, silently, because the new content management system has its own opinions about trailing slashes, category prefixes and pagination. Each of the three needs its own pass through the redirect map, and the platform pass is the one that gets skipped.
Why the map is the only artefact that survives
Wireframes get superseded. Content briefs get archived. The redirect map is the only document from the project that still matters two years later, when someone asks why a URL in a trade press article from 2021 still resolves. It is also the only place where the reasoning is recorded: not just that /services/it-support now points at /managed-it-services, but that a human decided it should, and that a different human checked. Treat it as a permanent record, not a launch artefact.
What a missing row costs
A single unmapped page returns a 404. If that page had backlinks, the equity those links carried stops flowing anywhere. If it had rankings, they decay over the following weeks as the search engine confirms the page is genuinely gone. If it was in a paid campaign, the ad spend lands on an error page. Multiply by the number of rows a rushed team omits — usually the blog archive, the old case studies and everything with a query string — and a 5% gap in coverage can account for a fifth of the traffic loss.
Five Sources Every Redirect Map Must Draw From
The most expensive assumption in migration work is that a crawl of the live site produces a complete list of URLs. It does not. A crawler only finds what is linked from somewhere it can reach. Orphaned pages, expired campaign landing pages, PDFs referenced only from an email, and pages that rank but sit three clicks behind a filter are all invisible to it — and all of them can be earning.
Start with a crawl, then freeze the export
Crawl the live site with the settings that match reality: render JavaScript if your pages need it, follow no-index pages so you can see them, include images, PDFs and other documents, and respect nothing. You want the full picture, not the polite one. Then export it and freeze it. The redirect map must be built against a snapshot, because the live site will keep changing while you work and a moving baseline makes every later reconciliation impossible.
Add Search Console’s list of known URLs
Search Console knows about addresses your crawler will never reach, because it records what the search engine has actually indexed and what external sites have linked to. Export the pages report and the links report. This is usually where the orphans appear: old landing pages, a supplier microsite path, a URL that has ranked for years without a single internal link pointing at it. Every one of them needs a row in the redirect map.
Add analytics, for the pages that genuinely earn
Pull twelve months of landing-page data, not three. Twelve months catches seasonality — the Christmas guide that earns nothing in June, the tax-year page that earns nothing in September. Sort by sessions, then sort again by conversions or assisted revenue. The second sort will surface pages the first one buried, and those are the rows in the redirect map that deserve a human decision rather than an automated match.
Add the sitemaps and the CMS export
The XML sitemap is the site’s own declaration of what it thinks exists, and comparing it to the crawl is diagnostic in itself: URLs in the sitemap but not the crawl are orphans, and URLs in the crawl but not the sitemap suggest the generator is broken. The Sitemaps protocol is worth a read if you are rebuilding the generator. Add a raw export of published content from the CMS database too, which catches anything the sitemap logic filtered out.
Add server logs, for what crawlers actually request
Log files are the only source that shows what search engine crawlers request rather than what you published. A month of logs will surface URLs nobody on the team remembers creating, along with the addresses that still receive real crawl budget. If you can only add one source beyond the crawl, add this one — it is the most direct evidence of what a search engine still considers part of your site.
The Redirect Map Schema: One Row Per Old URL
A redirect map is only as good as its structure. Free-form notes in a shared document will not survive the third round of edits. Fix the columns before anyone starts filling them in, and treat the schema as non-negotiable for the duration of the project.
The columns that do real work
Six columns carry the weight: the old URL exactly as it appears including protocol and trailing slash, the new URL in the same form, the status code to use, the reason for the decision, the evidence that justified it, and the person who approved it. Everything else is optional. Resist the urge to add fifteen columns of metadata that nobody will maintain — a redirect map with six well-kept columns beats one with twenty that are half empty.
Status, ownership and verification columns
Add three operational columns alongside the six: a status field with a small fixed vocabulary (proposed, reviewed, implemented, verified), the owner responsible for that row, and the date it was last tested. These are what turn the spreadsheet from a design document into a working tracker. On launch day you will filter by status constantly, and a free-text status column makes that impossible.
Keep it in one place, under version control
The single most common process failure is three copies of the redirect map in circulation: one in the agency’s drive, one attached to an email, one pasted into a ticket. Put the canonical file in version control as a CSV, and let people read it wherever they like. Version control gives you a diff, which is exactly what you want when a row changes two days before launch and nobody remembers agreeing to it.
| Column | What it holds | Why it earns its place |
|---|---|---|
| Old URL | Absolute, with protocol, host and trailing slash exactly as published | Ambiguity here is what produces loops and missed rules |
| New URL | Absolute, in the same form, on the rebuilt site | Relative targets break when the rule moves to the edge |
| Status code | 301, 302, 307, 308 or 410 | Permanence is a signal, and the default should be deliberate |
| Decision reason | Exact match, closest equivalent, consolidation, retirement | Lets you audit whole categories of decision at once |
| Evidence | Sessions, conversions, referring domains, rankings | Turns “this page looked thin” into a defensible judgement |
| Approver | A named person, not a team | Every contested row needs someone who can settle it |
| Status | proposed / reviewed / implemented / verified | The launch-day filter that tells you what is left |
| Last tested | Date of the most recent automated pass | Stale verification is worse than none, because it reassures |
How a Redirect Map Chooses Each Destination
Filling in the destination column is where judgement lives. Automation can propose, but a redirect map that was never reviewed by someone who understands the business will send your best-earning page somewhere plausible and wrong.
Exact equivalents first, and they are the majority
Most rows are easy. The about page becomes the about page. A blog post keeps its content and changes its path. Automate these with confident string matching on slugs and titles, flag anything below a similarity threshold for review, and move on. In the worked example used throughout this article — a 1,412-URL business site rebuilt on a new platform — 1,043 rows resolved as exact equivalents with no human input beyond a sampled spot-check.
Closest equivalent, and never the homepage
When the new site has no exact match, send the visitor to the closest page that answers the same question. A retired product page goes to the category that replaced it, not to the shop landing page. A discontinued service goes to the nearest live service, not to /services. Sending everything to the homepage is the single worst decision available in a redirect map: search engines widely treat it as a soft 404, and the visitor who clicked a specific promise lands on a generic welcome and leaves.
Consolidation and the canonical question
Redesigns often merge four thin pages into one strong one. That is usually good for both readers and rankings, but it needs recording as a distinct decision type, because consolidation changes what the destination has to contain. If four pages merge into one, the survivor should genuinely cover all four topics — otherwise you have not consolidated, you have deleted three pages and redirected them somewhere irrelevant. Google’s guidance on consolidating duplicate URLs is the reference for how canonical signals and redirects interact.
When 410 Gone is the honest answer
Not everything deserves a destination. A 2016 event page, an expired job advert, a discontinued product with no successor — these can legitimately return 410 Gone, which tells a crawler the removal is intentional rather than a mistake. The discipline is to make retirement a decision with evidence attached, not a default for anything nobody recognises. If a page has referring domains or non-trivial organic sessions, it gets a destination.
| Situation | Correct destination | Common wrong answer |
|---|---|---|
| Page exists on the new site with the same purpose | The matching page on the new site | A section index because the slug changed |
| Page retired, close successor exists | The nearest page answering the same question | The homepage |
| Several thin pages merged | The merged page, which must cover all of them | The strongest of the old pages only |
| Page retired, no successor, has backlinks | The most relevant parent, with a note on the row | 410 Gone, discarding the referring domains |
| Page retired, no successor, no traffic or links | 410 Gone, recorded with evidence | A redirect to a vaguely related page |
| Paginated archive beyond page one | The equivalent page of the new archive, or page one | Leaving them to 404 because “nobody links to page 7” |
| Asset: PDF, image or feed | Its new location, same as any page | Excluded from the map entirely |
Status Codes: 301, 302, 307 and 308 Compared
The status code column looks trivial and is not. Choosing the wrong one is a slow failure — nothing breaks, the page loads, and months later the rankings still have not transferred because you told the search engine the move was temporary.
301 is the default, and permanence is the point
A 301 Moved Permanently is the correct code for essentially every row in a redesign redirect map. It tells crawlers to replace the old address with the new one in their index and to transfer the signals attached to it. Google’s own guidance on 301 redirects and site moves is unambiguous about this. Browsers cache 301s aggressively, which is a feature after launch and a hazard during testing — always test in a private window or with caching disabled.
When 302 is genuinely correct
A 302 says “this is temporary, keep the old address”. That is right for a seasonal campaign takeover, a maintenance page, or geolocation logic that varies per visitor. It is wrong for a redesign, and a 302 left in place for months will hold your rankings on an address that no longer serves content. If you find 302s in the map, each one needs a written reason on its row or it becomes a 301.
307, 308 and method preservation
307 and 308 are the method-preserving equivalents of 302 and 301 respectively, defined in RFC 9110. They matter when a POST request must remain a POST across the redirect — form endpoints, API paths, checkout steps. For ordinary content pages, 308 is functionally equivalent to 301 for search purposes but less universally understood by tooling, so most teams stay with 301 and reserve 308 for endpoints that need it.
Meta refresh and JavaScript redirects
Both work in a browser and both are worse. A meta refresh is slow and its handling by crawlers is inconsistent. A client-side JavaScript redirect requires the crawler to execute your JavaScript before it discovers the move, which delays and sometimes prevents the signal transfer. Neither belongs in a redirect map except as a documented last resort where no server-side option exists — and if that is your situation, say so explicitly on the row.
| Code | Meaning | Method preserved | Use in a redesign |
|---|---|---|---|
| 301 | Moved permanently | No, POST may become GET | The default for almost every row |
| 302 | Found, temporary | No, POST may become GET | Only for genuinely temporary states |
| 307 | Temporary, method preserved | Yes | Form and API endpoints, temporarily moved |
| 308 | Permanent, method preserved | Yes | Endpoints that must keep their method |
| 410 | Gone, deliberately | Not applicable | Evidence-backed retirements only |
| 404 | Not found | Not applicable | Never a deliberate choice in a migration |
Building the Redirect Map Without Losing a Fortnight
The reason redirect map work gets cut is that teams imagine it as a fortnight of manual matching. Done well it is not, because the work splits cleanly into a large automated portion and a small, genuinely valuable manual one.
Automate the obvious matches first
Normalise both URL lists — lowercase, strip trailing slashes consistently, remove tracking parameters — then match on slug similarity and page title similarity. Anything scoring above a high confidence threshold gets a proposed destination automatically. In the worked example this handled roughly three-quarters of the redirect map in about four hours of scripting and review, leaving 369 rows that actually needed a person.
Review the money pages by hand, always
Take the top 50 pages by organic sessions, the top 50 by conversions, and everything with more than a handful of referring domains. Deduplicated, that is usually 80 to 120 rows. Every one gets a human decision, recorded with the evidence that justified it. This is the highest-value hour in the entire project, and it is the step that separates a migration that recovers in three weeks from one that never quite does.
Pattern rules versus explicit rows
Pattern rules are seductive because one regular expression can replace two thousand rows. They are also where loops and mis-matches breed, because a pattern matches things you did not think about. The safe compromise is to generate explicit rows from patterns, review the generated output, and deploy explicit rules where your platform allows it. Where volume forces you to deploy patterns — very large catalogues, for instance — keep the expanded row list in the redirect map anyway so the QA pass can still test every address individually.
Budgeting the effort honestly
For a site of one to two thousand URLs, budget around 54 hours of specialist time across the whole exercise. That is not a fortnight; it is roughly a person-week and a half, spread over the project rather than spent in one block. Quoting it accurately up front is also what stops it being the line item that gets cut when the timeline compresses — a point worth reading alongside the GOV.UK guidance on deploying software regularly, which makes the same argument about rehearsal generally.
Testing the Redirect Map Before Anyone Sees It
A redirect map that has not been executed against a real server is a hypothesis. The testing step is cheap, it is fully automatable, and skipping it is how teams discover on launch morning that a quarter of their rules were never deployed.
Run the whole map against staging
Point a script at every old URL in the redirect map, with the staging host substituted, and record what comes back. Not a sample — every row. A thousand requests takes minutes. This is the single most valuable hour in the process, because it converts “we wrote the rules” into “we observed the rules working”, and those are very different claims.
The four assertions every row must pass
For each row, assert four things: the response status equals the intended code, the final destination equals the intended URL exactly, the number of hops is exactly one, and the destination itself returns 200 rather than another redirect or an error. Most teams check only the first. The fourth is the one that catches destinations that were renamed after the map was written, which is a very common late-stage failure.
Spot-check the money pages by eye
Automation confirms the mechanics. It cannot tell you that your best-converting service page now redirects to a page about something adjacent but different. Take the 20 highest-value rows, follow them in a browser, and read the page you land on. Ask whether a visitor who clicked the original promise would feel they arrived somewhere sensible. That question has no automated equivalent.
Test what should not redirect
Half of a good QA pass is negative testing. Assert that the new site’s canonical URLs return 200 and do not redirect anywhere. Assert that the homepage is not caught by a greedy pattern. Assert that a URL not in the map returns a proper 404 with your custom error page. Rules that fire when they should not are harder to notice than rules that fail to fire, and considerably more damaging.
Implementing the Redirect Map on Your Platform
Where the rules live determines how fast they are, how many you can have, and who can change them. Decide this before you build, because moving thousands of rules between layers late in a project is miserable.
Server config, edge rules or application code
Server-level rules — Apache mod_rewrite or the nginx rewrite module — are fast and close to the request, but need a deployment to change. Edge rules such as Cloudflare Bulk Redirects run before the request reaches your origin and can be updated without a release, which is exactly what you want in the first 48 hours; most sites already route through that layer for cybersecurity and caching, so the capability is usually there already. Application-level plugins are the easiest to edit and the slowest, because every redirected request boots your framework first.
Scale limits are real, and they bite late
Every layer has a ceiling. A few thousand explicit rules in an Apache config file is workable; tens of thousands is not, and response times degrade measurably as the list grows. Plugin-based lists in a content management system hit database lookup costs sooner than teams expect. Check the ceiling for your platform against the size of your redirect map before you commit, not after the launch-day latency spike.
Order of evaluation matters more than you think
Rules are evaluated in order, and the first match wins. A broad pattern near the top of the file will swallow specific rules below it, silently. Put explicit one-to-one rules first, patterns last, and document the intended ordering at the top of the file. If you generated the rules from the redirect map, generate them in that order so nobody has to remember.
| Layer | Change speed | Practical scale | Main trade-off |
|---|---|---|---|
| CDN or edge rules | Minutes, no deployment | Tens of thousands | Another system to keep in sync with the map |
| Web server config | Requires a deployment | Low thousands comfortably | Fast, but slow to iterate under pressure |
| Reverse proxy or load balancer | Config reload | Thousands | Often owned by a different team |
| Application or framework | Release cycle | Thousands | Full stack boots before every redirect |
| CMS plugin | Instant, via admin | Hundreds to low thousands | Slowest path, easiest to change by accident |
Chains, Loops and the Silent Latency Costs
The rules can all be individually correct and the result still be wrong, because redirects compose. A chain is what you get when yesterday’s migration meets today’s, and nobody flattened the join.
How chains form without anyone deciding to
Your site moved to HTTPS in 2019, dropped the www prefix in 2022, and restructured its blog in 2024. Each change added a layer. Today a single old URL may go http://www.example.com/old → https://www.example.com/old → https://example.com/old → https://example.com/new. Every hop adds latency and, historically, every hop was a place where signals could be diluted. Google is now clear that it follows reasonable chains, but “it works eventually” is a poor standard for the pages that pay your salaries.
Flatten every chain to exactly one hop
Flattening is mechanical: for each row, follow the chain to its final destination and rewrite the rule to point straight there. Then re-run the QA pass and assert a hop count of one. Do this after the new rules are written, because a redesign will itself create new chains where an old rule and a new rule both match. The hop-count assertion in your test suite is what stops chains coming back the next time somebody adds a rule.
Loops and the “too many redirects” page
A loop is a chain that returns to its start, and it renders your page completely unreachable. They are usually created by an interaction — a rule normalising trailing slashes fighting a rule normalising casing, or an edge rule and an origin rule disagreeing about the canonical host. Automated testing catches loops instantly because the request never resolves, which is another argument for testing every row rather than a sample.
Latency compounds on mobile
Each hop costs a full round trip. On a slow mobile connection, three hops before the page even starts loading is a meaningful chunk of the budget that Core Web Vitals measures. The pages most likely to sit behind long chains are old blog posts and campaign landing pages — precisely the pages that receive cold traffic from people with no patience for a slow first impression.
Launch Day: Putting the Redirect Map Live
Everything up to this point is preparation. Launch day is where the redirect map earns its keep, and it goes best when it is boring, rehearsed and owned by a named person.
Choose the window deliberately
Pick the quietest genuine traffic window you have, which for most British business sites is early on a weekday morning rather than Friday afternoon. Avoid launching immediately before a weekend or a holiday: not because the risk is higher, but because the response time is slower, and what matters is how long a defect stays live. Make sure the people who can roll back are awake and available for the following eight hours.
The first hour
Deploy the rules, then immediately re-run the full automated pass against production. Confirm the sample of highest-value rows by hand. Check that the new site is not blocked by a leftover staging directive — a noindex header or a disallow-all robots file surviving into production remains the most expensive single mistake in this whole discipline. Submit the new sitemap, and leave the old one accessible for a short period so crawlers rediscover the old addresses and follow the rules.
The first evening
Re-run the pass again. Pull the first server-log slice and look at what crawlers requested and what they received. Check the error report for 404s that did not exist that morning, because these are rows the redirect map missed and each one is a five-minute fix now versus a forensic exercise in three weeks.
Name the rollback owner before you need one
Agree, in writing and before launch, who decides to roll back and what threshold triggers that decision. The useful framing comes from deployment practice generally — blue-green deployment and canary releases both exist because reversibility is worth designing for. A migration with a clean rollback path is a migration where nobody has to be brave at 4pm.
noindex header, robots file correct, canonical tags self-referencing.The First 30 Days: Proving the Redirect Map Worked
A modest dip after a migration is normal while search engines re-crawl and re-evaluate. A sustained drop is a defect. The purpose of a 30-day plan is to tell those two apart quickly enough to act, using the redirect map as the reference for what should have happened.
Days one to three: errors and gaps
Watch the 404 report daily. Every new 404 is a missing row — add it to the redirect map, deploy, and mark it verified. Watch crawl statistics for a collapse in crawl rate, which usually means a server or robots problem rather than a mapping one. Do not touch content, titles or internal links this week; you need a clean signal.
Days four to fourteen: indexation
Track how many new URLs are indexed against the count of pages the new site should have. Track how many old URLs remain indexed, which should decline steadily as the rules are processed. Use the Search Console coverage and inspection tools rather than crude site queries. If old addresses are still indexed after two weeks, verify those specific rows are actually firing in production.
Days fifteen to thirty: rankings and the recovery curve
By now rankings should be re-establishing. Compare against the frozen pre-launch baseline, segmented by template rather than site-wide, because an average hides everything useful. Set the recovery target before launch so the conversation is about a plan rather than a mood: a reasonable target for a well-mapped migration is 78% of baseline organic sessions in week one, 88% in week two, 96% in week three, and above baseline by week four. Google’s guide to debugging search traffic drops is the right diagnostic sequence if you fall short.
Change one thing at a time
The strongest discipline in the recovery period is patience. If you change templates, internal linking and page copy in the same week you are diagnosing a dip, you have destroyed your own ability to attribute the outcome. Make one change, wait, measure, repeat. This is also why the redirect map matters as a record — it is the only place that says what the intended state was.
Redirect Map Mistakes That Cost the Most Traffic
These are the failures that recur across projects. None of them are exotic, and every one is cheaper to prevent than to diagnose.
Mapping everything to the homepage
It is the fastest way to produce a complete-looking redirect map and the most damaging. Search engines commonly treat an irrelevant destination as a soft 404, so the equity does not transfer and the row bought you nothing. Visitors bounce because they clicked a specific promise and arrived at a generic one.
Leaving internal links pointing at redirected addresses
The rules work, so nothing looks broken — but every internal link now costs an extra hop, and your own navigation is telling crawlers the old addresses still matter. Update internal links to point directly at final destinations. The redirect map is your worklist for this: search the new codebase and content for every old URL in the map.
Forgetting assets, feeds and everything non-HTML
PDFs get linked from other sites more than most teams realise. RSS feeds are consumed by aggregators that will not investigate a 404. Images have their own search surface. If it had a URL and it moved, it belongs in the redirect map, even though your crawl configuration probably excluded it by default.
Trusting a plugin that “handles redirects automatically”
Automatic redirect features generally detect a slug change within one system and create a rule for it. They do not know about the platform migration, the architecture change, or the URLs that existed two systems ago. They are a useful safety net underneath a redirect map, never a substitute for one — and they are a common source of the chains discussed above.
Deleting pages that looked thin but were earning
Word count is a poor proxy for value. A 180-word page answering one precise question can hold rankings and referring domains for years. Before retiring anything, check sessions, conversions and referring domains, and record what you found on the row. This is exactly the discipline that creating helpful content implies: judge by whether it serves a real need, not by length.
Edge Cases That Break Otherwise Good Migrations
Beyond the straightforward page-to-page rows sit categories of URL that behave differently. Each needs an explicit policy in the redirect map rather than a case-by-case guess.
Trailing slashes, casing and protocol
Pick one canonical form for each and enforce it in exactly one place. Two systems both normalising trailing slashes is the classic loop. Decide whether URLs are case-sensitive on your new platform — they often are on Linux hosts and are not on Windows ones — and normalise before matching, or your redirect map will contain duplicate rows that behave differently in production.
Query parameters and faceted navigation
Tracking parameters should generally be ignored rather than redirected, so that campaign URLs still work. Faceted parameters that generated indexable pages need a decision: redirect to the unfiltered page, keep them with a canonical tag pointing at the parent, or block them. Whatever you choose, write the policy once and apply it to every affected row rather than deciding per URL.
Pagination and archives
Paginated archives are the most commonly forgotten set. If the new site paginates differently, map page-for-page where you can and to the archive root where you cannot. Category and tag archives frequently disappear entirely in a redesign, taking a surprising number of long-tail rankings with them, so check them against analytics before deciding they do not matter.
Multilingual and international sets
If you run language or region variants, every rule must preserve the variant. A rule that sends the German page to the English equivalent breaks the entire hreflang set, and the resulting mess takes months to unpick. Test each locale as a separate pass against the redirect map, and assert that the destination’s language annotations still reference each other correctly.
Retiring the Redirect Map: When to Stop Redirecting
Redirect rules are not free. They accumulate, they slow down rule evaluation, and they make future migrations harder. But retiring them early undoes the work.
The rule of thumb, and why it is not enough
The common advice is to keep rules for a year. That is a reasonable floor and a poor decision rule, because it ignores whether anything is still using them. A page linked from a trade body’s resource list may still send meaningful traffic in year three. A page nobody has requested since week six can go after six months.
Retire by evidence, not by calendar
Instrument the rules so you can count how often each fires. Once a quarter, pull the counts and retire only the rows that have not fired at all in the preceding period and have no referring domains. That converts retirement from a guess into a measurement, and it usually reveals that a small fraction of the redirect map is carrying almost all of the residual traffic.
Keep the document even after the rules go
Retire the rules, keep the file. When the next redesign starts — and it will, in three to five years — the old redirect map is the single most useful document in the building. It tells the next team what used to exist, what was already consolidated, and which addresses have been carrying links since before anyone currently employed joined the company.
Redirect Map Questions Teams Ask Most
How long does a redirect map take to build?
For one to two thousand URLs, budget the 54 hours set out above, spread across the project. Larger catalogue sites scale sub-linearly because more of the work is pattern-based, but they need proportionally more QA. The one thing that does not scale is the manual review of top-earning pages, and that is the part worth protecting.
Who should own it?
One named person, with the technical lead and the content lead as reviewers. Shared ownership across a project team reliably produces the three-conflicting-copies failure. The owner does not have to write every row; they have to be the person who can say authoritatively what the current state of the redirect map is.
Do we still need one if the URLs are not changing?
Yes, and build it anyway — because “the URLs are not changing” is a claim that fails on contact with the new platform about half the time. Trailing slashes, casing, category prefixes and pagination conventions change under you. Building the inventory and running the comparison takes a few hours and either confirms the claim or catches the exceptions.
Do redirects lose ranking value?
A single well-implemented 301 to a genuinely relevant destination transfers signals effectively; that has been Google’s stated position for years. The losses in practice come from irrelevant destinations, long chains, temporary codes used by mistake, and rows that were never written at all. Those are all redirect map problems, not redirect problems.
Can we change domain and redesign at the same time?
You can, and it is usually better to separate them. Doing both at once means that if traffic drops you cannot tell which change caused it. If they must happen together, use Google’s site move with URL changes process, complete the domain change first if the calendar allows, and expect the recovery window to be longer.
What does this cost if an agency does it?
At typical British specialist rates the 54-hour estimate lands in the low thousands, which sits alongside the wider figures in our guides to SEO cost in the UK and SEO services. Compared with a migration that loses a fifth of its organic traffic for a quarter, it is the cheapest insurance available in a redesign.
The same logic applies to a cloud migration cutover plan, where rehearsal is similarly the line item most often cut and most often regretted. If you are planning a rebuild, our digital strategy and software development teams build the redirect map into the schedule rather than bolting it on at the end.
References and Further Reading
Google Search Central: Site Moves with URL Changes
Google Search Central: Redirects and Google Search
Google Search Central: Consolidate Duplicate URLs
Google Search Central: Build and Submit a Sitemap
Google Search Central: Introduction to robots.txt
Google Search Central: JavaScript SEO Basics
Google Search Central: HTTP Status Codes and Network Errors
Google Search Central: Debugging Drops in Search Traffic
Google Search Central: Get Started with Search Console
Google Search Central: SEO Starter Guide
Google Search Central: Creating Helpful, Reliable, People-First Content
Google Search Central: Introduction to Structured Data Markup
Apache HTTP Server: mod_rewrite
Microsoft IIS: Using the URL Rewrite Module
Martin Fowler: Blue-Green Deployment
Martin Fowler: Strangler Fig Application
Google SRE Workbook: Canarying Releases
Google SRE Book: Monitoring Distributed Systems
GOV.UK Service Manual: Deploying Software Regularly
GOV.UK Service Manual: Moving Away from Legacy Systems
GOV.UK Service Manual: Measuring Success
