Recherche · Multilingue

Ce qu'un site traduit
doit vraiment porter

Dix points vérifiés aux sources primaires. Plusieurs croyances très répandues n'y ont pas résisté — dont l'idée que <html lang> aide au référencement, et celle qu'il faut déclarer hreflang deux fois pour être sûr.

Points vérifiés
10
sources primaires
Mythes écartés
6
dont 5 très répandus
Absences documentées
2
aucune source primaire trouvée
Piège le plus grave
IP
la redirection automatique
§1

hreflang — exigences exactes

Règle Réciprocité obligatoire (sinon les annotations sont ignorées), auto-référencement obligatoire, x-default recommandé mais optionnel. Ce n'est pas un signal de ranking mais un signal de sélection d'URL — avec un effet indirect documenté sur la canonicalisation.

Auto-référencement — obligatoire

"Each language version must list itself as well as all other language versions."

Et pour la méthode HTML :

"For each variation of the page, include a set of <link> elements in the <head> element, one link for each page variant including itself. The set of links is identical for every version of the page."

Point d'implémentation important : le bloc de liens est identique sur toutes les versions. Ce n'est pas « chaque page liste les autres », c'est « chaque page liste tout le cluster, elle-même comprise ». C'est ce qui rend la génération triviale : un seul bloc, injecté partout.

Réciprocité — rupture = annulation

"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."

La section Troubleshooting le reformule en termes de conséquence :

"Missing return links: If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly."

Ce qui se passe concrètement quand la réciprocité casse : les annotations sont ignorées — il n'y a pas de pénalité, pas de sanction. On retombe simplement dans le comportement par défaut : Google choisit lui-même quelle version montrer. La dégradation est silencieuse, ce qui la rend difficile à diagnostiquer sans outil.

Nuance importante, souvent ignorée : la rupture est partielle, pas globale.

"If it becomes difficult to maintain a complete set of bidirectional links for every language, you can omit some languages on some pages; Google will still process the ones that point to each other. However, it is important to link newly expanded language pages bidirectionally to the originating/dominant language(s)."

Autrement dit un cluster à moitié cassé fonctionne encore pour les paires intactes. La priorité de rattrapage est de lier les nouvelles langues vers la langue dominante d'origine, pas les nouvelles langues entre elles.

x-default

"The reserved x-default value is used when no other language/region matches the user's browser setting. This value is recommended for specifying the fallback page for users whose language settings don't match any of your site's localized versions. While you can use the x-default value for any page, it was designed for language selector pages and so it will work best with those."

Statut : recommandé ("Consider adding a fallback page"), jamais formulé comme obligatoire. Aucune source primaire n'indique qu'omettre x-default cause un préjudice.

Ranking ou sélection d'URL ?

Google ne dit jamais « hreflang est un facteur de ranking ». Le cadrage est constamment celui de la sélection :

"Doing so will help Google Search point users to the most appropriate version of your page by language or region."

Et surtout, l'aveu que hreflang n'est pas nécessaire à l'indexation :

"Note that even without taking action, Google might still find alternate language versions of your page, but it is usually best for you to explicitly indicate your language- or region-specific pages."

Nuance critique — l'effet indirect réel. Il existe un endroit où hreflang influence bien le résultat, via la canonicalisation :

"To help with sites' localization efforts, for canonicalization purposes Google prefers URLs that are part of hreflang clusters. For example, if https://example.com/de-de/cats and https://example.com/de-ch/cats reciprocally point to each other with hreflang annotations, but not to https://example.com/de-at/cats, the pages for de-de and de-ch will be preferred as canonicals instead of the /de-at/ page that doesn't appear in the hreflang cluster."

C'est le vrai enjeu : une page hors cluster risque de perdre la canonicalisation au profit d'une page du cluster — donc de disparaître au profit d'une autre langue. Ce n'est pas du ranking, mais l'effet observable est le même.

---

Sources primaires

§2

<html lang> — Google l'utilise-t-il ?

Règle Non. Google l'ignore explicitement et le classe dans ses « Unsupported tags and attributes ». La croyance répandue est exacte. Mais l'attribut reste obligatoire pour l'accessibilité (WCAG niveau A).

C'est le point le plus contre-intuitif du dossier, et il est documenté trois fois de façon convergente.

1. Dans la doc hreflang :

"Google doesn't use hreflang or the HTML lang attribute to detect the language of a page; instead, we use algorithms to determine the language."

2. Dans la doc multi-régionale, encore plus large :

"Google uses the visible content of your page to determine its language. We don't use any code-level language information such as lang attributes, or the URL."

Noter la portée : « ni l'URL ». Le préfixe /de/ ne dit rien à Google sur la langue. C'est confirmé par l'exemple de la doc hreflang :

"Note that the language-specific subdomains in these URLs (en, en-gb, en-us, de) are not used by Google to determine the target audience for the page; you must explicitly map the target audience."

3. Dans la liste explicite des attributs non supportés — la formulation la plus tranchée :

"Unsupported tags and attributes — The following tags and attributes aren't supported by Google Search and are ignored. […] HTML tag lang attributes — Google Search detects the language of a page based on the textual content of the page. It doesn't rely on code annotations such as the lang."

lang y figure au même titre que <meta keywords> et rel=next/prev, c'est-à-dire dans la catégorie « sans effet aucun ».

Ce qui utilise réellement lang

L'attribut n'est pas inutile — il a simplement d'autres consommateurs que le moteur de recherche. Le W3C en fait une exigence ferme :

"Always use a language attribute on the html tag to declare the default language of the text in the page."

WCAG 2.2 en fait un critère de succès de niveau A (le niveau minimal), critère 3.1.1 Language of Page :

"The intent of this success criterion is to ensure that content developers provide information in the web page that user agents need to present text and other linguistic content correctly."

Bénéficiaires listés textuellement par le W3C :

- "people who use screen readers or other technologies that convert text into synthetic speech" - "people who find it difficult to read written material with fluency and accuracy" - "people with certain cognitive, language and learning disabilities who use text-to-speech software" - "people who rely on captions for synchronized media"

Concrètement : lecteurs d'écran (règles de prononciation), affichage correct des caractères par les navigateurs visuels, sous-titres des lecteurs multimédia, et — non couvert par WCAG mais dépendant du même attribut — le déclenchement de la proposition de traduction automatique du navigateur.

Conclusion opérationnelle : mettre lang correctement, toujours — mais ne jamais compter dessus pour du SEO, et ne jamais présenter sa présence comme une optimisation de ranking.

---

Sources primaires

§3

og:locale / og:locale:alternate

Convention Non utilisé par les moteurs de recherche. Usage social uniquement (Facebook/LinkedIn). Un og:locale faux ne cause aucun préjudice SEO documenté — le préjudice, réel mais limité, est au partage social.

Définition primaire, à la lettre — les deux propriétés sont dans la section Optional Metadata de la spec :

og:locale — "The locale these tags are marked up in. Of the format language_TERRITORY. Default is en_US." og:locale:alternate — "An array of other locales this page is available in."

Noter le format : underscore (de_DE), pas le tiret de hreflang (de-DE). C'est une source d'erreur classique quand on génère les deux depuis la même variable.

Usage par les moteurs — argument par absence

Aucune source primaire Google ne mentionne og:locale. La page qui énumère les balises meta supportées par Google ne contient aucune occurrence de og: ni de locale. Elle pose la règle générale :

"You can use other meta tags if they are important to your site, but Google will ignore meta tags that it doesn't support."

Et la doc multi-régionale ferme la porte au genre entier :

"Google ignores locational meta tags (like geo.position or distribution) or geotargeting HTML attributes."

Aucune source primaire trouvée attestant qu'un moteur de recherche lise og:locale. Réciproquement, aucune source primaire n'existe pour un quelconque préjudice SEO d'un og:locale erroné. Toute affirmation en ce sens relève du folklore SEO.

Préjudice réel d'un og:locale faux (ex. fr_CH sur une page allemande)

Ce que la spec permet d'affirmer : la valeur déclare la locale dans laquelle les balises OG sont rédigées. Une valeur fausse désinforme donc les plateformes sociales sur la langue du titre/description partagés. Effets plausibles côté Facebook/LinkedIn : mauvaise sélection de variante localisée, mauvais formatage. Ce sont des effets de présentation sociale, pas de recherche.

Verdict pragmatique : à corriger par rigueur — le coût est nul —, mais ce n'est ni un bug SEO ni une priorité. Ne pas le vendre comme tel.

---

Sources primaires

§4

JSON-LD inLanguage

Mixte Propriété schema.org valide et correcte, mais Google ne l'exige que pour un seul type de rich result (Book actions). Absente des specs Article, VideoObject, Movie, Course. Aucun effet documenté sur le ranking multilingue.

Définition schema.org :

"The language of the content or performance or used in an action. Please use one of the language codes from the IETF BCP 47 standard."
  • Types attendus : Language ou Text
  • Types portant la propriété (domainIncludes) : BroadcastService, CommunicateAction, CreativeWork, Event, LinkRole, PronounceableText, WriteAction
  • Remplace l'ancienne propriété language ; équivalente à dct:language (Dublin Core)

CreativeWork étant la racine de Article, WebPage, BlogPosting, etc., la propriété est syntaxiquement valide sur la quasi-totalité des types utiles.

Noter que BCP 47 utilise le tiret (de-DE) — même convention que hreflang, à l'inverse d'og:locale.

Ce que Google en fait — vérification exhaustive

Recherche de inLanguage dans les specs de rich results Google :

TypeOccurrencesStatut
Article0absent
Video (VideoObject/Clip)0absent
Movie0absent
Course0absent
Podcast0absent
Dataset0absent
Fact Check0absent
Book actions9Required property

Seule mention normative, dans les Book actions :

"The Google-supported properties are the following: Required properties […] inLanguage Text — The main language of the content in the edition. Use one of the two-letter codes from the list of ISO 639-1 alpha-2 codes."

(Noter l'incohérence de Google lui-même : schema.org prescrit BCP 47, la spec Book actions impose ISO 639-1 alpha-2.)

Conclusion : hors Book actions — un cas de niche réservé aux catalogues de bibliothèques et libraires —, inLanguage est de l'hygiène sémantique correcte et sans risque, mais aucune source primaire ne lui attribue d'effet sur le ranking ou l'affichage multilingue. Le mettre : oui. Le compter comme levier SEO : non.

---

Sources primaires

§5

Structure d'URL

Mixte Google ne classe pas les options par ordre de préférence. Il présente un tableau pros/cons neutre. Une seule option est explicitement déconseillée : les paramètres d'URL. Le sous-répertoire /de/ est donc parfaitement légitime.

Il n'existe aucune phrase dans la documentation Google du type « nous recommandons les sous-répertoires » ou « les ccTLD sont supérieurs ». Le cadrage est explicitement ouvert :

"Consider using a URL structure that makes it easy to geotarget your site, or parts of it, to different regions. The following table describes your options:"

Tableau primaire reproduit fidèlement :

StructureExempleProsCons
Country-specific domainexample.deClear geotargeting ; Server location irrelevant ; Easy separation of sitesExpensive (can have limited availability) ; Requires more infrastructure ; Strict ccTLD requirements (sometimes) ; Can only target a single country
Subdomains with gTLDde.example.comEasy to set up ; Allows different server locations ; Easy separation of sitesUsers might not recognize geotargeting from the URL alone (is "de" the language or country?)
Subdirectories with gTLDexample.com/de/Easy to set up ; Low maintenance (same host)Users might not recognize geotargeting from the URL alone ; Single server location ; Separation of sites harder
URL parameterssite.com?loc=de—"Not recommended." URL-based segmentation difficult ; Users might not recognize geotargeting

Seule prescription normative du tableau : Not recommended. pour les paramètres d'URL.

Nuance à ne pas perdre : la structure d'URL est listée comme signal de géociblage (pays), pas de langue. Pour la langue, l'URL est explicitement inopérante (cf. §2 : « We don't use any code-level language information such as lang attributes, or the URL »). Un /de/ aide donc Google à deviner l'audience pays — et encore, uniquement en tant que ccTLD, ce que /de/ n'est pas. Pour un site multilingue non multi-régional, le choix /de/ est une décision d'architecture et d'ergonomie, pas un levier SEO.

Les signaux réellement listés par Google pour déterminer la locale cible :

"Country-code top-level domain names (ccTLDs) […] hreflang statements, whether in tags, headers, or sitemaps. Server location (through the IP address of the server) […] Other signals […] local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, or signals from your Business Profile."

---

Sources primaires

§6

Interaction canonical + hreflang

Règle Le canonical doit être auto-référentiel dans sa propre langue. Ne jamais faire pointer le canonical d'une page traduite vers la version originale — cela désindexe la traduction. Par ailleurs Google ignore tout rel=canonical portant un attribut hreflang.

Règle explicite :

"If you're using hreflang elements, make sure to specify a canonical page in the same language, or the best possible substitute language if a canonical page doesn't exist for the same language."

Et le canonical auto-référentiel est recommandé de façon générale :

"Do include a rel="canonical" link on the canonical page itself (also known as a self-referential canonical)."

Le pattern correct

Pour /de/produit dans un cluster de/en/fr :

<link rel="canonical" href="https://example.com/de/produit" />          <!-- soi-même, en allemand -->
<link rel="alternate" hreflang="de" href="https://example.com/de/produit" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/produit" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Deux annotations distinctes et non concurrentes : canonical désigne soi-même ; alternate hreflang désigne le cluster (soi-même inclus).

L'erreur classique et sa conséquence

Faire pointer <link rel="canonical" href="…/en/product"> depuis /de/produit. Conséquence : on déclare que la page allemande est un doublon de l'anglaise, donc qu'elle ne doit pas être indexée séparément. La traduction disparaît des résultats — et les annotations hreflang se contredisent avec le canonical, puisque le cluster affirme que ce sont des versions distinctes.

Google verrouille aussi une seconde erreur, plus subtile — combiner les attributs dans une seule balise :

"rel="canonical" annotations that suggest alternate versions of a page are ignored; specifically, rel="canonical" annotations with hreflang, lang, media, and type attributes are not used for canonicalization. Instead, use the appropriate link annotations to specify alternate versions of a page; for example, link rel="alternate" hreflang for language and country annotations."

Et symétriquement, côté hreflang :

"don't combine link tags for alternate representations of the document; for example don't combine hreflang annotations with other attributes such as media in a single <link> tag."

Rappel du §1 : appartenir au cluster hreflang est en soi un signal de canonicalisation favorable. Canonical propre + cluster complet se renforcent mutuellement.

---

Sources primaires

§7

Sitemap ou HTML — Google préfère-t-il l'un des deux ?

Règle Aucune préférence. Les trois méthodes (HTML, en-tête HTTP, sitemap) sont déclarées équivalentes. Il ne faut surtout pas les cumuler : Google dit explicitement qu'il n'y a aucun bénéfice à le faire.

Formulation sans ambiguïté :

"There are three ways to indicate multiple language/locale versions of a page to Google: HTML / HTTP Headers / Sitemap. The three methods are equivalent from Google's perspective and you can choose the method that's the most convenient for your site. 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)."

C'est un démenti direct d'une pratique courante (« mettre hreflang dans le sitemap et dans le HTML pour être sûr »). Google la qualifie de sans bénéfice et plus difficile à maintenir.

Critères de choix donnés par Google :

  • HTML — "useful if you don't have a sitemap or the ability to specify HTTP response headers for your site."
  • HTTP Headers — "useful for non-HTML files (like PDFs)." C'est le seul cas où la méthode est imposée par la nature du fichier.
  • Sitemap — pertinent à grande échelle : évite d'alourdir chaque page. Contrainte propre : "a sitemap can only contain descendant URLs of the directory where the sitemap is hosted from."

Implication pour un générateur de site : puisque le bloc <link> est identique sur toutes les pages du cluster (§1), la méthode HTML est la plus simple à générer correctement — un partiel unique. Le sitemap devient intéressant au-delà de quelques milliers d'URLs, où le poids du bloc en tête de page commence à compter. Les deux sont défendables ; cumuler ne l'est pas.

Contrainte de validité pour la méthode HTML :

"The <link> tags must be inside a well-formed <head> section of the HTML. If in doubt, paste code from your rendered page into an HTML validator to ensure that the links are inside the <head> element."

Piège réel : un <head> invalide (script mal placé, balise non fermée) fait fermer le <head> prématurément par le parser, éjectant les hreflang dans le <body> — où ils sont sans effet. C'est une panne fréquente et invisible à la lecture du source.

---

Sources primaires

§8

Métadonnées traduites (<title>, <meta description>)

Règle Oui, il faut réellement les traduire. C'est une règle documentée, pas une convention. Un <title> non traduit déclenche activement la réécriture par Google — c'est l'un des rares points de ce dossier où une balise du <head> a un effet mesurable et explicitement documenté.

Prescription directe :

"Use the same language and writing system (meaning, the script or alphabet for a given language) as the primary content on your pages. For example, if a page is written in Hindi, make sure to also write the <title> element in Hindi (don't write title text in English or transliterate the title into Latin characters)."

Conséquence explicite du non-respect :

"Google tries to show a title link that matches the primary language and writing system of a page. If Google determines that a <title> element does not match the writing system or language of the page's primary content, we may choose a different text as the title link."

Google liste même le cas comme problème nommé dans sa section de dépannage :

"Mismatch of writing system or language used in <title> elements — When the writing system or language of the text in <title> elements doesn't match the writing system or language of the primary text on a page. […] If Google detects a mismatch, it may generate a title link that better matches the primary content. Consider ensuring that the script and language matches what is most prominent on the page."

Ce que cela signifie concrètement : un <title> resté en français sur une page /de/ ne provoque pas de pénalité, mais fait perdre le contrôle de l'élément le plus cliquable du résultat de recherche. Google le remplace par du texte extrait de la page (souvent le <h1>). Le préjudice est en CTR et en maîtrise éditoriale.

Et la traduction automatique par Google ?

Elle existe mais ne remplace rien. Google peut traduire l'affichage d'un résultat :

"When Google recognizes that the contents of a page aren't in the language that the user likely wants to read, Google may provide a translated title link and snippet in search results. If the user clicks the translated title link, all further user interaction with the page is through Google Translate."

Ce mécanisme (translated results) s'applique à des pages non disponibles dans la langue de l'utilisateur — c'est une roue de secours pour du contenu étranger, pas un substitut à une vraie version localisée. Il ne rend pas la page native dans cette langue et n'en fait pas une page allemande aux yeux de l'index.

Concernant <meta description> : aucune source primaire trouvée posant une exigence de correspondance linguistique explicite pour la description, comparable à celle du <title>. La règle documentée ne couvre nommément que <title>. Traduire la description reste évidemment cohérent (elle s'affiche à l'utilisateur), mais il faut être honnête sur le statut : pour <title> c'est une règle citable, pour <meta description> c'est une bonne pratique par extension.

---

Sources primaires

§9

Affirmations courantes mais FAUSSES

Mythe Cinq mythes répandus contredits par des sources primaires.

Mythe 1 — « Le contenu dupliqué entre langues est pénalisé »

Faux à double titre : il n'y a pas de pénalité pour duplicate content, et les traductions ne sont même pas du duplicate content.

Google possède une entrée de FAQ intitulée littéralement Duplicate content "penalty" — guillemets de Google :

"If you have some content that's accessible under multiple URLs, it's fine; don't fret about it. It's inefficient, but it's not something that will cause a manual action. Copying others' content, however, is a different story."

Et :

"Having duplicate content on your site is not a violation of our spam policies, but it can be a bad user experience and search engines might waste crawling resources on URLs that you don't even care about."

Surtout, la définition qui règle la question pour le multilingue :

"Localized versions of a page are only considered duplicates if the main content of the page remains untranslated."

Une page réellement traduite n'est pas un doublon, par définition de Google. Le seul cas de duplication est celui où l'on traduit le gabarit (menu, pied de page) en laissant le corps du texte dans la langue d'origine — le scénario explicitement décrit comme problématique :

"Translating only the boilerplate text of your pages while keeping the bulk of your content in a single language (as often happens on pages featuring user-generated content) can create a bad user experience if the same content appears multiple times in search results with various boilerplate languages."

Mythe 2 — « Il faut un ccTLD pour ranker localement »

Faux. Le ccTLD est un signal parmi plusieurs, et Google documente explicitement les alternatives pour un gTLD :

"If your site has a generic top-level domain such as .com, .org […] and wants to target users in a particular geographic location, explicitly set a country target using one of the methods described previously."

Le tableau (§5) liste d'ailleurs des inconvénients réels du ccTLD — coût, infrastructure, et surtout "Can only target a single country". Pour un site multilingue visant plusieurs marchés, le ccTLD est souvent le pire choix, pas le meilleur.

Attention au piège associé : certains ccTLD ne géociblent rien du tout, Google les traitant comme génériques —

"Google treats some ccTLDs (such as .tv and .me) as gTLDs, as we've found that users and website owners frequently see these more generic than country-targeted."

La liste inclut notamment .io, .co, .me, .tv, .ai, .fm, .la.

Mythe 3 — « La traduction automatique est pénalisée »

Faux depuis mars 2024, et Google a supprimé sa propre consigne inverse en juin 2025. Traité en détail au §10.

Mythe 4 — « La redirection par IP est recommandée »

Faux — c'est explicitement déconseillé, deux fois.

"Avoid automatically redirecting users from one language version of a site to a different language version of a site. For example, don't redirect based on what you think the user's language may be. These redirections could prevent users (and search engines) from viewing all the versions of your site."
"Don't use IP analysis to adapt your content. IP location analysis is difficult and generally not reliable. Furthermore, Google may not be able to crawl variations of your site properly. Most, but not all, Google crawls originate from the US, and we don't attempt to vary the location to detect site variations."

Raison technique décisive — Googlebot ne se comporte pas comme un utilisateur :

"This is because the Googlebot crawler usually originates from the USA. In addition, the crawler sends HTTP requests without setting Accept-Language in the request header."

Un site qui redirige selon l'IP ou Accept-Language montre donc systématiquement la même version à Googlebot — les autres langues peuvent ne jamais être indexées. C'est le mode de défaillance le plus destructeur du dossier : il annule silencieusement tout le travail de traduction.

Ce que Google recommande à la place :

"Consider adding hyperlinks to other language versions of a page. That way users can click to choose a different language version of the page."

Soit : un sélecteur de langue cliquable (liens réels, crawlables), jamais une redirection automatique.

Mythe 5 — « Mettre hreflang dans le sitemap ET dans le HTML est plus sûr »

Faux — "there's no benefit in Search" (cf. §7).

---

Sources primaires

§10

Politique actuelle sur la traduction automatique

Règle La traduction automatique n'est plus interdite en soi. Depuis mars 2024, seule compte la valeur pour l'utilisateur, « no matter how it's created ». Google a supprimé en juin 2025 sa dernière consigne demandant de bloquer les pages auto-traduites.

L'ancienne politique

Google recommandait autrefois de bloquer les pages traduites automatiquement via robots.txt, et classait le « texte traduit par un outil automatisé sans révision humaine » parmi le contenu auto-généré prohibé.

Le basculement — mars 2024, critère de valeur et non de méthode

La politique « scaled content abuse » remplace le critère de méthode de production par un critère de valeur :

"Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users. This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created."

La traduction n'apparaît plus qu'assortie d'une condition de nuisance :

"Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users"

La proposition subordonnée fait tout le travail. Traduire n'est abusif que si (a) c'est à grande échelle, (b) sur du contenu récupéré ailleurs, et (c) sans valeur ajoutée. Traduire son propre contenu pour servir réellement un public dans sa langue ne coche aucune des trois cases.

La confirmation — juin 2025, suppression de la consigne obsolète

Entrée de changelog Google Search Central, 11 juin 2025, intitulée « Spring cleaning in our multilingual documentation » :

What: "Removed a section from our multilingual documentation about using robots.txt to block all automatically translated pages." Why: "To align with our spam policy update in March 2024. This is a docs-only change, no change in behavior."

Deux enseignements. D'abord, la consigne de blocage est officiellement retirée — la bloquer aujourd'hui reviendrait à suivre une doc morte. Ensuite, « no change in behavior » : les systèmes ne traitaient déjà plus la traduction automatique comme un signal négatif en soi depuis mars 2024 ; seule la documentation était en retard.

Principe général cohérent

Google applique le même raisonnement au contenu généré par IA :

"using generative AI tools or other similar tools to generate many pages without adding value for users may violate Google's spam policy on scaled content abuse"

Ce que cela implique en pratique

Une traduction automatique est acceptable si elle produit une page réellement utile dans la langue cible. Le risque s'est déplacé : il n'est plus réglementaire mais qualitatif. Une traduction machine médiocre ne déclenche pas de sanction — elle échoue simplement à convaincre les utilisateurs et à satisfaire l'intention de recherche, ce qui se traduit par de mauvaises performances. Le rappel du §8 vaut ici : si la qualité linguistique est faible ou incohérente, Google réécrit les <title> et l'on perd la maîtrise de l'affichage.

Recommandation Google en matière de transparence :

"If you're automatically generating content, consider adding information on how your content was created in a way that makes sense for your audience"

---

Sources primaires

—

Annexe — Bing : là où il diverge de Google

Convention Bing recommande la balise meta content-language, que Google ignore totalement. Divergence réelle entre moteurs.

Bing recommande hreflang comme Google, mais y ajoute un signal que Google n'utilise pas : la balise content-language, composée d'un code langue ISO 639 suivi d'un code géographique ISO 3166. Bing conseille par ailleurs de regrouper le contenu localisé par TLD, sous-domaine ou sous-dossier — en gardant chaque région/langue dans une structure unique.

Implication : ajouter <meta http-equiv="content-language" content="de-DE"> est sans effet chez Google (non listé parmi les balises supportées) mais peut aider chez Bing. Coût nul, bénéfice possible sur un moteur.

Réserve de méthode : la documentation Bing n'a pu être extraite verbatim (page rendue en JavaScript, contenu inaccessible au fetch). Ces éléments proviennent d'un résumé de la source Bing officielle et n'ont pas pu être vérifiés mot à mot — à traiter avec plus de prudence que les citations Google ci-dessus.

---

Sources primaires

—

Synthèse — ce qui compte vraiment, par ordre d'impact

#ÉlémentStatutImpact réel
1Contenu visible traduitRègleDécisif — seul déterminant de la langue perçue
2Pas de redirection auto IP / Accept-LanguageRègleCritique — sinon les traductions ne sont jamais crawlées
3Canonical auto-référentiel dans sa langueRègleCritique — sinon la traduction est désindexée
4<title> traduitRègleÉlevé — sinon réécriture par Google, perte de CTR
5hreflang réciproque + auto-référencéRègleMoyen — sélection d'URL + canonicalisation du cluster
6Liens crawlables entre languesRègleMoyen — découverte des variantes
7x-defaultRecommandationFaible — confort de fallback
8<html lang>Règle (a11y)Nul en SEO, obligatoire en accessibilité (WCAG A)
9inLanguageConventionNul, hors Book actions
10og:localeConventionNul en SEO ; social uniquement
11hreflang dans sitemap ET HTMLÀ éviterNul — « no benefit in Search »

Le point à retenir : presque tout ce que l'écosystème SEO présente comme « les balises multilingues » (lang, og:locale, inLanguage, préfixe d'URL) est ignoré par Google pour la détection de langue. Ce qui fait ranker une page allemande en allemand, c'est du texte allemand. hreflang ne fait qu'aiguiller entre des pages qui rankent déjà ; le canonical et l'absence de redirection automatique déterminent si elles existent dans l'index.