Sur un grand site, le seo react se joue d’abord dans le HTML reçu par le robot. Une page React peut sembler complète à l’écran et rester vide pour lui.
Cet article aide à choisir le rendu, puis à vérifier ce que Google indexe.
Choisir le rendu selon la fréquence de mise à jour et le volume
Le rendu adapté à chaque type de page
Le rendu côté client (CSR) livre une structure HTML minimale, puis construit la page dans le navigateur. Il convient aux espaces privés, aux tableaux de bord et aux interfaces personnalisées. Il ajoute cependant une étape entre la réponse HTTP et l’apparition du contenu exploitable.
Le rendu côté serveur (SSR) produit le HTML à chaque requête. Il s’impose pour les pages publiques dont les données changent souvent : fiches produit, contenus éditoriaux récents, pages dépendantes d’une information actualisée.
La génération statique (SSG) fabrique les fichiers HTML avant leur diffusion. Elle reste pertinente pour les contenus stables, les pages institutionnelles et les milliers de pages dont les données évoluent peu.
La génération incrémentale (ISR) combine génération statique et régénération différée. Le serveur sert une version mise en cache, puis reconstruit une page après un délai ou lors d’un changement de donnée, sans reconstruire l’ensemble du site.
Trois critères de décision
Le choix repose sur trois critères mesurables :
- Fréquence de mise à jour : le SSR répond à chaque requête, tandis que la génération statique exige une reconstruction ou une revalidation.
- Volume de pages : une reconstruction globale devient coûteuse au-delà de plusieurs centaines de milliers d’URL, surtout lorsque chaque page interroge plusieurs sources de données.
- Valeur SEO de la page : un contenu public et stratégique doit produire un HTML exploitable dès la première réponse, alors qu’une interface privée peut rester en CSR.
Les cas particuliers
Une page publique à données variables doit conserver une réponse HTML complète, même si React ajoute ensuite les interactions. Le navigateur peut hydrater ce HTML avec hydrateRoot, à condition que l’arbre React produise le même résultat côté serveur et côté client.
Sur un grand site, la règle opérationnelle se résume ainsi :
- Contenu rarement modifié : génération statique ;
- Contenu régulièrement actualisé : ISR ou cache HTML avec invalidation ciblée ;
- Contenu fréquemment modifié : SSR avec cache court ou invalidation événementielle ;
- Contenu privé et personnalisé : CSR, avec un contrôle explicite de l’indexation.
Comment Google explore et indexe une page React
Les étapes du traitement
Lors de l’exploration, Googlebot lit d’abord les règles de robots.txt. Il récupère ensuite le document autorisé, puis recherche des URL dans les attributs href des liens HTML. Cette première réponse transmet donc des URL avant même l’exécution de React.
Les pages qui répondent avec un statut 200 entrent dans la file de rendu. Une directive noindex, placée dans les métadonnées ou les en-têtes, l’en empêche. La présence de JavaScript n’est pas nécessaire pour qu’une page soit envoyée au rendu.
Éligibilité et statuts HTTP
Le statut HTTP oriente le traitement :
- 200 : la page peut être rendue et indexée si son contenu et ses directives l’autorisent
- 301 ou 308 : l’URL signale un déplacement permanent vers une autre adresse
- 404 ou 410 : la ressource est absente et ne doit pas être traitée comme une page valide
- 401 ou 403 : l’accès est protégé ou interdit
- 5xx : le serveur rencontre une erreur temporaire ou persistante
Une application monopage renvoie parfois 200 pour une route inexistante, puis affiche un composant d’erreur côté client. C’est une soft 404 : une page inexistante traitée comme une page valide. Le serveur doit renvoyer 404, ou la page d’erreur doit recevoir noindex.
Googlebot doit aussi charger les scripts, les feuilles de style et les appels nécessaires au rendu. Une ressource essentielle bloquée par robots.txt, protégée par authentification ou interrompue par une erreur réseau réduit la version analysée.
Avant de valider le rendu
- Scripts, feuilles de style et appels nécessaires au rendu accessibles, sans blocage par robots.txt
- Aucune ressource essentielle derrière une authentification
- Aucune erreur réseau interrompant le chargement des ressources du rendu
- Routes inexistantes renvoyant 404, ou page d’erreur marquée noindex
Les contrôles techniques à prioriser
Valider le rendu et l’indexabilité
Le premier contrôle porte sur le contenu principal dans le HTML rendu : titre, texte, produits, liens internes, images et données utiles. Une page correcte dans le navigateur mais vide dans le DOM rendu ne peut pas être indexée correctement.
Les causes les plus fréquentes d’absence de contenu sont :
- des données récupérées uniquement après un clic ou un défilement
- un appel d’API bloqué, lent ou dépendant d’une session
- une exception JavaScript qui interrompt l’arbre React
- un contenu injecté après une condition que le robot ne satisfait pas
- un écart entre l’état serveur et l’état client, provoquant une erreur d’hydratation
Le deuxième contrôle porte sur le statut HTTP. Une page éditoriale publiée répond en 200. Une page supprimée sans remplacement répond en 404 ou 410, une redirection permanente en 301 ou 308. Une page privée doit rester protégée de façon cohérente.
Le troisième contrôle concerne les directives. Le noindex doit figurer dans le HTML ou dans l’en-tête X-Robots-Tag pour les ressources non HTML. Une URL bloquée par robots.txt empêche Google de lire son noindex.
Organiser les tests
Il convient d’échantillonner les gabarits plutôt que de tester la seule page d’accueil. Sur un grand site, l’échantillon minimal comprend une page d’accueil, une page de catégorie, une fiche détaillée, une page éditoriale, une page paginée, une page d’erreur et une route à paramètres.
La comparaison doit distinguer le HTML initial de la réponse HTTP du DOM rendu après exécution. Le premier montre les contenus disponibles immédiatement. Le second montre ce que Google peut analyser après rendu.
Le contrôle doit enfin comparer les métadonnées initiales et rendues : titre, description, canonique, directives robots, liens alternatifs et données structurées. Une valeur correcte dans le navigateur ne suffit pas si une valeur contradictoire apparaît pendant le rendu.
Contrôles à prioriser avant de conclure
- Vérifier que le contenu principal figure dans le DOM rendu de chaque gabarit
- Contrôler le code HTTP de chaque gabarit : 200, 404 ou 410, 301 ou 308
- Confirmer que le noindex figure dans le HTML ou dans l’en-tête X-Robots-Tag
- Vérifier qu’aucune URL porteuse d’un noindex n’est bloquée par robots.txt
- Comparer titre, description, canonique, directives robots et données structurées, initiaux et rendus
La navigation doit fonctionner sans clic simulé
Rendre les contenus découvrables
Google explore de manière fiable les éléments . Un span, un bouton relié uniquement à onclick, un élément sans href ou une URL placée dans un script ne constituent pas une base équivalente.
React peut insérer des liens après le rendu, à condition de produire un élément HTML standard avec une URL résolvable. Le gestionnaire de navigation peut rester attaché au lien, sans remplacer l’attribut href.
- Chaque lien est un élément a avec un attribut href résolvable
- Le gestionnaire de navigation reste attaché au lien sans remplacer href
- Chaque contenu indexable possède une URL stable et unique
- La route restitue le même contenu au rechargement, au partage et à la visite directe
- Les changements de vue passent par l’History API, et non par un fragment après #
- Le serveur répond directement aux routes côté client, sans erreur ni page générique
Chaque contenu indexable doit avoir une URL stable et unique. La route doit afficher le même contenu au rechargement, au partage, à la visite directe et à l’exploration sans historique.
Les applications monopages doivent utiliser l’History API pour modifier l’adresse lors d’un changement de vue.
Les fragments placés après # ne doivent pas représenter des pages différentes. Google peut les ignorer lors de la découverte et de l’indexation.
Les routes côté client doivent être servies directement par le serveur. Une visite directe de /produits/chaussures ne doit pas renvoyer d’erreur ni de page générique avant l’exécution de React.
Traiter les listes et le défilement
Le défilement infini peut améliorer le chargement initial. Google ne simule pas de manière fiable les actions nécessaires à l’apparition de nouveaux éléments. Une liste longue doit donc proposer des URL paginées accessibles par des liens HTML.
Chaque page d’une séquence doit avoir sa propre URL, par exemple ?page=2. Son contenu doit rester identique pour une même adresse.
La navigation doit relier les pages successives par des éléments : la page 1 pointe vers la page 2, la page 2 vers la page 3. Un bouton qui exécute seulement une fonction JavaScript ne suffit pas.
Une page paginée doit garder sa propre canonique si son contenu a une valeur autonome. La page 2 ne doit pas désigner la page 1 par défaut, sinon les éléments situés plus loin dans la liste perdent en visibilité.
Métadonnées et URL canoniques dans React
Des métadonnées propres à chaque page
Les titres doivent distinguer les pages d’une même famille par un élément réellement variable : nom du produit, catégorie, sujet éditorial ou localisation. Un nom de marque répété sur des milliers de pages réduit la capacité des moteurs à saisir le sujet de chacune.
Avec une API de métadonnées côté serveur, ces informations peuvent être fixées statiquement. Elles peuvent aussi être générées à partir des paramètres de route et de données externes.
Canoniques et vérification
La balise rel= »canonical » doit identifier l’URL principale d’un contenu lorsque plusieurs variantes sont accessibles. Elle doit utiliser une adresse absolue, stable, indexable et cohérente avec les liens internes et le plan de site.
La canonique présente dans le HTML initial et celle produite après rendu doivent pointer vers la même adresse. Une canonique modifiée par JavaScript vers une autre valeur crée un signal contradictoire.
La vérification doit comparer trois valeurs : la canonique déclarée par la page, celle visible dans le HTML rendu, et celle retenue par Google. Cette dernière peut différer, car Google évalue aussi les doublons, les liens internes et la qualité de la page.
Trois canoniques à comparer
- Relever la canonique présente dans le HTML initial, sans exécution de JavaScript
- Relever la canonique du HTML rendu, après exécution du JavaScript
- Vérifier que les deux valeurs pointent vers la même adresse absolue
- Relever l’URL canonique retenue par Google dans l’outil d’inspection d’URL
- Comparer cette URL retenue aux liens internes et au plan de site
Core Web Vitals : des seuils utiles, pas une promesse de classement
Interpréter les indicateurs
Les seuils « bons » s’évaluent au 75e percentile des expériences observées :
- LCP : inférieur ou égal à 2,5 secondes, pour le temps d’affichage de l’élément principal
- INP : inférieur ou égal à 200 millisecondes, pour la réactivité après interaction
- CLS : inférieur ou égal à 0,1, pour limiter les déplacements inattendus de la mise en page
| Indicateur | Ce qu’il mesure | Seuil à viser | Délai de lecture |
|---|---|---|---|
| LCP | Affichage de l’élément principal | ≤ 2,5 s | Données de terrain agrégées sur environ 28 jours |
| INP | Réactivité après les interactions | ≤ 200 ms | Données de terrain agrégées sur environ 28 jours |
| CLS | Stabilité de la mise en page | ≤ 0,1 | Données de terrain agrégées sur environ 28 jours |
Prioriser les optimisations
Dans une application React, le LCP dépend de quatre éléments : le HTML initial, le temps de réponse serveur, le chargement du composant principal et de l’image dominante. Les scripts qui retardent l’affichage pèsent aussi sur ce délai.
Réduire le JavaScript sans accélérer la réponse HTML laisse souvent le problème principal intact.
L’INP se dégrade dans trois cas :
- L’hydratation monopolise le fil principal.
- Un composant exécute un volume excessif de JavaScript.
- Un gestionnaire d’événement déclenche un traitement long.
Il faut découper les tâches. Chargez ensuite les interactions secondaires après le contenu prioritaire.
Avant de modifier le code
- Temps de réponse serveur du HTML initial, mesuré avant tout découpage de bundle
- Durée de la tâche la plus longue déclenchée par chaque interaction principale
- Dimensions réservées pour chaque image, publicité, police et module distant
Le CLS augmente quand une image, une publicité, une police ou un module distant apparaît sans espace réservé. Réservez les dimensions des images et les emplacements des contenus distants. Une stratégie de chargement stable limite les déplacements visibles.
Trois leviers reviennent le plus souvent :
- Afficher rapidement le contenu principal et l’image LCP
- Réduire les scripts nécessaires à l’hydratation initiale
- Différer les composants secondaires et les fonctionnalités peu utilisées
Données structurées : utiles si elles décrivent le contenu visible
Choisir et implémenter le balisage
Les données structurées donnent à Google des indications explicites sur le type de contenu : fil d’Ariane, produit, article, événement, recette, cours ou profil. Selon la page, elles rendent parfois une présentation enrichie possible. Elles ne garantissent jamais son affichage.
Le type choisi doit correspondre au contenu visible. Une fiche produit affiche les informations décrites dans son balisage. Un fil d’Ariane reflète la hiérarchie présentée aux utilisateurs.
Les propriétés obligatoires conditionnent l’éligibilité au résultat enrichi. Les propriétés recommandées améliorent la précision. Ne les fabriquez pas pour compléter un schéma incomplet.
React peut générer un bloc JSON-LD dans un élément . Ce bloc doit reprendre les données de la page courante et rester présent dans le HTML rendu destiné aux robots.
Évitez de publier un balisage générique identique sur toutes les routes. Le nom, l’URL, l’image, le prix, l’auteur ou la date doivent correspondre à l’objet affiché sur chaque page.
Avant de publier un balisage
- Vérifier que le type JSON-LD correspond au gabarit réellement affiché.
- Contrôler que le nom, l’URL, l’image, le prix, l’auteur et la date correspondent à l’objet de la page.
- Confirmer que le bloc figure dans le HTML rendu transmis aux robots.
- Tester au moins une page de chaque gabarit avant de généraliser.
Contrôler les résultats enrichis
Le test des résultats enrichis vérifie l’éligibilité d’une URL et signale les erreurs critiques. Testez plusieurs pages de chaque gabarit. Une donnée absente ou mal typée peut toucher une famille entière d’URL.
L’outil d’inspection d’URL montre la page rendue, les ressources chargées et les données structurées telles que Google les voit.
Mesurer le résultat et suivre les délais
Outils et indicateurs
L’inspection d’URL présente deux états à distinguer. La version indexée correspond au dernier traitement connu. Le test en direct analyse la version actuellement accessible.
Une correction récente peut donc apparaître dans le test. Elle n’est pas encore visible dans l’index.
| Indicateur | Ce qu’il mesure | Où le trouver | Délai de réaction |
|---|---|---|---|
| Statut d’indexation | Présence de l’URL dans l’index | Inspection d’URL et rapport d’indexation | Après une nouvelle exploration et un nouveau traitement |
| Canonique retenue | URL considérée comme principale | Inspection d’URL | Après comparaison avec les doublons et les signaux du site |
| Contenu rendu | HTML produit après exécution de React | Inspection d’URL et test des résultats enrichis | À la prochaine phase de rendu |
| Impressions et clics | Visibilité et trafic issus de la recherche | Rapport de performances | Après réindexation et collecte de données |
| Core Web Vitals | Expérience réelle par groupe d’URL | Rapport Core Web Vitals | Environ 28 jours de données glissantes |
| Données structurées | Éligibilité aux résultats enrichis | Test des résultats enrichis et rapports dédiés | Après exploration et traitement de la page |
Interpréter et prioriser
Le diagnostic d’une page non indexée suit un ordre strict :
- Vérifier l’accès et le statut HTTP
- Contrôler les directives robots.txt et noindex
- Examiner le contenu rendu
- Comparer la canonique
- Évaluer la qualité de la découverte interne
Une page explorée mais non indexée ne justifie pas une suite de demandes d’indexation. Il faut d’abord vérifier si Google a retenu une autre canonique. Il faut aussi contrôler que le contenu rendu est complet et que le gabarit ne produit pas une page pauvre ou dupliquée.
Après une correction, une demande d’indexation place l’URL dans une file de traitement. Elle ne force ni l’exploration immédiate ni l’indexation. La mise à jour peut prendre plusieurs jours. Sur un grand site, ou après une modification touchant de nombreuses URL, le délai peut être plus long.
Avant d’attribuer une évolution à une modification
- Comparer le HTML initial et le DOM rendu
- Vérifier le statut HTTP et la canonique
- Contrôler les directives robots.txt, noindex et les rapports d’indexation
- Suivre un échantillon représentatif de chaque gabarit avant de conclure
Pour les corrections massives, le suivi doit porter sur un échantillon représentatif de chaque gabarit. Comparez le HTML initial, le DOM rendu, le statut HTTP et la canonique. Vérifiez aussi les directives et les rapports d’indexation. Ce n’est qu’ensuite que vous attribuez une évolution à une modification précise.
Sources
Le choix du rendu et les contrôles qui le valident ne relèvent pas d’un réglage ponctuel. Ils doivent se traduire dans le processus de mise en production de chaque gabarit. Il convient donc d’attribuer à chaque famille de pages un mode de rendu selon sa fréquence de mise à jour, son volume et sa valeur SEO, puis de vérifier, sur un échantillon représentatif, que le HTML initial, le DOM rendu, le statut HTTP, la canonique et les directives concordent. Une correction ne doit être jugée qu’à partir de ces comparaisons, jamais d’une demande d’indexation répétée.