A website migration protects SEO performance only when the technical work happens before launch, not after. That means a full pre-migration audit and URL inventory, a one-to-one redirect map using 301 redirects, staging environments locked with noindex until launch, and updated sitemaps and Search Console settings on day one. Even with careful execution, some ranking fluctuation is normal. Research on domain migrations found the median recovery time is around 304 days, so the real goal of a technical SEO checklist is not zero movement, it is a fast, predictable recovery instead of a permanent loss.
A company relaunches its website on a new platform on a Friday afternoon. The design team is thrilled. Monday morning, organic traffic is down 40 percent, half the blog is returning 404 errors, and nobody can find the redirect map because it was never actually finished before launch. This happens more often than most marketing teams expect, and it is almost never the design or the new platform that causes it. It is the technical SEO work that got skipped or rushed in the days before launch.
This checklist walks through what actually needs to happen before, during, and after a website migration to protect rankings and traffic. It covers the pre-migration audit, redirect strategy, launch day verification, the most common technical causes of traffic loss, and how long recovery realistically takes when something does slip through.
What Needs to Happen Before You Touch the New Site?
Most of the SEO risk in a migration is created or prevented before launch day. Search Engine Land’s site migration guide notes that a large share of migration SEO work happens in the pre-migration phase, not after. That starts with a full crawl of the existing site to build a complete URL inventory, along with a benchmark of current rankings, organic traffic, backlink profile, and page-level performance so any post-launch drop can be measured against a real baseline rather than a guess.
Search Engine Journal makes a similar point from the other direction: the article’s review of migrations that went wrong found that collecting and benchmarking data before the move happens is what makes it possible to diagnose exactly what caused a traffic drop afterward, instead of guessing across a dozen possible causes at once.
How Should Redirects Be Mapped and Implemented?
Redirects are where most migrations succeed or fail. Google’s own migration documentation recommends server-side permanent redirects, 301 or 308 status codes, wherever technically possible, and specifically warns against redirecting large numbers of unrelated URLs to the homepage, since this pattern can trigger soft 404 errors that quietly tell Google the destination page does not actually match. Google also advises keeping redirects live for at least one year to give ranking signals time to fully transfer to the new URLs.
The mapping itself should be one-to-one wherever possible: old URL to the single new URL that most closely matches its content, not a bulk redirect to a category page or the homepage. Google also cautions against redirect chains longer than three to five hops, since each additional hop adds crawl overhead and risk of the chain breaking somewhere in the middle.
The median time for organic traffic to recover to pre-migration levels, based on SALT.agency’s analysis of over 1,000 domain migrations. Only about 23 percent recovered within 90 days, which is why redirect accuracy and pre-launch preparation matter more than a fast timeline once the site is already live.
What Should Happen on Launch Day Itself?
Launch day is a verification exercise, not a build step. According to Search Engine Land’s checklist, the first thing to confirm is that any staging-environment noindex tags were removed from production, since a single forgotten noindex directive can deindex an entire site within days. From there, the checklist is straightforward: confirm 301 status codes are actually live on every redirect rather than returning 302s or errors, test for broken internal links, verify analytics and tag manager events are firing correctly, and submit the updated XML sitemap through Google Search Console.
For domain-level migrations specifically, Google’s documentation recommends using the Change of Address tool in Search Console, though it notes this step is unnecessary for HTTP-to-HTTPS migrations on the same domain. Both the old and new properties should be verified in Search Console before launch so this transition can happen without a gap in data.
Technical Migration Checklist by Phase
| Phase | Key Actions |
|---|---|
| Pre-migration | Full crawl and URL inventory, ranking and traffic benchmarks, one-to-one redirect map, staging with noindex |
| Launch day | Remove noindex, verify 301s live, test links, confirm analytics, submit sitemap, use Change of Address if needed |
| First 30 days | Daily Search Console monitoring, resolve indexation errors, fix redirect chains, watch Core Web Vitals |
| 30 to 90 days | Track ranking recovery by query and page, resolve remaining crawl issues, begin backlink outreach for unfixed external links |
A line chart plotting organic traffic against days since launch would typically show a dip in the first two to four weeks as Google recrawls and reindexes the new URLs, followed by either a steady climb back to baseline for well-executed migrations, or a flat, extended trough for migrations with unresolved redirect or indexation errors. The shape of that recovery curve, not just its depth, is usually the clearest signal of whether the technical checklist was actually followed.
Why Do Most Migrations Lose More Traffic Than They Should?
Search Engine Journal’s review of failed migrations points to a consistent set of causes, and almost none of them are exotic. Canonical tags pointing to the wrong pages, robots.txt files accidentally blocking crawlers, metadata lost during a database transfer, broken internal links still pointing at the old domain, and redirect chains that break somewhere in the middle all show up repeatedly. Page speed regressions on the new server or CDN, and JavaScript rendering issues that prevent Google from seeing content at all, round out the list.
In our experience, the common thread across nearly all of these is that they are caught in a QA pass before launch far more cheaply than they are fixed after traffic has already dropped. A migration checklist is only as useful as the discipline to actually run it before the new site goes live, not as a document reviewed after something has already gone wrong.
Migrations rarely fail because of one big mistake. They fail because five small technical issues went unchecked at the same time.
How Do You Know If a Migration Recovered Successfully?
A migration should be measured against the pre-launch benchmark, not against a general sense of how things feel. A reasonable tracking framework includes organic sessions and revenue compared to the same period last year, indexation coverage in Search Console for the new URL set, ranking position for a fixed set of priority keywords, crawl errors and redirect chain counts, and Core Web Vitals scores on the new platform. Recovering all of these to baseline is the real definition of a successful migration, not simply the site being live without errors.
Given that SALT.agency’s research found a median recovery time of roughly 304 days across all migration types, with faster recovery typically tied to cleaner redirect mapping and fewer indexation errors, we generally recommend setting stakeholder expectations at the 90-day mark for a first real check-in, and treating anything before that as normal post-launch noise rather than a sign something is broken. Businesses considering a platform change alongside a broader rebuild often pair this checklist with a full website development engagement so the technical SEO work is planned in from the start rather than bolted on after the new site is already built.
Some short-term fluctuation is expected as Google recrawls and reindexes new URLs, typically over the first two to four weeks. A drop that persists well past that window, or one deeper than a small percentage, usually points to a specific technical issue such as broken redirects or blocked crawling rather than normal migration turbulence.
Use 301 redirects for permanent migrations. Google’s documentation specifically recommends server-side permanent redirects, 301 or 308 status codes, for site moves, since a 302 signals a temporary move and can delay or prevent ranking signals from transferring to the new URL.
Yes, if you are migrating to a new domain. Google’s guidance notes this tool is not required for HTTP-to-HTTPS migrations that stay on the same domain, but it is recommended for any true domain change to help Google process the transition faster.
Google recommends keeping redirects active for at least one year to fully transfer ranking signals to the new URLs. In our experience, many businesses keep key redirects live indefinitely, since the cost of maintaining them is low compared to the risk of losing equity from old backlinks that never get updated.
A noindex tag accidentally carried over from the staging environment into production is one of the most damaging and most common mistakes, since it can cause Google to remove pages from its index within days of launch. Verifying this is one of the first checks that should happen immediately after going live.
Research from SALT.agency, based on over 1,000 domain migrations, found a median recovery time of approximately 304 days, though only about 23 percent recovered within 90 days. Recovery speed is closely tied to how accurately the redirect map and technical checklist were executed before and at launch.
Talk to Skyfield Digital about a technical SEO migration plan built to protect your rankings and traffic before launch day, not after.
Sources
| Google Search Central | Site Moves and Migrations |
| Search Engine Land | Site Migration SEO Guide: Preserve Rankings and Traffic |
| Search Engine Journal | Site Migration Issues: 11 Potential Reasons Traffic Dropped |
| SALT.agency | Only 27% of Domain Migrations Recover in 90 Days |
