How to Migrate Off WordPress Without Losing Your Rankings

Sites do not lose rankings because they left WordPress. They lose rankings because URLs changed without redirects, content was thinned during migration, or pages got slower. Each of those is preventable. This is the phase-by-phase plan we use to move a site to a modern stack while holding organic performance.

A caveat worth stating first: if WordPress is working for you and the only complaint is aesthetic, a redesign on the existing platform is cheaper and lower risk. Replatforming is justified when you need application logic WordPress fights you on, authenticated accounts, complex payments, custom operational workflows, or when plugin sprawl has become a security and performance liability. Where the need is a faster, better-structured site rather than new logic, a rebuild on a modern stack is the narrower and cheaper project.

Justification

When replatforming is justified

• You need application logic. Accounts, permissions, multi-step workflows, and payment orchestration are things WordPress can be made to do and rarely does comfortably at scale.
• Plugin sprawl is a liability. Thirty plugins is thirty update streams, thirty potential vulnerabilities, and a performance floor you cannot get below.
• Performance has plateaued. When you have already done caching, image optimisation, and hosting upgrades and the site is still slow, the architecture is the constraint.
• Editorial workflow is fighting you. Multi-role publishing, structured content, and content reuse across channels are structural needs a page-based CMS handles awkwardly.

If none of these apply, invest in speed, content, and design on the platform you have.

Phase 1

A complete URL inventory

This is the phase that determines whether the migration succeeds, and the one most often shortened. A sitemap is not an inventory. It lists what the CMS knows about, not what the internet has linked to and search engines have indexed. Build the list from three sources and combine them:

1. A full crawl of the existing site, following every internal link, including paginated archives, tag and category pages, attachment pages, and feeds.
2. Search Console, every URL that has received an impression in the last sixteen months, exported and deduplicated.
3. Server logs and analytics, every path that has received real traffic or a crawler visit in the last twelve months.

The union of those three is your true inventory. It will be substantially larger than you expect, and the surplus is where old ranking pages hide, the post from four years ago that still earns links, the PDF someone cited, the landing page from a campaign nobody remembers.

Phase 2

Baseline everything before you touch anything

You cannot diagnose a drop without a pre-migration record. Capture and store, with dates:

• Organic sessions and conversions by landing page, for the last twelve months.
• Rankings for your top 100 queries, with the URL currently ranking for each.
• Impressions and average position by query and page from Search Console.
• Core Web Vitals for your ten most important templates, mobile and desktop.
• Total indexed page count.
• Your backlink profile, specifically which pages hold the strongest external links.

That last point deserves emphasis. The pages holding your best backlinks are the ones whose URLs you should be most reluctant to change, and whose redirects you should verify individually rather than in bulk.

Phase 3

The redirect map

Keep every URL you can. The best redirect is the one you did not need. Where the new architecture makes a change unavoidable, follow four rules:

1. Map one to one. Every old URL points to the single most equivalent new page. Bulk-redirecting a category of old pages to the homepage tells search engines those pages no longer exist in any meaningful sense, and the rankings go with them.
2. Use permanent redirects. A 301 (or 308) passes signals. A 302 tells search engines the move is temporary and that the old URL should be retained.
3. Never chain. Old URL to final URL in one hop. Chains dilute signals and slow crawling; a chain through a legacy redirect layer is a common and avoidable mistake.
4. Handle the boring cases. Trailing slashes, uppercase paths, http to https, www versus non-www, query-string variants, and old feed and attachment paths. These are individually trivial and collectively responsible for a large share of migration losses.

Test the map before launch. Run the entire inventory against the staging environment and assert that every URL returns a single permanent redirect to a page that returns 200. Automate it; a spot check of twenty URLs will miss what matters.

Phase 4

Content and metadata parity

The second most common cause of post-migration drops is unintentional content thinning. A redesign with a cleaner aesthetic frequently drops sections, shortens copy, and removes internal links, and each of those was doing work.

For every page that earns organic traffic, verify after migration: the main content is equal or longer, headings retain their structure and keywords, title and meta description carry over or improve, image alt text survives, internal links pointing to that page still exist, structured data is present and valid, and canonical tags point where they should.

Pay particular attention to internal links. A new design with a simplified footer and a slimmer sidebar can quietly remove thousands of internal links, changing how authority flows through the site. If your old footer linked to forty pages and the new one links to eight, that is a substantive SEO change, not a design decision.

Phase 5

Technical parity and speed

• robots.txt, carried over deliberately, and verified not to block anything it should not. A staging robots file reaching production is the classic catastrophic migration error.
• Noindex tags, audit every page. Staging environments are typically noindexed wholesale, and that directive must not travel.
• XML sitemaps, regenerated, accurate, and submitted at launch.
• Structured data: Article, Breadcrumb, FAQ, Product, and Organisation schema present and validating.
• Core Web Vitals, equal or better on every important template. A modern stack should win here comfortably; if it does not, something is wrong.
• Analytics, tracking verified on every template before launch, not after. Losing measurement during the riskiest fortnight of the project is avoidable and painful.

Phase 6

Launch sequence

1. Final crawl of the old site. This is your last chance to capture anything the inventory missed.
2. Deploy, with redirects live from the first second. There must be no window in which old URLs return 404.
3. Immediately crawl the new site and re-run the full redirect assertion against production.
4. Submit the new sitemap in Search Console and request indexing for your twenty most valuable pages.
5. Verify analytics is recording on every template.
6. Check the live 404 log hourly for the first day, daily for the first fortnight. Every 404 with traffic is a missing redirect you can still add.

Launch on a Tuesday morning, never a Friday afternoon. You want your full team available for the first 48 hours, which is when almost every fixable problem surfaces.

Phase 7

The first six weeks

Expect a modest fluctuation for two to four weeks as search engines recrawl and re-evaluate. Watch four things weekly: indexed page count, impressions by query, average position for your top queries, and 404 volume. Compare against your baseline rather than against last week, so you are measuring the migration rather than seasonality.

Resist making large changes during this window. Recrawling takes time, and layering new variables onto an unsettled site makes any subsequent diagnosis much harder.

Recovery

Diagnosing a drop

If traffic is materially down after six weeks, work through this in order, the causes are ranked by how often they turn out to be responsible.

In our experience the answer is in the first two rows far more often than in the last one. Migration drops are usually mechanical, and mechanical problems are fixable.

$100 for a one-hour session, billed at $25 per 15 minutes with a one-hour minimum. You choose your time on Calendly immediately after checkout. Pay by card or M-Pesa.

FAQ

Frequently asked questions

Will migrating off WordPress hurt my SEO?

Only if the migration is done badly. Rankings are lost through changed URLs without redirects, thinned content, lost internal links, slower pages, or missing metadata, not through changing platform. A migration that preserves URLs, redirects every changed path permanently, and keeps content depth intact typically holds rankings and often improves them.

How long does it take to recover rankings after a site migration?

With a clean migration, expect a small fluctuation for two to four weeks as search engines recrawl, then stability. If traffic is still materially down after six weeks, something is wrong and should be diagnosed rather than waited out, the most common causes are redirect gaps and unintentionally noindexed pages.

Should I redesign and replatform at the same time?

It is more efficient but harder to diagnose. If traffic drops after a combined project you cannot easily tell whether the cause was the platform, the URLs, or the content. If your organic traffic is commercially important, migrate first on the existing design, confirm stability, then redesign.

What is the single most common cause of traffic loss in a migration?

Missing or incorrect redirects, usually because the old URL inventory was taken from a sitemap rather than from server logs and analytics, so pages that were ranking but not linked internally were never mapped.