fr
EnglishSvenskaDeutschNederlandsFrançaisEspañolItaliano

Lunover Engineering Notes

Checklist SEO Next.js 16 pour la production

Une checklist prête pour la prod pour le SEO Next.js 16 : metadata, canoniques, hreflang, hygiène de sitemap, règles robots, schema et QA de release automatisable.

March 5, 2026By LunoverWork with us

Checklist SEO Next.js 16 pour la production

Le SEO technique est surtout une discipline opérationnelle. Le moyen le plus rapide de perdre des positions, c’est de livrer une release avec des canoniques incohérents, des metadata dupliquées ou un sitemap cassé. Cette checklist est écrite pour des équipes qui construisent des sites marketing et des sites de services en Next.js 16 (App Router), en particulier avec plusieurs locales.

À quoi ressemble « done »

  • Chaque page indexable a un titre + une description uniques, alignés avec l’intention de la page.
  • Les canoniques écrasent les doublons (host, alias de locale, conventions de trailing slash).
  • Les hreflang pointent uniquement vers de vrais équivalents et incluent x-default.
  • Le sitemap contient uniquement des URLs canoniques, indexables, et un lastmod fiable.
  • Le JSON-LD correspond au contenu visible de la page.
  • Vous pouvez vérifier tout cela dans l’HTML rendu.

1. La metadata appartient à la route

Ne vous appuyez pas sur un défaut global unique pour les pages “business”. Pour chaque route indexable, vérifiez que vous générez :
  • title
  • description
  • URL canonique
  • image Open Graph / Twitter
Si vous utilisez metadataBase dans Next.js, préférez des valeurs relatives dans le code et laissez Next composer des URLs absolues. Exemple : 
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
  alternates: {
    canonical: "/services/web-development/",
    languages: {
      en: "/services/web-development/",
      de: "/de/services/web-development/",
      "x-default": "/services/web-development/",
    },
  },
  robots: {
    index: true,
    follow: true,
  },
};
Référence : generateMetadata / Metadata API de Next.js.

2. Les canoniques doivent être stables et assumées

Choisissez une politique et appliquez-la :
  • un seul host (par exemple www)
  • une seule convention de trailing slash
  • une seule convention de locale par défaut
Puis redirigez tout le reste de façon permanente. Si votre politique canonique est « www + trailing slash + pas de préfixe /en », assurez-vous que ces URLs ne se résolvent jamais comme des pages indexables séparées :
  • https://lunover.com/...
  • https://www.lunover.com/en/...
  • https://www.lunover.com/... (sans trailing slash)

3. Hreflang ne doit inclure que de vrais équivalents

Hreflang ne veut pas dire « traduire l’URL ». Ça veut dire « déclarer des pages équivalentes ». Règles qui gardent des clusters propres :
  • inclure des alternates uniquement pour les locales où la page existe
  • chaque variante de locale doit se référencer elle-même et référencer le même ensemble d’alternates
  • inclure x-default pointant vers la version de langue par défaut
Référence : versions localisées Google (hreflang).

4. Robots : une question d’intention, pas de tradition

robots.txt contrôle le crawl. Le noindex au niveau page contrôle l’indexation. Utilisez noindex au niveau page pour les pages qui ne doivent jamais apparaître en recherche :
  • pages de chat utilitaires
  • pages d’outils internes
  • pages temporaires que vous ne voulez pas indexer
Dans la metadata Next.js, c’est un champ de première classe :

5. Le sitemap doit être ennuyeux et fiable

Un sitemap n’est pas du marketing. C’est un contrat machine. Incluez uniquement :
  • URLs canoniques
  • URLs indexables
  • lastmod exact
Google recommande explicitement que lastmod reflète la dernière mise à jour significative (contenu principal, données structurées ou liens), pas un bump cosmétique de timestamp. Référence : guidance sitemap Google.

6. Les données structurées doivent correspondre à ce que l’utilisateur voit

Le JSON-LD doit être dérivé de la même source de vérité que la page. Schemas de base qui font souvent sens :
  • Organization (site-wide)
  • WebSite (homepage)
  • Service (pages services)
  • BlogPosting (articles)
Le mode d’échec à éviter : « le schema dit une chose, la page en dit une autre ». Référence : guidelines Google pour les données structurées.

7. Le maillage interne fait partie de l’infrastructure SEO

Si les articles techniques ne lient jamais vers les pages services, les moteurs de recherche ont du mal à associer votre expertise à vos intentions commerciales. Une règle simple qui scale :
  • chaque article technique pointe vers au moins une page service pertinente
  • chaque page service pointe vers au moins un article technique pertinent
Commencez par :

8. Release QA (automatisable)

Avant de déployer, vérifiez sur l’HTML rendu :
  • titres/descriptions uniques sur les pages clés
  • canonical correct et absolu
  • set hreflang correct
  • meta robots correcte (surtout noindex)
  • sitemap qui se rend correctement et contient les URLs attendues
  • schema rendu et validé
Traitez ces points comme des gates de déploiement. Le SEO est trop sensible pour dépendre de spot checks manuels.

Related