Migration First 301 Redirect Mapping with Staging Checklist

A 301 redirect map is a one-to-one source-to-destination spreadsheet that uses HTTP status code 301 to tell search engines a URL has moved permanently. Build it as a full inventory, not a sample. The single action that saves migrations from ranking loss is testing every row in staging until each source URL resolves in one hop to a live 200 page, with no chains and no redirects to the homepage as a catch-all.

---

TL;DR:

• Properly testing each redirect in staging ensures all URLs resolve directly to live 200 pages without chains or redirects to the homepage, minimizing ranking loss.
• Building a comprehensive URL inventory requires crawling the site, analyzing sitemaps, search console data, backlinks, and external links, then normalizing and deduplicating for accuracy.
• Mapping old to new URLs should prioritize one-to-one content matches, avoid redirecting to homepages, and document all decision reasons, especially when no exact match exists for retired or category pages.
• Implementing redirects should use server-appropriate formats like nginx or Apache rules, ordered from most specific to least, with query parameters managed consistently to prevent redirect chains.
• Validating the redirect map in staging, confirming single hop 301s land on correct 200 pages, and checking for loops or canonical conflicts, prevents costly errors post-launch.

---

Table of Contents

• What Is 301 Redirect Mapping and Why Does It Matter for SEO?
• How Do You Build a Complete List of Legacy URLs?
• How Do You Map Old URLs to New Destinations?
• What Are the Best Formats for Implementing Redirects?
• How Do You Validate a Redirect Map Before Launch?
• What Should You Monitor After a Site Migration?
• How Depechecode Approaches Redirect Mapping for Client Migrations
• The Redirect Mapping Advice Most Teams Get Wrong
• Get a Managed Migration Instead of a Spreadsheet Full of Guesswork
• Sources
• FAQ

What Is 301 Redirect Mapping and Why Does It Matter for SEO?

A redirect map is the connective tissue between an old site and a new one. Every row pairs a legacy URL with its replacement and specifies the exact response code the server sends when someone (or Googlebot) requests the old address. Get this wrong, and you’re not just breaking links. You’re telling search engines to forget years of accumulated ranking signals.

Google treats a 301 as a permanent move and reassigns the ranking signals from the old URL to the new one, according to its own crawling and indexing documentation. Codes 302 and 307 signal a temporary change, and Google is far more cautious about transferring authority through them. If a migration is permanent, which almost all are, 301 is the only code that makes sense.

There’s a fourth code worth knowing: 308. It behaves like a 301 in permanence but preserves the original HTTP request method during the redirect, according to Redirect. That distinction rarely matters for a blog post migrating from one URL to another, but it matters enormously for API endpoints, where a 301 can silently convert a POST request into a GET in some client implementations.

• 301: permanent, passes ranking signals, safe default for site migrations.
• 302/307: temporary, use only for short-lived redirects like A/B tests or maintenance pages.
• 308: permanent and method-preserving, the right call for APIs and form submission endpoints.
• Rewrite (not a redirect): happens server-side, invisible to the browser and to Google’s crawler as a separate URL. Fine for internal routing, wrong for public-facing URL changes because it doesn’t communicate the move to search engines.

Pro Tip: If your CMS offers both a “rewrite” and a “redirect” option for handling old URLs, always choose the redirect for anything public-facing. Rewrites keep the old URL alive in the browser bar, which confuses both users and crawlers about which address is canonical.

How Do You Build a Complete List of Legacy URLs?

You can’t map what you haven’t found. Missing even a handful of indexed URLs from your inventory means those pages 404 the day you launch, and recovering from that gap after the fact is far more expensive than catching it beforehand.

Start with a full crawl of the live site using a tool like Screaming Frog run in standard spider mode, then export every indexable URL it discovers. A crawl alone won’t catch everything: orphaned pages with no internal links, old campaign landing pages, or paginated archives that got deindexed but still receive traffic from external links.

1. Crawl the live site. Run a full spider crawl and export the URL list, including redirected and error-status URLs already in place.
2. Pull every XML sitemap, current and historical if you can find archived versions, since sitemaps sometimes list pages a crawler misses due to nofollow links or JavaScript rendering issues.
3. Export Google Search Console’s index coverage report and its performance data for pages that received clicks or impressions in the last 12 to 16 months.
4. Pull top landing pages from analytics (Google Analytics 4 or your platform of choice) sorted by sessions, going back at least a year to catch seasonal content.
5. Export your backlink profile from Ahrefs, Semrush, or Google Search Console’s links report, since external sites pointing to a URL that disappears is exactly how link equity evaporates.
6. Collect marketing and ad URLs from active campaigns, email templates, and print materials with QR codes or short links, since these often bypass the site’s own navigation.

Once you’ve gathered every list, normalize before you merge. Standardize on one protocol (https), one host format (with or without “www,” but pick one), and a consistent trailing-slash convention. Strip session IDs and irrelevant tracking parameters, but keep parameters that control unique content like pagination or filtered views if those pages carry their own SEO value. Deduplicate ruthlessly, and don’t forget non-HTML assets: PDFs, images with direct traffic, and downloadable files that show up in your analytics export just as often as web pages.

A comprehensive pre-migration crawl that consolidates crawl data, sitemaps, analytics, and backlink exports is the foundation every solid redirect map is built on, according to Screamingcat. Skip a source and you’ll find the gap in Search Console’s 404 report weeks after launch, usually right as rankings start slipping.

How Do You Map Old URLs to New Destinations?

The mapping itself is where most migrations lose or preserve their SEO value, one row at a time. The governing principle is simple: every old URL should land on the new page that most closely matches its original content and intent. A blog post about email marketing tips should redirect to the new site’s equivalent post, not to the blog’s homepage and not to a generic “resources” hub.

A practical spreadsheet needs consistent columns so anyone on the team, or a client reviewing the file, can understand a row’s status at a glance:

Column	Purpose
Source URL	The exact legacy URL, normalized for protocol and trailing slash
Destination URL	The new URL it should redirect to
Status code	301, 308, or 410 depending on the case
Action	Redirect, gone, or no change needed
Priority	P1 (high traffic/backlinks), P2 (moderate), P3 (low value)
Owner	Who’s responsible for confirming this row before launch
Reason	Why this mapping was chosen (content match, category fallback, deprecated)
Notes	Anything unusual: canonical conflicts, redirect chains found, client requests

Four rules keep the mapping honest:

• Prefer 1:1 mapping whenever a genuine content match exists. Resist the temptation to batch-redirect similar pages to save time; each redirect should answer the same search intent as the original.
• Preserve protocol and host consistency. A mapping that redirects from an http page to an https destination on a different subdomain introduces mixed signals that dilute the transfer, a point Screamingcat makes explicit for migrations of any size.
• Never bulk redirect to the homepage as a default. It’s the single most common anti-pattern in migrations, and it costs you keyword-level relevance for every page redirected that way, according to Search Engine Journal’s analysis of redirect practices.
• Document every non-obvious decision in the Reason column. Future audits, and future you, will need to know why a page redirected somewhere that isn’t an obvious match.

When there’s truly no equivalent page, you have two honest options. Serve a 410 Gone status for content that’s intentionally retired, which signals to search engines that the page isn’t coming back and should be dropped from the index rather than treated as a broken link. Or redirect to the closest parent category if the content’s subject still exists at a broader level; a discontinued product page can reasonably redirect to its product category rather than vanishing or dumping the visitor on the homepage.

Regex-based pattern rules can handle repetitive URL structures (like a blog with predictable date-based paths) far faster than writing one row per URL. But pattern rules carry real risk. A regex intended to match “/blog/2019/*” can accidentally sweep up URLs you didn’t intend to redirect, creating unintended matches or loops. Use pattern rules only for structurally identical URL groups, and always spot-check the matches against your full inventory before trusting them, a caution echoed in Microsoft’s own documentation on URL rewriting and redirect middleware.

What Are the Best Formats for Implementing Redirects?

Your finished spreadsheet is only useful once it’s translated into a format your server, CDN, or CMS can actually execute. The right format depends entirely on where your site runs.

• nginx uses rewrite or return 301 directives inside server blocks, typically compiled into a dedicated redirect configuration file for readability.
• Apache relies on .htaccess with RedirectMatch or mod_rewrite rules, which work well for shared hosting environments without full server access.
• Netlify reads a plain-text _redirects file at the site root, one rule per line, which makes bulk imports from a spreadsheet almost trivial.
• Vercel uses a vercel.json configuration with a redirects array, supporting both exact-match and pattern-based source paths.
• Cloudflare offers bulk redirect rules through its dashboard or API, useful when DNS and CDN sit in front of multiple origin servers.
• CSV bulk import is the standard fallback for CMS platforms like WordPress redirect plugins, and some platforms such as HubSpot expose a dedicated URL mappings API for programmatic bulk creation.

Tools built specifically for this workflow, like the Map301 redirect map generator, can export directly into several of these formats from a single source file, which cuts down on manual translation errors between spreadsheet and server config.

Three implementation habits prevent the majority of post-launch redirect bugs. Order your rules from most specific to least specific, since most redirect engines process top to bottom and a broad pattern placed too early will swallow requests meant for a more specific rule further down. Escape regex special characters deliberately; an unescaped period or asterisk in a pattern rule matches far more than intended. And decide upfront whether query strings should carry through the redirect or get stripped, since UTM parameters on an old marketing URL usually need to survive the jump for attribution to keep working.

Pro Tip: Rule ordering is the number one source of accidental redirect chains. If Rule 12 catches a URL before Rule 47 was supposed to handle it, you’ve created an unintended detour that a crawler will flag as a chain, even though each individual rule looks correct in isolation.

The most common pitfalls all trace back to the same root cause: rules written and tested in isolation rather than as a complete ordered set. Mixing 302s into what should be an all 301 permanent migration, using the wrong host in a pattern rule, or forgetting that a CDN layer sits in front of the origin server and needs its own redirect logic. All of these surface in staging, if you actually test in staging.

How Do You Validate a Redirect Map Before Launch?

Staging validation is the checkpoint that separates a migration that holds its rankings from one that doesn’t. Upload the full mapping to a staging environment configured to mirror production, then run your original URL inventory back through a crawler in list mode, feeding it the exact source URLs rather than letting it discover pages by following links.

1. Run the full source list through a list-mode crawl and confirm every single URL returns a 301 (or 410, where intended) rather than a 200, 404, or unexpected code.
2. Trace each redirect to its final destination and verify it lands on a 200 status page in one hop, not two or three.
3. Flag and fix every chain and loop. A chain (A redirects to B, which redirects to C) adds latency and dilutes signal strength; a loop breaks the page entirely.
4. Check the canonical tag on every destination page to confirm it matches the URL the redirect actually lands on, not a different canonical that contradicts the redirect target.
5. Spot-check non-HTML assets like PDFs and images from your inventory, since these get overlooked far more often than HTML pages.

Validating the full list in staging with a crawler, confirming single-hop 301s that land on 200 targets, is the step screamingcat.net’s guide treats as non-negotiable, and for good reason: a chain discovered after launch means re-deploying redirect rules while search engines are actively re-crawling a live site, a far messier fix than catching it in staging.

Set a firm acceptance checklist before anyone signs off on launch: zero unresolved chains across the entire mapping, every P1-priority page manually spot-checked by a human, UTM and tracking parameters preserved on the URLs that need them, and every non-HTML asset in the inventory confirmed working. Treat this checklist the way you’d treat a pre-flight check. Skipping one item because “it’s probably fine” is exactly how a migration loses traffic in week one.

What Should You Monitor After a Site Migration?

The two to six weeks immediately following launch are when problems surface, and they surface fast if you’re watching the right signals. Google Search Console’s coverage report will show new 404s or “not found” errors within days of them occurring, and a spike there almost always traces back to a URL that slipped through the pre-migration inventory.

• Watch Search Console coverage daily for the first two weeks, then weekly through week six, looking specifically for a rise in 404 or “submitted URL not found” errors.
• Check server logs for 404 spikes, since logs often catch issues Search Console hasn’t processed yet, especially for URLs Google hasn’t recrawled.
• Compare analytics landing-page traffic against pre-migration baselines for your highest-traffic pages specifically, not just site-wide totals, since aggregate numbers can mask a serious drop on one important page.
• Re-crawl your original source URL list at the one-week and one-month marks to confirm redirects are still firing correctly; server config changes and CDN cache issues can quietly break rules that tested fine in staging.
• Retire temporary workaround redirects once the permanent structure is confirmed stable, and archive the final mapping file in version control alongside the server rules or CDN snippets used to deploy it, a practice that pays off the next time someone needs to audit what changed and why.
• Convert stale or duplicate redirect rules to a 410 if the underlying content has been permanently retired rather than just relocated, which keeps your redirect map lean instead of accumulating dead weight over successive migrations.

Treating the redirect map as a release artifact, versioned, owned, and auditable, rather than a one-time spreadsheet that gets deleted after launch, is what makes the next migration easier instead of starting from zero.

How Depechecode Approaches Redirect Mapping for Client Migrations

Depechecode builds redirect maps as part of full website redesign and migration engagements, not as an afterthought bolted on after launch. The process mirrors the playbook above: a full pre-migration URL inventory pulling from crawls, sitemaps, and analytics; a mapped spreadsheet with priority and ownership columns; staging validation before a single rule touches production; and monitoring through the critical post-launch window.

An audit typically starts with a review of your current URL inventory and backlink profile to flag high-value pages that need priority mapping. From there, the team builds the map, tests it in staging, and coordinates the cutover so indexed rankings transfer cleanly instead of resetting. For businesses handling this in-house, Depechecode’s website migration service page outlines what a managed handoff includes if the internal team would rather focus on content and business operations during the switch.

The Redirect Mapping Advice Most Teams Get Wrong

Most migration guides treat redirect mapping as a technical checkbox: export URLs, match them up, ship the file. That framing undersells the actual risk. The mapping decisions, not the mapping mechanics, are what determine whether a site keeps its rankings or spends six months recovering them.

The overrated piece of advice is speed. Teams rush the inventory phase to hit a launch date, then discover in week three that an entire archived blog category never made it into the crawl because it had no internal links pointing to it anymore. The underrated piece is the Reason column on the spreadsheet. Nobody wants to fill it in, and almost everyone skips it under deadline pressure, but it’s the only thing that lets someone six months later understand why a category page redirects somewhere that looks, at first glance, wrong.

If you take one thing from this playbook, prioritize the staging crawl over everything else. A redirect map that looks correct on paper and hasn’t been list-mode crawled against a staging environment is a guess, not a plan. Do the inventory thoroughly, map with intent rather than convenience, and let the staging validation catch what the spreadsheet alone never will.

— Donovan

Get a Managed Migration Instead of a Spreadsheet Full of Guesswork

Depechecode is the alternative to piecing together a migration yourself from scattered crawl exports and half-tested redirect rules. Instead of building the inventory, mapping schema, and staging checklist solo, and hoping nothing slips through before launch, you get a team that has already run this process across real client migrations and knows exactly where the common failure points hide.

That matters most for businesses mid-redesign or moving platforms entirely, where a mismapped redirect isn’t a minor inconvenience but a direct hit to years of ranking history. Depechecode’s website design and development service folds redirect mapping and staging validation directly into the redesign process, so the technical SEO groundwork happens alongside the design work instead of as a rushed afterthought before launch. If your site also needs a broader SEO health check post-migration, the SEO plans and options page outlines ongoing support for monitoring rankings once the new site is live.

If you’re planning a migration in 2026 and want the redirect map handled by people who’ve already caught the mistakes that cost other sites their traffic, reach out to Depechecode for a proposal.

Sources

• Redirects and Google Search
• Redirect
• 301 Redirect Mapping for Migration: A Complete Guide
• 301 vs 302 redirects SEO

FAQ

How Do I Configure a 301 Redirect?

Configuration depends on your server or CDN. On Apache, add a RedirectMatch 301 rule to .htaccess; on nginx, use return 301 inside the relevant server block; on Netlify or Vercel, add a rule to the _redirects file or vercel.json. Always test the rule in staging before deploying to production.

When Should I Use a 301 Redirect Instead of Another Code?

Use a 301 whenever a URL change is permanent, which covers nearly every site migration, redesign, or domain change. Reserve 302 and 307 for genuinely temporary situations, like a maintenance page or a short-lived A/B test, since Google treats those codes differently when it comes to transferring ranking signals.

Is a 301 Redirect Better for SEO Than Other Options?

For permanent URL changes, yes. Google explicitly reassigns ranking signals from the old URL to the new one through a 301 redirect, while 302 and 307 codes signal a temporary move that search engines treat more cautiously. A properly built 301 redirect mapping process is the most reliable way to preserve rankings through a migration.

What Do 307 and 308 Redirects Mean?

A 307 is a temporary redirect that preserves the original HTTP method, commonly used for short-lived server-side routing. A 308 is the permanent equivalent, preserving the method while also signaling a lasting change, which makes it the better choice for API endpoints where a request type like POST must not be altered during the redirect.

Recommended

• Website Migration
• How To Plan A Website Migration: 2026 Step-by-Step Guide
• Website Redesign Checklist: SEO Preservation & Success