An SEO migration checklist exists because the damage happens in the quiet parts. The new server works, the pages load, and three weeks later impressions are down and nobody can say which step broke. Most of the time it’s one of four failures that produced no error message at all.
We’ve moved sites between hosts since 2017, including one project at Tianwenseo that relocated 49 export websites from managed hosting to a self-built VPS in a single operation. Same domains, different server, and the total cost fell by more than half. The checklist below is what we’d hand to someone doing it themselves.
First, name the migration you’re doing
The risk isn’t the same for every move, and the plan should say which one this is.
- Host move. Same domain, same URLs, different server. Lowest risk. The main dangers are DNS timing, mail, and a cache that serves the old site.
- Domain change. Highest risk. Every URL changes, every backlink points elsewhere, and you need a change-of-address step in Search Console.
- Platform change. A CMS rebuild usually changes URL patterns and page templates at the same time, even when the visible design is copied.
- URL structure change. Adding or removing a language prefix, switching http to https, changing trailing slashes or directory depth. This is a migration even when the content and the server stay put.
Name the category before you start, because it decides which of the later steps are mandatory and which are just good practice.
Before the move: freeze, inventory, and take a baseline
The baseline is the part people skip and later regret, because without it you can’t tell whether the migration caused a change. Export the last 16 months from Search Console: queries, pages, countries, devices. Save the current sitemap and count the URLs. Record which pages hold the impressions you care about.
Take a full backup of files and database, and write down the environment while it’s still in front of you — PHP version, database version, active plugins and their versions, cron entries, and the mail configuration. That list is what you’ll rebuild against, and it’s also the rollback reference.
Then freeze publishing for 24 hours before cutover. A post published mid-migration can end up in the old database only, which is a confusing way to lose an afternoon.
One more item belongs here. If the site keeps backup copies inside the web root, clear them before the move. We once found 36 .backup files inside a theme directory, all publicly downloadable. A migration is the natural moment to stop republishing them to the new server.
The URL map is the migration
If the domain changes or URL patterns change, the map from old URL to new URL is the single most important artifact. Build it as a spreadsheet before cutover, with one row per old URL and exactly one destination. Keep the same URL wherever you can — the safest URL after a migration is the one that never changed.
Where a URL must change, redirect it with a single 301 to its final destination. Chains of two or three redirects waste crawl budget and dilute the signal. Avoid 302 for permanent moves. Watch the details that break mappings: trailing slashes, uppercase letters, query strings on paginated and filtered URLs, and the www versus non-www form. Google’s guidance on moving a site and changing URLs is short and worth reading once before you build the map.
Test redirects after the cache is purged, not before
This is the trap that has burned us. A cached 200 is not a passing test. If a server cache or CDN is still holding the old response, every check passes and every user still sees the old site. Purge the server cache and the CDN first, then test.
Test with a script over the whole list, not by spot-checking five URLs. Follow redirects and record the final URL and the status at each hop. The output you want is a table where every old URL resolves to its intended destination in one hop, with a 200 at the end.
The four things that break silently
None of these raises an error. Each one has cost us or a client real time.
1. A frozen sitemap file
Some SEO plugins cache the sitemap as a file and serve that file until a timer expires. The admin screen shows a green checkmark while the file it serves is weeks old, and the filename often contains no “sitemap” string, so searching the filesystem for it finds nothing. The fix is to delete the cached files after the move so they rebuild, then confirm in Search Console that the sitemap’s download date and URL count are current. Don’t trust the plugin’s checkmark; read the timestamp.
2. Cron that didn’t come along
A host move rebuilds the environment, and scheduled tasks are easy to leave behind. If WP-Cron is disabled in the config and no system cron replaces it, scheduled posts sit in “Scheduled” forever and nothing warns you. The probe is simple: schedule a test post one minute out and watch whether it publishes.
3. Canonical and hreflang left pointing at the old URLs
On a multilingual site, these tags are generated, and a generated tag can regenerate old URLs after a move. Check each language version for a self-referencing canonical and reciprocal hreflang tags, and confirm every URL in the set returns 200. Google’s documentation on multi-regional sites is specific about how the tags must pair up.
4. Forms and mail that stop arriving
DNS and mail records are part of the migration even when the website is fine. On a domain change, a form can submit successfully and deliver nowhere. On a host move, a domain-bound anti-spam key can stop validating if the site is reached through a different address. We audited a site whose form had been failing silently for 12 days because its reCAPTCHA key was registered to another domain; 207 paid clicks landed on it before anyone noticed. Send a real test message from a phone and confirm it arrives, both after the move and again a week later.
DNS, TTL and certificates
Lower the DNS TTL to a few minutes at least 24 hours before cutover, so the switch propagates quickly. Keep the old server running and online until the new one is verified and the TTL has fully expired. Don’t cancel old hosting on cutover day; it’s your rollback.
Issue the TLS certificate on the new host before the switch, and decide up front which canonical hostname you’ll use. Then make the other forms redirect to it. Server location is a weak signal for international targeting — Google looks at the domain, the hreflang setup and the content itself, and a CDN makes location close to irrelevant — so don’t let a hosting region decision override the migration plan.
After the move: verify in a fixed order
The order below catches the failures in the sequence they’d otherwise surprise you.
- HTTP status on every mapped URL. One hop, correct destination, 200 at the end.
- robots.txt and the sitemap. Confirm both load, then check the sitemap’s real download date in Search Console and resubmit it.
- Canonical and hreflang. Self-referencing, reciprocal, all 200.
- Rendering. JavaScript, CSS and fonts load; the mobile layout matches what you had.
- Speed. Measure time to first byte on the pages that matter. A host move is the cheapest moment to fix an infrastructure fault — on one of our sites, adding a cache layer to nginx took TTFB from 2.14 seconds to 0.067.
- Forms and mail. A test message from a phone, to the inbox, then check the spam folder as well.
- Change of address in Search Console, if the domain changed. This is a required step, not an optional one.
Expect a delayed recrawl, not an instant recovery
Crawl attention after a migration is uneven, and it depends on the site’s history as much as on the new server. On 22 September 2026 we inspected our own three properties on the same machine. One homepage had been crawled the previous day and pages published that week were already indexed. Another had last been crawled ten days earlier, its sitemap fourteen days earlier, and three new pages published in between were still unknown to Google — “Google can’t recognize this URL”. Same server, same day, different outcomes.
So don’t judge the migration on day three. Watch two numbers over four to six weeks: the indexed rate by URL type, and the crawl statistics for the new host. If the indexed rate is falling and the redirect map is clean, look for an accidental noindex, a robots.txt block, or a canonical pointing at the old domain before you change anything else. If it’s flat and the redirects resolve, the migration worked; the rest is the ordinary work of getting pages recrawled.
What actually breaks, and how soon do you see it?
The visible symptoms arrive in a fairly consistent order. Within hours, a redirect or a certificate problem shows up as an error. Within a day, mail and forms reveal themselves, usually because someone didn’t get a message. Within a week, the sitemap and canonical faults start to matter, as the crawl settles on the new host. Indexing and impression changes are the slowest, and they’re the ones people panic about first.
So the timeline is the checklist read backwards. Fix the things that break immediately, then watch the things that take weeks. If a redirect error and a small impression dip appear on the same morning, they’re not the same event, and treating them as one is how teams start changing three variables at once.
Rollback stays available for 30 days
Keep the old server, the old DNS records and the pre-migration database for at least a month. Write the rollback command before cutover, not after the first alarm. If the indexed rate collapses and the cause isn’t found within a day, pointing DNS back is a legitimate move, and having the path written down makes it a decision instead of a panic.
One sizing note for the new host, learned the hard way. A single-core, 1 GB machine running three WordPress sites was unstable not because of the site count but because PHP’s memory limit was set to 1024 MB — more than the machine had. Setting it to 256 MB and trimming PHP workers from 6 to 4 restored it. Individual PHP processes were measured at 80–124 MB each, so the arithmetic is easy to get wrong in the generous direction.
The checklist on one page
| Phase | Must do | Probe that proves it |
|---|---|---|
| Before | Baseline export, full backup, environment list, freeze publishing | Baseline file dated and stored off-server |
| Before | URL map, one destination per old URL | Every row has a target and a status |
| During | Lower TTL, issue certificate, keep old server live | Certificate valid on the new host before switch |
| After | Purge caches, then test redirects end to end | One-hop 301 to a final 200, scripted |
| After | Rebuild the sitemap cache, verify the real download date | Search Console shows today’s date and the right count |
| After | Canonical, hreflang, forms, mail | Test message received; tags self-reference |
| After | Change of address if the domain changed | Search Console confirms the submission |
| Four weeks | Indexed rate and crawl stats compared to baseline | Indexed rate by URL type is stable or rising |
The pattern behind every item is the same: configuration can look right while the site behaves wrong. Probe the result, not the setting. The indexing questions that surface after a move are the same ones we run on a normal site — see the 12-point audit and the indexing test on our own archive. Both are collected on the research index.
Questions about SEO migrations
What is the single most important migration step?
The URL map, if any URL changes. One row per old URL with exactly one final destination, built before cutover. Where you can keep the same URL, keep it. After that, purging caches before testing redirects is the step that catches the most silent failures.
Why did my rankings drop after moving hosts?
The usual causes are a redirect that resolves incorrectly, a sitemap still serving a cached file, a canonical or hreflang tag regenerated with the old URL, and a form or mail route that stopped delivering. Symptom timing helps: errors show in hours, mail within a day, indexing over weeks.
How long does it take to recover after a migration?
Crawl attention is uneven and depends on the site’s history. On the same server and the same day, we have seen one homepage crawled the day before with new pages indexed, and another last crawled ten days earlier with new pages still unknown to Google. Watch the indexed rate over four to six weeks.
Should I cancel the old hosting straight after cutover?
No. Keep the old server, the old DNS records and the pre-migration database for at least 30 days. If the indexed rate collapses and the cause is not found within a day, pointing DNS back is a legitimate move, and a written rollback path makes it a decision rather than a panic.
Who wrote this and how to check it. Written by Liu Yu, founder of Tianwenseo (Henan Tianwenseo Technology Co., Ltd., registered 3 May 2017; Zhengzhou, China; UTC+8). Tianwenseo has built and maintained WordPress export websites and run Google SEO for B2B manufacturers since 2017, and currently maintains dozens of client sites plus its own research domains. Every figure on this page is measured on a site we run, or linked to the source it came from. We don’t promise rankings or a number of enquiries. Contact: WhatsApp +86 135 2681 6415.