A migration done well is invisible. The site is faster, the host is better, the team behind it is sharper, 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.
The difference is rarely the technical lift of moving files and a database. It is the dozen small details around what you do before, during, and after the cutover. This piece is the practical checklist — 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" actually 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. Recovery requires re-earning what was already paid for.
Crawl confusion. Stale sitemaps, conflicting canonicals, orphaned old pages, wrong robots directives — any of these can make engines temporarily uncertain about the structure of the site. Uncertain engines rank less confidently.
Lost authority signals. Backlinks pointing at old URLs, structured data that no longer matches the page content, social and review profile URLs that go nowhere. Each one is a small loss; together they meaningfully soften the site's authority.
All three are preventable. The work is detailed but not mysterious.
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. Export 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 really 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, performance — all of it — before the cutover. Discovering broken pages on the day of cutover 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. Less stale-traffic window, faster ability to roll back if needed.
8. Cut over at low-traffic time. Whatever "low traffic" means for your audience. For B2B, that is usually late evening or weekend. For consumer, it varies. 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. These three together are the most common single mistake — a site that has been "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. Notify Bing as well. This signals "look at me 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 what modern SEO actually looks like now 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 personally. Confirm content rendered, images loaded, forms work, internal links work, the page title and meta description are correct. Catch what the crawler did not.
15. Verify analytics and Search Console. Both should be tracking the new site within 24 hours. If they are not, fix that before fixing anything else — you need visibility into what is 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. 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. Anything broken, fix immediately. Schema markup that actually matters in 2026 covers the underlying discipline.
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 watching the trend is the right discipline.
The non-negotiables
If you remember nothing else from this list:
One. Every old URL needs a destination — either the same URL on the new site, or a clean 301 redirect to the closest equivalent. No exceptions.
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. You have to verify, not assume. Crawl the new site, walk the top pages, 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."
That gap — the gap between "the site is technically live" and "the site has retained its SEO equity through the move" — is where most of the damage happens. The fix is not technical. It is making sure one team or one person is accountable for the whole arc, not just their piece.
How we handle this
Our migrations are run by the same person who will host the site afterward. The redirect map is built before the cutover, not patched together after. The new site is fully staged. The cutover happens at low-traffic time with lowered DNS TTL. The post-cutover crawl and Search Console watch is part of the engagement, not an extra.
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.
