IndexNow sur mon site : Yandex passe dans l'heure, Bingbot un mois plus tard

24 octobre 2026 par Benoit

Ou : Comment sonner chez quelqu’un qui avait déjà décidé de passer quand il voudrait

Le 15 avril 2026, à 8 h 14, mon terminal a envoyé cinquante adresses à IndexNow, le protocole qui permet de prévenir Bing, et six autres moteurs, qu’une page vient d’être publiée ou modifiée. Dans la seconde qui a suivi, un robot de Bing est venu lire le fichier de clé qui prouve que le site m’appartient. Cette partie du protocole fonctionne exactement comme promis. La suite est plus lente : sur 160 pages signalées en quatre mois, Bingbot a mis un mois, en valeur médiane, à venir les lire. Yandex en a lu près d’un tiers dans l’heure. Et en relisant ces journaux pour écrire cet article, j’ai découvert que mon script de déploiement n’envoyait plus rien depuis le 19 septembre, sans qu’aucune alerte ne me le dise.

Voici donc le protocole, l’outil que j’ai écrit pour m’en servir, et ce que six mois de journaux en disent.

IndexNow pour Bing : la clé, la requête et ce que mesurent mes journaux

Une clé, un fichier, une requête POST

IndexNow a été lancé en octobre 2021 par Microsoft Bing et Yandex¹. Le principe tient en trois pièces. Une clé, de 8 à 128 caractères, lettres, chiffres et tirets. Un fichier texte posé à la racine du site, qui porte le nom de la clé et la contient : c’est la preuve que tu contrôles le domaine. Et une requête : un GET pour une seule adresse, un POST en JSON pour en envoyer jusqu’à 10 000 d’un coup².

1
2
3
4
5
6
7
8
9

{
  "host": "benoit.gouthiere.be",
  "key": "ta-cle-de-8-a-128-caracteres",
  "keyLocation": "https://benoit.gouthiere.be/ta-cle-de-8-a-128-caracteres.txt",
  "urlList": [
    "https://benoit.gouthiere.be/blog/un-article/",
    "https://benoit.gouthiere.be/blog/un-autre-article/"
  ]
}

Ce corps part vers https://api.indexnow.org/indexnow, avec l’en-tête Content-Type: application/json; charset=utf-8. La réponse tient dans un code HTTP :

La documentation précise que le code 200 « only indicates that the search engine has received your URL ». Bing est plus net encore : IndexNow « does not guarantee that web pages will be crawled or indexed »³. Garde ces deux phrases en tête, elles vont servir.

Les moteurs participants s’engagent à se transmettre les adresses reçues. En octobre 2026, la liste officielle en compte sept : Bing, Yandex, Seznam, Naver, Yep, Internet Archive et Amazonbot⁴. Google n’y figure pas. En novembre 2021, il avait annoncé qu’il allait tester « the potential benefits of this protocol »⁵. Près de cinq ans plus tard, il ne l’a toujours pas rejoint.

Un script bash, et une limite que personne n’impose

Mon outil tient en un script bash de 231 lignes, qui s’appuie sur curl et jq. Il connaît trois commandes : submit envoie des adresses, status affiche le compteur du jour, reset efface les entrées du jour dans le journal. Chaque adresse envoyée y devient une ligne JSON, avec la date, l’heure et le code reçu. Une option --dry-run affiche la requête sans l’envoyer.

Le script refuse aussi beaucoup de choses : une adresse hors du domaine, un guillemet, une espace, une extension de fichier source comme .md ou .go. Ce zèle a une date. Le 19 avril 2026, des chemins de fichiers Hugo, guillemets compris, ont été envoyés tels quels, et chacun a consommé une place dans le quota pour une page inexistante.

Ce quota, justement, est de 250 adresses par jour, et c’est moi qui l’ai fixé. Le protocole ne publie aucune limite quotidienne : sa FAQ indique que chaque moteur fixe ses propres seuils par site, et répond 429 quand il juge que tu exagères⁶. Ma limite est un garde-fou contre moi-même, pas une règle de Bing.

Le déploiement s’en sert tout seul. Le serveur republie le site toutes les dix minutes ; le script de déploiement programme donc, avec systemd-run, un second script douze minutes plus tard. Celui-ci liste les fichiers Markdown modifiés entre deux commits, les traduit en adresses, les envoie à IndexNow, puis signale le sitemap à Bing. Sur le papier, plus rien à faire.

Ce que racontent les journaux du serveur

Mon audit de site par un crawler en Go vérifie que les pages sont propres ; il ne dit rien de qui vient les lire. Les journaux du serveur, si. Entre le 15 avril et le 15 août 2026, l’outil a fait 235 envois pour 160 adresses distinctes, tous acceptés par un 200 ou un 202. Pour chaque adresse, j’ai cherché la première visite de chaque robot après le premier envoi.

Yandex a réagi comme le protocole le promet, du moins en avril : presque toutes ses visites rapides datent du 16 au 18 avril. Googlebot, qui ne reçoit rien, est passé trois fois plus vite que Bingbot. Et sur les 109 pages que Bingbot n’avait encore jamais vues, aucune n’a été lue dans la semaine de leur envoi ; il a fallu attendre 32 jours en valeur médiane.

Les limites de la mesure sont réelles. Un seul site, 160 adresses, des robots reconnus à leur nom déclaré, que n’importe qui peut emprunter⁷. Cet article s’appuie sur les journaux du serveur, pas sur les rapports de Bing Webmaster Tools. Mais une chose est sûre : Bing a bien reçu les adresses, puisqu’il a vérifié la clé dans la seconde. Il a ensuite choisi son propre rythme, ce que sa documentation autorise noir sur blanc.

La requête que personne n’envoyait

Le 19 septembre 2026, j’ai sorti les secrets du dépôt. Ils sont désormais chargés dans l’environnement par le script qui lance ma session de travail, et j’ai adapté l’outil le jour même pour y lire la clé. Sauf que systemd-run exécute la tâche différée dans un environnement neuf, qui n’hérite pas des variables du terminal. J’ai vérifié avec systemd 255 : sans option, la variable est absente ; avec --setenv, elle est là⁸.

Résultat : depuis ce jour, les 21 déploiements qui avaient des adresses à signaler ont tous échoué sur le même message, INDEXNOW_KEY non définie. Avant, les 7 envois automatiques avaient tous réussi. Au total, 299 adresses distinctes ne sont jamais parties, dont les 211 pages des guides sur le choix d’un VPN professionnel et le GPU loué pour l’IA.

Je ne l’ai pas vu parce que le script ajoute || echo "(IndexNow failed, non-blocking)", dans un fichier journal que personne n’ouvre. Ne pas bloquer un déploiement parce qu’un moteur de recherche boude, c’est le bon choix. Se taire, non. La correction tient en une option, qui reprend la valeur de la variable dans l’environnement de l’appelant :

1
2
3
4

systemd-run --user \
  --on-active=12min \
  --setenv=INDEXNOW_KEY \
  "$POST_DEPLOY" "$PREV_HEAD"

Le même journal contenait une seconde surprise. À chacune des 62 exécutions depuis avril, le script a aussi signalé le sitemap à Bing, et reçu 62 fois la même réponse : 410 Gone. Bing a fermé cette adresse en mai 2022, parce qu’elle « was often subject to misuse by spammers », en recommandant à la place… IndexNow⁹. Google a annoncé la fermeture de la sienne en juin 2023¹⁰. Mon script frappait à une porte murée depuis six mois, et la porte lui répondait poliment qu’elle était murée.

Deux défauts de conception, enfin. Le script ne voit que ce qui est commité : un article déployé avant son commit passe sous le radar. Et un article daté dans le futur est signalé au déploiement, avant que Hugo ne le publie, alors que la page répond encore 404.

DevOps Dave : Le déploiement prévient Bing tout seul. Je n’y touche plus depuis avril.

Security Sarah : Et il te prévient, toi, quand il échoue ?

DevOps Dave : Il écrit « non-blocking ».

Security Sarah : Dans un fichier que tu ouvres quand ?

DevOps Dave : Quand j’écris un article sur IndexNow, apparemment.

IndexNow tient sa promesse au sens strict : une requête, et Bing sait. Ce qu’il fait de l’information ne regarde que lui, et sur ce site, c’est un mois. Je garde le protocole, parce qu’il ne coûte qu’une requête par déploiement et que six autres services la reçoivent. Mais la vraie leçon de ces journaux ne concerne pas le référencement : un signal qu’on envoie sans vérifier qu’il part n’est pas un signal. C’est une hypothèse. IndexNow te permet de prévenir Bing en une requête. Encore faut-il l’envoyer.

À lire aussi