Robots.txt et sites multilingues : budget de crawl, hreflang et pièges courants
Un site WordPress multilingue double ou triple le nombre d'URL crawlables. Chaque page existe en plusieurs versions linguistiques, chacune avec sa propre URL, ses propres annotations hreflang et ses propres besoins de crawl. Cela crée des défis spécifiques pour la configuration du robots.txt que les sites unilingues ne rencontrent jamais.
Le problème de multiplication des URL
Un site unilingue de 100 pages a 100 URL à crawler. Un site bilingue avec le même contenu en a 200. Un site trilingue en a 300. Chaque version linguistique doit être crawlée, indexée et maintenue dans l'index du moteur de recherche indépendamment.
Cette multiplication affecte directement le budget de crawl. Les patrons d'URL à faible valeur qui sont des nuisances mineures sur un site unilingue deviennent des drains significatifs quand ils sont multipliés par le nombre de langues.
Le robots.txt s'applique au domaine entier
Le robots.txt est un fichier unique à la racine du domaine. Il n'y a pas de robots.txt par langue. Une règle qui bloque /page/ le bloque dans chaque répertoire linguistique : /en/page/, /fr/page/, /de/page/.
Les règles du robots.txt doivent donc être écrites en connaissance de la structure d'URL complète de toutes les langues. Une règle correcte pour le site anglais peut avoir des conséquences imprévues pour la version française si les patrons d'URL diffèrent.
L'interaction avec le hreflang
Les annotations hreflang indiquent aux moteurs de recherche quelles pages sont les équivalents linguistiques les unes des autres. L'interaction avec le robots.txt crée un piège subtil : si on bloque une version linguistique d'une page dans le robots.txt mais pas l'autre, la relation hreflang se brise.
Google ne peut pas valider une annotation hreflang qui pointe vers une page bloquée. Le résultat est que les deux versions linguistiques peuvent s'afficher incorrectement dans les résultats de recherche.
La règle est simple : si une page a des annotations hreflang, toutes les versions linguistiques doivent être crawlables.
Ce qu'il faut bloquer sur les sites multilingues
Les mêmes catégories d'URL à faible valeur qui gaspillent le budget de crawl sur les sites unilingues s'appliquent aux sites multilingues, mais avec des patrons adaptés à la langue.
Les résultats de recherche internes doivent être bloqués pour toutes les langues. Les archives paginées doivent être bloquées de manière cohérente entre les langues. Les chemins générés par les plugins (WooCommerce, etc.) apparaissent souvent identiquement dans tous les répertoires linguistiques.
La coordination avec le sitemap
Sur un site multilingue, l'alignement entre sitemap et robots.txt est doublement important. Chaque version linguistique de chaque page devrait apparaitre dans le sitemap avec des annotations hreflang correctes, et aucune entrée du sitemap ne devrait correspondre à une règle Disallow du robots.txt.
Better Robots.txt applique ses règles de manière cohérente à travers la structure linguistique du site. La directive sitemap dans le robots.txt généré pointe vers l'index du sitemap, qui contient toutes les versions linguistiques.