Requêtes AJAX bloquées par robots.txt : voir ce que Google ignore

Vous ouvrez l’inspection d’URL dans la Search Console, et là, le verdict tombe : « Bloquée par le fichier robots.txt ». Pourtant, votre appel AJAX fonctionne à merveille dans le navigateur. Le problème, c’est que Google ne le voit pas, et il vous le dit à sa manière. Entre une ligne Disallow posée un peu vite et une URL paramétrée qu’on croyait protéger, il y a un monde. On va démêler ce que Google ne voit pas, pourquoi, et comment corriger sans casser ce qui marche déjà en production.

Ce que l’inspection d’URL vous montre vraiment

Première chose à faire, ouvrir l’outil d’inspection d’URL et coller l’adresse exacte de votre requête AJAX. Dans la section Indexation des pages, le message « Bloquée par le fichier robots.txt » s’affiche quand la page est effectivement bloquée. Ce diagnostic est fiable.

Il vient directement de Googlebot et vous évite de chercher la panne ailleurs pendant des heures. Pour approfondir ce type de vérification, creaweb3000.com détaille la mécanique d’indexation et les pièges classiques des redirections mal posées sur un site en production.

Ensuite, il faut comprendre la conséquence. Une page bloquée par le fichier robots.txt ne s’affichera probablement pas dans les résultats de recherche et, si elle s’affiche malgré tout, elle ne présentera pas de description. Vous perdez donc le contrôle du snippet. Parfois, la page remonte quand même avec un titre tronqué. C’est le pire des deux mondes : bloquée pour vous, visible pour l’internaute.

Ne confondez pas ce cas avec l’erreur « Indexé, bien que bloqué par robots.txt ». Elle correspond à une autre situation : les robots de Google ont trouvé la page, l’ont lue, puis ont remarqué qu’elle était bloquée dans le fichier robots.txt. Google connaît donc son existence sans pouvoir en lire le contenu. Cette distinction change tout dans la façon de corriger le problème.

Wildcards et Disallow : ce que Google comprend, et ce que les autres ignorent

Le Googlebot est capable de lire les wild cards dans le fichier robots.txt. La directive Disallow: /*action=commenter est comprise par Google, c’est vrai. Mais attention, ce n’est pas un standard. Les autres robots, ceux des moteurs concurrents ou des outils tiers, peuvent l’ignorer complètement. Vous bloquez pour Google et vous laissez passer pour les autres.

Du coup, la question n’est pas « est-ce que ça marche ? » mais « est-ce que ça marche pour tout le monde ? ». La réponse est non. Un Disallow avec wildcard reste une directive propriétaire, tolérée par Google mais absente des spécifications du protocole d’exclusion. Si votre objectif est de nettoyer l’index, ce n’est pas l’outil adapté à la situation.

Les situations qui réclament autre chose qu’un Disallow

Beaucoup de webmasters posent un Disallow par réflexe, sans mesurer l’effet réel sur le crawl et sur l’indexation. Cette habitude vient souvent d’une vieille consigne répétée partout. Or elle produit régulièrement l’inverse du résultat attendu, en privant Google de l’information dont il a besoin pour trancher entre deux variantes d’une même adresse. Voici les cas où cette approche pose problème concrètement.

• Vous voulez empêcher l’indexation d’une URL paramétrée, mais le Disallow bloque aussi le crawl, donc Google ne voit jamais la balise canonique que vous avez posée.
• Une page produit avec un paramètre de tri qui génère des dizaines de variantes.
• Faut-il bloquer ou consolider quand la même requête AJAX sert plusieurs affichages ?
• Un contenu dupliqué entre une version avec et sans paramètre, que vous voulez fusionner vers une seule adresse.

Dans chacun de ces cas, le blocage pur et simple ne règle pas le fond. Il empêche Google de voir, mais n’indique pas quelle version doit compter. Et c’est exactement ce que vous voulez obtenir : une seule version qui compte, pas zéro. Sur ce point, voir aussi notre article sur comment fonctionne l’indexation Google ? Le guide complet pour booster votre visibilité.

La canonique plutôt que le blocage

La solution de l’URL canonique consiste à insérer une balise dans le code HTML de la page. Concrètement : <link rel= »canonical »> avec l’adresse de référence en attribut. Cette ligne indique à Google quelle adresse doit être considérée comme la référence, même si d’autres variantes existent.

L’avantage est net : Google peut crawler toutes les variantes, lire la canonique sur chacune, et consolider le signal vers l’URL que vous avez choisie. Vous ne cachez rien, vous orientez. À l’inverse, un Disallow empêche la lecture de la canonique, donc Google ne saura jamais vers quoi consolider. C’est le piège classique du blocage réflexe.

Un point de vigilance quand même : la canonique doit pointer vers une URL accessible, non bloquée par le robots.txt, et renvoyer un code de succès. Si la cible est elle-même bloquée, la directive est ignorée. Vérifiez toujours les deux côtés de la chaîne avant de valider.

Nettoyer ce qui est déjà indexé

Si des URL paramétrées sont déjà dans l’index, la canonique seule mettra du temps à faire effet. Vous pouvez accélérer les choses : les URL déjà indexées avec un paramètre peuvent être supprimées manuellement via l’option « URL à supprimer » du menu « Index Google » dans la Search Console (ex-Google Webmaster Tools).

Cette suppression est temporaire, mais elle laisse le temps à Google de recrawler et de prendre en compte vos canoniques. Combinez les deux : canonique posée, puis demande de suppression des variantes gênantes. Franchement, c’est la méthode la plus propre pour repartir sur une base saine.

Et pour les requêtes AJAX dont le contenu doit vraiment rester inaccessible à l’index, posez un Disallow ciblé. Vérifiez ensuite avec l’inspection d’URL que le blocage est bien celui que vous vouliez. Un robots.txt se relit, se teste, se corrige.

Ce que Google voit dépend surtout de ce que vous lui laissez voir

Bloquer une requête AJAX avec un Disallow semble rapide, mais ça prive Google de l’information dont il a besoin pour consolider vos URL. La canonique fait le travail inverse : elle ouvre la porte et désigne la bonne adresse.

La Search Console vous donne le diagnostic, encore faut-il le lire correctement et faire la différence entre « Bloquée » et « Indexé, bien que bloqué ». Wildcards ou pas, la vraie question reste de savoir ce que vous voulez montrer. Avez-vous vérifié récemment ce que Google lit vraiment dans votre robots.txt ?