What is Redirect Map?
A redirect map is a structured lookup table that pairs old URLs with their new destinations during site migrations.
What is a Redirect Map?
A redirect map is a structured data file — typically CSV, JSON, or a server config block — that pairs each old URL on a site with its corresponding new URL after a migration, rebrand, or URL restructure. It serves as the single source of truth for every 301 or 302 redirect that needs to fire post-launch. A well-built redirect map preserves accumulated link equity, maintains search rankings, and prevents users from hitting 404 pages. On a typical CMS migration (say, WordPress to a headless Next.js setup), the map can range from a few hundred rows to 500,000+ entries for large publishers. We've shipped redirect maps on 50+ migration projects, and the pattern is always the same: crawl the old site, generate the map, validate it programmatically, then deploy it to the edge or server layer before DNS cutover.
How it works
The redirect map lifecycle has four stages:
1. Crawl & export
Use a crawler like Screaming Frog or Sitebulb to extract every indexable URL from the old site. Export as CSV. Include HTTP status, canonical URL, and any existing redirect chains.
2. Map generation
Match each old URL to its new equivalent. For pattern-based migrations (e.g., /blog/2024/post-slug → /articles/post-slug), write regex or glob rules:
# Nginx map block
map $uri $redirect_target {
~^/blog/\d{4}/(.*)$ /articles/$1;
/old-about /about;
/services/seo /services/search;
}
For one-to-one mappings, a flat CSV works:
old_url,new_url,status
/pricing-2023,/pricing,301
/team/jane,/about#jane,301
3. Validation
Before deploying, run automated checks:
- No redirect chains (A → B → C should be A → C)
- No loops (A → B → A)
- No orphaned old URLs (every crawled URL has a mapping or an intentional 410)
- New URL returns 200 (don't redirect to a page that itself 404s)
We typically write a Node script that fetches every new_url and flags non-200 responses.
4. Deployment
The map gets deployed to whichever layer handles routing: Vercel next.config.js redirects, Cloudflare Workers, Nginx config, or a middleware function in Next.js. For maps over ~10,000 entries, we push to a KV store (Cloudflare Workers KV or Vercel Edge Config) rather than embedding in config files, because build times and cold-start sizes balloon otherwise.
When to use it
You need a redirect map any time URLs change at scale. Specific scenarios:
- CMS migration — Moving from WordPress, Drupal, or Shopify to a new platform where slug structures differ.
- Domain consolidation — Merging
blog.example.comandexample.com/bloginto one path. - URL cleanup — Removing query parameters, fixing casing inconsistencies, or dropping date-based paths.
- Rebrand / domain change —
oldname.com→newname.comwith path changes.
When NOT to use it:
- If URLs aren't changing, don't create redirects "just in case." Unnecessary redirects add latency (each 301 costs ~50-100ms on a cold hit).
- For temporary A/B test routing — use edge middleware or feature flags instead.
- For localization routing (e.g.,
/en/vs/fr/) — that's i18n config, not a redirect map.
Redirect Map vs alternatives
| Approach | Best for | Drawbacks |
|---|---|---|
| Redirect map (flat file/KV) | Large-scale migrations, one-to-one mappings | Requires upfront crawl; manual for dynamic params |
| Regex rewrite rules | Pattern-based URL changes (dates, prefixes) | Hard to audit; easy to introduce loops |
| Edge middleware | Complex conditional logic (geo, cookies + URL) | Adds compute cost per request; overkill for static maps |
| Plugin-based (e.g., Yoast, Redirection) | Small WordPress sites, <500 rules | Doesn't survive a platform migration; DB-dependent |
Our preferred stack for Next.js projects: static entries in next.config.js for <1,000 rules, Vercel Edge Config or Cloudflare Workers KV for anything larger. We avoid storing redirect logic in a CMS database — it's a deployment concern, not a content concern.
Real-world example
A B2B SaaS client migrated from a legacy PHP site to Next.js 14 on Vercel. The old site had 12,400 indexable URLs. We crawled it with Screaming Frog, exported the full URL list, and wrote a mapping script that matched old slugs to new ones using a combination of exact matches (8,200 URLs) and regex patterns (3,100 URLs). The remaining 1,100 URLs were intentionally killed with 410 Gone status codes — thin content pages with zero backlinks. We deployed the map to Vercel Edge Config (lookup time ~1ms at the edge). Post-migration, Google Search Console showed 97% of indexed URLs were re-crawled and re-indexed within 18 days, and organic traffic dipped only 4% in week one before recovering fully by week three.