IndexNow

Comment fonctionne le protocole

Il n'y a que deux pièces mobiles. La première est une clé : vous générez une chaîne aléatoire, vous l'enregistrez comme un fichier texte brut portant son propre nom à la racine du site, et vous le servez. Ce fichier est public par conception — le servir ouvertement à une URL que seul le propriétaire du site pouvait créer constitue à lui seul la preuve de propriété, et c'est pourquoi une clé IndexNow n'est pas un secret et peut être versionnée avec le code. La seconde pièce est l'envoi : un POST contenant votre hôte, la clé, l'emplacement du fichier de clé et la liste des URL modifiées.

La mécanique est délibérément réduite. La documentation d'IndexNow fixe le plafond à 10 000 URL par POST, bien plus que ce dont la plupart des sites auront besoin en une fois. Le premier envoi avec une nouvelle clé peut répondre HTTP 202 plutôt que 200, parce que le moteur récupère votre fichier de clé pour le vérifier avant d'accepter quoi que ce soit ; une fois cette étape passée, les envois réussis renvoient 200. Un refus vient presque toujours du fichier de clé — absent, renommé, ou servant un contenu différent de la clé envoyée. C'est donc la première chose à vérifier quand un envoi qui fonctionnait se met à échouer.

Quels moteurs figurent sur la liste

IndexNow publie les points de terminaison participants et, à l'heure où ces lignes sont écrites, il s'agit de Bing, Naver, Seznam.cz, Yandex et Yep. Le point de conception à comprendre est qu'on n'envoie qu'une fois : un envoi adressé à n'importe quel point de terminaison participant est partagé avec les autres, il n'y a donc rien à gagner à expédier le même lot cinq fois. Plusieurs plateformes de contenu et CDN embarquent aussi la prise en charge d'IndexNow, ce qui signifie que certains sites envoient déjà sans que personne ne l'ait décidé.

• Google ne figure pas sur cette liste. Envoyer à IndexNow ne fait rien pour Google Search, qui continue de trouver les pages à l'ancienne : par les liens et par le sitemap que vous avez déjà déclaré dans la Search Console. Quiconque vend IndexNow comme un moyen d'entrer plus vite dans Google décrit un autre protocole.
• Bing est la raison pour laquelle la plupart s'en donnent la peine. C'est de loin le plus grand des moteurs participants sur les marchés anglophones, et donc, pour la plupart des sites, celui qui décide si l'après-midi consacré au protocole en vaut la peine.
• Les moteurs régionaux ne sont pas du remplissage. Si la Corée, la Tchéquie ou la Russie sont un marché réel pour vous, Naver, Seznam.cz et Yandex y sont les moteurs domestiques, et leur présence est une vraie raison d'utiliser le protocole, pas un détail négligeable.
• Le discours d'IndexNow lui-même s'appuie sur les réponses par IA. Sa documentation présente le protocole comme une aide pour maintenir vos contenus à jour dans les résultats de recherche assistés par IA — c'est la version honnête de l'argument, puisque la fraîcheur de l'index sous-jacent se situe en amont de tout assistant qui y puise.

Ce qu'un 200 vous apprend vraiment

Il vous apprend que l'envoi a été accepté. C'est tout ce qu'il vous apprend. La documentation d'IndexNow est inhabituellement directe sur ce point : envoyer une URL ne garantit pas son indexation, car le moteur décide toujours de l'explorer ou non selon sa propre planification, son quota d'exploration et ses contrôles de qualité. Le protocole avance une page dans la file d'attente de la découverte ; tout ce qui vient après la découverte reste inchangé.

Nous faisons tourner IndexNow sur agentceres.com comme une étape d'une routine quotidienne et non à chaque build, parce que le protocole demande de ne pas renvoyer excessivement des URL inchangées. L'exécution d'aujourd'hui a lu le sitemap en production et envoyé 415 URL en un seul POST, et le point de terminaison a répondu HTTP 200. Ce nombre constitue tout le retour que nous obtenons. Il n'y a ni rappel, ni statut par URL, ni rien qui signale quand ou si un robot est effectivement passé — la confirmation doit donc venir de Bing Webmaster Tools, de la Search Console pour les moteurs qu'elle couvre, ou de vos propres journaux serveur. Notre émetteur refuse purement et simplement de s'exécuter si le fichier de clé hébergé est absent ou si son contenu diffère de la clé inscrite dans le script, parce que cet écart renvoie un refus qui, autrement, ressemble à une requête échouée ordinaire et passe inaperçu.

• Cela vaut le coup si vous publiez ou modifiez des pages assez souvent pour qu'attendre une réexploration organique constitue un vrai délai : un site de documentation, un ensemble de pages programmatiques, un catalogue e-commerce dont le stock bouge, ou tout cas où une page supprimée qui s'attarde dans un index est gênante.
• Cela n'apporte pas grand-chose si vous publiez quelques pages par mois et qu'elles sont bien maillées en interne. Un budget d'exploration qui couvre déjà confortablement votre site n'a pas besoin d'aide pour être dépensé.
• Ce n'est jamais un substitut à la raison d'explorer. Annoncer plus vite une page pauvre la fera simplement regarder plus tôt. C'est le même levier qu'une balise canonique propre ou qu'un fichier llms.txt : de la plomberie qui retire un obstacle, pas une raison de s'y intéresser.