Recherche · Exploration

robots.txt
et le cas multilingue

Ce que le standard impose, ce que Google et Bing en font, et pourquoi un site à préfixes de langue n'a besoin que d'un seul fichier, à la racine. Six fautes documentées sont devenues des contrôles qui arrêtent la compilation.

Points vérifiés
10
sources primaires
Mythes écartés
3
dont un par langue
Fautes contrôlées
6
exécutables, pas documentaires
robots.txt
1
à la racine — jamais par langue
§0

Préalable — « Yahoo » n'est pas une autorité distincte

Règle Yahoo Search n'a pas de moteur d'indexation web indépendant — les résultats viennent de Bing ; Bing est donc l'autorité à citer. Slurp existe encore mais ne sert plus l'index web général.

L'utilisateur a demandé « Google et Yahoo ». Vérification faite sur les pages d'aide de Yahoo elles-mêmes (source primaire) :

La page Yahoo « Submit your website to Yahoo Search » ne propose aucun outil Yahoo et renvoie entièrement à Microsoft :

"Submit your site via Bing Webmaster Tools. Yahoo is unable to provide any status updates or assistance regarding submissions to Bing; contact Bing for assistance."

La page « Webmaster tools available for Yahoo Search » confirme qu'il n'existe pas d'outil webmaster Yahoo, seulement les mécanismes standards, et renvoie vers Bing :

"You can manage how your website appears in Yahoo Search by using meta tags and robots.txt." "Visit Bing's Webmaster Help Center to review optimization tips."

Nuance importante à ne pas caricaturer. Le crawler Slurp n'est pas mort, mais son rôle n'est plus l'index web général. La page Yahoo « Why is Slurp crawling my page? » décrit ses fonctions actuelles :

"Collects content from partner sites for inclusion within sites like Yahoo News, Yahoo Finance and Yahoo Sports" "Accesses pages from sites across the Web to confirm accuracy and improve Yahoo's personalized content."

Et sa règle robots.txt propre :

"Slurp will obey the first entry in the robots.txt file with a User-agent containing 'Slurp'. If there is no such record, it will obey the first entry with a User-agent of '*'."

Conséquence pratique : aucune règle robots.txt ni structure de sitemap spécifique à Yahoo n'est à inventer. Un User-agent: * permissif couvre Slurp automatiquement (dernière phrase citée). Le référencement web dans Yahoo se pilote via Bing Webmaster Tools. Aucune source primaire trouvée attestant que Slurp alimente encore l'index web algorithmique de Yahoo.

---

Sources primaires

§1

RFC 9309 — le standard robots.txt

Règle RFC 9309 (septembre 2022) impose l'emplacement /robots.txt par origine, un parsing d'au moins 500 KiB, un cache ≤ 24 h et l'interdiction totale en cas d'erreur 5xx ; Sitemap: n'est PAS dans le standard, c'est une extension explicitement tolérée.

Emplacement (obligatoire, §2.3) : > "The rules MUST be accessible in a file named '/robots.txt' (all lowercase) in the top-level path of the service."

L'URI suit la forme scheme:[//authority]/robots.txt — donc une portée par origine (schéma + hôte + port).

Sitemap: — extension, pas standard (§2.2.4) : > "Crawlers MAY interpret other records that are not part of the robots.txt protocol -- for example, 'Sitemaps'."

C'est un MAY sur un enregistrement « not part of the robots.txt protocol ». La ligne Sitemap: est donc parfaitement légitime et universellement supportée, mais formellement une extension. Google confirme la supporter (voir point 3).

Casse (§2.2.1, §2.2.2) — asymétrique : > "Crawlers MUST use case-insensitive matching to find the group that matches the product token." (noms de champs / user-agent : insensibles à la casse) > "The matching SHOULD be case sensitive." (valeurs de chemins : sensibles à la casse)

Google reprend exactement cette asymétrie : les noms de champs sont insensibles à la casse, mais « the value is case-sensitive » pour allow/disallow. Conséquence directe pour vous : /de/ et /DE/ sont deux chemins distincts.

Taille — 500 KiB (§2.5) : > "The parsing limit MUST be at least 500 kibibytes [KiB]."

Le RFC fixe un plancher pour les crawlers ; Google applique ce chiffre comme plafond dur :

"Google enforces a robots.txt file size limit of 500 kibibytes (KiB). Content which is after the maximum file size is ignored."

Ce qui suit l'octet 500 KiB est ignoré silencieusement — pas d'erreur. Sans objet pour un fichier de quelques lignes.

Cache (§2.4) : > "Crawlers MAY cache the fetched robots.txt file's contents...Crawlers SHOULD NOT use the cached version for more than 24 hours, unless the robots.txt file is unreachable."

Codes d'erreur (§2.3.1.3, §2.3.1.4) : > 4xx : "If a server status code indicates that the robots.txt file is unavailable...the crawler MAY access any resources on the server." > 5xx : "If the robots.txt file is unreachable due to server or network errors...the crawler MUST assume complete disallow."

Point d'attention opérationnel : un 5xx sur /robots.txt = interdiction totale de crawl (MUST). Sur un hébergement statique, mieux vaut un fichier réellement servi en 200 qu'un 404 « pardonné ». Google précise sa propre variante : 4xx (sauf 429) traité comme robots.txt inexistant ; 5xx → arrêt de crawl 12 h, puis usage du cache jusqu'à 30 jours.

---

Sources primaires

§2

Faut-il déclarer les langues séparément dans robots.txt ?

Mixte Non. Aucune directive robots.txt liée à la langue n'existe, et il faut UN SEUL robots.txt à la racine de l'hôte — un /de/robots.txt serait purement ignoré.

Il n'existe aucune directive de langue. Google énumère limitativement les champs supportés — user-agent, allow, disallow, sitemap — et rien d'autre. Le RFC 9309 ne définit que user-agent, allow, disallow. Aucune source primaire ne documente une directive robots.txt liée à la langue, au pays ou à hreflang — ni chez Google, ni chez Bing, ni dans le RFC. Confirmation de votre intuition : ça n'existe pas. La langue se gère par hreflang (points 4-5), jamais par robots.txt.

Un seul fichier, à la racine de l'hôte — Google est explicite et cite le cas du sous-répertoire :

"The robots.txt file must be located at the root of the site host to which it applies. For instance, to control crawling on all URLs below https://www.example.com/, the robots.txt file must be located at https://www.example.com/robots.txt. It _cannot_ be placed in a subdirectory (for example, at https://example.com/pages/robots.txt)."
"Your site can have only one robots.txt file."

Portée = origine, pas répertoire : > "Rules apply only to the host, protocol, and port number where the robots.txt file is hosted." > "A robots.txt on a subdomain is only valid for that subdomain."

Bing applique la même règle par hôte complet, et précise qu'aucun repli n'existe entre sous-domaines :

"For a given page, BingBot looks at the root of the host for your robots.txt file." "Note that the host here is the full subdomain (us.contoso.com), not contoso.com nor www.contoso.com." "if a robots.txt file is missing from a subdomain, BingBot will not try to fall back to any other file in your domain, meaning it will consider itself allowed anywhere on the subdomain."

Conclusion pour votre site : /, /de/, /en/ sont des chemins sur une seule origine → un seul /robots.txt, qui couvre les trois langues. Créer /de/robots.txt ou /en/robots.txt ne produirait aucun effet (fichiers inertes, jamais lus comme robots.txt). Note : si un jour vous passiez à de.example.com, chaque sous-domaine exigerait son propre robots.txt — mais ce n'est pas votre architecture.

---

Sources primaires

§3

La directive Sitemap: et la stratégie multilingue

Mixte Plusieurs lignes Sitemap: sont permises, mais pour 26 pages un sitemap unique avec annotations hreflang est le bon choix ; l'index de sitemaps et le découpage par langue ne servent qu'au-delà des limites de volume.

Lignes multiples : autorisées. sitemaps.org indique que plusieurs déclarations Sitemap: sont permises dans un même robots.txt, et Google documente :

"Insert the following line anywhere in your robots.txt file, specifying the path to your sitemap." Sitemap: https://example.com/my_sitemap.xml

« anywhere » : la ligne est indépendante des groupes User-agent — elle n'appartient à aucun groupe et n'a pas besoin d'être placée après l'un d'eux. Elle exige une URL absolue.

Limites (identiques Google / sitemaps.org / Bing) : > "All formats limit a single sitemap to 50MB (uncompressed) or 50,000 URLs." (Google) > Bing : "Up to 50,000 URLs per individual sitemap file. Up to 50,000 child sitemap files referenced within a single sitemap index file."

26 pages ≈ 0,05 % de la limite. Aucun besoin technique d'index de sitemaps ni de découpage par langue.

Règle de portée du sitemap (importante, et souvent ignorée) : > "The location of a Sitemap file determines the set of URLs that can be included in that Sitemap." — un sitemap placé à /catalog/sitemap.xml ne peut référencer que des URLs sous /catalog/.

Conséquence directe : si vous placiez un sitemap dans /de/sitemap.xml, il ne pourrait légitimement lister que des URLs /de/… — ce qui casserait les annotations hreflang, puisque chaque entrée <url> doit pointer vers toutes les langues (point 5). C'est l'argument technique décisif contre un sitemap par langue dans votre cas. Un sitemap unique à la racine (/sitemap.xml) couvre les trois langues sans conflit.

Ce que Google recommande pour le multilingue : la documentation hreflang ne prescrit ni un sitemap par langue ni un index. Elle décrit un sitemap contenant un élément <url> par version linguistique, chacun portant les <xhtml:link> de toutes les alternatives (voir point 5). L'exemple officiel est un fichier unique contenant les trois versions.

Avertissement Google sur la portée de l'envoi : > "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling."

Note Bing spécifique : changefreq et priority sont inutiles. > "Optional sitemap tags like changefreq and priority are ignored by Bing and do not influence how your content is crawled or ranked."

---

Sources primaires

§4

hreflang : sitemap vs HTML vs en-tête HTTP

Règle Les trois méthodes sont équivalentes ; Google n'en préfère aucune et déconseille explicitement de les cumuler — il faut en choisir une seule.

Équivalence, textuellement : > "The three methods are equivalent from Google's perspective and you can choose the method that's the most convenient for your site."

Le cumul est possible mais contre-productif : > "While you can use all three methods at the same time, there's no benefit in Search (in fact, it maybe be much harder to manage three implementations instead of just picking one)."

Donc : mélanger n'est pas une erreur technique, mais n'apporte aucun gain et multiplie le risque d'incohérence. Recommandation : une seule implémentation.

Que se passe-t-il en cas de désaccord HTML / sitemap ? Aucune source primaire trouvée décrivant une règle de priorité explicite entre les trois méthodes en cas de contradiction. Google ne publie pas d'ordre de préséance. Ce qui est documenté, en revanche, c'est la sanction de l'incohérence bidirectionnelle :

"If two pages don't both point to each other, the tags will be ignored. This is so that someone on another site can't arbitrarily create a tag naming itself as an alternative version of one of your pages."

Autrement dit : le mécanisme de défaillance documenté n'est pas « le sitemap gagne » ou « le HTML gagne », mais l'annulation pure et simple des annotations non réciproques. C'est précisément le risque créé par une double implémentation divergente — et la raison concrète pour laquelle il faut n'en tenir qu'une.

Choix conseillé pour un site statique de 26 pages : le sitemap. Il centralise toutes les annotations dans un seul fichier générable, plutôt que de disperser 3 balises <link> dans chacune des 26 pages (78 balises à maintenir cohérentes). L'en-tête HTTP n'a d'intérêt que pour les documents non-HTML (PDF).

---

Sources primaires

§6

noindex et robots.txt — l'interaction critique

Mixte Une page bloquée par Disallow ne peut jamais voir son noindex lu — les deux se neutralisent. Et Noindex: dans robots.txt n'est plus supporté depuis le 1er septembre 2019.

L'interaction, dans les mots de Google (le plus net) : > "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler."

Formulation complémentaire dans la spécification des balises robots :

"If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving rules will not be found and will therefore be ignored."
"If indexing or serving rules must be followed, the URLs containing those rules cannot be disallowed from crawling."

Et la conséquence perverse — le blocage ne garantit pas l'absence d'indexation :

"A page that's disallowed in robots.txt can still be indexed if linked to from other sites."
"it is not a mechanism for keeping a web page out of Google."

Le piège classique est donc de combiner Disallow: /page + <meta name="robots" content="noindex"> en croyant renforcer l'exclusion : le crawler ne lit jamais la balise, et l'URL peut apparaître dans les résultats (sans description) sur la foi de liens externes. Pour désindexer, il faut autoriser le crawl.

Noindex: en robots.txt — retiré le 1er septembre 2019 : > "we're retiring all code that handles unsupported and unpublished rules (such as noindex) on September 1, 2019." > "we focused on rules unsupported by the internet draft, such as crawl-delay, nofollow, and noindex. Since these rules were never documented by Google, naturally, their usage in relation to Googlebot is very low."

Confirmé dans la documentation courante :

"Specifying the noindex rule in the robots.txt file is not supported by Google."

Les alternatives officiellement listées par Google dans cette annonce : noindex en balise meta ou en en-tête HTTP (« the most effective way to remove URLs from the index when crawling is allowed »), codes 404/410, protection par mot de passe, Disallow (avec la réserve ci-dessus), et l'outil de suppression d'URL de Search Console.

Pour votre site : avec 26 pages toutes destinées à l'indexation, aucun Disallow de contenu n'est nécessaire. Le robots.txt doit rester permissif.

---

Sources primaires

§7

Spécificités Bing

Règle Une seule divergence réelle et documentée — Bing honore Crawl-delay, que Google ignore totalement. Sinon Bing suit le même protocole. IndexNow est utile mais optionnel pour un site de 26 pages.

Crawl-delay — la divergence. Google est catégorique :

"The non-standard 'crawl-delay' robots.txt rule is not processed by Google's crawlers."

Bing tout aussi catégorique en sens inverse :

"Yes, BingBot honors the Crawl-delay directive, whether it is defined in the most specific set of directives or in the default one – that is an important exception to the rule defined above."

Sémantique Bing (souvent mal comprise, et Bing le souligne) :

"One common mistake is that Crawl-delay does not represent a crawl rate. Instead, it defines the size of a time window (from 1 to 30 seconds) during which BingBot will crawl your web site only once."
"if your crawl delay is 5, BingBot will slice the day in smaller five-second windows, crawling only one page (or none) in each of these, for a maximum of around 17,280 pages during the day."
"the higher your crawl delay is, the fewer pages BingBot will crawl. As crawling fewer pages may result in getting less content indexed, we usually do not recommend it"

Bing recommande de le placer dans le groupe générique :

"Bing recommends that any crawl-delay directive be made in the generic directive section for all bots"

Recommandation pour votre site : ne PAS mettre de Crawl-delay. Bing lui-même écrit « we usually do not recommend it », et le blog de 2009 vise explicitement votre profil :

"Websites that are small (page-wise) and whose content is not regularly updated probably will never need to set crawl delay settings."

Un Crawl-delay bride Bing sans bénéfice ; il écrase aussi le réglage des Webmaster Tools (« a crawl delay noted in your robots.txt file will override the direction set within the Bing Webmaster Tool »).

Priorité des groupes chez Bing — piège à connaître. Bing ne lit qu'UN seul groupe :

"BingBot honors only one set of directives, in this order of priority: The section for the bingbot user agent, discarding everything else. The section for the msnbot user agent (for backwards compatibility), discarding everything else. The default section (wildcard user agent)."
"if you have a specific set of directives for the bingbot user agent, BingBot will ignore all the other directives in the robots.txt file."

Corollaire : si vous ajoutez un jour un bloc User-agent: bingbot, vous devez y recopier tout ce qui doit s'appliquer, y compris ce qui figure dans User-agent: *. Raison de plus pour n'avoir qu'un seul groupe générique.

Sitemaps chez Bing : mêmes limites, mêmes méthodes de soumission (robots.txt ou Webmaster Tools), relecture quotidienne, lastmod valorisé, changefreq/priority ignorés (citations au point 3).

IndexNow. Protocole ouvert de notification, soutenu par Bing, Yandex, Naver, Seznam.cz, Amazon, Yep — Google n'y participe pas (absent de la liste officielle des moteurs participants). Il ne remplace pas le sitemap :

"Using both IndexNow and sitemaps improves content visibility and ensures broader search engine coverage."

Sur l'intérêt pour les petits sites, la FAQ officielle répond oui :

"IndexNow is beneficial even for small websites with only a few pages. It allows you to instantly notify search engines about updates, increasing the likelihood of faster crawling and indexing."

Fonctionnement : une clé publiée dans un fichier .txt à la racine (nommé d'après la clé, contenant la clé), puis un simple ping HTTP par URL modifiée. > "This key proves ownership of your domain and authenticates your submissions so search engines know they're coming from an authorized source."

Verdict IndexNow pour 26 pages statiques : optionnel, faible priorité. Le bénéfice est proportionnel à la fréquence de mise à jour ; un site vitrine statique rarement modifié en tire peu. Il ne couvre en outre pas Google. À envisager seulement s'il est gratuit à intégrer dans votre pipeline de déploiement (beaucoup de CDN/CMS l'ont nativement) et si le contenu change souvent. Ce n'est en aucun cas un prérequis.

---

Sources primaires

§8

Erreurs documentées les plus fréquentes

Règle Six erreurs attestées par sources primaires — dont le blocage des ressources CSS/JS et l'usage de robots.txt comme outil de confidentialité, tous deux explicitement dénoncés par Google.

8.1 — Bloquer CSS / JavaScript (ressources de rendu). Google, décembre 2024 :

"It is tempting to add robots.txt to the list also, however from a rendering perspective disallowing crawling of resources usually causes issues. If WRS cannot fetch a rendering-critical resource, Google Search may have trouble extracting content of the page and allowing the page to rank in Search."

Et dans le guide robots.txt :

"if the absence of these resources make the page harder for Google's crawler to understand the page, don't block them."

Le rendu Google passe par le Web Rendering Service, qui retélécharge les ressources référencées ; un Disallow: /assets/ ou /css/ casse ce rendu. Ne jamais bloquer les répertoires d'assets d'un site statique.

8.2 — Utiliser robots.txt pour cacher des pages. Erreur conceptuelle la plus répandue :

"Don't use a robots.txt file as a means to hide your web pages (including PDFs and other text-based formats supported by Google) from Google Search results."
"A page that's disallowed in robots.txt can still be indexed if linked to from other sites."
"it is not a mechanism for keeping a web page out of Google."

robots.txt contrôle le crawl, jamais l'indexation. Pour exclure : noindex (crawl autorisé), mot de passe, ou 404/410.

8.3 — Disallow + noindex combinés. Voir point 6 : ils s'annulent. > "Any URL that is crawled affects crawl budget, and Google has to crawl the page in order to find the noindex rule."

8.4 — Casse des chemins. Les valeurs de Allow/Disallow sont sensibles à la casse (RFC §2.2.2 « The matching SHOULD be case sensitive » ; Google : « the value is case-sensitive »), alors que les noms de champs ne le sont pas. Disallow: /De/ ne bloque pas /de/. Pertinent pour un site à préfixes de langue.

8.5 — Slash final : page vs répertoire. Google : les chemins doivent commencer par /, et « Directories must end with / ». Disallow: /de bloque /de, /de/, mais aussi /design, /demo, /de-luxe — tout ce qui commence par la chaîne. Disallow: /de/ ne vise que le répertoire. Sur un site à préfixes de langue, cette confusion peut désindexer une langue entière par effet de bord.

8.6 — Mauvais emplacement / fichier par sous-répertoire. Voir point 2 : « It _cannot_ be placed in a subdirectory ». Un /de/robots.txt est un fichier mort.

Erreurs annexes documentées : encodage — « A robots.txt file must be a UTF-8 encoded text file (which includes ASCII) » ; groupes multiples chez Bing (point 7) ; 5xx sur robots.txt = interdiction totale (RFC §2.3.1.4) ; joker * et ancre $ supportés par Google mais non standardisés dans le RFC — les crawlers tiers peuvent les ignorer, donc ne pas fonder une exclusion critique dessus.

---

Sources primaires

§9

Un site de 26 pages a-t-il besoin d'un sitemap ?

Mixte Selon les critères écrits de Google : non, pas nécessaire — 26 pages tombent explicitement dans la catégorie « you might not need a sitemap ». Le mettre reste néanmoins peu coûteux et utile ici pour un motif distinct : porter les annotations hreflang.

Google publie deux listes explicites. Verbatim, « You might not need a sitemap if » : > "Your site is 'small'. By small, we mean about 500 pages or fewer on your site." > "Your site is comprehensively linked internally. This means that Googlebot can find all the important pages on your site by following links starting from the home page." > "You don't have many media files (video, image) or news pages that you want to show in search results."

Verbatim, « You might need a sitemap if » : > "Your site is large. Generally, on large sites it's more difficult to make sure that every page is linked by at least one other page on the site." > "Your site is new and has few external links to it." > "Your site has a lot of rich media content (video, images) or is shown in Google News."

Application honnête à votre site. Sur les trois critères de non-nécessité : 26 pages ≪ 500 → oui ; maillage interne complet (menu de navigation présent sur toutes les pages d'un site statique) → oui, à vérifier ; pas de vidéo/news → probablement oui. Le seul critère de la colonne « need » qui pourrait s'appliquer est « your site is new and has few external links to it » — pertinent si le site vient d'être lancé.

Donc : la réponse à « faut-il un sitemap ? » n'est pas un « oui » automatique. Le sitemap n'accélérera pas notablement la découverte d'un site de 26 pages bien maillé. Google rappelle d'ailleurs que ce n'est qu'un indice : « submitting a sitemap is merely a hint ».

Mais dans votre cas précis, il existe une raison indépendante de la taille. Vous avez choisi de déclarer hreflang par sitemap (point 4). Or c'est l'une des trois méthodes officielles, et elle requiert un sitemap. Le sitemap cesse alors d'être un outil de découverte — rôle pour lequel il est superflu ici — pour devenir le support des annotations multilingues, où il est pleinement justifié. Alternative si vous préfériez ne pas maintenir de sitemap : basculer sur les balises <link rel="alternate"> en HTML, strictement équivalentes selon Google.

Coût de maintenance : nul si le sitemap est généré par le build. C'est le cas de figure typique d'un site statique.

---

Sources primaires

—

Synthèse — configuration recommandée

Votre approche (un robots.txt unique à la racine + un sitemap unique avec xhtml:link hreflang) est correcte et conforme aux sources primaires Google, Bing et sitemaps.org. Aucun changement structurel n'est requis.

/robots.txt :

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Points de vigilance : - Un seul robots.txt, à la racine de l'hôte. Pas de /de/robots.txt (fichier inerte). - Aucune directive de langue n'existe en robots.txt — la langue se gère exclusivement par hreflang. - Un seul sitemap, à la racine — obligatoire pour que les annotations hreflang inter-langues soient valides (règle de portée sitemaps.org). - Ne rien bloquer : ni CSS, ni JS, ni assets. - Pas de Crawl-delay (Google l'ignore, Bing le déconseille pour les petits sites). - Pas de Noindex: en robots.txt (retiré en 2019). - Chaque <url> du sitemap doit porter le jeu complet des alternatives, auto-référence comprise. - Soumettre le sitemap dans Google Search Console et Bing Webmaster Tools (ce dernier couvrant aussi Yahoo). - Vérifier la casse des préfixes : /de/ ≠ /De/.

Comptage des statuts : Règle documentée = 8 items (0, 1, 2, 4, 5, 6, 7, 8) · Convention = 2 (3 et 9, sur le volet « choix » uniquement) · Mythe identifié = 3 (robots.txt par langue ; directive robots.txt de langue ; Noindex: en robots.txt) · Aucune source primaire trouvée = 2 (règle de préséance en cas de conflit hreflang HTML/sitemap ; rôle actuel de Slurp dans l'index web de Yahoo).