Google -bot, -sitemap, -index et -webmastertools
Les erreurs sont parfois une occasion d’apprendre, et le mois dernier j’ai fait une des plus belles bêtises qui soit, heureusement sur un site dont le propriétaire est à la fois mon client et mon mari… autrement dit, une bêtise interne.
En cours de développement de la nouvelle version de notre agence de voyage à Ouarzazate, j’ai chargé sur la version en production le robots.txt de la version de développement, avec un joli “Disallow:*”
La sanction a été très rapide mais je ne m’en suis pas aperçue tout de suite, car on était en pleine période de bouleversements dans les SERPS, et je voyais que les concurrents sur les requêtes plongeaient aussi, ou remontaient (mais pas moi). Ayant déjà vécu ce genre de bouleversements, je ne me suis pas inquiétée avant que le trafic chute brutalement, c’est-à-dire que Google ne m’envoyait plus qu’une dizaine de visiteurs, et avait désindexé presque toutes mes pages.
Coup d’adrénaline, coup d’oeil à la console GoogleWebmaster Tools, identification du problème, correction, et attente… nous étions le 5 février, et selon le graphique de passage du bot, j’avais envoyé le mauvais robots.txt le 23 janvier. Il avait donc eu tout le temps de faire son effet.
Et on voit maintenant sur la courbe de passage du bot un beau trou…

Passage du GoogleBot
Du 5 février à maintenant, j’ai plus que régulièrement interrogé mes stats, toutes mes stats, pour voir si j’arrivais peu à peu à remonter le problème. J’en ai tiré un certain nombre d’informations, sur le fonctionnement des “GoogleTools” et ce à quoi ils peuvent vraiment servir.
La structure du site et des sitemaps
La partie francophone du site est gérée de façon séparée, avec une géolocalisation.
Il y a trois sitemaps, pour des raisons pratiques : un pour le site proprement dit, un pour le blog, généré par un plugin, et un pour les fichiers .kml. Et donc un sitemap de sitemap, qui est le seul soumis dans GWT.
Au niveau du blog, il y a un problème identifié de duplicate content sur les pages de catégories, avec deux versions d’url : celle avec uniquement l’identifiant de la catégorie, et celle avec toute la hiérarchie des catégories mères. C’est un problème qui sera réglé dans la prochaine version. Les urls présentes dans le sitemap du blog sont les “mauvaises” url, avec toute la hiérarchie de catégorie, les “bonnes” urls sont dans le site, sous forme de liens internes. (cf. comment faire du duplicate content avec les permaliens)
Dans le blog, les urls “primaires” (celles avec l’appel du paramètre), et les archives calendaires sont interdites par le robots.txt (plus de détails sur le robots.txt d’un blog wordpress). Il y a donc environ une centaine de pages qui sont légitimement bloquées par le robots.txt
Le rythme de ré-indexation
La journée du 5 au 6 février a été assez longue et stressante.
En effet, Google ne charge le robots.txt qu’une fois toutes les 24 heures, et bien sûr il l’avait chargé une heure avant que je m’aperçoive du problème.
La désindexation a donc continué, pour s’arrêter seulement à partir du 7 février.
J’ai deux sources d’informations différentes :
- le tableau de bord de GWT, dont les informations sont fausses
- le résultat de la requête site:mondomaine, avec deux chiffres : le total des pages, et les pages sans les résultats complémentaires
Ces deux derniers chiffres sont très différents de ceux indiqués dans GWT.

Réindexation des pages (GWT vs. commande site)
Google a eu un comportement que je qualifierais de “glouton”. Il a d’abord rechargé dans l’index secondaire toutes les pages qu’il pouvait trouver, puis il a fait son tri, et a commencé à ré-indexer dans l’index primaire, à un rythme plus calme. Puis, au bout de deux semaines, il a supprimé – et il continue à le faire – les pages qu’il jugeait inutiles. A partir du 19-20 février, il diminue fortement le nombre de pages “inutiles”, tout en continuant à augmenter le nombre de pages indexées.

Nombre de pages par index
Et pendant ce temps, le nombre de pages indiquées comme indexées dans GWT est totalement décalé de ce qui ressort dans les SERPs.
La ré-indexation en détail
J’ai donc regardé en détail par sitemap, et exécuter tous les jours une requête avec Advanced Web Ranking pour savoir quelles étaient mes pages indexées.
Voici le tableau de synthèse des trois sitemaps :

Indexation des différents sitemap
Alors que le sitemap maitre est chargé tous les jours, les sitemaps qui montrent réellement les urls ne sont pas chargés tous les jours.
Or j’ai écrit quelques articles dans le blog, qui ont été immédiatement indexés.
C’est une confirmation : Google ne se base pas en priorité sur le sitemap pour crawler les pages d’un site et découvrir les nouveautés.
Alors que selon GWT, aucun de mes 104 fichiers kml ne sont indexés, en réalité, il y en a au moins 4 dans les résultats de la commande site.
Enfin, et c’est là ce que je trouve le plus intéressant, comment Google a-t-il traité mes pages de catégories en duplicate content ?
Quelques unes, assez rares, apparaissent toutes les deux dans les pages indexées.
Quand une seule url apparait, c’est en majorité l’url qui est linkée dans le site (l’url courte donc), or celle ci apparait le plus souvent dans des liens in-texte, ou dans des menus dont les ancres sont variées. A l’inverse, les urls présentes dans le sitemap (donc avec la hiérarchie de catégorie) ont dans le blog des ancres moins optimisées, et se trouvent dans des pavés beaucoup moins variés quant au contenu.
Le linking interne et externe est vraiment le premier critère d’indexation, puisque ce sont mes pages sans liens externes qui ont été les dernières à disparaître de l’index (en fait c’était les seules qui restaient quand je me suis aperçue du problème), et les pages les plus fortement linkées ont été les premières à revenir.
En revanche, le linking n’est pas un critère de positionnement. Une fois ré-indexées, des pages avec un très faible linking peuvent être beaucoup mieux positionnées que d’autres.
Google vous ment
De la même façon que les infos sur les sitemaps ne reflètent pas la réalité de l’index, les infos sur les liens, internes et externes, ne reflètent pas la réalité.
- Elles sont mises à jour avec beaucoup de retard : aujourd’hui les liens les plus récents selon GWT datent de fin janvier
- des liens manifestement identifiés par Google (apparaissant notamment dans les referrers dans Google Analytics) ne sont pas mentionnés dans GWT
Durant cette période, j’ai essayé de pousser Google en appuyant fortement sur les communiqués de presse. Or ces liens n’apparaissent pas, ou avec beaucoup de retard, alors que mon outil de suivi des backlinks (Advanced Link Manager) les détecte dès l’indexation du communiqué de presse.
Google est glouton, mais il est pudique. Il n’a manifestement pas envie qu’on puisse voir ce qu’il mange, et comment.
D’où l’intérêt d’outils autres pour suivre son positionnement et ses backlinks.
Google vous dit la vérité
En revanche, quand Google vous indique un problème sur votre site, il est réel.
C’est l’erreur que j’ai faite, de ne pas surveiller d’assez près les avertissements. J’en connaissais un certain nombre, qui allaient être réglés dans la prochaine version, et je me concentrais sur le développement.
Aujourd’hui, je surveille mes problèmes d’exploration quotidiennement.
Suivant de façon détaillée les pages indexées, j’ai constaté que même l’amélioration de la qualité des pages (indications sur les balises meta et title) avait un impact sur l’indexation de ces pages.
En conclusion, le sitemap n’est pas un outil qui vous permet de dire à Google ce qu’il doit faire, mais un outil qui permet à Google de vous indiquer ses propres problèmes.
La situation au bout de deux semaines
J’ai retrouvé – et assez rapidement – mes positions sur les requêtes les plus concurentielles.
Je n’ai pas retrouvé toutes mes positions sur les nombreuses petites requêtes qui constituaient ma longue traîne, et Google a encore une bonne centaine de mes pages à réindexer.
Le niveau de visites est presque revenu à la normale.

Évolution des pages et des visites
Pendant que j’étais au creux de la vague, le taux de rebond avait chuté fortement : moins de visites, mais plus qualifiées, manifestement.
Cet incident s’est produit en même temps qu’il y a eu les problèmes de crawl chez OVH. Si je vois chez moi quelle est la durée de retour à la normale, suite à un problème d’une durée à peu près similaire (mais avec un impact plus fort, à cause du robots.txt), je pense que les SERPS vont être encore instables sur une bonne semaine pour un certain nombre de requêtes où j’ai de nombreux concurrents chez OVH… ça tombe bien, ce sera à peu près le moment du lancement de la V4 !
Edit : suite à un commentaire, un lien vers un billet de Jean Véronis, sur les mystérieuses pages manquantes de l’index de Google. Il fait partie d’une série d’analyses sur la taille et le contenu de ce fameux index “secondaire” par rapport au primaire.
Hello Magic :)
Ce que je veux dire par là, c’est que le nombre de liens en soit, n’est pas le critère prédominant.
C’est ce que je conclus de l’indexation / positionnement de mes pages de catégories en duplicate content : celles qui venaient des liens du blog avaient plus de liens internes que celles qui venaient du site, mais elles étaient moins bien positionnées. (et dans les deux cas, quasiment pas de liens externes)
Ce n’est pas nouveau d’ailleurs :)
Salut Marie-Aude;
Il y a plein de petits enseignements dans ton étude. Merci de partager
J’ai juste tiqué sur une phrase que j’ai du mal à cerner :
“En revanche, le linking n’est pas un critère de positionnement. ”
Si tu peux développer.
a+
Merci pour le passage et pour le soutien :) Bise retransmise :)
Moi j’ai rien compris mais ça ne fait rien je te donne le bonjour quand même et te souhaite de retrouver tous tes internautes perdus dans la nature ou passés à la concurrence !-))
La bise de St Etienne
F
Hello Marie-Aude ;)
Effectivement le Disallow dans le robots.txt c’est la boulette de chez boulette^^
Merci beaucoup pour cette analyse des “suites” qui est vraiment très intéressante ;)
Juste concernant ce passage : “Or j’ai écrit quelques articles dans le blog, qui ont été immédiatement indexés.
C’est une confirmation : Google ne se base pas en priorité sur le sitemap pour crawler les pages d’un site et découvrir les nouveautés.”
Tu es sûr que cette indexation rapide des nouveaux articles ne provient pas du ping automatique intégré dans WordPress ? Moi j’aurais cherché de ce coté là pour trouver une explication à ce phénomène.
Keep on the good work ;)
@Keroin la boulette je l’ai faite une fois, je préfère la faire sur un de mes sites que chez un client ;)
Pour les articles de blog, tu as en principe raison, mais j’ai remarqué que des modifs sur des pages du site proprement dite se propageaient en 24 heures, alors que le sitemap n’avait pas été consulté. Je me suis mis ça sous le coude pour la prochaine création de page, voir si ça va aussi vite.
@kaliseo je n’ai pas dit que les liens indiqués dans GWT n’avaient aucune importance, c’est quand même un très bon indicateur, mais qu’il y avait un décalage par rapport à la réalité. Quand j’en ai plus dans l’index que dans GWT par exemple, ce qui est le cas du premier jour (0 dans GWT) ou des fichiers .kml qui sont indiqués comme non indexés, alors qu’ils le sont.
En fait tu as un “forfait” GWT, un “forfait” avec consommation détaillée ;) index, et les deux ne se recoupent pas.
Les liens sont effectivement indiqués avec un retard important. Donc il vaut mieux les gérer autrement, si on veut les suivre finement.
Je n’ai pas dit non plus qu’un sitemap ne sert à rien. Mais qu’il ne sert pas à grand chose pour un site avec un maillage interne correct. Manifestement, quand Google a le choix entre explorer lui même et prendre les infos d’un sitemap, il choisit la première solution. Mais ça reste un outil valide pour les sites avec des difficultés structurelles de linking, ou pour d’autres infos dans le sitemap, comme la priorité ou la date de dernière mise à jour.
En ce qui concerne les liens dans GWT, on ne sait pas réellement ce que Google fournit ou pas. De la a dire qu’ils n’ont aucune importance, il y a des nuances. certes ca ne fait pas tout, mais un linking bien construit reste garant d’une réelle popularité.
Les données que l’on trouve dans GWT ne sont effectivement pas a jour en temps réel, mais qui nous dit qu’elles ne le sont pas dans l’index ? Tout comme la Google Toolbar, on sait aujourd’hui qu’elle ne fourni un pagerank qui est calculé avec beaucoup de retard et qui est un indicateur peu fiable puisque calculé tous les 3 mois environ. Par contre, le PageRank utilisé par google, lui, semble bien calculé en temps réel dans l’index.
Bonjour,
article très instructif,
merci et bonne continuation.
Bonsoir Thomas,
je ne pense pas avoir un très gros site :)
Et surtout je ne pense pas que les données soient des approximations grossières. Je suis en train de regarder de façon assez précise la réalité de la commande site, en regardant pour une page, donnée en index complémentaire ou pas si elle ressort ou pas sur une requête [en résultat primaire, bien sûr], et surtout ce qui se passe quand Google renvoie une de mes pages dans les résultats complémentaires, et cela concorde suffisamment bien pour l’instant.
De plus, ces informations (la commande site: ) sont mises à jour quotidiennement.
Il y a déjà d’autres domaines dans lesquels Google a officiellement décidé de faire preuve de “pudeur” ou d’approximation grossière (après tout c’est une question de style), et notamment dans celui du PR affiché.
Je pense qu’une partie des informations est volontairement bridée, ou donnée avec retard, pas pour des raisons de limite de calcul – puisque les calculs sont déjà faits – mais simplement pour éviter de donner trop d’informations qui permettraient de percer plus facilement les résultats de l’algo, et notamment en voyant les résultats de tests immédiatement dans ses outils.
En tout cas, quelle qu’en soit la raison, le résultat est le même : il n’y a pas de moyen d’avoir facilement et rapidement des informations à jour sur le classement d’un site.
la grande majorité des donnée fournies par Google (et surtout le “site:”) sont des approximations grossières faites avec un impératif : limiter le temps machine nécessaire a leur calcul; Google ne ment pas et n’est pas pudique Google cherche à économiser des $, Et plus le nombre de pages indexées d’un site est grand plus grosses seront les approximations en volume.
hmm… oui “aproximations grossières” est un peu fort surtout qu’en dessous de quelques dizaines de pages Google est presque précis, enfin il y a quand même des écarts notables quand on intérroge différents data center…
Sans compter le coup du chiffre revu à la baisse quand on se ballade sur la pagination (ça le fait presque à tous les coups sur les sites de 50+ pages :D)
Sur des gros sites les commandes site: (avec ou sans le &filter=0) sont imprécises au possible et peuvent varier fortement dans le temps sans pour autant qu’il n’y ait de nouvelles pages.
Pour appuyer l’argument de l’approximation, je prendrai l’exemple de Matt sucks ((c) magicyoyo) qui expliquait que l’algo de détection des google bomb était lancé à plusieurs mois d’intervalle car cela nécessitait de grosses ressources et beaucoup de temps machine pour l’exécuter sur l’intégralité du web.
Typiquement j’imagine que sortir un mapping régulier des liens externes des GWT (ce qui sont mis à jour toutes les x semaines) de tous les sites nécessite également de grosses ressources…
Pour nous c’est complètement virtuel mais ça ne m’étonnerait pas que Google arrive à chiffrer le coût en $ de ce genre de requêtes :D
Le chiffre revu à la baisse c’est la différence entre résultats complémentaires et résultats “primaires” non ? Puisqu’on ne peut connaitre les résultats primaires qu’en arrivant à la fin de la pagination, justement.
C’est tout à fait exact que les liens dans GWT sont mis à jour avec beaucoup de retard. Ça ne veut pas dire pour autant que le mapping ne soit pas mis à jour régulièrement – ou alors c’est en complète contradiction avec “le PR est mis à jour quasiment en temps réel”
Mais on se fait peut être des illusions sur le PR… en fait il n’est plus mis à jour ;)
le paramètre filter=0 permet en théorie d’afficher la totalité des pages indexées (complémentaires / secondaire / primaire et quaternaire :p), c’est le paramètre que rajoute google quand on clique sur “Afficher tous les résultats”.
Quand tu arrives au bout de la pagination que tu cliques sur afficher tous les résultats tu retombes sur le chiffre du site: de la première page toi ? ;)
Google a une contrainte très forte afficher une réponse en moins d’une seconde… alors donner un chiffre précis à un “site:” crois moi il s’en moque ;).
Quant à ce qui est du calcul du PR en quasi temps réel, je ne suis pas dans la confidence –
j’ai bien une théorie mais elle va pas te plaire : là encore je crois qu’il doit y avoir une “estimation”, peut-être moins grossière on est pas sur des requêtes de webmaster useless pour le commun des mortels comme le “site:”.
Mes sites sont de petits sites :) Mezgarne a 587 urls dans le sitemap, dont une centaine de fichiers kml. Comme tu le dis, je pense que ce genre de sites est traité de façon plus exacte que les énormes usines qui génèrent des dizaines de milliers de pages.
En ce qui concerne le PR, pour être honnête, je m’en fiche totalement. Je ne suis pas une obsédée de la petite barre verte, mais du positionnement et du trafic qualifié :)
Sinon pour répondre à ta question, oui j’ai bien le même nombre de pages en cliquant sur “afficher tous les résultats”.
En revanche en allant “au bout” de ces résultats, il y en a beaucoup moins qu’annoncé. Mais cela n’est pas nouveau, Jean Véronis avait déjà fait un billet sur la disparition mystérieuse de ces pages
Bonjour,
Je découvre votre article qui est fort intéressant. Mais où je n’ai pas compris, c’est les metas données dupliqués.
On sait tous que google sanctionne ces mets en double. Si vous avez un meta en double quelque soit l’endroit, votre site chute comme une feuille de papiers. Pour le référencement vous le savez que le première facteur que google prend en compte c’est la structure du site et dans le cas où vous avez la malheur d’avoir des erreurs du type meta en double votre site chute. Je dirais que ces metas en doubles sont plus dangereux que les erreurs 404.
Le sitemap est très utile pour vous pour voir le pourcentage de nombre de page dans l’index de google. Si vous êtes à 100% de page en indexaient de votre sitemap, alors vous n’avez pas de problème pour google et votre site est très bien référencer.
Dites moi si j’ai raison.