Rendu JavaScript et SEO : ce que Google lit vraiment

J'ai ouvert le code source d'une fiche produit un mardi matin, café encore trop chaud, et j'ai cru à une panne. Titre dans le head, feuille de style, un bloc vide, puis plus rien. Dans le navigateur, la même URL montrait le nom, le prix, les avis et le bouton. Deux HTML pour une seule adresse. Depuis, quand une interface très travaillée plafonne dans les résultats, je lis d'abord la réponse du serveur.

Pourquoi le JavaScript change la page indexée

Le code source et le HTML rendu

Le code source, c'est le fichier que le serveur envoie. Afficher la source de la page le montre tel quel. Le HTML rendu, c'est cette page une fois les scripts exécutés : blocs créés, phrases insérées, liens ajoutés. Le public voit la seconde version. Un audit pressé s'arrête souvent à la première, et c'est là que les conclusions dérapent.

Google exécute les scripts. Je le vois dans l'inspection d'URL, assez régulièrement pour ranger l'idée d'un robot qui ignorerait le JavaScript. L'exécution a des ratés : script en erreur, fichier lourd, ressource qui ne répond pas. Le robot repart alors avec la coquille, celle du premier HTML.

Une page peut donc être superbe chez vous et pauvre pour l'index. Le décalage ne se devine pas au scroll.

Quand le texte arrive après le chargement

Sur cette fiche, le nom du produit était dans la balise title. Description, déclinaisons, avis et liens vers les produits proches vivaient dans le JavaScript. Le title ouvrait une piste. La page, elle, restait maigre.

Les catégories m'ont fait faire une erreur nette. J'avais fait rédiger un paragraphe unique par rubrique, puis je l'avais glissé dans un composant. Le texte n'apparaissait qu'après hydratation. J'ai d'abord relu les canoniques, les titres, le maillage. La cause était plus simple : ce paragraphe n'existait pas dans la première réponse. Les URL restaient au statut « Explorée, actuellement non indexée ».

Dès que le paragraphe a été écrit par le serveur, le modèle de page a cessé de tourner dans ce rapport. Pas de refonte. Un déplacement de contenu.

Quatre modes de rendu à connaître

SSR, CSR, prérendu et pages statiques

Le rendu côté serveur écrit le HTML avant l'envoi. Le texte principal, les liens internes et les données stables partent dans cette réponse, sans attendre le navigateur. Je le garde pour les fiches, les catégories, les guides et les pages marques.

Le rendu côté client envoie une coquille et des scripts. Le navigateur construit l'écran ensuite. Je le réserve au compte client, au tunnel de paiement, aux outils internes et aux écrans qui portent un noindex.

Le prérendu fait jouer la page par un service et met le HTML en cache. Je l'ai utilisé comme pont sur un catalogue déjà en ligne, le temps qu'une vraie réponse serveur soit prête. La copie vieillit : un texte modifié dans l'admin peut rester l'ancien pendant toute la vie du cache.

La génération statique fabrique les fichiers au build. Le robot lit un HTML complet, sans attendre de script. Elle va aux pages qui bougent peu. Quand les données changent plusieurs fois dans la journée, ces URL-là passent par un rendu à la requête.

Le tableau que je garde sous le coude

Mode	Qui produit le HTML	Premier document reçu	Point de vigilance
Rendu serveur	Le serveur, à chaque requête	Le contenu principal déjà écrit	Charge, et pages trop liées à une session
Rendu client	Le navigateur	Une coquille plus des scripts	Texte absent si le script casse
Prérendu	Un service qui joue la page	Une copie HTML	Copie en retard sur la page réelle
Génération statique	L'étape de build	Un fichier prêt à être lu	Build trop rare face à des données vivantes

Le même site peut combiner ces modes. Accueil et guides en statique, fiches en rendu serveur, espace connecté en rendu client avec noindex, recherche interne hors sitemap. Un seul mode imposé à toutes les URL alourdit le chantier, avec peu de bénéfice.

Vérifier ce que Google reçoit

La méthode en cinq temps

1. Dans le code source, chercher une phrase, un prix ou un lien que vous tenez pour utile. S'il manque, noter le modèle de page.
2. Dans le navigateur, ouvrir l'inspecteur et confirmer que cette phrase apparaît bien une fois la page construite.
3. Dans la Search Console, lancer l'inspection d'URL et comparer le HTML rendu au DOM que vous venez de voir.
4. Regarder la capture associée. Un écran blanc ou un message de chargement figé appelle une seconde lecture du HTML.
5. Répéter sur une autre URL du même modèle, puis sur un modèle différent. Les fiches peuvent être saines pendant que les catégories sont vides.

Ce parcours m'a déjà évité de réécrire un template qui envoyait le bon HTML. Le problème était deux rubriques plus loin.

Les signes d'un rendu incomplet

• Le source affiche un H1 du type « Chargement », ou un H1 différent de celui vu à l'écran.
• Les liens vers les fiches filles sont absents du source et présents seulement après exécution.
• Le HTML de l'inspection d'URL est beaucoup plus court que la page affichée chez vous.
• Le rapport d'indexation parle d'URL explorées non indexées, et le texte unique est introuvable dans la réponse initiale.

Un signe isolé appelle une vérification. Trois signes sur le même modèle appellent une correction du modèle, pas un bricolage sur l'URL qui a servi d'exemple.

Les erreurs qui reviennent sur les sites JS

Des liens qui n'existent qu'après un clic

Le robot suit des URL écrites dans le HTML. Un bouton qui déclenche une fonction, un bloc cliquable, une liste qui s'allonge seulement au scroll : la personne devant l'écran s'en sort. Le parcours automatique, beaucoup moins.

J'ai validé un menu en le promenant à la souris. Chaque entrée s'ouvrait, l'animation était propre. Dans le source, seuls les liens de premier niveau existaient. Les rubriques profondes n'avaient presque aucun chemin. On a posé de vrais a href, gardé l'effet au survol, et ces rubriques ont enfin eu des routes lisibles.

Le scroll infini demande la même discipline. Une URL par portion de liste, plus un lien HTML vers la portion suivante, donne un chemin stable. La pagination peut rester discrète sous les produits. Elle fait le travail que le scroll laisse au hasard.

Un contenu lié à l'écran ou à un cookie

Une description qui n'apparaît qu'après un clic sur le bandeau, ou seulement sur un grand écran, reste fragile. Le robot n'utilise pas votre largeur de fenêtre, et il ne valide pas le bandeau à votre place.

Le H1, le paragraphe distinctif, les liens de parcours et les données produit stables partent dans la réponse initiale. Le chat, la carte, la galerie enrichie et les avis chargés plus tard peuvent arriver avec le script.

Même réflexe pour les variantes. Une version qui vit seulement dans la mémoire du script entre en conflit avec la canonique. Chaque version utile reçoit une adresse, un HTML qui la décrit, et une canonique alignée sur cette adresse.

Corriger sans réécrire toute l'application

Par où je commence

Je trie les modèles par enjeu : fiches qui portent la demande, catégories qui distribuent le maillage, guides déjà écrits et pourtant absents, pages marques qui répètent la même coquille. Le compte client et le paiement restent de côté.

Sur le modèle retenu, le contenu critique quitte le JavaScript. Le serveur écrit le H1, l'introduction, le texte unique, les liens vers les pages sœurs et les données stables. Le script reprend la main pour l'interface, sans effacer ce HTML au démarrage. J'ai vu une hydratation remplacer un source correct par un conteneur vide le temps d'un instant. Selon le moment du rendu, le robot tombait sur l'une ou l'autre version.

Les pages sans intérêt pour l'index reçoivent un noindex, dans la balise meta robots ou dans l'en-tête HTTP, et elles sortent du sitemap. Les laisser bloquées en parallèle dans le robots.txt complique la prise en compte de ce noindex : encore faut-il pouvoir consulter l'URL.

Ce qui peut rester dans le navigateur

Le configurateur, le calcul des frais de port, les suggestions internes et la galerie au doigt vivent très bien en JavaScript. La visite y gagne. L'index comprend la page sans eux.

La frontière tient en un essai. Couper les scripts doit laisser une page compréhensible, avec son sujet et ses liens. Un écran blanc veut dire que l'indexation repose sur une exécution incertaine.

Quand le rendu serveur représente un chantier long, le prérendu sert de relais. Cache court sur les modèles qui bougent, contrôle d'un échantillon d'URL, retrait du service le jour où le serveur écrit lui-même le HTML.

Le réflexe que je ne lâche plus

Avant de toucher une title ou d'épaissir un texte, j'affiche la source. Si la phrase que je veux voir indexée n'y figure pas, le reste attend. Sur les catégories dont je parlais, cette vérification a suffi : le paragraphe est passé côté serveur, et ces URL ont quitté la zone grise du rapport d'indexation.

Le JavaScript anime, filtre, calcule. Le HTML porte le propos. Une page déjà lisible dans la réponse du serveur se défend mieux qu'une coquille brillante. Trente secondes sur « afficher la source » montrent souvent de quel côté vous êtes.

Questions fréquentes

Google exécute-t-il le JavaScript des pages ?

Oui, dans une large part des cas. L'exécution peut échouer ou produire un HTML plus pauvre que celui de votre navigateur. L'inspection d'URL, sur vos principaux modèles, vaut mieux qu'une supposition.

Un site rendu seulement côté client peut-il être indexé ?

Cela arrive sur des pages légères, avec des scripts stables. Pour un catalogue, ou pour un texte injecté après coup, le HTML initial doit déjà contenir ce qui est destiné à l'index.

Le prérendu remplace-t-il un rendu serveur ?

Il dépanne une application déjà livrée. Il ajoute une copie à surveiller, avec un écart possible entre cette copie et la page du moment. Un rendu serveur, ou des pages statiques régénérées, se tient plus simplement sur la durée.

L'inspection d'URL suffit-elle à obtenir l'indexation ?

Elle montre le rendu au moment du test. La place dans l'index dépend aussi du contenu, de la canonique, du maillage, du statut HTTP et des consignes d'indexation. Un HTML complet pose la base. La suite se joue sur le reste de la page.