DEV Community

Daniel Mercer
Daniel Mercer

Posted on

We rebuilt 27,854 pages and lost 81% of our traffic — a redirect postmortem

Last month we rebuilt My Fast Movers — an independent moving-cost calculator with 27,854 city-to-city route pages — and migrated every route URL to a cleaner structure. Old URLs 301-redirected to new ones. Textbook migration. Then our Search Console impressions fell 81.7% in a week.
Here's the honest postmortem.

What we did

Old URL pattern: /states/<state>/<city>/moving-from-X-to-Y/
New URL pattern: /popular-routes/<city>-to-<city>/
Every old URL got a 301 to its new counterpart. No 404s. Sitemap updated and resubmitted (63,063 pages discovered). We expected a brief dip, then recovery.

What actually happened

Google dropped the old URLs from the index fast — within days — but has been slow to index and rank the new ones. Two weeks post-migration: 9,049 pages indexed, 54,692 not indexed. The top reasons: "Crawled – currently not indexed" (38,712) and "Discovered – currently not indexed" (13,531). Our best route pages — the ones driving all the impressions — went from ranking to invisible while their replacements sat in the crawl queue.

What we'd do differently

1. Don't migrate all URLs at once. We moved 27,854 pages in one deploy. A staged rollout — 10% of routes first, watching indexation — would have contained the damage.
2. Treat "redirects are in place" as the start, not the end. A 301 preserves link equity in theory. In practice, Google still has to recrawl, re-evaluate, and re-rank every new URL. For a site with tens of thousands of pages, that queue is long.
3. Internal linking matters more than we thought. Our new pages launched with thinner internal link graphs than the old ones had accumulated over years. We're now deliberately rebuilding internal links to priority routes.
4. Watch the sitemap fetch status. Two of our sub-sitemaps showed "Couldn't fetch" in Search Console while returning HTTP 200 externally — a Googlebot fetch-reliability issue that slowed discovery of exactly the pages we needed indexed.

Where we are now

Redirects holding, no 404s, steadily requesting indexing on priority routes, and building fresh backlinks to the new URLs to speed up re-evaluation. Traffic hasn't recovered yet — I'm writing this mid-recovery, not after it.
The lesson I'm taking: URL migrations on large sites aren't a redirect problem, they're an indexation-queue problem. Plan for the queue, not just the redirects.


I work on My Fast Movers, a moving-cost calculator and route directory. If you've survived a large-scale URL migration, I'd love to hear how long your recovery took.

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.