Faut-il vraiment abandonner la commande site: pour compter vos pages indexées ?

Pourquoi la commande site: est-elle jugée peu fiable par Google ?

La commande site:domain.com interroge un index allégé, pas la base complète utilisée pour le classement. Google maintient plusieurs couches d'index : un index principal pour le ranking, des index secondaires pour les requêtes de diagnostic, et des caches temporaires. Quand vous tapez 'site:', vous accédez à une approximation qui peut inclure des URLs jamais crawlées récemment ou exclure des pages pourtant bien indexées.

Le chiffre affiché fluctue d'un jour à l'autre sans que votre site ait changé. Vous pouvez observer des écarts de 20 à 40% entre deux requêtes espacées de quelques heures. Ces variations ne reflètent pas une indexation ou désindexation réelle, mais des artefacts techniques liés au système de requête utilisé pour cette commande.

Quelle méthode Google recommande-t-il à la place ?

Google pousse l'usage du rapport d'indexation dans la Search Console, qui s'appuie sur les logs de crawl réels. Ce rapport distingue les URLs découvertes, explorées, indexées, et celles exclues avec le motif précis (canonicale alternative, robots.txt, noindex). Vous avez accès à un historique et à des graphiques qui montrent l'évolution dans le temps.

Le sitemap joue un rôle de référentiel : il liste ce que vous souhaitez indexer. En croisant ce fichier avec les données de la Search Console, vous détectez les URLs soumises mais non indexées. C'est ce delta qui compte pour le diagnostic, pas un chiffre absolu sorti d'une commande approximative.

Quelles sont les limites réelles de cette déclaration ?

Google ne précise pas à quel point la commande site: est inexacte. On parle d'un ordre de grandeur flou, mais pour un site de 50 000 pages, une marge d'erreur de 30% représente 15 000 URLs fantômes ou manquantes. Cette déclaration reste donc vague sur le seuil à partir duquel l'écart devient critique.

Autre point : la Search Console elle-même n'est pas infaillible. Elle échantillonne certaines données et peut ignorer des URLs crawlées par Googlebot mais non remontées dans l'interface. L'idée que le sitemap soit la source de vérité suppose qu'il soit parfaitement à jour, ce qui n'est pas toujours le cas sur des sites dynamiques où le catalogue change chaque heure.

• La commande site: interroge un index secondaire, pas celui utilisé pour le ranking
• Les écarts observés peuvent atteindre 20 à 40% d'un jour à l'autre sans changement réel
• Le rapport Search Console s'appuie sur les logs de crawl et offre un historique détaillé
• Le sitemap sert de référentiel pour identifier les URLs soumises mais non indexées
• La Search Console elle-même échantillonne certaines données et peut manquer des URLs crawlées

Cette déclaration est-elle cohérente avec les observations terrain ?

Sur le terrain, les SEO constatent depuis des années que site: donne des chiffres erratiques. Un site e-commerce de 80 000 fiches produits affiche tantôt 65 000 résultats, tantôt 92 000, sans modification technique. Cette instabilité est documentée dans les forums depuis au moins 2015, bien avant que Google ne le confirme officiellement.

Ce qui est nouveau, c'est que Google assume publiquement cette limitation. Pendant longtemps, la commande site: était la seule méthode accessible avant la démocratisation de la Search Console. Beaucoup d'audits SEO reposent encore sur ce chiffre, ce qui pose un problème de fiabilité des diagnostics. [A vérifier] : Google n'explique pas si cette imprécision est un bug qu'il pourrait corriger ou une caractéristique intrinsèque du système.

Dans quels cas la commande site: reste-t-elle utile malgré tout ?

La commande site: garde un intérêt pour des vérifications rapides et qualitatives. Si vous lancez un nouveau domaine et que site: renvoie zéro résultat après trois semaines, vous savez qu'il y a un problème bloquant d'indexation (robots.txt, noindex global, pénalité). C'est un signal d'alerte, pas un tableau de bord.

Elle reste aussi utile pour inspecter des sous-sections précises : site:domain.com/blog/ vous montre rapidement si cette partie du site est présente dans l'index. Vous pouvez combiner avec des filtres temporels (inurl:, intitle:) pour traquer des pages spécifiques. Mais dès qu'il s'agit de compter précisément ou de suivre une évolution dans le temps, cette méthode devient contre-productive.

Quelles précautions prendre avec le rapport Search Console ?

La Search Console affiche parfois des URLs que Google a découvertes mais jamais crawlées. Elles apparaissent dans le rapport avec le statut 'Découverte, actuellement non indexée', ce qui gonfle artificiellement le nombre d'URLs connues. Si vous avez 100 000 URLs découvertes dont 60 000 jamais explorées, votre sitemap ne vous aidera pas à comprendre pourquoi.

Le rapport peut aussi exclure des URLs crawlées via des chemins non standards (redirections 302 temporaires qui durent des mois, paramètres dynamiques non déclarés). Croiser Search Console et logs serveur reste la méthode la plus fiable, mais peu d'équipes ont l'infrastructure pour traiter des dizaines de millions de lignes de logs chaque jour. [A vérifier] : Google ne donne aucune garantie sur la complétude des données remontées dans la Search Console.

Comment auditer efficacement l'indexation de votre site ?

Mettez en place un process de réconciliation hebdomadaire entre trois sources : votre sitemap XML (liste des URLs que vous souhaitez indexer), le rapport Search Console (URLs effectivement indexées selon Google), et vos logs serveur (URLs réellement crawlées par Googlebot). Exportez ces trois jeux de données et croisez-les dans un tableur ou un script Python.

Identifiez les URLs présentes dans le sitemap mais absentes de l'index. C'est votre priorité : elles devraient être indexées mais ne le sont pas. Le rapport Search Console vous donnera le motif d'exclusion (noindex, canonicale, contenu dupliqué, crawl bloqué). Ne perdez plus de temps à comparer des chiffres approximatifs issus de site:.

Quelles erreurs éviter lors du suivi d'indexation ?

Ne vous fiez jamais à un chiffre unique. Un client vous dit 'J'ai perdu 10 000 pages indexées en une semaine' en se basant sur site: ? Vérifiez d'abord si ces pages sont dans le sitemap et si la Search Console confirme une désindexation réelle. Souvent, il s'agit d'une fluctuation de l'estimation site:, pas d'un problème technique.

Évitez aussi de soumettre massivement des URLs via l'outil d'inspection. Google limite à quelques dizaines de soumissions par jour, et cette méthode ne règle pas les problèmes structurels (temps de chargement, contenu pauvre, canonicalisation défectueuse). Si 5 000 pages ne sont pas indexées, c'est rarement un oubli de Googlebot, c'est un signal qualité.

Quels outils utiliser pour automatiser ce suivi ?

Connectez l'API Search Console à un outil de reporting (Google Sheets, Data Studio, ou une solution custom). Configurez des alertes automatiques si le taux d'indexation descend sous un seuil critique (par exemple, moins de 85% des URLs du sitemap indexées). Certains outils comme Oncrawl, Botify ou Screaming Frog permettent de croiser crawl + logs + Search Console dans une interface unifiée.

Pour les très gros sites (plusieurs millions d'URLs), investissez dans une stack de traitement de logs (ELK, BigQuery). Vous pourrez identifier les sections du site que Googlebot ignore systématiquement et ajuster votre architecture de liens internes en conséquence. Cette approche demande une expertise technique avancée, et beaucoup d'entreprises choisissent de déléguer cette partie à une agence SEO spécialisée pour obtenir un accompagnement personnalisé et des recommandations sur-mesure.

• Exporter chaque semaine le rapport d'indexation Search Console et le croiser avec le sitemap
• Identifier les URLs présentes dans le sitemap mais marquées 'Exclues' dans la Search Console
• Analyser les motifs d'exclusion et corriger les problèmes techniques (canonicalisation, noindex, redirections)
• Mettre en place des alertes automatiques si le taux d'indexation chute sous 85%
• Croiser les données Search Console avec les logs serveur pour détecter les URLs crawlées mais non indexées
• Ne plus utiliser la commande site: pour des décisions stratégiques ou des rapports clients