The decision is made. The rebuild is funded, the platform is picked, and the launch date is on a slide. What almost nobody has assigned is the one job that decides whether the new site keeps the traffic the old one earned. That job is a checklist, and it starts before anyone writes code.
Gate 1: The Baseline You Cannot Reconstruct Later
Most migration post-mortems stall on the same question: down from what? In 2025, Search Engine Journal published a study of 892 domain migrations and found an average recovery time of 523 days[1]. The teams at the fast end of that range all did the same unglamorous thing first. They measured.
The same dataset recorded its shortest recoveries at 19, 22, 23, and 33 days. At the other end, 17% of the 892 domains had still not returned to their previous traffic level after 1,000 days. Same search engine, same year, same measurement method. The variable is not luck and it is not Google’s mood. It is whether anybody owned the checklist.
Whether a rebuild is the wrong answer is a separate argument, and often it is. Once the answer is yes, the job changes shape entirely. It stops being a decision and becomes an inventory problem.
The baseline has three parts. Crawl the current site and export every indexable URL, not the sitemap’s version of the site. Pull what is actually ranking and what is actually driving sessions, page by page. Snapshot both before anyone touches a URL. Pull the traffic side from GA4 and Search Console together, because those two will not agree. You want that disagreement recorded up front, not discovered during a post-launch argument.
That gap between the sitemap’s version of a site and the ranking version is not hypothetical. In 2026, Sistrix published its IndexWatch 2025 analysis of Google UK visibility and recorded an 85.10% year-on-year drop at NerdWallet after a URL restructure[2]. The submitted XML sitemap listed 255 URLs. At the time, 12,828 URLs were actively ranking. One case study is not a rate, but it names the failure precisely: the inventory described a site that did not exist.
A Series B B2B SaaS team I worked with went into a replatform with no baseline beyond a screenshot of a GA4 overview. Three months after launch, organic sessions were down and the entire debate was whether the migration caused it or a seasonal dip did. Nobody could settle it. There was no page-level “before,” so six weeks went into arguing rather than fixing. This is mise en place applied to a migration: the prep is boring, and skipping it costs more than doing it. The audit that produced the decision is not the same artifact as the baseline. One justifies the work. The other is the only evidence you will ever have that the work went well.
Redirect Mapping Is One to One, or It Is Not a Map
A redirect map pairs every old URL with the single best new URL. In 2026, Sistrix recorded a 98.40% year-on-year visibility loss at BioMed Central after its old URLs were 301-redirected to a single Springer brand page instead of mapped individually[3]. Many to one is not a map. It is a deletion with extra steps.
Every URL from the crawl runs through the same four branches. If an equivalent page exists on the new site, 301 to it. If the closest match is near-equivalent rather than identical, 301 to that. If nothing equivalent exists but the page carried links or traffic, 301 to the most relevant parent, a category or hub page, never the homepage. If the page is genuinely retired with no links and no traffic, let it return 404 or 410 on purpose and write down that you meant it.
The status code matters more than most migration tickets acknowledge. Google’s documentation is explicit. A permanent redirect (301 or 308) tells the indexing pipeline that the target should be canonical[4]. A temporary redirect (302, 303, 307) gets followed by Googlebot, but is not used as that signal. The same page ranks redirect methods by reliability: server-side first, meta refresh second, JavaScript last and only when the other two are impossible. A migration shipped on JavaScript redirects is betting on the slowest mechanism Google documents.
A canonical tag is not a substitute for a redirect, and this one costs teams real traffic. Google’s canonicalization guidance lists redirects as a strong signal and rel=canonical as a strong signal, with sitemap inclusion as a weak one[5]. Both are strong, so where does the swap fail? A canonical only works while the old URL still resolves and still serves that tag. On a replatform, the old URL usually stops existing, which makes the canonical unreachable and therefore not a signal at all. A canonical also never moves the visitor. A redirect does both jobs at once.
Then there is how long the map lives. Google says to keep redirects for as long as possible, generally at least one year, and to consider keeping them indefinitely from a user’s perspective[6]. The same guidance notes that Googlebot follows up to 10 hops in a chain, but that chains should ideally be no more than three and fewer than five. That ceiling is easier to hit than it sounds. A redirect map layered on top of last year’s redirect map, which was layered on the 2019 migration, is how a site ends up with four-hop chains nobody remembers creating.
A Series C team’s agency handled this the fast way. The migration ticket said “make sure nothing 404s,” so every retired URL got pointed at the homepage. Technically nothing 404’d. Practically, 300 pages of accumulated relevance were told they were now the homepage, and the homepage did not rank for any of the things they used to. The ticket was closed as complete.
What Has to Be True on Staging Before You Cut Over?
Four things fail on staging often enough to deserve their own gate. A noindex left on from the staging environment. Canonical tags still pointing at staging hostnames. Schema and metadata that quietly did not carry over. Internal links across the new site still pointing at the old URLs.
The noindex is the famous one, and it still happens. A Series B team launched with the staging robots meta tag intact and found it on day four, by a person manually checking, not by an alert. Four days of a fully deindexed site during the exact window when Google most wants to recrawl. A pre-launch gate is a list somebody signs off on by name, not a feeling that things look fine.
Schema and metadata carryover gets skipped because it feels cosmetic. It is not. If the old product and article templates emitted structured data that earned rich results, that markup has to exist on the new templates before launch, not in a follow-up sprint. Rebuilding the design without rebuilding the structural layer that earned those results is how a site launches looking better and performing worse.
Internal links are the quiet one. If the new site’s navigation and body links still point at old URLs, every internal click fires a redirect. The map then becomes impossible to audit, because it is doing double duty. Crawl the staging build and check that zero internal links resolve through a 301. The whole staging pass is the same regression-proof discipline any website change deserves, applied to a change that touches every URL at once.
One item almost every checklist omits: DNS. Google’s guidance for a hosting change advises lowering the TTL to a conservative low value, a few hours for example, at least a week before the move[7]. DNS caches then refresh faster when the switch happens. It costs one ticket, a week early, and shortens the window where half the visitors are still hitting the old server.
Launch Day Is a Server-Health Problem, Not a Crawl-Budget Problem
Crawl budget is the most over-prescribed item on migration checklists. Google scopes crawl-budget management to sites with 1 million or more unique pages changing weekly, or 10,000 or more pages with content changing daily[8]. A 200-page B2B SaaS marketing site is nowhere near that. The real lever is server health.
The same Google documentation says what actually throttles crawling: 5xx responses, HTTP 429s, or rising latency, and the crawl limit goes down and Google crawls less. It also notes that site-wide events like site moves may trigger an increase in crawl demand, because Google needs to reprocess the content under the new URLs. Read those two together and launch day gets clearer. It is the exact moment Google wants to crawl more, and the exact moment a brand-new stack is most likely to serve errors or slow down under load. So watch the 5xx rate, the 429 count, and response times, in whatever the host gives you. That is the dashboard for launch day, not a crawl-budget spreadsheet.
The other launch-day items are short. Submit the new sitemap in Search Console so Google learns the new URLs[9]. Spot-check the top 50 URLs from the baseline against the live redirect map and confirm each returns a 301, not a 302 and not a JavaScript hop. Confirm robots.txt is not blocking anything it should not. Confirm the analytics and tag container actually fire on the new templates, because a migration that breaks measurement makes every question in the next 90 days unanswerable.
Set expectations in the same channel where people will panic. Google’s own site-move documentation says a small to medium-sized website can take a few weeks for most pages to move. It also says visibility in Search may fluctuate temporarily during the move, and that this is normal. Post that sentence before launch, not on day three when somebody screenshots a dip.
Why Do Some Migrations Recover in 19 Days and Others in 523?
Because one team can tell, in week one, whether the migration is working. In the same 2025 Search Engine Journal dataset, the shortest recorded recoveries were 19, 22, 23, and 33 days. Another 17% of the 892 domains had not recovered after 1,000 days. The difference is measurement and a rollback nobody had to debate.
The tracking has a shape. At day 30, check index coverage on the new URLs, read the 404 log for anything that used to rank, and re-check the top 50 baseline URLs for position movement. At day 60, compare organic sessions and conversions by landing page against the baseline, not against last month. At day 90, give the honest verdict, because by then the fluctuation Google describes has had time to settle and what is left is signal.
The rollback plan is where most teams get caught, and it has to exist before launch. Treat it as a *pre-authorized decision*: a written trigger, a numeric threshold, a named person allowed to pull it, and a defined action. What the threshold is matters less than that it was agreed while everyone was calm. After launch, every number is contested and every decision needs a meeting. A rollback that requires a meeting is not a rollback.
Redirect retention belongs in this window too. If the domain itself changed and you used Google’s Change of Address tool, the signal window runs 180 days from the start of the migration in Search Console[10]. Google asks you to maintain the redirects for at least that long, and longer if Google Search still sends traffic to them. That 180 days is the tool’s own signal window, not permission to drop the map at six months. The broader retention guidance, at least a year, still stands. And the tool is for a domain change: not for a same-domain restructure, and, Google says, not needed for a move from HTTP to HTTPS.
None of these five gates is clever. Baseline, map, staging, launch, and 90 days of tracking with a rollback already agreed. Every one of them is a list, and every one of them needs a name next to it before the launch date is set. The teams that recovered in a month were not luckier than the ones still waiting at 1,000 days. They just refused to cut over until somebody had signed each gate off.
Sources
- Search Engine Journal (Dan Taylor), How Long Should An SEO Migration Take? – Published January 8 2025, data collected October 22 2024; n=892 domain migrations across SaaS, legal, finance, ecommerce and retail; recovery measured as days for the new domain to match the old domain’s estimated organic traffic; average 523 days; shortest recorded 19, 22, 23 and 33 days; 17% not recovered after 1,000 days; 25 migrations (2.8%) excluded as inconclusive ↩
- Sistrix, IndexWatch 2025: Visibility Losers in Google UK Search – Published January 28 2026, updated February 18 2026; Sistrix Visibility Index, year-on-year, Google UK; NerdWallet lost 85.10% of visibility after a URL restructure, with a submitted XML sitemap listing 255 URLs while 12,828 URLs were actively ranking; single case study, not a rate ↩
- Sistrix, IndexWatch 2025: Visibility Losers in Google UK Search – Same analysis; BioMed Central lost 98.40% of Google UK visibility year-on-year after its URLs were 301-redirected to a single Springer brand page instead of mapped one to one, with little to no SEO authority transferred; single case study, not a rate ↩
- Google Search Central, Redirects and Google Search – Google’s own documentation; with permanent redirects (301, 308) the indexing pipeline uses the redirect as a signal that the target should be canonical, while temporary redirects (302, 303, 307) are followed but not used as that signal; reliability order is server-side, then meta refresh, then JavaScript ↩
- Google Search Central, How to Specify a Canonical URL with rel=canonical and Other Methods – Google’s own canonicalization documentation; ranks redirects as a strong signal and rel=canonical as a strong signal, with sitemap inclusion listed as a weak signal ↩
- Google Search Central, Site Moves with URL Changes – Google’s own documentation; recommends HTTP permanent redirects such as 301 and 308, advises keeping redirects as long as possible, generally at least 1 year, and considering keeping them indefinitely from a user perspective; Googlebot follows up to 10 hops in a chain, but chains should ideally be no more than 3 and fewer than 5 ↩
- Google Search Central, Changing Your Web Hosting and SEO – Google’s own documentation for a site move without URL changes; advises lowering DNS TTL to a conservative low value, for example a few hours, at least a week in advance of the move so DNS caches refresh faster ↩
- Google Search Central, Large Site Owner’s Guide to Managing Your Crawl Budget – Google’s own documentation; scopes crawl-budget management to large sites of 1 million or more unique pages changing weekly, or medium and larger sites of 10,000 or more unique pages changing daily, described by Google as a rough estimate rather than exact thresholds; 5xx responses, HTTP 429, or rising latency cause the crawl limit to go down; site-wide events like site moves may trigger an increase in crawl demand ↩
- Google Search Central, Site Moves with URL Changes – Same documentation; instructs submitting the new sitemap in Search Console so Google learns the new URLs; states that a small to medium-sized website can take a few weeks for most pages to move, larger sites longer, and that visibility in Search may fluctuate temporarily during the move, which is normal ↩
- Google Search Console Help, Change of Address Tool – Google’s own Search Console documentation; migration signals continue for 180 days after the migration starts in Search Console, and Google asks site owners to maintain the redirects for at least 180 days, longer if Google Search still sends traffic to them; the tool applies to a domain change and is not needed for a move from HTTP to HTTPS ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
It varies far more than most teams expect. In 2025, Search Engine Journal studied 892 domain migrations and found an average of 523 days to match the old domain's organic traffic. The same dataset recorded recoveries in 19, 22, 23, and 33 days. Execution quality drives that spread.
Redirect every URL carrying links, traffic, or rankings, mapped one to one. Pages that are genuinely retired with no equity can return 404 or 410 on purpose. What you cannot do is bulk-redirect the remainder to the homepage. In 2026, Sistrix recorded a 98.40% visibility loss at one publisher that did exactly that.
No. Google's canonicalization guidance lists both redirects and rel=canonical as strong signals, but a canonical only works while the old URL still resolves and still serves the tag. On a replatform, that URL usually stops existing. A canonical also never moves the visitor. A redirect does both jobs.
Google's site-move documentation says to keep redirects as long as possible, generally at least one year, and suggests keeping them indefinitely from a user's perspective. If you used the Change of Address tool, Google asks for at least 180 days, which is that tool's signal window rather than the retention rule.
Only if the domain itself changes. The tool exists for domain moves, not same-domain URL restructures, and Google states it is not needed for a move from HTTP to HTTPS. For a replatform on the same domain, a complete redirect map and a resubmitted sitemap are the working signals.
