Comparez le code source initial et le DOM rendu d’une même URL de fiche produit. Si le nom, le prix, la disponibilité, les liens ou les meta n’apparaissent qu’après exécution JavaScript, ils dépendent du rendu. Googlebot crawle puis rend les pages, mais les ressources non essentielles peuvent ne pas être récupérées. Documentez chaque écart, puis choisissez : rendre le contenu côté serveur, le pré-rendre ou accepter le risque.
Pourquoi le HTML initial et le DOM rendu divergent-ils ?
Google Search traite une page en trois phases : crawling, rendering, indexing. Googlebot récupère d’abord la réponse HTTP, lit le robots.txt, puis parse les liens href pour alimenter la file d’exploration. Ensuite, il peut exécuter le JavaScript avec une version Chromium maintenue à jour. Le rendu exécute le JavaScript et produit un DOM rendu ; Googlebot exploite le contenu présent dans ce DOM rendu. (Official source)
Deux modèles coexistent. Un site rendu côté serveur place tout le contenu dans la réponse HTTP. Un site en « app shell » renvoie une coquille vide et laisse JavaScript construire la fiche. Dans ce second cas, le contenu n’existe pas au moment du crawl initial ; il faut attendre le rendu. Googlebot met en file les pages en 200 pour rendu, sauf indication contraire via une balise ou un en-tête robots meta. (Official source)
Le Web Rendering Service analyse et peut ne pas récupérer les ressources qui ne contribuent pas au contenu essentiel. Les requêtes d’analyse côté client ne reflètent donc pas forcément l’activité réelle de Googlebot. (Official source)
Quels éléments d’une fiche produit faut-il comparer en priorité ?
Tous les écarts ne se valent pas. Classez-les par conséquence commerciale et par difficulté de correction.
| Élément | Pourquoi il compte | Signal d’alerte |
|---|---|---|
| Nom et description | Compréhension de la page | Absents du HTML initial |
| Prix et disponibilité | Confiance et éligibilité | Injectés après requête API |
| Liens internes | Découverte des fiches | href vides ou # |
| Canonical et robots | Contrôle de l’indexation | Générés en JavaScript |
| Données structurées | Lecture enrichie | Présentes seulement au rendu |
| Contenu différé | Onglets, avis, guides | Chargés au clic ou au scroll |
Un lien injecté en JavaScript reste exploitable s’il respecte les bonnes pratiques des liens crawlables, notamment une balise <a> avec un href réel. (Official source)
Comment comparer concrètement le HTML initial et le contenu rendu ?
La méthode tient en cinq étapes reproductibles.
- Capturez le HTML initial. Utilisez
curlou l’onglet Réseau en désactivant JavaScript. Enregistrez la réponse brute. - Capturez le DOM rendu. Activez JavaScript, puis utilisez le Rich Results Test ou l’URL Inspection Tool de Search Console. Ces outils montrent les ressources chargées, la console JavaScript, les exceptions et le DOM rendu. (Official source)
- Diffez les deux versions. Comparez texte visible, liens, meta, canonical et données structurées. Notez chaque élément présent dans un seul des deux.
- Testez le rendu sans ressources secondaires. Si la fiche dépend d’un script d’analyse ou d’un widget tiers, vérifiez que le contenu essentiel reste visible sans lui.
- Surveillez dans le temps. Le rapport sur les statistiques d’exploration de Search Console aide à suivre l’activité de Googlebot et du WRS. (Official source)
Exemple hypothétique. Une fiche affiche « 49,90 € » et « en stock » uniquement après un appel à une API de stock. Dans le HTML initial, ces mentions sont absentes. Le DOM rendu les contient. Le diagnostic : le contenu dépend du rendu. L’arbitrage : rendre le prix côté serveur avec une valeur par défaut, ou accepter que le prix ne soit pas dans le HTML initial. Les chiffres sont illustratifs.
Quelles décisions prendre selon les écarts observés ?
Le choix dépend de la criticité et du coût.
- Écart sur le contenu principal : privilégiez le rendu côté serveur ou le pré-rendu. C’est le cas le plus risqué.
- Écart sur les liens internes : corrigez en priorité. Sans
hrefexploitables, la découverte des fiches ralentit. - Écart sur les meta et le canonical : générez-les côté serveur. Une canonical injectée en JavaScript peut ne pas être prise en compte de la même manière qu'une canonical présente dans le HTML initial.
- Écart sur du contenu secondaire : avis, recommandations, guides. Le risque est plus faible, mais il faut le documenter.
- Écart sur les données structurées : vérifiez leur présence dans le DOM rendu. Si elles n'apparaissent qu'après interaction, leur prise en compte n'est pas garantie.
Pour approfondir la structure des fiches, consultez fiche produit SEO : les informations qui aident à acheter. Pour replacer ce diagnostic dans l’ensemble de la boutique, lisez SEO e-commerce : les fondations d’une boutique visible.
Quelles incertitudes restent ouvertes ?
Google ne publie pas de calendrier de rendu par URL et il n'est pas immédiatement évident de savoir quand une page attend son crawl ou son rendu. Le rendu n'est pas instantané et un contenu rendu peut donc mettre du temps à être pris en compte. De plus, le WRS peut ne pas récupérer des ressources non essentielles, ce qui rend les tests en laboratoire plus permissifs que la réalité. (Official source)
Enfin, les outils de test montrent un état à un instant donné et ne garantissent pas le comportement futur de l'indexation. La seule méthode fiable consiste à comparer régulièrement, à documenter les écarts et à vérifier l’effet des corrections dans Search Console.
Questions fréquentes
Google exécute-t-il toujours le JavaScript d’une fiche produit ?
Googlebot met en file les pages en 200 pour rendu, sauf indication contraire. Mais le rendu n’est pas instantané et certaines ressources peuvent ne pas être récupérées. (Official source)
Faut-il tout rendre côté serveur ?
Pas nécessairement. Le contenu critique — nom, prix, disponibilité, liens, canonical — gagne à être dans le HTML initial. Le contenu secondaire peut rester différé si le risque est accepté et documenté.