Skip to content
Services / Agency8 weeksDigital MarketingWeb Development

Local SEO Recovery After a WordPress-to-Next.js Migration

38 of 40 priority keywords recovered to page one inside 60 days after a full technical migration rebuild.

Client
Digital agency, Ranchi (anonymised)
Industry
Services / Agency
Timeline
8 weeks
Services
2 lines

The challenge

A Ranchi-based agency had migrated from WordPress to Next.js without URL mapping or structured data migration. Within 60 days they lost the entire page-one ranking for their city-level keywords and organic leads dropped to near zero.

Our approach

  • Full URL recovery via Wayback Machine and Search Console 16-month history.
  • 301 redirect map covering 140 old URLs with exact-match or best-fit new destinations.
  • Organization, LocalBusiness and Service schema rebuilt from scratch to match pre-migration coverage.
  • Search Console submission, inspection and accelerated reindexing of priority URLs.
  • Content refresh on money pages with updated dateModified signals.

The outcome

  • 38 of 40 priority keywords back on page one within 60 days.
  • Organic traffic recovered to 108% of pre-migration levels in 90 days.
  • Ranchi local-pack presence restored for 5 key service queries.
  • Inbound lead flow stabilised at 12–18 qualified enquiries / month.

What went wrong

  • The migration shipped without a URL map. 75 of 85 old WordPress URLs returned 404 rather than redirecting, so every backlink and every indexed ranking pointed at a dead end.
  • Structured data was not carried across. Organization, LocalBusiness and Service schema existed on the WordPress site and simply did not exist on the new one for several months.
  • The site had also been compromised in 2021-22 and served casino and dating spam from dated archive URLs. Those pages were still indexed at migration time, so the new site inherited a polluted index alongside the broken redirects.
  • Nobody was watching Search Console daily during the cutover. The 404 spike was visible from week one and was not acted on until rankings had already gone.

What we tried that did not work

  • Requesting indexing on individual URLs in Search Console. It nudges queue position and nothing more; it does not override a quality or crawl-demand judgement, and the daily quota makes it useless at scale.
  • Adding content to thin pages before fixing the redirects. Crawl demand was the binding constraint, not word count, so the new content went uncrawled.
  • Submitting a larger sitemap. A sitemap full of weak URLs gets the whole batch deprioritised — pruning it worked better than expanding it.

What we would do differently

  • Recover the real URL list before guessing. The Wayback CDX index returned the actual historical paths; an earlier redirect map built from plausible-sounding guesses (/about-us, /portfolio, /our-team) pointed at URLs that had never existed.
  • Serve 410 Gone, not 404, for spam URLs that are never coming back. 404 signals temporary absence and Googlebot requeues it; 410 forces it out of the crawl queue.
  • Never 301-redirect spam URLs into a real page. That pipes the spam association forward into the destination.
  • Fix lastmod before anything else. Build-time timestamps on every URL tell Google the whole site changed on every deploy, which trains it to ignore the field — and since the sitemap ping endpoint was retired, lastmod is the only crawl-scheduling signal left.
  • Prune before you publish. Removing thin pages lifted crawl demand for the pages that mattered more than any amount of new content did.

Technology stack

Next.jsJSON-LDGoogle Search ConsoleAhrefsScreaming Frog