Migrating a WordPress site — to a new host, a new domain, or a completely rebuilt platform — is one of the few moments where months or years of accumulated SEO rankings can be lost in a single afternoon, not because search engines are punishing you, but because they can no longer find what they used to know. The good news is that ranking loss during a migration is almost always preventable. It happens because of missed redirects and broken URL structures, not because Google penalizes sites for moving. Get the mapping right and rankings typically transfer with minimal disruption.
Why migrations tank rankings when they go wrong
Search engines rank URLs, not domains and not "sites" in the abstract. Every page that currently ranks does so because Google has crawled that specific URL, evaluated its content, and built up trust signals — including inbound links, both external and internal — pointing at that specific address. When a migration changes the URL structure, moves to a new domain, or restructures permalinks without telling search engines where the content went, Google doesn't automatically know that the old URL and the new URL represent the same page. Without an explicit signal connecting them, it treats the new URL as new, unranked content, and the accumulated authority of the old URL simply doesn't transfer. A 301 redirect is that explicit signal. Missing it — even for a fraction of your URLs — is the single most common cause of post-migration ranking loss.
Before you touch anything: build a complete inventory
You cannot redirect what you haven't accounted for, so the first step happens well before any technical migration work starts.
- Crawl the current site to generate a complete list of every live URL — not just pages linked from the navigation, but old blog posts, tag and category archives, paginated listings, and anything still indexed even if it's no longer linked internally.
- Export the current XML sitemap as a second, cross-referencing source of URLs, since a sitemap and a crawl don't always agree — a crawl finds what's actually linked, while a sitemap reflects what the site claims exists.
- Pull your top-performing URLs from search data (Search Console and analytics) specifically, so you know which pages carry the most ranking value and get extra scrutiny during testing. A typo in a redirect for your highest-traffic page is a much bigger problem than the same typo on a page nobody visits.
- Note current rankings and traffic levels for your important pages before migration, so you have a real baseline to compare against afterward instead of relying on impression.
Map every URL that's going to change
Once you have the full inventory, build an explicit map: old URL to new URL, for every single one. This is tedious and there is no way around the tedium — it's also the part of the project that determines whether the migration is a non-event or a traffic disaster. For a straightforward host migration where permalinks aren't changing, most URLs won't need mapping at all beyond confirming they resolve identically post-move. For a domain change, a platform rebuild, or a permalink structure change, every single URL needs an entry.
Pay particular attention to:
- Pages that are being consolidated or removed — these need to redirect to the closest genuinely relevant replacement, not just the homepage. A blanket redirect-everything-to-the-homepage approach is a well-documented way to lose most of the SEO value you were trying to preserve, since it signals to Google that the destination content has no real relationship to what used to be there.
- Category and tag archive URLs, which are easy to forget because they're not "content" in the way a blog post is, but they're indexed and often rank.
- Paginated URLs (page/2/, page/3/, and so on) which multiply fast on any site with a lot of content and are easy to miss in a manual audit.
- Query-string variations that might be indexed separately, particularly on WooCommerce sites with filtered or sorted category views.
Preserve the permalink structure wherever you can
The single easiest way to avoid needing thousands of redirect rules is to not change the URL structure in the first place. If the migration is about hosting, design, or the underlying platform, and doesn't require a new permalink structure, keep the existing one. Every URL you don't have to change is one less redirect to write, test, and maintain, and one less opportunity for something to fall through the mapping process. Structural URL changes should be a deliberate decision made for a real reason, not a side effect of a redesign that didn't need to touch it.
Implement 301 redirects — and only 301s
A 301 redirect tells search engines and browsers that a page has permanently moved, and it's what passes ranking signals from the old URL to the new one. A 302 (temporary redirect) does not reliably pass that same signal, because it tells search engines the move might not be permanent — so search engines are right to hold off on transferring authority until they've seen enough evidence otherwise. For a permanent migration, every redirect in your map should be a 301, implemented server-side (via your web server config or a well-tested redirect plugin) rather than relying on JavaScript-based redirects, which crawlers handle less reliably and which add a delay for real visitors.
Redirect chains — URL A redirecting to URL B, which itself redirects to URL C — should be flattened so A points directly to C. Chains add latency for every visitor who follows them and add unnecessary risk that a search engine crawler gives up partway through, especially across long chains.
Update internal links, don't just rely on redirects
Redirects are a safety net, not a substitute for correct internal linking. If your navigation menu, in-content links, and related-posts modules still point at old URLs after migration, every one of those clicks costs an extra redirect hop, adds latency, and depends on a redirect rule staying in place indefinitely. Go through the site's internal links — menus, widgets, in-content hyperlinks, hardcoded links inside page builder content — and update them to point directly at the new URLs. This also matters for a healthy internal linking structure generally: search engines use internal links to understand which pages you consider important, and a site full of stale internal redirects sends a weaker version of that signal than direct links do.
Test thoroughly on staging before DNS cutover
The migration should be fully built and verified on a staging environment before it ever goes live, and before DNS changes point real traffic anywhere near it. Use that staging window to check that redirects resolve correctly, that the site's robots.txt isn't accidentally blocking crawlers on the new setup (a shockingly common mistake — staging environments are often deliberately blocked from indexing, and that block sometimes ships to production by accident), that canonical tags point at the correct URLs, and that core functionality — forms, checkout, search — all still works. If the migration involves a full rebuild rather than a simple host move, this is also the natural point to run through a performance pass, since you're already touching everything and a migration is the cheapest time to fix problems you've been meaning to address anyway.
Go live, then immediately resubmit your sitemap
Once DNS has cut over and the new site is confirmed live and stable, submit the updated XML sitemap in Search Console for the property, and if the domain changed, use Search Console's change of address tool to formally notify Google of the move. This doesn't guarantee instant re-crawling, but it gives search engines the clearest possible signal about what changed and speeds up how quickly they process the new structure instead of discovering it gradually through normal crawl cycles.
Monitor closely in the weeks after migration
The work isn't done at go-live. For at least the first few weeks, watch for:
- A spike in 404 errors in Search Console's coverage report, which usually points to a gap in your redirect map — a URL pattern you missed during the inventory phase.
- Ranking drops on specific pages rather than the whole site, which often points to a redirect that's technically working but pointing at a less relevant replacement page than the original.
- Crawl stats and indexing status, to confirm Google is actively re-crawling the new URLs rather than stalling out.
- Core Web Vitals and site speed on the new setup, since a migration to a different host or platform can quietly change performance in either direction, and performance is itself a ranking factor.
A short-term dip immediately after migration is common even when everything is done correctly, since search engines need time to re-crawl and re-evaluate the new URLs. What you're watching for is a dip that doesn't recover within a few weeks, or one concentrated on pages that should have redirected cleanly — both are signals that something in the mapping needs fixing, not signals to panic and undo the whole migration.
Migrations done carefully, with a full URL inventory and a properly tested redirect map, are routine. It's the migrations done in a rush — a domain switch over a weekend with "we'll fix broken links if anyone reports them" as the plan — that turn into visible traffic losses. If you're planning a migration alongside other site work, it's also worth pairing it with a look at what ongoing maintenance should cover afterward, since a freshly migrated site is exactly the kind of site worth keeping a close eye on for the first few months. Our team handles WordPress migrations as part of our broader development and maintenance work if you'd rather have this checklist executed for you.
