Le SEO multilingue dans Next.js : hreflang, sitemaps et fallbacks locaux
Une configuration pratique pour les alternatives hreflang, x-default, les sitemaps localisés, les slugs traduits et les chaînes de fallback locales dans un site Next.js multilingue.
View as MarkdownTraduire votre contenu n'est que la moitié du travail pour le SEO multilingue. L'autre moitié consiste à indiquer aux moteurs de recherche ce que vous avez fait : quelle URL correspond à quelle langue, laquelle est celle par défaut, et que faire lorsqu'une langue n'a pas encore de traduction. Si vous vous trompez, Google indexera vos pages en français pour des requêtes en anglais, ou considérera dix traductions comme du contenu dupliqué.
Voici la checklist que nous appliquons, et comment Scribe en génère la majeure partie à partir du contenu qu'il connaît déjà.
Alternatives hreflang sur chaque page
Chaque page localisée doit déclarer toutes ses pages sœurs, y compris elle-même, ainsi qu'un x-default pointant vers la version destinée aux langues non correspondantes. Dans Next.js, il s'agit du champ alternates.languages des métadonnées de la page.
La difficulté réside dans les slugs traduits. Si /docs/getting-started devient /fr/docs/premiers-pas en français, vos liens alternatifs doivent utiliser le slug localisé, et non le slug anglais avec un préfixe local. Scribe stocke le slug traduit avec chaque traduction, et la fonction alternates() du runtime renvoie la carte complète par document. Le code des métadonnées est donc une boucle plutôt qu'une table de correspondance que vous devez maintenir manuellement.
Deux règles pour éviter les erreurs courantes :
- Le hreflang doit être réciproque. Si la page française liste la page allemande, la page allemande doit lister la page française. Générer les deux côtés à partir de la même base de données garantit cela.
- Les URL canoniques doivent faire référence à elles-mêmes par langue. L'URL canonique de la page française est l'URL française. Pointer la version canonique de chaque langue vers l'anglais indique à Google de supprimer vos traductions de l'index.
Un sitemap qui connaît les langues
Chaque entrée d'URL dans le sitemap doit comporter les mêmes liens alternatifs, plus x-default. La fonction sitemapEntries() de Scribe renvoie une entrée par document avec toutes les URL locales et un lastmod dérivé des champs intégrés publishedAt et updatedAt. Le sitemap reste ainsi précis sans dates manuelles.
Les documents que vous retirez ne doivent pas simplement disparaître. Scribe conserve les redirections dans un fichier _redirects.json par type, et les URL retirées font l'objet d'une redirection 301 vers leur remplaçant dans chaque langue, ce qui préserve le capital de liens que vous avez acquis.
Des fallbacks locaux plutôt que des 404
Que doit afficher /fr-CA/guide si vous avez traduit la page en français mais pas en français canadien ? Une erreur 404 gaspille la traduction que vous possédez, tandis qu'afficher de l'anglais en silence désoriente les lecteurs.
Scribe gère automatiquement une chaîne de fallback : une langue régionale se rabat sur sa langue de base avant l'anglais. fr-CA essaie fr, puis en. zh-Hant-TW essaie zh-Hant, puis zh, puis en. Le runtime indique quelle langue a été réellement servie via actualLocale, ce qui permet à votre mise en page d'étiqueter honnêtement la page, et les paramètres prérendus incluent les URL de secours afin que les pages existent au moment de la compilation.
Les métadonnées sont aussi du contenu
Les titres et les méta-descriptions sont des éléments de positionnement et doivent être traduits avec le même soin que le corps du texte. Dans Scribe, il s'agit de champs frontmatter traduisibles ordinaires, hachés et validés comme le reste. Le prompt de traduction est conçu pour la transcréation plutôt que pour la traduction mot à mot, ce qui est particulièrement crucial pour les 60 caractères d'une balise title.
En résumé
Rien de tout cela n'est exotique. Il s'agit d'une question d'organisation : les alternatives, les canoniques, les sitemaps, les redirections et les fallbacks découlent tous d'une seule question, à savoir « quel document existe dans quelle langue et à quelle URL ». Un CMS qui stocke les traductions comme des données de premier plan peut répondre à cette question en un seul endroit. C'est lorsque vous devez relier manuellement un CMS hébergé, une plateforme de traduction et votre routeur que le SEO multilingue se brise généralement.
Découvrez comment les éléments s'articulent dans le guide de l'API d'exécution, ou commencez par la prise en main.