How to Migrate Your WordPress Site Without Losing Your Google Rankings

You’ve decided it’s time for a new website. New theme, modern design, better user experience. Your developer is ready, the design looks great, and you’re excited to launch.

Then someone asks: “What about your Google rankings?”

It’s a fair question. For many small businesses, organic search traffic is the lifeblood of new customer enquiries. A botched migration can see rankings drop for months. In the worst cases, sites never fully recover.

The good news: migrations don’t have to hurt your SEO. With the right preparation, you can switch themes, restructure URLs, and go live with a completely new site while protecting — sometimes even improving — your search rankings.

This post walks through the exact process we follow when handling WordPress migrations for clients. It’s based on real work, real numbers, and lessons learned from managing sites that had accrued years of SEO equity before a redesign.

Why WordPress Migrations Go Wrong for SEO

Before we get into the checklist, it helps to understand the three main ways a migration can damage your rankings.

1. URL Changes Without Redirects

Every URL on your site is a unique asset. Over time, those URLs accumulate backlinks, social shares, and search engine trust. When you change a URL structure — say, renaming /blog/our-services to /services/ — and don’t set up a redirect, that equity vanishes. Google sees the old URL as a 404 error and eventually removes it from the index. Any links pointing to that URL become dead ends.

This is the single most common cause of post-migration ranking drops.

2. Metadata Not Migrated

Your SEO titles, meta descriptions, and focus keywords live in your SEO plugin’s database tables, not in the post content itself. When you switch themes or rebuild a site, that data doesn’t automatically come with it. We’ve audited migrated sites where every single page had a blank meta description and a generic template title — the new site was effectively invisible to search engines.

3. Redirect Chains and Loops

Sites that have been running for several years tend to accumulate redirect chains: redirects that point to other redirects, which sometimes point to yet another redirect. A → B → C is a chain. Each hop bleeds link equity and adds latency. Some chains are even longer.

When you migrate and add new redirects on top of old ones, chains get worse. We’ve seen five-hop redirect chains on otherwise well-maintained sites.

Phase 1: Baseline Crawl — Before You Touch Anything

The most important step in any migration is one most people skip: thoroughly documenting the current site before changing anything.

Run a full crawl with Screaming Frog (free up to 500 URLs, paid for larger sites). Export:

• All URLs with status codes (200, 301, 302, 404)
• All existing redirects and their destination
• All page titles and meta descriptions
• Internal link counts per page
• Any existing redirect chains

This export becomes your reference document. Every decision during the migration gets checked against it. After launch, you run the same crawl again and compare — it’s your before/after proof.

Why this matters: On a recent client project, the baseline crawl revealed something unexpected. The live site had been cleaned up from a historical peak of over 13,000 URLs down to 620 active pages — a 95% reduction. Without that baseline, we would have had no idea how much old link equity was potentially floating around on dead URLs, and which of those needed redirects to protect.

Phase 2: URL Decision Matrix

For every URL on your current site, you need to make one of three decisions:

Decision	When to use it	HTTP Response
Keep	URL stays the same in the new site	200 (no action needed)
Redirect	URL changes but content still exists	301 (permanent redirect)
Gone	Content is being removed deliberately	410 (gone)

The 410 status code is underused. Most people either leave deleted pages as 404s or redirect everything to the homepage. A 410 tells Google: this page is intentionally gone, stop crawling it. It’s faster for Google to process and stops crawl budget being wasted on dead ends.

Build a spreadsheet with three columns: Old URL, New URL, Action. Work through your entire URL inventory. This redirect map becomes the implementation document.

From our experience: On one migration we mapped over 50 redirects across review pages, promotional pages, and legacy blog posts. Roughly 60% were 301 redirects to the correct new URL, 30% were 410 (gone — no equivalent content), and 10% were keeping the same URL unchanged. Getting this right before development starts saves hours of firefighting after launch.

Phase 3: Set Up Staging Correctly

If your new site is being built on a staging environment (it should be), there are two non-negotiable requirements from an SEO perspective.

Block staging from being indexed

Every staging environment must return a noindex header for every page. If Google crawls your staging site — which it will try to do — it can register duplicate content against your live domain before you’ve even launched.

The standard approach is X-Robots-Tag: noindex, nofollow at the server level (Nginx or Apache), which applies globally regardless of the CMS settings. Don’t rely on a checkbox in WordPress settings — it’s too easy to accidentally untick.

Protect it with HTTP Basic Auth

Add password protection to the staging environment. It keeps bots out, prevents competitors from seeing work in progress, and acts as a second layer of protection against accidental indexing.

Once both are in place, you can build, test, and iterate without any risk to your live site’s SEO.

Phase 4: Fix Internal 404s on Staging Before Cutover

When you rebuild a site — especially if you’re importing content from an older version — you’ll almost certainly have internal 404 errors. These are links within your own content pointing to pages that don’t exist on the new site.

Don’t go live with these. Internal 404s mean:

• Users hit dead ends during navigation
• PageRank doesn’t flow to those linked pages
• Google interprets them as a quality signal against your site

The process for finding them is simple: run a Screaming Frog crawl of your staging site (authenticated if it’s password-protected) and filter for 4xx response codes. For each 404, trace back to the source page, find the broken link, and either fix it or remove it.

From our experience: A recent pre-launch audit found 94 internal 404 errors on a staging site. Left unfixed, that would have been a significant problem on day one. We systematically worked through each one — some needed a redirect added, some needed a link updated in the content itself, and a few needed a draft post published that should have been live. The crawl after fixing those showed zero internal 404s.

Phase 5: Audit and Flatten Redirect Chains

This step is often overlooked but it makes a meaningful SEO difference.

A redirect chain is when URL A redirects to URL B, which redirects to URL C. Each additional hop has two costs:

• Link equity loss: Each redirect step passes less of the original page’s authority forward. The first hop is close to 100%, but chains compound.
• Load time: Every extra redirect adds a network round-trip. For mobile users on slower connections, this is measurable.

To find chains: in Screaming Frog, enable “Always Follow Redirects” in settings, then crawl. Any URL showing as a redirect that has another redirect as its destination is a chain.

To fix chains: update the original redirect to point directly to the final destination. /old → /interim → /final becomes /old → /final. One hop. Done.

From our experience: On the same project, the staging audit revealed 149 internal redirects to review. Several were chains from an older URL structure. Flattening those chains before cutover meant the new site launched with clean, single-hop redirects throughout.

Phase 6: Migrate Your Metadata

Your SEO metadata — titles, descriptions, keyphrases — needs to travel with the content.

If you’re using Yoast SEO on both sides, the export/import process is straightforward: Yoast has a built-in export tool that produces a CSV you can import to the new installation. If you’re switching SEO plugins, you’ll need to map fields manually.

What to export and verify:

• SEO title — the tag in search results, not the page title
• Meta description — the snippet under your link in Google
• Focus keyword / keyphrase — Yoast-specific, but useful for reference
• Canonical URLs — if you have any explicitly set
• noindex settings on specific pages — privacy policy, thank-you pages, etc.

After import, spot-check 20–30 pages by inspecting the page source or using a browser extension like Detailed. Look for the <title> tag and <meta name="description"> tag. If they’re blank or showing template placeholders, the import didn’t work correctly.

The cost of skipping this: We audited a site post-migration where the agency had done a beautiful visual redesign but imported zero SEO metadata. Every page’s title was the site name alone. Every description was blank. The site’s click-through rate in Google dropped sharply because every single search result snippet looked generic. It took weeks to manually rebuild the metadata.

Phase 7: Implement Your Redirects in the New Site

With your redirect map built in Phase 2, now it’s time to implement. There are a few approaches.

Option A: Nginx configuration (recommended for performance)

If you have server access, implement redirects at the Nginx level. They execute before WordPress processes the request — faster and zero PHP overhead. For Trellis-based WordPress sites, this means editing your Nginx includes configuration and reprovisioning.

location = /old-page-url/ {
    return 301 https://example.com/new-page-url/;
}

Option B: WordPress Redirection plugin

For non-technical users or smaller redirect sets, the free Redirection plugin works well. It manages redirects from the WordPress admin and logs 404 hits so you can catch redirects you missed.

Option C: Yoast Premium or .htaccess

Yoast Premium has redirect management built in. Apache servers can use .htaccess. These are fine for smaller sites but can become unwieldy with large redirect sets.

Whichever method you use, test every redirect before going live. A simple way: open your redirect map CSV and spot-check 10–15 random entries using curl -I or a browser extension like Redirect Path. Verify the response code is 301 (not 302) and the destination is the right page.

Phase 8: Pre-Launch Checklist

Before you flip the DNS, work through this list.

SEO

• noindex confirmed OFF on new live environment (check response headers)
• Staging still has noindex (you’ll leave staging up temporarily)
• SEO plugin active and configured
• XML sitemap generates correctly
• Canonical URLs set to HTTPS (not auto-detect)
• Metadata imported and verified on 20+ pages

Redirects

• All redirects from Phase 2 are implemented
• No redirect chains (all single-hop)
• No redirect loops
• 410s set for intentionally removed content

Content

• Zero internal 404 errors (verified by Screaming Frog crawl)
• Internal links updated to new URL structure where needed
• Images loading correctly (check for hardcoded dev/staging URLs)

Technical

• HTTPS working with valid SSL certificate
• www and non-www both redirect to canonical version
• robots.txt is correct and not blocking important content
• No dev/staging URLs hardcoded in content (search the database)

Specifically on that last point: If your staging environment ran on a .test or .staging domain, WordPress pattern files may have baked those URLs into post content in the database when patterns were inserted. Run a database search-replace before launch to catch any http://yoursite.test references that would appear as broken images on the live site.

Phase 9: The Day of Cutover

Keep this window short and controlled.

1. Run a final Screaming Frog crawl of staging — confirm zero 404s, zero redirect chains
2. Take a full database backup of the old live site
3. Update DNS to point to the new server
4. Wait for DNS propagation (check with dig or a DNS checker tool)
5. Immediately verify the site is loading correctly over HTTPS
6. Check 5–10 critical pages manually in a browser
7. Verify noindex is NOT present on the new live site (use curl -I and look for X-Robots-Tag)
8. Submit the updated sitemap to Google Search Console

The most common cutover mistake: forgetting to turn off the noindex that was protecting the staging environment. Your entire site will be live but invisible to Google until that’s fixed. Set a reminder to check this first.

Phase 10: Post-Launch Monitoring

Expect some turbulence in the first 2–3 weeks. This is normal. Google re-crawls the site, reprocesses redirects, and re-evaluates content. Rankings for individual pages may fluctuate before settling.

Google Search Console — daily for first 2 weeks

• Coverage report: watch for a spike in 404 errors
• Any new 404s after launch are redirects you missed — add them immediately
• Impressions and clicks: should be broadly similar to pre-launch baseline

Screaming Frog — 7 days post-launch

• Full crawl of the new live site
• Compare to baseline: every page that existed before should either be returning 200 (same URL) or receiving a redirect from its old URL
• Any page returning 404 that was returning 200 before is a missed redirect

Rankings — weekly for first month

• Spot-check your top 10–20 target keywords
• A single position fluctuation is noise; a consistent multi-position drop on a specific page may indicate a technical issue with that page’s redirect or metadata

What’s a red flag vs normal: A temporary shuffle of 1–3 positions on individual pages is completely normal. A page that was ranking position 4 dropping to page 2 altogether, combined with a 404 for that URL in GSC, is a missed redirect that needs fixing immediately.

How Long Does SEO Recovery Take?

For a well-executed migration — where every URL is either preserved or redirected correctly, metadata is migrated, and technical checks pass — most sites see minimal disruption. There may be a 1–2 week ranking shuffle while Google processes the changes, but positions generally return to baseline or better.

For migrations done without these steps, recovery typically takes 3–6 months — and some rankings never fully recover if the backlinks pointing to old URLs were never redirected.

The difference between those two outcomes is almost entirely preparation. The actual cutover is a small part of the process. The weeks of audit, mapping, and testing before cutover are what determine the result.

Summary: The Migration SEO Checklist

Phase	Action	When
1	Baseline crawl of current live site	Before development starts
2	Build URL decision matrix (keep / 301 / 410)	Before development starts
3	Set up staging with noindex + Basic Auth	Day 1 of build
4	Fix all internal 404s on staging	Before cutover
5	Audit and flatten redirect chains	Before cutover
6	Migrate SEO metadata (titles, descriptions)	Before cutover
7	Implement redirect map	Before cutover
8	Pre-launch checklist (noindex off, sitemap, HTTPS)	Day of cutover
9	Post-launch: submit sitemap, verify live	Day of cutover
10	Monitor GSC and crawl for 2–4 weeks	Post-launch

Thinking About a WordPress Redesign?

If you’re planning a theme migration or full site rebuild, we can handle the entire SEO side of the process — from baseline audit through to post-launch monitoring. A migration done right protects the rankings you’ve spent years building.

Get in touch to discuss your project