« Discovered – currently not indexed » et « Crawled – currently not indexed » sont les deux lignes les plus courantes du rapport « Pages indexées » de Search Console – et les plus mal comprises. Elles ressemblent à un échec technique, mais ce sont en réalité des jugements de priorité et de qualité que Google a portés sur vos pages. Soumettre plus fort ne change rien. Corriger la cause, oui.
Ce guide est une boucle complète que vous pouvez confier entièrement à l'agent Hermes : extraire la liste des URLs, inspecter chaque page, trier la vraie cause, approuver la file de corrections et ne soumettre via l'API Google Indexing que les pages qui méritent d'être indexées. Au bout du compte, vous avez un pipeline hebdomadaire reproductible – pas une session de clics ponctuelle.
Ce que vous obtenez
- Un inventaire classé : les URLs bloquées en « discovered », les URLs crawléées mais non indexées, et celles que vous n'auriez jamais dû soumettre
- Une liste approuvée pour l'API Indexing et une liste d'exclusion avec justification
- Une étape de vérification qui montre si vos soumissions ont réellement fonctionné
Ce qu'il vous faut : un agent Hermes installé et fonctionnel (hermes chat ouvre une session. Étapes d'installation à jour : doc officielle sur hermes-agent.nousresearch.com/docs), une propriété Search Console dont vous êtes propriétaire, et deux jeux d'identifiants Google (un pour lire la GSC, un pour l'API Indexing). Premier paramétrage environ 60–90 minutes, puis environ 15 minutes par semaine. « Terminé » signifie : vos URLs soumises affichent un vrai changement de statut dans l'API d'inspection sous deux semaines – ou vous avez des preuves solides du contraire.
Lire correctement les deux statuts
Google n'est pas coincé sur votre site. Il a pris une décision – et le statut vous dit laquelle.
Statut | Ce que ça signifie vraiment | Causes fréquentes | Quand soumettre |
|---|---|---|---|
Discovered – currently not indexed | Google connaît l'URL (via sitemap ou liens) mais ne l'a pas encore crawléé | Priorité de crawl faible, liens internes faibles ou absents, pression du budget de crawl sur les gros sites, site neuf, rendu JS lent ou lourd, sitemaps qui changent souvent | Une fois, après avoir amélioré les signaux de priorité (surtout les liens internes) |
Crawled – currently not indexed | Google a récupéré l'URL mais a décidé de ne pas l'indexer | Contenu dupliqué ou quasi-dupliqué, contenu pauvre, canonical vers une autre URL, noindex au moment du crawl, soft 404, jugé de faible valeur | Seulement si vous avez vraiment changé quelque chose : contenu, canonical ou noindex |
Indexed | Dans l'index | — | Ne pas soumettre |
Excluded | Crawléé et exclue volontairement (noindex, canonical, choix de doublon, blocage) | — | Ne pas soumettre ; vérifier que l'exclusion est intentionnelle |
En une phrase : ne soumettez que les URLs que vous avez réellement modifiées ou qui méritent un second regard. L'API Indexing est un canal de notification, pas un outil pour écraser le classement. Soumettre une page pauvre dix fois, c'est récolter dix fois le même verdict.
Pourquoi le faire faire par un agent
Le bouton « Demander l'indexation » de la GSC n'a pas d'API publique – il n'existe donc aucun moyen officiel de le cliquer par script. L'automatisation la plus proche est l'API Google Indexing, qui accepte directement des notifications d'URL. Un agent apporte de la valeur pour trois raisons :
- La boucle est mécanique et longue : inventaire → inspection → classification → correction → soumission → vérification. Chaque semaine.
- Elle exige une piste d'audit : il vous faut un fichier montrant quelles URLs ont été soumises, quand et pourquoi.
- Elle exige un sas d'approbation : la partie qui écrit sur Google doit être relue par un humain. Hermes est précisément construit autour de cette séparation – avec des compétences, des dossiers de projet et des règles d'approbation.
Ce dont vous avez besoin avant de commencer
- Agent Hermes installé. Vérifiez avec
hermes chatavant d'aller plus loin. - Une propriété GSC dont vous êtes propriétaire. Au format
sc-domain:example.com(pas l'URL complète). - Accès en lecture : un client OAuth Google Cloud (ID client + secret) pour l'API Search Console. Les scripts de la compétence GSC l'utilisent pour les sitemaps, les analytics de recherche et l'inspection d'URL.
- Accès en écriture : un projet Google Cloud avec l'API Indexing activée et une clé JSON de compte de service. Ajoutez l'e-mail du compte de service comme propriétaire dans GSC → Paramètres → Utilisateurs et autorisations. Si la soumission renvoie 403, c'est cette étape qui manque.
- Python 3 et
pip install google-auth google-api-python-client. - Un dossier de projet. Par exemple
/hermes-seo-projectaveccontext/,data/,qa/et unapproval-rules.mdqui impose que l'étape de soumission requière toujours une signature humaine.
Étape 1 : constituer l'inventaire des URLs
Copiez les deux compétences GSC dans le répertoire de compétences d'Hermes (~/.hermes/skills) : la compétence de lecture (sitemaps, analytics de recherche, inspection d'URL) et la compétence d'indexation (script de soumission). Si le harness catalogue les compétences, vous pouvez aussi les charger avec skill_view.
Demandez ensuite à Hermes dans une session de chat, depuis le dossier de projet :
Liste tous les sitemaps de sc-domain:example.com, récupère chaque URL avec son lastmod et écris-les dans data/url-inventory.csv. Marque tout sitemap dont la récupération échoue.
Hermes exécute les commandes sitemap via l'outil terminal et écrit le CSV. Une bonne sortie : un CSV dédupliqué avec URL, lastmod et sitemap source. Contrôle qualité : vérifiez cinq lignes au hasard et comparez le total avec le rapport de sitemaps de la GSC. Si la liste est vide ou si l'authentification échoue, relancez le flux d'authentification GSC ; le script de lecture a besoin d'un jeton OAuth frais.
Étape 2 : inspecter et classer
L'agent inspecte ensuite l'inventaire par lots via l'API URL Inspection et récupère l'état de couverture actuel de chaque page. Demandez-lui l'étape suivante :
Inspecte chaque URL de data/url-inventory.csv. Répartis-les en trois fichiers : data/to-submit.txt (non indexées et méritant une soumission), data/skip.txt (avec une justification par URL) et data/needs-fix.txt (non indexées et bloquées sur quelque chose que nous pouvons corriger).
L'API d'inspection a des limites de débit par propriété (consultez le quota actuel dans Google Cloud Console ; plusieurs milliers par jour, mais pas infini). Pour les grands sites, limitez cette passe aux URLs au lastmod le plus récent – celles que vous avez réellement modifiées ce trimestre. Contrôle qualité : échantillonnez la liste d'exclusion. Elle devrait être dominée par des noindex, des canonicals pointant ailleurs et des doublons – pas par des pages qui comptent pour vous. Si une liste de plusieurs milliers d'URLs donne un needs-fix vide, l'étape d'inventaire a probablement manqué des pages. Élargissez le périmètre d'entrée.
Étape 3 : trier avant de soumettre
L'étape que tout le monde saute. Faites correspondre les URLs bloquées à une cause et une correction, dans cet ordre :
Cause | Correction | Soumettre après correction ? |
|---|---|---|
La page n'a aucun lien interne | Ajouter des liens contextuels depuis des pages indexées | Oui |
Site ou page tout neuf | Rien à corriger ; soumettre une fois et attendre 1–2 semaines | Oui, une seule fois |
Bloqué par robots.txt | Lever le blocage sur le chemin | Oui |
Crawléé mais dupliquée ou pauvre | Réécrire, fusionner ou supprimer | Seulement après un vrai changement de contenu |
canonical vers une autre URL | Corriger le canonical si faux ; intentionnel : ne plus soumettre cette URL | Seulement après correction |
noindex au moment du crawl | Retirer le noindex et laisser Google recrawler | Oui, après retrait |
Soft 404, pagination/archives sans valeur | Corriger la page ou la supprimer | Non — exclusion définitive |
Demandez à Hermes de préparer la file de corrections sous forme de tableau : URL, cause présumée, preuve (résultat d'inspection ou contrôle de contenu), action recommandée, niveau de risque. Approuvez chaque ligne dans le chat. Votre approval-rules.md devrait l'imposer : l'agent prépare, vous approuvez, et rien au-dessus du faible risque n'est soumis sans signature.
Le sas d'approbation sépare la préparation de l'agent de l'étape d'écriture.
Les corrections elles-mêmes sont du travail SEO classique : réécrire du contenu, nettoyer les canonicals, poser des liens internes. Ce pipeline couvre la moitié « soumission ». La moitié « correction » est traitée par les articles d'audit et de rafraîchissement de la série Hermes.
La liste de soumission est l'intersection de « corrigeable » et « digne d'indexation ».
Étape 4 : soumettre via l'API Indexing
Une fois la file approuvée, placez les URLs dans data/approved-urls.txt et laissez Hermes exécuter la compétence d'indexation :
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtLe type de notification par défaut est URL_UPDATED, destiné aux pages nouvelles ou modifiées. Trois chiffres à retenir : le quota par défaut est de 200 URLs par jour, 600 requêtes par minute – et 403 signifie que le compte de service n'est pas propriétaire de la propriété. Si la liste approuvée dépasse 200, étalez sur plusieurs jours ; Hermes peut planifier les lots restants.
Ne soumettez jamais de pages déjà indexées ni la liste d'exclusion. Des notifications gaspillées ne font que brûler du quota et créer du bruit.
Étape 5 : vérifier, puis attendre
Le status juste après la soumission ne vous dit que si Google a des métadonnées sur la notification – pas si la page est indexée. La vraie confirmation arrive des jours plus tard.
3–7 jours après le lot, demandez à Hermes :
Réinspecte les URLs de data/approved-urls.txt et rapporte les changements de statut par rapport à la dernière exécution.
Une progression saine est discovered → crawled → indexed. Voilà à quoi ça ressemble sur plusieurs semaines : la liste des non-indexées rétrécit, et vos corrections réelles (nouveaux liens internes, textes réécrits) apparaissent dans l'index. Rappelez-vous : les données GSC ont quelques jours de latence et Google recrawle selon son propre calendrier. Une URL qui reste en « Crawled – currently not indexed » 10–14 jours après de vraies corrections est un signal de qualité, pas un problème de soumission – remontez-la vers le travail de contenu.
Garder la boucle en marche
Faites du pipeline une routine hebdomadaire : URLs nouvelles ou modifiées depuis le dernier passage → inspection → classification → tri → approbation → soumission → journal. Hermes peut faire tourner la partie lecture seule (inventaire, inspection, classification) sans surveillance, sur un calendrier, et vous présenter la file chaque lundi. L'étape de soumission reste derrière le sas d'approbation, avec un journal continu dans qa/indexing-log.md : date de soumission, URL, type de notification, résultat. Six mois de journal sont la seule mesure honnête de l'efficacité du pipeline.
Limites honnêtes
- Google documente l'API Indexing pour les pages avec données structurées
JobPostingouBroadcastEvent. L'utiliser pour des pages normales est une pratique SEO répandue, mais Google ne garantit l'indexation ni le support pour aucun type de page. - Le bouton « Demander l'indexation » n'a pas d'API publique. L'API Indexing est l'automatisation la plus proche, pas le même bouton.
- Soumettre ne crée pas de priorité. Si une page reste non indexée après correction, soumission et attente, la réponse suivante est la qualité du contenu – pas une nouvelle notification.
FAQ
L'API Indexing fonctionne-t-elle pour des pages normales ? Elle accepte toute URL que vous envoyez. La documentation officielle de Google vise les pages JobPosting et BroadcastEvent, alors traitez les soumissions de pages normales comme du best-effort : utile, courant, mais jamais garanti.
Pourquoi ça reste en « Discovered – currently not indexed » après soumission ? Ce statut signifie généralement une priorité de crawl, pas un échec. Vérifiez les liens internes vers la page, si robots.txt bloque le chemin et si la page dépend fortement de JavaScript. Puis attendez : sur un site neuf, la découverte jusqu'au crawl peut prendre 1–2 semaines.
Est-ce que 200 URLs par jour suffisent ? Pour la plupart des sites, oui – vous ne devriez de toute façon soumettre que des URLs réellement modifiées. Si vous en avez régulièrement plus, priorisez par valeur métier et demandez un quota plus élevé dans Google Cloud Console.
L'API Indexing accélère-t-elle le classement ? Non. Elle signale seulement à Google qu'une URL a changé. Le classement est un jugement séparé, rendu par les systèmes de Google, indépendamment du nombre de vos notifications.
En quoi diffère-t-elle du clic « Demander l'indexation » dans Search Console ? Même intention, mécanismes différents. Le bouton est une pure UI sans API publique ; l'API Indexing est le canal scriptable. Aucun des deux n'écrase le jugement de Google sur la place d'une page dans l'index.
Auteur : Julian Mercer, praticien SEO technique chez Auspia, 14 ans d'expérience. Écrit sur la crawlabilité, l'indexation, le schéma et les fondations techniques qui rendent un site lisible à la fois par Google et par les systèmes d'IA.
