Votre application React se charge parfaitement dans le navigateur, les routes fonctionnent, les composants s’affichent en moins d’une seconde. Pourtant, trois semaines après le lancement, la Search Console montre encore 60 % de vos pages en statut « Découverte – actuellement non indexée ». C’est le problème concret que pose le client-side rendering (CSR) face à Googlebot.
La différence entre React pur et Next.js porte sur ce que Googlebot reçoit au premier octet : du HTML complet exploitable ou un shell vide qui attend JavaScript pour se remplir. Cette distinction détermine la vitesse d’indexation, le crawl budget consommé et, depuis 2025, la visibilité auprès des crawlers IA comme GPTBot et ClaudeBot.
Ce guide couvre les stratégies de rendu disponibles dans Next.js (SSR, SSG, ISR), leur impact mesuré sur l’indexation et les cas d’usage où chaque approche s’impose.
Ce que Googlebot fait réellement avec une SPA React
Quand Googlebot atteint une page React en CSR, il reçoit un fichier HTML de quelques lignes : un div#root vide et des balises script. Il ajoute la page à sa file de rendu, repart crawler d’autres URLs et reviendra exécuter le JavaScript plus tard. Ce retour peut prendre des heures sur un domaine à forte autorité, plusieurs jours sur un site jeune.
Onely a mesuré que Googlebot consacre 9 fois plus de temps à crawler une page JavaScript qu’une page HTML statique. Sur un site de 800 pages produit sans SSR, les logs serveur révèlent des retours de Googlebot entre 3 et 9 jours après la première visite, avec des pages soumises en semaine 1 qui n’apparaissent en index qu’en semaine 2 ou 3.
Ce délai s’appelle la « deuxième vague d’indexation ». Googlebot dispose d’un rendering budget fini. Les pages HTML pures passent en priorité. Les pages JavaScript attendent dans la file selon l’autorité du domaine et la disponibilité des ressources de rendu.
« Googlebot utilise un processus d’indexation en deux temps qui diffère l’exécution JavaScript de quelques heures à plusieurs jours, tandis que les crawlers IA comme GPTBot et ClaudeBot ne peuvent pas exécuter JavaScript du tout. » (Discovered Labs, janvier 2026)
Un second problème, moins discuté : une montée en charge CSR peut épuiser le crawl budget avant que les pages importantes soient revisitées. Un e-commerce React avec 5 000 références produit et zéro SSR expose ses nouvelles fiches à des délais d’indexation structurellement plus longs que sa concurrence sur Next.js.
Les modes de rendu Next.js et ce qu’ils envoient à Google
Next.js propose trois stratégies, chacune avec un profil SEO différent. Le choix dépend de la fréquence de mise à jour du contenu et du volume de pages.
| Stratégie | HTML au premier octet | Délai d’indexation | Cas d’usage idéal |
|---|---|---|---|
| CSR (React pur) | Shell vide | 3-14 jours | Apps authentifiées, dashboards |
| SSG (Static Site Generation) | HTML complet pré-généré | Sous 24h | Blog, landing pages, docs |
| SSR (Server-Side Rendering) | HTML complet à chaque requête | Sous 24h | Contenu dynamique : prix, stocks |
| ISR (Incremental Static Regeneration) | HTML complet + revalidation | Sous 24h + fraîcheur contrôlée | Contenu semi-dynamique, SaaS |
SSG génère les pages au moment du build. Googlebot reçoit du HTML pur, identique à ce qu’un utilisateur verrait. Le fichier est servi directement depuis un CDN. Pour les pages dont le contenu change rarement, c’est la bonne option.
SSR génère le HTML à chaque requête côté serveur. Le crawler reçoit un document complet mais le serveur supporte une charge à chaque visite. Adapté aux pages avec des données fraîches : fiches produit avec prix temps réel, pages de résultats filtrées.
ISR combine les deux. La page est générée statiquement au build, puis régénérée en arrière-plan selon un intervalle configuré (revalidate). Un article de blog peut être régénéré toutes les 60 secondes sans rebuild complet. Pour un site SaaS avec 10 000 pages de documentation, ISR réduit le temps de build de 45 minutes à 3 minutes tout en gardant Google heureux.
L’angle que la plupart des guides ignorent : les crawlers IA
Si le problème CSR/SSR se limitait à Googlebot, la migration resterait une optimisation souhaitable mais non urgente. La situation a changé en 2025 avec la généralisation des crawlers IA.
Une recherche publiée sur amicited.com et citée par Discovered Labs en janvier 2026 établit que 69 % des crawlers IA ne peuvent pas exécuter JavaScript. GPTBot, ClaudeBot et PerplexityBot récupèrent les fichiers JS mais ne les exécutent pas. Pour eux, un site React en CSR pur renvoie une page blanche.
Sur la topical authority et le knowledge graph, l’impact est direct. Si ChatGPT, Perplexity ou Claude AI ne peuvent pas lire le contenu de vos pages produit, ils ne vous citeront pas comme source. Avec la montée des AI Overviews dans les SERP, être invisible pour les crawlers IA signifie être absent des réponses générées et du ranking traditionnel.
Cloudflare a mesuré sur son réseau une croissance du trafic PerplexityBot de 157 490 % sur la période mai 2024–mai 2025. Ce crawler lit uniquement le HTML brut. Une migration vers Next.js SSG ou SSR donne accès à cette audience sans travail supplémentaire : le HTML est déjà là.
Si votre app React est derrière authentification et ne vise aucun trafic organique, le CSR reste pertinent. Le problème est strictement lié aux pages publiques indexables.
Configurer Next.js pour maximiser l’indexation
La migration React vers Next.js ne suffit pas si la configuration SEO technique est absente. Points à vérifier dans l’ordre où ils impactent l’indexation.
- Dans Next.js App Router, les Server Components sont rendus côté serveur par défaut. Ajouter
'use client'uniquement aux composants qui ont besoin d’état ou d’événements navigateur. Une page produit sans interactivité ne doit pas être un Client Component. - Les balises
titleetdescriptiondans unuseEffectReact ne sont pas lues par Googlebot lors du premier crawl. AvecgenerateMetadata()dans Next.js, elles sont dans le HTML initial. - Next.js génère un sitemap.xml automatique via
app/sitemap.ts. Sur un site avec ISR, inclure les dates de dernière modification pour signaler les pages à recrawler en priorité. - Un problème fréquent : des pages cachent leur image LCP derrière un attribut
data-srcchargé par JavaScript, invisible au premier crawl. Le composant<Image />avec priorité dans Next.js injecte l’image directement dans le HTML. - Activer les logs de crawl Googlebot côté serveur permet de vérifier si le bot reçoit du HTML complet ou un shell vide. C’est la vérification directe, avant tout outil tiers.
Le piège classique après migration : laisser des pages critiques en 'use client' parce que leur ancien code React avait des hooks. Vérifier avec l’outil « Inspecter l’URL » de la Search Console que le contenu rendu par Googlebot correspond au contenu visible par un utilisateur.
Quand garder React pur sans Next.js
La migration Next.js a un coût réel. Pour un dashboard interne, une application de gestion de projet ou n’importe quelle interface derrière un login, le CSR est la bonne architecture. Google n’indexe pas ces pages. Les performances perçues par l’utilisateur authentifié sont souvent meilleures avec une navigation SPA qu’avec des rechargements SSR.
Le query fanout de Google, qui permet à un même site d’être jugé sur plusieurs signaux de pertinence en parallèle, n’avantage pas les pages SSR sur les pages CSR pour les résultats hors index. La distinction SSR/CSR n’a de valeur SEO que sur les URLs publiques et crawlables.
Pour un projet greenfield avec des pages publiques et des pages privées, l’architecture courante est : Next.js App Router avec Server Components pour les pages publiques, Client Components pour les interfaces utilisateur authentifiées. La frontière s’établit au niveau du layout.
Ce que les données GSC révèlent après migration
Sur les sites qui migrent d’une SPA React vers Next.js SSG ou SSR, les effets mesurables apparaissent dans la Search Console dans un délai de 4 à 8 semaines. Les indicateurs à surveiller :
Pages indexées : le ratio « indexé / découvert » remonte progressivement. Les pages en statut « Découverte – actuellement non indexée » se vident au fur et à mesure que Googlebot trouve du HTML complet à chaque nouvelle visite.
Core Web Vitals : le LCP s’améliore mécaniquement parce que le navigateur n’attend plus l’exécution JavaScript pour afficher le contenu. Les pages SSG servent depuis un CDN en temps constant, indépendamment de la charge serveur.
Couverture d’index : les rapports de crawl montrent une réduction des erreurs liées aux ressources JavaScript (erreurs de parsing, timeouts de rendu). Le volume de pages dans la file de rendu diminue.
Migrer de CSR vers SSR produit une remontée du trafic organique dans les semaines suivant la migration, visible dans les rapports de couverture GSC. À l’inverse, les sites qui reviennent de SSR vers CSR documentent des baisses significatives dans les mêmes délais.
La semantic search et l’entity SEO reposent sur la capacité de Google à lire et interpréter le contenu lors du premier crawl. Un site Next.js bien configuré permet à Google d’extraire les entités et le champ lexical dès la première visite. Un site React CSR force Googlebot à revenir pour exécuter le JavaScript avant d’analyser le contenu. Deux passages là où Next.js n’en demande qu’un.
L’architecture de rendu est une décision d’infrastructure SEO.
