SEO multilingue Framer : se faire indexer dans chaque langue

La plupart des sites Framer multilingues échouent au même endroit. La traduction est correcte. Les pages existent. Et Google, soit les ignore, soit sert la page allemande à un visiteur français.

La traduction, c’est la moitié facile. Voici l’autre moitié, avec ce que Google dit réellement plutôt que ce que les articles SEO répètent.

D’abord, trois choses que Google ne fait explicitement pas

Se tromper là-dessus coûte des semaines.

Google ne lit pas votre attribut lang. Sa documentation est sans ambiguïté : “Google n’utilise ni hreflang ni l’attribut HTML lang pour détecter la langue d’une page ; nous utilisons des algorithmes pour la déterminer.” Poser lang="fr" vaut le coup, mais pour l’accessibilité (les lecteurs d’écran en ont besoin, et WCAG 3.1.1 l’exige au niveau A) et pour le prompt de traduction du navigateur. Ce n’est pas un signal SEO. Qui vous dit le contraire répète un mythe.

Google ne vous classe pas mieux parce que vous avez du hreflang. Le hreflang échange l’URL qui se classe déjà contre celle qui correspond à la locale. Il ne promeut rien.

Google ne traite pas les pages traduites comme du contenu dupliqué. Mot pour mot : “Les versions localisées d’une page ne sont considérées comme des doublons que si le contenu principal reste non traduit.” La traduction est transformative. Le seul risque de doublon, c’est de traduire votre navigation en laissant le corps de page dans la langue d’origine.

La structure d’URL, et la préférence que Google n’a jamais exprimée

Google documente quatre structures et, contrairement à l’idée reçue, n’exprime aucune préférence entre les trois premières.

ccTLD (example.de) : geotargeting clair, mais coûteux, plus d’infrastructure, et il ne peut cibler qu’un seul pays.
Sous-domaine (de.example.com) : facile à mettre en place, permet des serveurs distincts, mais les utilisateurs peuvent ne pas reconnaître le ciblage à l’URL.
Sous-répertoire (example.com/de/) : facile à mettre en place, peu de maintenance, un seul emplacement serveur, séparation des sites plus difficile.
Paramètres d’URL (example.com?loc=de) : la seule option que Google qualifie explicitement de “non recommandée”.

Le consensus des praticiens selon lequel les sous-répertoires sont préférables, parce qu’ils héritent de l’autorité du domaine racine, est un vrai consensus, et ce n’est pas une déclaration de Google. Dites-le, et choisissez selon vos contraintes. Un site Framer avec des pages traduites en /fr et /de est sur la voie des sous-répertoires, celle qui demande le moins de maintenance.

Une chose qui, elle, est une déclaration de Google : le geotargeting concerne le pays, pas la langue. Le ciblage linguistique, c’est le travail du hreflang.

Ce que changent les services de traduction tiers

Les services qui servent vos pages traduites depuis leur propre infrastructure peuvent être correctement indexés, et Google n’en a jamais approuvé ni condamné aucun nommément. Ne croyez aucun éditeur prétendant que Google valide son approche : ce document n’existe pas.

Ce qui compte est mécanique, et découle de la doctrine générale de Google :

Les pages traduites ont besoin de leurs propres URLs explorables et d’un HTML rendu côté serveur. Une couche JavaScript qui échange le contenu sur une seule URL ne fera pas indexer ses traductions comme des pages distinctes.
Si un service montrait le contenu traduit aux visiteurs et l’original à Googlebot selon le user-agent, ce serait du cloaking, que la politique anti-spam de Google définit comme “présenter un contenu différent aux utilisateurs et aux moteurs dans l’intention de manipuler le classement”. Les services sérieux l’évitent.

Weglot sert les versions traduites sur un sous-domaine ou un sous-répertoire, avec un reverse proxy disponible en Enterprise. Linguana sert des pages statiques traduites depuis sa propre infrastructure, en sous-répertoires. Les deux sont indexables. La question est de savoir quelles URLs accumulent l’autorité, et ce qui survit si vous arrêtez de payer.

Ce que la traduction automatique fait vraiment à votre référencement, en 2026

C’est ici que presque tous les articles sont périmés, y compris une version antérieure de celui-ci.

Jusqu’au début 2024, les politiques anti-spam de Google contenaient une section intitulée “Contenu auto-généré à caractère de spam”, qui listait comme exemple explicite : “Texte traduit par un outil automatisé sans relecture ni curation humaine avant publication.”

Le 5 mars 2024, Google a remplacé cette section par une nouvelle politique, “scaled content abuse” (abus de contenu à grande échelle). Son annonce précise que la nouvelle politique “s’appuie sur notre précédente politique sur le contenu auto-généré, afin que nous puissions agir sur l’abus de contenu à grande échelle, que le contenu soit produit par automatisation, par des humains, ou par une combinaison des deux”.

Le point isolé sur la traduction non relue a disparu. Dans la politique actuelle, la traduction n’apparaît qu’une fois, comme exemple d’abus à grande échelle : “scraper des flux, des résultats de recherche ou d’autres contenus pour générer de nombreuses pages (y compris via des transformations automatisées comme la synonymisation, la traduction ou d’autres techniques d’obfuscation), lorsque peu de valeur est apportée aux utilisateurs”.

La position honnête en 2026 est donc :

La traduction automatique n’est pas du spam. Elle le devient quand elle participe à générer de nombreuses pages dont l’objet premier est de manipuler le classement plutôt que d’aider les utilisateurs, quelle que soit la façon dont ces pages ont été faites.

Le test est passé de “un humain est-il intervenu ?” à “est-ce produit à grande échelle pour manipuler le classement, et est-ce que ça apporte de la valeur ?”. Traduire vos quinze vraies pages avec l’IA, puis les relire, est très loin de cette ligne.

Cela dit, la relecture paie, et on sait où. ISO 18587, la norme qui encadre la post-édition de traduction automatique, nomme les classes d’erreurs récurrentes : traductions littérales, fautes de grammaire comme les négations, et noms qui n’auraient pas dû être traduits. Des travaux évalués par les pairs (EAMT 2020) documentent une sortie machine exacte et grammaticale qui échouait pourtant complètement aux exigences de registre d’une marque, et des noms de produits traduits en charabia. Les défauts de genre sont eux aussi bien étudiés.

La règle pratique : traduisez avec l’IA, puis relisez les pages qui convertissent. Votre accueil, votre page tarifs, la page vers laquelle pointent vos annonces. Mettez les noms de marque et le jargon dans un glossaire avant de commencer, parce que ni DeepL ni Google Translate n’a de notion de “ne pas traduire” par défaut : les deux l’implémentent comme une entrée de glossaire qui mappe le terme sur lui-même.

Les cinq choses qui vous font indexer

1. Chaque page traduite est une vraie URL explorable, qui renvoie du HTML contenant le contenu traduit. Sans ça, rien d’autre dans cette liste ne compte.

2. Du hreflang sur chaque version, réciproque, auto-référent, absolu. C’est là que les sites cassent, et Search Console a cessé d’en signaler les erreurs en 2022. Le guide hreflang dédié couvre les règles et la vérification.

3. Chaque version linguistique se canonicalise elle-même. Une page française dont le canonical pointe vers l’anglaise a demandé à ne pas être indexée.

4. Un sélecteur de langue fait de vrais liens. Google est explicite : “Google ne peut explorer votre lien que s’il s’agit d’un élément HTML <a> doté d’un attribut href.” Il précise ne pas pouvoir suivre de façon fiable <span href>, <a onclick> ou href="javascript:goTo()". Un sélecteur bâti sur des boutons et du JavaScript peut laisser vos autres langues introuvables.

5. Aucune redirection automatique par IP ou Accept-Language. Google : “Évitez de rediriger automatiquement les utilisateurs selon leur langue supposée. Ces redirections peuvent empêcher les utilisateurs (et les moteurs) de voir toutes les versions de votre site.” L’alternative qu’il recommande est exactement le point 4 : “envisagez d’ajouter des hyperliens vers les autres versions linguistiques”. Si vous voulez aider, affichez une bannière qui suggère l’autre langue. Ne l’imposez pas.

Deux points de plus que personne n’automatise à votre place : donnez à chaque page traduite son propre titre et sa propre méta-description dans sa langue (Google ne publie aucune règle là-dessus, mais une page française portant un extrait anglais correspond mal à un chercheur francophone), et vérifiez que chaque version linguistique figure dans votre sitemap. Framer génère le sitemap pour vous et y inclut les versions de locale quand vous utilisez les Locales natives.

N’oubliez pas le CMS

Si votre blog ou votre catalogue produit vit dans une collection CMS, traduire les pages statiques laisse l’essentiel de votre contenu indexable dans une seule langue. Les collections ont leur structure et leurs URLs propres, et c’est à ça que sert CMS Translator. Il y a un guide pour ça.

Où Page Translator se situe, honnêtement

Page Translator vous donne le point 1 (de vraies pages à de vraies URLs, dans votre propre projet), le point 3, et un sélecteur fait de vrais liens.

Sur le point 2, lisez attentivement. Le plugin injecte les balises hreflang avec un script qui s’exécute dans le navigateur, pas dans le HTML servi, parce que Framer verrouille le lang et le hreflang rendus côté serveur sur ses Locales natives payantes. Google exécute le JavaScript et peut les voir ; Bing y est moins fiable. Il ne traduit les slugs qu’en mode DeepL, et ne traduit jamais les titres de page ni les méta-descriptions, ce que font les Locales natives de Framer et Linguana.

Si un hreflang rendu côté serveur, des slugs traduits et des métadonnées par locale sont des exigences, les Locales natives sont l’outil le plus solide, et elles coûtent 20 $ par locale et par mois. C’est un vrai arbitrage, et vous devez le faire avec les faits.

Sources primaires : Google Search Central, Managing multi-regional and multilingual sites (mis à jour le 10 décembre 2025) ; Tell Google about localized versions of your page (mis à jour le 22 décembre 2025) ; Spam policies (mis à jour le 15 mai 2026) ; March 2024 core update and new spam policies ; Make your links crawlable. ISO 18587:2017. Nunziatini & Marg, EAMT 2020. Vérifié le 9 juillet 2026.