Attention si vous utilisez des jokers (astérisques) dans votre fichier robots.txt : Google vient de modifier (sans communication officielle à ce sujet) sa façon de les interpréter. Un changement qui peut avoir des conséquences plus ou moins néfastes sur votre indexation dans le moteur de recherche...
C'est le site Search Foresight qui nous l'indique : Google a lancé dernièrement des messages d'alerte dans sa Search Console pour certains sites qui pourraient voir leurs pages bloquées et ne plus être crawlées suite à une nouvelle interprétation du fichier robots.txt par les spiders du moteur.
Explication : si votre fichier robots.txt contient des directives utilisant l'astérisque (joker) telles que celle-ci : Disallow: *terme, il faut maintenant les libeller ainsi pour que Google les prenne en compte (avec un "/" avant l'astérisque) : Disallow: /*terme. Un seul petit caractère qui peut induire de gros changements dans l'indexation de votre site...
Vérifiez donc bien votre fichier robots.txt pour vérifier s'il contient ou pas ce type de joker. Et corrigez la situation au cas où. Un webmaster averti en vaut toujours deux...
 Un spider (allégorie 🙂 ). Source de l'image : DR |
J’ai résolu mon problème de robots.txt.
Finalement rien à voir avec l’astérisque, mais on dirait que la détection du problème par Google correspond à la même date que celle du problème d’absence de « / » avant un alias « * ».
Pour faire court, les Disallow qui pointaient vers des pages (ou dossier) en redirection 301 étaient considérés par la Console Search de Google comme un problème majeur depuis quelques jours, alors que le robots.txt et ces redirections sont en place depuis plusieurs années…
Spéc° à mettre à jour : https://developers.google.com/webmasters/control-crawl-index/docs/robots_txt?hl=fr, qui indiquait « La valeur du chemin d’accès doit commencer par « / » pour désigner la racine. Si nous trouvons un chemin d’accès sans barre oblique initiale, nous pouvons faire comme si elle y figurait. «
Par contre, les * dans le robots.txt j’en ai utilisé très souvent mais en respectant la règle officielle de Google : https://support.google.com/webmasters/answer/6062596?hl=fr où justement il n’a jamais été marqué de mettre des règles Disallow : *.mais du Disallow: /*
Bref, on annonce que Google n’a pas officiellement dit qu’il ne prenait plus en compte ce paramétrage mais à la base je n’avais pas vu de communication officielle l’affirmant non plus. (ni là http://www.robotstxt.org/robotstxt.html ni là https://en.wikipedia.org/wiki/Robots_exclusion_standard). Même si a priori c’est obsolète, j’aimerai bien voir l’annonce initiale (en dehors des on-dit) car a priori j’avais loupé un truc (mais pas bien méchant^^).
Ca craint pour TF1 ….
http://www.tf1.fr/robots.txt
C’est qui leur SEO ?
Quel est le problème de leur robots.txt ?
Bah : leurs * justement !
Oui mai sil faut voir l’impact sur le crawl que cela peut avoir en réalité si Google les interprète mal. C’est peut-être très minime…
J’ai également eu le message mais rien vu de particulier dans les logs…
Attention à ne pas généraliser un cas particulier. Tout le monde s’enfonce alors que rien n’a été vérifié par d’autres sources et croisé. Donc je reste sceptique sans autres témoignages / tests sérieux.
This is a question for a HOA with John Mueller tomorrow !
J’ai toujours mis le slash avant les règles dans le robots.txt, cela me semblait « obligatoire », c’est peut-être pour ça que je n’ai reçu aucun message de la part de Google. En effet, ce premier slash indique qu’on démarre à la racine du site, donc ça me semblait logique de le mettre, je le faisais sans forcément réfléchir en fait. Maintenant, je le ferai en conscience. 😀
J’ai effectivement reçu un message d’alerte rouge dans la Search Console concernant le robots.txt d’un de mes sites de 2005 (robots.txt que je n’ai pas modifié depuis 5 ans !).
Malheureusement, je ne trouve pas le problème car le seul astérisque contenu dans le fichier est :
User-agent: *
Mes directives Disallow sont, quant à elles, sans astérisque.
Par contre, certaines de ces directives Disallow pointent vers des URLs en redirection 301. Le problème vient peut-être de là…