Can a domain migration really take place within 48 hours without losing rankings?

What exactly does "everything is set up correctly" mean?

Behind this vague phrase, Google expects a flawless technical setup: 301 redirects (never 302), precise URL mapping, an up-to-date XML sitemap submitted on Search Console for both domains, and preservation of URL structure when possible.

The devil is in the details. A misplaced canonical, a sitemap still pointing to the old domain, or a chain redirect (olddomain.com → www.olddomain.com → newdomain.com) can derail the process. And that’s where the problem lies: many migrations fail not due to a lack of redirects, but due to the accumulation of micro-errors.

Why only 1 to 2 days?

This timeframe corresponds to the priority recrawl time for a site that Googlebot visits frequently. If your crawl budget is high (news site, active e-commerce, high-traffic platform), bots will quickly discover the redirects and propagate the new signals.

But this timing only holds if the volume of pages is manageable and the new domain already has some authority (for example, intra-group migration). For a site with 50,000 URLs and a low crawl budget, this idyllic scenario is pure fiction.

What is actually transferred during a migration?

Google transfers ranking signals: backlinks, content quality history, accumulated domain authority. 301 redirects act as "tubes" that channel PageRank and trust.

What does NOT transfer instantly: click history (CTR in SERPs), user behavioral signals on the new domain, and sometimes crawl speed if the new server/hosting is less performant. These elements rebuild progressively.

• Permanent 301 redirects: mandatory page by page, no global redirect to the homepage
• Up-to-date XML sitemap: submitted on Search Console for both the old AND new domain
• Preservation of URL structure: ideally identical or very close
• Crawl monitoring: check server logs to ensure Googlebot is correctly following the redirects
• No robots.txt blocking on the old domain during the transition

Is this claim consistent with real-world observations?

Partially. The 1-2 day timeframe indeed corresponds to premium migrations: high crawl budget sites, domains of the same authority level, perfect redirects. But it is far from the norm. Across thousands of analyzed migrations, the median timeframe is more like 7 to 21 days for a full recovery of organic traffic.

Google communicates here about the optimal case, creating a distorted expectation. SEO practitioners know that a clean migration does not mean a quick migration — the recrawl time depends on factors largely beyond the site's control (historical crawl frequency, server capacity of the bot, algorithmic priority).

What nuances need to be added?

The statement overlooks several realities. First point: the announced timeframe only concerns technical indexing, not the recovery of traffic. A URL can be indexed under its new domain in 48 hours, but take 3 weeks to regain its initial position if user signals (CTR, time on site) plummet.

Second nuance: [To be verified] Google does not specify whether this timeframe applies uniformly to all types of sites. A 200-page blog has nothing in common with a marketplace with 500,000 product listings. Crawl budget literally explodes the promise of "2 days" once you exceed 10,000 URLs.

In what cases does this rule not apply?

It does not apply to low authority domains (new domains, expired domains reactivated without history). If the new domain starts from scratch, Googlebot will crawl it cautiously — which mechanically extends the transition timeframe.

It also fails on poorly prepared migrations: chain redirects, temporary duplicate content between old and new domains, contradictory canonicals, or worse, the old domain remains accessible without a redirect. In these setups, even a quick crawl is insufficient — Google enters a "confusion" phase and sometimes suspends the transfer of signals.

What should you do concretely before and during the migration?

First, map each URL of the old domain and map it to the new one. No global redirect to the homepage — that’s the guarantee of a 40 to 60% traffic loss. Use a spreadsheet or script to generate a clean 301 redirect file, line by line.

During the migration, set up both Search Console properties (old and new domain) and use the "Change of Address" tool in the settings. Submit the XML sitemap of the new domain immediately after the DNS switch. Monitor server logs to ensure Googlebot is correctly following the redirects — not just discovering them.

What mistakes should you absolutely avoid?

Never delete the old domain or cut hosting in the first 6 months. Redirects must remain active as long as Googlebot is still crawling the old domain — and that can take a long time if external backlinks still point to it.

Avoid also changing multiple parameters simultaneously: domain migration + redesign + CMS change = recipe for disaster. Googlebot won’t know what to prioritize, and you lose the ability to diagnose the origin of any potential traffic drop. One migration = one major change at a time.

How can you check that the migration is going smoothly?

Daily monitor three metrics in Search Console: number of indexed pages (old domain going down, new domain going up), coverage rate (errors 4xx/5xx on redirects), and organic impressions per domain. If after 7 days the old domain retains 80% of impressions, that’s a bad sign.

Use a crawl tool (Screaming Frog, Oncrawl) to verify that all redirects return a clean 301 code, no chains, no loops. Also, check that the canonical tags of the new domain point to themselves, never to the old domain. A single misaligned canonical can block the transfer of authority from an entire section.

• Map 100% of URLs before the switch (no default redirects to the homepage)
• Set up both Search Console properties and use the "Change of Address" tool
• Submit the XML sitemap of the new domain immediately after migration
• Maintain active 301 redirects for at least 12 months
• Monitor server logs to track Googlebot’s behavior
• Check for the absence of contradictory canonicals or redirect chains