If you launch a replatform without redirects in place, expect a real drop in organic traffic that takes months, not days, to recover. The short version: every old URL that returns a 404 gets dropped from Google's index over the following weeks, every backlink pointing at those URLs stops passing value, and rebuilding that lost trust is far slower than losing it. "We'll fix redirects after launch" is not a scheduling decision. It's a decision to pay six months of interest on a five-day job.
Let me tell you why I'm so twitchy about this one.
You moved house and forgot the post office
Imagine you move to a new place. New street, new door, better kitchen. You are thrilled. And in the excitement you forget one boring little errand: filing the change-of-address form.
For the first week, nothing seems wrong. Then the mail carrier starts arriving at your old house, finding a stranger, and shrugging. Your bank statement gets stamped "return to sender." The birthday card from your aunt bounces. The magazine you actually like just... stops. Nobody announced any of this. There was no error message. The letters simply went to a place that no longer knows you, and after enough bounces, the senders quietly gave up and crossed you out of their address book.
That is exactly what a missing redirect does. The old URL is your old address. Google's crawler is the mail carrier. Every link on the internet pointing at you is somebody with your old address written down. And a 301 redirect is the change-of-address form that says, in a language machines actually respect, "I still live here, I just moved to this door instead."
Skip the form, and the mail bounces.
Why the delay compounds instead of waiting patiently
Here's the part that makes "we'll do it next sprint" so expensive: the damage is not paused while you get around to it. It accrues.
When an old URL starts returning a 404 (or a soft 404, which is arguably worse because it pretends to be fine), Google doesn't drop it instantly. It comes back, checks again, and over a few weeks decides the page is genuinely gone and removes it from the index. The link equity those pages were holding — the accumulated votes from every site that ever linked to you — stops flowing to your new pages, because the new pages either don't exist at that address or aren't connected to the old ones. A 301 passes that value along. A 404 pours it down the drain.
And recovery is not symmetric. Losing an indexed page takes a couple of weeks of neglect. Getting it re-crawled, re-evaluated, and re-ranked at the new URL takes far longer, because Google recrawls different pages at wildly different rates. Your homepage might get visited daily. That three-year-old resource page that quietly ranks for a money keyword? Google might not swing by for weeks. Google's own guidance on site moves says to expect a few weeks to a few months for a change of addresses to fully process even when you do everything right. When you do it wrong first and fix it later, you restart that clock.
So the timeline of "fix it after launch" really looks like this:
| Moment | Redirects done at cutover | Redirects deferred "until we have time" |
|---|---|---|
| Launch week | Old URLs pass straight to new ones | Old URLs 404; crawler starts finding dead ends |
| Weeks 2–6 | Google reprocesses the move, rankings hold | Dead pages drop from the index, rankings slide |
| You finally ship redirects | n/a | Recovery clock starts here, not at launch |
| Following months | Traffic stable | Slow re-crawl, re-index, and re-ranking of everything you lost |
The cruel bit is that the deferral doesn't just delay recovery by the length of the delay. It adds the decay window plus the recovery window. Two months of "we'll get to it" can easily cost six months of traffic before you're whole again.
What the fix actually requires (and why teams flinch)
People don't defer redirects because they're lazy. They defer because the mapping is genuinely annoying, and it always surfaces at the worst moment: the week before go-live, when everyone is already on fire. You need a complete inventory of every live URL on the old site, matched to its destination on the new one, with the many-to-one and the retired pages and the trailing-slash weirdness all accounted for.
That's a job for a crawl, not a spreadsheet you fill in from memory. Pull every indexable URL, cross-reference it against analytics and Search Console so you know which pages actually earn traffic and links, and flag the orphans that have no obvious new home. Do that before cutover, not after, so the map ships with the launch instead of chasing it. This is exactly the kind of pre-migration inventory Replatform Radar builds — every page scored so you know what has to redirect, what can quietly die, and what will hurt if you miss it.
The good news: most of the value hides in a small slice of URLs. Your top few hundred pages by traffic and inbound links usually carry the vast majority of what you'd lose. Get those mapped perfectly and covered by clean, one-hop 301s, and you've defused most of the bomb. The long tail matters, but the money is in the head.
So, what do I actually think?
Redirects are not a post-launch chore, and treating them like one is the single most common self-inflicted wound I see in a replatform. If I were running the migration, redirects would be a release blocker — the site does not go live until the map is loaded and spot-checked. No exceptions, no "we'll batch it Thursday." I would rather delay a launch by three days than spend three quarters clawing back rankings I handed away for free.
File the change-of-address form before you move. Otherwise the whole internet keeps knocking on a door that isn't yours anymore, and eventually it stops knocking.