Migrating off WordPress without losing your rankings

A platform migration is one of the few moments in a website's life where a genuinely well-executed technical project can still tank organic traffic if a handful of specific details get missed. We treat migrations as their own discipline, separate from the redesign work happening alongside them.

We export a full crawl of the existing site's URLs, including ones with any recorded organic traffic or backlinks, before development starts. Every one of those URLs needs a mapped destination on the new site, and every mapping needs a corresponding redirect at launch. This mapping document is arguably the single most important deliverable of the entire migration.

Permanent 301 redirects pass the overwhelming majority of a page's accumulated ranking signal to its new destination; temporary 302 redirects don't reliably pass the same signal and can leave Google treating the old and new URLs as separate. And redirecting every old URL to the homepage instead of its actual new equivalent, a common shortcut under time pressure, forfeits page-specific ranking signal that took months or years to build.

A redirect to a page with substantially different or thinner content than the original doesn't fully preserve ranking value, even with a correct 301 in place. We check that migrated pages retain the core content and keyword targeting of their predecessor, not just an equivalent URL slot in the new site structure.

We submit the new XML sitemap to Search Console immediately at launch and check the coverage report daily for the first two weeks, looking specifically for a spike in 404s or unexpected "crawled, not indexed" pages, which usually points to a redirect gap or a content issue we can still fix quickly before it compounds.

We avoid launching a migration right before a client's known high-traffic season, a retail client's holiday period, a B2B client's typical quarter-end close, specifically because the temporary fluctuation a migration can cause is a much bigger risk during peak demand than during a quieter stretch of the year.

Even a well-executed migration typically sees a small, temporary ranking fluctuation as Google reprocesses the new URL structure, usually recovering within two to four weeks. What's not normal is a sustained drop past that window, which almost always traces back to a specific missed redirect or a content gap rather than an inherent migration penalty, since no such blanket penalty actually exists.

We build and test the full migration, including the actual redirect map, on a staging environment that's as close to the real launch conditions as possible, rather than testing individual pieces in isolation and assuming they'll work together correctly on launch day. Redirect logic in particular tends to surface edge cases, trailing slashes, query parameters, case sensitivity, only when tested as a complete system rather than a handful of spot checks.

This staging pass has caught real problems before they reached production more than once, a redirect rule that worked correctly for the majority of URLs but silently failed on a specific pattern used by an older section of the site that nobody remembered to test individually. Finding that kind of gap in staging costs an afternoon of debugging; finding it after launch costs actual ranking and traffic while the fix gets identified and deployed.

When possible, we separate a content or messaging overhaul from the underlying platform migration into two distinct phases, since combining both makes it much harder to diagnose which change caused a ranking shift if one occurs. Migrating the existing content as-is onto the new platform first, then revising content in a second phase once the platform migration has stabilized, isolates the variables and makes any problem far easier to trace back to its actual cause.

WordPress stores a surprising amount of SEO-relevant data in places that aren't always obvious during an export, custom meta fields used by SEO plugins, category and tag structures that affect URL patterns, alt text stored separately from image files. We do a specific audit of what an SEO plugin like Yoast or RankMath has been managing before migration, since some of that data doesn't export cleanly by default and needs to be manually mapped to its equivalent on the new platform.

Many WordPress SEO plugins auto-generate structured data, review stars, article schema, breadcrumb markup, without a site owner ever needing to think about it directly, which means that structured data quietly disappears on migration unless someone explicitly rebuilds the equivalent on the new platform. We check Search Console's rich results report before and after migration specifically to confirm structured data eligibility didn't silently drop.

This is one of the more common gaps we find when auditing a migration someone else ran, since the site's visible pages look correct and the redirects pass a spot check, but a specific piece of markup that used to earn a rich snippet in search results, a star rating, a FAQ dropdown, has quietly vanished because nobody accounted for the plugin that used to generate it automatically. The visible ranking impact of losing a rich snippet is real but easy to miss without specifically checking for it.

We keep the old WordPress installation running on a private staging URL for at least a month after launch, rather than deleting it immediately, specifically so we have a reference to check against if a specific piece of content or metadata needs to be recovered after the fact. This costs almost nothing to maintain and has saved real time more than once when a post-launch discrepancy needed tracing back to its original source.