Les modes de rendu en bref
| Mode | Fonctionnement | Avantages | Limites SEO / technique |
|---|---|---|---|
| SSR (rendu côté serveur) | La page est générée à chaque requête | Contenu toujours à jour | Coût serveur plus élevé, temps de réponse variable |
| SSG (génération statique) | La page est produite au déploiement | Très rapide et fiable, idéale pour les contenus stables | Reconstruction nécessaire pour mettre à jour |
| ISR (régénération incrémentale) | Pages statiques régénérées à intervalle ou à la demande | Bon compromis pour les catalogues volumineux | Pas pris en charge en export statique ; cache à surveiller en multi-instances |
| CSR (rendu côté client) | Le contenu apparaît après l’exécution de JavaScript | Interactivité | À éviter pour les contenus à indexer |
- SSR : la page est générée à chaque requête. Contenu toujours à jour, mais coût serveur plus élevé.
- SSG : la page est produite au déploiement. Très rapide et fiable, adaptée aux contenus stables.
- ISR : pages statiques régénérées à intervalles ou à la demande. Un bon compromis pour les catalogues.
- CSR : le contenu apparaît après l’exécution de JavaScript. À éviter pour les contenus qui doivent être indexés.
Ma recommandation
Pour tout contenu à positionner (pages catégories, fiches, articles), privilégiez SSG ou ISR, et SSR lorsque la donnée change très souvent. Réservez le rendu côté client aux zones sans enjeu SEO, comme un compte utilisateur. Le choix du rendu fait partie du SEO technique et GEO technique à cadrer dès la conception.
| Type de page | Rendu conseillé | Raison |
|---|---|---|
| Page d’accueil, pages institutionnelles | SSG | Contenu stable, performance maximale |
| Catégories et fiches produits d’un catalogue | ISR | Régénération à la demande après mise à jour de prix ou de stock |
| Articles de blog | SSG ou ISR | Contenu stable avec mises à jour ponctuelles |
| Pages avec données très changeantes (stock en temps réel) | SSR | Fraîcheur prioritaire |
| Espace client, panier, tableau de bord | CSR | Aucun enjeu d’indexation |
Comment Google traite le JavaScript
Google indique que Googlebot met en file d’attente toutes les pages en statut 200 pour le rendu, et qu’un Chromium headless exécute le JavaScript dès que ses ressources le permettent. Les pages bloquées par le robots.txt ne sont pas rendues. Google rappelle aussi que le rendu côté serveur ou le pré-rendu reste recommandé, car il accélère le site pour les utilisateurs comme pour les robots, et que tous les robots n’exécutent pas le JavaScript : c’est un point clé pour la visibilité dans les assistants IA. Pour les agents d’IA qui lisent peu de JavaScript, voir aussi agents IA et site web.
Les pièges fréquents
- Liens construits en JavaScript sans véritable balise a href : Google ne découvre les liens que s’ils sont des éléments a avec un attribut href.
- Métadonnées (title, description, canonical) absentes du HTML initial.
- Pages inexistantes qui renvoient un statut 200 au lieu de 404 (soft 404).
- Sitemap et redirections oubliés lors de la mise en production.
- Balise noindex modifiée en JavaScript : Google peut sauter le rendu quand il rencontre un noindex.
La vérification est simple : affichez le code source de la page et inspectez l’URL dans la Search Console. Ce que vous y lisez est ce que Google voit. Pour aller plus loin, voyez notre accompagnement SEO JavaScript et headless. C’est le quotidien d’un consultant SEO Freelance seo de bout en bout, de l’audit à la mise en œuvre.
Votre site Next.js se positionne mal ?
Je compare le HTML brut et rendu, vérifie les statuts, les liens et les métadonnées, puis je rédige les demandes précises pour vos développeurs.
Demander un audit techniqueComment vérifier ce que Google voit
- Affichez le code source de la page (et non l’inspecteur du navigateur) : le contenu principal et les balises doivent y figurer.
- Utilisez l’outil d’inspection d’URL de la Search Console pour consulter le rendu tel que Google le restitue.
- Désactivez JavaScript dans le navigateur : si la page devient vide, une partie du contenu dépend du rendu côté client.
- Crawlez le site avec un outil capable de comparer HTML brut et HTML rendu.
Ces contrôles prennent quelques minutes et révèlent la grande majorité des problèmes de rendu.
Les points d’attention propres à Next.js
| Sujet | Bonne pratique Next.js | Risque si négligé |
|---|---|---|
| Métadonnées | Définir title, description et canonical au niveau de chaque route (generateMetadata) | Balises identiques sur toutes les pages |
| Pages introuvables | Utiliser notFound() pour renvoyer un vrai 404 | Soft 404 en statut 200 |
| Redirections | Les déclarer dans la configuration (redirects) plutôt que côté navigateur | Redirections JavaScript non fiables pour les robots |
| Sitemaps | Les générer dynamiquement à partir du catalogue | Pages absentes ou obsolètes dans le sitemap |
| Cache ISR | Surveiller la revalidation (revalidate, revalidatePath, revalidateTag) et le cache en multi-instances | Prix ou stock périmés affichés |
Enfin, surveillez les temps de génération des pages ISR et la cohérence du cache : une page régénérée avec retard peut afficher des informations de prix ou de stock périmées, ce qui nuit autant à l’utilisateur qu’au référencement. La documentation Next.js précise qu’avec plusieurs instances, le cache par défaut est propre à chaque instance et que la revalidation à la demande n’invalide que celle qui reçoit l’appel : un cache partagé est nécessaire.
Sur des sujets voisins : améliorer LCP, INP et CLS et migration de site.
Checklist de recette SEO d’un site Next.js
- Le HTML initial (code source) contient le titre, la description, le canonical, le H1 et le contenu principal.
- Les liens internes sont de vraies balises a avec un attribut href.
- Les pages inexistantes renvoient un statut 404 et non un 200 avec un message d’erreur.
- Les redirections sont déclarées dans la configuration et testées (301/308, pas de chaîne).
- Le sitemap est généré dynamiquement et ne contient que des URL indexables en statut 200.
- Les métadonnées sont définies par route (generateMetadata) et uniques.
- Le cache ISR est configuré (durée de revalidation, revalidation à la demande après mise à jour) et testé en production.
- Le robots.txt et les balises meta robots ne bloquent pas les gabarits à indexer.
- Les Core Web Vitals sont mesurés sur les données de terrain après la mise en ligne.
Pourquoi me confier le SEO de votre site Next.js ?
Entre développeurs et SEO, tout se joue dans la précision des demandes. Voici ce que j’apporte :
| Ce que vous obtenez | Concrètement |
|---|---|
| Un diagnostic HTML brut / rendu | Je repère ce que Google reçoit réellement, page par page et gabarit par gabarit |
| Des tickets exploitables | Chaque correction est décrite avec un exemple de code, un critère de validation et une priorité |
| Un dialogue avec vos développeurs | J’ai dirigé des équipes de développement : je parle leur langage |
| Une vision performance et GEO | Rendu, Core Web Vitals et accès des robots IA traités ensemble |
| Un accompagnement avant le lancement | Cahier des charges SEO dès la conception, recette avant mise en production |
- Un échange de 30 minutes, gratuit et sans engagement, pour cadrer votre contexte et vos objectifs.
- Un expert senior qui reste sur le dossier : vingt ans de SEO depuis 2005, côté agence comme côté annonceur, dont +50 M€ de chiffre d’affaires SEO généré chez LDLC.
- Une réponse écrite et chiffrée : priorités classées par impact sur votre chiffre d’affaires, pas une checklist générique.
- Une confidentialité totale : je peux intervenir en complément de votre agence ou de votre équipe, sans que vous ayez à résilier quoi que ce soit.
Parlons de votre projet
Décrivez-moi votre site et votre objectif : je reviens vers vous avec une première analyse et la façon la plus simple de travailler ensemble, en tant que consultant SEO indépendant.
Contacter Laurent BousquetQuestions fréquentes
Quel mode de rendu choisir pour le SEO avec Next.js ?
SSG ou ISR pour les contenus à positionner, SSR quand les données changent très souvent, CSR uniquement pour les zones sans enjeu d’indexation.
Google indexe-t-il le contenu rendu en JavaScript ?
Oui, Googlebot exécute le JavaScript avec un Chromium headless, mais en différé via une file de rendu. Google recommande malgré tout le rendu côté serveur ou le pré-rendu, notamment parce que tous les robots n’exécutent pas le JavaScript.
Qu’est-ce que l’ISR ?
La régénération statique incrémentale met à jour des pages statiques à intervalle ou à la demande, sans reconstruire tout le site. Elle n’est pas prise en charge avec un export statique.
Comment renvoyer un vrai 404 en Next.js ?
Avec la fonction notFound(), qui renvoie la page d’erreur avec un statut 404, plutôt qu’une page vide en statut 200.
Comment vérifier ce que Google voit ?
Affichez le code source, utilisez l’inspection d’URL de la Search Console, désactivez JavaScript et comparez HTML brut et rendu avec un crawler.
Les liens en JavaScript sont-ils suivis ?
Seulement s’il s’agit de balises a avec un attribut href. Les liens déclenchés par des gestionnaires de clic sans href ne sont pas découverts.
À retenir
- SSG ou ISR pour tout contenu à positionner ; SSR si les données changent très souvent ; CSR pour les zones sans enjeu SEO.
- Le HTML initial doit contenir le contenu principal, les liens a href et les métadonnées.
- Renvoyez de vrais 404 avec notFound() et déclarez les redirections dans la configuration.
- Surveillez le cache ISR, surtout en multi-instances.
- Vérifiez toujours ce que Google voit : code source, inspection d’URL, rendu.
Un projet sur ce sujet ?
Échangeons 30 minutes sur votre site et vos objectifs, ou découvrez les missions associées :
Demander un audit