L'une des principales décisions SEO sous Next.js est la façon de rendre chaque route. Certains robots exécutent JavaScript, d'autres peuvent s'appuyer surtout sur la réponse HTML initiale. Un contenu clé présent dans cette réponse réduit la dépendance aux capacités d'un robot précis.
Règle pratique :
- Statique (SSG) : pages marketing, documentation, blog. Le plus rapide, le moins cher, entièrement indexable.
- ISR (Incremental Static Regeneration) : catalogues, listings, tout ce qui change chaque heure/jour. La vitesse du statique avec une fraîcheur maîtrisée.
- SSR (rendu dynamique) : pages personnalisées ou vraiment temps réel. Indexable, mais TTFB plus lent.
- CSR (client uniquement) : tableaux de bord et intérieur d'application. Jamais pour du contenu destiné à être indexé.
// app/blog/[slug]/page.tsx — ISR : HTML statique, régénération toutes les heures
export const revalidate = 3600;
export async function generateStaticParams() {
const posts = await getPosts();
return posts.map((post) => ({ slug: post.slug }));
}
Vérifiez ce que reçoit le robot, et non ce qu'affiche votre navigateur :
curl -s https://example.com/votre-page | grep -i "phrase-cle"
Si le contenu clé est absent de cette réponse, les robots qui ne rendent pas la page risquent de l'ignorer.
Attention au rendu dynamique accidentel. Utiliser cookies(), headers() ou searchParams dans une page la fait basculer silencieusement en SSR. Ce n'est pas fatal pour le SEO, mais cela coûte du TTFB et de la charge serveur. Nous avons décrit ces pièges en détail dans l'article Comment fonctionne le cache dans Next.js avec l'App Router.
Checklist :
- Chaque route indexable est en SSG ou ISR ; SSR seulement là où la personnalisation l'exige
- Un
curlsur le HTML brut confirme la présence du contenu principal - Aucun appel à
cookies()/headers()dans les pages qui doivent être statiques - Les composants clients servent l'interactivité, pas le contenu