[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fwxfJO225HKLTD3GpiYnTy6CaJWVE03UKWp8Luqqb-c0":3,"$fFu28BJEzxZmN7HOpPg9z_eGxhPWMO0VXzIvdnGVvwYk":23,"$fcTFjTaPPT1sVcnh1wWEGoTWMSaOD4bwmwntkMae6w5s":111},{"_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},"6a38ddbaaa6b273b0cc22d38","verifier-llms-txt-servi-en-production",0,"Equipe Seogard","Vous avez créé un `llms.txt`, vous le voyez dans votre repo, et pourtant `GPTBot` ne le récupère pas. Le problème n'est presque jamais le contenu du fichier. C'est la couche de service : routing, dossier de build, redirections, `Content-Type`, casse. Ce guide est une checklist de diagnostic pour vérifier ce qui est **réellement servi en production** — pas ce que vous croyez avoir déployé.\n\n## Le piège : \"le fichier existe\" ≠ \"le fichier est servi\"\n\nLa majorité des guides s'arrêtent à \"placez le fichier à la racine\". En pratique, les régressions arrivent après, au déploiement. Quelques cas documentés et représentatifs :\n\n- PrimeVue : llms.txt et llms-full.txt ont commencé à renvoyer des réponses 404 après la dernière release.\n- Rank Math : une version qui retirait le trailing slash via une redirection, faisant tomber `/llms.txt` en 404.\n- Yoast : après réactivation du plugin, le bouton \"Voir le fichier llms.txt\" pointe vers un 404 pendant les 5 minutes suivantes.\n\nDans les trois cas, le fichier \"existe\" côté CMS ou repo. C'est la chaîne de service qui casse. Votre validation doit donc porter sur la réponse HTTP réelle de l'URL publique, pas sur la présence du fichier source.\n\n## Étape 1 — Tester la réponse HTTP brute\n\nNe testez jamais dans le navigateur uniquement : le rendu masque les en-têtes. Utilisez `curl` contre l'URL de production.\n\n```bash\ncurl -sSL -o /dev/null -w \"code=%{http_code} type=%{content_type} url=%{url_effective}\\n\" \\\n  https://votredomaine.com/llms.txt\n```\n\nCe que vous voulez voir : le fichier accessible à `https://votredomaine.com/llms.txt`, pas dans un sous-répertoire, pas derrière une authentification, avec un Content-Type `text/plain` (ou `text/markdown`) et un code HTTP 200.\n\nPoints de contrôle dans la sortie :\n\n- `code=200` — un `301`/`302` vers une autre URL est un signal d'alerte (voir étape 3).\n- `type=text/plain` ou `text/markdown` — si vous voyez `text/html`, votre serveur sert une page (souvent un 404 déguisé en 200, ou la SPA de fallback).\n- `url=` identique à l'URL demandée — sinon, une redirection a eu lieu.\n\n## Étape 2 — Vérifier le dossier de build (SSG / SPA)\n\nSur les frameworks statiques, le fichier doit être dans le bon dossier source pour être copié à la racine du build. C'est l'erreur la plus fréquente côté dev.\n\n- **Astro** : placez le fichier dans `public/llms.txt`. Il est servi à la racine.\n- **Next.js** : `public/llms.txt`, ou une route qui génère le fichier dynamiquement.\n- **Netlify / Cloudflare Pages** : placer dans le répertoire `public/` ou à la racine du répertoire de build.\n\nLe test qui compte : après un `build` local, vérifiez que le fichier est présent dans le dossier de sortie (`dist/`, `out/`, `build/`), pas seulement dans les sources.\n\n```bash\nnpm run build\ntest -f dist/llms.txt && echo \"OK servi\" || echo \"ABSENT du build\"\n```\n\nSi le fichier est dans vos sources mais absent du dossier de build, aucun crawler IA ne le verra jamais en prod. C'est la régression silencieuse type : le repo est correct, le déploiement non.\n\n## Étape 3 — Traquer redirections et trailing slash\n\nBeaucoup de configs normalisent les URLs (suppression du slash final, redirection HTTP→HTTPS, www→apex). Une règle trop large peut transformer `/llms.txt` en redirection cassée, exactement comme dans l'incident Rank Math. Testez les deux variantes :\n\n```bash\ncurl -sI https://votredomaine.com/llms.txt   | grep -i \"^HTTP\\|^location\"\ncurl -sI https://votredomaine.com/llms.txt/  | grep -i \"^HTTP\\|^location\"\n```\n\nUne `301` vers `/llms.txt/` (ou l'inverse) qui aboutit à un 404 est un faux positif classique : le fichier \"marche\" dans un seul des deux cas. Les crawlers IA testent l'URL canonique sans slash. Servez un `200` direct sur `/llms.txt`.\n\n## Étape 4 — Vérifier la casse et le nom exact\n\nSur Linux, le nom de fichier est sensible à la casse. Enregistrez le fichier sous le nom exact `llms.txt` — minuscules, sans espace, avec l'extension `.txt`. Le nom est sensible à la casse sur les serveurs Linux. Un `LLMs.txt` committé sur macOS (insensible à la casse) passera en local et tombera en 404 en prod Linux. Vérifiez aussi la faute classique `llms.txt` vs `llm.txt` : une erreur dans le nom casse la fonctionnalité.\n\n## Étape 5 — Confirmer l'accès côté serveur, pas côté front\n\nPour les fichiers générés à la volée (plugins CMS, routes API), l'échec se produit au niveau du serveur web. Dans un cas WordPress documenté, les fichiers markdown se généraient correctement mais le llms.txt, lui, ne se générait pas. La piste habituelle : vérifier la config Nginx et s'assurer qu'aucune directive ne bloque le llms.txt ou ne sert pas les fichiers `.txt` manquants.\n\nPour les sites fortement dépendants de JavaScript, le risque est double : si votre site nécessite fortement JavaScript pour générer le contenu, les robots des chatbots IA pourraient ne pas y accéder car ils n'utilisent pas JavaScript. Un `llms.txt` statique servi en HTTP brut contourne ce problème — à condition qu'il soit réellement servi en `text/plain`, et pas intercepté par le router de votre SPA qui renvoie l'`index.html`.\n\n## Étape 6 — Auditer et surveiller dans la durée\n\nCôté audit ponctuel, Lighthouse intègre désormais une vérification : Lighthouse signale les pages si une erreur serveur survient lors de la récupération du llms.txt ; si le fichier renvoie un 404, l'audit est marqué Not Applicable, car le fichier reste optionnel pour l'instant. Utile en one-shot, mais un audit manuel ne détecte pas une régression survenue le mardi après un déploiement du lundi soir.\n\nLe vrai risque, c'est la disparition silencieuse : le fichier était là, un refactor de routing ou un changement de plan d'hébergement l'a fait sauter, et personne ne le remarque pendant des semaines. Les crawlers IA n'aident pas à le détecter vite, car les bots IA ne visitent pas votre site quotidiennement : l'absence de visite dans les jours suivant un déploiement ne signifie pas que votre fichier est mal configuré. Vous ne voyez donc pas immédiatement l'impact dans les logs.\n\nC'est précisément ce que surveille Seogard. La règle `llms_txt_removed` compare chaque déploiement à l'état précédent et alerte quand un `llms.txt` qui renvoyait `200` se met à renvoyer `404`, une redirection, ou un `Content-Type` HTML. Branchée en CI/CD, elle peut [bloquer un déploiement régressif avant qu'il n'atteigne la prod](/blog/gate-seo-github-actions-echouer-deploiement-regressif), sur le même principe que la [détection d'un `noindex` en production avant Google](/blog/detecter-noindex-production-avant-google-ci-cd). Vous n'attendez plus la prochaine visite de `GPTBot` pour découvrir le problème. Le monitoring continu est détaillé sur la [page d'accueil Seogard](/).\n\n## Checklist de validation rapide\n\nÀ passer après chaque déploiement, idéalement automatisé :\n\n1. `GET /llms.txt` → `200` (pas `301`, pas `404`).\n2. `Content-Type` → `text/plain` ou `text/markdown` (jamais `text/html`).\n3. URL effective identique à l'URL demandée (aucune redirection silencieuse).\n4. Fichier présent dans le dossier de build, pas seulement dans les sources.\n5. Nom exact `llms.txt`, minuscules, racine du domaine.\n6. Comparaison avec le déploiement précédent : alerte si le statut change.\n\nUn `llms.txt` n'a de valeur que s'il est servi. Tant que vous ne validez pas la réponse HTTP réelle en production à chaque déploiement, vous opérez en aveugle.\n```","https://seogard.io/blog/verifier-llms-txt-servi-en-production","GEO / IA","2026-06-22T07:01:14.996Z","2026-06-22","Checklist technique pour auditer un llms.txt en prod : code 200, Content-Type, racine, casse, build SSG. Détectez la disparition avant les crawlers IA.","\u003Cp>Vous avez créé un \u003Ccode>llms.txt\u003C/code>, vous le voyez dans votre repo, et pourtant \u003Ccode>GPTBot\u003C/code> ne le récupère pas. Le problème n'est presque jamais le contenu du fichier. C'est la couche de service : routing, dossier de build, redirections, \u003Ccode>Content-Type\u003C/code>, casse. Ce guide est une checklist de diagnostic pour vérifier ce qui est \u003Cstrong>réellement servi en production\u003C/strong> — pas ce que vous croyez avoir déployé.\u003C/p>\n\u003Ch2>Le piège : \"le fichier existe\" ≠ \"le fichier est servi\"\u003C/h2>\n\u003Cp>La majorité des guides s'arrêtent à \"placez le fichier à la racine\". En pratique, les régressions arrivent après, au déploiement. Quelques cas documentés et représentatifs :\u003C/p>\n\u003Cul>\n\u003Cli>PrimeVue : llms.txt et llms-full.txt ont commencé à renvoyer des réponses 404 après la dernière release.\u003C/li>\n\u003Cli>Rank Math : une version qui retirait le trailing slash via une redirection, faisant tomber \u003Ccode>/llms.txt\u003C/code> en 404.\u003C/li>\n\u003Cli>Yoast : après réactivation du plugin, le bouton \"Voir le fichier llms.txt\" pointe vers un 404 pendant les 5 minutes suivantes.\u003C/li>\n\u003C/ul>\n\u003Cp>Dans les trois cas, le fichier \"existe\" côté CMS ou repo. C'est la chaîne de service qui casse. Votre validation doit donc porter sur la réponse HTTP réelle de l'URL publique, pas sur la présence du fichier source.\u003C/p>\n\u003Ch2>Étape 1 — Tester la réponse HTTP brute\u003C/h2>\n\u003Cp>Ne testez jamais dans le navigateur uniquement : le rendu masque les en-têtes. Utilisez \u003Ccode>curl\u003C/code> contre l'URL de production.\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -sSL\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -o\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> /dev/null\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -w\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"code=%{http_code} type=%{content_type} url=%{url_effective}\\n\"\u003C/span>\u003Cspan style=\"color:#79B8FF\"> \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">  https://votredomaine.com/llms.txt\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>Ce que vous voulez voir : le fichier accessible à \u003Ccode>https://votredomaine.com/llms.txt\u003C/code>, pas dans un sous-répertoire, pas derrière une authentification, avec un Content-Type \u003Ccode>text/plain\u003C/code> (ou \u003Ccode>text/markdown\u003C/code>) et un code HTTP 200.\u003C/p>\n\u003Cp>Points de contrôle dans la sortie :\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ccode>code=200\u003C/code> — un \u003Ccode>301\u003C/code>/\u003Ccode>302\u003C/code> vers une autre URL est un signal d'alerte (voir étape 3).\u003C/li>\n\u003Cli>\u003Ccode>type=text/plain\u003C/code> ou \u003Ccode>text/markdown\u003C/code> — si vous voyez \u003Ccode>text/html\u003C/code>, votre serveur sert une page (souvent un 404 déguisé en 200, ou la SPA de fallback).\u003C/li>\n\u003Cli>\u003Ccode>url=\u003C/code> identique à l'URL demandée — sinon, une redirection a eu lieu.\u003C/li>\n\u003C/ul>\n\u003Ch2>Étape 2 — Vérifier le dossier de build (SSG / SPA)\u003C/h2>\n\u003Cp>Sur les frameworks statiques, le fichier doit être dans le bon dossier source pour être copié à la racine du build. C'est l'erreur la plus fréquente côté dev.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>Astro\u003C/strong> : placez le fichier dans \u003Ccode>public/llms.txt\u003C/code>. Il est servi à la racine.\u003C/li>\n\u003Cli>\u003Cstrong>Next.js\u003C/strong> : \u003Ccode>public/llms.txt\u003C/code>, ou une route qui génère le fichier dynamiquement.\u003C/li>\n\u003Cli>\u003Cstrong>Netlify / Cloudflare Pages\u003C/strong> : placer dans le répertoire \u003Ccode>public/\u003C/code> ou à la racine du répertoire de build.\u003C/li>\n\u003C/ul>\n\u003Cp>Le test qui compte : après un \u003Ccode>build\u003C/code> local, vérifiez que le fichier est présent dans le dossier de sortie (\u003Ccode>dist/\u003C/code>, \u003Ccode>out/\u003C/code>, \u003Ccode>build/\u003C/code>), pas seulement dans les sources.\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">npm\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> run\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> build\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#79B8FF\">test\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -f\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> dist/llms.txt\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> && \u003C/span>\u003Cspan style=\"color:#79B8FF\">echo\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"OK servi\"\u003C/span>\u003Cspan style=\"color:#F97583\"> ||\u003C/span>\u003Cspan style=\"color:#79B8FF\"> echo\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"ABSENT du build\"\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>Si le fichier est dans vos sources mais absent du dossier de build, aucun crawler IA ne le verra jamais en prod. C'est la régression silencieuse type : le repo est correct, le déploiement non.\u003C/p>\n\u003Ch2>Étape 3 — Traquer redirections et trailing slash\u003C/h2>\n\u003Cp>Beaucoup de configs normalisent les URLs (suppression du slash final, redirection HTTP→HTTPS, www→apex). Une règle trop large peut transformer \u003Ccode>/llms.txt\u003C/code> en redirection cassée, exactement comme dans l'incident Rank Math. Testez les deux variantes :\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -sI\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> https://votredomaine.com/llms.txt\u003C/span>\u003Cspan style=\"color:#F97583\">   |\u003C/span>\u003Cspan style=\"color:#B392F0\"> grep\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -i\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"^HTTP\\|^location\"\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -sI\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> https://votredomaine.com/llms.txt/\u003C/span>\u003Cspan style=\"color:#F97583\">  |\u003C/span>\u003Cspan style=\"color:#B392F0\"> grep\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -i\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> \"^HTTP\\|^location\"\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>Une \u003Ccode>301\u003C/code> vers \u003Ccode>/llms.txt/\u003C/code> (ou l'inverse) qui aboutit à un 404 est un faux positif classique : le fichier \"marche\" dans un seul des deux cas. Les crawlers IA testent l'URL canonique sans slash. Servez un \u003Ccode>200\u003C/code> direct sur \u003Ccode>/llms.txt\u003C/code>.\u003C/p>\n\u003Ch2>Étape 4 — Vérifier la casse et le nom exact\u003C/h2>\n\u003Cp>Sur Linux, le nom de fichier est sensible à la casse. Enregistrez le fichier sous le nom exact \u003Ccode>llms.txt\u003C/code> — minuscules, sans espace, avec l'extension \u003Ccode>.txt\u003C/code>. Le nom est sensible à la casse sur les serveurs Linux. Un \u003Ccode>LLMs.txt\u003C/code> committé sur macOS (insensible à la casse) passera en local et tombera en 404 en prod Linux. Vérifiez aussi la faute classique \u003Ccode>llms.txt\u003C/code> vs \u003Ccode>llm.txt\u003C/code> : une erreur dans le nom casse la fonctionnalité.\u003C/p>\n\u003Ch2>Étape 5 — Confirmer l'accès côté serveur, pas côté front\u003C/h2>\n\u003Cp>Pour les fichiers générés à la volée (plugins CMS, routes API), l'échec se produit au niveau du serveur web. Dans un cas WordPress documenté, les fichiers markdown se généraient correctement mais le llms.txt, lui, ne se générait pas. La piste habituelle : vérifier la config Nginx et s'assurer qu'aucune directive ne bloque le llms.txt ou ne sert pas les fichiers \u003Ccode>.txt\u003C/code> manquants.\u003C/p>\n\u003Cp>Pour les sites fortement dépendants de JavaScript, le risque est double : si votre site nécessite fortement JavaScript pour générer le contenu, les robots des chatbots IA pourraient ne pas y accéder car ils n'utilisent pas JavaScript. Un \u003Ccode>llms.txt\u003C/code> statique servi en HTTP brut contourne ce problème — à condition qu'il soit réellement servi en \u003Ccode>text/plain\u003C/code>, et pas intercepté par le router de votre SPA qui renvoie l'\u003Ccode>index.html\u003C/code>.\u003C/p>\n\u003Ch2>Étape 6 — Auditer et surveiller dans la durée\u003C/h2>\n\u003Cp>Côté audit ponctuel, Lighthouse intègre désormais une vérification : Lighthouse signale les pages si une erreur serveur survient lors de la récupération du llms.txt ; si le fichier renvoie un 404, l'audit est marqué Not Applicable, car le fichier reste optionnel pour l'instant. Utile en one-shot, mais un audit manuel ne détecte pas une régression survenue le mardi après un déploiement du lundi soir.\u003C/p>\n\u003Cp>Le vrai risque, c'est la disparition silencieuse : le fichier était là, un refactor de routing ou un changement de plan d'hébergement l'a fait sauter, et personne ne le remarque pendant des semaines. Les crawlers IA n'aident pas à le détecter vite, car les bots IA ne visitent pas votre site quotidiennement : l'absence de visite dans les jours suivant un déploiement ne signifie pas que votre fichier est mal configuré. Vous ne voyez donc pas immédiatement l'impact dans les logs.\u003C/p>\n\u003Cp>C'est précisément ce que surveille Seogard. La règle \u003Ccode>llms_txt_removed\u003C/code> compare chaque déploiement à l'état précédent et alerte quand un \u003Ccode>llms.txt\u003C/code> qui renvoyait \u003Ccode>200\u003C/code> se met à renvoyer \u003Ccode>404\u003C/code>, une redirection, ou un \u003Ccode>Content-Type\u003C/code> HTML. Branchée en CI/CD, elle peut \u003Ca href=\"/blog/gate-seo-github-actions-echouer-deploiement-regressif\">bloquer un déploiement régressif avant qu'il n'atteigne la prod\u003C/a>, sur le même principe que la \u003Ca href=\"/blog/detecter-noindex-production-avant-google-ci-cd\">détection d'un \u003Ccode>noindex\u003C/code> en production avant Google\u003C/a>. Vous n'attendez plus la prochaine visite de \u003Ccode>GPTBot\u003C/code> pour découvrir le problème. Le monitoring continu est détaillé sur la \u003Ca href=\"/\">page d'accueil Seogard\u003C/a>.\u003C/p>\n\u003Ch2>Checklist de validation rapide\u003C/h2>\n\u003Cp>À passer après chaque déploiement, idéalement automatisé :\u003C/p>\n\u003Col>\n\u003Cli>\u003Ccode>GET /llms.txt\u003C/code> → \u003Ccode>200\u003C/code> (pas \u003Ccode>301\u003C/code>, pas \u003Ccode>404\u003C/code>).\u003C/li>\n\u003Cli>\u003Ccode>Content-Type\u003C/code> → \u003Ccode>text/plain\u003C/code> ou \u003Ccode>text/markdown\u003C/code> (jamais \u003Ccode>text/html\u003C/code>).\u003C/li>\n\u003Cli>URL effective identique à l'URL demandée (aucune redirection silencieuse).\u003C/li>\n\u003Cli>Fichier présent dans le dossier de build, pas seulement dans les sources.\u003C/li>\n\u003Cli>Nom exact \u003Ccode>llms.txt\u003C/code>, minuscules, racine du domaine.\u003C/li>\n\u003Cli>Comparaison avec le déploiement précédent : alerte si le statut change.\u003C/li>\n\u003C/ol>\n\u003Cp>Un \u003Ccode>llms.txt\u003C/code> n'a de valeur que s'il est servi. Tant que vous ne validez pas la réponse HTTP réelle en production à chaque déploiement, vous opérez en aveugle.\u003C/p>\n\u003Cpre>\u003Ccode>\u003C/code>\u003C/pre>",null,8,[18,19,20],"llms.txt","monitoring","crawlers IA","Vérifier que son llms.txt est servi en production","Mon Jun 22 2026 07:01:14 GMT+0000 (Coordinated Universal Time)",[24,41,56,69,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":38,"updatedAt":39,"categoryLegacy":40},"6a3238a5aa6b273b0c4e69eb","bing-rolls-out-ai-citation-share-in-webmaster-tools-via-sejournal-mattgsouthern","https://seogard.io/blog/bing-rolls-out-ai-citation-share-in-webmaster-tools-via-sejournal-mattgsouthern","2026-06-17T06:03:17.202Z","2026-06-17","Analyse technique du nouveau Citation Share dans Bing Webmaster Tools. Métriques AI, impact sur le trafic, et stratégies d'optimisation concrètes.",12,[33,34,35,36,37],"bing","citation share","webmaster tools","AI search","SEO technique","Bing AI Citation Share : ce que ça change pour le SEO technique","Wed Jun 17 2026 06:03:17 GMT+0000 (Coordinated Universal Time)","Actualités SEO",{"_id":42,"slug":43,"__v":6,"author":7,"canonical":44,"category":10,"createdAt":45,"date":46,"description":47,"image":15,"imageAlt":15,"readingTime":31,"tags":48,"title":54,"updatedAt":55,"categoryLegacy":40},"6a30222eaa6b273b0ca1e7dc","what-ai-overview-click-data-reveals-about-consumer-search-behavior-5-strategic-insights-for-cmos-via-sejournal-gregjarboe","https://seogard.io/blog/what-ai-overview-click-data-reveals-about-consumer-search-behavior-5-strategic-insights-for-cmos-via-sejournal-gregjarboe","2026-06-15T16:02:54.519Z","2026-06-15","Les utilisateurs quotidiens d'AI Overview cliquent 3.5x plus sur les sources. Analyse technique des données et stratégies d'optimisation concrètes.",[49,50,51,52,53],"AI Overview","click data","search behavior","SGE","structured data","AI Overview Click Data : ce que les clics révèlent vraiment","Mon Jun 15 2026 16:02:54 GMT+0000 (Coordinated Universal Time)",{"_id":57,"slug":58,"__v":6,"author":7,"canonical":59,"category":10,"createdAt":60,"date":61,"description":62,"image":15,"imageAlt":15,"readingTime":31,"tags":63,"title":67,"updatedAt":68,"categoryLegacy":40},"6a2c2decaa6b273b0c6a5308","ai-overview-click-data-reveals-unexpected-user-behavior-patterns-for-marketers-via-sejournal-gregjarboe","https://seogard.io/blog/ai-overview-click-data-reveals-unexpected-user-behavior-patterns-for-marketers-via-sejournal-gregjarboe","2026-06-12T16:03:56.058Z","2026-06-12","Les utilisateurs quotidiens d'AI Overviews cliquent 3,5x plus sur les sources. Analyse technique des opportunités d'optimisation pour les sites à fort volume.",[64,50,65,66,53],"ai overview","seo technique","google search","AI Overviews : les données de clics révèlent un comportement inattendu","Fri Jun 12 2026 16:03:56 GMT+0000 (Coordinated Universal Time)",{"_id":70,"slug":71,"__v":6,"author":7,"canonical":72,"category":10,"createdAt":73,"date":74,"description":75,"image":15,"imageAlt":15,"readingTime":76,"tags":77,"title":82,"updatedAt":83,"categoryLegacy":40},"6a283936aa6b273b0c255fdd","how-ai-forms-opinions-about-your-brand","https://seogard.io/blog/how-ai-forms-opinions-about-your-brand","2026-06-09T16:03:02.486Z","2026-06-09","Construisez une empreinte numérique que les LLMs comprennent : structured data, entités, corpus de citations. Guide technique pour Lead SEO.",14,[78,79,53,80,81],"AI visibility","brand authority","LLM optimization","entity SEO","Comment l'IA se forge une opinion sur votre marque","Tue Jun 09 2026 16:03:02 GMT+0000 (Coordinated Universal Time)",{"_id":85,"slug":86,"__v":6,"author":7,"canonical":87,"category":10,"createdAt":88,"date":89,"description":90,"image":15,"imageAlt":15,"readingTime":31,"tags":91,"title":95,"updatedAt":96,"categoryLegacy":40},"6a265b17aa6b273b0c9a6fff","your-next-ai-visitor-will-know-who-sent-it-via-sejournal-slobodanmanic","https://seogard.io/blog/your-next-ai-visitor-will-know-who-sent-it-via-sejournal-slobodanmanic","2026-06-08T06:03:03.429Z","2026-06-08","Les agents AI arrivent avec le contexte utilisateur. Comment adapter votre contenu pour rester utile face au blended retrieval.",[92,93,37,94,53],"AI agents","blended retrieval","crawl AI","AI Visitors contextuels : préparer vos pages au blended retrieval","Mon Jun 08 2026 06:03:03 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":31,"tags":104,"title":109,"updatedAt":110,"categoryLegacy":40},"6a205036aa6b273b0c9cf532","google-tests-dedicated-ai-search-reports-in-search-console-via-sejournal-mattgsouthern","https://seogard.io/blog/google-tests-dedicated-ai-search-reports-in-search-console-via-sejournal-mattgsouthern","2026-06-03T16:03:02.029Z","2026-06-03","Google teste des rapports dédiés AI Search dans Search Console. Analyse technique des données, impacts SEO et stratégies d'adaptation pour les sites 500+ pages.",[105,106,36,107,108],"google","search console","AI overviews","reports","AI Search Reports dans Search Console : analyse technique","Wed Jun 03 2026 16:03:02 GMT+0000 (Coordinated Universal Time)",{"categories":112},[113,117,120,124,128,132,136],{"category":114,"slug":115,"count":116},"Régressions SEO","regressions-seo",138,{"category":10,"slug":118,"count":119},"geo-ia",99,{"category":121,"slug":122,"count":123},"Indexation & crawl","indexation-crawl",32,{"category":125,"slug":126,"count":127},"SSR / CSR","ssr-csr",23,{"category":129,"slug":130,"count":131},"Données structurées","donnees-structurees",6,{"category":133,"slug":134,"count":135},"CI/CD SEO","ci-cd-seo",4,{"category":137,"slug":138,"count":139},"Monitoring continu","monitoring-continu",3]