Les bonnes pratiques SEO avec Next.js

Comprendre les modes de rendu et leur impact sur le SEO

C'est le point de départ. Next.js propose plusieurs stratégies de rendu, et le choix entre elles a des conséquences directes sur la façon dont Google indexe vos pages.

SSG : la base de données des pages pré-rendues

La génération statique (Static Site Generation) produit les pages HTML au moment du build. Au déploiement, chaque page existe déjà sous forme de fichier HTML prêt à être servi. Pour le SEO, c'est idéal : le crawler de Google reçoit immédiatement du HTML complet, sans attendre l'exécution de JavaScript.

C'est la stratégie à privilégier pour toutes les pages dont le contenu change peu : pages institutionnelles, articles de blog, pages produits d'un catalogue stable.

SSR : pour les pages dynamiques qui doivent rester indexables

Le rendu côté serveur (Server Side Rendering) génère le HTML à chaque requête. Le contenu est toujours à jour au moment où Google passe. C'est pertinent pour les pages de résultats de recherche interne, les pages de catégorie filtrées, ou les pages avec du contenu personnalisé selon l'utilisateur.

La contrepartie : le TTFB (Time To First Byte) est plus élevé qu'en SSG, ce qui peut peser sur les Core Web Vitals si le serveur est lent. Il faut un bon cache HTTP pour atténuer cet effet.

ISR : le meilleur des deux mondes

L'Incremental Static Regeneration est la fonctionnalité qui a beaucoup contribué à la popularité de Next.js. Elle permet de régénérer une page statique en arrière-plan après un certain délai (configuré via revalidate), sans déclencher un nouveau build complet.

Pour un blog avec des centaines d'articles ou un e-commerce avec un catalogue qui évolue quotidiennement, c'est souvent la meilleure option : les pages sont servies statiquement (performance maximale) et se mettent à jour automatiquement.

Métadonnées : l'API Metadata de Next.js 13+

Avant Next.js 13, gérer les métadonnées nécessitait next/head dans chaque page, avec un risque élevé de doublons et d'oublis. Depuis l'introduction de l'App Router, Next.js propose une API Metadata bien plus propre.

La déclaration statique

Pour une page dont les métadonnées ne changent pas, on exporte un objet metadata directement depuis le fichier de la page :

export const metadata = {

title: "Titre de la page | Nom du site",

description: "Description concise entre 130 et 155 caractères.",

alternates: {

canonical: "https://monsite.fr/ma-page",

},

};

Propre, lisible, et géré nativement par le framework. Pas de composant Head à importer, pas de risque de balise dupliquée.

La génération dynamique

Pour les pages dynamiques (articles de blog, fiches produits), on utilise generateMetadata qui reçoit les params de route en argument et peut faire un fetch de données :

export async function generateMetadata({ params }) {

const product = await fetchProduct(params.slug);

return {

title: `${product.name} | Ma Boutique`,

description: product.seoDescription,

openGraph: {

images: [product.image],

},

};

}

L'objet retourné supporte toutes les balises SEO utiles : Open Graph, Twitter Card, robots, viewport. Un seul endroit pour tout gérer, par page ou par layout.

Sitemap et robots.txt : la configuration qui change tout

Next.js 13+ permet de générer sitemap.xml et robots.txt dynamiquement depuis des fichiers dédiés dans le dossier app/.

Le sitemap dynamique

Un fichier app/sitemap.ts qui retourne un tableau d'URLs suffit à générer un sitemap valide, automatiquement accessible sur /sitemap.xml. Intégrer la génération de sitemap directement dans le build garantit que Google reçoit toujours une liste à jour de vos pages.

export default async function sitemap() {

const posts = await fetchAllPosts();

return [

{ url: "https://monsite.fr", lastModified: new Date() },

...posts.map((post) => ({

url: `https://monsite.fr/blog/${post.slug}`,

lastModified: new Date(post.updatedAt),

})),

];

}

Le robots.txt

Même logique : un fichier app/robots.ts exporte une fonction qui retourne les directives. Bloquer les routes d'API ou les pages privées depuis ce fichier évite que Google ne gaspille son crawl budget sur des URLs sans valeur.

Core Web Vitals : les points de vigilance Next.js

Les Core Web Vitals (LCP, INP, CLS) sont des facteurs de classement Google depuis 2021. Next.js aide beaucoup à les atteindre, mais certains réflexes sont indispensables.

Images : toujours next/image

Utiliser next/image au lieu d'une balise <img> classique active automatiquement le lazy loading, la conversion WebP/AVIF, le redimensionnement adaptatif selon la résolution de l'écran, et le calcul du CLS via la réservation d'espace. Ignorer ce composant revient à se priver des optimisations image qui comptent le plus sur le LCP.

L'attribut priority est à ajouter sur les images visibles dans le viewport initial (hero, logo, première image d'un article) pour déclencher un prefetch et améliorer le LCP.

Fonts : next/font pour éviter le FOUT

Le chargement des polices est une source fréquente de CLS et de mauvais LCP. next/font optimise automatiquement le chargement des fonts (Google Fonts ou locales) : les fichiers sont hébergés en local, le chargement se fait sans requête externe, et le font-display: swap est géré proprement. Deux lignes de configuration pour un gain visible sur les métriques.

Bundling et Code Splitting

Next.js gère le code splitting automatiquement par route. Mais des dépendances lourdes importées globalement (bibliothèques de charts, éditeurs rich text, players vidéo) peuvent alourdir le bundle initial. next/dynamic avec { ssr: false } permet de les charger à la demande, uniquement côté client et uniquement quand la page en a besoin.

Canonical et gestion des URLs dupliquées

Les URLs dupliquées sont un problème SEO fréquent en Next.js, surtout quand le routing génère des variantes : avec ou sans slash final, en majuscules/minuscules, avec des paramètres de pagination ou de tri.

Quelques règles à appliquer systématiquement : forcer le slash final (ou l'interdire) via trailingSlash dans next.config.js, déclarer systématiquement la balise canonical sur toutes les pages, et exclure les URLs de filtre ou de pagination de l'indexation via robots: { index: false } si elles n'apportent pas de valeur propre.

Maîtriser la technique Next.js est une chose. Construire une architecture de contenu qui performe sur des requêtes compétitives en est une autre. Pour comprendre comment Next.js s'intègre dans une stratégie de site plus large et pourquoi il s'est imposé comme framework de référence, l'article sur ce que Next.js apporte concrètement aux projets web développe ce point en détail.

Et si vous hésitez encore entre Next.js et d'autres frameworks comme Gatsby ou Nuxt, la comparaison technique entre ces trois solutions vous donnera les critères pour choisir selon votre contexte précis.

Le SEO Next.js, ça se joue dans les détails. Le rendu, les métadonnées, les images, les fonts : autant de points qui semblent mineurs pris séparément et qui font la différence sur les Core Web Vitals et la capacité de Google à crawler efficacement votre site.