La solution SEO pour les pages dynamiques avec NextJS
Découvrez quand utiliser getServerSideProps ou getStaticProps pour optimiser le SEO de vos pages dynamiques avec NextJS. Guide complet et bonnes pratiques.
Choisir entre getServerSideProps et getStaticProps pour le SEO des pages dynamiques Next.js
En Next.js (Pages Router), le rendu des pages dynamiques conditionne directement leur indexabilité. Google indexe le HTML initial servi par le serveur : si ce HTML est vide au moment du crawl, la page disparaît des résultats. Choisir la bonne méthode de récupération de données n'est donc pas qu'une question de performance — c'est un choix SEO structurant.
Comprendre les deux stratégies de rendu
Next.js propose deux approches principales pour les pages dynamiques dans le Pages Router :
getServerSideProps(SSR) : les données sont récupérées à chaque requête HTTP, côté serveur. Le HTML renvoyé est toujours à jour.getStaticProps(SSG) : les données sont récupérées au moment du build. Le HTML est pré-généré et mis en cache. Une revalidation incrémentale (revalidate) permet de le rafraîchir périodiquement.
Ces deux méthodes partagent un point commun décisif pour le SEO : le contenu est présent dans le HTML renvoyé au bot de Google, sans dépendance à l'exécution de JavaScript côté client.
Quand utiliser getServerSideProps
getServerSideProps est indiqué dans trois situations précises :
Données à haute fréquence de changement. Si le contenu évolue à chaque minute (cours boursiers, stock e-commerce, données utilisateur), une page statique serait immédiatement périmée. SSR garantit la fraîcheur.
Authentification et personnalisation. Accéder à la session, aux cookies ou aux en-têtes HTTP requiert une exécution serveur à chaque requête. Les profils utilisateurs, les tableaux de bord ou les pages derrière un paywall relèvent systématiquement de SSR.
Métadonnées SEO dynamiques basées sur les paramètres. Si le <title> ou la meta description d'une page dépendent d'un paramètre de requête (?q=strasbourg), SSR permet de les injecter dans le HTML initial avec les données exactes.
export async function getServerSideProps() {
const res = await fetch('https://api.github.com/repos/vercel/next.js')
const repo = await res.json()
return { props: { repo } }
}
export default function Page({ repo }) {
return repo.stargazers_count
}
L'inconvénient de SSR : chaque requête génère une charge serveur et augmente le Time to First Byte (TTFB). Un TTFB élevé dégrade l'expérience et peut impacter le classement via les Core Web Vitals (LCP notamment).
Quand utiliser getStaticProps
getStaticProps convient aux pages dont le contenu est stable ou peut être rafraîchi à intervalles définis. C'est la stratégie SEO la plus performante car le HTML est servi depuis un CDN sans latence serveur.
Pages produit, articles de blog, pages de destination. Un article rédigé la veille n'a pas besoin d'être régénéré à chaque visite. revalidate: 3600 suffit pour maintenir la fraîcheur sans surcharge.
Pages dynamiques avec un ensemble de paramètres connu. Couplé à getStaticPaths, getStaticProps pré-génère toutes les combinaisons possibles au build. Google crawle alors des URLs déjà rendues, sans attente.
export async function getStaticProps() {
const res = await fetch('https://api.github.com/repos/vercel/next.js')
const repo = await res.json()
return { props: { repo } }
}
export default function Page({ repo }) {
return repo.stargazers_count
}
La régénération statique incrémentale (ISR) — en ajoutant revalidate dans le retour — constitue souvent le meilleur compromis : performances CDN + fraîcheur contrôlée.
Les implications SEO concrètes de ce choix
TTFB et Core Web Vitals. getStaticProps avec CDN produit des TTFB inférieurs à 100 ms. getServerSideProps peut atteindre 300–600 ms selon la source de données. Google intègre le LCP dans son algorithme de classement ; un HTML lent pénalise mécaniquement les pages SSR surchargées.
Budget de crawl. Sur un site à fort volume de pages dynamiques (catalogue produit, fiches locales), SSG réduit la charge lors du crawl Googlebot. Le bot ne subit pas le temps de réponse serveur et peut explorer plus de pages dans le même budget.
Métadonnées et données structurées. Quelle que soit la méthode choisie, les balises <title>, <meta name="description"> et les blocs JSON-LD doivent être injectés dans le <head> côté serveur — via next/head — et non ajoutés dynamiquement par JavaScript après le chargement. C'est une règle absolue pour que Google les lise à coup sûr.
La règle de décision en pratique
Pour chaque page dynamique, posez-vous ces deux questions :
- Les données changent-elles à chaque visite ou dépendent-elles de l'utilisateur connecté ? →
getServerSideProps. - Les données peuvent-elles être pré-générées ou rafraîchies toutes les N minutes ? →
getStaticPropsavecrevalidate.
En cas de doute, SSG avec une revalidation courte est presque toujours préférable pour le SEO : le bot Google reçoit un HTML complet instantanément, et les données restent récentes. Réservez SSR aux cas où la personnalisation temps réel est fonctionnellement obligatoire.
Si vous travaillez avec le App Router (Next.js 13+), cette distinction évolue : les Server Components rendent côté serveur par défaut, et le cache est géré via fetch avec les options cache et next.revalidate. Les principes SEO restent identiques, seule la syntaxe change.
Pour une stratégie SEO technique complète sur votre site Next.js, consultez notre offre SEO ou explorez comment le GEO et l'optimisation pour les moteurs IA s'appliquent aux architectures modernes.
FAQ
getServerSideProps est-il mauvais pour le SEO ?
Non, il n'est pas mauvais en soi. Google indexe correctement les pages SSR. Le risque vient de la latence : si le serveur répond lentement, le TTFB élevé dégrade le LCP et peut indirectement nuire au classement. Sur un serveur bien dimensionné avec une source de données rapide, SSR fonctionne très bien pour le SEO.
Peut-on mixer SSR et SSG sur le même site ?
Oui, et c'est même recommandé. Next.js permet de choisir la stratégie page par page. Une page d'accueil ou un article de blog → getStaticProps. Un tableau de bord utilisateur → getServerSideProps. Cette granularité est l'un des atouts majeurs du framework pour le SEO à grande échelle.
Le rendu côté client (CSR avec useEffect) est-il acceptable pour le SEO ?
Non, pour les contenus que vous souhaitez indexer. Si le contenu est injecté dans le DOM uniquement après exécution de JavaScript client, Googlebot peut le manquer ou l'indexer avec retard. Réservez le CSR aux données non-indexables (contenu personnalisé, interactions après connexion). Pour tout contenu devant apparaître dans les résultats de recherche, SSR ou SSG est obligatoire.
Vous développez un site ou une application Next.js et souhaitez un audit technique de votre stratégie de rendu ? Contactez Drylead pour un accompagnement sur mesure.
Pour aller plus loin
Vous aussi vous voulez bosser avec nous.
Pas d'engagement long, pas de package premium magique. On regarde votre cas, on dit ce qu'on peut faire, on chiffre. Vous décidez.