Official statement
Other statements from this video 22 ▾
- 2:24 Faut-il abandonner les paramètres d'URL mobiles au profit du rel=canonical ?
- 3:50 L'outil de gestion des paramètres d'URL agit-il vraiment sur l'indexation ou seulement sur le crawl ?
- 3:54 Les paramètres d'URL bloquent-ils vraiment l'indexation de vos pages ?
- 5:24 Faut-il abandonner l'outil de paramètres d'URL au profit du rel=canonical pour gérer mobile et desktop ?
- 5:41 Pourquoi la requête site: affiche-t-elle des URL que Google ne classe pas dans les SERP ?
- 9:30 Faut-il encore soumettre manuellement ses pages à Google pour accélérer l'indexation ?
- 10:04 Faut-il bloquer ou laisser indexer vos pages à facettes ?
- 13:54 Est-ce que l'ancienneté d'un site protège vraiment son classement lors des mises à jour Google ?
- 22:59 Les sites non mobile-friendly sont-ils vraiment pénalisés par Google ?
- 23:01 Un site non mobile-friendly est-il vraiment pénalisé par Google ?
- 24:22 Combien de temps faut-il vraiment pour qu'une mise à jour mobile-friendly impacte vos positions ?
- 26:42 Le nombre de mots influence-t-il vraiment le classement SEO ?
- 33:38 Faut-il vraiment abandonner un domaine pénalisé ou peut-on s'en sortir autrement ?
- 41:54 Faut-il vraiment bloquer le spam de référence dans Google Analytics par pays ?
- 42:50 La vitesse mobile améliore-t-elle vraiment l'engagement au-delà du classement ?
- 43:28 La vitesse serveur impacte-t-elle vraiment le crawl budget de Google ?
- 44:58 La vitesse serveur impacte-t-elle vraiment le classement Google ou seulement le crawl ?
- 45:18 La vitesse mobile impacte-t-elle vraiment le classement Google ?
- 46:32 La vitesse de chargement pénalise-t-elle vraiment le classement des sites lents ?
- 47:36 La vitesse de chargement transforme-t-elle vraiment le comportement utilisateur ?
- 48:12 Comment Googlebot adapte-t-il automatiquement son crawl en cas d'erreurs serveur ?
- 52:48 Un site non mobile-friendly est-il vraiment pénalisé par Google ?
Google confirms that site: queries can display the old URLs of a migrated domain, even if the redirections are functioning correctly. This behavior does not reflect the actual state of indexing for the new pages. In practice, this data has no diagnostic value: one should monitor the new URLs via Search Console and ignore the site: results from the old domain during the migration.
What you need to understand
What does John Mueller's statement actually mean?
When you migrate a site to a new domain, the site: operator applied to the old domain can continue to display the old URLs in search results. Google specifies that this temporary presence does not mean that these pages are still actively indexed or that they appear in regular organic results.
The nuance is critical: the results from a site: query are not synonymous with active indexing. Google retains the domain's history and can display these URLs based on "understanding" that they have been moved, even if the engine is already redirecting users to the new domain for normal searches.
Why does Google maintain the visibility of old URLs?
The engine keeps track of old URLs to understand the continuity between the old and new domains. This memory helps Google transfer ranking signals: authority, backlinks, content history. Temporary retention in site: results is part of the internal consolidation process.
This does not reflect a malfunction or a delay in processing 301 redirects. It's simply an artifact of how Google manages diagnostic queries versus actual user queries. The two processing circuits are not synchronized in real-time during a migration.
How long can this situation last?
Google does not provide a specific timeframe. According to field observations, old URLs can remain visible in site: results for several weeks, or even a few months, depending on the size of the site and crawl frequency. The engine operates in waves: some pages disappear quickly, while others linger.
This variability depends on several factors: crawl budget, number of migrated pages, quality of redirects, speed of indexing for the new domain. A site with 10,000 pages does not clean up at the same rate as a site with 100 pages. Patience is required, but above all, the use of proper monitoring tools.
- The site: operator is not a reliable indicator of the actual indexing state during a migration
- Google temporarily retains the history of the old domain to transfer ranking signals
- The duration of visibility for old URLs varies depending on the site size and allocated crawl budget
- 301 redirects function correctly even if old URLs still appear in site:
- Only the data from Search Console for the new domain reflects the reality of indexing
SEO Expert opinion
Is this statement consistent with field observations?
Absolutely. This clarification from Mueller aligns with what experienced SEO practitioners have noticed for years during domain migrations. The gap between site: results and actual indexing is a classic issue that generates unnecessary anxiety among clients. Too many junior SEOs panic upon seeing the old domain still present in site: while organic traffic is already mostly flowing through the new domain.
The real question remains: Why doesn't Google improve the accuracy of this operator? If site: is not reliable during a migration (and Mueller confirms this here), what is its exact purpose? For a quick audit, certainly, but with a margin of error that many underestimate. This ambiguity fuels confusion between index presence and performance in results.
What data should actually be monitored during a migration?
The Search Console of the new domain remains the sole source of truth. Monitor the evolution of indexed pages in the coverage report, the volume of organic clicks, and queries generating impressions. If these metrics progress rapidly after the migration, the redirects are functioning correctly, regardless of what site: displays.
Also check the server logs: Googlebot's crawl should shift massively to the new domain in the first few weeks. If Googlebot continues to crawl the old domain intensively after 3-4 weeks, there is a structural problem (broken redirects, redirect chains, crawl traps). But these signals do not appear in site:, which remains a superficial indicator.
In what cases does this rule not apply?
If the old domain continues to display its old URLs in regular organic results (not site:, but during real keyword searches), there is a real problem. This means that Google has not processed the redirects or that the new domain is encountering an indexing obstacle: blocking robots.txt, accidental noindex, transferred algorithmic penalty.
[To check] Mueller does not specify how long this gap between site: and actual indexing can last before considering there is a malfunction. A 2-month delay seems excessive, but Google does not communicate any SLA. If after 90 days the old domain still dominates site: AND the organic results, investigate the redirects and the quality signals of the new domain.
Practical impact and recommendations
What should you do during a domain migration?
Forget the site: operator as a validation tool post-migration. Immediately configure the Search Console for the new domain and monitor the coverage report daily. Indexed pages should progress rapidly, ideally reaching 70-80% of the old site's volume within the first 4 weeks for a well-prepared site.
At the same time, submit a change of address via the Search Console of the old domain. This notification speeds up the transfer of ranking signals and reduces the migration timeframe. Without this step, Google may process the migration more slowly, as it must discover the redirects itself over time.
What mistakes should be absolutely avoided?
Do not panic if site: still displays the old domain after 2-3 weeks. This behavior is normal. Do not flood the old domain with multiple sitemap XML resubmissions thinking it will force Google to understand the migration: it is pointless and wastes crawl budget unnecessarily. The engine has already understood; it simply does not synchronize site: in real-time.
Avoid especially modifying 301 redirects mid-process out of fear that "it won't work." If the redirects are correctly set up and the new domain is crawlable, let time take its course. Changing the redirect structure during migration disrupts already transferred signals and prolongs the process. Validate once, then leave it alone.
How can you check if the migration is going smoothly?
Use the server logs to compare the volume of Googlebot's crawl between the old and new domains week by week. The crawl should gradually shift to the new domain. If after 3 weeks Googlebot still predominantly crawls the old domain, inspect the redirect chains and any 4xx/5xx errors on the new domain.
Also monitor the overall organic traffic: it should remain stable or experience a slight temporary decrease (10-15% maximum) before stabilizing. A drop of 40-50% indicates a structural problem: loss of content, broken redirects, cannibalization, or accidental deindexing. These signals can be found in Analytics and Search Console, not in site:.
- Set up Search Console for the new domain before migration
- Submit a change of address via the Search Console of the old domain
- Monitor the coverage report of the new domain daily
- Analyze server logs to verify the shift in Googlebot's crawl
- Ignore the results from the site: operator for at least 60 days post-migration
- Check that organic traffic remains stable or does not drop more than 15%
❓ Frequently Asked Questions
Dois-je m'inquiéter si l'ancien domaine apparaît encore dans site: après 3 semaines de migration ?
Combien de temps les anciennes URL peuvent-elles rester visibles dans site: après une migration ?
L'opérateur site: est-il fiable pour valider une migration de domaine ?
Que faire si l'ancien domaine apparaît dans les résultats organiques classiques après la migration ?
Le changement d'adresse dans la Search Console accélère-t-il vraiment la migration ?
🎥 From the same video 22
Other SEO insights extracted from this same Google Search Central video · duration 1h00 · published on 21/04/2015
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.