Replatforming without losing rankings

Every migration checklist looks the same, and the checklists are mostly why migrations still go wrong. They list crawlability, canonical tags, sitemap submission, schema markup, Core Web Vitals, hreflang if the site is multilingual — a couple dozen items, each treated as roughly equally important, each with its own line in a spreadsheet someone dutifully checks off before launch. Then the site goes live, traffic falls by a third over three weeks, and nobody on the team can point to which checklist item failed, because most of them didn't.

That's the part the checklist genre gets wrong: it treats every technical detail as an equal citizen of the same list, when almost all of the damage in a replatforming project comes from three specific failures, and the rest of the checklist — while not worthless — is nowhere near as consequential as its place on the list suggests. The technical items everyone worries about going in are rarely what causes the loss. It's usually one of three quieter things: a URL that changed and never got a redirect, a paragraph that got shortened in the rewrite, or a link that used to be in the navigation and now isn't.

The inventory nobody wants to build, and the one thing that makes it fast

Before any redirect gets planned, before any new template gets approved, someone has to answer a boring question completely: what URLs does this site currently have indexed, how much traffic does each one get, and how many other sites link to it. Not the pages in the sitemap — the pages Google has actually indexed, which is frequently a longer and stranger list, including old campaign landing pages, paginated archives, and URLs from a platform migration three years ago that nobody remembers doing.

Three sources build this list reliably. Search Console's index coverage report, exported in full rather than sampled. Server log files, if you can get them, because they show which URLs are actually being crawled and visited rather than which ones you assume are. And a backlink tool, run against the whole domain, to find every URL that has an external link pointing at it — because a redirect gap on a page with twelve inbound links from other domains costs more than the same gap on a page nobody has ever linked to.

The inventory is tedious and it is also the entire foundation of a safe migration, because every subsequent decision — what gets redirected, what gets merged, what gets deliberately retired — is a decision made against this list or made blind. Teams that skip it aren't lazy so much as optimistic: they assume the new site's structure will roughly map onto the old one, and usually it does, right up until the ten percent of URLs that don't map turn out to carry forty percent of the organic traffic.

Redirects, including the pages you planned to delete

The redirect map is where most of the inventory's value gets spent, and the rule is simpler than it sounds: every URL from the inventory needs a specific, one-to-one destination on the new site, not a blanket redirect to the homepage or the nearest category page. A blanket redirect tells a search engine the old page's relevance doesn't map to anything specific on the new site, which is close to true and treated accordingly — the accumulated ranking signal for that URL mostly doesn't transfer.

The part that gets missed even by teams who take redirects seriously is the pages that were never meant to survive the migration at all. A product line got discontinued, a services page got folded into a broader one, an old blog category is being retired — the instinct is to let those URLs 404 on launch day, because keeping them feels like dragging dead weight into the new site. But a URL that a hundred people found useful enough to link to is not dead weight; it's equity, and a 404 spends it for nothing. The right move for a genuinely retired page is still a redirect, aimed at whatever page on the new site now covers that topic most closely, even if the match is imperfect. An imperfect match keeps most of the value. A 404 keeps none of it.

This is also where a redesign done for the reasons described in the redesign decision tends to create its own redirect problem: if the trigger was a content model that couldn't express what the business now sells, the new site often has a genuinely different page structure, not just a different skin on the old one. That makes one-to-one mapping harder, not optional — more of the redirect map has to be built by judgment rather than by matching old slugs to new ones, and it's worth budgeting the time for that judgment before launch rather than during the traffic drop afterward.

Content shrinkage is the quiet cause, and it's usually not intentional

Ask anyone running a migration whether they're planning to thin out the content, and they'll say no. Nobody sets out to cut. It happens anyway, almost every time, for a reason that has nothing to do with SEO strategy: a new template looks cleaner with less text in it, a writer tightening old copy for a fresh design trims what reads as padding, and a page that used to run nine hundred words of genuine explanation comes out the other side at four hundred words that say less about fewer things.

This is, by a wide margin, the most common silent cause of a ranking drop after a migration, and it's the hardest one for a team to see happening, because the new page reads better. It's tighter, more scannable, more aligned with whatever the new design system wants a page to look like. Nobody in the room experiences the rewrite as a loss. But a page that used to answer six subordinate questions a searcher might have and now answers two has measurably less reason to rank for the queries those other four questions used to catch, and the ranking data reflects that within weeks, not immediately and not dramatically enough that any one person notices it happening in real time.

The fix isn't "never cut anything" — some of what gets cut in a redesign is genuinely dead weight, outdated detail nobody needed. The fix is checking word count before and after, page by page, on anything that carried meaningful traffic, and asking a direct question about every page that shrank by more than a small margin: was this cut a deliberate editorial decision, made by someone who looked at what was being removed, or did it happen as a side effect of fitting content into a new template. The second kind is the one that causes the damage, because nobody chose it — the new design chose it for them.

The navigation simplification that quietly deletes internal links

The other habit that ships with almost every redesign is a simpler navigation, and simpler navigation is very often the right call — a mega-menu with forty links serves almost nobody well. But every link removed from a navigation, a footer or a related-content module is an internal link some page on the site was relying on, and internal links are one of the more direct signals a search engine uses to judge how important a page is relative to the rest of the site.

A page that used to be reachable from the main navigation and is now three clicks deep, findable only through a search box, has lost a real amount of the authority the site's own structure was passing to it — not because anything about the page changed, but because the site stopped telling search engines and visitors that the page mattered. This shows up constantly on resource pages, older case studies, and category pages folded into a "more" menu during a navigation simplification, and it's rarely caught before launch because nobody audits the old navigation's link count against the new one; they compare screenshots and agree the new one looks cleaner.

The check that catches this is mechanical rather than judgmental: take the full list of internal links the old site's main navigation, footer and any sitewide modules pointed to, and confirm each one still has at least one prominent internal link somewhere on the new site — not necessarily in the same place, but somewhere a normal visitor and a crawler would both find it. Pages that fall out of that list entirely are the ones worth asking about before launch, not after the ranking report comes in three weeks later.

The two weeks after launch, and where the rollback line sits

Launch day is not when the migration's outcome gets decided; it's when the clock starts on finding out. The two weeks immediately after are the window that matters most, because that's roughly how long it takes search engines to recrawl and re-evaluate a meaningfully changed site, and it's long enough for a genuine problem to show a clear trend rather than a day's noise.

The routine worth running daily in that window is unglamorous: pull organic traffic and ranking position for the highest-traffic URLs from the pre-migration inventory, compare each one against its baseline, and watch for two different shapes of decline. A broad, even dip across most pages is usually the expected, temporary cost of a platform change settling in — the same dip described in the redesign decision as the price of resetting accumulated learning, and it typically continues recovering past the two-week mark rather than finishing within it. A sharp, isolated drop on a specific page or cluster of pages, especially one that doesn't recover and doesn't match the broad pattern, is a signal something specific broke — a missed redirect, a page that lost most of its content, a link that didn't survive the new navigation.

The threshold worth setting before launch, not during a bad week, is roughly this: if a high-value page's traffic is down by half or more after ten days with no sign of stabilizing, that page gets manually diagnosed rather than left to "settle." Check whether its redirect target is correct, whether its word count and heading structure match what was live before, whether it's still linked from somewhere prominent. Most of the time the diagnosis lands on one of the three causes above. A full rollback of the whole site is rarely the right response to an isolated page problem — it undoes everything that did go right along with the one thing that didn't — but it's worth having agreed in advance what would justify one: a broad decline, across most of the site, still worsening rather than stabilizing after two weeks, with no specific fixable cause found. That combination is rare. Most migration traffic loss traces back to something on the list above and is fixable without undoing the whole project — a separate exercise from deciding whether the positioning behind the site was the actual problem in the first place, a question worth asking before the next migration rather than during this one's recovery.

What none of this changes is the general timeline for judging whether the new site is actually working, on SEO terms rather than launch-week terms — that's a longer conversation, covered separately in how long before SEO shows up in the numbers. The two-week window described here answers a narrower question: did the migration itself break something. It won't tell you whether the new site is better. It will tell you, reliably, whether you handed away rankings you didn't have to.