Key takeaways
- A website migration is any change to the URLs, platform, domain or template structure of a live site, which is why a redesign that keeps every URL intact is not a migration and a domain change with no visual change is.
- You can transfer a website to another provider without losing rankings, because rankings attach to URLs rather than to hosting, and the risk comes from whatever changes alongside the move rather than from the move itself.
- To migrate a website to another platform, map every URL that has ranked, earned a link or received organic traffic to a single new destination with one permanent redirect each, then prove content parity page by page before launch day.
- Redirecting old URLs to the homepage loses almost all of their link value, because search engines read a redirect to an unrelated page as a soft error and drop the association with the original.
- Migrating one variable at a time is what makes a problem diagnosable; a combined replatform, redesign and domain change on the same weekend removes your ability to attribute any traffic movement to a cause.
An SEO migration is any change to a live site's URLs, platform, domain or templates, and the whole job is making it invisible in the traffic graph. Done properly nobody outside the team notices it happened. Done badly it removes years of accumulated rankings over a single weekend, and the recovery costs more than the project saved. This SEO migration checklist covers the pre-launch, launch-day and post-launch work in the order it should actually happen.
The engineering underneath it is ordinary technical SEO services work. What makes a migration different is that every mistake lands at once, on a deadline, with no gradual signal to warn you.
Decide what is changing, and whether you can transfer it in stages
Write down precisely which variables move: the domain, the platform, the URL structure, the templates, the content, or several together. The number of simultaneous changes decides how hard recovery will be, because you cannot isolate a cause you changed alongside four other things.
This is also the answer to whether you can transfer a website to another provider. You can. Positions attach to URLs and to the pages behind them, not to the hosting account, so a straight host-to-host move with identical URLs and identical markup is close to risk-free. What creates risk is everything that usually gets bundled with it: a new platform that generates different URLs, a new theme that drops structured data, a CDN that changes response headers, or a staging build that ships with crawling blocked. Separate the hosting move from the rebuild and you convert one dangerous release into two safe ones.
Then capture a baseline before anything changes. Export current positions for your top-priority keyword set, organic traffic by URL for the last twelve months, the full backlink profile, and index coverage from Search Console. Date it and store it somewhere outside the site you are about to change. Every post-launch check compares against this, and without it you cannot tell recovery from decline.
Map every URL to exactly one destination
This is the step the whole project turns on, and the rest of the SEO migration checklist assumes it is finished and owned. Build a sheet with one row per existing URL and one destination for each.
| Column | What goes in it | Why it matters |
|---|---|---|
| Old URL | Every URL that ranked, earned a link, or received organic traffic in recent years | Navigation-only lists miss the pages that carry the most value |
| New URL | The closest topical equivalent on the new site | A near match keeps the association; a loose one breaks it |
| Redirect type | A permanent redirect, every time | Temporary redirects and meta refreshes do not transfer value |
| Hops | Must be one | Each additional hop leaks value and adds latency |
| Owner | A named person | Unassigned rows are the ones that ship broken |
Any URL without a close equivalent goes to the most relevant category or parent page, never to the homepage. A homepage redirect reads as a soft error and the original page's history is dropped rather than transferred. Test hop length across the whole map, not a sample, because chains form silently when an old redirect rule is still live underneath the new one.
Prove content parity before launch, not after
For every mapped pair, confirm the new page covers the same ground at equal or greater depth. Thin destinations are the most common cause of loss after a clean-looking migration, because a redirect into a shallower page is a statement that the topic is now less well covered.
Carry over the elements that carry meaning: title tags, headings, meta descriptions, canonical tags, image alt text and structured data. Small copy corrections are fine. Wholesale rewrites are not, because they make it impossible to separate a mapping fault from a content change afterwards. Migrate first, prove stability against the baseline, then improve the content in a later release once you know the move itself was clean. Where a rebuild and a content overhaul are both genuinely needed, website redesign SEO sets out how to split them.
Run the technical checks against staging
Crawl staging and crawl production, then compare the two crawls rather than eyeballing either one. You are looking for pages present in one and absent in the other, internal links that broke, status codes that changed, and response headers that shifted.
- Confirm staging blocks all crawling, and confirm the production robots file will allow what it needs the moment it goes live. Shipping a staging block to production is the single most expensive typo in this project.
- Verify canonical tags, hreflang if you run more than one language or region, and pagination markup across every template, not just the homepage.
- Test rendering on staging with the URL Inspection tool. If the build depends on client-side rendering, run the JavaScript SEO checks before launch rather than after.
- Compare Core Web Vitals between the old build and the new one. A launch build that is slower than what it replaced can cost positions even when the redirect map is perfect.
Launch day, in order
Everything earlier in this SEO migration checklist exists to make launch day uneventful. Go live in a low-traffic window so a fault affects the fewest people and you have hours rather than minutes to react.
- Crawl production immediately and check the redirect map is behaving as designed.
- Hand-follow a set of your highest-value old URLs and confirm each lands on the intended page in one hop.
- Submit the new sitemap in Search Console and request indexing on the most important pages.
- Confirm analytics and tag management are firing. A broken tag on launch day blinds you at the exact moment you need data most.
- Watch for impressions appearing against the new URLs in Search Console. That is the first sign the move is being processed rather than ignored.
Keep the old sitemap accessible for a while rather than deleting it. It gives crawlers a fast route to the URLs that need reprocessing.
The first month after launch
Some short-term movement is normal while redirects are reprocessed and new URLs are re-crawled. What matters is the shape of the curve, not the first week's number. A dip that begins recovering is the expected pattern. A dip that keeps deepening, or one concentrated in a single template rather than spread across the site, is a fault rather than a settling period.
Check three things weekly against the baseline. Positions on the priority keyword set, with any material drop traced back through the map to a specific URL. Not-found reports, watching for clusters that share a path pattern, since a pattern means a rule rather than an oversight. Index coverage, watching whether the new URL count is climbing toward the old one. Log analysis is usually the fastest diagnosis available, because it shows exactly which URLs crawlers are requesting and what they are getting back. Almost every post-migration loss traces to one of three causes: a gap in the map, a redirect chain, or a parity failure, and all three are fixable once named.
What stays on the list after recovery
The project is not finished when traffic returns to baseline. Update external links pointing at old URLs wherever you have the relationship to ask, because a direct link is worth more than a redirected one. Fix internal references outside the site: ad landing pages, email templates, documentation, printed material, partner listings.
Leave the redirect map in place indefinitely. Removing redirects after a year is a self-inflicted second migration, since links and bookmarks keep sending people to old URLs for far longer than that. Then run the broader technical health pass on the new build, because a migration is the moment a site inherits a fresh set of template-level issues along with the new templates.
Related terms
You may see this topic described with related searches like cms migration seo, seo migration plan, seo migration strategy, seo site migration best practices, and site migration checklist seo. Those phrases are useful when they clarify what the reader needs next, but they should still point back to one clear plan.
Related searches such as site migration seo checklist, site migration without losing seo, and website migration seo are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Frequently asked questions
What is a website migration?
A website migration is any change to a live site that alters its URLs, platform, domain or template structure. Changing hosting alone is the mildest version. Changing platform, restructuring URLs and moving domain together is the most severe, because search engines have to reprocess the whole address space at once. The defining feature is that existing URLs stop working in their old form, which is why redirect mapping sits at the centre of every migration plan.
Can you move a website to another provider without losing rankings?
Yes. Positions attach to URLs and to the pages behind them rather than to a hosting account, so moving a site between providers while keeping identical URLs and identical markup carries very little risk. Problems appear when other changes travel with the move, such as a new platform generating different URL patterns or a new theme dropping structured data. Keep the transfer separate from any rebuild and check the crawl before and after.
How do I migrate a website to another platform?
Map every URL that has ranked, earned a link or received organic traffic to a single new destination, each with one permanent redirect and no chains. Confirm the destination covers the same topic at equal depth, and carry over titles, headings, canonical tags, alt text and structured data. Crawl staging against production before launch, go live in a low-traffic window, then check positions, not-found reports and index coverage weekly against a baseline you captured beforehand.
Can I transfer my website to another provider?
Yes, but the move needs a controlled handoff: files, database, DNS, redirects, analytics, forms, and backups all need to be checked. The risk is not the transfer itself; it is missing one of the pieces that makes the site work.
How much does a website migration service cost?
Website migration cost is driven by URL count, platform complexity, redirect mapping, content movement, analytics setup, launch QA, and monitoring after go-live. The cheapest quote is rarely the best value if it skips the checks that protect traffic.
How do I migrate my website?
Migrate the site by inventorying every current URL, mapping redirects, preserving important content and metadata, testing the new templates, launching in a controlled window, and monitoring crawl, indexation, rankings, and conversions after the switch.