How to Move WordPress to a New Host Without Losing SEO

A hosting migration should improve the home of your website without confusing visitors, search engines or the people who maintain it. The difficult part is rarely uploading files. It is knowing which copy is current, which server a visitor reaches, and whether checkout, forms and scheduled jobs still work.

This guide covers a single WordPress installation moving to a different hosting provider with its existing domain. It includes a practical DirectAdmin workflow, DNS and IPv6 checks, an SEO checklist and a rollback plan. WordPress Multisite, a domain rebrand and heavily customised commerce systems need additional planning.

Does changing hosting affect SEO?

Changing the server does not require changing your public URLs. Keep the same domain, HTTPS scheme, preferred www or non-www hostname and permalink structure. A move becomes more complicated if you also rename pages, replace the theme, remove content or change your canonical settings.

Google separates infrastructure migrations from URL-changing moves. Its process is to prepare and test the destination, change DNS, monitor both hosts and retire the old infrastructure once traffic has moved. A temporary change in Googlebot crawl rate can occur. Follow Google's hosting-migration guidance and assess crawl errors and real page responses, rather than treating every short-term search fluctuation as a migration failure.

Our recommendation is to separate the move from a redesign. Record the current titles, descriptions, canonical tags and redirects first. You then have a useful comparison if a plugin setting changes during the transfer.

Choose the right WordPress hosting destination

Measure your current disk use, database size, busiest periods and plugin requirements before selecting a plan. Leave working space for the extracted site, a database import and backups. An account that only just fits the live files can run out of space partway through a restore.

Shared plans currently start at $2 per quarter; reseller plans start at $6 per quarter. Those are quarterly charges, not monthly prices. See the linked plan pages for current allowances and billing choices. Shared and reseller web hosting are in Wolverhampton; the two-region choice above applies to Cloud VPS.

Using a VPS is not a requirement for moving WordPress. If you do not need root access, managed web hosting often removes work from your migration checklist. Our shared hosting versus VPS guide explains the operational differences.

1. Record what must survive the move

Create a small migration record with the old and new server addresses, DNS provider, registrar login, WordPress administrator access and hosting-account access. Store credentials privately, not in a shared checklist or support screenshot.

• Record the PHP version, required extensions, database version, active theme and essential plugins.
• Export the DNS zone or save all records: A, AAAA, CNAME, MX, TXT, CAA and any verification entries.
• List external services: payments, form delivery, analytics, CDN, object storage, webhooks and scheduled jobs.
• Save the XML sitemap and a list of important URLs, including your best landing pages, products and recent posts.
• Record the current SEO plugin settings, redirects and robots directives.

Website hosting, DNS hosting, domain registration and email hosting can be separate services. You do not need to transfer the domain registration to move the website. If email will stay where it is, preserve its DNS and routing configuration deliberately.

2. Take a complete, recoverable backup

WordPress has two essential parts: files and the database. The files include uploads, plugins, themes, configuration and sometimes custom code outside the usual folders. The database contains posts, settings, users and other application data. A WordPress content export alone is not a complete hosting-account backup.

For the initial copy, use a full-site migration package or download the site files and export the database. Include hidden files such as .htaccess where relevant. Keep the backup outside the public document root and save an independent copy before changing anything. The WordPress migration handbook covers file/database transfers and the configuration changes involved.

Check that the archive opens and contains the expected uploads and database export. For a valuable site, rehearse restoring it into the destination before the final migration window. Record the backup time so nobody mistakes yesterday's copy for the final one.

HYEHOST includes daily JetBackup backups on its shared platform. A fresh pre-migration copy still has value: it captures the state you chose to move. For independently managed backups, a Storage Box can hold an off-server copy when used with a compatible backup workflow.

3. Prepare DirectAdmin and restore the site

Open the new hosting service from the HYEHOST panel, enter DirectAdmin and add the existing domain to the account. Confirm its document root and available storage. Match a supported PHP version to the site's requirements; combining a major PHP upgrade with a hosting move makes faults harder to isolate.

Option A: use a WordPress migration plugin

A migration plugin is useful if you prefer to work inside WordPress. Check its current import-size limits, licensing, storage requirements and handling of custom folders before relying on it. Create a temporary destination installation only if the plugin's documented restore workflow requires one. Import into the new site, never the existing live site.

A restored database can bring across the old WordPress administrator accounts and settings. Keep the original credentials available and verify that the restored site contains the expected users. Learn WordPress explains a plugin-based migration; follow the chosen plugin's current instructions for its specific import process.

Option B: transfer files and import the database

1. Upload and extract the WordPress files into the new domain's document root using the access methods available on the account.
2. Create a new, empty database and a database user on the destination.
3. Import the SQL backup into that database using the available database tools. Large imports may require assistance or an alternative supported method.
4. Update DB_NAME, DB_USER, DB_PASSWORD and, if different, DB_HOST in the destination's wp-config.php.
5. Preserve the existing table prefix. Check custom paths, cache connections and any environment-specific settings.

Do not overwrite an unrelated database or leave SQL dumps and installer archives publicly downloadable. After verifying the restore, remove temporary migration installers and public backup files. DirectAdmin's WordPress Manager documentation explains its installation and database-configuration controls; available menus depend on the enabled account features.

4. Test the new host before changing public DNS

Test using the real hostname so WordPress generates the same URLs and cookies it will use after the move. A temporary hosts-file entry on your computer can map the domain and its www hostname to the destination address. Only that computer uses the override; visitors continue reaching the existing site. Remove the entry after testing.

Arrange a valid certificate for the real domain on the new host before sending visitors there. If ordinary HTTP validation still reaches the old host, ask about DNS validation or another supported provisioning method. A preview page that bypasses certificate validation does not demonstrate working production HTTPS.

For a terminal check, curl can connect to a specific address while retaining the hostname for HTTPS. Replace the documentation address below with the actual destination IPv4 address:

curl --resolve example.com:443:192.0.2.10 -I https://example.com/
curl --resolve example.com:443:192.0.2.10 -I https://example.com/sample-page/

These commands inspect response headers; they do not test checkout, page rendering or every redirect target. Test www separately if it is used. Do not add -k to hide certificate errors. The curl documentation for --resolve describes this address override.

• Open the homepage and several deep URLs, including one that uses WordPress permalinks.
• Check media, menus, downloads, search and mobile layouts.
• Sign in to the dashboard and confirm the correct site/database is in use.
• Test forms and external integrations without sending duplicate real customer notifications.
• Check redirects, canonical tags, the sitemap, robots.txt and response headers.

If a CDN or reverse proxy sits in front of the site, an origin test is only half the job. Test the public CDN route after updating its origin configuration as well.

5. Prepare DNS, IPv6 and email records

If your DNS provider allows it, lower the website records' TTL ahead of the move, then wait out the previous TTL before relying on the shorter value. Changing a TTL does not erase answers already cached by resolvers. Cloudflare's TTL reference explains cache lifetimes and the special behaviour of proxied records.

For a straightforward host-only move, you may only need to change website A and AAAA records. Retaining the existing DNS provider can reduce the number of changes. If moving authoritative DNS too, build and verify the complete destination zone first and coordinate DNSSEC/DS changes with both providers.

Keep MX, SPF, DKIM and DMARC records intact unless you are intentionally migrating email. Moving WordPress does not transfer mailbox contents or passwords. A contact form also needs a working delivery method on the destination; verify receipt, not just the “message sent” screen.

HYE DNS is an option for managing authoritative DNS separately from the website. The same migration discipline applies whether you use it, your registrar's DNS or another provider.

6. Take the final copy and move traffic

For an infrequently updated brochure site, the final copy may simply mean pausing edits, copying the latest files and exporting/importing the database again. For WooCommerce, bookings or membership sites, writes include orders, registrations, webhooks and background jobs—not just posts you publish.

1. Announce a suitable maintenance window and stop new writes on the old site using an appropriate maintenance or read-only workflow.
2. Pause relevant scheduled tasks and integrations so both copies do not process the same work.
3. Take the final database export and copy files changed since the rehearsal, such as new uploads.
4. Restore that final state on the destination and repeat the critical checks.
5. Update website DNS records or the CDN origin settings.
6. Enable writes and jobs on the destination only after validating the cutover. Keep the old instance read-only while cached traffic drains.

Some users may still reach the old host during the transition. A maintenance response there can be safer than accepting orders into a database that will no longer be used. Where uninterrupted transactions are essential, design a controlled proxy or replication-based migration with an engineer rather than promising zero downtime from a basic file copy.

7. Run the post-migration SEO checklist

Compare the public site against the record made before migration. Check representative pages from each template, not just the homepage.

• Successful responses: important pages return their intended content, without new 404, 500 or redirect-loop errors.
• Stable URLs: HTTPS, www preference, paths and trailing-slash behaviour remain consistent.
• Indexing allowed: remove temporary staging authentication and unintended noindex directives from the live site. Review WordPress's search-engine visibility setting and server-level X-Robots-Tag headers.
• Correct canonicals: tags reference the public domain, not a preview hostname or server address.
• Preserved content: titles, descriptions, headings, internal links and structured data match the intended live site.
• Working sitemap: its URLs remain canonical and reachable, with no preview entries.
• Operational checks: analytics, forms, transactions and scheduled tasks behave as expected.

Inspect important URLs in Search Console and monitor crawl and indexing reports. A host-only move on unchanged URLs does not need a domain Change of Address submission. If you also change the domain or URL structure, create an old-to-new URL map and follow Google's separate URL-migration guidance.

Only replace database URLs if they actually change

Keeping the same public URL usually means no domain-wide database replacement is necessary. If a temporary URL was written into the database, use a WordPress-aware replacement tool on the destination after taking another backup. A plain SQL string replacement can damage serialised values.

Where SSH and WP-CLI are available, this example previews a replacement first. It is optional and not a promise of SSH access on every hosting account:

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

Review the affected tables and counts. Only then repeat without --dry-run if the change is correct. Run it from the destination installation and avoid --all-tables when a database contains unrelated applications. See the official WP-CLI search-replace reference.

Common WordPress migration problems

Inspect logs before reinstalling plugins at random. Once the uncached site works, enable the intended cache configuration and purge stale content. HYEHOST's LiteSpeed and LSCache stack can help serve cacheable pages, but checkout, account pages and private responses must retain suitable cache exclusions.

Keep a rollback plan and retire the old host carefully

Record the old DNS values and keep access to the old hosting account until the new site is stable and old traffic has drained. Google recommends using traffic evidence when deciding to shut down the old infrastructure; a fixed countdown alone cannot tell you where every client is connecting.

Switching DNS back is not a complete rollback if the new site has accepted orders, registrations or uploads. Preserve the new data first, pause conflicting writes and decide how it will be reconciled. Restoring the old snapshot blindly can lose real customer activity.

When ready, remove preview records, local hosts overrides and temporary tools. Verify destination backups and perform a restore test. Keep the original migration archive according to your retention policy, then review whether the old hosting subscription is still needed.

WordPress hosting migration FAQ