C'est quoi IndexNow et qui le supporte ?

Un protocole ouvert de notification instantanée des moteurs sur les URL modifiées : vous posez une clé texte à la racine du site et vous POST-ez la liste des URL sur api.indexnow.org. Supporté par Bing et Yandex (plus Seznam, Naver). Google ne supporte pas IndexNow - le protocole ne lui dit rien. Un seul ping se propage à tous les participants du protocole.

IndexNow garantit l'indexation ?

Non. C'est un signal 'la page a changé, viens' - le moteur décide lui-même de venir ou pas et d'inclure ou pas la page dans l'index. Mon exemple : les pings partaient avec le code 200 tout le mois de mai, et le 22 juin Bing avait 1-3 pages sur 77 dans l'index avec zéro erreur d'exploration. Bing voyait tout - et n'indexait pas. Seul un SubmitUrlBatch direct sur les 77 URL a aidé, trois jours après l'index est monté à 26-29 pages.

Comment accélérer le recrawl chez Google ?

Deux canaux qui marchent. Le premier - le sitemap : Google attrapait mes articles frais en 24 heures sans aucun ping. Le deuxième - le Request Indexing manuel dans Search Console, environ 10 URL par jour, réaction de quelques heures à trois jours. L'Indexing API n'est officiellement pas prévue pour des pages ordinaires (seulement offres d'emploi et diffusions) : dans mon test elle répondait 200 à l'envoi mais ne renvoyait pas de métadonnées - rien pour confirmer un recrawl réel.

Quels sont les quotas des outils de recrawl ?

D'après mon expérience, par site : Yandex Webmaster - 150 URL par jour en réexploration via l'API ou l'interface ; Bing SubmitUrlBatch - 100 URL par jour ; Google Request Indexing dans la GSC - environ 10 URL par jour. IndexNow n'a montré aucun quota formel à ces volumes. Pour un site de 77 pages, n'importe laquelle de ces limites suffit largement.

Pourquoi IndexNow renvoie 503 ou 502 ?

L'endpoint api.indexnow.org vit côté Bing et tombe lui-même parfois. Le 29 mai, mon ping de déploiement a reçu 503, le retry - 502, la répétition manuelle plus tard - encore 503. Deux jours après, tout est revenu à 200 sans action de ma part. Conclusion pour l'automatisation : prévoyez des retries avec pause et ne faites pas échouer le déploiement à cause d'un ping indisponible - c'est une étape non critique.

Pourquoi accélérer le recrawl, au fond ?

Deux raisons. La première - les correctifs doivent arriver plus vite dans les résultats : vous réécrivez un title pour le CTR, et le moteur garde l'ancien snippet des semaines. La deuxième - la recherche IA : Copilot tire ses réponses de l'index Bing, et tant que la page n'y est pas, vous n'êtes pas dans les réponses non plus. Mon projet de nettoyage a récolté 40 citations dans Copilot précisément après que j'ai réglé l'index Bing - décortiqué dans un article séparé sur le GEO.

IndexNow, GSC et Yandex : ce qui accélère vraiment le recrawl

Sur IndexNow, on écrit soit ‘branchez-le et les moteurs sauront tout instantanément’, soit rien. Je l’ai fait tourner un mois sur un site réel avec le reste des outils de recrawl - l’API Yandex Webmaster, les submits Bing, le Request Indexing manuel chez Google - et j’ai assemblé le tableau honnête : ce qui fait vraiment bouger l’indexation, et ce qui clignote juste agréablement en code 200.

En bref

IndexNow est pingé automatiquement après chaque déploiement - gratuit et bon marché, branchez-le.

Mais ping ≠ indexation : Bing acceptait les pings et gardait 1-3 pages sur 77 dans l’index.

L’endpoint IndexNow tombe lui-même : 29 mai - 503 et 502 aux retries, deux jours après - de nouveau 200.

Yandex : le levier qui marche - la réexploration via l’API Webmaster, 150 URL/jour, traitement en heures.

Bing : SubmitUrlBatch, 100 URL/jour - c’est lui qui a sorti l’index de 1-3 à 26-29 pages.

Google : sitemap + Request Indexing manuel (~10 URL/jour). L’Indexing API pour pages ordinaires - rien ne se confirme.

Comment mon auto-ping est monté

Le site est du statique sur Astro, déploiement via GitHub Actions : push dans main, 1-2 minutes plus tard les fichiers sont sur l’hébergement. Ensuite, un workflow séparé assemble la liste des URL modifiées et envoie un POST sur api.indexnow.org avec la clé posée en fichier texte à la racine du site. Un seul ping se propage à tous les moteurs participants du protocole - pour moi, Bing et Yandex.

Deux détails qui ne sont sortis qu’en pratique :

Les retries sont obligatoires. Le workflow prévoit des répétitions sur 503/504/429 avec pauses. Ça a servi plus vite que prévu.

Le ping ne doit pas faire tomber le déploiement. Si IndexNow est indisponible - le workflow écrit un avertissement et se termine avec succès. Un ping non livré est une perte non critique : le moteur viendra quand même par le sitemap, juste plus tard.

Chronique d’un mois de pings

Les réponses réelles de l’endpoint d’après les logs de déploiement :

Date	Événement	Réponse
28 mai	Déploiement, auto-ping	200, accepté
29 mai	Déploiement, auto-ping	503, retry - 502
29 mai	Répétition manuelle plus tard	encore 503/502
31 mai	Déploiement, auto-ping	200
1er juin	Ping manuel de 5 URL	200

Le 29 mai, l’endpoint était couché côté Bing - mon infrastructure allait très bien. Deux jours après, il est revenu à la vie tout seul. Si le déploiement échouait à cause du ping, le 29 mai je n’aurais livré aucun correctif.

La conclusion du tableau est ennuyeuse mais importante : IndexNow est une carte postale bon marché, pas une lettre recommandée. L’envoi ne garantit rien, la non-livraison ne casse rien.

Bing : accepte les pings, n’est pas obligé d’indexer

L’histoire la plus parlante du mois. Le 22 juin, je vérifie Bing Webmaster Tools : 1-3 pages dans l’index sur les 77 du sitemap. Avec zéro erreur d’exploration - pas de 4xx ni de 5xx, le crawler passe, les pings sont partis tout le mois en code 200. Bing voyait tout. Et n’indexait pas.

Pourquoi c’est douloureux, c’est un sujet à part : Copilot assemble ses réponses depuis l’index Bing, et tant que le site n’y est pas, pour la recherche IA de Microsoft vous n’existez pas. Sur mon projet de nettoyage, c’est justement l’index Bing qui a donné 40 citations dans Copilot - donc j’ai remarqué l’effondrement vite.

Ce que j’ai fait : via la Bing Webmaster API, envoyé un SubmitFeed (re-soumission du sitemap) et un SubmitUrlBatch sur les 77 URL - les deux requêtes acceptées en code 200. Le quota de soumission d’URL est de 100 par jour, après le batch il en restait 23.

Trois jours après, le 25 juin, l’index est monté à 26-29 pages. Pas les 77, mais depuis 1-3 c’est la différence entre ‘le site n’existe pas’ et ‘le site existe’. Ensuite Bing a complété tout seul.

Morale : pour Bing, le submit direct via la Webmaster API est un signal plus fort que le ping IndexNow. Gardez les deux : le ping - la routine de fond, le submit - le levier manuel en cas d’effondrement.

Yandex : la réexploration marche comme une horloge

Yandex a deux canaux. Il accepte IndexNow - mais mon cheval de trait est ailleurs : la réexploration via l’API Webmaster (la même limite est visible dans l’interface : ‘Réexploration des pages’).

Chiffres d’une seule journée, le 23 juin : envoyé 5 URL modifiées - toutes acceptées en code 202 avec un task_id. À huit heures du soir le même jour, dans les logs - 9 passages avec réponse 2xx : le robot est venu sur chaque URL, certaines explorées deux fois. Quota - 150 URL par jour et par site, pour mes volumes c’est l’infini.

Nuance d’automatisation : les wrappers non documentés au-dessus de cette API vivent leur propre vie (mon outil MCP de réexploration renvoie invariablement ‘Resource not found’), donc le plus fiable est d’appeler l’API Webmaster directement - une simple requête HTTP avec un token OAuth.

Important, là aussi, de ne pas confondre réexploration et indexation : le même Yandex a sorti de l’index 5 de mes pages le 23 juin comme ‘peu demandées’ - alors que la réexploration marchait parfaitement. Le robot vient sur demande ; que la page reste dans l’index, c’est la qualité et la demande qui en décident.

Google : le plus fermé des trois

Avec Google, le tableau est celui-ci :

Le sitemap marche. Les articles frais du blog, Google les attrapait en 24 heures sans aucun ping - vérifié sur quatre articles publiés le même jour : le lendemain, tous étaient au statut ‘indexée’.

Le Request Indexing dans la GSC marche, mais à la main. URL Inspection → Request Indexing, limite de l’ordre de 10 URL par jour, réaction de quelques heures à trois jours. Pour des correctifs ciblés (title réécrit, page clé mise à jour) - un outil correct.

L’Indexing API est une boîte noire. Officiellement, elle n’est prévue que pour les offres d’emploi (JobPosting) et les diffusions (BroadcastEvent). Je l’ai testée sur des pages ordinaires deux fois. Premier essai : le POST urlNotifications:publish renvoie 200 - mais sans champ latestUpdate, et le GetMetadata sur les mêmes URL renvoie 404. C’est-à-dire que ‘accepté’ et ‘fait’ sont deux choses différentes : rien pour confirmer le recrawl, j’ai retiré l’intégration. Deuxième essai, plus tard : envoi via un compte de service avec droits de propriétaire dans la GSC - les 5 URL de nouveau acceptées en code 200. Acceptées - oui ; ce qui se passe ensuite, Google ne le montre pas. Je ne bâtirais pas un process là-dessus.

IndexNow, Google ne le supporte pas du tout. Les pings ne lui parviennent pas, by design.

La conclusion principale : recrawl n’est pas indexation

Sur le même mois, ma statistique GSC s’est accumulée : 58 pages dans l’index, 49 - non. Sur ces 49, la majeure partie est ‘explorée, actuellement non indexée’ et ‘détectée, actuellement non indexée’. Google est déjà passé sur ces pages. Aucun ping, submit ou Request Indexing ne le fera changer d’avis - c’est une question d’autorité : contenu, maillage interne, liens externes.

Les outils de recrawl résolvent exactement une tâche - réduire le temps entre ‘j’ai modifié la page’ et ‘le robot l’a vu’. Cette tâche, ils la remplissent : Yandex vient en heures, Bing après un submit - en jours, Google par le sitemap - en 24 heures. Tout le reste, c’est du contenu régulier et des liens, là je n’ai pas trouvé de raccourci.

Quoi configurer chez vous : plan court

IndexNow - la clé à la racine, auto-ping après déploiement, retries sur 5xx, ne pas faire échouer le déploiement.
Sitemap - à jour, soumis dans la GSC, Yandex Webmaster et Bing WMT. C’est la base, sans elle le reste est cosmétique.
Yandex - pour les correctifs importants, déclencher la réexploration via l’API ou le bouton dans Webmaster (150/jour).
Bing - jeter un œil à l’index toutes les deux semaines ; en cas d’effondrement - SubmitUrlBatch (100/jour).
Google - passer les correctifs ciblés par le Request Indexing (~10/jour), confier le reste au sitemap.
Ne pas confondre les métriques : ‘l’exploration a lieu’ se vérifie dans les logs et Webmaster, ‘l’index existe’ - seulement dans les consoles des moteurs.

Liens utiles

GEO sur des chiffres réels : 40 citations contre 0 - pourquoi se battre pour l’index Bing, au fond.
50 jours de SEO en nettoyage B2B - 194 pages dans Yandex : à quoi ressemble l’indexation quand elle tient au contenu.
Beget CDN sur mutualisé : ce que ça donne vraiment - l’infrastructure du même site.
Cloudflare en Russie en 2026 - le point de départ de ce cycle infrastructure.

Si les moteurs ignorent vos correctifs pendant des semaines ou que le site n’entre pas dans l’index - je le décortique en audit ponctuel ou dans le cadre du SEO. Questions rapides - sur Telegram @dimik90.