What Happens to Your SEO When You Migrate Off WordPress?

What Happens to Your SEO When You Migrate Off WordPress?

The most common fear that keeps businesses on WordPress isn't love of the platform — it's fear of losing rankings in the move. It's a reasonable fear with an encouraging answer: Google doesn't rank WordPress sites, it ranks URLs with content and signals attached. Preserve those, and rankings follow you. Break them, and no platform will save you. Here's exactly what happens to your SEO when you migrate off WordPress, separated into what transfers, what's at risk, and what usually improves.

Table of Contents
  1. What Google Actually Cares About (Hint: Not Your CMS)
  2. The Risk, Quantified
  3. Where Migrations Actually Lose Rankings
  4. What Usually Improves
  5. The Realistic Timeline
  6. How to Come Out Ahead

What Google Actually Cares About (Hint: Not Your CMS)

Search engines see rendered HTML over HTTP. They have no ranking preference for how it was produced — WordPress, headless CMS, or hand-written files. What they do care about survives or dies in the migration mechanics:

  • URLs — the address where each piece of ranking equity lives
  • Content — titles, headings, body text, and internal link structure
  • Metadata — title tags, meta descriptions, canonicals, structured data
  • Backlinks — which point at URLs, not at platforms
  • Performance — Core Web Vitals, which are a ranking signal and usually the migration's big win

The Risk, Quantified

Industry studies of site migrations put the stakes plainly: poorly handled migrations commonly lose 20–60% of organic traffic within days, and botched launches can take over a year to recover. Well-executed migrations, by contrast, typically see a temporary dip of 5–15% and recover fully within one to three months. The difference between those outcomes is not luck — it's almost entirely the redirect map and the pre-launch checks.

Tablet showing a web analytics dashboard with traffic graphs beside a coffee cup
The first two weeks after launch are monitoring weeks, not vacation weeks. Source: Pexels
Read also:

Where Migrations Actually Lose Rankings

  • Missing or lazy redirects. Every old URL needs a one-to-one 301 to its new equivalent. Redirecting everything to the homepage doesn't transfer equity — Google treats those as soft 404s. The mechanics are covered in our WordPress redirect guide.
  • Lost metadata. Yoast/Rank Math titles and descriptions live in the database, not in the standard export. Losing them resets years of click-through optimization — see how to export SEO data properly.
  • Changed content structure. Rebuilt pages that drop heading hierarchy, thin out body copy, or lose internal links change what the page ranks for. Migrate first, redesign second — or accept that you're doing two risky things at once.
  • Accidental noindex. The classic: staging robots settings shipped to production. It happens to professionals. Crawl the live site on launch day.

What Usually Improves

Migrations off WordPress tend to gain on the signals WordPress struggles with. Pre-rendered pages routinely cut Largest Contentful Paint from 3–5 seconds to under 1.5 — and Core Web Vitals are a ranking signal, particularly on competitive mobile queries. Cleaner HTML without page-builder wrapper markup also tends to improve how reliably structured data and content get parsed. Teams that migrate carefully often end up ahead of their baseline within a quarter — the dip is a trade for a faster foundation.

The Realistic Timeline

  • Days 1–14: Google recrawls, discovers redirects, and begins swapping old URLs for new ones in the index. Impressions wobble. This is normal.
  • Weeks 2–8: Rankings consolidate on the new URLs. A 5–15% traffic dip during this window is within the expected band for a clean migration.
  • Months 2–3: Full recovery for well-executed moves; performance gains start showing in Core Web Vitals field data.
  • Month 12: Keep redirects live at least this long — Google's own guidance — so slow-recrawled URLs and backlink equity finish transferring.

How to Come Out Ahead

Benchmark before you move, map every URL, carry your metadata, launch with redirects tested, and watch Search Console daily for two weeks. That's the whole defensive game, and it's all laid out step by step in the WordPress migration checklist and the deeper technical SEO checklist for CMS migrations. If you want the failure patterns spelled out, read how to avoid losing SEO rankings during a CMS migration before you schedule the launch date.

Share

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

TL;DR — A custom session-cookie login flow appeared to succeed on localhost (the OTP verified, the response looked fine) but every subsequent request to a login-gated page treated the visitor as logged out. Identical code worked fine on the live HTTPS site. The cookie's Secure attribute was hardcoded to true — and per the cookie spec, browsers never store or send a Secure cookie over a plain, non-HTTPS connection.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Fix
  4. Lessons learned

Diagnostic

Check the actual Set-Cookie response header and the browser's own cookie storage panel — on localhost over http://, the cookie is sent by the server but never actually stored by the browser.

Root cause

// before -- assumes the app is always served over HTTPS
setCookie("session", token, { secure: true, httpOnly: true });
emdashkits.com

A cookie config that quietly assumes "we're always on HTTPS" breaks the instant you test over plain HTTP, which local dev servers commonly are.

Read also:

Fix

// after -- derive secure from the actual request protocol
const isHttps = request.url.startsWith("https://");
setCookie("session", token, { secure: isHttps, httpOnly: true });
emdashkits.com

Lessons learned

  • Any Secure-flagged cookie needs to key off the real request scheme, not an assumption baked in once at cookie-creation time.
  • "Works in production, silently fails in local dev" is a strong signal to check cookie flags before anything else in an auth flow.
  • Check other cookies in the same codebase for the same hardcoded assumption — if one cookie has this bug, sibling cookies set the same way are worth auditing too.
Share
Previous Article

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Comments

Write a comment

Related Articles

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

July 16, 2026

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

Google Analytics (GA4) Not Tracking Anything and No Console Errors: Check Your CSP First

TL;DR — GA4's gtag.js snippet was installed correctly, the page loaded with no visible JavaScript error, and GA4's real-time report still showed zero activity. The CMS's default Content-Security-Policy had no allowance for analytics domains and no config option to add one — so every request to Google's tracking endpoints was blocked at the browser level before it could fail loudly.

Table of Contents
  1. Diagnostic
  2. Root cause
  3. Lessons learned

Diagnostic

Check the browser's dedicated CSP violation reporting, not the regular console error list — CSP blocks are reported through their own channel, not thrown as normal script errors, so "no console errors" doesn't mean nothing was blocked.

Root cause

The CSP's script-src and connect-src directives had no entry for googletagmanager.com or google-analytics.com, and the CMS exposed no configuration surface to add one — the only way in was patching the CSP directives directly.

// patch-package: add analytics domains to the existing CSP directives
scriptSrc.push("https://www.googletagmanager.com");
connectSrc.push("https://www.google-analytics.com", "https://www.googletagmanager.com");
emdashkits.com
Read also:

Lessons learned

  • "No console errors" is not proof nothing was blocked — CSP violations live in their own reporting surface and are easy to miss if you're only scanning for red error text.
  • Before adding any third-party script tag to a site with a CSP already in place, check the CSP's directives first rather than assuming a silently-empty analytics dashboard means a snippet-installation mistake.
Share
Previous Article

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Next Article

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Comments

Write a comment

Related Articles

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

July 16, 2026

Login Works in Production but Fails on localhost: The secure Cookie Flag Gotcha

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

July 16, 2026

Native Module Build Fails on Shared Hosting (node-gyp, Old glibc/Python): The .npmrc Fix

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)

July 16, 2026

Uploaded Images Disappear After Every Deploy on Shared Hosting (and Other Reverse-Proxy Gotchas)