Skip to content
Now accepting Q2 projects — limited slots available. Get started →
Migrations · Updated Apr 30, 2026

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.com and example.com/blog into one path.
  • URL cleanup — Removing query parameters, fixing casing inconsistencies, or dropping date-based paths.
  • Rebrand / domain changeoldname.comnewname.com with 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.

Frequently asked questions about Redirect Map

Is a redirect map the same as a 301 redirect?
No. A 301 redirect is a single HTTP response that tells browsers and search engines a URL has permanently moved. A redirect map is the collection of all such rules — it's the data structure that contains hundreds or thousands of old-to-new URL pairings. Think of a 301 as one row in the spreadsheet; the redirect map is the entire spreadsheet. The map can also include 302 (temporary) redirects and 410 (gone) declarations, so it's broader than just 301s.
When did redirect maps become standard practice in SEO migrations?
Redirect mapping has been part of migration best practice since at least 2012, when Google's Matt Cutts began explicitly recommending 1:1 URL mappings for site moves. The practice became more formalized around 2016-2017 as tools like Screaming Frog (v9+) added bulk export features and SEOs started sharing CSV-based mapping templates. By 2020, most migration playbooks from agencies and Google's own site move documentation treated a redirect map as a mandatory deliverable, not optional. Today in 2026, it's table stakes for any migration involving more than a handful of URLs.
What's the alternative to using a redirect map?
The main alternatives are regex-based rewrite rules (useful when URL patterns change predictably, like stripping a date prefix) and CMS plugins like the WordPress Redirection plugin. For very small sites (<50 pages), you can sometimes handle redirects manually in server config without a formal map. However, none of these replace the audit step — you still need to crawl the old site and verify coverage. For large sites, there's no real substitute for a structured map. Some teams use database-driven redirect tables, but we avoid that because it couples routing to the CMS and adds a DB query to every request.
How many redirects can a redirect map handle before performance suffers?
It depends entirely on the deployment layer. Nginx map blocks handle millions of entries efficiently because they're compiled into a hash table at startup. Vercel's `next.config.js` redirects start slowing build times around 10,000 entries. Cloudflare Workers KV and Vercel Edge Config are designed for large key-value lookups and handle 100,000+ entries with sub-2ms lookup times. The key rule: don't put huge maps in application code or config files that get parsed on every cold start. Push them to a key-value store at the edge. We've deployed maps with 80,000+ entries on Cloudflare Workers KV with no measurable latency impact.
Get in touch

Let's build
something together.

Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.

Get in touch →