4 078 URL soumises à IndexNow depuis un mutualisé : ce que le 429 raconte vraiment
Le même paquet refusé par un point d’entrée et accepté par l’autre, à la minute près. La cause n’est ni le site ni la clé : c’est l’adresse IP partagée.
Soumettre des milliers d’adresses à IndexNow depuis un hébergement mutualisé se heurte tôt ou tard à un HTTP 429. Chez nous, le refus est venu des deux points d’entrée Microsoft, api.indexnow.org et www.bing.com/indexnow, alors que la même machine obtenait 200 pour un autre domaine. Le paquet refusé est passé en 202 chez Yandex à la seconde suivante.
Ce que fait IndexNow, en deux phrases
Le protocole permet de prévenir un moteur qu’une adresse vient d’être créée ou modifiée, au lieu d’attendre qu’il repasse la découvrir. On dépose un fichier clé à la racine du site, on envoie la liste des URL en JSON, le moteur vérifie la clé et met les adresses en file d’exploration. Les points d’entrée se relaient les soumissions : viser l’un plutôt que l’autre ne double aucune soumission.
Le 429 dépend de deux variables, pas d’une
Notre premier constat était « le plafond se compte par domaine, pas par IP ». Il était incomplet. Mesuré depuis un poste : un annuaire de plus de 12 000 pages et un second annuaire rendaient 429, ce site-ci rendait 200. Mesuré depuis le serveur mutualisé, dans la même minute : ce site-ci rendait 429 alors que l’annuaire venait d’y faire accepter 12 000 adresses. Le domaine et l’adresse IP de départ comptent tous les deux, et l’état se décale de quelques minutes d’un point d’entrée à l’autre.
Vous lisez la suite le mardi
Chaque semaine, la lettre reprend une série publique : la valeur, sa date, sa source. Quatre minutes, le mardi matin.
En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.
Le diagnostic tient donc en une expérience : envoyer le même paquet à un autre point d’entrée. S’il passe, le problème n’est ni le fichier clé ni le format JSON.
La rotation des points d’entrée, puis une file d’attente
Le code essaie api.indexnow.org, puis yandex.com/indexnow, puis www.bing.com/indexnow, et s’arrête au premier 200 ou 202. Le correctif durable a été une file d’attente persistante au lieu d’un envoi unique : une adresse ne quitte la file que sur un 200 ou un 202, un refus laisse le paquet en place, et une tâche planifiée horaire vide la file par paquets de 1 000. Le dossier de la file refuse toute lecture directe.
Résultat le 2026-08-25 : 12 484 adresses acceptées pour l’annuaire d’hôtellerie, 3 541 pour l’annuaire de pâtisseries, 17 pour ce site.
Un envoi sans compte rendu est un envoi sans preuve
Une première version du module de ce site envoyait sa notification sans attendre la réponse et sans rien écrire dans un journal. Les refus passaient inaperçus. La version suivante attend la réponse, bascule de yandex.com vers api.indexnow.org et garde le compte rendu des trente derniers envois. Second défaut : le fichier n’existait qu’en production, en trois exemplaires identiques, sans copie de référence dans le dépôt local.
Autre piège de la file : la fonction qui soumet « un lot » rechargeait d’abord toute la collecte avant d’envoyer, si bien que l’appeler en boucle ne vidait jamais rien. Sur l’annuaire de pâtisseries, 4 078 adresses sont passées en cinq paquets, tous en HTTP 200, après avoir rempli la file une seule fois puis drainé par paquets de 1 000.
Ce que ça ne fait pas
IndexNow accélère la découverte. Il n’achète pas l’indexation, et encore moins le classement. Le cas où l’outil vaut son installation est le site qui publie souvent et dont les pages ont une valeur qui se périme. Pour un corpus restreint de contenu intemporel, c’est de l’hygiène, pas un levier : le facteur limitant reste le nombre et la qualité des pages.
La lettre du mardi
Une fois par semaine, le mardi : une série publique de la Banque mondiale ou de la BCE, ce qu’elle dit, avec sa date et sa source. Quatre minutes de lecture.
En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.