How to Migrate WordPress Without Losing SEO

Short answer: preserve the URL structure whenever possible, move the files and complete database together, test the new environment before changing DNS, and use direct permanent redirects only when URLs change. A host move with the same domain is primarily an infrastructure project. A domain change is also a search migration and needs URL mapping, redirects, canonical updates, a new sitemap, and Search Console monitoring.

The old version of this guide incorrectly treated Tools → Export as a full database migration. WordPress export files are useful for transferring content, but they do not clone every plugin table, setting, user relationship, or environment configuration. A complete site move normally requires the full database and the relevant files.

Decide which type of WordPress migration you are doing

New host, same domain and URLs

If every public URL stays identical, Google does not need a Change of Address request or page-by-page redirects. The main risks are downtime, incorrect DNS, missing files, database differences, SSL, email delivery, cache, cron, and server configuration.

New domain or changed URL structure

If public URLs change, create a one-to-one map from every valuable old URL to its new equivalent. Google recommends permanent server-side redirects, updated internal links, self-referencing canonicals on the new URLs, updated sitemaps, and Search Console monitoring.

HTTPS, www, subdomain, or path changes

These changes also affect public URLs. Handle them as a search migration even when the WordPress content is unchanged. Avoid combining a domain move, complete redesign, CMS replacement, and major content deletion unless there is a strong operational reason; each extra variable makes failures harder to isolate.

Pre-migration checklist

• Crawl or export a list of current indexable URLs.
• Export top landing pages, queries, links, and performance data from Search Console and analytics.
• Record current titles, canonicals, robots directives, structured data, hreflang, redirects, and HTTP status codes.
• Inventory forms, email, payment, webhooks, scheduled jobs, integrations, DNS records, and CDN rules.
• Create a complete restorable backup of the database and files.
• Reduce DNS TTL in advance when the DNS provider and migration plan support it.
• Choose a quiet migration window and define who can approve rollback.
• For stores or membership sites, plan how to handle new orders and user activity during the final database sync.

Step 1: Build and test the destination

Install the required PHP version, database, web server rules, SSL certificate, and WordPress environment on the new host. Copy the site to a staging hostname or test using a local hosts-file override so the production domain can remain live during validation.

Protect staging from public access and search indexing. Prevent it from sending production email, charging real payment methods, or triggering live webhooks. Before launch, remember to remove temporary noindex rules and access restrictions from the real destination.

Step 2: Copy WordPress files and the complete database

Copy the required files, including uploads, active themes, plugins, must-use plugins, and environment-specific configuration. Export and import the complete WordPress database rather than relying only on the WXR content export.

Keep the database and files from approximately the same point in time. On a frequently changing store, use a maintenance window or a final delta process so orders created after the initial copy are not lost.

Step 3: Update configuration safely

Set the correct database credentials and environment values in wp-config.php or the host’s secret-management system. Confirm file paths, salts, cache configuration, object-cache connections, SMTP credentials, cron behavior, and external API endpoints.

If the domain changes, update URLs using a tool that understands serialized WordPress data. WP-CLI provides a dry-run option:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid --dry-run

Review the dry-run output, take another database backup, then run the intended replacement without --dry-run. The official WP-CLI search-replace documentation explains table scope, serialized data, export, network, and dry-run options.

Do not run a plain text replacement directly against a SQL database without understanding serialized values. Incorrect replacements can corrupt widget, builder, and plugin settings.

Step 4: Test before launch

Test the destination while the public site still points to the old host:

• home page and representative posts, pages, archives, and media;
• administrator login, password reset, and user roles;
• contact forms and actual email delivery;
• search, menus, redirects, downloads, and protected content;
• WooCommerce product, cart, coupon, shipping, checkout, sandbox payment, order email, and My Account;
• canonical URLs, robots meta, robots.txt, XML sitemap, schema, and hreflang;
• scheduled actions, backups, security monitoring, and external integrations;
• mixed-content errors, browser console errors, PHP logs, and 404 responses;
• performance and cache behavior with anonymous and logged-in sessions.

Step 5A: Launch a same-domain host move

1. Put high-activity features into a controlled maintenance or content-freeze window if needed.
2. Run the final database and upload sync.
3. Confirm SSL and virtual-host configuration on the destination.
4. Change the DNS record to the new server.
5. Monitor traffic on both servers while DNS caches update.
6. Do not cancel the old host immediately. Keep a rollback window and preserve logs.
7. Verify that the same URLs still return the intended status, canonical, and content.

If the domain and every path remain the same, do not add unnecessary redirects merely because the server changed.

Step 5B: Launch a domain or URL migration

Create a one-to-one URL map

Each old URL should redirect to the closest equivalent new URL. Do not send every retired page to the new homepage. Google warns that irrelevant mass redirects can be treated as soft 404s.

Use permanent server-side redirects

Use HTTP 301 or 308 redirects when the move is permanent. Point each old URL directly to the final new URL and avoid chains such as old HTTP → old HTTPS → new HTTP → new HTTPS.

Google recommends permanent server-side redirects as the clearest signal that the destination should become canonical. See the official redirect guidance.

Update signals on the new site

• Use self-referencing canonicals on the new URLs.
• Update internal links, images, structured data, hreflang, feeds, and Open Graph URLs.
• Generate a sitemap containing the new canonical URLs.
• Update analytics, advertising destinations, email templates, social profiles, and important external links.
• Verify both old and new Search Console properties.

Use Search Console correctly

For a domain or subdomain change, submit the Change of Address after redirects are active and verified. It is not needed for a normal host change with identical URLs, a simple HTTP-to-HTTPS move, or path changes within the same domain.

Submit the new sitemap and inspect important URLs. Google’s site-move documentation recommends keeping redirects for at least one year; keeping useful redirects indefinitely is often better for visitors and old links.

Step 6: Monitor after launch

For the first hours and days, monitor:

• uptime, server resources, PHP and application errors;
• DNS resolution and SSL certificate behavior;
• 404s, redirect loops, chains, and unexpected 5xx responses;
• form submissions, email, payment, webhooks, and scheduled actions;
• Search Console indexing, crawl errors, pages, sitemap processing, and Core Web Vitals;
• analytics page views and conversion events;
• logs on the old server to find traffic hitting URLs without a valid mapping.

Some ranking fluctuation is normal after a domain move while Google recrawls the old and new URLs. A small or medium site may take several weeks for most URLs to transfer. Do not remove redirects or reverse the migration solely because positions move for a few days.

Assign ownership after the migration

A successful launch still needs an operational handoff. Record the new hosting, DNS, backups, deployment process, licenses, monitoring, administrator accounts and vendor contacts. Name the team responsible for post-launch defects and agree when the old environment can be retired.

Document response and escalation expectations in a website support SLA. If the destination needs continuing updates, monitoring and fixes, connect the handoff to a defined WordPress maintenance service instead of treating migration as the final ownership step.

When responsibility also moves to a new agency or internal team, use the complete WordPress website handover checklist to transfer accounts, licenses, analytics, source code and open work.

Common WordPress migration mistakes

• Using Tools → Export as if it were a complete database and site clone.
• Launching a staging site with a forgotten noindex directive.
• Replacing URLs in serialized data with an unsafe SQL text operation.
• Redirecting every old URL to the homepage.
• Creating redirect chains instead of pointing directly to the final URL.
• Changing domain, design, navigation, and most content simultaneously without a testable reason.
• Closing the old host before DNS, email, redirects, and rollback are verified.
• Losing orders or form entries created between the initial copy and final sync.
• Forgetting canonicals, hreflang, structured data, sitemap, analytics, or consent configuration.
• Blocking Googlebot at the new destination after launch.

Frequently asked questions

Will changing WordPress hosting hurt SEO?

Not inherently. If URLs, content, status codes, canonicals, performance, and availability remain stable, a host move should not require a search migration. Downtime, server errors, slower performance, or accidental blocking can still hurt.

Do 301 redirects lose PageRank?

Google states that permanent redirects do not cause a loss of PageRank. Relevance, correct one-to-one mapping, direct redirect paths, and keeping redirects active remain important.

How long should migration redirects remain?

Google recommends at least one year for a site move. Keeping them longer helps visitors and links that continue using the old URLs.

Can I migrate WordPress without a plugin?

Yes. You can move files and the database using hosting tools, SFTP/SSH, database utilities, and WP-CLI. The important part is handling serialized data, configuration, testing, final sync, and redirects correctly.

Need the migration handled and verified?

CodaStudio can plan the URL map, move the files and database, test business-critical workflows, and monitor the launch through our WordPress support service. Before moving, create a verified recovery point with our guide to backing up WordPress to Dropbox. Ongoing updates, backups, and monitoring are available through WordPress maintenance.