How long does it really take for a domain change to propagate in Google?

What does "properly configured" really mean in this context?

Google remains deliberately vague about what constitutes a correct configuration. In practice, this means permanent 301 redirects of all old URLs to the new ones, an update of the XML sitemap, and using the change of address tool in Search Console.

The devil is in the details. A single broken redirect chain, a forgotten sitemap on the old domain, or internal links still pointing to the old structure can significantly lengthen the process. Google does not crawl all your pages simultaneously; it follows the priority signals you give it.

Why does Google say "a few hours to a day" when reality often differs?

This estimate corresponds to the minimal technical delay under ideal conditions. It assumes a site with excellent crawl budget, a clear architecture, and perfect redirect implementation. For a well-structured 50-page site with a solid history, this delay is achievable.

On the other hand, for a site with thousands of pages and a limited crawl budget, this estimate becomes unrealistic. Google will discover and index new URLs gradually, at its usual crawl rate. Deep or poorly linked pages will take longer to be processed.

Is the propagation instantaneous for all pages simultaneously?

No, and this is a crucial point that the statement avoids. Google crawls in successive waves. It usually starts with your homepage and the most strategic URLs, then gradually moves down the site's architecture according to the priorities it assigns.

In practical terms, your homepage may appear with the new URL within 24 hours, while level 4 or 5 pages in your hierarchy may remain under the old domain for several days or even weeks in the results. This phenomenon is normal but rarely clearly explained by Google.

• A domain migration requires complete 301 redirects from each URL to its exact equivalent on the new domain
• The propagation delay directly depends on your usual crawl frequency and crawl budget
• Strategic pages switch over first, followed gradually by deeper pages
• The change of address tool in Search Console accelerates the process but does not make it instantaneous
• Keeping the old domain active with redirects for at least 6 months is essential

Is this estimate consistent with real-world observations?

To be honest, Google's estimate is optimistic at best, misleading at worst. In 15 years of practice, I have rarely seen a migration wrap up in less than a week, even with perfect technical implementation. The actual delay tends to range from 2 weeks to 2 months for complete propagation.

Mueller's statement omits critical factors. A site with a strong history and high authority will indeed be prioritized. However, an average site crawled once a week will naturally take longer. Google does not say this, but the reality of crawl budget physically limits the speed of propagation.

In what cases does this delay absolutely not apply?

For sites with tens of thousands of pages, forget this estimate. The progressive crawl means that some sections will take weeks to switch. I’ve seen e-commerce migrations take 3 months before 95% of the URLs are transferred into the index.

Another problematic case involves sites with a history of penalties or low quality. Google will never say this officially, but a site that has had problems will be scrutinized more closely during a migration. The engine checks that you are not trying to reset your history by changing domains. [To be verified]

What should you do when the propagation stalls beyond the announced delay?

First check: are all your redirects in place, without intermediate chains? A tool like Screaming Frog can quickly detect 404 errors or redirect chains that hinder Google. Also, make sure your new domain’s XML sitemap is submitted and error-free.

If everything is technically correct but propagation is stalled, push the issue with Google. Retrieve from Search Console your list of top-performing pages on the old domain and request their manual reindexing through the URL inspection tool on the new domain. This prompts Google to recrawl them first.

What should you set up concretely before launching the migration?

Start with a complete crawl of your current site to identify all URLs to be redirected. Don’t rely solely on your sitemap; some orphaned or old pages may still receive traffic. Export the complete list and create an accurate mapping table between old and new URLs.

Next, configure your new domain with an identical or improved architecture, never degraded. If you take this opportunity to restructure, ensure that each old URL points to its exact semantic equivalent, not to a generic page. Mass redirects to the homepage are a classic mistake that ruins your SEO.

How can you speed up propagation once the migration is launched?

Immediately use the change of address tool in Search Console. This tool explicitly signals to Google your intention to migrate and speeds up processing. Submit the XML sitemap of the new domain simultaneously and request reindexing of strategic pages via the inspection tool.

Update all your controllable external links: social profiles, quality directories, partner links. Every direct link to the new domain avoids a redirect and speeds up discovery by Google. Contact the sites that link to you the most to modify their outbound links.

What critical errors can ruin a domain migration?

The most common error remains redirect chains. Old domain to temporary to new domain: Google hates this and may simply give up on crawling. Ensure that each old URL redirects in one single 301 jump to the new one.

Second pitfall: leaving internal links pointing to the old domain on the new site. This creates conflicting signals and forces Google to unnecessarily follow redirects. Update all internal links, including images, to point directly to the new domain.

• Crawl the old site entirely and create a URL mapping table
• Implement direct permanent 301 redirects without intermediate chains
• Use the change of address tool in Search Console starting on day one
• Submit the XML sitemap of the new domain and check for errors
• Update all internal links to point directly to the new domain
• Force manual reindexing of strategic pages through the URL inspection tool