Les X-Robots-Tag dans l'AJAX sont-ils vraiment ignorés par Google ?

Pourquoi Google ignore-t-il les X-Robots-Tag dans les appels AJAX ?

Les balises X-Robots-Tag sont des en-têtes HTTP qui permettent de contrôler l'indexation sans toucher au HTML. Elles fonctionnent parfaitement pour les ressources classiques (pages, PDF, images). Mais quand il s'agit de requêtes AJAX, Google ne les lit tout simplement pas.

La raison ? Le moteur de rendu de Google exécute le JavaScript, récupère le contenu final injecté dans le DOM, mais ne scrute pas les en-têtes HTTP des requêtes XHR ou Fetch lancées en arrière-plan. Ces appels restent invisibles au niveau de l'indexation, même si leur contenu finit affiché sur la page. Google se concentre sur ce qui arrive dans le DOM après exécution complète du JS.

Qu'est-ce que cela change pour un site chargé en AJAX ?

Si votre architecture repose sur des Single Page Applications (SPA) ou des chargements dynamiques massifs, vous ne pouvez pas compter sur les X-Robots-Tag côté serveur pour bloquer certaines portions de contenu. Google indexera ce qui est rendu dans le HTML final, peu importe ce que vos en-têtes HTTP disent lors des requêtes internes.

Concrètement, un module de filtres de recherche qui charge des résultats via fetch() avec un X-Robots-Tag: noindex ne sera pas respecté. Google verra le contenu injecté et l'indexera normalement si rien d'autre ne l'en empêche. C'est un piège classique sur les sites e-commerce avec filtres combinés ou les applications complexes.

Quelles sont les alternatives techniques fonctionnelles ?

Mueller mentionne deux solutions : robots.txt pour bloquer les endpoints JSON/API qui servent le contenu AJAX, ou injection de meta robots via JavaScript directement dans le head du document après le chargement. La première bloque le crawl des ressources, la seconde ajoute des directives d'indexation dans le DOM final que Google peut lire.

Le robots.txt fonctionne bien si vous voulez empêcher Google de crawler les URLs qui retournent les données JSON. Mais attention : bloquer en robots.txt empêche le crawl, pas l'indexation si l'URL est liée ailleurs. Pour un contrôle fin, l'injection JS de balises meta reste la plus fiable sur une SPA.

• Google lit uniquement le DOM final après exécution du JavaScript, pas les en-têtes HTTP des requêtes internes AJAX
• Les X-Robots-Tag dans les réponses XHR/Fetch sont totalement ignorés par le moteur d'indexation
• Solution 1 : bloquer les endpoints JSON en robots.txt pour empêcher le crawl des ressources
• Solution 2 : injecter des balises meta robots (noindex, nofollow) via JavaScript dans le head après chargement
• Cette limitation affecte principalement les architectures SPA et les sites avec chargement dynamique massif de contenu

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même une confirmation précieuse d'un comportement que beaucoup de SEO soupçonnaient sans avoir de validation officielle. Sur le terrain, on constate régulièrement que des contenus chargés en AJAX finissent indexés malgré des en-têtes HTTP restrictifs. Google rend le JavaScript, assemble le DOM, et indexe ce qu'il voit à l'écran. Les en-têtes des sous-requêtes ne jouent aucun rôle dans cette décision.

Ce qui manque ici, c'est la nuance entre crawl et indexation. Mueller dit que Google ignore ces en-têtes, mais ne précise pas si Googlebot crawle quand même les endpoints AJAX pour d'autres raisons (découverte de liens, analyse de la structure). [A vérifier] sur des logs serveur : les URLs JSON appelées en AJAX sont-elles visitées directement par Googlebot, ou uniquement via le rendu JS ?

Dans quels cas cette règle pose-t-elle vraiment problème ?

Les architectures headless ou JAMstack qui servent du contenu via API et comptaient sur les X-Robots-Tag pour gérer l'indexation au niveau API sont directement concernées. Si vous avez des dizaines de milliers de combinaisons de filtres, de pages de résultats paginés ou de variantes de contenu chargées dynamiquement, l'absence de contrôle fin via en-têtes HTTP complique sérieusement la gestion du crawl budget.

Autre cas problématique : les sites qui chargent des blocs de contenu dupliqué (avis clients, descriptions produits partagées entre variantes) et espéraient utiliser noindex sur ces fragments. Google verra tout dans le DOM final et indexera potentiellement du duplicate content que vous pensiez avoir neutralisé côté serveur.

Quelles sont les zones grises non couvertes par Mueller ?

Mueller reste vague sur le comportement exact de Googlebot face aux endpoints JSON bloqués en robots.txt mais liés ailleurs. Est-ce que Google indexe ces URLs sans les crawler, uniquement sur la base de liens externes ? [A vérifier] car la doc officielle dit qu'une URL bloquée en robots.txt peut quand même être indexée si elle reçoit des backlinks.

Autre point flou : que se passe-t-il si vous injectez un meta robots noindex via JS, mais que Google n'exécute pas complètement le JavaScript pour une raison X (timeout, erreur, crawl budget épuisé) ? Le contenu sera-t-il indexé par défaut ? Probablement oui, et c'est un risque non négligeable sur les gros sites où le rendu JS n'est jamais garanti à 100%.

Que faut-il faire concrètement sur un site AJAX-heavy ?

Première étape : auditer tous les endpoints qui servent du contenu dynamique (API JSON, fragments HTML, modules chargés en XHR). Identifiez ceux qui retournent du contenu que vous ne voulez pas voir indexé. Ensuite, choisissez votre méthode : bloquer ces URLs en robots.txt si elles ne doivent jamais être crawlées, ou injecter des directives meta robots via JS si vous voulez un contrôle page par page.

Pour les SPA, privilégiez une approche hybride : robots.txt pour les routes API pures (endpoints /api/*, /data/*), et injection JS de meta robots pour les pages applicatives où le contenu est assemblé côté client. Testez systématiquement le rendu avec l'outil d'inspection d'URL de la Search Console pour vérifier que vos directives apparaissent bien dans le DOM final.

Comment vérifier que mes directives d'indexation sont bien prises en compte ?

Utilisez l'outil "Inspection d'URL" dans la Search Console et regardez le code HTML rendu. Si vous avez injecté un meta robots noindex via JavaScript, il doit apparaître dans le head du HTML affiché par Google. Si ce n'est pas le cas, votre script ne s'exécute pas correctement ou trop tard dans le cycle de vie de la page.

Vérifiez aussi les logs serveur pour voir si Googlebot crawle directement vos endpoints JSON. Si oui, assurez-vous qu'ils sont bien bloqués en robots.txt ou qu'ils renvoient un 404/410 si le contenu n'a pas de sens hors contexte applicatif. Un endpoint qui renvoie du JSON brut ne sera normalement pas indexé, mais un endpoint qui renvoie du HTML fragmentaire peut l'être.

Quelles erreurs éviter absolument ?

Ne comptez jamais sur les X-Robots-Tag dans les réponses AJAX pour contrôler l'indexation. C'est la principale leçon ici. Si vous avez un header X-Robots-Tag: noindex sur vos requêtes fetch(), supprimez-le : il ne sert à rien et crée une fausse impression de sécurité.

Évitez aussi de bloquer en robots.txt des ressources JS/CSS critiques pour le rendu. Google a besoin d'exécuter votre JavaScript pour voir le contenu final et les directives d'indexation que vous injectez. Bloquer les ressources nécessaires au rendu revient à empêcher Google de lire vos meta robots injectés via JS, et donc à perdre tout contrôle sur l'indexation.

• Auditer tous les endpoints API/JSON qui servent du contenu dynamique et identifier ceux à exclure de l'indexation
• Bloquer en robots.txt les routes API qui ne doivent jamais être crawlées (/api/*, /data/*, etc.)
• Injecter des balises meta robots (noindex, nofollow) via JavaScript dans le head pour un contrôle page par page
• Tester le rendu avec l'outil d'inspection d'URL de la Search Console pour vérifier la présence des directives dans le DOM
• Vérifier les logs serveur pour détecter un crawl direct des endpoints JSON par Googlebot
• Ne jamais bloquer en robots.txt les ressources JS/CSS critiques pour le rendu de la page