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 ?

Guide de l'indexation
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.

Porte d'entrée vers index secondaire

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

Mettons de côté l’aspect automatisation dans un premier temps. Les techniques ci-dessous permettent de checker manuellement l’indexation URL par URL, et j’aborderai les outils qui automatisent tout cela un peu plus loin, car il est nécessaire de comprendre sur quoi ils se basent.

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…

La commande site:

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.

Sitemap (Search Console)

C’est justement la technique du sitemap qui m’a incité à creuser le sujet de l’indexation : un client s’étonnait que certaines de ses pages ne s’indexent pas, même avec le temps et à coup de re-soumissions. Et en creusant un peu avec les opérateurs de commande cache, et info j’ai rapidement compris qu’un paquet d’URLs étaient en index secondaire, avec des problématiques de contenu dupliqué.

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.

Nécessité absolue d’avoir de bons proxies ! Dès qu’il faut sonder Google avec des opérateurs de commande, on a très vite fait d’avoir des Captcha et cramer son IP. Il vous faudra inévitablement mettre la main à la poche pour acheter une dizaine de proxies anonymes, privés et inconnus de Google. Je peux vous recommander myprivateproxy.net ou anonymous-proxies.net pour un bon rendement. Après il faut évaluer le ratio nombre de proxies / volumétrie d’URL. Avec 11 proxies J’arrive à checker 2000 URLs mais en faisant par palier de 200 et 15/20mn de pause entre chaque opération. Si j’obtiens des « connection failed » à la fin, je recheck toutes ces URLs plus tard.

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 :

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.

La notion de « thin content » n’est pas intrinsèquement liée au volume de mots par page/texte. Ce n’est pas tant la quantité, mais surtout la qualité. Pour Google, l’accent est mis sur le manque de valeur ajoutée, la manière de monétiser, le contenu auto généré, etc. Donc mon protocole abordé plus haut reste perfectible.

À 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.

Je tiens à remercier Bruno Guyot (@ChablaisWeb) qui m’a permis de découvrir cette fonction améliorée d’URL Profiler, merci également à Yann (@omnireso) qui a bien voulu partager l’un de ses projets bien plombé par panda pour allimenter ma R&D, et bien entendu merci à URL Profiler, et cet article en particulier qui m’a bien ouvert les yeux.
Vous pouvez avoir un lien en DoFollow si :
  • Vous ne faites pas de lien optimisé (brand ok).
  • Votre contribution apporte de l'eau au moulin et ne se contente pas de remercier (même si c'est toujours appréciable).
  • Vous ne donnez pas l'impression de ne pas avoir lu l'article.
  • Votre site doit graviter dans l'univers du SEO / web marketing / IT.
  • Nouveau : Se suivre mutuellement sur Twitter (oui ça fait copinage, et j'assume !).
Le but n'étant pas d'être plus sévère, mais au contraire plus équitable et... naturel. N'oubliez-pas : moins de spamco = meilleur jus !

7 réflexions au sujet de « Comment checker et récupérer les URLs indexées et plus encore ? »

  • Je vais quand même remercier.
    Merci Aurélien, car c’était une partie de mon interrogation de ce matin : je voulais vérifier la bonne indexation d’une page avec un BL et j’ai des réponses différentes selon les navigateurs, avec la commande site:tagada.com « text on page ». Chrome ne renvoie rien quand FF et IE confirme une indexation. La commande info renvoie par contre la même réponse, quel que soit le navigateur.
    D’où une vraie pertinence à croiser les infos.

  • Je ne suis pas sûr qu’il y ai encore un index secondaire au sens ou tu l’entends: le terme me semble avoir été abandonné par google à peu prés au moment ou son architecture d’extraction des requetes pertinente a migré en https://en.m.wikipedia.org/wiki/Shard_(database_architecture), et je parie que les dates coincident avec caffeine.
    Bref, ce n’est qu’une question de dénomination.
    Sinon pour accélèrer les requêtes, si la commande info: fonctionne comme la commande cache:, elle doit renvoyer 200 si elle a l’info, et 404 si elle ne l’a pas. Une requête HEAD suffit, pas besoin de faire le GET.

  • Bravo pour cet article très didactique. Comme nous l’avons abordé sur Skype, tout ce distinguo « crawlé/indexé/caché/ranké » fait partie du b-a–BA du métier, et pourtant on en parle (trop) peu à mon avis. Reste d’autres commandes Google pour trier les pages récemment crawlées par exemple, à l’aide du paramètre tbs (&tbs=qdr:w) pour avoir les pages crawlées la dernière semaine. On retrouve tout ça dans la box « recherche avancée » et ça donne une indication de l’appétence de Google pour un site… sans faire confiance aveugle à la Search Console.
    Quant au partage, c’est avec plaisir et nul doute que tes recherches vont m’aider à requalifier le site, donc merci également !

  • @Mathieu : Merci pour ton retour. Il y a une partie de l’index visible, l’autre pas… après l’étiquette que veut mettre Google dessus, whatever :)

    @Bruno : je n’ai pas encore testé la fonction sur le duplicate. Il faut également que j’essaye kill duplicate (de Paul Sanchez). Mais il est clair que SEO Profiler est un très bon outil d’agrégation de données. Merci encore !

    @Yann : pour l’appétence, je préfère me fier au logs (Googlebot). Les pages les plus récemment crawlées ne sont pas forcément les plus fréquemment crawlées !
    Pour les recherches je pensais aller beaucoup plus loin, mais avec le taf qui s’accumule par ailleurs, j’ai été obligé de faire court. L’essentiel y est je pense :) Fanx ;)

  • Bonjour Aurélien Berrut, en voyant le titre de votre post, j’ai dis dans ma tête :) , ça doit être un post banal, et qu’il est en manque d’inspiration, mais réellement après avoir lu le post, vous m’avez épaté, chapeau.
    Pour moi, contrôler l’indexation ça était uniquement la commande site: (une manière basique), mais je viens de découvrir qu’on peut compléter avec cache, info et le service de Urlprofile.
    Je regrette jamais de passer par ton blog ;)

  • Je trouve cet article très complet et fourni un maximum d’informations sur le sujet. Toutefois, je m’oppose au BL à tout prix. Google en fait trop, il ne suffit plus de faire un site de qualité pour avoir du trafic, il faut sans cesse chercher et trouver des BL de qualité, ce qui devient de plus en difficile pour les novices en seo comme nous. Pas facile de trouver des webmasters partants pouvant vous fournir un bon BL. Je me tourne de plus en plus vers les réseaux sociaux. Cela n’enlève rien à votre article qu’une fois encore je dois le dire esta ssez complet.

Les commentaires sont fermés.