BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Building the 301 Mapping Sheet: The Domain Migration Redirect Map, Done Right vs Done Wrong, Step by Step
The 301 mapping sheet is the single spreadsheet that decides whether a domain migration keeps its rankings or loses them. It pairs every old URL with the new URL that inherits its authority, so the equity built over years moves across the move instead of evaporating at the DNS cutover.
The honest frame is this. Done right, the sheet is a decision register: one-hop redirects, each old page sent to its true topical match, every choice owned and tested. Done wrong, it is a URL dump that points half the site at the homepage, stacks redirect chains, and dilutes the link equity it was built to protect. This guide builds the right version, field by field, and names the mistake that breaks each step.
It also covers the part every competitor guide skips. When the migration is a move onto a new or aged domain, or a consolidation of two or more domains into one brand, the target domain in the sheet is a decision, not a given. SEO Domains operates the curated marketplace where that destination domain is screened before it is priced, so the equity you are about to redirect lands on a clean, vetted name instead of an unchecked one.
What is a 301 mapping sheet, and why it decides the migration
A 301 mapping sheet is the spreadsheet that lists every URL on the old domain and the new URL each one redirects to with a permanent 301. It is the plan a developer or server config executes at launch, and it is the artifact that determines whether the link equity and rankings of the old site survive the move to the new domain.
The 301 in the name is the HTTP status code for a permanent redirect. Google Search Central states that a permanent server-side redirect is the best way to ensure Search and people reach the correct page, and that the indexing pipeline treats the redirect as a signal to make the target the canonical URL. The mapping sheet is where you decide, URL by URL, what that target is.
Why the spreadsheet, and not just a plugin
You can type redirects straight into a CMS plugin and skip the sheet. Migrations that do this lose equity, because the plugin records the redirect but not the reasoning, the priority, or the test result. The sheet exists so the move is auditable: every old URL is accounted for, every target is justified, and every redirect is verified before and after launch.
Siteimprove frames the map as a decision register, not a URL dump, and that distinction is the whole point. A URL dump is two columns and a hope. A decision register records who owns each redirect, why the target was chosen, and whether it passed QA, so a migration of thousands of URLs stays governable.
Done right vs done wrong, in one line each
The sheet is a tactic artifact, so the honest read is two-sided. Done right, it preserves rankings: one-hop redirects, each old page sent to its closest topical match, every row tested. Done wrong, it sheds rankings: catch-all redirects to the homepage, redirect chains, and equity dumped onto pages that do not match what the old URL ranked for.
Done right: the decision register
Every old URL mapped to its true topical equivalent on the new domain, in a single 301 hop, with priority, owner, rationale, and a recorded QA result. The target domain is clean and the equity lands where it belongs.
Done wrong: the URL dump
Bulk redirects to the homepage, chains where one URL hops twice or more, missed URLs left to 404, and high-authority pages pointed at irrelevant targets. The equity dilutes, and Google reads a homepage redirect of a deep page as a soft 404.
The mapping sheet schema: the columns that make it a decision register
A mapping sheet that holds up has more than two columns. The two-column source-to-target format the ranking guides show is enough to fire a redirect, not enough to govern a migration. The schema below adds the priority, ownership, rationale, and validation fields that turn a URL list into an auditable plan, with a worked example for each.
The competitor guides land between two and six columns. Edwin Romero and Adaptive show a two-column source-to-target map. Delante adds a response-code and status column. Siteimprove adds owner, rationale, and evidence. The twelve-field schema here is the union of those, made concrete, so a junior practitioner can copy the header row and start filling it in.
| Field | What it holds | Required | Validation rule |
|---|---|---|---|
| Source URL | The full old-domain URL being redirected | Yes | Absolute, deduplicated, one row each |
| Target URL | The new-domain URL it redirects to | Yes | Must return 200 OK, no further redirect |
| Page type | Category, product, article, tag, paginated, parameter | Yes | Drives pattern rules and review batching |
| Match method | Exact, H1 match, title match, URL stem, manual | Yes | Records how the target was chosen |
| Priority tier | Tier 1 high value, Tier 2 medium, Tier 3 retire | Yes | Set from traffic and backlink data |
| Monthly traffic | Organic sessions over a 12-month window | Recommended | From Analytics or Search Console |
| Referring domains | Count of unique linking domains to the URL | Recommended | From Ahrefs or Majestic |
| Action | 301 redirect, 410 gone, or no-change | Yes | 410 only for deliberately removed pages |
| Implementation method | CMS rule, server config, or edge rule | Yes | Names where the redirect is built |
| Owner | The technical owner and the QA owner | Yes | A named person, not a team |
| Rationale | Why this target was chosen | Recommended | One line, enough to defend the choice |
| QA status | Pending, passed, or failed with the response code seen | Yes | Updated from the staging crawl |
Why ownership and rationale earn their columns
The two columns practitioners skip first are owner and rationale, and they are the two that pay off at launch. When a redirect fires wrong at 2 a.m. on cutover night, the owner column tells you who fixes it without a meeting. When someone questions a target six months later, the rationale column answers without a forensic re-crawl. Storing the sheet in version control, as Siteimprove recommends, gives every change a diff and a reviewer.
How to build the 301 mapping sheet, step by step
Building the sheet runs in seven stages: lock the source inventory, agree the target URL rules, match one-to-one, prioritize by value, resolve the non-matches, make it executable, then test. Each stage has a done-right move and a specific mistake that loses equity. The stages below state both, and link to the supporting guides where each is documented in full.
-
Lock the source inventory of old URLs
Crawl the old domain, then merge that crawl with the XML sitemaps, the Analytics top landing pages over 12 months, the Search Console URL list, and any paid-campaign destinations. Deduplicate, then freeze the list so nothing is added mid-build. Screaming Frog handles the crawl, and its free version covers up to 500 URLs in one crawl, with the paid tier and List Mode taking over at scale.
The mistake: crawling the live site alone. A crawl misses orphaned pages that have no internal links yet still earn traffic and backlinks. Skip the sitemaps and Analytics merge and those high-value URLs never reach the sheet, so they 404 at launch.
-
Agree the target URL rules with the developer
Before mapping a single row, settle the new URL structure: trailing slashes, lowercase, parameter handling, and how faceted navigation resolves. The full pre-launch list lives in the migration technical checklist. Agreeing the rules once means every target you write follows one pattern.
The mistake: mapping against a moving target. If the developer changes trailing-slash behavior after you have mapped 2,000 rows, every one needs re-checking, and the rows you miss become chains or 404s.
-
Match one-to-one, automated first, manual for the rest
Crawl the new domain too, then match old to new. Automate the bulk: split URLs into segments with Text to Columns, and use a lookup formula such as
=VLOOKUP(old_stem, new_range, 2, 0)to pair URLs by stem, H1, or title tag. Wrap it in=IFERROR()so unmatched rows flag themselves for manual review instead of failing silently.The mistake: trusting the formula blindly. A stem match can pair a product URL with the wrong variant. Every automated match on a Tier 1 URL needs a human eye before it ships.
-
Set the priority tier from traffic and backlinks
Score each URL on organic sessions and referring domains, then assign a tier. Tier 1 is the traffic, conversion, and backlink leaders that get manual mapping. Tier 2 is medium value that safe pattern rules can cover. Tier 3 is low or no value, retired with a recorded reason. The detail is in the section below.
The mistake: treating every URL as equal. With no tiers, the team spends the same effort on a zero-traffic tag page as on the URL that holds half the site’s backlinks, and the high-value mappings get rushed.
-
Resolve the URLs with no clean match
A share of old URLs have no exact equivalent. Send each to its closest topical match: the relevant parent category, the replacement asset, or a deliberate 410 if the content is gone for good. The decision rules are in the non-one-to-one section below.
The mistake: redirecting every non-match to the homepage. Google reads a redirect whose destination does not match the old intent as a soft 404, so the equity is discarded and the URL drops out of the index anyway.
-
Make the sheet executable and assign owners
Fill the implementation method per row: CMS redirect rule, server config, or edge rule. Name a technical owner and a QA owner for each batch. Store the sheet in version control so every edit has a diff and a reviewer, and hand a clean, frozen version to whoever builds the redirects.
The mistake: handing over a sheet with blank owners and no implementation column. The developer guesses the method, nobody is accountable for a failed row, and broken redirects surface only after launch.
-
Test on staging before the cutover
Crawl the full old-URL set against a staging environment that mirrors production routing, including CDN and WAF rules. Confirm each URL returns a single-hop 301 to its mapped target and that every target returns 200. The staging method is detailed in testing migrations on staging.
The mistake: testing in production after launch. By then the equity is already leaking. A chain or a 404 found post-cutover costs rankings that a pre-launch crawl would have caught for free.
Prioritizing by traffic and backlink equity
Not every URL deserves the same care, and the sheet records the difference. Prioritization sorts URLs into tiers by the equity they carry, measured as organic traffic and referring domains. Tier 1 gets hand-mapped, Tier 2 rides safe pattern rules, and Tier 3 is retired on purpose. Getting the first 50 high-value redirects right matters more than the long tail.
The two signals that set the tier
Adaptive flags any URL with more than one referring domain as a redirect priority and uses a 12-month organic-landing-page window to find the traffic leaders. Those two signals, links and sessions, are what decide a tier. A URL that holds backlinks carries link equity worth preserving. A URL with sustained organic traffic carries ranking equity worth preserving. A URL with neither is a candidate to retire.
| Tier | What qualifies | How it is mapped |
|---|---|---|
| Tier 1: high value | Top organic traffic, conversions, and the URLs holding the most referring domains | Hand-mapped to the exact topical equivalent, reviewed before launch |
| Tier 2: medium value | Steady but modest traffic, templated pages, a handful of referring domains | Pattern rules with spot-checks, validated as a batch |
| Tier 3: low or no value | Zero traffic, no backlinks, thin or duplicate pages | Retired with a recorded reason, 410 where the content is gone |
The first-50 rule
Siteimprove poses the planning question directly: what breaks if you get the first 50 wrong? Those first 50 are the Tier 1 URLs, the ones holding the traffic and the links. Concentrate QA there before touching the long tail. A flawless redirect on a zero-traffic page earns nothing. A broken redirect on the page holding a quarter of the site’s backlinks can sink the whole migration.
Handling URLs with no one-to-one match: redirect, 410, or rethink
The hardest rows are the URLs with no exact equivalent on the new domain. Three actions cover every case: redirect to the closest topical match, return a 410 Gone for content removed on purpose, or escalate the row for a manual decision. The one action to avoid is the bulk redirect to the homepage, which Google reads as a soft 404.
The decision order for a non-match
Work down the same order on every orphaned URL. First, is there a closely related page, a parent category, or a replacement asset that serves the same intent? Redirect there. Second, is the content deliberately gone with no successor? Return a 410 Gone so the signal is clean. Third, is the URL high value with no obvious target? Flag it for manual review and use the site colon search operator to surface the closest live match before deciding.
Why the homepage redirect is the classic equity leak
Pointing every dead URL at the homepage feels safe because nothing 404s. It is the leading way a migration loses equity. When the destination does not match what the old URL was about, Google treats the redirect as a soft 404 and declines to pass the equity. Edwin Romero and Siteimprove both name the catch-all-to-homepage move as the error to avoid, and they agree because the link graph treats a homepage redirect of a deep product page as a non-answer.
Quality assurance: testing the sheet on staging before launch
The sheet is only as good as its QA. Testing crawls the full old-URL set against a staging environment that mirrors production, confirms every row resolves in a single-hop 301 to a 200 target, and flags every chain, loop, 404, or wrong status code before the migration goes live. A custom script that compares the actual redirect path against the mapped target catches broad rules that silently override specific rows.
What a passing row looks like
A row passes QA when the old URL returns one 301, that 301 lands on the mapped target, and the target returns 200 with no onward redirect. Anything else fails: a 302 instead of a 301, a chain that hops twice, a loop that cycles back, a 404, a 500, or a 200 page that does not match the intent. Crawl the source list in List Mode against staging, and record the response code per row in the QA status column.
| Check | Pass condition | Fail signal |
|---|---|---|
| Redirect status | Single 301 (permanent) | 302, 307, or no redirect |
| Hop count | One hop, source straight to target | Chain of two or more hops |
| Loop check | No cycle back to the source | A to B to A redirect loop |
| Target status | Target returns 200 OK | Target is itself a redirect, a 404, or a 500 |
| Intent match | Target content matches the old URL’s topic | Soft 404, target unrelated to source |
| Robots and canonical | Target indexable, canonical to itself | Target blocked in robots.txt or canonicalized elsewhere |
The error budget and the monitoring window
Define an error budget before launch: a ceiling on 404 landings, on the chain rate, and on redirect latency, above which the launch escalates instead of proceeding. After cutover, treat the first 2 to 4 weeks as an active incident window, with daily Search Console checks for 404 and soft-404 spikes, weekly re-crawls against the sheet, and a quarterly prune of obsolete rules. This is operational work, not passive settling time.
Common 301 mapping mistakes: the equity-loss checklist
The mistakes that drain equity from a migration are a short, repeatable list. Each one is a row in the sheet built wrong, each has a clear reason it costs rankings, and each has a documented fix. The fixes converge on one discipline: map every URL to its true topical target, in one hop, to a clean destination, and test it before launch. Use this as the scannable reference.
The table consolidates the errors scattered through the build and QA sections into one place. The left column is the mistake, the centre column is why it loses equity, and the right column is the done-right fix. Read top to bottom, the fixes describe a mapping sheet that holds its rankings across the move.
| The mistake | Why it loses equity | The fix (done-right move) |
|---|---|---|
| Catch-all redirect to the homepage | A destination that does not match the source is read as a soft 404, so no equity passes | Map each URL to its closest topical target, or return a deliberate 410 |
| Redirect chains | Multi-hop redirects add latency and Google may stop following them | Collapse every chain to a single 301 from source straight to final target |
| Redirect loops | A cycle leaves users and crawlers at a dead end, and the page drops | Test for loops on staging and break any cycle before launch |
| Missed orphaned URLs | Pages not in the crawl 404 at launch and lose their backlinks | Merge the crawl with sitemaps, Analytics, and Search Console before freezing |
| 302 instead of 301 | A temporary redirect signals the move is not permanent, so equity is withheld | Use a permanent 301 for every migrated URL |
| High-value URL to a weak target | Equity from a strong page lands on a page that does not rank for the term | Hand-map every Tier 1 URL and review the target before shipping |
| No QA before launch | Broken redirects surface in production, after the equity has leaked | Crawl the full set on staging, verify one-hop 301 to a 200 target |
| Blank owner and rationale columns | Failed rows have no accountable fixer and choices cannot be defended later | Name a technical and QA owner per row, record a one-line rationale |
| Redirecting to a junk destination domain | A clean redirect to a penalized or thin domain wastes the equity it carries | Confirm the target domain is screened and clean before mapping equity onto it |
| Treating launch week as settling time | Early 404 and soft-404 spikes go unfixed and harden into ranking loss | Run the first 2 to 4 weeks as an incident window with daily monitoring |
One discipline runs down the whole fix column. Map every URL to a real topical target, in one hop, tested, and onto a clean destination domain. The first nine rows are spreadsheet craft. The tenth is the one the ranking migration guides never mention, because they assume the destination domain is fixed and clean. When the migration involves a new or aged domain, that assumption is the decision the next section addresses.
301 mapping sheet frequently asked questions
The five questions practitioners raise when they build a 301 mapping sheet for a domain migration, answered against the migration QA record and the done-right vs done-wrong distinction this guide draws.
Q1What columns belong in a 301 mapping sheet?
At minimum, source URL, target URL, and action (301 or 410). To govern a real migration, add page type, match method, priority tier, traffic, referring domains, implementation method, owner, rationale, and QA status. The first three fire the redirect. The rest make the sheet auditable, so a failed row has an accountable owner and a defensible reason.
Q2Is it fine to redirect old URLs to the homepage when there is no match?
No. A redirect whose destination does not match the old URL’s intent is read by Google as a soft 404, so the equity is discarded. Send each non-match to its closest topical target, a relevant parent category, or a replacement page. Where the content is gone for good, return a 410 Gone instead of forwarding to the front door.
Q3How do I map thousands of URLs without doing each by hand?
Automate the bulk and reserve manual work for the high-value rows. Crawl both domains, split URLs into segments with Text to Columns, and pair them with a lookup formula such as VLOOKUP on the URL stem, H1, or title, wrapped in IFERROR so misses flag for review. Then hand-map and review every Tier 1 URL, the traffic and backlink leaders, by eye.
Q4How do I test the mapping sheet before the migration goes live?
Crawl the full old-URL list in List Mode against a staging environment that mirrors production routing, including CDN and WAF rules. Confirm each URL returns a single-hop 301 to its mapped target and that every target returns 200 OK with no onward redirect. Flag every chain, loop, 302, 404, or 500, fix it, then re-crawl until the sheet is clean.
Q5Does the destination domain affect whether the redirects work?
Yes, and the ranking guides skip it. A 301 can only pass equity to a domain that holds up. Redirecting years of authority onto a thin, penalized, or junk destination wastes the migration regardless of how clean the sheet is. When the move is onto a new or aged domain, screen the target domain’s backlink profile and history before you map a single row of equity onto it.
The target domain the sheet redirects to: source it clean
Every redirect in the sheet ends at the same place: the new domain. The mapping sheet decides which URL inherits each old page’s equity, but the domain decides whether that equity survives at all. When a migration is a move onto a new or aged domain, or a consolidation of two or more domains into one brand, the destination is a decision, and a clean, screened domain is what makes the whole sheet worth building. SEO Domains operates that curated marketplace.
Why the destination domain decides the outcome
A 301 redirect passes link equity to its target. If the target sits on a domain with a toxic history, a penalized profile, or thin inherited authority, the equity arrives somewhere that cannot hold it. The sheet can be flawless and the migration still fails. For a like-for-like move to a fresh brand domain, the destination is chosen, and choosing well is covered in how to pick the new domain for migration.
The consolidation case the sheet has to serve
When two or more domains fold into one brand, the mapping sheet redirects every old domain at a single destination, and that destination carries the combined equity of all of them. The strategy for merging domains without diluting authority is in multi-domain consolidation into one brand. The destination domain in that case is the single highest-stakes choice in the whole migration, because every redirect from every old domain lands on it.
How to source a destination domain that holds the equity
A destination domain that holds up survives a profile check before the migration commits to it. The signals to read are documented across the authority-metrics hub:
- Referring domains and the quality, not just the count, of the links the domain already holds.
- A clean backlink profile with no toxic or spam-flagged inheritance from a prior owner.
- A registration and content history that matches the brand, with no prior penalty or unrelated abuse.
- Authority metrics read together, DR and DA cross-validated against Trust Flow, not trusted as one figure.
A junk destination fails these and wastes the equity the sheet redirects onto it. A vetted destination passes them and is an asset the migration can build on. The metrics method is in the Domain Authority & Metrics hub, and SEO Domains lists aged and expired domains screened across exactly these signals before pricing.
