Migration redirect maps: the most important deliverable nobody plans for.

The deliverable nobody budgets for

Every redesign and every replatform ships with a redirect map. The only question is whether someone built it on purpose or whether it got thrown together at 11pm the night before launch. We have seen both. The difference shows up in Search Console about ten days later, and by then it is expensive to fix.

A redirect map is the document that says: this old URL now lives at this new URL. One row per address. When a site changes structure, and almost every redesign changes some structure, the old links and the old Google index entries still point at the old addresses. Without a map, those addresses return a 404 or, worse, a 200 page that says “oops, not found.” Years of accumulated ranking signal, every backlink someone earned, every bookmark, every citation in a forum from 2019, all of it drains away quietly. Nothing crashes. Nothing alerts. Traffic just slides.

We treat the map as a first-class deliverable, the same way we treat a staging environment or a backup. It is not launch-week cleanup. It is part of the build.

301 versus 302 is not a detail

A 301 tells search engines and browsers: this moved, permanently, update your records. A 302 says: this is a temporary detour, keep the old address on file. Google honors that distinction. A 301 passes ranking signal to the new URL and eventually drops the old one from the index. A 302 holds the old URL in place and is much slower, sometimes never, to consolidate signal onto the destination.

For a migration, you want 301s on almost everything. The trap is that a lot of plugins, server defaults, and developers reach for 302 because it is the lazy default in some frameworks, or because someone tested with a temporary rule and forgot to flip it. We have inherited sites where the entire migration ran on 302s for four months. The old URLs were still indexed, the new ones were treated as duplicates, and the client could not understand why a clean migration tanked their organic traffic. It was one wrong status code repeated a few thousand times.

So: 301 for permanent moves. 302 only when the move genuinely is temporary, which during a migration it never is.

How we actually build the map

It starts with an inventory, not with guesses. You cannot map URLs you do not know exist, and the worst migrations are the ones where someone mapped the 40 pages in the main nav and ignored the other 1,400.

Crawl the old site completely

We crawl the old site with Screaming Frog before we touch anything. Every URL that returns a 200. Then we cross-check that crawl against three more sources, because a crawler only finds what is linked:

• The XML sitemap, which often lists pages that are orphaned in the nav but still indexed.
• Google Search Console’s page indexing report and the Search Analytics export, so we know which URLs actually earn impressions and clicks. Those are the ones that must not break.
• Server access logs or analytics, which surface old URLs that still get traffic from external links even if they were dropped from the site years ago.

The union of those four lists is the real surface area of the site. It is almost always bigger than the client thinks.

Map each URL to its best equivalent

Then the slow part. Every old URL gets mapped to the single best new equivalent. Not the closest category. Not the homepage. The page that serves the same intent. An old blog post about WooCommerce shipping zones maps to the new post on the same subject, not to /blog/. A discontinued product maps to its replacement or its parent category, with a real explanation on that page, not to a generic 404.

This is judgment work, and it is why the map is a deliverable and not a script. A find-and-replace on the URL structure handles the easy 80 percent. The remaining 20 percent, the renamed sections, the consolidated pages, the content that no longer exists, is where rankings live or die.

Preserve structure and parameters where they matter

Where the URL carries meaning, we keep it. Pagination, filtered category views, tracking parameters that feed Klaviyo flows or ad attribution, these are not noise. If an old store used /shop/?category=peptides and the new one uses /shop/peptides/, that mapping has to be explicit or the parameter version returns nothing. We have watched a client lose a chunk of paid traffic because the migration ignored UTM-tagged landing URLs that the ad platform was still serving. The page existed. The exact address the ad pointed at did not.

The failure modes we keep cleaning up

Most of our redirect work is not greenfield. It is cleanup, because someone treated the map as an afterthought. The patterns repeat.

• Redirect chains. Old URL redirects to a second URL, which redirects to a third, which finally lands. Each hop bleeds a little signal and adds latency. Google will follow a chain, but it gives up after a handful of hops and stops passing equity. Every redirect should point directly at the final destination. One hop.
• Redirect loops. A points to B, B points back to A. The browser throws “too many redirects” and the page is simply dead. Usually caused by two redirect systems fighting each other, a server rule and a plugin rule, neither aware of the other.
• Soft 404s. The page returns a 200 status but the content is a “not found” message, or it is that blanket redirect to the homepage. Google flags these in coverage and quietly stops trusting the URL.
• Lost links to PDFs and images. People forget that a price sheet, a spec PDF, or an inline product image can have dozens of external links and a real position in search. /wp-content/uploads paths change during migrations more often than anyone expects. We map the assets too.
• Parameter URLs ignored. Covered above, and worth repeating because it is the one almost everyone skips.

A redirect map that creates chains, loops, and soft 404s is sometimes worse than no map, because it looks done. The boxes are checked. The damage is just harder to see.

How we test it after launch

The map is a hypothesis until you crawl the live site. So the moment the new site goes live, we crawl it again, this time feeding the full list of old URLs through Screaming Frog in list mode. Every old URL should return a single 301 to a 200 page. We sort by status code and we look hard at anything that is not a clean single hop: the 404s, the 302s that should be 301s, the chains, the loops.

Then we watch two dashboards for the following weeks.

Search Console’s page indexing report tells us when Google starts processing the redirects, when old URLs move to “page with redirect,” and whether new soft 404s or crawl errors appear. We submit the new sitemap and use the URL inspection tool on the highest-value pages to nudge recrawling. Analytics, GA4 or whatever the client runs, tells us about the traffic cliff in close to real time. A small dip on day one is normal as Google reprocesses. A cliff that keeps falling means the map has a hole, and we go back to the status-code report to find it.

We keep the redirect rules in a managed file, not scattered across a plugin UI nobody documented. On Kinsta we lean on server-level redirects where we can, because they are faster than PHP-level rules and they survive plugin changes. The map lives in version control. When the next redesign comes in three years, the new team inherits a record instead of a mystery.

The timeline reality

Here is the part clients most need to hear, because it is the part that causes panic. Even a perfect migration wobbles. Google has to recrawl the old URLs, see the 301s, follow them, and reassign the signal. That takes time, and during that window rankings flutter. A page that ranked third might bounce to seventh for a couple of weeks. Impressions get noisy. It feels like the migration failed.

If the map is right, it recovers. We usually see things settle within two to four weeks for a mid-size site, sometimes six to eight for a large one with deep history. The recovery is the proof. Rankings come back to where they were, occasionally better, because a redesign often ships faster pages and cleaner structure on top of preserved equity. We pair the migration with the usual performance work, WP Rocket and Cloudflare in front, so the new site is not just preserved but quicker, and Google notices that too.

If the map is wrong, there is no recovery. The line just stays down, and three months later someone is asking why organic traffic never came back. By then the old site is gone, the access logs may be rotated out, and reconstructing the inventory is archaeology. We have done that archaeology for clients who came to us after a bad replatform. It is doable. It is far more expensive than building the map right the first time, and you never fully recover the months of lost traffic in between.

That is the whole argument for treating the redirect map as a deliverable. It is cheap to do well and brutal to do badly, and the cost of doing it badly is invisible until it is the only thing anyone can see. We put it in the plan, we put it in the budget, and we hand it over as an artifact. If you are staring down a redesign or a replatform and nobody has mentioned the redirect map yet, that is the first question to ask. See how we have handled migrations, or tell us what you are moving.