Le prerendering n'est pas du cloaking tant que le HTML servi au bot est identique au contenu que voit l'utilisateur. C'est la règle que répètent Google, Bing et tous les guides. Mais cette règle déplace le vrai problème au lieu de le résoudre : avec le prerendering, vous maintenez deux pipelines de rendu — un cache prérendu pour les crawlers, un CSR live pour les humains. Rien ne garantit qu'ils restent synchronisés dans le temps. Et c'est précisément quand ils divergent que vous basculez, sans le vouloir, du côté du cloaking. Cet article traite ce que la SERP ignore : comment détecter cette divergence avant Google.
Pourquoi le prerendering crée un risque que le SSR n'a pas
En SSR pur, il n'existe qu'une source de vérité. Le serveur génère le HTML, et users comme bots reçoivent la même réponse au même instant. La divergence est structurellement impossible (hors bug d'hydration).
Le prerendering fonctionne autrement. Le rendu dynamique sert une version HTML statique aux bots, tandis que les visiteurs normaux reçoivent le contenu rendu côté client, en distinguant selon le user-agent qui effectue l'appel. Vous avez donc deux artefacts distincts pour la même URL.
La position officielle est tolérante mais conditionnelle. Tant que vous faites un effort de bonne foi pour renvoyer le même contenu à tous les visiteurs, la seule différence étant un rendu serveur pour les bots et client pour les utilisateurs réels, c'est acceptable et n'est pas considéré comme du cloaking. Le mot clé est "même contenu". Dès que les deux versions divergent, la tolérance tombe.
Et le rendu dynamique n'est plus la voie recommandée de toute façon. Le rendu dynamique était une solution de contournement pour les sites rencontrant des problèmes avec le contenu généré par JavaScript. Google le qualifie désormais explicitement de workaround, pas de stratégie pérenne. Si vous l'utilisez encore, le coût de surveillance retombe entièrement sur vous.
Les trois mismatchs qui transforment le prerendering en cloaking
La divergence n'est presque jamais volontaire. Elle vient d'un cache prérendu qui se périme, d'un déploiement qui modifie le CSR sans réinvalider le cache, ou d'un changement de données dynamiques. Trois cas concrets :
1. Title divergent. Le composant qui calcule le <title> côté client (Helmet sur React, vue-meta, service Title sur Angular) évolue, mais le snapshot prérendu garde l'ancien. Le bot indexe un title obsolète, l'utilisateur en voit un autre. C'est typiquement ce que le crawler Seogard remonte via la règle ssr_title_mismatch.
2. Contenu manquant dans la version servie au bot. Le prerendering présente parfois aux crawlers du contenu rendu en temps réel : si le JavaScript met trop de temps à charger, le contenu n'apparaît que partiellement — par exemple le header et le footer, mais pas le corps. Côté CSR, l'utilisateur finit par voir la page complète. Côté cache, le bot reçoit une page tronquée. C'est ssr_content_mismatch.
3. Balises SEO absentes du prérendu. Canonical, hreflang, robots : ces balises sont souvent injectées par le même JS que le contenu. Si elles n'arrivent pas dans le snapshot, le bot voit une page sans signal de canonisation ni de langue. Ce sont les règles rec_canonical_missing_in_ssr et rec_hreflang_missing_in_ssr.
Le danger commun : ces trois cas sont silencieux. Le site fonctionne pour vos utilisateurs. Rien ne casse visiblement. Vous ne le découvrez qu'en lisant une chute d'impressions dans Search Console, des semaines plus tard.
Comment diagnostiquer la divergence (méthode)
L'approche manuelle classique reste valable pour un audit ponctuel : récupérer le HTML servi avec un user-agent Googlebot, récupérer le HTML rendu en CSR, et differ les deux. Si vous identifiez des différences entre la version prérendue et la version CSR, comparez les deux versions de la page avec un outil de comparaison de code HTML, en récupérant la source vue par le crawler.
Concrètement, pour un check rapide en ligne de commande :
# Version servie aux bots (cache prérendu)
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://exemple.com/page -s > bot.html
# Version brute servie aux users (shell CSR avant exécution JS)
curl -A "Mozilla/5.0" https://exemple.com/page -s > user.html
# Diff sur le <title>
diff <(grep -oP '(?<=<title>).*?(?=</title>)' bot.html) \
<(grep -oP '(?<=<title>).*?(?=</title>)' user.html)Le problème : user.html ne contient pas le DOM final post-hydration. Pour une comparaison juste, il faut exécuter le JS côté user (Playwright/Puppeteer) puis comparer le DOM rendu au snapshot prérendu. C'est faisable en script, mais ça ne tient pas en continu sur 10 000 URLs ni à chaque déploiement.
C'est exactement le rôle de Seogard : comparer en production le HTML brut servi aux bots et le rendu JS final, route par route, et lever un verdict quand ssr_content_mismatch ou ssr_title_mismatch se déclenche — avant que Googlebot ne recrawle. Pour un diagnostic sur une SPA qui sert une coquille vide aux crawlers, voyez le guide SPA non indexée : page blanche, diagnostic.
Verrouiller la non-régression en CI/CD
Détecter en production, c'est bien. Empêcher le déploiement fautif, c'est mieux. Un mismatch prérendu/CSR est une régression comme une autre : il doit faire échouer le build avant la mise en ligne.
Le principe est le même que pour un noindex qui fuite en prod : on transforme un check SEO en gate bloquante. Voir Bloquer un déploiement SEO régressif : verdict pass/fail et l'intégration concrète dans Détecter un noindex en production avant Google avec la CI/CD.
La gate idéale, au minimum, vérifie sur un échantillon d'URLs représentatives :
- le
<title>prérendu == title du DOM CSR rendu ; - la présence du contenu principal (un sélecteur attendu) dans les deux versions ;
- la présence de
canonical,hreflangetrobotsdans le snapshot bot.
Si l'un de ces points échoue, le déploiement est bloqué. Vous ne pouvez plus mettre en ligne une version où le cache prérendu a silencieusement divergé.
Verdict par cas
- Site statique / semi-statique, peu de routes : le prerendering (ou mieux, le SSG) couvre le SEO sans le coût du SSR. Acceptable, à condition de monitorer la fraîcheur du cache.
- Contenu qui change par requête ou très fréquemment : le SSR reste plus sûr, car il supprime par construction le risque de mismatch. Le prerendering vous expose à des fenêtres de contenu périmé.
- Site existant difficile à migrer : le prerendering reste une béquille acceptable — mais seulement avec une surveillance active de la divergence bot/user, sinon vous accumulez une dette de cloaking involontaire.
Dans tous les cas où vous gardez deux pipelines de rendu, la question n'est pas « est-ce du cloaking aujourd'hui », mais « comment je sais qu'il ne le deviendra pas demain ». La réponse tient en un mot : monitoring continu de l'écart HTML brut / rendu JS. C'est ce que Seogard automatise.
Pour le cadre officiel, référez-vous à la documentation Google Search Central sur le rendu dynamique et au guide JavaScript SEO de web.dev.