Online Tool Store Online Tool Store
↪️ SEO & Web

· 5 min read

How to Build a Redirect Map for a Migration

Heshan Fernando

Co-founder & COO

Heshan Fernando is the Co-founder and Chief Operating Officer of Ceyentra Technologies, where he leads project management, engineering, and research and development strategy. With over nine years of industry experience, he is passionate about transforming complex customer challenges into practical, high-impact solutions. His customer-centric leadership has enabled multidisciplinary teams to consistently deliver secure, scalable, and industry-grade digital products that create lasting business value. View on LinkedIn

Share

How to Build a Redirect Map for a Migration

The new site launches on Tuesday. Everything looks right, the content transferred, the design is better. Three weeks later organic traffic is down forty percent and nobody can point at the cause.

The cause is nearly always the same: URLs that changed and were not redirected. The pages that were ranking are exactly the ones with inbound links pointing at addresses that now return 404.

What a redirect map is for

Every URL that existed on the old site needs a destination on the new one. That is the whole job, and it is unglamorous enough that it gets left to the week before launch.

Three things make it fail.

Unmapped URLs. Any old URL with no entry in the map returns 404 at launch. Its rankings, its inbound links and its traffic go with it. This is the largest single cause of migration traffic loss.

Chains. Old URL A redirects to B, which redirects to C. Each hop costs a request, and search engines follow a limited number before giving up. Chains usually appear because a previous migration’s redirects were never collapsed.

Loops. A redirects to B and B redirects back to A. The browser gives up and the page is unreachable. This happens when the two sides of a mapping are edited independently.

ProblemConsequence
Unmapped URL404 — rankings and links lost
Chain of 3 hopsSlower, signal degrades
LoopPage unreachable
302 instead of 301Signals stay with old URL

301 or 302

A migration is permanent, so 301.

A 302 tells search engines the old URL will return, so they keep the signals attached to the old address and do not transfer them to the new one. On a migration that is exactly wrong, and it is a common accident because some frameworks and CDNs default to 302.

Check what your server actually sends rather than what you configured. The two differ more often than you would expect, particularly behind a CDN or a load balancer that adds its own redirect layer.

Build the map from a crawl, not from a sitemap

The sitemap lists what the old site intended to expose. A crawl lists what actually exists, including pages the sitemap missed, old campaign landing pages, and paginated URLs nobody remembered.

The gap between the two is where the surprises are. A sitemap with 1,200 URLs and a crawl finding 3,400 means 2,200 URLs that will 404 unless someone looks at them.

Include URLs with parameters, and decide deliberately what happens to them rather than letting them fall through.

Preserve the query strings that matter

A detail that costs traffic on sites with parameterised URLs.

Most redirect rules drop query strings unless configured to preserve them. That is correct for tracking parameters, which the new URL does not need, and wrong for parameters carrying meaning — a search term, a filter, a pagination position, a product variant.

Dropping a meaningful parameter sends the visitor to a page that is related but not what they clicked, which reads as a broken link even though it returned 200.

The rule is to preserve deliberately: pass through parameters the new site understands, drop the rest. Deciding that per parameter takes an hour and prevents a category of complaint nobody will connect to the migration.

Common mistakes to avoid

  • Mapping only the URLs in the sitemap.
  • Leaving chains in place because each individual redirect works.
  • Using 302 for a permanent move, or not checking what the server actually returns.
  • Redirecting everything unmapped to the home page, which search engines treat as a soft 404 and users find useless.
  • Not re-crawling the old URL list after launch, which is the only way to prove the map worked.

How to do it with Redirect Map Builder

The Redirect Map Builder checks the map before it goes live.

  1. Paste the old URL list from a crawl of the live site and the new URLs from staging.
  2. Review the flagged rows first — chains, loops and anything unmapped.
  3. Export in your server’s format.
  4. Re-crawl the full old URL list after launch and confirm every one resolves with a single 301.

Google’s site move documentation covers the wider migration process. Other SEO tools are in the tools directory.

Frequently asked questions

Why do redirect chains matter if each hop works?

Each hop costs a round trip, search engines follow a limited number, and a little signal is lost at each step. Map every old URL directly to its final destination instead of relying on the chain resolving.

What happens to URLs I forget to map?

They return 404. On a migration that is the largest cause of lost traffic, because the pages worth mapping are exactly the ones with inbound links and rankings.

Should unmapped pages redirect to the home page?

No. A bulk redirect to the home page is treated as a soft 404 and gives users nothing. Map to the closest equivalent page, or return a proper 404 if there genuinely is none.

Final thought

Build the map from a crawl, not a sitemap, and re-crawl after launch. The URLs nobody remembered are the ones that were quietly carrying your traffic.

Try the free Redirect Map Builder

#redirect-map#site-migration#301-redirects#redirect-chains#online-tools#free-tools