Site multilingue avec Astro : une langue, une adresse

Ajouter une langue à un site paraît être une affaire de traduction. Pour les textes, oui. Mais ce qui décide si la nouvelle version sera trouvée par les moteurs, lue dans la bonne langue et partagée sans surprise, c’est la structure : où vit chaque version, comment elle désigne ses traductions, et si les liens gardent le lecteur dans sa langue. Cette structure tient en une règle, une langue, une adresse, et elle se pose avant la première page traduite. Si votre site doit d’abord changer de technologie, notre guide de la migration vers un site statique avec Astro pose le cadre.

Pourquoi une adresse par langue

Un site peut servir plusieurs langues de deux façons : la même adresse affiche un texte différent selon le visiteur (un cookie, la langue du navigateur), ou chaque langue vit à sa propre adresse. Google tranche dans sa documentation sur les sites multilingues : il recommande des adresses différentes pour chaque version linguistique, plutôt que des cookies ou des réglages du navigateur.

La raison est concrète. Une adresse qui change de langue selon le visiteur n’est qu’une page pour un moteur, qui en indexe une version. Le lien partagé par un commercial français s’ouvre en anglais chez son prospect si le navigateur de celui-ci est réglé ainsi. Et la même documentation va plus loin :

Proposer la langue du navigateur dans un bandeau reste permis : c’est le visiteur qui choisit, et l’adresse qu’il a demandée reste servie.

Quelle forme d’adresse

Google liste quatre structures : un domaine par pays (exemple.de), un sous-domaine (de.exemple.com), un sous-dossier (exemple.com/de/) et un paramètre (exemple.com?loc=de). Seul le paramètre est déconseillé. Pour une entreprise qui ouvre une langue de plus, le sous-dossier est souvent le plus simple : un seul domaine, un seul certificat, un seul hébergement, et la Search Console filtre les résultats par dossier. Le domaine par pays se justifie quand il y a une entité, une offre et une équipe propres à chaque pays.

Le chemin d’une page traduite

L’étape 3 est celle qui casse le plus souvent, parce qu’elle ne se voit pas en relisant une page : le texte est juste, la page s’affiche, et le lien mène pourtant vers l’autre langue.

Les slugs se traduisent aussi

Le slug, c’est la fin de l’adresse : cout-site-entreprise en français, business-website-cost en anglais. Un lecteur anglais qui voit une adresse en français comprend qu’il lit une traduction, et un moteur y lit un signal de langue incohérent avec la page.

La règle est donc de décider avant de publier : sur ce site, chaque article a un slug dans sa langue, et ce que vous lisez existe en anglais sous une autre adresse, reliée à celle-ci par une clé commune. Si votre site existant mélange déjà les langues dans ses adresses, une refonte est le bon moment pour trier, comme le montre notre méthode pour décider des pages à garder, fusionner ou supprimer, à condition de poser la liste des redirections 301 avant la bascule.

Hreflang : chaque page désigne ses traductions

Les balises hreflang disent au moteur : « cette page existe aussi en anglais, à telle adresse ». Elles doivent être réciproques, pointer vers des pages qui répondent, et ne citer que les langues où la page existe vraiment. Les erreurs classiques sont détaillées dans notre article sur le hreflang et le SEO multilingue.

Ce qui arrive quand la règle n’est pas tenue est rarement spectaculaire, et toujours coûteux : sur Palmora Property, un audit a relevé 24 groupes d’articles dont les traductions déclarées menaient à des pages en erreur 404. Sur ce site, le gabarit n’émet un hreflang que pour les langues où la page existe, et la version par défaut (x-default) désigne l’anglais.

Les liens qui gardent la langue

Un menu, un pied de page, un bouton d’appel à l’action, un lien dans un article : chacun doit mener à la page de la même langue. Le piège est le lien écrit en dur, avec une adresse complète sans préfixe de langue, qui ramène le lecteur dans la langue par défaut.

La parade tient en deux gestes : générer les liens à partir de la langue de la page plutôt que de les écrire, et contrôler avant publication. Sur ce site, un programme refuse un article français dont un lien interne sort de /fr/.

Ce qu’Astro fait pour tenir la règle

Astro ne traduit rien : il donne la structure pour que la traduction soit servie au bon endroit. Sa documentation sur l’internationalisation décrit ce qu’il apporte :

• Des routes par langue. On choisit si la langue par défaut vit à la racine ou dans son propre dossier ; ce site sert l’anglais à la racine et le français sous /fr/.
• Des liens générés. Des fonctions produisent l’adresse d’une page dans une langue donnée, au lieu de l’écrire à la main.
• Une langue de repli. Pour une page pas encore traduite, Astro peut renvoyer vers une autre langue ou en afficher le contenu. Nous préférons ne pas publier une page qui n’existe pas : l’hreflang ne la cite pas, et le lecteur ne tombe pas sur une redirection.
• La langue préférée du visiteur. Astro sait lire celle du navigateur ; elle sert à proposer une langue, pas à rediriger d’office.

Le contenu suit la même logique : chaque article vit dans le dossier de sa langue, et une clé commune relie ses traductions. Comme le site est statique, chaque langue n’est qu’un dossier de fichiers de plus à servir, sans base de données à dupliquer ni extension de traduction à mettre à jour. Le coût de l’hébergement ne change pas avec le nombre de langues, comme le détaille notre comparatif pour héberger un site statique.

Ajouter une langue, et savoir en retirer une

Une langue coûte à l’ouverture (traduction, relecture, structure) et chaque mois ensuite : chaque nouvelle page, chaque mise à jour se fait deux fois. Le coût de la traduction elle-même a beaucoup baissé : sur Palmora Property, il a été divisé par 60 en passant à un modèle d’IA, et 95 % des segments viennent du cache après la première traduction. Le reste du chiffrage est dans notre article sur le coût d’un site d’entreprise et dans celui sur le coût de la traduction d’un site.

L’ouverture de l’allemand sur Palmora Property donne l’ordre de grandeur d’une langue complète :

La méthode retenue : ouvrir d’abord le blog seul, qui sert de test d’intérêt à faible coût, avant de traduire tout le reste. Et quand une langue ne rapporte pas, elle se retire proprement : ce site a archivé l’espagnol et le chinois le 9 septembre 2026, chaque ancienne adresse redirigeant en 301 vers la page anglaise équivalente.

Les autres pièces du chantier

Une langue de plus touche tout le site. Les formulaires doivent répondre dans la langue du visiteur (formulaire et recherche sur un site statique), chaque version doit rester rapide (les Core Web Vitals pour un dirigeant) et accessible (l’obligation européenne d’accessibilité). Si plusieurs personnes publient dans plusieurs langues, un éditeur aide (Astro et Sanity en headless), et le choix entre Markdown dans le dépôt ou CMS pour le blog se pose. Une traduction produite avec une IA se relit, et la question de le dire se pose aussi. Enfin, la page d’accueil de chaque langue doit faire ce que fait la première, générer des demandes, et l’hébergement peut rester en Europe quel que soit le public visé. Un site sous WordPress ajoute ses propres risques à chaque extension de traduction : pourquoi un site WordPress se fait pirater.

Nos deux offres de site intègrent cette structure : le site vitrine pour partir de zéro, la migration vers un site statique pour reprendre un site existant et ses adresses, langues comprises.

Questions fréquentes

Sources

1. Google Search Central, gérer un site multirégional et multilingue (nouvel onglet)developers.google.com
2. Astro, guide de l’internationalisation (nouvel onglet)docs.astro.build