A redirect map is the contract between an old website and its replacement. It tells browsers, search engines, bookmarks, advertisements, and external links where each valuable URL moved. A good map preserves intent. A bad one sends everything to the homepage and quietly discards years of accumulated signals.
This guide gives you a repeatable process for migrations between builders, frameworks, domains, or URL structures.
What a redirect map actually contains
Use a spreadsheet or database with one row per old URL. At minimum, include:
| Column | Purpose |
|---|---|
| Old URL | Exact currently reachable URL |
| New URL | Final intended destination |
| Action | Keep, redirect, remove, or investigate |
| Status | Expected HTTP status |
| Page type | Product, article, campaign, utility, CMS item |
| Traffic | Recent organic sessions or page views |
| Links | External links or internal references |
| Owner | Person responsible for approving the mapping |
| Test result | Pending, passed, or failed |
Keep query parameters in a separate column. Many parameters are tracking noise, while others change the content or application state. Do not strip them all without review.
Build the source URL inventory from multiple systems
No single source is complete. Combine:
- the current XML sitemap;
- a crawl that starts from the homepage;
- CMS and ecommerce exports;
- analytics landing pages;
- Search Console performance and indexing reports;
- server or CDN request logs;
- paid campaign destination URLs;
- backlinks from an SEO tool, if available;
- routes found in the application or repository.
Normalize the list before mapping. Decide how you will treat trailing slashes, uppercase paths, www, protocols, duplicate query parameters, and URL-encoded characters. Preserve the raw URL too, because normalization can hide a routing bug.
Classify every URL into four actions
1. Keep
If the page and path remain the same, no redirect is needed. Verify that the new site returns 200, the canonical points to itself, and the content still satisfies the same intent.
2. Redirect
Use a permanent redirect when a page has a clear successor. Map at the most specific useful level:
- old product → same product at its new path;
- old article → migrated article;
- retired service → closest replacement service;
- renamed category → new category.
3. Remove
Return 404 or 410 when content was intentionally removed and has no relevant replacement. A clean not-found response is more honest than sending people to an unrelated page.
4. Investigate
Flag URLs whose intent or ownership is unclear. Do not let uncertainty turn into a catch-all homepage redirect.
Choose the right redirect status
For a permanent move, use a permanent server-side redirect. Google specifically recommends permanent server-side redirects such as 301 or 308 for site moves. Read its current site move guidance before launch.
In Next.js configuration, { permanent: true } produces a 308 permanent redirect, while a temporary redirect uses 307. Both preserve the HTTP method, which is one reason the framework uses them. The Next.js redirects reference documents current behavior.
Do not use a temporary redirect for a permanent migration just because it feels safer. The rollback mechanism should be deployment or configuration versioning, not misleading status semantics.
Map intent, not words
Two pages with similar titles may serve different jobs. Evaluate the old page's search query, body content, conversion action, and audience.
For example:
| Old page | Weak destination | Better destination |
|---|---|---|
/pricing-agencies |
/ |
/pricing or /agency |
/blog/form-validation |
/blog |
migrated article on form validation |
/templates/restaurant |
/templates |
restaurant template category |
/contact-sales |
/contact |
sales form or booking page |
When no destination matches the intent, removal may be better than a misleading redirect.
Avoid redirect chains
A chain occurs when A redirects to B and B redirects to C. It adds latency, complicates debugging, and increases the chance that a later cleanup breaks an old link.
Update the map so every historical URL points directly to the current canonical destination:
Bad: /old-a -> /old-b -> /new-c
Good: /old-a -> /new-c
/old-b -> /new-c
Keep old rules when they still receive traffic, but rewrite their destination when the target moves again.
Handle pattern redirects carefully
Pattern rules save time when the old and new structures align exactly. Suppose every route under /journal/:slug moved to /blog/:slug. A wildcard rule may be appropriate.
It becomes dangerous when exceptions exist. CMS migrations often change some slugs, merge several entries, or drop unpublished items. Generate explicit redirects for those exceptions before applying the broad rule.
Order matters. Put exact redirects before general patterns and test that a wildcard cannot capture assets, API routes, or already-correct paths.
Keep four signals consistent
After a migration, these should agree on the preferred URL:
- the redirect destination;
- the page's
rel="canonical"; - internal links;
- the XML sitemap.
Google describes redirects as a strong canonicalization signal and sitemap inclusion as a weaker one. Its canonical URL documentation also warns against conflicting signals.
If /old redirects to /new, but /new declares /old as canonical, you have built a loop in meaning even if the HTTP request does not loop.
Implementing redirects in Next.js
For a manageable static list, keep rules in version control:
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-pricing',
destination: '/pricing',
permanent: true,
},
{
source: '/journal/:slug',
destination: '/blog/:slug',
permanent: true,
},
]
},
}
For thousands of rules or frequent changes, use an edge, proxy, or data-backed approach designed for that scale. Keep editorial ownership and validation outside the request path. A production request should not depend on someone manually opening a spreadsheet.
Test the map automatically
Turn the approved spreadsheet into a test input. For every row marked redirect, assert:
- the first response is the expected status;
Locationis exactly the approved destination;- the final response is
200; - the chain contains no unexpected hop;
- the final canonical matches the destination;
- the page is not accidentally
noindex.
Manual spot checks are still useful:
# First response only
curl -I https://example.com/old-path
# Follow redirects and show every response
curl -IL https://example.com/old-path
Test encoded characters, trailing slashes, uppercase variants, parameters, and paths that resemble static files. Run the same suite against the production hostname immediately after cutover.
Update links at the source
Redirects are compatibility infrastructure, not a replacement for clean links. Update:
- navigation and footer links;
- links inside articles and CMS rich text;
- canonical and alternate-language links;
- structured data URLs;
- image and video references;
- emails, ads, social profiles, and documentation you control.
This gives users a direct request and makes the preferred URL unambiguous.
Monitor the migration by cohorts
Do not judge the migration using only total traffic. Group URLs by type: products, articles, categories, campaign pages, and top organic landing pages. Monitor:
- server errors and redirect loops;
- not-found requests;
- indexed URL counts;
- clicks and impressions;
- conversions from migrated landing pages;
- crawl activity;
- form and checkout failures.
Traffic can fluctuate while search engines recrawl a site. What matters operationally is whether the important old URLs resolve to correct, useful pages and whether technical signals remain consistent.
A practical launch sequence
One to two weeks before launch
- complete the source URL inventory;
- approve destinations with content owners;
- implement exact and pattern rules;
- update internal links and metadata;
- generate the new sitemap;
- run automated redirect tests on preview.
At launch
- deploy redirect rules with the new site;
- verify the top URLs and conversion paths;
- submit the new sitemap;
- inspect production logs for loops and high-volume 404s;
- keep the rollback procedure ready.
After launch
- rerun the entire map daily at first, then on every deployment;
- add legitimate missed URLs to the map;
- correct broken external campaign links you control;
- retain permanent redirects while old URLs still receive requests or have external value.
Redirect-map definition of done
The map is ready when every discovered URL has an approved action, every redirect points directly to a relevant canonical page, automated tests pass on the production hostname, and monitoring can tell you which old paths still receive requests.
The spreadsheet is only the planning artifact. The real deliverable is predictable behavior at every historical URL.