Comment traduire un site web Astro : routage i18n et SEO

Déployez des URL localisées et explorables sur Astro grâce au routage i18n, aux collections de contenu, aux balises SEO localisées, aux sitemaps compatibles avec hreflang et aux processus éditoriaux MDX.

Grant DaviesMis à jour

Comment traduire un site Astro : des composants en îlots Astro flottant dans le cadre d’une page statique, avec des pastilles de dossiers de langue sur un

L’architecture d’Astro, axée sur le statique, convient naturellement aux sites marketing multilingues, à condition que les équipes traitent le routage i18n, les collections de contenu et les annotations SEO comme des tâches d’ingénierie à part entière. Les développeurs Astro livrent souvent des dossiers de langue impeccables, puis découvrent qu’il manque les annotations hreflang, que les éléments communs de la mise en page 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 par langue, collections de contenu structurées, mise en page et balises SEO localisées, sitemaps compatibles avec hreflang, précautions liées au rendu hybride et processus éditoriaux pour Markdown et MDX. Le tout s’appuie sur les exigences multilingues de Google, sans inventer de facteurs de classement.

Les questions auxquelles répond ce guide

  • 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 mise en page 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 un site Astro multilingue ?
  • Comment intégrer le processus 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 ?

Réponse rapide : 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é, y compris la navigation, les métadonnées et le contenu principal, puis ajoutez des annotations hreflang réciproques entre les différentes versions.

Le HTML prégénéré pour chaque URL linguistique répond bien à la préférence de Google pour des versions linguistiques explorables, accessibles via des URL distinctes. Astro peut générer des fichiers statiques pour chaque 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 changement de langue côté client.

Google recommande des URL explorables distinctes pour chaque version linguistique, plutôt qu’un fonctionnement reposant uniquement sur les cookies ou la langue du navigateur. Le routage astro:i18n d’Astro, ou des modèles équivalents avec préfixe de langue, permet d’appliquer cette approche en générant un chemin de sortie pour chaque langue.

Routage i18n d’Astro et structure des URL

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

  • Ajouter un préfixe pour la langue par défaut (/en/about, /fr/about) : une structure explicite et facile à annoter.
  • Masquer 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 selon votre matrice de langues. Chaque fichier de route doit recevoir la langue 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 du contenu visible ; chaque version linguistique doit donc présenter un contenu et une navigation essentiellement dans une seule langue. Reliez les composants de navigation à des dictionnaires de traduction tenant compte de la langue active 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, avec des liens vers les URL des autres versions.

Pour mieux comprendre les enjeux stratégiques du ciblage par langue ou par pays, consultez SEO international et SEO multilingue : quelles différences ?.

Collections de contenu par langue

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

  • Des répertoires de collection distincts par langue (src/content/blog/en/, src/content/blog/fr/), avec des schémas communs.
  • Un champ de langue dans le frontmatter pour filtrer une collection unique lorsque le volume est faible.
  • Des index générés ou reliés par des liens symboliques qui répertorient uniquement les éléments disponibles dans chaque langue : évitez de publier des pages linguistiques vides.

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

Lorsqu’un contenu équivalent n’existe pas dans une langue, ne créez pas de fausses correspondances hreflang : traduisez le contenu concerné ou omettez cette relation jusqu’à ce que la traduction soit prête.

Localiser les mises en page, le SEO et les balises Open Graph

Centralisez les éléments communs de mise en page dans des composants tenant compte de la langue active :

  • BaseLayout.astro lit Astro.currentLocale (ou votre 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 langue active, pour l’accessibilité et la clarté ; Google continue toutefois de s’appuyer sur le contenu visible pour détecter la langue.

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

Génération des annotations hreflang et des sitemaps

Les sites Astro doivent eux aussi produire des annotations hreflang réciproques entre les URL linguistiques lorsque des versions alternatives existent, que ce soit dans le HTML, les en-têtes ou les sitemaps. Lors du build, générez une matrice des langues à partir de votre graphe de contenu :

  1. Pour chaque page, répertoriez toutes les URL linguistiques publiées.
  2. Insérez <link rel="alternate" hreflang="..." href="..." /> dans <head> pour chaque fichier HTML statique, ou
  3. Générez un sitemap XML contenant 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 xhtml:link hreflang si vous choisissez cette méthode d’implémentation.

Chaque URL linguistique doit indiquer clairement une URL canonique dans la même langue. Les recommandations de Google sur les URL canoniques s’appliquent aux sites statiques comme 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 convient 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 les composants React, Vue ou Svelte. Voici les points de vigilance pour le multilingue :

  • Les widgets exclusivement 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 langue lorsque c’est possible.
  • Les routes dynamiques (output: 'server' ou hybrid) nécessitent de transmettre la langue via le 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 le rendu hybride ou côté serveur lorsque le contenu est personnalisé, soumis à authentification ou récupéré au moment de la requête, tout en générant des structures de page statiques et explorables pour les versions linguistiques des pages marketing qui doivent être bien référencées. Pour ces pages, privilégiez la génération statique par défaut ; réservez le rendu dynamique aux sections de l’application accessibles après 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 langue pour les contenus longs.
  3. Pull requests par lot de traductions d’une même langue, avec vérification du respect du glossaire.
  4. Export vers un outil de TAO ou un TMS pour les grands ensembles documentaires, puis réimportation dans src/content.

Les recommandations de Google sur le contenu utile privilégient les pages conçues avant tout pour les internautes ; les contenus générés automatiquement sans révision produisent des versions linguistiques pauvres.

Définissez des critères bloquants avant publication : aucune fusion si des champs obligatoires d’une version linguistique sont manquants, si des liens internes renvoient vers une autre langue ou si les paires hreflang testées ne respectent pas la réciprocité.

Liste de contrôle de mise en œuvre

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. Langue 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. Contenu MDX mêlant plusieurs langues à la suite de fusions de traductions partielles.
  6. Publication de versions linguistiques inachevées avec 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 recommandations de Bing aux webmasters soulignent également l’importance d’un contenu explorable et utile, ainsi que d’une structure de site claire, pour l’indexation sur différents marchés.

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

Les fondements communs du HTML statique localisé et des collections de contenu d’Astro restent essentiels pour Google, Bing et les moteurs de réponse : des versions linguistiques explorables, des entités clairement définies, des affirmations étayées, des données structurées fidèles au contenu et une véritable localisation, plutôt que des structures de page uniquement en anglais. Considérez les guides ci-dessous comme des éclairages propres à chaque plateforme sur les mêmes exigences de diffusion multilingue.

Dans la recherche Google, la découverte des pages repose sur des URL localisées explorables, un contenu HTML adapté à la langue, des titres et intertitres exacts, ainsi que des liens hreflang réciproques lorsque des variantes existent. Les fondements techniques comprennent un contenu indexable, et non un changement de langue reposant uniquement sur les cookies, des métadonnées localisées, des sitemaps et une gestion rigoureuse des URL canoniques. La qualité du contenu suppose un contenu principal conçu avant tout pour les internautes dans chaque langue ; l’autorité découle d’une identité claire de l’organisation et de sources concordantes, et non du discours marketing des outils de traduction. En contexte multilingue, chaque URL propre à un marché ou à une langue doit donc se suffire à elle-même. Évaluez les résultats à l’aide de la couverture d’indexation dans Search Console et de l’outil d’inspection d’URL pour chaque version locale. Ce qui est établi et ce qui reste incertain : Google documente le fonctionnement des sites multilingues et de hreflang, mais ne garantit aucun classement lié à un CMS ou à un processus de MTPE particulier.

Guide par plateforme : Bing

Bing découvre et indexe les pages multilingues explorables dont la structure est claire, avec des attentes similaires à celles de Google en matière de clarté des URL et des contenus. Les bases techniques comprennent des URL accessibles pour chaque version linguistique ou régionale, des contenus utiles et un suivi dans Bing Webmaster Tools. Privilégiez la localisation des titres, des arguments 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 rendez pas les langues accessibles uniquement par des sélecteurs fonctionnant 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 des contenus utiles et explorables ; 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 des contenus ne suit pas un classement classique fondé sur l’exploration ; la visibilité se traduit par une sélection comme source ou une mention dans les réponses. Les bases techniques reposent toujours sur des URL HTML accessibles, et non sur des widgets en surimpression qui masquent le texte. Parmi les qualités de contenu utiles figurent les réponses directes, les FAQ et une terminologie stable issue de glossaires. L’autorité repose sur des éléments probants et sur la cohérence des entités entre les versions linguistiques ou régionales. Conséquence pour le multilingue : chaque page localisée doit pouvoir être lue 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 permette 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 lorsqu’elles sont exactes et de pages localisées indexables. La visibilité consiste à être cité ou reconnu, et non à inventer des facteurs de classement propres à 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 des informations sur l’organisation et de leur corroboration. Conséquence pour le multilingue : les noms de produits encadrés par un glossaire réduisent les confusions entre les versions linguistiques ou régionales. Mesurez les résultats de manière classique dans Search Console et examinez un échantillon de réponses de l’IA sur le plan qualitatif. Ce qui est établi et ce qui reste incertain : le comportement de Gemini ne remplace pas les consignes documentées de Google Search sur hreflang et les versions linguistiques.

Guide par plateforme : Google AI Overviews

Google AI Overviews peut proposer des liens vers des pages qui étayent les réponses ; les critères d’éligibilité reposent toujours sur des contenus indexables conçus avant tout pour les internautes. Ces aperçus ne sont pas un sélecteur de langue et ne remplacent pas hreflang. Les bases techniques restent des pages HTML localisées explorables et des données structurées fidèles à la réalité. Les qualités du contenu comprennent des réponses concises et des titres clairs dans chaque langue. Les signaux d’autorité reflètent les attentes en matière de contenu utile. Conséquence pour le multilingue : aucune page traduite n’est assurée de figurer dans un aperçu. Mesurez les résultats à l’aide des rapports de Search Console sur les fonctionnalités génératives, lorsqu’ils sont disponibles, et suivez séparément les indicateurs d’indexation classiques. Ce qui est établi et ce qui reste incertain : aucun processus de traduction ne peut garantir une présence dans ces aperçus.

Le rôle de GlotEO

Quand les équipes utilisant Astro devraient-elles adopter une plateforme de traduction ? Dès que l’application du glossaire, les files de révision par langue et les matrices hreflang deviennent trop complexes à gérer au moyen de pull requests manuelles sur les fichiers JSON et MDX.

L’équipe technique peut livrer un routage i18n Astro irréprochable ; la localisation exige néanmoins 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 contrôles qualité aux pipelines de contenu des sites statiques. Les mises à jour des fichiers MDX et des dictionnaires restent ainsi cohérentes avec les annotations hreflang et les métadonnées SEO générées par votre build Astro.

Comparez les tarifs et les offres de GlotEO lorsque le volume de traduction dépasse ce que permettent les modifications manuelles de fichiers JSON, et utilisez des outils de gestion du workflow SEO multilingue pour que les matrices linguistiques et les exigences éditoriales restent visibles tant pour les développeurs que pour les équipes de contenu.

Complétez ce tutoriel Astro par une comparaison du SEO international et du SEO multilingue lorsque la stratégie linguistique et géographique doit être définie avant la mise en œuvre.

Références