IndexNow : notifier Bing sans confondre envoi et indexation

IndexNow permet de notifier les moteurs participants lorsqu’une URL est ajoutée, modifiée ou supprimée. La requête ne pousse pas la page dans un index et ne réserve aucune place dans un résultat génératif. Elle transmet un signal de changement que chaque moteur reste libre d’explorer, d’indexer et d’utiliser.

Une bonne implémentation part donc du déploiement : quelles URL ont réellement changé et sont publiques après la mise en ligne ? Elle ne renvoie pas tout le sitemap à chaque build, ne soumet pas les prévisualisations et ne transforme pas un code HTTP 200 en preuve de visibilité.

Ce guide montre la vérification de propriété, les formats pour une URL et un lot, la lecture des réponses, la construction d’un journal et les contrôles à effectuer avant l’automatisation.

Réponse en bref

Pour utiliser IndexNow proprement :

1. vérifiez si le CMS, le CDN ou le plugin le fait déjà ;
2. choisissez un seul propriétaire de la soumission ;
3. créez une clé conforme et publiez son fichier de vérification ;
4. envoyez d’abord une seule URL publique réellement modifiée ;
5. vérifiez le code HTTP et l’accès au fichier de clé ;
6. construisez ensuite un lot limité aux URL ajoutées, modifiées ou supprimées ;
7. déclenchez la notification après un déploiement réussi ;
8. conservez le sitemap pour l’inventaire complet ;
9. contrôlez exploration et indexation dans les outils du moteur ;
10. ne présentez jamais la réception de la requête comme une garantie d’indexation ou de citation.

Un 200 signifie que le moteur a reçu la soumission. Un 202 signifie que l’URL a été reçue et que la validation de la clé est en attente. Aucun des deux ne prouve que la page est indexée.

Ce que fait réellement IndexNow

Le protocole transporte un message très court : « cette URL de ce domaine vient de changer ». La documentation autorise les ajouts, mises à jour et suppressions. Le moteur peut alors décider de récupérer la version récente.

Il faut distinguer cinq événements :

Événement	Preuve possible
notification émise	ligne du journal local
notification reçue	réponse HTTP 200 ou 202
URL explorée	rapport du moteur ou log serveur vérifié
URL indexée	outil d’inspection ou rapport du moteur
URL affichée ou citée	observation dans une interface définie

Passer d’une ligne à la suivante n’est pas automatique. Une page peut être reçue puis refusée pour un problème de qualité, de duplication, de robots, de noindex, de réponse HTTP ou de choix propre au moteur.

La FAQ officielle le dit explicitement : soumettre une URL avertit les moteurs d’un changement, mais ne garantit pas son indexation. Chaque moteur participant conserve sa propre décision.

Vérifier qu’IndexNow n’est pas déjà actif

Les doublons techniques commencent souvent ici. Un CDN, un hébergeur, un CMS et un plugin SEO peuvent tous notifier la même URL.

Avant de coder, vérifiez :

• la configuration du CMS ;
• les extensions SEO actives ;
• le tableau de bord du CDN ;
• les fonctions de l’hébergeur ;
• les tâches planifiées ;
• les scripts de build ou de déploiement ;
• la source affichée dans IndexNow Insights de Bing Webmaster Tools.

La FAQ IndexNow recommande de commencer par le support natif du CMS, de l’hébergeur ou du plugin. Si une intégration existante envoie correctement les changements, ajoutez au besoin une vérification plutôt qu’un deuxième émetteur.

Décidez qui possède la soumission. Ce composant doit connaître l’état final public. Un éditeur de contenu sait qu’un brouillon a changé, mais seul le déploiement sait si cette version est réellement en ligne.

Créer et vérifier la clé

La documentation prévoit une clé de 8 à 128 caractères utilisant lettres, chiffres et tirets. La méthode recommandée consiste à publier à la racine un fichier texte UTF-8 dont le nom est la clé suivie de .txt et dont le contenu est exactement la clé.

Exemple fictif :

URL  : https://www.example.com/EXAMPLE-INDEXNOW-KEY.txt
Corps: EXAMPLE-INDEXNOW-KEY

N’utilisez pas cette valeur d’exemple. Générez la vôtre selon la documentation du protocole. Ne réutilisez ni mot de passe, ni jeton d’API, ni donnée personnelle. Même si le fichier de vérification doit être accessible au moteur, une clé IndexNow ne doit pas devenir le nom ou le contenu d’un secret privé de l’organisation.

Contrôlez depuis le Web public :

• réponse HTTP 200 ;
• type de contenu texte acceptable ;
• absence de redirection inattendue ;
• corps exact, sans balise HTML ;
• même schéma et même hôte que les URL soumises ;
• absence de blocage par authentification ou pare-feu.

Le protocole accepte aussi un fichier placé dans un sous-répertoire avec keyLocation. Dans ce cas, la portée des URL est limitée par son emplacement. La documentation recommande la racine pour le cas général.

Soumettre une seule URL

Le format conceptuel est :

https://api.indexnow.org/indexnow
  ?url=https%3A%2F%2Fwww.example.com%2Fguide%2F
  &key=VOTRE_CLE_INDEXNOW

La valeur url doit être complète, appartenir à l’hôte vérifié et être correctement encodée. L’endpoint global partage les notifications avec les moteurs participants selon les règles du protocole.

Pour un premier test :

1. publiez une modification réelle sur une URL indexable ;
2. ouvrez l’URL et vérifiez son contenu final ;
3. contrôlez canonical, robots et code HTTP ;
4. vérifiez le fichier de clé ;
5. effectuez la requête ;
6. enregistrez l’heure, l’URL, l’endpoint et le statut ;
7. ne renvoyez pas immédiatement l’URL si rien n’a changé.

La documentation précise qu’un 200 indique seulement la réception de l’URL. Cette phrase doit rester dans le rapport, car elle empêche une conclusion SEO excessive.

Soumettre un lot d’URL

Pour plusieurs changements, IndexNow accepte un POST JSON. La documentation annonce jusqu’à 10 000 URL par requête.

{
  "host": "www.example.com",
  "key": "VOTRE_CLE_INDEXNOW",
  "urlList": [
    "https://www.example.com/nouveau-guide/",
    "https://www.example.com/page-mise-a-jour/",
    "https://www.example.com/ancienne-page/"
  ]
}

Le troisième élément peut représenter une URL supprimée ou redirigée. Le moteur doit pouvoir constater son nouvel état lors de l’exploration.

Avant l’envoi, validez :

• même hôte que le champ host ;
• URL absolues et encodées ;
• absence de doublon ;
• protocole final correct ;
• seulement des routes publiques ;
• liste bornée aux changements du déploiement ;
• aucun paramètre de prévisualisation, de session ou de suivi ;
• aucun fichier privé.

Un lot de dix URL utiles vaut mieux qu’un lot de dix mille URL inchangées.

Lire les codes de réponse

La spécification documente six familles principales.

Code	Signification documentée	Action opérationnelle
200	URL soumise avec succès	enregistrer la réception, puis observer séparément
202	URL reçue, validation de clé en attente	vérifier le fichier et attendre la validation
400	format invalide	corriger la requête avant tout nouvel essai
403	clé non valide ou non trouvée	contrôler nom, contenu, accès et emplacement
422	URL hors de l’hôte ou contrat non respecté	contrôler hôte, schéma, portée et liste
429	trop de requêtes	arrêter la rafale et reprendre selon les indications du service

Ne convertissez pas tous les statuts non 200 en retry immédiat. Un 400, un 403 ou un 422 demande une correction. Répéter la même requête ne la rendra pas valide. Un 429 indique qu’il faut réduire la fréquence ou la taille du lot.

Le journal peut contenir :

submitted_at
deployment_id
endpoint
host
url_count
url_list_fingerprint
response_status
key_check_status
retry_after
next_action

N’enregistrez pas la clé dans les logs généraux. Conservez uniquement une référence à la configuration utilisée ou une empreinte non réversible si elle apporte une valeur de diagnostic.

Construire la liste depuis les changements réels

L’entrée du système n’est pas le sitemap complet. C’est un ensemble de changements entre deux versions publiées.

version précédente publique
          ↓ comparaison
version nouvelle publique
          ↓
ajouts + modifications éditoriales + suppressions ou redirections
          ↓ filtres d’indexabilité
lot IndexNow

Pour chaque route, conservez un type de changement :

• added : nouvelle URL publique ;
• updated : contenu ou métadonnée utile réellement modifiés ;
• removed : réponse 404, 410 ou retrait documenté ;
• redirected : ancienne URL et destination finale ;
• unchanged : aucune notification.

Un nouveau hash de fichiers compilés ne prouve pas une modification éditoriale. Les bundles, noms d’assets et fragments de navigation peuvent changer sans que la page mérite une notification distincte.

À l’inverse, un changement de prix, de disponibilité, de date, de contenu principal, de canonical ou de redirection mérite une détection explicite. Le type de site détermine la règle.

Placer la notification après le déploiement

L’ordre sûr est :

1. construire et valider ;
2. déployer ;
3. vérifier que l’URL publique répond ;
4. contrôler canonical et robots ;
5. envoyer le lot ;
6. enregistrer la réception ;
7. effectuer les vérifications live restantes.

Si la notification part avant la mise en ligne, le moteur peut récupérer l’ancienne version. Si le déploiement échoue ensuite, le journal affirme qu’un changement a été annoncé alors qu’il n’existe pas en production.

Une opération de notification doit être idempotente au niveau du déploiement : un redémarrage du pipeline ne doit pas créer une boucle de soumissions. Enregistrez le couple deployment_id + url + change_type. L’article sur l’idempotence d’un workflow IA détaille la construction de cette protection.

IndexNow, sitemap, lastmod et liens internes

Ces mécanismes répondent à des questions différentes.

Mécanisme	Rôle principal
IndexNow	notifier un changement récent aux moteurs participants
sitemap XML	présenter un inventaire durable des URL canoniques
lastmod	indiquer une modification réelle dans le sitemap
lien interne	rendre l’URL accessible dans le parcours et l’architecture
canonical	exprimer l’URL préférée parmi des variantes

Microsoft Bing recommande de conserver les sitemaps pour la couverture complète et d’utiliser IndexNow pour les changements en temps réel. Sa documentation sur la recherche alimentée par l’IA précise qu’aucun outil ne garantit quand ni comment un contenu apparaîtra dans une réponse générée.

Ne retirez donc pas le sitemap après avoir activé IndexNow. Maintenez des lastmod fidèles et ajoutez de vrais liens internes. Le protocole de fraîcheur éditoriale explique comment aligner contenu, date et sitemap.

Vérifier dans Bing Webmaster Tools

IndexNow Insights peut montrer notamment :

• les URL soumises ;
• l’heure de soumission ;
• la source de la notification ;
• les tentatives d’exploration ;
• les URL indexées ;
• des anomalies ou éléments à examiner.

Ces rapports aident à répondre à trois questions distinctes : l’intégration émet-elle, Bing reçoit-il et que devient l’URL ensuite ?

Une URL absente du rapport peut révéler un mauvais endpoint, un autre hôte, une clé invalide, un émetteur non identifié ou un délai. Une URL reçue mais non indexée demande une lecture de l’accessibilité, de la qualité, de la duplication et des directives, pas une nouvelle rafale de soumissions.

Le rapport AI Performance de Bing Webmaster Tools traite une étape encore différente : les citations observées dans les expériences couvertes. IndexNow ne remplace pas ce suivi.

Relation avec les moteurs de réponse

IndexNow peut contribuer à la découverte plus rapide d’une version récente par les moteurs qui participent au protocole. Il ne transmet pas une réponse prête à citer et ne dicte pas la représentation d’une entité.

Pour qu’une page soit utile après l’exploration, elle doit encore :

• répondre à une intention claire ;
• être accessible et indexable ;
• montrer des faits et sources contrôlables ;
• distinguer date de publication et date de révision ;
• être reliée au reste du site ;
• éviter les doublons et contradictions ;
• proposer une information suffisamment précise pour le lecteur.

IndexNow traite le moment du changement. Le contenu, les preuves et la décision du moteur restent séparés.

Les 12 tests de l’intégration

1. le fichier de clé répond publiquement avec son contenu exact ;
2. une URL valide renvoie 200 ou 202 ;
3. une clé volontairement incorrecte est refusée ;
4. une URL d’un autre hôte est bloquée avant l’envoi ;
5. une route noindex est exclue du lot ;
6. une prévisualisation n’est jamais soumise ;
7. deux changements de la même URL dans un déploiement produisent une entrée ;
8. un déploiement échoué ne produit aucune notification ;
9. une reprise du pipeline ne renvoie pas le même lot sans décision ;
10. une suppression conserve l’ancienne URL à notifier ;
11. un 429 arrête la rafale et respecte la reprise prévue ;
12. le sitemap final contient toutes les URL publiques canoniques, même non modifiées.

Ajoutez un test rendu : ouvrez une URL du lot depuis l’extérieur, vérifiez le contenu attendu, le canonical, les directives robots et les liens principaux. La notification ne doit jamais précéder cette preuve.

Checklist de production

• une seule intégration possède la soumission ;
• la clé n’est pas réutilisée comme secret privé ;
• le fichier de vérification est accessible ;
• les URL appartiennent à l’hôte déclaré ;
• le lot provient des changements réellement déployés ;
• les brouillons et routes privées sont exclus ;
• les codes HTTP conduisent à des actions différentes ;
• les retries sont bornés ;
• le journal ne contient ni clé, ni cookie, ni donnée personnelle ;
• le sitemap et les liens internes restent maintenus ;
• Bing Webmaster Tools est utilisé pour observer, pas pour promettre ;
• le rapport distingue réception, exploration, indexation et citation.

Limites

IndexNow est un protocole de notification pour les moteurs participants. Il ne garantit ni exploration immédiate, ni indexation, ni position, ni trafic, ni présence dans une réponse générée. Un statut HTTP réussi prouve seulement que la soumission a été reçue selon le contrat documenté.

Les moteurs, endpoints, limites de débit, intégrations de CMS et rapports peuvent évoluer. La documentation et la liste des participants doivent être vérifiées au moment de l’implémentation.

Ce guide n’exécute aucune soumission pour un site tiers et ne fournit aucune clé réelle. Les exemples utilisent un domaine et des valeurs fictifs. Une automatisation de production doit être testée sur son propre hôte, après autorisation et avec un journal adapté.

À propos de l’auteur

Je suis Ayoub Kahouadji, consultant SEO/GEO et développeur Python. Je travaille sur des pipelines où un signal de découverte reste séparé des preuves d’exploration, d’indexation et de visibilité.

Prochaine étape

Vérifiez d’abord si votre CMS, CDN ou plugin notifie déjà IndexNow. Sinon, publiez le fichier de clé, envoyez une seule URL réellement modifiée puis consignez le statut sans conclure sur l’indexation. Pour relier cette intégration au sitemap et à la mesure, consultez la page consultant SEO et GEO.