Comment traduire un site Astro : routage i18n et SEO

L’architecture d’Astro, qui privilégie le statique, se prête naturellement aux sites marketing multilingues, à condition que les équipes traitent le routage i18n, les collections de contenu et les annotations SEO comme des travaux d’ingénierie à part entière. Les développeurs Astro déploient souvent de beaux dossiers de langue, avant de découvrir que les annotations hreflang manquent, que les éléments communs de l’interface restent en anglais ou que les îlots hybrides affichent des chaînes non traduites côté client.

Ce guide explique comment traduire un site Astro : HTML explorable pour chaque langue, collections de contenu organisées, éléments de mise en page et balises SEO localisés, sitemaps compatibles avec hreflang, points de vigilance liés au rendu hybride et workflows éditoriaux pour Markdown et MDX. Le tout s’appuie sur les exigences de Google pour les sites multilingues, sans inventer de facteurs de classement.

Les questions auxquelles ce guide répond

• Comment le routage i18n d’Astro permet-il de créer des versions linguistiques explorables ?
• Comment organiser les collections de contenu par langue ?
• Comment localiser les éléments communs de l’interface et les balises SEO dans Astro ?
• Comment générer les annotations hreflang pour les pages statiques produites par Astro ?
• Quand le rendu hybride est-il nécessaire pour les sites Astro multilingues ?
• Comment intégrer le workflow de traduction aux contenus Markdown/MDX ?
• Quelles sont les erreurs courantes sur les sites Astro multilingues ?
• Quand les équipes Astro devraient-elles adopter une plateforme de traduction ?

En bref : le HTML statique par langue est l’atout SEO d’Astro

En bref : utilisez le routage i18n d’Astro pour prégénérer des URL distinctes par langue avec un HTML entièrement localisé, comprenant la navigation, les métadonnées et le contenu principal, puis ajoutez des annotations hreflang réciproques entre les différentes versions.

Un HTML prégénéré pour chaque URL linguistique répond bien à la préférence de Google pour des versions linguistiques explorables dotées d’URL distinctes. Astro peut produire des fichiers statiques par langue lors du build : les robots d’exploration reçoivent ainsi le même document dans la langue concernée que les utilisateurs, sans dépendre d’un sélecteur de langue côté client.

Google recommande des URL distinctes et explorables pour chaque version linguistique, plutôt que de s’appuyer uniquement sur les cookies ou la langue du navigateur. Le routage astro:i18n d’Astro, ou des modèles équivalents avec préfixes de langue, permet de suivre cette approche lorsque vous générez un chemin de sortie par langue.

Routage i18n d’Astro et structure des URL

Configurez Astro en définissant explicitement les langues disponibles et la langue par défaut. Voici les structures d’URL courantes :

• Ajouter un préfixe à la langue par défaut (/en/about, /fr/about) — une structure explicite et facile à annoter.
• Masquer le préfixe de la langue par défaut (/about pour l’anglais, /fr/about pour le français) — des URL plus épurées pour le marché principal ; indiquez la correspondance dans les annotations hreflang.

Dans astro.config.mjs, définissez i18n.locales, i18n.defaultLocale et i18n.routing en fonction de votre matrice. Chaque fichier de route doit recevoir la locale active via les API d’Astro pour que les modèles affichent la bonne langue.

Google détermine la langue d’une page principalement à partir de son contenu visible ; chaque version linguistique doit donc proposer un contenu et une navigation majoritairement dans une seule langue. Reliez les composants de navigation à des dictionnaires de traduction tenant compte de la locale afin que les en-têtes et pieds de page soient dans la même langue que le corps de la page.

Évitez les redirections automatiques fondées sur une langue ou une localisation supposée. Google déconseille ces redirections et recommande un sélecteur de langue visible par l’utilisateur, proposant des liens vers les autres versions linguistiques.

Pour mieux comprendre les enjeux stratégiques du ciblage par langue ou par pays, consultez notre article sur le SEO international et le SEO multilingue.

Collections de contenu par locale

Les collections de contenu d’Astro alimentent les blogs, la documentation et les textes des pages de destination. Structurez votre contenu multilingue de manière réfléchie :

• Des répertoires de collections distincts par locale (src/content/blog/en/, src/content/blog/fr/), avec des schémas partagés.
• Un champ de locale dans le frontmatter pour filtrer une collection unique lorsque les volumes sont faibles.
• Des index générés ou reliés par des liens symboliques qui ne répertorient que les éléments disponibles dans chaque locale — évitez de publier des ébauches vides pour certaines locales.

Chaque document localisé doit utiliser des ressources et des liens internes adaptés à sa locale. Un article en français qui renvoie vers une documentation uniquement en anglais nuit à la confiance des utilisateurs et à la cohérence linguistique.

Lorsqu’aucun contenu équivalent n’existe dans une locale, ne créez pas de fausses correspondances hreflang : traduisez les contenus concernés ou omettez cette relation jusqu’à ce que les traductions soient prêtes.

Localisation des mises en page, du SEO et d’Open Graph

Centralisez les éléments d’interface communs dans des composants tenant compte de la locale :

• BaseLayout.astro lit Astro.currentLocale (ou votre fonction utilitaire i18n) et sélectionne les chaînes dans des dictionnaires JSON ou TS.
• <title> et la méta-description proviennent du frontmatter ou des champs du CMS propres à chaque page, et non de textes anglais codés en dur.
• Les balises Open Graph et Twitter reprennent le titre et la description localisés.
• L’attribut html lang correspond à la locale active (pour l’accessibilité et la clarté ; Google continue de s’appuyer sur le contenu visible pour détecter la langue).

Les titres SEO et les méta-descriptions localisés doivent être propres à chaque URL de locale. Une localisation superficielle, limitée aux éléments communs — une navigation traduite avec des articles en anglais — produit des versions linguistiques de faible qualité.

Hreflang et génération de sitemaps

Les sites Astro doivent eux aussi inclure des annotations hreflang réciproques (dans le HTML, les en-têtes ou les sitemaps) entre les URL des différentes locales lorsque des versions alternatives existent. Lors du build, générez une matrice des locales à partir de votre graphe de contenu :

1. Pour chaque page logique, répertoriez toutes les URL de locale publiées.
2. Ajoutez <link rel="alternate" hreflang="..." href="..." /> dans <head> de chaque fichier HTML statique, ou
3. Générez un sitemap XML avec des versions alternatives xhtml:link pour chaque entrée d’URL.

Les sitemaps XML facilitent la découverte des versions linguistiques et peuvent contenir des annotations hreflang xhtml:link si vous choisissez cette méthode d’implémentation.

Chaque URL linguistique doit avoir une URL canonique clairement définie dans la même langue. Les recommandations de Google sur les URL canoniques s’appliquent aussi bien aux sites statiques qu’aux sites dynamiques.

Intégrez la génération du sitemap à l’intégration continue — @astrojs/sitemap associé à des hooks de sérialisation personnalisés fonctionne bien — pour que les annotations hreflang restent synchronisées lorsque le contenu change.

Consultez les fondamentaux du SEO multilingue pour découvrir comment les équipes éditoriales gèrent les annotations en coordination avec les développements techniques.

Îlots hybrides et contenu dynamique : points de vigilance

L’architecture en îlots d’Astro permet d’hydrater sélectivement des composants React, Vue ou Svelte. Voici les points de vigilance en contexte multilingue :

• Les widgets exécutés uniquement côté client peuvent s’afficher en anglais jusqu’au chargement de JavaScript, ce qui nuit à la détection de la langue et à l’expérience utilisateur.
• Effectuez le rendu côté serveur du HTML initial des îlots dans la bonne locale lorsque c’est possible.
• Les routes dynamiques (output: 'server' ou hybrid) nécessitent de transmettre la locale via un middleware pour que le HTML rendu côté serveur corresponde au préfixe de l’URL.

Quand le rendu hybride est-il nécessaire ? Utilisez un rendu hybride ou côté serveur lorsque le contenu est personnalisé, réservé aux utilisateurs authentifiés ou récupéré au moment de la requête. Générez néanmoins des structures de pages statiques localisées et explorables pour les pages marketing qui doivent être bien référencées. Privilégiez la génération statique pour les versions localisées des pages marketing ; réservez le rendu dynamique aux sections de l’application nécessitant une authentification.

Workflow éditorial pour les contenus MDX et CMS

Pour de nombreuses équipes, Markdown et MDX restent la couche de contenu la plus facile à maintenir dans Astro :

1. Chaînes sources dans les fichiers de traduction (src/i18n/fr.json) pour les éléments d’interface.
2. Frontmatter dans chaque fichier de locale pour les contenus longs.
3. Pull requests par lot de locales avec vérification du respect du glossaire.
4. Export vers un outil de TAO ou un TMS pour les grands ensembles de documentation, puis réimportation dans src/content.

Les recommandations de Google sur les contenus utiles privilégient les pages conçues avant tout pour les internautes ; les traductions purement automatiques publiées sans relecture offrent des expériences localisées pauvres.

Définissez des critères bloquants pour la publication : aucune fusion si des champs obligatoires d’une locale sont manquants, si des liens internes renvoient hors de la locale ou si les paires hreflang contrôlées par échantillonnage ne sont pas réciproques.

Liste de contrôle de mise en œuvre

• Configurer les locales i18n d’Astro et la stratégie de préfixes de routage
• Créer des mises en page et des fichiers de dictionnaire adaptés à la locale
• Organiser les collections de contenu par locale avec des schémas partagés
• Localiser le titre, les balises meta, les balises OG et html lang dans chaque modèle
• Construire une matrice locales × URL à la compilation
• Générer des annotations hreflang réciproques dans le HTML ou le sitemap
• Définir des URL canoniques dans la même langue pour chaque page statique générée
• Effectuer le rendu des îlots côté serveur ou de manière statique dans la locale active
• Ajouter un sélecteur de langue visible sans redirections forcées
• Lancer une exploration de la préproduction après le lancement de chaque locale

Erreurs courantes

1. Structure de mise en page uniquement en anglais sur les routes localisées.
2. Annotations hreflang manquantes parce que les chemins statiques étaient gérés manuellement.
3. Locale par défaut masquée sans déclaration des versions alternatives — réciprocité rompue.
4. Sélecteur de langue rendu côté client sans URL distinctes.
5. MDX mêlant plusieurs langues à la suite de fusions de traductions partielles.
6. Publication de versions localisées incomplètes contenant du lorem ipsum ou des textes provisoires en anglais.
7. Absence de sitemap sur les grands sites statiques — découverte des pages plus lente.
8. URL canonique pointant vers une autre langue par négligence.

Les consignes de Bing aux webmasters soulignent également l’importance d’un contenu utile et explorable ainsi que d’une structure de site claire pour l’indexation sur différents marchés.

Les fondamentaux de la recherche traditionnelle et des moteurs de réponse

Les fondamentaux communs au HTML statique localisé d’Astro et aux collections de contenu restent essentiels pour Google, Bing et les moteurs de réponse : des versions linguistiques explorables, des entités clairement identifiées, des affirmations étayées, des données structurées conformes à la réalité et une véritable localisation, plutôt que de simples structures de pages en anglais. Considérez les guides ci-dessous comme des approches propres à chaque plateforme, au service d’un même niveau d’exigence pour la diffusion multilingue.

Guide par plateforme : Google Search

Sur Google Search, la découverte des pages repose sur des URL localisées explorables, avec un HTML adapté à la langue, des titres et des intertitres précis, ainsi que des annotations hreflang réciproques lorsqu’il existe des versions alternatives. Les bases techniques comprennent du contenu indexable, et non des changements de langue reposant uniquement sur des cookies, des métadonnées localisées, des sitemaps et une gestion rigoureuse des URL canoniques. Un contenu de qualité suppose un contenu principal conçu d’abord pour les internautes dans chaque langue ; l’autorité repose sur une identité d’organisation claire et des sources concordantes, pas sur le discours marketing d’un outil de traduction. Conséquence pour le multilingue : chaque URL propre à un marché ou à une langue doit se suffire à elle-même. Mesurez les résultats à l’aide des rapports de couverture et de l’outil d’inspection d’URL de Search Console pour chaque version locale. Ce qui est établi et ce qui reste incertain : Google documente le fonctionnement du multilingue et de hreflang, mais ne garantit aucun positionnement lié à un CMS ou à un processus de post-édition de traduction automatique (MTPE).

Guide par plateforme : Bing

Bing découvre et indexe les pages multilingues explorables dont la structure est claire, avec des exigences de clarté des URL et du contenu similaires à celles de Google. Les bases techniques comprennent des URL localisées accessibles aux robots, du contenu utile et un suivi dans Bing Webmaster Tools. Privilégiez la localisation des titres, des affirmations et des FAQ plutôt que la seule traduction de l’interface. Les signaux d’autorité reposent toujours sur des sources fiables et des entités cohérentes. Conséquence pour le multilingue : ne masquez pas les langues derrière des sélecteurs fonctionnant uniquement côté client. Mesurez l’indexation et les statistiques d’exploration dans Bing Webmaster Tools. Ce qui est établi et ce qui reste incertain : les consignes de Bing mettent l’accent sur du contenu utile et explorable ; n’inventez pas de facteurs de classement propres à Bing pour les outils de traduction.

Guide par plateforme : ChatGPT

ChatGPT peut citer ou résumer des pages accessibles au public lorsque leurs versions linguistiques sont clairement identifiées et que leur contenu se prête à la formulation de réponses. La découverte ne suit pas un classement classique fondé sur l’exploration : la visibilité consiste à être sélectionné comme source ou mentionné dans les réponses. Les bases techniques reposent toujours en premier lieu sur des URL HTML accessibles, et non sur des widgets en surcouche qui masquent le texte. Parmi les qualités utiles du contenu figurent des réponses directes, des FAQ et une terminologie stable issue de glossaires. L’autorité repose sur des preuves et sur la cohérence des entités entre les versions locales. Conséquence pour le multilingue : chaque page localisée doit être compréhensible de manière autonome. La mesure reste imparfaite : considérez les vérifications de citations comme des hypothèses à tester. Ce qui est établi et ce qui reste incertain : aucune garantie documentée n’indique que la MTPE ou une quelconque intégration à un CMS permet d’obtenir des citations dans ChatGPT.

Guide par plateforme : Gemini

Gemini et les expériences d’IA associées de Google bénéficient d’entités cohérentes, de données structurées conformes à la réalité et de pages localisées indexables. La visibilité consiste à être cité ou reconnu, pas à inventer des facteurs de classement pour Gemini. Les bases techniques recoupent les exigences de Google Search en matière d’explorabilité et de qualité des métadonnées. Le contenu doit présenter des affirmations et des définitions claires dans chaque langue. L’autorité dépend de la cohérence de l’identité de l’organisation et d’éléments corroborants. Conséquence pour le multilingue : des noms de produits encadrés par un glossaire réduisent les confusions entre les versions locales. Mesurez les performances de manière classique avec Search Console et analysez qualitativement un échantillon de réponses de l’IA. Ce qui est établi et ce qui reste incertain : le comportement de Gemini ne remplace pas les recommandations documentées de Google Search concernant hreflang et les versions linguistiques.

Guide par plateforme : Google AI Overviews

Google AI Overviews peut proposer des liens vers des pages qui étayent ses réponses ; les critères d’éligibilité reposent toujours sur un contenu indexable, conçu d’abord pour les internautes. Ces aperçus ne sont pas un sélecteur de langue et ne remplacent pas hreflang. Les bases techniques restent un HTML localisé explorable et des données structurées conformes à la réalité. Un contenu de qualité comprend des réponses concises et des titres clairs dans chaque langue. Les signaux d’autorité reflètent les exigences relatives au contenu utile. Conséquence pour le multilingue : aucune page traduite n’est assurée d’être incluse dans un aperçu. Utilisez les rapports de Search Console sur les résultats génératifs lorsqu’ils sont disponibles, tout en suivant séparément les indicateurs d’indexation classiques. Ce qui est établi et ce qui reste incertain : aucun processus de traduction ne peut promettre une présence dans les aperçus.

Le rôle de GlotEO

Quand les équipes Astro devraient-elles adopter une plateforme de traduction ? Dès que le respect du glossaire, les files de relecture par locale et les matrices hreflang deviennent trop complexes pour être gérés manuellement via des pull requests JSON et MDX.

Les équipes techniques peuvent mettre en place un routage i18n irréprochable dans Astro ; la localisation exige aussi des glossaires, des files de révision et un processus de publication rigoureux. Découvrez la localisation de sites web avec GlotEO pour relier les briefs, le workflow de traduction et les étapes de validation qualité aux pipelines de contenu de sites statiques. Ainsi, les mises à jour des fichiers MDX et des dictionnaires restent cohérentes avec les balises hreflang et les métadonnées SEO générées lors du build Astro.

Comparez les tarifs et les offres de GlotEO lorsque le volume de traduction devient trop important pour modifier manuellement les fichiers JSON, et utilisez des outils de gestion des workflows SEO multilingues pour que les développeurs comme les équipes de contenu gardent une vue claire sur les matrices de langues et de régions ainsi que sur les exigences éditoriales.

Complétez ce tutoriel Astro par une lecture sur les différences entre SEO international et SEO multilingue lorsque la stratégie de ciblage par langue et par pays doit être définie avant la mise en œuvre technique.