Migrating off WordPress without losing rankings — what the handoff looks like

The fear that a WordPress migration will tank organic rankings is legitimate — it has happened to plenty of businesses. It just doesn’t have to. The businesses where it happened skipped specific, identifiable work. The businesses where it didn’t, did the work.

This is what the work actually looks like.

Why migrations sometimes destroy rankings

The mechanics are straightforward. Search engines have indexed your URLs. Each URL has accumulated some amount of authority — backlinks, internal links, ranking history. When the URL changes and there’s no redirect, the search engine sees the old URL as a 404 and the new URL as a brand-new page with no history.

Five things cause ranking loss during migrations:

1. Missing 301 redirects from old URLs. The most common cause and the biggest one.
2. URL slug changes without redirects. Often deliberate (“the old slugs were ugly”) and almost always damaging.
3. Lost or broken metadata. Title tags, meta descriptions, and structured data that didn’t carry over.
4. Internal link breakage. Old URLs referenced from other content that now point to dead pages.
5. Indexability changes. A robots.txt or noindex directive that accidentally got carried over from staging.

All five are preventable. The reason they happen is that they’re often handled as cleanup work after the rebuild instead of as core work during it.

The four work products that protect rankings

A migration that protects organic traffic produces four artifacts. If a vendor can’t show you these, the rebuild isn’t migration-grade.

One — the URL inventory

Every URL the existing site has ever served, captured from three sources:

• A complete crawl of the live site
• Google Search Console’s coverage report (every URL Google has indexed)
• Backlink data from any reputable SEO tool

Combined, this list is usually 1.5 to 3x larger than what a single-source crawl reveals. The “missing” URLs are the ones that ranked for something three years ago, still earn occasional traffic, and would otherwise quietly disappear.

Two — the URL map

For each old URL, a decision: one-to-one new URL, consolidation into a related page, or intentional retirement. Documented as a single spreadsheet or a single script — not as decisions made ad-hoc during the rebuild.

The map is reviewed before any new URL gets locked in, because the constraints flow in both directions: some new URLs need to match old ones to preserve equity, and some old URL groups should consolidate to strengthen the new structure.

Three — the content audit

The migration is the right moment to fix what’s been wrong about the content for years. The audit identifies:

• The pages that drive the most organic value (treat carefully, strengthen, don’t break)
• The pages that drive nothing and clutter the site architecture (cut)
• The pages that should exist but don’t (build during the rebuild, not after)

This is where the actual SEO upside of a migration usually comes from. The redirect plan protects what you have; the content audit is what improves it.

Four — the launch verification checklist

On launch day:

• Every old URL returns a 301 to its new home (verified by automated check, not eyeballing)
• The XML sitemap is rebuilt and submitted to Search Console
• Internal links throughout the new site point to new URLs, not redirected ones
• Robots.txt allows indexing (the staging directive is gone)
• Schema and metadata render correctly on a representative sample of pages

For the first thirty days after launch, daily monitoring of Search Console and weekly ranking checks for the top 50 keywords. Most of what’s going to happen happens in those thirty days.

What the timeline actually looks like

A migration done well takes eight to ten weeks. Where the time goes:

• Weeks 1–2 — Inventory, audit, URL mapping, content strategy
• Weeks 3–6 — Build (new site, new content, new structure)
• Week 7 — Staging review, redirect implementation, verification dry-run
• Week 8 — Launch with same-day verification
• Weeks 9–12 — Monitoring, adjustment, post-launch SEO work

Compressing below six weeks is where corners get cut. The corners are usually the audit and the redirect mapping — both invisible until traffic starts dropping.

What “tended after launch” actually means in this context

The launch is not the endpoint. For the first ninety days after migration, the site needs:

• Daily Search Console monitoring for the first week
• Weekly ranking checks for top organic terms
• Crawl error response (anything that breaks gets fixed before the search engine decides the page is gone)
• 301 chain cleanup (any redirect that ended up two hops gets compressed to one)
• Internal link audits as new content publishes

This is ongoing work, not project work. It’s why the rebuild-and-walk-away model breaks down for serious migrations: the launch is the first quarter of the work, not the last.

What to do if rankings drop anyway

Some ranking volatility is normal in the first two weeks — search engines re-crawl, re-evaluate, and re-rank. A 10–15% wobble that recovers within three weeks is normal and not a problem.

A sustained 25%+ drop after three weeks is a real problem and almost always traces to one of the five causes above. The diagnostic is fast: the URL inventory, the redirect map, and a fresh crawl of the new site against the old list usually reveal exactly what got missed.

This is the diagnostic and recovery work we’d run for any business in that situation. The fix is rarely complicated; it’s usually a redirect that didn’t fire, a metadata field that didn’t carry over, or a robots directive that got left in place.

The bottom line

Migrations off WordPress don’t have to be the unbounded risk they’re sometimes treated as. The risk is bounded by the practices, and the practices are knowable. Done correctly, the migration is the moment the site stops being a maintenance burden and starts being a business asset that compounds — without losing what it’s already earned.