Brancher Search Console sur Claude, et la vérité sur l'indexation

Un lot de pages non indexées dans le rapport demandait vérification. J'ai utilisé Claude pour inspecter 120 URL en lot, comparer leurs états et distinguer l'inspection d'une demande d'indexation.

Jim Sagnier 6 min de lecture Mis à jour le
SEOEurofiscalis : les outils · épisode 2
L’essentiel en bref

Google Search Console t'affiche "cette page n'est pas indexée". Sur le lot raconté ici, l'inspection d'URL et le rapport agrégé ne donnaient pas le même état. Ce cas ne permet pas de dire que les rapports Search Console sont généralement faux. J'ai perdu des heures à vérifier ces pages une par une, à la main, avant de brancher Search Console directement sur Claude. Voilà ce que ça a changé, et ce que ça m'a appris sur l'indexation.

Je suis Jim. Deuxième volet de l'aparté "outils" dans la saga Eurofiscalis. Après mon crawler maison, qui me dit ce qu'il y a sur le site, place à l'outil qui me dit ce que Google, lui, en fait : Search Console.

Brancher Search Console sur Claude

Vérifier les pages une par une dans l'interface web prenait du temps. Je voulais pouvoir l'interroger en langage naturel, et surtout automatiser les vérifications fastidieuses. Alors je l'ai reliée à Claude par un pont, le même type de pont que celui dont je parlais dans l'article sur nos skills : le MCP.

Une bonne pratique au passage : avant de brancher quoi que ce soit, j'ai vérifié que l'accès fonctionnait vraiment, que le compte de service dédié voyait bien la propriété du site. Tester l'accès avant de connecter, ça évite de croire qu'on est relié alors qu'on ne l'est pas. Une fois en place, Claude avait sous la main tout un jeu d'outils Search Console : les statistiques, l'inspection d'URL, les sitemaps.

Ce qui a coincé

Le blocage n'était pas dans la configuration, mais dans l'usage. Deux limites dans la configuration que j’utilisais.

D'abord, dans la configuration que j'utilisais, le serveur MCP ne se chargeait qu'au démarrage d'une session. Tu le branches en cours de conversation, et ses outils ne sont pas encore appelables tant que tu n'as pas relancé. Il fallait relancer la session pour disposer des outils.

Ensuite, mes sous-agents n'avaient pas accès à cette connexion dans cet environnement. Je lance souvent des recherches en parallèle, réparties sur plusieurs agents. Tous m'ont remonté la même chose : "pas d'accès à Search Console". Dans cet environnement, je devais donc faire les inspections depuis la session principale. Ce comportement est à vérifier selon le client et sa configuration.

Comparer le rapport et l’inspection d’URL

Voici le cas qui a tout déclenché. Dans Search Console, 120 pages étaient marquées "explorée, actuellement non indexée". Je voulais savoir lesquelles demandaient réellement une intervention.

Sauf que, quand je cliquais sur l'une d'elles pour relancer l'analyse, Google me répondait qu'elle était bien indexée. Vérifier les 120 de cette façon aurait demandé autant de manipulations.

Avec Claude relié à Search Console, je l'ai fait en lot. L'API d'inspection permet de consulter l'état enregistré par Google pour chaque URL. J'ai donc inspecté les 120 pages en lot, sans lancer un test en direct de chacune. Résultat : 117 étaient déjà indexées. Un décalage de mise à jour du rapport était l'hypothèse retenue. Cette observation concerne ces 120 URL, pas l'ensemble du site. Il ne restait que 3 vrais problèmes : deux catégories de blog vides (des pages sans contenu) et une fiche de glossaire trop maigre pour mériter sa place.

Le détail qui m'a mis sur la piste : Claude a repéré dans l'export que ces 120 pages étaient passées "de 0 à 120 en un seul jour". Pas une lente dégradation, un événement ponctuel : un changement de rapport après que j'avais resoumis le sitemap. Savoir ça change toute la lecture. Ce signal m'a poussé à vérifier les URL plutôt qu'à déduire une panne globale à partir du graphique.

L'API inspecte une URL par appel, avec des quotas à prendre en compte. Je l'utilise pour des lots ciblés ; ce contrôle ne remplace pas un crawl du site.

L'Indexing API, ce faux ami

Il faut distinguer cette inspection de l’Indexing API. Cette dernière ne sert pas à soumettre les articles d’un blog. Google réserve officiellement l'Indexing API aux pages JobPosting et aux BroadcastEvent intégrés à un VideoObject. Les articles de blog ordinaires sont hors de ce périmètre. Je ne l'utilise donc pas pour eux, et je ne la présente pas comme un moyen de forcer leur indexation.

Ce que je vérifie sur une page non indexée

Je regarde d'abord si la page est accessible, si son contenu répond au sujet et si elle figure dans le sitemap. Je vérifie aussi les liens qui permettent de la découvrir depuis d'autres pages. L'inspection permet ensuite de consulter son état. Cette API lit les informations de la version connue de Google, elle ne demande pas l'indexation. Une éventuelle demande d'indexation se fait dans l'interface Search Console, séparément. Des liens depuis des pages pertinentes aident à la découverte, sans nombre obligatoire ni garantie de délai.

Un exemple concret : une page de glossaire coincée dans le fameux "explorée, non indexée". On a enrichi son contenu, et surtout on lui a ajouté une poignée de liens internes réciproques depuis des pages voisines déjà bien indexées. Le contrôle suivant l'a trouvée indexée. Je ne peux pas isoler l'effet du contenu, des liens ou du temps écoulé. Ce contrôle confirme seulement que son état avait changé après ces interventions.

La suite

Le crawler sert à inventorier les pages. Search Console permet de consulter ce que Google en a enregistré. Sur ce lot, la comparaison du rapport et des inspections m’a évité de traiter 120 URL comme autant de pages absentes de l’index.

L'article suivant porte sur les outils destinés au visiteur : les outils interactifs d'un blog, sans casser le SEO.