[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fl6-H5uYd9JCG2X5q6I2R3M9R1HZnf7BkLS_iJ50zb3A":3,"$fN7A5S8RFy33dgUOzBwNnOmAnrnCkIJNQnYf4UimHL1k":23,"$fcTFjTaPPT1sVcnh1wWEGoTWMSaOD4bwmwntkMae6w5s":110},{"_id":4,"slug":5,"__v":6,"author":7,"body":8,"canonical":9,"category":10,"createdAt":11,"date":12,"description":13,"htmlContent":14,"image":15,"imageAlt":15,"readingTime":16,"tags":17,"title":21,"updatedAt":22},"6a3b80b5aa6b273b0cefb309","prerendering-vs-ssr-cloaking-mismatch-bot-user",0,"Equipe Seogard","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.\n\n## Pourquoi le prerendering crée un risque que le SSR n'a pas\n\nEn 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).\n\nLe 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.\n\nLa 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.\n\nEt 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.\n\n## Les trois mismatchs qui transforment le prerendering en cloaking\n\nLa 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 :\n\n**1. Title divergent.** Le composant qui calcule le `\u003Ctitle>` 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`.\n\n**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`.\n\n**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`.\n\nLe 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.\n\n## Comment diagnostiquer la divergence (méthode)\n\nL'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.\n\nConcrètement, pour un check rapide en ligne de commande :\n\n```bash\n# Version servie aux bots (cache prérendu)\ncurl -A \"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)\" \\\n  https://exemple.com/page -s > bot.html\n\n# Version brute servie aux users (shell CSR avant exécution JS)\ncurl -A \"Mozilla/5.0\" https://exemple.com/page -s > user.html\n\n# Diff sur le \u003Ctitle>\ndiff \u003C(grep -oP '(?\u003C=\u003Ctitle>).*?(?=\u003C/title>)' bot.html) \\\n     \u003C(grep -oP '(?\u003C=\u003Ctitle>).*?(?=\u003C/title>)' user.html)\n```\n\nLe 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.\n\nC'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](/blog/spa-non-indexee-google-page-blanche-diagnostic).\n\n## Verrouiller la non-régression en CI/CD\n\nDé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.\n\nLe 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](/blog/bloquer-deploiement-seo-regressif-verdict-pass-fail) et l'intégration concrète dans [Détecter un noindex en production avant Google avec la CI/CD](/blog/detecter-noindex-production-avant-google-ci-cd).\n\nLa gate idéale, au minimum, vérifie sur un échantillon d'URLs représentatives :\n\n- le `\u003Ctitle>` prérendu == title du DOM CSR rendu ;\n- la présence du contenu principal (un sélecteur attendu) dans les deux versions ;\n- la présence de `canonical`, `hreflang` et `robots` dans le snapshot bot.\n\nSi 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é.\n\n## Verdict par cas\n\n- **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.\n- **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é.\n- **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.\n\nDans 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.\n\nPour le cadre officiel, référez-vous à la documentation [Google Search Central sur le rendu dynamique](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) et au [guide JavaScript SEO de web.dev](https://web.dev/articles/rendering-on-the-web).\n```","https://seogard.io/blog/prerendering-vs-ssr-cloaking-mismatch-bot-user","SSR / CSR","2026-06-24T07:01:09.370Z","2026-06-24","Le vrai risque du prerendering n'est pas le SSR : c'est la divergence silencieuse entre la version servie aux bots et le CSR. Comment la détecter.","\u003Cp>Le prerendering n'est pas du cloaking tant que le HTML servi au bot est \u003Cstrong>identique au contenu\u003C/strong> 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 \u003Cstrong>deux pipelines de rendu\u003C/strong> — 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.\u003C/p>\n\u003Ch2>Pourquoi le prerendering crée un risque que le SSR n'a pas\u003C/h2>\n\u003Cp>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).\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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.\u003C/p>\n\u003Cp>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 \u003Cem>workaround\u003C/em>, pas de stratégie pérenne. Si vous l'utilisez encore, le coût de surveillance retombe entièrement sur vous.\u003C/p>\n\u003Ch2>Les trois mismatchs qui transforment le prerendering en cloaking\u003C/h2>\n\u003Cp>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 :\u003C/p>\n\u003Cp>\u003Cstrong>1. Title divergent.\u003C/strong> Le composant qui calcule le \u003Ccode><title>\u003C/code> 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 \u003Ccode>ssr_title_mismatch\u003C/code>.\u003C/p>\n\u003Cp>\u003Cstrong>2. Contenu manquant dans la version servie au bot.\u003C/strong> 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 \u003Ccode>ssr_content_mismatch\u003C/code>.\u003C/p>\n\u003Cp>\u003Cstrong>3. Balises SEO absentes du prérendu.\u003C/strong> 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 \u003Ccode>rec_canonical_missing_in_ssr\u003C/code> et \u003Ccode>rec_hreflang_missing_in_ssr\u003C/code>.\u003C/p>\n\u003Cp>Le danger commun : ces trois cas sont \u003Cstrong>silencieux\u003C/strong>. 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.\u003C/p>\n\u003Ch2>Comment diagnostiquer la divergence (méthode)\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>Concrètement, pour un check rapide en ligne de commande :\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># Version servie aux bots (cache prérendu)\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -A\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)\"\u003C/span>\u003Cspan style=\"color:#79B8FF\"> \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">  https://exemple.com/page\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -s\u003C/span>\u003Cspan style=\"color:#F97583\"> >\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> bot.html\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># Version brute servie aux users (shell CSR avant exécution JS)\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -A\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"Mozilla/5.0\"\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> https://exemple.com/page\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -s\u003C/span>\u003Cspan style=\"color:#F97583\"> >\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> user.html\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># Diff sur le <title>\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">diff\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> <(\u003C/span>\u003Cspan style=\"color:#B392F0\">grep\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -oP\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> '(?<=<title>).*?(?=</title>)' bot.html)\u003C/span>\u003Cspan style=\"color:#79B8FF\"> \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">     <(\u003C/span>\u003Cspan style=\"color:#B392F0\">grep\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -oP\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> '(?<=<title>).*?(?=</title>)' user.html)\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>Le problème : \u003Ccode>user.html\u003C/code> 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.\u003C/p>\n\u003Cp>C'est exactement le rôle de Seogard : comparer en production le \u003Cstrong>HTML brut servi aux bots\u003C/strong> et le \u003Cstrong>rendu JS final\u003C/strong>, route par route, et lever un verdict quand \u003Ccode>ssr_content_mismatch\u003C/code> ou \u003Ccode>ssr_title_mismatch\u003C/code> se déclenche — avant que Googlebot ne recrawle. Pour un diagnostic sur une SPA qui sert une coquille vide aux crawlers, voyez le guide \u003Ca href=\"/blog/spa-non-indexee-google-page-blanche-diagnostic\">SPA non indexée : page blanche, diagnostic\u003C/a>.\u003C/p>\n\u003Ch2>Verrouiller la non-régression en CI/CD\u003C/h2>\n\u003Cp>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.\u003C/p>\n\u003Cp>Le principe est le même que pour un \u003Ccode>noindex\u003C/code> qui fuite en prod : on transforme un check SEO en gate bloquante. Voir \u003Ca href=\"/blog/bloquer-deploiement-seo-regressif-verdict-pass-fail\">Bloquer un déploiement SEO régressif : verdict pass/fail\u003C/a> et l'intégration concrète dans \u003Ca href=\"/blog/detecter-noindex-production-avant-google-ci-cd\">Détecter un noindex en production avant Google avec la CI/CD\u003C/a>.\u003C/p>\n\u003Cp>La gate idéale, au minimum, vérifie sur un échantillon d'URLs représentatives :\u003C/p>\n\u003Cul>\n\u003Cli>le \u003Ccode><title>\u003C/code> prérendu == title du DOM CSR rendu ;\u003C/li>\n\u003Cli>la présence du contenu principal (un sélecteur attendu) dans les deux versions ;\u003C/li>\n\u003Cli>la présence de \u003Ccode>canonical\u003C/code>, \u003Ccode>hreflang\u003C/code> et \u003Ccode>robots\u003C/code> dans le snapshot bot.\u003C/li>\n\u003C/ul>\n\u003Cp>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é.\u003C/p>\n\u003Ch2>Verdict par cas\u003C/h2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Site statique / semi-statique, peu de routes\u003C/strong> : le prerendering (ou mieux, le SSG) couvre le SEO sans le coût du SSR. Acceptable, à condition de monitorer la fraîcheur du cache.\u003C/li>\n\u003Cli>\u003Cstrong>Contenu qui change par requête ou très fréquemment\u003C/strong> : 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é.\u003C/li>\n\u003Cli>\u003Cstrong>Site existant difficile à migrer\u003C/strong> : 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.\u003C/li>\n\u003C/ul>\n\u003Cp>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 \u003Ca href=\"/\">Seogard\u003C/a> automatise.\u003C/p>\n\u003Cp>Pour le cadre officiel, référez-vous à la documentation \u003Ca href=\"https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering\">Google Search Central sur le rendu dynamique\u003C/a> et au \u003Ca href=\"https://web.dev/articles/rendering-on-the-web\">guide JavaScript SEO de web.dev\u003C/a>.\u003C/p>\n\u003Cpre>\u003Ccode>\u003C/code>\u003C/pre>",null,7,[18,19,20],"prerendering","cloaking","ssr-vs-csr","Prerendering vs SSR : éviter le cloaking et le mismatch","Wed Jun 24 2026 07:01:09 GMT+0000 (Coordinated Universal Time)",[24,39,53,70,84,97],{"_id":25,"slug":26,"__v":6,"author":7,"canonical":27,"category":10,"createdAt":28,"date":29,"description":30,"image":15,"imageAlt":15,"readingTime":31,"tags":32,"title":37,"updatedAt":38},"6a363ab5aa6b273b0c949ac4","spa-non-indexee-google-page-blanche-diagnostic","https://seogard.io/blog/spa-non-indexee-google-page-blanche-diagnostic","2026-06-20T07:01:09.673Z","2026-06-20","Diagnostic actionnable pour confirmer que Googlebot voit une page blanche sur votre SPA, comparer HTML brut vs rendu JS et corriger avant l'indexation.",8,[33,34,35,36],"spa","indexation","csr","googlebot","SPA non indexée : détecter la page blanche vue par Google","Sat Jun 20 2026 07:01:09 GMT+0000 (Coordinated Universal Time)",{"_id":40,"slug":41,"__v":6,"author":7,"canonical":42,"category":10,"createdAt":43,"date":44,"description":45,"image":15,"imageAlt":15,"readingTime":46,"tags":47,"title":51,"updatedAt":52,"categoryLegacy":50},"6a3567e0aa6b273b0ce66e5a","multi-currency-dropdown-change-le-title-cote-csr-google-voit-le-default-usd","https://seogard.io/blog/multi-currency-dropdown-change-le-title-cote-csr-google-voit-le-default-usd","2026-06-19T16:01:36.079Z","2026-06-19","Un sélecteur de devise JS réécrit le title au runtime. Google indexe la version USD sur tous les marchés. Récit, diagnostic et correctif.",11,[48,35,49,33,50],"multi currency","title","i18n","Multi-currency dropdown réécrit le title côté CSR : fix","Fri Jun 19 2026 16:01:36 GMT+0000 (Coordinated Universal Time)",{"_id":54,"slug":55,"__v":6,"author":7,"canonical":56,"category":10,"createdAt":57,"date":58,"description":59,"image":15,"imageAlt":15,"readingTime":60,"tags":61,"title":67,"updatedAt":68,"categoryLegacy":69},"6a317369aa6b273b0cb03aa2","strapi-public-role-bloque-l-api-lecture-ssr-void-googlebot-voit-page-blanche","https://seogard.io/blog/strapi-public-role-bloque-l-api-lecture-ssr-void-googlebot-voit-page-blanche","2026-06-16T16:01:45.497Z","2026-06-16","Un seed Strapi écrase le rôle Public. L'API renvoie 403, le SSR sert du vide. Récit complet : diagnostic, fix, récupération SEO en 19 jours.",12,[62,63,64,65,66],"strapi","permissions","ssr","api","headless-cms","Strapi public role 403 : SSR vide, Googlebot indexe du blanc","Tue Jun 16 2026 16:01:45 GMT+0000 (Coordinated Universal Time)","Headless",{"_id":71,"slug":72,"__v":6,"author":7,"canonical":73,"category":10,"createdAt":74,"date":75,"description":76,"image":15,"imageAlt":15,"readingTime":60,"tags":77,"title":81,"updatedAt":82,"categoryLegacy":83},"6a2cf253aa6b273b0c0c9a5f","tanstack-router-ssr-title-pris-du-layout-au-lieu-de-la-leaf-route","https://seogard.io/blog/tanstack-router-ssr-title-pris-du-layout-au-lieu-de-la-leaf-route","2026-06-13T06:01:55.020Z","2026-06-13","Un e-commerce perd 40 % de clics organiques : TanStack Router applique le title du layout parent au lieu de la leaf route. Récit, diagnostic, fix.",[78,79,64,49,80],"tanstack router","react","meta tags","TanStack Router SSR : le title vient du layout, pas de la page","Sat Jun 13 2026 06:01:55 GMT+0000 (Coordinated Universal Time)","Framework",{"_id":85,"slug":86,"__v":6,"author":7,"canonical":87,"category":10,"createdAt":88,"date":89,"description":90,"image":15,"imageAlt":15,"readingTime":60,"tags":91,"title":95,"updatedAt":96,"categoryLegacy":83},"6a2adbecaa6b273b0c53007c","remix-meta-async-non-awaited-metas-vides-en-streaming","https://seogard.io/blog/remix-meta-async-non-awaited-metas-vides-en-streaming","2026-06-11T16:01:48.933Z","2026-06-11","Un site Remix perd 30% de trafic organique. La cause : meta() async non awaited, les balises arrivent après la fermeture du head en streaming.",[92,93,94,64],"remix","meta","streaming","Remix meta() async : metas vides en streaming SSR","Thu Jun 11 2026 16:01:48 GMT+0000 (Coordinated Universal Time)",{"_id":98,"slug":99,"__v":6,"author":7,"canonical":100,"category":10,"createdAt":101,"date":102,"description":103,"image":15,"imageAlt":15,"readingTime":60,"tags":104,"title":107,"updatedAt":108,"categoryLegacy":109},"6a23b7d0aa6b273b0c6c840f","splash-screen-noscript-mal-place-qui-contient-le-vrai-contenu-pour-googlebot-sansjs","https://seogard.io/blog/splash-screen-noscript-mal-place-qui-contient-le-vrai-contenu-pour-googlebot-sansjs","2026-06-06T06:01:52.615Z","2026-06-06","Un e-commerce SPA cache son contenu dans une balise noscript pour les bots. Google détecte du cloaking. Récit, diagnostic et fix complet.",[105,19,33,106],"noscript","splash","noscript cloaking : splash screen SPA piège Google","Sat Jun 06 2026 06:01:52 GMT+0000 (Coordinated Universal Time)","Rendering",{"categories":111},[112,116,120,124,127,131,135],{"category":113,"slug":114,"count":115},"Régressions SEO","regressions-seo",138,{"category":117,"slug":118,"count":119},"GEO / IA","geo-ia",99,{"category":121,"slug":122,"count":123},"Indexation & crawl","indexation-crawl",32,{"category":10,"slug":125,"count":126},"ssr-csr",24,{"category":128,"slug":129,"count":130},"Données structurées","donnees-structurees",6,{"category":132,"slug":133,"count":134},"CI/CD SEO","ci-cd-seo",5,{"category":136,"slug":137,"count":138},"Monitoring continu","monitoring-continu",3]