By Mehdi HassanA redesign is rarely just new visuals. Navigation changes, sections merge, the blog moves from /resources to /blog, and product pages get new names. Each of those changes breaks old URLs that Google, backlinks and bookmarks still point to. A redirect map is how you decide, in advance, where every one of them goes.
This guide gives you the template and, more importantly, the decision rules that make a map good: when to redirect one-to-one, when to consolidate, when to let a page go, and how to avoid chains. It's part of our technical SEO guide for marketing websites. If you're moving platforms as well as redesigning, the 301 redirect map template for migrations covers the platform-migration version of this sheet.
What is a redirect map for a website redesign?
A redirect map is a spreadsheet that lists every URL on the current site and records what happens to it after the redesign: stays the same, moves, merges or is removed. For every URL that moves or merges, it names the destination and the redirect type, usually a 301.
It does three jobs. It forces content decisions before design is final, so nobody discovers missing pages after launch. It becomes the import file for your platform's redirect settings. And it's your test plan on launch day. Industry recovery write-ups consistently name missing redirects as one of the main causes of persistent traffic drops after a redesign, so this document is the cheapest insurance in the project.
What should a redirect map template include?
A redirect map template needs the old URL, the action, the new URL, the redirect type and a reason, plus columns for traffic and links so you know which rows deserve the most care. Keep one row per old URL and never leave the action column blank.
Column | What goes in it | Example |
|---|---|---|
Old URL | Path on the current site | /resources/guides/onboarding |
Action | Keep, move, merge or remove | Merge |
New URL | Final destination path, blank if removed | /blog/customer-onboarding |
Type | 301, 308, 410 or none | 301 |
Clicks and links | From Search Console and a backlink tool | From your exports |
Reason | Why this destination | Merged with two overlapping guides |
Tested | Pass or fail on staging and production | Pass |
Fill the old URL column from three sources: a full crawl of the current site, Search Console's pages export and your backlink tool's top pages. Each catches URLs the others miss, especially old campaign pages and PDFs that nothing links to internally anymore.
When should you use a one-to-one redirect?
Use a one-to-one redirect whenever a page survives the redesign with the same purpose, even if its URL, title or design changes. The old URL goes to its direct replacement, and nothing else points there. This is the default for most rows.
- Renamed paths: /features/reporting becomes /product/reporting.
- Restructured folders: /resources/blog/post-name becomes /blog/post-name.
- Cleaned-up slugs: /blog/2023/05/how-to-price-saas becomes /blog/saas-pricing.
- Changed casing or trailing slashes: handle with a sitewide rule rather than individual rows.
Where many URLs follow the same pattern, such as every blog post moving folders, use a pattern rule in your platform instead of hundreds of rows. Keep individual rows for any URL with meaningful traffic or links, so it gets checked by hand.
How do you redirect pages you're consolidating?
When several old pages merge into one, redirect every one of them to the new combined page, and make sure that page genuinely covers what each old page offered. Consolidation works when the destination answers the old page's question. It fails when it's a loose topical neighbor.
Redesigns are a good moment to consolidate. Startup sites often accumulate three thin pages on the same topic, five near-identical integration pages or a feature page per minor setting. Merging them into one strong page usually helps, but only if the content audit decides what to keep. Our guide to a content audit before a redesign sets out the keep, merge and remove calls.
Hypothetical example: consolidating four use-case pages
For example, suppose a SaaS site has four use-case pages: /use-cases/startups, /use-cases/small-teams, /use-cases/early-stage and /use-cases/founders. They target overlapping audiences and each gets a trickle of traffic.
The redesign replaces them with one page, /solutions/startups, that covers the shared problems and adds a short section for each audience. All four old URLs get a 301 to /solutions/startups. The section headings on the new page reflect each old page's angle, so a visitor arriving from an old link finds what they expected.
What the team avoids is redirecting all four to /pricing or the home page because the new page wasn't ready by launch.
What should happen to pages with no replacement?
Pages with no equivalent on the new site should return a 404 or 410, not a redirect to the home page. Google tends to treat mass redirects to an unrelated page as soft 404s anyway, and visitors who land on the home page instead of what they clicked usually leave.
Old page type | Recommended action | Why |
|---|---|---|
Page with a clear new equivalent | 301 to the equivalent | Keeps users and link signals |
Retired product or feature with backlinks | 301 to the closest current page or a short retirement note | Preserves links where intent still fits |
Expired campaign or event page | 410, or 301 if it has strong links | Nothing to replace it with |
Thin tag or archive page | 404 or 410 | Low value, no equivalent |
Old PDF still linked externally | 301 to the page that replaced it | External links often outlive pages |
How do you avoid redirect chains in a redesign?
Avoid chains by updating old redirects so they point straight to the new final URL. If a 2022 rule sends /a to /b and the redesign moves /b to /c, change the first rule to send /a directly to /c. Every legacy URL should reach its destination in one hop.
Chains build up quietly over several redesigns, and each hop slows users down and gives crawlers another chance to stop. Export your platform's existing redirects before you start, add them to the map as old URLs, and resolve each to its final destination. Then update internal links on the new site so they point to final URLs too, not to redirects. After launch, recheck for new chains every few months, because later edits add redirects too.
How do you test a redirect map before and after launch?
Test the redirect map twice: once on staging before launch, and again on production within an hour of going live. Use a crawler in list mode to request every old URL and confirm each returns a single 301 to the expected destination, which then returns 200.
Load redirects on staging
Import the map into the new platform's redirect settings or config on the staging site.
Crawl the old URL list
Paste every old URL into a crawler in list mode and record status code, hop count and final URL.
Compare against the map
Flag any row where the final URL differs from the map, the hop count is more than one or the final status isn't 200.
Fix and retest
Correct rules, especially pattern rules that catch more than intended, and rerun the list.
Repeat on production
Run the same list against the live domain right after launch. Hosting and DNS changes can behave differently from staging.
Watch Search Console
For the following weeks, check the Pages report for new not found and page with redirect statuses, and add missed URLs to the map.
The map is also the right place to record new URLs for your sitemap and to check canonicals point to final URLs. Our technical SEO checklist for new website launches covers those launch-day checks, and XML sitemaps and robots.txt explains how to keep the sitemap clean.
