If you launch a replatform without redirects in place, every old URL that ever earned a ranking or a backlink starts returning a 404, and the crawlers that fed you traffic quietly walk away. Google has to rediscover the new URLs on its own schedule (which is measured in weeks, not minutes), and the link equity pointing at your old addresses sits stranded with nowhere to go. Recovery, once you finally ship the map, commonly runs three to six months. So the honest answer to "can we do redirects after launch?" is: you can, and you will pay for it in the one currency you cannot back-order, which is time.
You moved house and forgot to tell the post office
Picture it. You've packed up the whole site, hired the movers, painted the new place, and on go-live morning you're standing in the new hallway feeling great. Every box is where it should be. The only thing you skipped was the little form at the post office that forwards your mail to the new address.
For a few days nobody notices. Then the mail keeps arriving at the old house. Your paycheck. The wedding invite. The letter from the person who wanted to send you more letters. All of it thumping onto the doormat of a place you no longer live, and the new tenant (a 404 page, in this metaphor) just shrugs and lets it pile up.
That mail is your traffic. Every link on the internet that points at an old URL, every bookmark, every entry in Google's index that took years to earn, is a letter addressed to the old house. A redirect is the forwarding form. Skip it and none of that mail finds you.
What actually happens in those first weeks
Here's the part that makes "we'll fix it after launch" feel so reasonable and be so wrong. The damage is invisible for about a week, because Google's index still remembers your old URLs and keeps sending people to them. Then it crawls, hits the 404s, and starts dropping those pages. Rankings you built over years come off the board in days.
Meanwhile the new URLs are strangers. Google finds them at its own pace by following your sitemap and internal links, and a big site does not get recrawled overnight. So you're losing the old and slowly earning the new, and the gap between those two curves is the hole your traffic falls into.
A proper 301 collapses that gap. Google has been clear that a 301 passes ranking signals through to the target, and has retired the old folklore about redirects bleeding off a fixed percentage of PageRank. The forwarding address works. But only if you filed it before the mail started arriving at an empty house.
The cost, laid out plainly
Below is roughly what the two approaches look like on a mid-sized site with a few thousand ranked URLs. The numbers aren't a physics constant (your mileage depends on site size, authority, and crawl budget), but the shape is consistent across the migrations I've watched.
| Redirects live at cutover | Redirects added 4 weeks later | |
|---|---|---|
| Old URLs returning 404 | Near zero | Thousands, for weeks |
| Link equity preserved | Most of it | Whatever survives the recrawl |
| Visible traffic dip | Small, days | Steep, then a slow climb |
| Time to recover baseline | Usually under a month | Three to six months |
| AI answer engines re-citing you | Fast, links stay valid | Delayed until pages are re-fetched |
That last row matters more every quarter. Answer engines cite specific URLs. When those URLs 404, you don't just lose a blue link, you lose the citation, and the model doesn't come back to check whether you moved until it re-crawls. You've been un-invited from the answer.
Why teams keep making this bet
Nobody defers redirects because they're reckless. They defer them because the redirect map is genuinely tedious to build, it always seems to slip behind the visible launch work, and there's a comforting sentence available: "we'll clean it up next sprint." The problem is that the launch date is fixed and the crawler doesn't grant extensions. The map is the one piece of migration work whose value expires the instant you go live.
The other quiet failure is the half-done map. Redirecting your top hundred pages and pointing everything else at the homepage feels like diligence. Google reads a redirect to an irrelevant page as a soft 404 and treats it about as kindly as a real one, so those pages still fall out. Redirect chains (old URL to interim URL to final URL) leak the same way. The forwarding form has to send each letter to the right new address, not to a pile in the lobby.
This is exactly the inventory work worth doing before the trucks arrive: every live URL, its status, its inbound links, and the exact destination it should map to. Crawling the old site and scoring each page for redirect risk is the whole point of a pre-migration pass, and it's a lot cheaper than a two-quarter traffic recovery.
So what would I actually do?
I'd treat the redirect map as a launch blocker, full stop. Same status as "the login page works" or "checkout takes money." If the map isn't built, tested against the old URL list, and staged behind the same deploy as the new site, the site does not go live. Not next sprint. That day.
Is that strict? Yes. But I've never once heard a team say they regretted having the forwarding address ready. I've heard plenty say they spent Q1 explaining to leadership why the traffic graph looked like a cliff.
File the form before you move. The new tenant at your old address is not going to save your mail.