Move WordPress without losing rankings: DNS, redirects and Search Console checklist

Moving a WordPress site to new hosting or a new domain is an operation that takes a few hours of technical work, but the effects on traffic and rankings show up over the following weeks. The difference between a clean migration and one that costs positions on Google almost always comes down to three things: DNS preparation, redirects, and proper use of Search Console. Here's the sequence, in the order it should be executed.

Rule one: distinguish between the two cases

The procedure changes depending on what you're moving:

• Same domain, new hosting: the URLs don't change. You don't need any 301 redirects and you won't use the Change of Address tool in Search Console. Just copy the data and update the DNS.
• New domain (with or without hosting change): here you need both 301 redirects and, after the migration, the Change of Address tool. Does this apply to switches from HTTP to HTTPS or between www and non-www? No: for these specific cases Google recommends using canonical tagging and/or redirects without using the Change of Address tool, because they remain variations of the same domain.

DNS: lower the TTL before, not after

The step most often overlooked is the first one. If the A record has a high TTL (24 hours, which is 86,400 seconds) and you change it on migration day, some visitors will keep seeing the old server for hours. The standard practice, confirmed by several industry technical guides, is:

1. 24–48 hours before cutover, lower the TTL of the A/AAAA records (and MX if mail is also moving) to a value between 300 and 600 seconds.
2. Wait for the old TTL to expire everywhere: if it was 86,400 before, you must wait at least 24 hours after lowering it before proceeding with the actual change.
3. On cutover day, change the record to the new IP: with a low TTL, actual propagation typically takes anywhere from a few minutes to a few hours, rather than the typical 24–48 hours of a high TTL.
4. Keep the old server reachable for 48–72 hours after the change, as a safety net: if something doesn't work on the new hosting, you can switch back in minutes by putting the old IP back.
5. Once you've verified that everything is running on the new hosting, restore the TTL to its normal value (typically 3,600 or 14,400 seconds), to avoid unnecessarily overloading resolvers with continuous queries.

What to copy, in order

Before touching the DNS, the new site must already be ready and tested, accessible via a temporary URL or via hosts file:

1. Full backup of files and database from the old hosting, and verify the backup can actually be restored (not just that it exists).
2. Files: the wp-content folder (themes, plugins, uploads), plus any configuration files (wp-config.php adapted to the new database credentials).
3. Database: export and import on the new server, with the same versions of PHP and MySQL/MariaDB or higher.
4. Update URLs in the database, if the domain is changing. With WP-CLI the command is:

wp search-replace 'http://olddomain.it' 'https://newdomain.it' --skip-columns=guid

The --skip-columns=guid option avoids touching the GUID field of content, which by WordPress convention shouldn't be modified after publication. Before running it on the live site, it's worth doing a trial run with --dry-run, which executes the operation and shows the report without writing anything to the database.

5. Test the new site (via hosts file or temporary URL) before moving the DNS: pages, forms, shopping cart if you have an e-commerce, email sending.

301 redirects: when they're mandatory

If the domain is changing, the 301 redirect from the old to the new homepage is the bare minimum, but the most solid practice is to map old URLs one-to-one to their corresponding new ones, not just the homepage. Without redirects, anyone arriving from an old link or from an indexed page will find a 404 error and that page's authority signal will be lost, not transferred.

If the change is only hosting with the same domain and URL structure, no redirect is needed: for both visitors and search engines nothing changes, only the server responding changes.

Search Console: when and how to use Change of Address

The Change of Address tool in Search Console is used exclusively for transfers between different domains or subdomains. It should only be used after you've moved and redirected the site.

Google lists four cases where the tool shouldn't be used: switching from HTTP to HTTPS, moving some pages within the same site, switching between www and non-www on the same domain, and changing hosting or CDN with the same visible URLs.

Before starting the procedure, both properties (old and new domain) must be verified in Search Console with the same Google account, at domain level and not individual path level. Google also recommends submitting the request for all verified variants of the old domain: subdomains and www/non-www versions, even those not actively used, before sending the requests.

Once the procedure is started, it remains visible in Search Console for 180 days, a period during which redirects must be kept active: Google recommends maintaining redirects for at least 180 days, or longer if you don't notice traffic dropping from the old URLs. After that period, if the old domain is still reachable, Google stops treating it as linked to the new one. A practical consequence: don't deactivate the old domain too soon, even if everything looks "fine" after just a few days.

Another useful pointer for those managing multiple domains: Google advises against chaining multiple migrations in sequence (domain A to B, then immediately B to C), because the system doesn't allow you to start a second Change of Address request from site B until the first one has concluded, and traffic risks getting lost along the chain.

After cutover: what to check

• Submit the new XML sitemap from Search Console: this helps Google discover the new URLs faster, and at that point the old sitemap can be removed.
• Check in the "Coverage" or "Pages" report in Search Console that the new domain is actually being crawled and indexed.
• Monitor impressions and clicks on both the old and new properties for a few weeks: a temporary drop in the first few weeks is normal, Google itself indicates that for medium-sized sites it can take several weeks before the new URLs gradually replace the old ones in search results.
• Verify that the Search Console property verification file or meta tag is present on the new site as well, otherwise you'll lose property verification.

Once you've done this, the migration is technically complete. The rest is waiting: Google needs time to recrawl every old and new URL at least once before considering the migration finished, and there's no visible "completed" status anywhere: the only reliable signal is traffic stabilising on the new domain.