Séparer exploration, rendu et indexation
L’exploration commence par une URL, un statut HTTP et une réponse. Google peut ensuite placer la page dans une file de rendu, exécuter JavaScript et analyser le résultat. Enfin, ses systèmes décident de l’indexer ou non. Une page peut donc être explorée sans que son contenu soit correctement rendu, ou rendue sans être retenue dans l’index. Search Console doit être lue avec cette séquence en tête.
Google décrit explicitement ces trois phases dans sa documentation JavaScript SEO. La conséquence pratique est simple : ne concluez pas qu’un problème vient de React parce qu’une URL n’est pas indexée. Contrôlez d’abord le statut, robots, canonical, qualité de la page, découverte par liens et rendu. Une demande manuelle d’indexation répétée ne corrige aucune de ces causes.
Comprendre CSR, SSR et génération statique sans jargon
En rendu côté client, le serveur peut envoyer une structure minimale puis le navigateur construit la page. En rendu côté serveur, la réponse contient déjà le contenu de la requête. La génération statique produit le HTML à l’avance. Next.js peut combiner plusieurs stratégies selon les routes. Le choix doit suivre la fraîcheur des données, la personnalisation, le cache et l’importance publique de la page.
Une page service stable peut être générée à l’avance. Un catalogue peut combiner HTML initial et mises à jour. Un tableau de bord derrière connexion n’a pas besoin d’être indexable. Il n’existe donc pas une stratégie SEO unique pour toute l’application. La règle utile est de rendre dans la réponse les informations et liens nécessaires à toute page publique destinée à être découverte.
Comparer le HTML reçu et le DOM rendu
Ouvrez le code source ou téléchargez la réponse avec un outil HTTP. Recherchez title, H1, texte principal, canonical, robots et liens. Comparez ensuite avec l’inspecteur du navigateur après exécution. Une différence n’est pas automatiquement une erreur : un menu interactif peut apparaître plus tard. En revanche, si toute la réponse utile manque, la page dépend entièrement du rendu et devient plus fragile pour les robots et outils secondaires.
Vérifiez aussi l’outil d’inspection d’URL de Search Console pour voir la page testée par Google. Le cache, le consentement, une API bloquée ou une erreur uniquement côté robot peuvent produire un rendu différent du vôtre. Conservez la date, l’URL, la capture et le HTML testés. Sans cette preuve, le diagnostic reste une impression locale.
Exposer les liens sous forme crawlable
Google recommande des éléments `<a>` dotés d’un attribut `href` résolvable pour découvrir les pages. Un bouton qui appelle uniquement une fonction JavaScript peut fonctionner pour l’utilisateur tout en ne constituant pas un lien exploitable. Les cartes, menus, paginations et résultats de recherche doivent donc exposer les destinations essentielles dans le HTML, même si une transition côté client améliore ensuite l’expérience.
Testez la navigation au clavier et sans interaction complexe. Les liens doivent avoir un libellé compréhensible, une cible stable et un état de focus. Un sitemap aide à découvrir les URL, mais ne remplace pas un maillage interne. Une page présente uniquement dans le sitemap peut rester orpheline et recevoir peu de signaux sur son rôle dans l’architecture.
Renvoyer des statuts HTTP significatifs
Une application monopage affiche parfois une belle page d’erreur tout en répondant 200. Google peut l’interpréter comme soft 404. Une URL supprimée doit renvoyer 404 ou 410 ; une redirection permanente doit être serveur ; une erreur doit avoir un code cohérent. Le JavaScript ne doit pas masquer le statut que le robot reçoit avant rendu.
Testez directement une URL inexistante, une route privée et une ancienne adresse. Vérifiez aussi les erreurs serveur et les redirections en chaîne. Dans Next.js, la manière de produire ces réponses dépend de la version et de l’architecture ; il faut suivre la documentation présente dans le projet, pas recopier une recette ancienne. Le résultat attendu reste indépendant du framework : un code honnête et une destination claire.
Scénario : une fiche service visible dans le navigateur mais absente de Google
Entrées fictives : `/services/audit` répond 200, le HTML contient seulement `<div id=app>`, le H1 arrive après un appel API et les cartes liées utilisent des `onClick`. Search Console découvre l’URL par sitemap mais le rendu testé montre une API en erreur. Raisonnement : le problème prioritaire n’est ni le nombre de mots ni le sitemap ; le contenu et le maillage dépendent d’une ressource qui échoue pendant le rendu.
Décision : rendre le titre, la réponse principale et les liens côté serveur ou à la génération, conserver l’interactivité pour les éléments secondaires, puis retester statut, HTML, rendu et liens. Résultat attendu : la réponse devient exploitable avant JavaScript et le rendu reste cohérent. Limite : cela améliore l’accessibilité du contenu aux robots, mais ne garantit ni indexation ni position.
Surveiller hydratation, scripts tiers et performance
L’hydratation attache le comportement client au HTML produit par le serveur. Si les deux versions divergent, le navigateur peut remplacer du contenu ou afficher une erreur. Surveillez la console, les avertissements et les changements de texte. Les tests doivent inclure production, car les variables, caches et politiques de sécurité diffèrent du serveur local.
Les scripts analytics, chat ou tests peuvent retarder l’interaction et le contenu. Chargez-les selon leur nécessité et mesurez leur effet. Une bonne indexabilité ne compense pas une page inutilisable. Inversement, réduire tout JavaScript n’est pas un objectif en soi : conservez ce qui aide la tâche, mais ne rendez pas le contenu public dépendant d’un script sans solution robuste.
Choisir la correction minimale avec un arbre de décision
Si le HTML contient le contenu et les liens, cherchez ailleurs : qualité, canonical, duplication, noindex ou demande. Si le contenu manque mais le rendu Google le voit, évaluez la fréquence de mise à jour et les autres robots avant de modifier l’architecture. Si le rendu échoue, corrigez la ressource ou rendez les informations critiques côté serveur. Si seule une interaction révèle les liens, exposez des URL crawlables.
Documentez avant/après avec le même échantillon. Contrôlez page service, article, pagination, 404 et route dynamique. Le diagnostic ne doit pas devenir un prétexte à migrer tout le site. Une correction locale du rendu ou des liens peut suffire. Si plusieurs modèles partagent la même faiblesse, traitez le composant ou la stratégie de rendu partagée, puis relancez une régression complète.
Mise en pratique, sans collecte
Où en êtes-vous sur « SEO JavaScript : React et Next.js empêchent-ils Google d’indexer un site ? » ?
Évaluez cinq critères concrets. Vos réponses restent dans votre navigateur.Votre premier chantier utile : Le statut HTTP est cohérent
Outil pratique à copier
Recette SEO d’une route JavaScript
Testez une URL publique, une URL dynamique, une 404 et une page profonde avec le même protocole.
Checklist
À vérifier avant de passer à l’action.
- Le statut HTTP est cohérent
- Le contenu critique existe dans la réponse ou un rendu fiable
- Les liens utilisent href
- Canonical et robots ne divergent pas
- Les routes profondes et 404 sont testées
- La console et l’hydratation sont propres
Pour aller plus loin
Les réponses aux questions les plus fréquentes.
Des repères concrets pour passer de la lecture à une décision adaptée à votre situation.
Google exécute-t-il JavaScript ?
Oui, Google décrit un processus de rendu avec Chromium. Cela ne dispense pas de vérifier ressources, liens, statuts et cohérence du rendu.
Faut-il migrer React vers Next.js ?
Pas automatiquement. Identifiez la cause route par route. Un pré-rendu, une correction de liens ou une API robuste peut suffire.
Le SSR garantit-il l’indexation ?
Non. Il rend le contenu disponible dans la réponse, mais qualité, duplication, canonical, découverte et décisions de Google restent déterminants.
Comment tester sans outil payant ?
Comparez la réponse HTTP, le code source, le DOM rendu, les liens et l’inspection Search Console. Conservez les preuves et la date du test.
Sources consultées
Pour vérifier et approfondir.
Besoin de l’appliquer à votre site ?