Next.js multi-site : SEO sans contenu dupliqué
Publier plusieurs sites avec une base Next.js commune sans diluer le SEO : intentions distinctes, h1 unique, métadonnées propres, maillage entre domaines et rendu serveur.

Publier plusieurs sites avec une base Next.js commune sans diluer le SEO : intentions distinctes, h1 unique, métadonnées propres, maillage entre domaines et rendu serveur.

Un site Next.js servi sur plusieurs domaines multiplie les risques de contenus dupliqués et de signaux contradictoires. Ce guide fixe la méthode : clarifier les intentions avant la structure technique, un h1 unique par document, des titres et métadonnées maîtrisés, un maillage entre domaines, le rendu serveur et une feuille de passage « page prête à indexer ».
Un même dépôt peut servir plusieurs domaines ou préfixes de route ; ce qui change pour le référencement, ce n’est pas seulement la technique, c’est l’intention de recherche :
Fixez pour chaque segment une liste courte de types de pages (accueil, tarifs, article de blog, leçon, rapport d’audit de démonstration). Tant que cette carte n’existe pas, les métadonnées copiées-collées d’un layout à l’autre sont presque inévitables.
Même lorsque React assemble plusieurs composants, chaque URL canonique doit exposer un seul titre principal du point de vue du contenu éditorial :
h1 masqués par le CSS « pour le style » ;h2 puis h3 sans sauter un niveau gratuitement ;Cette discipline profite au SEO et à l’accessibilité : une grille avant mise en ligne complète ce sujet dans checklist accessibilité reproductible avant production.
Mini-exemple : deux intentions, deux titres
Imaginons « SaaSKiosk » : la page Tarifs ne doit pas partager le même h1 que Cas clients. Si les deux affichent « La plateforme tout-en-un », vous créez de la redondance pour les moteurs comme pour les lecteurs. Préférez « Tarifs et engagements » d’un côté et « Études de cas (illustrations anonymisées) » de l’autre — formulations à ajuster selon votre terminologie marché.
Les conventions Next.js (generateMetadata, layouts) sont un outil ; la responsabilité qualité reste humaine :
title lisible dans les résultats (en pratique, restez concis ; au-delà d’une certaine largeur, les extraits sont tronqués selon le moteur).Quand yunt.fr, academy.yunt.fr, audit.yunt.fr et agency.yunt.fr coexistent, le réflexe facile est de renvoyer chaque article vers la même landing. C’est compréhensible politiquement, mais SEO et parcours utilisateur gagnent à être plus précis :
La méthode des ancres est détaillée dans maillage interne SEO et ancres descriptives.
Attention aux doubles contenus « légers »
Deux URLs qui affichent presque le même texte — par exemple une rubrique blog et une page produit recyclée — créent des signaux faibles même sans sanction spectaculaire : clarifiez la canonique, fusionnez ou différenciez réellement les corps de page.
Dans l’App Router Next.js, une partie du contenu peut être rendue côté serveur et une autre hydratée côté client. Pour la rédaction SEO :
Pour un cadre technique d’équipe plus large (TypeScript, secrets, qualité), prolongez avec bonnes pratiques développement web : cadre d’équipe durable.
Les Core Web Vitals et la performance ne sont pas « du SEO technique séparé » : une page qui annonce « guide complet » mais affiche un bloc vide pendant plusieurs secondes décourage la lecture. Mesurez avec des protocoles reproductibles et méfiez-vous des conclusions tirées d’un seul poste de travail :
Une entrée méthodologique : mesurer la performance en lab et sur le terrain sans pièges.
Les assistants peuvent proposer plans, reformulations ou variantes de méta — utiles pour iter vite. En revanche :
Cocher explicitement en revue :
h1 éditorial ; enchaînement h2→h3 cohérent.title et meta description fidèles au corps ; pas de promesse absente du texte.Pour vérifier les consignes de référence, consultez la documentation Next.js sur les métadonnées et le guide de démarrage SEO de Google. Côté Yunt :
Oui, tant que chaque site publie des contenus distincts, une URL canonique propre et des métadonnées adaptées à son audience. Le code partagé ne pose pas de problème ; ce sont les pages quasi identiques qui en posent.
Pas obligatoirement, mais des domaines ou sous-domaines distincts clarifient l’intention de chaque site et simplifient les canoniques, les sitemaps et la Search Console. Quel que soit le choix, il doit rester stable.
Ils aident à livrer un HTML complet dès la première réponse, avec titres, liens et métadonnées présents sans attendre l’exécution de JavaScript. C’est un avantage, pas une garantie de classement.
Contrôlez le code de réponse, la balise canonique, l’absence de noindex involontaire, le titre, la meta description, le h1 unique et la présence dans le sitemap. Une inspection d’URL dans la Search Console complète la vérification.
Un contenu multi-site réussi repose sur des intentions claires : chaque site, chaque page, répond à une demande précise et le dit dans son titre, son h1 et ses métadonnées. La technique (rendu serveur, canoniques, sitemaps) sert cette clarté ; elle ne la remplace pas.
Avant chaque publication, passez la page par la même feuille de contrôle courte, et mesurez ensuite ce que les moteurs indexent réellement. Pour un diagnostic extérieur, un audit de site peut servir de point de départ.