Quelques infos sur Google (et Bing parfois) et son moteur de recherche, glanées ici et là de façon officieuse ces derniers jours, avec au programme cette semaine quelques réponses à ces angoissantes questions : est-il judicieux de faire de ses URLs mobiles ses URLs canoniques ? Le fichier robots.txt peut-il garantir l'exclusion des crawlers ? Google prend-il en compte les paramètres d'en-tête HTTP X-RateLimit ?

Ne changez pas vos URLs pour mobile en URLs canoniques
John Mueller de Google conseille de ne pas changer les URLs dédiées au mobile (m.url) en URL canonique, même avec l'indexation mobile-first. Il explique que ce changement pourrait causer des problèmes techniques majeurs pour les grands sites. Il recommande plutôt de maintenir les configurations existantes avec les balises « rel=canonical » et « rel=alternate » et suggère de passer à un design responsive à long terme pour simplifier les choses. De plus, les en-têtes HTTP « vary » ne sont pas nécessaires pour le SEO, mais seulement pour l'accessibilité.
Source : Search Engine Roundtable
Taux de fiabilité :
Un rappel bienvenu de la part de John Mueller qui s’était déjà exprimé à ce sujet. Le tournant mobile-first de Google peut en effet susciter des questionnements et de la confusion.

Le fichier robots.txt ne peut pas garantir totalement l’exclusion des crawlers
Google a confirmé que le fichier robots.txt n’a pas la capacité d’empêcher l'accès non autorisé à un site web. Gary Illyes de Google a en effet expliqué que ce fichier ne fait que demander aux robots d'éviter certaines parties du site, sans garantir leur exclusion. Pour une véritable protection, il est indispensable d’utiliser un pare-feu, une protection par mot de passe ou un autre système d’authentification.
Source : Search Engine Journal
Taux de fiabilité :
En effet, les informations contenues dans le fichier robots.txt sont des directives que les crawlers sont censés respecter. « Censés » est là où se trouve toute la nuance ! Pour vous assurer l’exclusion de certaines parties de votre site, le plus judicieux est en effet de mettre en place un vrai système de protection qui peut passer par différents outils.

Google ne traite pas l’en-tête HTTP X-RateLimit
Sur Mastodon, un internaute a demandé à John Mueller si Google respectait le header X-RateLimit-Limit lors de l’exploration des sites. Réponse de l’intéressé : « Je n’en ai jamais entendu parler », ajoutant : « Nous documentons l’utilisation des codes http 429 et 503 pour demander des ralentissements. »
Source : Search Engine Roundtable
Taux de fiabilité :
X-RateLimit-Limit permet de limiter le nombre de requêtes, mais n’est vraisemblablement pas pris en compte par Google. John Mueller renvoie son interlocuteur vers les codes 429 (trop de requêtes) et 503 (service indisponible).