Key takeaways
- Week one after launch looks fine on almost every migration, including the ones that go badly. The recrawl is what tells you, and it takes weeks.
- Redirects get the attention and rendering does the damage. A client-side build can arrive late in Google and never reach AI crawlers at all, while passing every QA check you have.
- Redirect every URL that earns impressions, links or conversions. Trying to redirect all of them is how maps become unmaintainable and wrong.
- The SEO work that protects a migration happens before the URL structure is signed off, which is usually months before anyone thinks to ask.
The graph doesn't fall on launch day, and that's exactly what trips most teams up.
You migrate on a Tuesday, watch analytics all week and everything looks broadly normal, because Google hasn't reprocessed most of the site yet and is still serving what it already knows. Google's own site move guide says a medium-sized site can take a few weeks or more before the new URLs replace the old ones in results, and larger sites take longer, so a broken migration usually shows itself around week six, by which point the build team has moved on and nobody can remember which decision caused the drop. More often than not that decision was about rendering rather than redirects, and the work that would have caught it belonged months before launch.
Rendering breaks more migrations than redirects do
Redirects get all the attention because they're the visible, checkable part of the project, while rendering is the one that costs more and shows up later.
Usually a team moves off a monolithic CMS onto a modern JavaScript framework, ships the front end as a client-side app (the kind that sends the browser an empty page plus a bundle of scripts and builds the content on arrival), and QA passes because QA uses a browser, and browsers run JavaScript. Google runs it too, just not straight away, and when Vercel and the agency MERJ matched more than 37,000 crawl and render events on nextjs.org in 2024, the median render came 10 seconds after the crawl, but the 90th percentile waited around three hours and the 99th around 18, and that's on a site built by the people who make the framework.
AI crawlers don't wait at all, because they don't render. Vercel's analysis of AI crawler traffic in December 2024 found that ChatGPT's and Claude's crawlers download JavaScript files and never execute them, so anything your page builds in the browser doesn't exist for them. Google's JavaScript SEO documentation, last updated in March 2026, still recommends server-side rendering or pre-rendering because "not all bots can run JavaScript." That matters more every quarter, since your buyers build their shortlist inside Claude and ChatGPT now, well before they ever visit your homepage.
The check takes two minutes and almost nobody runs it before launch. Open the staging site, choose view source rather than inspect element (inspect shows the page after scripts have run, and view source shows what a crawler gets first), and search the raw HTML for a sentence from the middle of the page. If it isn't there, you're asking every crawler to do extra work, and some of them won't.
Run it on one page of every template type, so a product page, a blog post, a category listing and a docs page at minimum. Teams often server-render the marketing pages and leave the blog client-side, which is precisely backward for search, since the blog is usually the section meant to earn the traffic.
Redirect what earns something, and let the rest 404
The instinct on a migration is to redirect every old URL to something, which feels safe and produces maps with thousands of rows that nobody can verify.
I'd use a narrower rule. Pull the URLs that earn impressions in Search Console, the ones with referring domains and the ones with conversions, and redirect those one by one to the closest match on the new site. Everything else can 404 honestly, because a 404 on a page nobody visits costs you nothing, while pointing a dead page at the homepage is something Google's site move guide warns "might be treated as a soft 404" anyway.
Make them permanent (a 301 or 308). Google's redirects documentation says a permanent redirect makes the new URL the one it shows and treats as canonical, while a temporary one keeps the old URL in results, and its site move guide adds that permanent redirects don't lose PageRank.
The expensive mistake here is bulk-redirecting a whole directory to a single new landing page. It looks tidy in the config file, and tidy is about all it has going for it, because what it does is collapse fifty different search intents onto one URL that answers one of them.
Watch for chains as well. If the old site already had redirects in place and the new map redirects those destinations again, you've built a chain, and while Googlebot will follow up to 10 hops, Google's advice is to send every legacy URL to its final destination in one.
Content triage is the part everyone skips
A replatform is the one moment when someone will let you delete things, and most teams waste it by migrating everything.
Before the move, sort the existing content into three piles. Anything that earns impressions, links or revenue goes across as it is, with its URL preserved wherever possible. Pages that earn nothing but cover a topic you still care about get merged into fewer, better pages, with the old URLs redirecting to the survivor (the one case where Google is happy for several URLs to point at a single page), and whatever's left, earning nothing on a topic you've moved on from, stays behind.
That third pile is usually bigger than anyone expects, and cutting it helps, because a smaller site where every page has a job is easier to crawl and easier to link internally than a large one carrying eight years of abandoned posts.
Going headless? Keep your previews out of the index
A move to a headless CMS brings a few failure modes a like-for-like platform swap doesn't, and most of them live in the content model, where an SEO field nobody designed in (a canonical, a separate title tag) becomes a migration inside your migration. We write about migration from the vendor side too (our SEO content for e-Spirit reached page one for CMS migration to cloud terms), and I've put the modeling decisions in their own piece, headless CMS migration and the decisions that cost you later.
The failure that belongs here is preview environments leaking into the index. Headless builds often deploy previews on public URLs, crawlers find them, and suddenly you're competing with yourself for your own rankings. A robots.txt disallow won't fix it, because Google's robots.txt guide says plainly that it isn't a mechanism for keeping a page out of Google, so password-protect previews or send a noindex rule in the response header on every preview URL.
A timeline that matches how Google behaves after launch
Most migration checklists end at launch, which is where the part worth watching starts.
Before anyone signs off the URL structure
This is when the cheapest wins are still on the table, and it's usually months before anyone calls an SEO. Once the new sitemap is signed off, the redirect map is the only lever you have left.
Two weeks before launch
The redirect map is written and tested against the list of URLs that earn something, rendering has passed the view-source check on every template type, and the triage decisions are made.
Launch week
Submit the new sitemap, then watch server logs rather than analytics and confirm Googlebot is getting 200s and 301s instead of 404s and 500s. Traffic will look normal this week, and that tells you nothing yet.
Weeks two to eight
Problems surface here. Watch Search Console's indexing report for pages sliding into "Crawled - currently not indexed", track average position alongside clicks, and compare the indexed page count against what you expected to migrate, because a large gap usually means something isn't rendering.
Month three
If traffic hasn't come back by now, stop waiting and start diagnosing. The usual culprits, in order, are pages not rendering, redirects pointing at the wrong equivalents, and consolidation that merged pages serving different intents.
Start the redirect map this week
A migration keeps its rankings when the SEO decisions are made before anyone signs off the URL structure.
If a replatform is planned for this year, the most useful thing you can do this week is export your Search Console pages report and mark every URL that earns impressions, because that list is the backbone of the redirect map. If you'd rather not run it alone, that's what our SEO migration agency work covers, from the URL mapping and content triage before launch to the eight weeks of crawl monitoring after it, and the easiest next step is a discovery call.
Quick answers
How long should we keep the old redirects?
Google's site move guide says at least a year, which gives it time to recrawl and reassign links from other sites, and from a visitor's point of view it suggests keeping them indefinitely. Update your own internal links to the new URLs anyway, since every redirect adds a little load time.
Should we keep the same URL structure?
If there's no strong reason to change it, yes. Preserving URLs removes the single largest risk in the project for free, so change them when the old structure blocks something, not because the new platform happens to prefer a different convention.
Do we need to resubmit our sitemap?
Submit the new one in Search Console on launch day. Google says you can then remove the old sitemap, though its site move guide also describes watching the old sitemap's indexed count fall to zero as a progress check, so I'd keep it around until that happens.
Will changing domains at the same time make it worse?
It compounds the risk, because you can no longer tell whether a drop came from the platform or the domain. If both have to happen, sequence them a couple of months apart, and remember the domain move needs a Change of Address request in Search Console, which a same-domain replatform doesn't.
What about AI search and citations during a migration?
Treat pages that already get cited or send referral visits from chatgpt.com, perplexity.ai or claude.ai in your analytics as pages that earn something, and give each one its own one-to-one redirect. I'd protect those pages even when their search impressions look modest, because AI referral traffic tends to arrive well-informed and close to a decision.
We fixed the problem. How do we speed up recovery?
Recovery follows the recrawl of the pages you fixed, so run your top earners through Search Console's URL Inspection tool, check the rendered HTML shows the content, and request indexing. For everything else, a fresh sitemap with accurate lastmod dates on the fixed pages is the nudge.
Who should own the redirect map?
Someone who can read Search Console, not whoever has capacity in the final sprint. The map is a set of judgment calls about which old page best matches which new one, and that's an editorial decision as much as a technical one.
