Comment checker et récupérer les URLs indexées et plus encore ?

Par nécessité et curiosité, j’ai récemment cherché à améliorer ma méthode pour sonder les abîmes de Google pour checker l’indexation d’un site, URL par URL et en full auto cela va de soi. Et pourquoi pas récupérer également tout ce qu’il a dans le ventre. Sans me la péter, niveau info et méthodologie sur le web francophone, c’est un peu le désert de Gobi ! Sorti de la Search Console avec ses données faméliques, et les scraps bricolés avec la commande site, c’est walou ! Cet article qui mixe à la fois infos et howto, implique de bien comprendre comment fonctionne l’indexation chez Google d’une part, et d’avoir déjà de bonnes bases en SEO.

Ceux qui pensaient jusqu’ici (je m’inclus dedans) qu’il fallait une vision 3D (Croisement de web crawl + GA + logs) pour réaliser des audits SEO « high level », vont certainement passer à la 4D avec l’analyse fine de l’indexation. Et surtout, c’est un moyen de s’approcher encore plus près de la manière dont Google apprécie nos pages, ce qui constitue quand même l’un des objectifs suprêmes du prestataire SEO.

Alors l’indexation, comment ça marche ?

On le sait tous, il faut que le Googlebot passe sans contrainte sur nos pages pour les indexer. On fait donc le raccourci suivant : si une URL est crawlée par le Googlebot (voir mon article sur l’analyse des logs), c’est qu’elle est indexée. Mais en fait pas vraiment ! Le choix de mettre une URL dans l’index et la rendre trouvable va se décider dans un processus « post crawl ». A contrario une URL qui n’a jamais été crawlée par le Googlebot n’a en théorie que très peu de chance d’apparaître dans les SERPs.

Il y a ensuite les notions d’index primaire et secondaire. Ca, vous le verrez par la suite, c’est quelque chose de très important ! Petit rappel vite fait sur la différence entre les deux : l’index primaire est celui qui présente les pages dans les résultats de recherche, autrement dit, celui qui est sollicité à 99,9% du temps. L’index secondaire contient lui des pages que Google juge sans intérêt, et surtout dupliquées. En gros, l’index secondaire, c’est la corbeille de Google, et quand vos URLs sont dedans, autant les considérées comme non indexées, même si ce n’est pas vraiment le cas.

Et puis il y a le fameux cache, qui permet de consulter une page quand celle-ci ne répond pas par exemple. On peut dire sans se tromper qu’une page disponible en cache de Google (voir opérateur de commande cache:[URL]), est indexée. Mais l’inverse n’est pas forcément vrai ! Au même titre qu’avec l’index secondaire, Google ne juge pas toujours utile de stocker des pages en cache avec grosso modo les mêmes critères. Donc, une page non disponible en cache ne veut pas dire qu’elle n’est pas dans l’index.

Les techniques de base pour checker l’indexation

La technique élémentaire : rechercher l’URL dans Google, comme on le ferait avec une requête

Petite remarque, il faut aller vraiment sur Google.fr pour faire ça, et ne pas utiliser l’omnibox de la page de démarrage de votre navigateur qui transfert systématiquement tout ce que vous tapez dans le champ URL. Donc si l’URL est trouvée, c’est qu’elle est indexée. Logique.

L’opérateur de commande site:[URL]

C’est une technique très répandue pour lister les pages indexées. À l’aide d’un bookmarklet ou d’un scraper quelconque, on récupère la liste des URLs… Hélas ce n’est pas fiable du tout, car Google fait tout pour brouiller et bloquer la récupération. Les techniques de checking en batch s’avèrent meilleures que le scraping, je vais y venir…

Avantages de l’opérateur de commande site : je n’en vois pas vraiment. Il pourrait y en avoir un si site:domaine.com affichait un ranking qui aurait une quelconque corrélation avec la valeur (PageRank) des pages selon Google, mais manifestement là aussi, Google a bien brouillé les ondes. Cela dit, quand on veut savoir rapidement ce que Google a dans le ventre (juste le nombre de résultats) sur un domaine particulier, c’est quand même intéressant.

Inconvenient de l’opérateur de commande site : il n’affiche que les URLs de l’index primaire (à mois de forcer le paramètre &filter=0 dans l’URL). En plus, Google limitera volontairement les résultats à quelques centaines d’URLs, quand bien même la volumétrie fait plusieurs milliers d’URLs. Donc cette solution est complètement casse-gueule et imprécise, à moins de sonder un mini site d’une dizaine d’URLs.

L’opérateur info:[URL]

C’est l’opérateur de commande « Google approved » pour vérifier si une page est indexée.
La plupart des outils qui offrent une fonction pour checker l’indexation des URLs en masse comme Scrapebox, utilisent l’opérateur de commande info:[URL]. À noter que cette commande renvoie l’URL canonique si le rel canonical est implanté.

Avantage de l’opérateur de commande info : à ma connaissance, c’est l’opérateur le plus pertinent pour checker si Google connait une page ou pas, à défaut de savoir dans quel type d’index elle figure. C’est déjà une bonne information.

Inconvenient de l’opérateur de commande info : il ne fait pas la différence entre index secondaire et primaire ! Et si vous pensez qu’il n’y a pas de problème d’indexation sous prétexte que la commande info trouve l’URL, peut-être que vous vous trompez ;-) Fatalité, tous les tools permettant de vérifier l’indexation des pages de cette manière et qui vous donnent juste une réponse oui/non, sont au mieux imprécis, au pire trompeurs.

L’opérateur cache:[URL]

C’est la technique que j’ai utilisée pendant un long moment, sous prétexte qu’une page en cache était forcément signe d’indexation… Mais ce n’est pas parfait, loin de là !

Avantage de l’opérateur de commande cache : il y a la date de la dernière mise en cache. Par contre, contrairement à la majorité de mes confrères, je ne m’avancerai pas à dire que cette date correspond au dernier passage du Googlebot, même si on peut le supposer.
Mais il y a un autre avantage (abordé dans les inconvénients), c’est que cet opérateur devient un indicateur sur l’appréciation que peut avoir Google sur nos pages. Je vais développer plus loin…

Inconvénients de l’opérateur de commande cache : il y en a plusieurs. Tout d’abord, il faut que la page n’ai pas une directive noarchive (ce qui n’empêche absolument pas l’indexation). De plus, de manière arbitraire, Google ne stock pas forcément une page en cache alors qu’elle est « indexée ». Si il juge qu’une page n’a pas d’utilité à être en cache (notion de thin content, duplication, etc), alors il l’a zappe. De fait, les probabilités sont faibles pour qu’une page soit en cache ET dans l’index secondaire. Par contre il se peut très bien qu’une page soit en index primaire (donc trouvable), mais pas disponible en cache.

Et puis il y a la search console…

Il faut bien en parler puisque Google nous offre des infos sur l’indexation de nos sites. Disons qu’elle a le mérite de donner une vision globale. Dans « Index Google > état de l’indexation », on a l’évolution du volume de pages indexées, mais sans savoir dans quel index exactement.

Il y a également l’outil de soumission de sitemaps XML (« Exploration > Sitemaps ») qui nous donne le volume d’URLs soumises et indexées. C’est une technique très utilisée pour checker l’indexation d’un site, sauf que là encore on n’a aucun détail URL par URL, et à priori, seul l’index primaire est pris en compte.

Et donc la question n’est plus de savoir si une page est indexée, mais comment elle est indexée, voir pourquoi elle est mal indexée !

À partir de la, tout s’enchaîne…

Si l’on parvient techniquement à quantifier ET identifier le volume d’URLs dans l’index primaire et secondaire, et même chose avec URLs en cache et pas en cache, le tout couplé avec l’analyse des logs, on s’approche au plus près de la manière dont Google apprécie nos pages… alors que ce dernier s’efforce de nous livrer une appréciation très partielle dans sa search console. Il t’en donne un peu pour t’endormir, mais pas trop quand même pour ne pas te donner trop de billes pour faire du SEO aux p’tits oignons… Allez, faites-moi plaisir, lâchez un peu cette search console !

L’étude fine et détaillée de l’indexation devient un formidable indicateur de contenu maigre et accessoirement une arme anti Google panda.

Les outils

La majorité des outils qui permettent de checker l’indexation le font de manière basique avec l’opérateur de commande info. C’est mieux que rien certes, mais c’est imprécis. La majorité des outils… sauf un (à ma connaissance) : URLProfiler.

Cela dit, vous pouvez arriver au même résultat avec d’autres outils, notamment des scrapers comme RDDZ Scraper ou Scrapebox, mais comme la méthodologie n’est pas intégrée en natif, vous allez bien galérer, et consommer plus de proxies.

Comment fonctionne URLProfiler pour checker l’indexation ?

En gros, la procédure en plusieurs passes est la suivante :

1. Recherche de l’URL dans Google comme on ferait une recherche classique depuis Google.fr. Si il y a résultat, l’URL est indexée dans l’index primaire, et est donc trouvable. Pas la peine de faire d’autres tests si ce n’est vérifier que la page est en cache et récupérer la date.
2. Opérateur info: il est utilisé pour toutes les URLs n’ayant pas eu de résultat à l’étape précédente. À partir de là on sait par déduction si une URL est indexée ou pas, si elle est trouvable ou pas, bref si elle est dans l’index primaire ou secondaire.
3. Opérateur cache: Check et récupère la date de mise en cache si disponible.

Le bouzin fait ensuite un export Excel avec toutes ces infos. Le déroulé de la procédure est très intéressant, car avec la première étape peu sensible aux requêtes en masse sur Google, cela permet d’économiser des proxies et accélérer le temps de traitement. Je vous conseille de lire le tutorial en anglais qui explique tout ça plus en détail.

Voilà, vous avez maintenant les cartes en main (CB comprise) pour checker l’indexation de vos URLs. Plus votre projet sera de grande envergure, plus cela vous demandera de temps et d’argent (proxies) pour tout checker.

Pour limiter les frais inutiles il y a une petite astuce : faites un crawl de votre site avec Screaming Frog, ou tout autre crawler permettant de récupérer les DATA de Google Analytics via l’API afin de récolter les entrées (GA Sessions) du segment « organic » sur une plage de plusieurs mois. À partir du moment ou une URL reçoit des entrées organiques, c’est qu’elle est trouvable et indexée dans l’index primaire. À moins de vouloir la date du cache, inutile de les soumettre dans URLProfiler pour checker l’indexation. Vous économiserez ainsi pas mal de billes.

l’indicateur d’indexation vs étude des logs

Pour les audits on site, et en particulier pour cibler les « pagina non grata » qui peuvent être à l’origine d’un panda ou autres joyeusetés de ce genre, les deux indicateurs offrent une excellente complémentarité, ce que j’aime appeler « la vision 4D ». Mais l’étude de l’indexation en profondeur a cet avantage de pouvoir s’exercer sur n’importe quel site ! À moins d’être vraiment couillu, vous n’allez pas demander à vos concurrents de vous passer leurs fichiers logs ;) En revanche, vous pouvez très bien évaluer le ratio de pages indexées/non indexées/primaires/secondaires, etc.

Un nouveau champ d’investigation s’ouvre à vous, mêlant corrélations, recoupements, comparaisons…

J’aime de plus en plus faire des corrélations avec des sites concurrents. D’ailleurs, je pense que Google en fait de même pour juger un site : il ne le fait pas uniquement en fonction de critères absolus, mais relatifs à des sites similaires. Pour vous donner un exemple, le taux critique de duplication de contenu externe pourra varier d’une niche à l’autre. Au delà de ça, il est intéressant d’évaluer l’indexation de son site vis-à-vis de la concurrence. C’est très instructif, et permet surtout de bien régler sa mire pour chasser le panda ;)

Petite méthode (économe en ressources) pour réaliser des études de corrélation

L’idée est donc d’aller récupérer les sites qui se positionnent le mieux sur votre thématique. Je préfère ça à la requête principale, car il n’y en a pas forcément qu’une. Pour ça, j’utilise le très bon Yooda Insight :

Je récupère ensuite les premiers sites les plus visibles… Disons 4 ou 5.

Puis je lance un crawl avec Screaming Frog SEO Spider sur chacun des sites. Si je me heurte à des projets de grande envergure, alors je stop le processus à environ 10 000 URLs. C’est suffisant pour se faire une idée de l’état de l’indexation. Depuis l’onglet internal (filtre HTML), je tri la colonne « Word Count » par ordre croissant pour ne retenir (copier/coller ou exporter) que les 200 URLs possédant le moins de contenu. Mais attention, il faut :

• Etre respectueux du robots.txt (voir paramètres de SF)
• Respecter les directives noindex et ne prendre que les URLs indexables
• Uniquement les URLs en status code 200
• … bref tout ce qui est susceptible de se retrouver dans l’index de Google.

Vous me suivez jusque là ? Il y a un objectif combiné ou j’économise les ressources, tout en mettant le focus sur le « thin content ». Chaque site doit faire l’objet du même protocole, y compris le vôtre. Vous pouvez vous faire vos propres règles, il n’y a rien de strict ici.

Enfin, il ne vous restera plus qu’à évaluer l’indexation de chaque site avec URL Profiler, puis comparer les stats de chaque site.

À ce jour et après quelques études faites sur quelques sites plombés par le contenu maigre, il n’y a pas vraiment de corrélation entre ranking et ratio pages indexées/non indexées. Je vois fréquemment des sites dans le top 5 avec plein de pages quasi vides de contenu et pas indexées… La notoriété de la marque prend très vite le dessus sur certains aspects techniques.

En revanche, il y a une corrélation beaucoup plus marquée quand on regarde le ratio des pages en cache / pas en cache sur les URLs indexées uniquement. Je n’ai pas les moyens de réaliser des études à la Searchmetrics, donc je vous invite à faire vos tests de votre côté, mais je pense de plus en plus que l’évaluation du ratio « pages en cache / pas en cache » sur un pool d’URLs indexées est le meilleur radar à thin content. Combiné avec l’étude des logs, ça devient chirurgical :)

Et pour récupérer l’ensemble des URLs dans l’index, on fait comment ?

Le sujet a déjà été abordé chez Olivier Andrieu. À l’évidence, il n’y a aucun moyen de le faire de manière exhaustive, et cela nécessite quelques pirouettes techniques… Si comme moi vous aimez cuisiner les DATA, alors cela ne devrait pas constituer un obstacle. À ma connaissance, la meilleure solution réside dans la récupération des logs, sur 3 ou 4 mois si possible. Si une page reçoit des hits du Googlebot, c’est qu’elle est connue de Google. Vous avez suivi ce qui a été dit avant hein ? « Connue » ne veut pas forcément dire indexée ! On peut ensuite croiser avec les données du crawl, tout repasser par URL Profiler, bref des heures de jeu :)

Un dernier mot sur Google panda : j’en parle, j’en parle, mais dans mon esprit il n’existe plus. Ca devient très dur de le diagnostiquer, il est plus ou moins intégré à l’algo, plus ou moins temps réel, mais aussi, un site peut très bien être affecté négativement par le contenu maigre indépendamment de panda ! Sans parler des érosions lentes des positions qui empêchent tout recoupement avec d’éventuelles mises à jour connues de l’algorithme. Du coup je ne cherche plus à savoir si un site est impacté ou pas par ce filtre. J’analyse la valeur du contenu, et l’appétence qu’il suscite. Point.