Anatomy of a Replatform That Wiped 60% off Organic Traffic

The fortnight after a bad launch, in order

This is a composite, not a client. We don't publish anyone's numbers without permission, and the specific site doesn't matter anyway — migration failures repeat with the same handful of causes, in roughly the same order, on WordPress and Shopify and Webflow and whatever headless build your CTO is excited about.

What's worth knowing is the sequence, because the sequence is why these get escalated ten days too late. Nothing looks wrong on launch day. Google hasn't been round yet.

1. Day 0 — launch. New URLs go live, traffic looks normal, and the migration gets marked done in the project tracker.
2. Days 1–4 — the crawl arrives. Googlebot re-crawls your most-crawled URLs first: homepage, main templates, anything with recent links. Those get re-evaluated within hours. The long tail can take weeks, which is why the damage arrives in instalments.
3. Days 4–10 — rankings slide before traffic does. Average position drifts on pages whose URL changed or whose word count halved. Search Console shows this before Analytics does, because impressions move before sessions.
4. Days 10–21 — the floor. Organic traffic bottoms out. This is normally when someone senior finally asks the question, about ten days after the data would have answered it.
5. Weeks 4–6 — leads follow. Organic leads lag organic traffic by roughly the length of your sales cycle. A B2B company often doesn't feel a June migration until August, and then blames August.

Decision one — the redirect map built from the sitemap alone

This is the most expensive mistake in the list, and it gets made the same way every single time. Someone exports the XML sitemap, maps those URLs to their new equivalents, ticks the box.

The sitemap is a list of pages you wanted indexed. It is not a list of URLs that have backlinks, rankings, impressions or traffic. Those four lists overlap with the sitemap and none of them is contained by it. An old site that's been through two previous redesigns will have hundreds of URLs earning links that nobody has looked at since 2019.

Decision two — the copy got shorter because the design wanted it shorter

Redesigns are run by designers, and designers are right about nearly everything except word count. The new hero is genuinely beautiful. It has room for eleven words. The old page had 1,400 words that happened to answer nine different questions, and eight of those questions no longer appear anywhere on the site.

Here's the mechanic that makes this invisible. A page ranks for far more queries than the one it was built for. Most established pages earn the bulk of their impressions from long-tail variants nobody on the team has ever tracked — the paragraph mentioning GST, the sentence about schools, the aside about Pune. Delete the paragraph and you delete the match. Rank tracking doesn't flag it because those queries were never in the rank tracker.

The fix isn't "keep it long". Word count doesn't rank; coverage does, and length is only a crude proxy for how many questions a page answers. So diff the coverage.

• Export top queries per URL from Search Console for every template you're redesigning.
• For each query above a threshold you set — 50 impressions a month is a reasonable line — confirm the new copy still contains a passage that answers it.
• Where it doesn't, either restore the passage or accept the loss in writing, so that nobody spends November investigating a decision made in August.

Decision three — the new template quietly removed your internal links

Old templates accumulate links the way a garage accumulates cable. Breadcrumbs, related-posts blocks, sidebar category lists, footer link farms somebody added in 2021, and years of in-body links added by whoever was writing that month. A clean new template has a nav, a footer with six items and a lot of whitespace.

That whitespace is where your internal link graph used to live. It isn't unusual for a page to go from thirty-odd internal links to under ten, sitewide, in one deployment.

Four things break at once, and none of them shows up as an error in any tool: crawl paths to deep pages, anchor-text signals, the distribution of link equity across the site, and the topical relationships that told Google your cluster pages belonged together. Internal linking does more work than most link building, which is exactly why removing it costs so much.

1. Crawl the old site and the staging site. Export inlink count per URL from both.
2. Diff them. Any URL whose internal inlinks fall to zero is an orphan, and orphans get dropped from the index over time regardless of how good they are.
3. Diff crawl depth as well. A page that sat two clicks from the homepage and now sits five will be crawled less often and re-evaluated more slowly.
4. Check in-body links specifically. Moving from a rich-text CMS field to a headless build very often sanitises the HTML, and anchors go out with the sanitiser. The words survive; the links don't.

Decision four — robots.txt, noindex, or the staging site itself

Four variants of the same class of error. They cause the most dramatic damage and the least durable damage, which is why they sit fourth rather than first — they're usually caught inside a week, and a week is survivable. Each one is checkable in about ninety seconds, and the reason they ship is that nobody was assigned those ninety seconds.

• The staging `robots.txt` ships to production. Disallow: / deployed with the rest of the build. Traffic goes to near-zero on a schedule set by Google's re-crawl rate.
• A global `noindex` inherited from staging config. Worse than the robots.txt version, because robots.txt merely stops crawling while a noindex actively removes pages already in the index. It can also arrive as an X-Robots-Tag HTTP header, where nobody thinks to look because it isn't in the HTML.
• Canonicals hardcoded to the staging hostname. Every page on your live site now tells Google the real version lives on a domain Google can't reach. Quietly catastrophic and very easy to miss on view-source unless you're specifically checking the hostname.
• Staging itself gets indexed. No auth, no noindex, a stray link from a Jira ticket, and now a full duplicate of your site is competing with production. The fix is HTTP auth, not robots.txt — a disallowed URL can still be indexed if something links to it.

The four ranked by damage, and by how long they take to undo

Ordering matters here because it's almost exactly the inverse of how much panic each one causes in the room.

The pre-launch checklist that would have caught all four

None of this is clever. All of it is boring, and the boring items are the ones that get dropped when the launch date slips and the scope doesn't.

1. Crawl the old site and save the export. Before a single URL changes. URLs, titles, H1s, word counts, inlink counts, crawl depth, status codes. You cannot diff what you never recorded, and this is the most-skipped item on the list.
2. Build the redirect map from five sources. Sitemap, crawl, 16 months of Search Console, 24 months of analytics, full backlink export. Deduplicate and map to closest equivalents.
3. Test every redirect against staging automatically. Feed the old URL list to the staging host and assert two things: a 301, and a 200 at the destination in a single hop. Chains work, but every extra hop slows consolidation and gives someone a chance to break it later.
4. Run the query-coverage diff per template. Top Search Console queries per URL, checked against the new copy.
5. Diff internal inlinks and crawl depth per URL. Any URL falling to zero inlinks is a launch blocker, not a post-launch ticket, and nothing commercially important should move past three clicks from the homepage.
6. Audit robots.txt, meta robots, `X-Robots-Tag`, canonicals and hreflang on staging, with the production hostname substituted. Hardcoded staging hostnames are the single commonest cause of the fourth category.
7. Put staging behind HTTP auth on day one of the build. Not on the day before launch, when you'd have to find the pages already indexed.
8. Set up analytics and Search Console before launch, not after. New property if the domain changes, tags verified on every new template, and — the important part — your trailing-90-day organic sessions, conversions and leads exported and frozen.
9. Pick a launch window that isn't your peak season and isn't a Friday. Search doesn't care, but the humans who have to fix things at 9pm do.

What recovery actually looks like, and where it stops

If all four fixes ship inside the first fortnight, most sites are back to pre-launch organic traffic in roughly eight to sixteen weeks. The range is wide because it's mostly a function of how often Google crawls you, and that varies enormously between a news site and a 40-page B2B brochure.

If the redirect map is still incomplete at month two, the honest forecast is "some of it, eventually". URLs whose backlinks you never mapped aren't recoverable by redirect, because you don't know they exist.

1. Weeks 1–2 after the fix. Google re-crawls your most important URLs first. Impressions move before sessions, so watch Search Console rather than Analytics.
2. Weeks 3–6. Money pages reconsolidate as redirects are processed and the new URLs inherit the old ones' signals. Submit fresh sitemaps and run URL Inspection on your top 30 URLs to hurry the first pass. Beyond thirty, it's patience.
3. Weeks 6–12. The long tail returns last, because those URLs are crawled least often. This is the stage where people give up early and start rewriting pages that were about to recover on their own.
4. Months 3–4. Leads follow traffic, offset by your sales cycle.

Why the hour before launch is the most expensive hour in SEO

We handle site migration work inside a normal retainer — SEO runs from ₹75,000/mo, or ₹40,000/mo for smaller sites, ex-GST, month-to-month after the first quarter. We're not raising the price here to make a point about it.

We're raising it because a migration is the one piece of SEO where the entire return is decided before launch and can't be bought back afterwards at any price. Thin content, you can rewrite. Slow pages, you can speed up. A missing link, you can go and earn. A backlink pointing at a URL you never redirected is simply gone, and the person who linked to you five years ago is not going to update it because you replatformed.

On engagements generally we guarantee movement against your own frozen trailing-90-day organic lead count — miss it in 90 days and we keep working free until we beat it. We never promise a specific ranking position for a specific keyword, because nobody controls Google's index. Around a migration that frozen number does double duty: it's the guarantee, and it's the only honest way to answer "how bad was it, really" three months later, once everyone's memory has quietly improved.

If you're mid-build right now and you only do one thing after reading this, do the dull one. Crawl the old site and save the file. It costs an afternoon, it costs nothing to store, and it's the difference between a post-mortem and a shrug. And if traffic has already gone, start by working out whether it was actually the migration before you spend a quarter fixing something that wasn't broken.