WordPress Migration SEO: Complete Guide to Moving Your Site Without Losing Rankings

A WordPress migration done well preserves rankings — and often improves them. Done badly, it can erase years of SEO work in a matter of days. This guide walks through every type of WordPress migration through an SEO lens, with the WordPress‑specific plugins, settings, and pitfalls that most generic migration guides miss. It's written for site owners, in‑house marketers, and developers who care about organic traffic — not just getting the site moved.

In this guide: the six types of WordPress migration ranked by SEO risk, a pre‑migration audit checklist, how to choose between plugin/manual/expert migration, a step‑by‑step execution sequence, post‑launch SEO checks, a monitoring framework, common WordPress‑specific mistakes, a printable summary, and FAQs.

For a platform‑agnostic master checklist used across CMSes (Shopify, custom builds, headless), see our Website Migration Checklist. If your site has already migrated and traffic has dropped, our Traffic Drop After Migration guide covers diagnosis and recovery in detail.

What Is a WordPress SEO Migration (and Why It's Risky)?

A website migration is any significant change to how a site is structured, accessed, or delivered — new domain, new URLs, new design, new platform, or new server. A WordPress‑specific migration applies that to a WordPress site: moving hosts, changing domains, switching from HTTP to HTTPS, altering permalinks, or rebuilding on a new theme or page builder.

From an SEO perspective, a migration is less about "copying files" and more about how search engines experience the changes. Google sees a migration as a set of new URLs and altered signals that must be recrawled, re‑evaluated, and re‑ranked. If old URLs don't correctly point to new ones, search engines treat them as separate pages, not as a continuation of the same authority.

That's where the risk comes in. Common SEO problems during WordPress migrations include:

• Loss of link equity when old URLs aren't 301‑redirected to their new equivalents.
• 404 errors from content or URL changes that send users and crawlers to dead ends.
• Indexing issues when robots.txt, noindex tags, or staging settings accidentally block important content.
• Broken page builder content when builders like Elementor, Divi, or WPBakery hardcode URLs into post meta — a uniquely WordPress problem covered later.

A rebrand from oldbrand.com to newbrand.com without a complete redirect map can wipe top‑ranking blog posts from search overnight. A simple host change with identical URLs is usually low‑risk, as long as the site stays crawlable and stable. Not all migrations carry the same SEO danger — understanding the difference is crucial before making any move.

Types of WordPress Migrations and Their SEO Risk

Most WordPress moves fall into one of six patterns. Each carries its own risk profile and recovery timeline.

Host‑to‑host (same domain). Moving between hosting providers while keeping the same domain and URLs is low SEO risk. Done cleanly, rankings stabilise within days to two weeks. Main concerns: downtime during DNS changes and performance regressions on a slower new server.

HTTP → HTTPS. Typically low to medium risk. Every URL technically changes, but it's a well‑understood upgrade. With correct 301 redirects and updated internal links, signals consolidate within 2–6 weeks. Watch for mixed content (insecure images or scripts) and incomplete redirect coverage that splits link equity between protocols.

Subdomain ↔ subfolder. Moving content between blog.example.com and example.com/blog is medium risk, with 1–3 month recovery. Google often treats subdomains as semi‑separate sites with their own authority, while subfolders are tightly tied to the root domain. Incomplete redirects mean losing accumulated authority; the move also changes how that content contributes to the main site's topical focus.

URL/permalink structure changes. Switching from date‑based to post‑name URLs (or similar) is medium to high risk — every affected URL changes and must be redirected. Recovery: 1–3 months. Main concerns are redirect chains that waste crawl budget and orphaned URLs that lose history.

Domain name change / rebrand. High risk, even with identical content and structure. Trust, links, and history must transfer to the new domain — typically 2–6 months for most queries, longer for competitive terms. Critical: full one‑to‑one 301s from every old URL to its exact new counterpart, plus consistent use of the new domain in internal links, canonicals, and sitemaps.

Full redesign / rebuild. A complete overhaul changing theme, layout, navigation, and often content/IA is the highest risk, especially when combined with URL or domain changes. Recovery: 3–6+ months. Biggest concerns: removed or rewritten content that previously ranked, altered internal linking, and template changes that affect headings and structured data. Cross‑platform rebuilds amplify these risks.

Pre‑Migration SEO Checklist (Before You Touch Anything)

1. Take and verify full backups

Back up all WordPress files (core, themes, plugins, uploads, wp-config.php, .htaccess) and the entire database — using your host's tools, a reputable plugin (UpdraftPlus, BlogVault, Solid Backups), or manual SFTP + database export. Then test the restore to a staging or local environment. An untested backup is not a backup.

2. Set up a staging environment

Most reputable WordPress hosts (Kinsta, WP Engine, SiteGround, Cloudways, Pressable) offer one‑click staging — use it. Block staging from indexing with HTTP authentication or IP whitelisting plus the "Discourage search engines" setting under Settings → Reading. The Discourage setting alone isn't reliable; treat it as one layer in defence‑in‑depth. Document where you set blocks so you can systematically remove them on launch day, and verify with site:staging.example.com in Google.

3. Run a full SEO crawl and export key data

Crawl the live site with Screaming Frog or Sitebulb. Export every URL, status code, page title, meta description, canonical tag, and hreflang tag.

Concrete example: building a URL mapping row. If your crawl shows /blog/wordpress-migration-guide/ as a 200 URL with strong traffic and links, your mapping sheet gets: - Old URL: /blog/wordpress-migration-guide/ - New URL: /resources/wordpress-migration-guide/ - Redirect type: 301

Repeat for every URL. For large sites, bulk 301 redirect tools make this manageable.

4. Export analytics and search baselines

Capture baselines so you can diagnose issues if performance drops.

Record the last 3–6 months of organic sessions, conversions, and revenue, noting seasonality. For top landing pages, capture current sessions, conversions, top queries, and average positions in a single spreadsheet.

5. Identify "must‑protect" URLs

Combine traffic, conversions, and links into a single must‑protect sheet. High‑traffic pages, high‑converting pages (even with modest traffic), and heavily linked pages all need strict 1:1 redirect treatment. Mark them clearly so developers and stakeholders know they require extra care.

6. Audit plugins, theme, and hosting compatibility

• SEO plugins. Confirm Yoast, Rank Math, AIOSEO, SEOPress, or The SEO Framework is compatible with the new WordPress version, theme, and host. Yoast and Rank Math both export configuration to a file for re‑import — use it.
• Cache and CDN. WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, and Cloudflare can interfere with redirects and canonicals. Plan how you'll purge caches at launch.
• Page builders. Elementor, Divi, Beaver Builder, and WPBakery store layout data with hardcoded URLs in serialized post meta. A simple find‑and‑replace in wp_posts will miss these — use a serialization‑safe tool like WP Migrate or Better Search Replace.
• WooCommerce and membership. Confirm product URLs, category bases, and checkout endpoints will remain stable or be redirected. For WPML, Polylang, or TranslatePress, verify language plugin compatibility and hreflang on the new theme.
• Hosting. Check PHP/MySQL versions, server limits, SSL support, and redirect support (.htaccess for Apache/LiteSpeed, server config for Nginx).

7. Set goals and risk thresholds

Document acceptable downtime (ideally zero), acceptable ranking volatility (e.g. up to 10–20% for a few weeks), and an expected stabilisation timeframe (e.g. 4–8 weeks). Pre‑agreed thresholds prevent panicked changes mid‑recovery.

Choosing Your WordPress Migration Method (Plugin vs Manual vs Expert)

How you migrate directly affects SEO. Each method carries different risks of broken URLs, missing content, and downtime.

Plugin‑based migration is best for small to medium, simple sites — blogs and brochure sites with a few hundred posts at most, no complex e‑commerce or membership, and modest media libraries. Common plugins: All‑in‑One WP Migration, Duplicator, Migrate Guru (specialised for large sites), WP Migrate, UpdraftPlus Premium. Pros: speed, simplicity, low technical barrier. Cons and hidden SEO risks: file size limits and PHP timeouts can cause silent partial imports (the plugin shows "success" while older posts or product variations are silently dropped); page builder URL hardcoding may persist if the search‑replace isn't serialization‑safe; redirect rule control is limited.

Manual migration is best for larger or more complex sites where you need full control. Tools: SFTP/SSH for files, phpMyAdmin or wp db export/wp db import for the database, Better Search Replace or WP Migrate for serialization‑safe URL find‑and‑replace. Pros: full control, transparency, better handling of edge cases like complex redirects, custom post types, and special taxonomies. Cons: higher technical skill required, more time‑consuming, real risk of user error.

Professional/agency migration makes sense when complexity and SEO risk justify the cost: high‑traffic or revenue‑generating sites, WooCommerce/membership platforms, multilingual setups, or migrations combining domain change with redesign and URL restructuring.

Decision framework

• Very small, simple site (under ~200 posts/pages, no WooCommerce or LMS, no domain change) → plugin‑based with manual checks afterward.
• Medium or moderately complex site (200–1,000 posts, custom post types, light e‑commerce/membership, possibly a domain change) → plugin‑only becomes risky. Prefer manual or hybrid; lean toward an expert if you're not technical.
• Large or high‑stakes site (1,000+ posts, large media, WooCommerce, membership, multilingual, or major domain/URL changes) → avoid plugin‑only. Choose manual by someone experienced or hire a professional.

Rule of thumb: if you have more than ~500 posts, WooCommerce, and a domain change, plugin‑only is risky.

Step‑by‑Step: Migrating WordPress Without Breaking SEO

This sequence assumes the pre‑migration checklist is complete. If not, pause and complete it first.

1. Set up the new environment

Provision hosting, create a staging URL (staging.example.com), and install a fresh WordPress instance matching your current major version. Match or upgrade PHP and MySQL/MariaDB to versions compatible with your core, theme, and plugins. SEO‑critical: a stable, compatible environment prevents plugin or theme failures that silently strip SEO elements like title tags, schema, and internal links.

2. Move files and database

Whether by plugin or manually, the SEO outcome is identical as long as URLs, content, and settings remain intact.

• Plugin: install on both old and new sites, generate a full export package, import into the new environment.
• Manual: download all WordPress files via SFTP — wp-content, themes, plugins, and the entire uploads directory — then upload to the new server. Export the database via phpMyAdmin or wp db export, then import to the new database.

SEO‑critical: move the entire wp-content/uploads directory. Missing uploads break image URLs, hurting rankings, rich results, and engagement.

3. Update wp-config and site URLs

Configure wp-config.php on the new server with new database credentials. Update siteurl and home in wp_options to the new domain or staging URL. Then run a serialization‑safe search‑and‑replace for old → new URLs across posts, pages, menus, widgets, and post meta.

This step is critical for page builders. Elementor, Divi, and WPBakery store layout data with embedded URLs in serialized PHP arrays. Use Better Search Replace, WP Migrate's CLI, or wp search-replace (which handles serialization correctly). Never run a raw SQL REPLACE on serialized data — it corrupts the array length prefixes and breaks layouts silently.

4. Verify on staging

Browse key templates (homepage, category pages, product/service pages, blog posts, contact forms) and confirm functionality. Validate that title tags, meta descriptions, and canonical tags point to the correct URLs (not staging if you'll switch to the main domain). Confirm the permalink structure matches the old site, or add every change to the URL mapping document. Open a few page‑builder pages and confirm images, links, and embedded media render with the new URLs.

SEO‑critical: this staging review catches the issues that destroy rankings — missing titles, broken internal links, incorrect canonicals, hardcoded old URLs in builder content.

5. Plan and document URL mapping

If any URLs will change (domain, protocol, structure, category base, slugs), build a mapping document with columns: Old URL, New URL, Redirect Type (typically 301), Notes.

Concrete example: removing the category base. - Old: https://example.com/category/seo-tips/ - New: https://example.com/seo-tips/ - Type: 301 - Notes: "Category base removed; ensure no conflicting page slug."

Avoid redirect chains and loops. Map each old URL directly to its final destination — Old A → Final C, never Old A → Intermediate B → Final C. For complex multi‑thousand‑URL migrations, see our guide to URL redirects for migrations.

6. Implement 301 redirects

Server‑level redirects are preferred for performance — they fire before WordPress loads. Add 301 rules to .htaccess (Apache/LiteSpeed) or the Nginx config.

Plugin‑level alternatives: Redirection (free, by John Godley), Rank Math's redirection module, Yoast Premium redirects, or 301 Redirects by WebFactory. Most support CSV import — paste your mapping spreadsheet straight in.

Test a sample of redirects to confirm they return 301 (not 302), land on the correct final URL, and don't hop through multiple redirects. For HTTP → HTTPS, ensure a global 301 forces HTTPS. For domain changes, ensure all variations (with/without www, HTTP/HTTPS) redirect to the canonical new domain.

SEO‑critical: use 301 (permanent), not 302. A 302 tells Google the old URL is still the "real" one, blocking signal transfer.

7. Prepare for DNS switch and go‑live

Lower DNS TTL to 300 seconds 24 hours before launch. Schedule the switch during a lower‑traffic period. Do final staging checks on titles, meta, canonicals, internal links, and media. Then handle the launch‑day SEO settings:

• Uncheck "Discourage search engines from indexing this site" in Settings → Reading on the live site.
• Update robots.txt to allow crawling of the live domain.
• Keep staging blocked via password protection or persistent noindex/robots disallow.
• Point DNS A and AAAA records to the new server and verify resolution.

SEO‑critical: forgetting to remove noindex or restrictive robots.txt from the live site is the single most common cause of catastrophic post‑migration deindexing — even when the technical migration was perfect.

Critical SEO Tasks Right After the Migration

Run through this checklist immediately after launch to protect rankings and avoid indexation disasters.

1. Test key redirects. Manually test top old URLs and confirm they 301 to the correct new URLs. Crawl your old URL list and verify every URL returns 301 — not 404 or 302. For bulk 404 cleanup, see our Fix 404 Errors at Scale guide.

2. Confirm indexing settings. In Settings → Reading, "Discourage search engines from indexing this site" must be unchecked. Check robots.txt for unintended Disallow rules and inspect meta robots tags on key pages. A single ticked box that carries over from staging can deindex an entire site within days.

3. Verify canonical tags. View source on key pages. Canonicals must point to the correct live URL on the correct domain and protocol — never staging, the old domain, or HTTP versions.

4. Regenerate and submit XML sitemaps. Use your SEO plugin to regenerate sitemaps, confirm they contain only live URLs, and resubmit in Google Search Console and Bing Webmaster Tools.

5. Check HTTPS and mixed content. Make sure all pages load over HTTPS with no security warnings. Use browser dev tools or a crawler to find HTTP images, scripts, or stylesheets and update them.

6. Validate performance and structured data. Run key templates through PageSpeed Insights and Lighthouse. Check responsiveness on real mobile devices. Validate structured data with Google's Rich Results Test — theme changes commonly strip schema markup. For deeper schema guidance, see our Schema Markup in WordPress guide.

7. Finalise Google Search Console setup. If you changed domains, verify the new property and use the Change of Address tool to formally notify Google. Ensure preferred domain (with or without www) and protocol are consistent.

Monitoring SEO Performance After a WordPress Migration

Track the right metrics over clear timeframes and act when results cross agreed thresholds. For a full diagnostic playbook when traffic has already dropped significantly, see our Traffic Drop After Migration guide.

Core metrics

• Organic traffic by landing page. Compare sessions for key pages (home, top categories, top blog posts, core product/service pages). Group by section to see whether issues are isolated or systemic.
• Rankings for core keywords. Track priority keywords and their intended landing pages. If a different URL replaces the intended one, that signals redirect, canonical, or internal linking problems.
• GSC Page Indexing and crawl stats. Watch trends in "Indexed," "Excluded," and "Error" statuses.
• 404s and redirect errors. Use GSC reports, server logs, and your redirect plugin's log to spot missing redirects, chains, and loops.

Monitoring framework

(Recovery timelines for each migration type are in the Types of WordPress Migrations table earlier.)

Healthy vs warning patterns in GSC

A healthy "Page indexing" report a few weeks after launch shows indexed pages on new URLs rising steadily, old URLs moving from "Indexed" to "Excluded – Page with redirect," and "Not found (404)" low and stable.

Warning patterns: a growing "Not found (404)" list for URLs that should redirect, many "Alternate page with proper canonical tag" entries where you expected direct indexing, or a plateau in indexed pages while errors rise.

Set stakeholder expectations that short‑term volatility is normal — drops up to ~20–25% in the first month can be expected. Define specific triggers (e.g. site‑wide drop >30% after 4–6 weeks) as the signal to investigate, and share a monitoring cadence: weekly for the first month, then bi‑weekly.

Common WordPress Migration SEO Mistakes (and How to Avoid Them)

These are the WordPress‑specific failure modes we see most often.

1. Leaving "Discourage search engines from indexing this site" ticked. A single setting under Settings → Reading can deindex an entire site. Add "verify Discourage box is unchecked" as a launch‑day item; confirm with robots.txt and a live crawl after go‑live.

2. Running a raw search‑replace on serialized data. WordPress stores theme settings, page builder layouts, and custom field data as serialized PHP arrays with length prefixes. A SQL REPLACE of oldsite.com with newsite.com corrupts the length prefix when string lengths differ, silently breaking Elementor/Divi/WPBakery layouts. Always use a serialization‑safe tool: Better Search Replace, WP Migrate, or wp search-replace via WP‑CLI.

3. Cache or CDN serving stale redirects. WP Rocket, W3 Total Cache, LiteSpeed Cache, and Cloudflare can serve cached pages that bypass new redirects, or cache the redirects themselves indefinitely. Purge all caches at launch and after any redirect change. Set short TTLs on redirect responses during week one.

4. No or incomplete 301 redirects. Old URLs with no permanent redirect lose link equity, send users to 404s, and let rankings collapse. Crawl the old site before migration, build a 1:1 redirect map, and after launch crawl old URLs to catch missed 404s.

5. Using 302 instead of 301 for permanent moves. A 302 tells search engines the move is temporary, so the old URL stays indexed and link equity doesn't transfer. Many WordPress redirect plugins default to 302 unless you change it — audit with a header checker.

6. Page builder content with hardcoded old URLs. Even after a successful database search‑replace, some builders cache rendered output or store URLs in post meta the search‑replace tool didn't reach. Open key page‑builder pages in the editor and re‑save them; clear the builder's CSS cache (Elementor: Tools → Regenerate CSS; Divi: Theme Options → Clear Static CSS).

7. Allowing staging to be indexed. If staging gets indexed alongside production, you create duplicate content and split signals. Protect staging with HTTP auth or IP whitelist, plus noindex plus robots.txt disallow. Periodically search site:staging.example.com and request removal of anything that slipped through.

8. Blanket redirects to the homepage. Redirecting every old URL to the homepage wastes relevance — Google often treats mass irrelevant redirects as soft 404s. Map each old URL to the most relevant new page; only send to the homepage when there's truly no equivalent.

9. Ignoring internal links and navigation updates. Old links in menus, widgets, and content force users and crawlers through redirect chains. Update menus, widgets, and template links to point directly to new URLs; crawl post‑launch to find internal links still hitting redirects or 404s.

10. Outdated canonical tags and XML sitemaps. Canonicals pointing to old URLs, staging, or HTTP send mixed signals. Outdated sitemaps slow discovery. Confirm canonicals are dynamically generated from the live URL, regenerate sitemaps via your SEO plugin, and resubmit.

11. Broken hreflang on multilingual sites. WPML, Polylang, and TranslatePress generate hreflang from URL structures. When language folders or domains change, hreflang annotations break, causing wrong‑language pages to rank or international visibility to drop. Update all hreflang tags and verify reciprocal relationships with a hreflang validator.

12. Forgetting the WordPress object cache. Sites using Redis or Memcached can serve stale wp_options data — including the old siteurl — even after the database has been updated. Flush the object cache after the database move and any URL changes (wp cache flush via WP‑CLI).

When to Hire Help for a WordPress SEO Migration

Hiring an expert is usually safer when traffic or revenue risk is high and the setup is complex. Professional help is strongly recommended if:

• You have a large site (hundreds or thousands of URLs) that depends on organic traffic. A misconfigured redirect rule can silently break hundreds of pages at once.
• You run complex WooCommerce, membership, or LMS functionality. Product filters, account areas, course content, and checkout flows generate many dynamic URLs that must be mapped and tested.
• You use multilingual or hreflang setups (WPML, Polylang, TranslatePress). Mistakes can cause entire markets to disappear from search.
• You're changing multiple things at once — new domain, full redesign, new URL structure. Each change adds risk; combined, they multiply the chances of losing rankings.

Concrete example: a mid‑sized WooCommerce site tried a DIY migration while redesigning and moving to a new domain. They launched without a complete redirect map, missed key category URLs, and didn't monitor Search Console. Within weeks, organic revenue dropped by more than half. An SEO specialist had to audit old vs new URLs, implement proper redirects, and fix indexing issues to recover.

When choosing a provider, look for proven SEO‑safe migration experience (not just general WordPress or design work), case studies showing stable or improved organic traffic, a clear documented process, rollback plans, and solid understanding of GSC, redirects, and analytics. Key questions to ask:

• How will you plan and implement redirects from every important old URL to the correct new one?
• How do you use staging to test technical SEO, templates, and tracking before launch?
• What post‑migration monitoring will you do, and how quickly will you act if traffic drops?

WordPress Migration SEO Checklist (Printable Summary)

For a platform‑agnostic version of this checklist suitable for project managers handling Shopify, custom builds, or other CMSes, see our Website Migration Checklist.

Frequently Asked Questions