A migration done well goes unnoticed: the site is faster, the host is better and search rankings barely flicker. Done poorly, the same migration can drop traffic 30-60% in a week, take months to recover, and leave the business explaining quarterly numbers it did not expect to have to explain.
Moving the files and database is rarely the hard part. The damage comes from a dozen small details before, during and after the cutover. This is a practical checklist of the non-negotiables that protect SEO equity through a host change, a redesign, a platform change, or any combination of the three.
What "breaking SEO" means
A migration can damage SEO in three ways:
Lost URL equity. When URLs change without proper redirects, the search engines and AI engines that used to know where your content lived send visitors to dead pages. Rankings drop, backlinks point to 404s, and you end up re-earning what you'd already paid for.
Crawl confusion. Stale sitemaps, conflicting canonicals, orphaned old pages or wrong robots directives can each leave engines unsure about the structure of the site, and they rank it less confidently while they work it out.
Lost authority signals. These include backlinks pointing at old URLs, structured data that no longer matches the page content, and social and review profile links that go nowhere. Each one is a small loss, but together they weaken the site's authority.
All three are preventable with careful, detailed work.
Before the migration
1. Crawl the existing site completely. Use a real crawler (Screaming Frog or similar) and export every URL the site has, including paginated lists, archive pages, tag pages, attachment URLs, redirected URLs, and 404s. This is your authoritative URL inventory. Nothing else in the process works without it.
2. Capture the current rankings and Search Console data. Export the queries each top page ranks for, plus current impressions and clicks. You need a baseline to compare against, both for early warning if something goes wrong and for proof that recovery is on track.
3. Identify every backlink target. Backlinks point to specific URLs. If those URLs change, the backlinks need to find their way through redirects. A backlink audit from any of the major tools (Ahrefs, Majestic, etc.) gives you the list of URLs that other sites are sending traffic to. Every one of those needs a redirect plan.
4. Plan URL changes carefully. The best migration changes zero URLs. The second best changes a few URLs deliberately and redirects each one. The worst restructures the entire URL pattern and hopes for the best.
If you are restructuring, do it for a real reason (consolidation, cleaner taxonomy, removing legacy patterns), not because the new platform "encourages" different URLs.
5. Build the redirect map. One row per old URL: old URL, new URL, redirect type (301 permanent for SEO-critical, 302 only if you mean "this is temporary"). Test this in a spreadsheet before you implement it.
6. Stage the new site fully. Build the new site on a staging environment that is blocked from search engines (proper robots.txt or basic auth). Test pages, forms, schema and performance before the cutover, because finding broken pages on cutover day is too late.
During the cutover
7. Lower the DNS TTL in advance. A day or two before cutover, drop the DNS TTL on the domain to 300 seconds. This means when you flip DNS to the new host, propagation happens in minutes instead of hours. That shortens the window where visitors still reach the old server, and lets you roll back faster if you need to.
8. Cut over at low-traffic time. What counts as low traffic depends on your audience. For B2B it's usually late evening or the weekend, and for consumer sites it varies, so look at your analytics and pick the actual valley.
9. Implement the redirects at the server level. Not via a plugin if you can help it. Server-level redirects are faster, more reliable, and harder to accidentally break with a future plugin update. WordPress hosts usually let you ship a list of redirects directly to the web server config.
10. Verify the new site is crawlable. Check robots.txt is correct. Check that staging-era "noindex" meta tags are removed. Check that the canonical tags point at the production URLs. Between them, these cause the most common single mistake: a site that was "noindexed" for the staging period and forgotten about in the cutover rush.
11. Submit the new sitemap. Generate a fresh sitemap.xml from the new site, submit it through Search Console and notify Bing as well. That tells them to look at the site again.
12. Update llms.txt if you use one. The AI crawler equivalent of a sitemap. Make sure it points at the new URLs, not the old ones. See our guide to modern SEO and AI search for context on llms.txt.
After the cutover
13. Crawl the new site immediately. Same crawler tool, same URL list. Walk through every old URL and confirm it either resolves on the new site or redirects properly. Anything that returns a 404 needs a redirect added that day.
14. Spot-check the top 50 pages by traffic. Visit each one yourself and confirm the content renders, images load, forms and internal links work, and the page title and meta description are correct. You're looking for anything the crawler missed.
15. Verify analytics and Search Console. Both should be tracking the new site within 24 hours. If they aren't, fix that before anything else, because you need to see what's happening.
16. Watch Search Console for spike in crawl errors. The week after migration is when Google notices missed redirects, broken canonicals, and changed schema. Watch the coverage report daily and fix issues as they appear.
17. Re-validate structured data. The schema you carefully implemented on the old site may not have made it cleanly to the new one. Run the key pages through Google's Rich Results Test and Schema.org's validator. Fix anything broken straight away. The schema markup worth adding in 2026 goes into more detail.
18. Manually check AI citations. Ask the assistants the questions your buyers ask. Confirm that any citations point at your new URLs, or at least redirect cleanly. AI assistants often cache content for a while, so this can take weeks to fully update, but it's still worth watching the trend.
The non-negotiables
If you remember nothing else from this list:
One. Every old URL needs a destination, with no exceptions: either the same URL on the new site or a clean 301 redirect to the closest equivalent.
Two. The new site must be crawlable from the moment DNS flips. Staging "noindex" must be off.
Three. The redirect implementation has to be server-level, not plugin-level, for anything you want to be durable.
Four. Check everything rather than assuming it worked: crawl the new site, walk through the top pages and watch Search Console.
Five. If something goes wrong, you need a rollback plan. Lowered DNS TTL gives you the option. Knowing in advance what triggers a rollback (more than X% of top pages broken? sudden ranking drop in the first 24 hours?) keeps the decision rational instead of panicked.
Why most migrations go wrong anyway
Because the work above is detailed and unglamorous, and because the cost of skipping it is invisible until weeks later. The team that should have done the redirect mapping was too busy with the design. The agency that ran the cutover did not own the SEO. The hosting company helped move files but did not know about the rankings being protected. Nobody was on the hook for "the site still ranks the day after we move."
Most of the damage happens in the gap between "the site is technically live" and "the site has retained its SEO equity through the move." The fix is organizational: one team or one person has to own the whole move from start to finish, instead of each party owning only their piece.
How we handle this
Our migrations are run by the same person who will host the site afterward. We build the redirect map before the cutover rather than patching it together after, fully stage the new site, and cut over at a low-traffic time with a lowered DNS TTL. The post-cutover crawl and Search Console watch are included in the job.
This is covered under our website migration service, and it is included in every Design & Development project we ship. Tell us about your situation if you are planning a move and want to discuss it before you commit. We would rather have the conversation early than rescue a botched migration later.
