Taux de rendu
Le taux de rendu est la proportion du texte d’une page qui existe déjà dans le HTML envoyé par le serveur, avant l’exécution du moindre JavaScript.
Une page à 95 % est lisible par tout ce qui sait récupérer une URL. Une page à 10 % est une coquille presque vide qui ne devient une page que dans un navigateur, et la plupart des robots n’en sont pas. C’est la vérification que le plus de sites échouent.
Pourquoi le taux de rendu décide-t-il de votre citabilité ?
Un modèle ne navigue pas. Quelque chose récupère votre URL, garde le texte reçu, et ce texte est tout ce que le modèle aura jamais de vous. Si votre contenu s’assemble côté client, ce qui reste est une barre de navigation et un état de chargement.
Google est l’exception qui entretient la confusion. Il exécute bien le JavaScript, dans une phase distincte postérieure au crawl, et sa propre documentation recommande toujours le rendu côté serveur parce que, selon ses termes, tous les robots ne savent pas exécuter du JavaScript. Les robots qui apportent des réponses appartiennent en majorité à ce second groupe.
Quel taux de rendu est bon ?
Mesuré comme la proportion du texte final présente dans le HTML brut. Les tranches sont volontairement grossières : au-dessus de 90 % la page est pratiquement complète sans scripts, et sous 60 % un robot voit autre chose que ce que vous avez publié.
- Au-dessus de 90 % — la page est pratiquement complète sans JavaScript.
- Entre 60 % et 90 % — le contenu principal est là et des parties manquent. Souvent des avis, des prix ou des onglets.
- Sous 60 % — un robot qui n’exécute pas le JavaScript voit une page différente de celle que vous avez publiée.
- Proche de 0 % — une coquille vide. Le site n’existe que pour des navigateurs.
Comment corriger un taux de rendu faible ?
Rendu côté serveur ou génération statique pour le contenu qui compte, ce que tout framework moderne permet et que la plupart des projets n’ont simplement jamais activé. Ni le design ni la technologie ne changent ; ce qui change, c’est qui assemble le HTML.
Quand une refonte n’est pas envisageable, le correctif partiel bon marché consiste à servir une version texte à qui la demande, par négociation de contenu ou via une copie Markdown documentée. Cela ne répare pas la page, mais le contenu existe alors quelque part où un robot peut l’atteindre.
Sur quoi cela s’appuie-t-il ?
La documentation de Google est ici la source la plus solide, et c’est celle que l’on cite le plus souvent à l’envers. Les trois se lisent en entier et gratuitement.
- JavaScript SEO basics, Google Search Central
Documente les trois phases —crawl, rendu, indexation— et affirme que le rendu côté serveur reste une bonne idée parce que tous les robots ne savent pas exécuter du JavaScript. Cette phrase est tout l’argument.
- GEO: Generative Engine Optimization
Mesure ce qui rend un contenu visible dans les réponses générées. Rien de tout cela ne s’applique à un contenu que le robot n’a jamais reçu.
- La convention llms.txt
Le contournement partiel habituel : publier une version Markdown de ce que dit la page, pour les agents qui n’exécuteront pas de script.
Questions fréquentes sur Taux de rendu
Google n’exécute-t-il pas le JavaScript de toute façon ?
- Si, dans une phase de rendu postérieure au crawl. Cela couvre Google et ne dit rien des autres, et la documentation de Google recommande toujours le rendu côté serveur au motif que tous les robots ne savent pas exécuter du JavaScript. Optimiser pour le seul robot qui rend, c’est parier sur le mauvais.
Un bon taux de rendu implique-t-il de renoncer à React ?
- Non. React, Vue et Svelte font du rendu serveur, et les frameworks bâtis dessus le font par défaut. Un taux faible est presque toujours une configuration jamais activée, pas une limite de la technologie.