WordPress · Host migration, redesign, staging site and 301 redirects
Moving a WordPress site to a new host shouldn't change its rankings. Redesigning it can. Doing both on the same day means that if traffic drops, you can't tell which one caused it.
The rule is to separate them: migrate the host first with nothing else changed, confirm with a crawl that the new server delivers an identical site, then launch the redesign as its own project with its own before and after audit.
Baseline crawl→Move host→Crawl and compare→Launch redesign→Crawl and compare
What can go wrong
Risk climbs with every variable you change at once. Each migration type has its own usual failures.
| Migration type | Risk level | What usually breaks |
|---|---|---|
| Host move, same domain, same design | Low | Staging settings copied over, mixed content, cache serving old pages, server errors under load |
| Redesign, same host | Medium to high | Changed URLs without redirects, lost content and headings, new theme drops schema or canonicals, page builder hides text in JavaScript |
| Host move plus redesign | High | Everything above, with no way to attribute the cause |
| Domain change | Highest | All of the above, plus every URL needs a cross-domain 301 and a Search Console change of address |
What travels with the staging database
Discourage search enginesThe checkbox in Settings > Reading, stored in the databaseSitewide noindex
Staging URLsLinks, images and page builder data still pointing at the staging domainBroken links
Staging robots.txtA Disallow: / written by a plugin or left in the fileBlocked crawl
Maintenance pluginPassword protection or noindex left switched onHidden site
Settings that travel with the database are the most common silent failure. Nothing looks wrong to visitors.
Before migrating
- Crawl the live site and save the audit. This is the baseline every later crawl compares against: URL count, status codes, titles, H1s, canonicals, word counts and schema.
- Save the old URL list. Combine the crawl, Search Console's top pages and backlink targets. See WordPress permalink SEO for the method.
- Build a URL map for a redesign. List old URL to new URL for every page that changes or is removed. Removed pages redirect to the closest equivalent, not the homepage.
- Crawl staging with the same settings. Turn on JavaScript Rendering if the new design uses a page builder. Compare against the baseline for content parity: missing pages, dropped headings, shorter word counts, missing schema.
- Lower DNS TTL a day or two before a host move. The switch propagates faster. Propagation still takes hours for some visitors, so keep the old host running until traffic stops reaching it.
- Record versions. Note theme, plugin and PHP versions on both hosts, so differences can be traced later.
After launch: what to check
Run these within the first hour, then crawl the full site and compare against the baseline in Audit Comparison.
| Check | Expected result |
|---|---|
| Settings > Reading | Discourage search engines unticked |
| Meta robots, sitewide | No noindex on pages indexable in the baseline |
| robots.txt | Production version, no Disallow: / |
| Staging URLs | Zero matches for the staging domain, via Custom Source Search |
| HTTPS | Valid certificate, HTTP to HTTPS 301, no mixed content |
| Old URL list | Every URL returns 200 (host move) or one 301 (redesign) |
| Indexable URL count | Matches the baseline within a few percent |
| Titles, H1s, canonicals | Match the baseline, or the new values you planned |
| Word count per template | No large drops versus the baseline |
| Server response | No 5xx or 429 errors under crawl load |
| Tracking | GA4 and pixels fire once on the new host, via Tracking & Pixel Audit |
Downloadable checklistWordPress migration SEO checklist
0 of 21 done
How to identify the scope
Where the failures sit tells you what caused them.
Every URL fails the same waySetting or serverEvery URL noindexed or served on HTTP points to a setting or server config.
One template failsThemePosts lose headings or schema while pages look fine: the new theme is the cause.
Scattered URLs failURL map or slugsCheck the URL map and individual slugs for gaps.
Host move onlyAny differenceNothing was supposed to change, so any difference from the baseline is a bug.
How to validate the fix
- Fix settings first, then purge every cache, including the old host's CDN if it's still in front.
- Recrawl and compare against the pre-migration baseline.
- Host move target: zero differences in status, indexability, titles and word counts.
- Redesign target: every difference is one you planned in the URL map.
- Submit the sitemap and use URL Inspection on your top pages in Search Console.
- Schedule weekly Scheduled SEO Audits for the first month, and watch the Not found and Excluded reports in Search Console.
0Unplanned differences from the baseline
0Staging URLs, noindex tags or Disallow rules in production
4 weeksOf weekly audits and Search Console monitoring
Common mistakes
- Migrating and redesigning on the same day. If rankings drop, you can't attribute the cause.
- Taking the staging database live without checking settings. Discourage search engines and the staging robots.txt arrive with it.
- Search-replacing URLs with a plain SQL query. Serialized data in widgets and page builders breaks. Use WP-CLI search-replace or a migration plugin such as All-in-One WP Migration that handles serialization.
- Turning off the old host on launch day. Visitors on slow DNS still reach it for hours, and some ISPs take longer.
- Assuming the migration plugin moved everything. Server-level redirects in .htaccess or Nginx config, and host-level redirects, often don't transfer.
- Comparing only the homepage. A theme change can strip content from posts while the homepage looks better than ever.
- Rebuilding rankings "from scratch" by launching a new site. You throw away every backlink and indexed URL. Migrate with redirects instead.
Related resources
Match the baseline
A migration is safe when the crawl after launch matches the crawl before it, except for changes you planned. Save the baseline, check what the database carried over, and compare. Most migration disasters are a single setting nobody looked at.