WordPress Migration Without Losing SEO Rankings: Complete Guide

How to Migrate a WordPress Site to a New Host Without Losing SEO Rankings

Moving WordPress to a new hosting provider is a task that goes wrong in predictable ways. URLs change without redirects, sites go offline during DNS propagation, and server configurations cause crawl errors that search engines notice immediately. The result is a measurable drop in search positions that can take weeks to recover. This guide walks through every step that affects your search visibility during a WordPress migration, with enough detail to make good decisions at each stage.

Why WordPress Migrations Damage SEO

Search engines index URLs, not servers. When you change hosting providers, if the URLs remain identical and the site stays accessible, there is no SEO impact at all. The damage happens when something in that equation changes unexpectedly.

The three main causes of SEO loss during migration are:

• URL changes: Moving from example.com/page to example.com/old/page changes the address that search engines have indexed. Without redirects, every incoming link and search position for that page is effectively lost.
• Extended downtime: If the site is unreachable for more than a few hours during the DNS switch, search engine bots may mark pages as unavailable and begin removing them from the index.
• Configuration errors: Incorrect file permissions, missing SSL certificates, malformed canonical tags, or unexpected server responses after migration can cause search engines to interpret the site differently than before.

Understanding these risks shapes how you plan the migration. Rushing through preparation to get to the "actual" migration is where most problems originate.

Step 1: Audit Your Current Site Before Migration

Before touching anything, export your current search position data. Note which pages rank for which keywords, your top performing URLs, and any pages with significant inbound links. This baseline lets you measure the actual impact of the migration and identify specific problems early.

Use Google Search Console to export this data:

1. Open Google Search Console: Sign in and select your website property.
2. Navigate to Performance: Click on the Search results section under the Performance menu.
3. Filter by page: Use the filter options to see data broken down by individual pages rather than aggregated site totals.
4. Export to CSV: Click the export button and download your data. Store this file somewhere accessible after migration completes.

Pay particular attention to your top 20 pages by clicks. These are the pages most likely to cause noticeable traffic loss if something goes wrong during migration. If you have a page that receives most of your search traffic, protecting that page during migration should be your highest priority.

Step 2: Back Up Everything

Take a complete backup of your WordPress site before making any changes. A WordPress site consists of two main parts that you need to capture separately.

• Files: All files in the WordPress root and subdirectories, including the wp-content folder, which contains your themes, plugins, and uploaded media.
• Database: The MySQL database containing all your posts, pages, comments, and WordPress settings.

Use a direct mysqldump command to export the database and tar to archive the files:

mysqldump -u username -p database_name > backup_date.sql

tar -czvf wordpress_backup_date.tar.gz /var/www/html/

Store this backup somewhere outside the server you are migrating from. Keeping the backup on the same server you are leaving defeats the purpose if that server fails during the migration process.

Note: If you use a managed WordPress host or a plugin-based backup service, follow their documented backup procedure and verify the backup is complete and restorable before proceeding. Do not assume the backup is valid without testing it.

Step 3: Set Up the New Server

Configure the new server before moving any data. Install the same version of PHP your site currently runs on, set up the same or equivalent web server configuration, and ensure the SSL certificate is ready before you point traffic at it. Matching the old environment as closely as possible reduces the number of variables that can cause problems.

If you are setting up a new server from scratch, the process involves installing a web server, database, and PHP environment. A LAMP stack (Linux, Apache, MySQL, PHP) is a common choice that works well with WordPress. The specific setup steps depend on your hosting provider and server operating system, but the goal remains the same: create a working environment that will run your site without unexpected changes to how it behaves.

When choosing a new hosting provider, consider that cheaper options sometimes cut corners on server configuration, security hardening, and support response times. The cost difference between hosting tiers can be small compared to the cost of recovering from a security incident or extended downtime. If you are evaluating hosting options, it is worth reviewing what each plan includes in terms of server maintenance, security updates, and backup infrastructure.

Your goal is for the new server to be a working clone of the old one before DNS changes. This means:

• Matching PHP version: Check your current site phpinfo() page or ask your current host what PHP version is in use. Running PHP 7.4 on the old server and PHP 8.2 on the new one without testing can cause compatibility issues with plugins. WordPress supports PHP 8.0 and above, but some older plugins may not be compatible with newer PHP versions without updates.
• Equivalent web server: If you run Apache, match the version and key modules. If you run Nginx, configure similar rewrite rules to your existing setup to preserve any custom URL handling.
• SSL ready: Install your SSL certificate on the new server before migration. An SSL certificate encrypts the connection between your visitors and the server, which is a standard expectation for modern websites.

Install WordPress on the new server and verify it is working with a placeholder page before importing your content. This confirms the server stack is correct and prevents a situation where you have migrated data to a broken environment.

Step 4: Import the Site to the New Host

Transfer the backup files to the new server and restore the database. Use secure file transfer to move the SQL dump, then extract your file archive and import the database.

scp wordpress_backup_date.sql user@newserver:/tmp/

tar -xzvf wordpress_backup_date.tar.gz -C /var/www/html/

mysql -u username -p database_name < /tmp/backup_date.sql

After importing, update the wp-config.php file if the database credentials have changed on the new server. Check these values carefully:

• DB_NAME: The database name on the new server.
• DB_USER: The database username with access to that database.
• DB_PASSWORD: The password for that user.
• DB_HOST: Usually localhost, but some hosts use a remote database address.

After updating wp-config.php, visit your WordPress admin area on the new server to confirm everything loads correctly. If you see database connection errors, the credentials in wp-config.php do not match the actual database configuration on the new server.

Step 5: Update Internal Links

WordPress stores absolute URLs in the database. If your domain has changed, update all internal links using WP-CLI. This tool handles the replacement correctly, including serialised data that direct SQL queries often break.

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

wp search-replace 'https://old-domain.com' 'https://new-domain.com'

Run with --dry-run first to see how many replacements will be made and verify the output looks correct before running the actual replacement. A dry run shows you exactly what will change without making any modifications.

Warning: If you are migrating to the same domain name (just a new server), skip the search-replace step entirely. Only run it when the domain URL itself has changed. Running this command unnecessarily can corrupt your database by making unintended replacements.

Step 6: Set Up 301 Redirects If URL Format Has Changed

If the URL structure has changed, for example moving from /post-name/ to /blog/post-name/, create 301 redirects from every old URL to every new URL. A 301 redirect tells search engines the page has permanently moved and passes most of the ranking signal to the new address. This is the most important SEO protection you can add during a migration.

In Apache, add redirects to the .htaccess file:

Redirect 301 /old-url-slug /new-url-slug

For more complex redirect mapping, you can use RewriteRule directives:

RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

In Nginx, use the rewrite directive:

rewrite ^/old-url-slug$ /new-url-slug permanent;

If you have many redirects to manage, consider using a redirection plugin on your WordPress site itself to keep the redirect map manageable and auditable over time. A plugin approach also means redirects are preserved if you later switch server configurations.

Map every changed URL individually. Wildcard redirects can help in some cases but often create unexpected behaviour where unintended URLs get redirected to pages that do not match them.

Step 7: Verify Before Switching DNS

Before pointing DNS at the new server, test the site on the new server using the hosts file on your local machine. This lets you view the new server content while everyone else still sees the old server.

# Add to /etc/hosts (macOS and Linux)
# or C:\Windows\System32\drivers\etc\hosts (Windows)

192.168.1.50 example.com
192.168.1.50 www.example.com

Replace the IP address with your new server's actual IP address. After saving the hosts file, clear your browser cache and visit your domain in a private or incognito window.

During this test phase, check the following:

• Pages load correctly: Navigate through your main pages and verify content displays properly.
• Images display: Check that images load from the correct paths and are not broken.
• SSL works: Verify the padlock icon appears and there are no certificate errors.
• Sitemap accessible: Visit your XML sitemap URL and confirm it generates correctly.
• Canonical tags: Check page source to confirm canonical tags point to the correct URLs.

Pay attention to mixed content warnings. If your site loads some resources over HTTP while the page itself loads over HTTPS, browsers display a security warning to visitors. This affects user trust and can indirectly influence search rankings through engagement metrics.

Step 8: Update DNS

Update your DNS A record or CNAME to point to the new server IP address. Log in to your domain registrar or DNS provider and make the change in their control panel.

After updating DNS, keep the old server running for at least 48 hours. Some DNS resolvers cache old records longer than expected, and having the old server available prevents downtime for visitors still hitting the old IP address.

Use a tool like What's My DNS to check propagation status across different regions. Full propagation can take up to 48 hours, though most visitors will see the new server within a few hours. During this period, split traffic between the two servers is normal and expected.

Note: If you are using a CDN in front of your site, you may need to update the CDN configuration separately from the DNS records. CDN providers typically have their own DNS management that points to your origin server. Update the origin server address in your CDN settings before or after changing DNS, depending on your provider's recommendations.

Step 9: Post-Migration Verification

Once the migration is live, run through these checks systematically. Catching problems early prevents longer-term SEO damage that can take weeks to reverse.

• Google Search Console: Check for crawl errors, canonical warnings, and mobile usability issues. Address any errors immediately.
• Top pages: Manually check your top 20 pages by traffic. Verify content, images, and internal links are all correct.
• SSL certificate: Confirm the padlock is showing and there are no mixed content errors where secure and insecure resources load on the same page.
• XML sitemap: Resubmit the sitemap in Google Search Console to trigger re-crawling.
• Page speed: Run the site through Google PageSpeed Insights to confirm performance has not degraded after migration.

Compare your post-migration rankings against the baseline data you captured in Step 1. Small fluctuations are normal, but significant drops warrant immediate investigation.

During the first week after migration, check Google Search Console daily for any emerging crawl errors. Problems that appear immediately after migration are easier to fix while the search engines are still processing the changes.

How Long Before SEO Recovers

If the migration is done correctly with 301 redirects for changed URLs, search positions typically recover within 2 to 4 weeks. Google processes the redirect signals and updates its index during this period. The exact timeline depends on how frequently Googlebot visits your site and how significant the changes appear to be.

If URLs changed without redirects, recovery is slower and some position loss is usually permanent. Search engines treat missing pages as deleted over time, and rebuilding rankings for new URLs takes considerably longer than redirecting existing signals. Every day without a redirect is a day of lost link equity.

Sites that experienced significant downtime during migration may take longer to re-crawl and re-index. If your site went offline for more than 24 hours, expect an extended recovery period as Googlebot needs to revisit and verify the site is stable again. Keeping the old server online until DNS fully propagates is the best protection against this.

Server Security After Migration

After completing the migration, take a moment to review the security posture of your new server. A fresh server configuration is a good opportunity to ensure baseline protections are in place.

Consider whether fail2ban is installed and configured. This tool monitors server logs for suspicious activity and automatically blocks IP addresses that show signs of brute force attacks or other malicious behaviour. Configuring fail2ban for SSH access is particularly important if your server accepts SSH connections directly.

Review your Apache or web server configuration for security best practices. Default configurations are often more permissive than necessary for a production website. Restricting access to sensitive files, disabling directory listing, and configuring appropriate timeout values are standard hardening steps that reduce your attack surface.

Related practical reading

These related guides can help you connect this topic with the wider website, server, security, and support decisions around it.

• SSH Config Tips That Save Hours of Time - useful background for related technology decisions
• How to Build a PHP Webhook Receiver: Complete Implementation Guide - useful background for related technology decisions

What Matters Most

WordPress migrations only damage SEO when URLs change without redirects, the site goes offline for extended periods, or configuration errors change how search engines interpret the content. The process is straightforward if you follow a clear sequence: audit before you start, back up everything, test on the new server before switching DNS, set up redirects for any changed URLs, and verify thoroughly after migration.

Most migration problems come from skipping the testing phase or not keeping the old server running long enough for DNS to propagate. Rushing to decommission the old server before confirming the new one works correctly is a common mistake that turns a manageable migration into an emergency.

If you need help reviewing your migration plan or handling a complex WordPress move, prepare a note with your current hosting details, target hosting provider, whether your domain is changing, and any URL structure modifications you are considering. This gives a clear picture of what the migration involves before any work begins.