How to Migrate a WordPress Site Without Losing SEO Rankings

Crawl and back up everything before you touch anything

Before any file gets moved or any theme gets switched, crawl the live site (Screaming Frog, Sitebulb, or even a simple sitemap export) and save a full list of every indexed URL, its title tag, and its current ranking snapshot from Search Console. This is your source of truth for step two — you can't build accurate redirects from memory.

Build a full 301 redirect map — not ad hoc redirects

The single most common migration mistake is redirecting page-by-page as issues get reported after launch, instead of mapping every old URL to its new equivalent before going live. A redirect map is a spreadsheet: old URL, new URL, nothing else. Every URL from your crawl needs a row, even ones you think "probably don't matter" — a stray backlink or an old bookmark pointing at a URL with no redirect is a lost visitor and a lost signal.

Watch specifically for redirect chains (A → B → C instead of A → C directly) — they slow crawling and dilute link equity slightly with each hop. Update the map to point directly at the final destination.

Stage it properly — with noindex, not a password wall

Build and test the new site on a staging subdomain with a site-wide noindex meta tag (or an X-Robots-Tag header), not a password prompt that also blocks Google's crawler from seeing anything at all — you want Google to be able to fetch the staging site to make sure nothing 500s, without it getting indexed. Remove the noindex the moment you cut over, and check immediately that it's actually gone (a noindex tag left behind after launch is a classic self-inflicted wound).

Preserve canonical tags and hreflang if the site is multilingual

If the old site had canonical tags or hreflang alternates, the new site needs to emit exactly the same relationships, not just visually similar pages. A common failure: the migration changes URL structure for one language but not another, breaking the hreflang pairing silently — Google won't error loudly, it'll just quietly stop trusting the annotations.

Cut over with DNS TTL lowered in advance

Lower your DNS TTL (e.g. to 300 seconds) at least 24–48 hours before the actual cutover, so that when you do switch nameservers or the A record, the change propagates fast instead of leaving some visitors (and crawlers) on the old server for hours. Raise the TTL back to normal once you've confirmed the cutover is stable.

Resubmit the sitemap and watch Search Console closely for two weeks

Submit the new sitemap.xml in Search Console the same day you launch — don't wait for Google to notice organically. Then watch the Coverage report daily for the first two weeks: a spike in 404s means your redirect map missed URLs; a spike in "Discovered – not indexed" can mean the new site is serving thin or duplicate content Google didn't see before. Both are fixable quickly if caught early, and much harder to unwind after rankings have already dropped.

The mistakes that actually cause ranking drops

• Changing URL slugs "for tidiness" with no real SEO reason, breaking every existing backlink and bookmark to that page.
• Migrating image files to new paths without redirects, silently killing image-search traffic.
• Forgetting internal links still point at old URLs — a redirect chain that's technically fine, but adds latency and dilutes signal across the whole site if left unfixed.
• Launching with a robots.txt still blocking the new site (a leftover from staging) — this alone can deindex a site within days.

Our take

None of this is exotic — it's a checklist, not a dark art. The sites that lose rankings during a migration almost always skipped the redirect map or launched a staging setup that blocked Google entirely. Do those two properly and the rest is mostly diligence.

Planning a WordPress migration and want a second set of eyes on the redirect map before you cut over? Get in touch.