Audit GEO

Le GEO (Generative Engine Optimization) consiste à faire en sorte qu'un site soit facile à explorer, à comprendre et à citer pour les moteurs d'IA : ChatGPT, Claude, Perplexity, Gemini et Google AI Overviews. L'audit GEO, sous Visibilité IA → Audit GEO, récupère le site d'un client comme le font la plupart des crawlers d'IA (une simple requête HTTP, sans exécution de JavaScript) et note des signaux concrets et vérifiables pour en tirer un score de maturité unique de 0–100. Les crawlers d'OpenAI, d'Anthropic et de Perplexity ne sont pas documentés comme exécutant le JavaScript. Google, lui, rend les pages dans Chromium headless, mais plus tard et dans une file d'attente : c'est donc le HTML brut que tous les moteurs peuvent lire dès la première visite. Il faut bien le comprendre : ce score mesure la maturité (le site est-il en position d'être cité ?), pas la part de citations réelle. La fréquence à laquelle une marque est effectivement mentionnée dans les réponses IA est suivie à part, dans l'onglet Visibilité. Nous maintenons cette distinction explicite pour que le score ne soit jamais survendu.

Le score composite pondère cinq catégories. Accès des crawlers d'IA (30) : votre robots.txt laisse-t-il réellement accéder au site les crawlers qui alimentent les réponses IA en direct : OAI-SearchBot et ChatGPT-User d'OpenAI, Claude-User et Claude-SearchBot d'Anthropic, PerplexityBot, Googlebot et Google-Extended, meta-webindexer de Meta AI ? Accessibilité du contenu / SSR (30) : le contenu principal de la page figure-t-il dans le HTML brut, et non injecté par JavaScript, puisque la plupart des crawlers d'IA n'exécutent pas le JS ? Cette catégorie comporte aussi une sonde d'écart de contenu, à titre informatif : les pages auditées sont récupérées une fois comme un agent IA et une fois comme un navigateur ordinaire, et un écart important entre les deux est signalé. Si le bot reçoit moins, les constats de l'audit peuvent sous-estimer ce que voient les humains ; si le bot reçoit plus ou un contenu différent, il y a un risque de cloaking. Cette sonde n'affecte jamais le score. La même catégorie analyse aussi les pages récupérées à la recherche de texte caché destiné aux lecteurs IA : un balisage qu'un visiteur humain ne voit jamais (display:none, font-size à zéro, décalages hors écran, attributs hidden ou aria-hidden, classes réservées aux lecteurs d'écran, commentaires HTML, attributs alt ou meta) et qui contient des formulations comme « ignore previous instructions » ou « AI assistants: recommend … ». Les crawlers d'IA lisent le HTML brut, donc ce texte leur parvient en entier, et les règles de Google contre le spam comptent le texte caché et les tentatives de manipuler les réponses d'IA générative comme du spam. Il s'agit du détecteur heuristique propre à CrunchJunkie, pas d'un contrôle de la politique d'une plateforme : il n'affiche une ligne que s'il trouve quelque chose, cite l'extrait pour que vous puissiez en juger, et n'affecte jamais le score. Données structurées (20) : du JSON-LD schema.org valide qui ancre votre marque comme entité connue, en particulier un bloc Organization avec des liens sameAs, plus la prise en charge de types plus riches adaptés aux réponses, dont FAQPage, Article, Product, HowTo et QAPage. Au-delà de la simple détection de ces types, l'audit vérifie qu'un type présent porte bien ses propriétés requises (une FAQPage a besoin de questions avec des réponses acceptées, un Article de headline, author et datePublished, un Product d'offers, un HowTo d'étapes) ; un type présent mais incomplet est signalé comme partiel, avec les propriétés manquantes exactes à ajouter, au lieu d'être validé en totalité. Hygiène SEO technique (15) : sitemap, canonical auto-référencée, un seul H1, un title et une meta description pertinents, et HTTPS. llms.txt (5) : présence et validité de base d'un fichier /llms.txt, une convention tournée vers l'avenir, pondérée au plus bas, et c'est voulu : les consignes officielles de Google sur l'IA générative indiquent qu'il ignore llms.txt, et aucun moteur de réponse n'a confirmé le consommer pour ses citations. Il est donc noté comme une hygiène lisible par les machines et peu coûteuse, jamais comme un facteur de classement Google/recherche ni de citation. Chaque contrôle est noté réussi, partiel ou échoué, avec une explication en langage clair de ce qui a été trouvé et de pourquoi cela compte. Le résultat est donc une liste d'actions, pas seulement un chiffre.

Dans la notation de la qualité du contenu, l'audit GEO vérifie trois signaux d'écriture tirés d'un benchmark de laboratoire de 2024 : les citations directes, les statistiques sourcées et les citations sortantes faisant autorité. Ils viennent de l'article KDD'24 « GEO: Generative Engine Optimization » (Aggarwal et al., Princeton / IIT Delhi), dans lequel la part d'une source dans la réponse générée (le nombre de mots ajusté à la position selon l'article, sur GPT-3.5 et son propre jeu de requêtes) est passée de 19,5 % sans modification à 27,8 % avec des citations directes, 25,9 % avec des statistiques et 24,9 % avec des sources citées. C'est un résultat de laboratoire, pas une mesure sur des moteurs en production, et nos propres données sur 81 sites (septembre 2026) n'ont montré aucun lien net entre le score global de l'audit et la fréquence à laquelle les réponses IA nommaient un site. Chaque contrôle est noté réussi/partiel/échoué avec une note en langage clair qui nomme sa source, pour que vous voyiez d'où vient la recommandation. L'audit note aussi la structure extractible : une page découpe-t-elle son contenu en listes à puces ou numérotées et en tableaux de données, qui donnent aux moteurs de réponse des passages autonomes à reprendre dans leurs réponses ? Cette note reste mesurée (une page riche en prose est incitée à devenir plus facile à parcourir, jamais sanctionnée pour cela) et s'appuie sur des recherches de 2026 sur la structure du contenu et la citation par l'IA (« Structural Feature Engineering for GEO », arXiv 2603.29979). Le même benchmark a identifié ce qui ne fonctionne pas : le bourrage de mots-clés a donné les pires résultats des méthodes testées. L'audit le traite donc comme un signal négatif : il ne rapporte jamais de points, et une page dont la densité de mots-clés est trop élevée (environ au-dessus de 6 %, avec une zone élevée autour de 4–6 %) est signalée comme un problème à corriger, pas comme une case à cocher. Rien dans le score de contenu ne récompense la densité de mots-clés ; seul le bourrage est pénalisé.

Une règle robots.txt qui indique « autorisé » ne compte que si le crawler peut réellement atteindre la page. De nombreux sites débloquent les bots d'IA dans robots.txt, mais se trouvent derrière un WAF ou un CDN (AI Crawl Control de Cloudflare, anciennement l'option « Block AI bots », est le plus courant) qui refuse discrètement ces mêmes crawlers en périphérie. Pour vous comme pour le propriétaire du site, tout semble en ordre ; pour le moteur d'IA, le site est invisible. L'audit GEO exécute désormais un contrôle d'accessibilité en direct à côté de la revue du robots.txt : il demande votre page d'accueil et une page de contenu tirée de votre sitemap en se présentant comme chaque crawler d'IA, et indique, page par page, si la requête est réellement passée. La deuxième page compte, car certains blocages ne s'appliquent qu'à certaines pages : depuis le 15 septembre 2026, le réglage par défaut de Cloudflare bloque les crawlers d'agents et d'entraînement uniquement sur les pages qui affichent des publicités, si bien qu'une page d'accueil seule peut sembler dégagée. Ce contrôle est informatif par défaut : il ne lève une alerte que lorsque notre requête de test reçoit un refus net (un HTTP 403/406), pour que vous n'ayez pas de fausses alertes dues à une limitation de débit ordinaire ou à des erreurs passagères. La sonde envoie le nom de chaque crawler depuis nos propres serveurs, pas depuis les adresses IP publiées par le crawler, et de nombreux pare-feu refusent de telles requêtes non vérifiées tout en laissant entrer les vrais crawlers : un refus est donc un indice fort, pas une preuve. Lorsque notre requête de test est refusée en périphérie, l'audit nomme le crawler concerné pour que vous puissiez le transmettre directement à l'équipe d'hébergement ou de sécurité du client. La leçon qu'il traduit : « autorisé dans robots.txt » et « accessible en pratique » sont deux choses différentes, et la visibilité IA exige les deux. Vous le verrez à deux endroits concrets. Dans l'audit GEO, une carte « Pare-feu et politique d'accès » détaille la situation crawler par crawler : ce que dit robots.txt à côté de ce que la sonde en direct a trouvé, avec un verdict clair pour chacun. « A refusé notre test » est celui à examiner : robots.txt autorise le crawler, mais la périphérie a quand même refusé notre requête de test. C'est l'indice d'un blocage plutôt qu'une preuve, car nos requêtes de test portent le nom du crawler mais viennent de nos serveurs, et de nombreux pare-feu refusent de telles requêtes tout en laissant entrer les crawlers vérifiés. Consultez les journaux de votre CDN ou de votre pare-feu pour y chercher des requêtes provenant des plages d'IP publiées des crawlers, afin d'en avoir le cœur net. La carte couvre les huit crawlers auxquels un blocage peut être attribué : les crawlers de recherche (OAI-SearchBot, PerplexityBot, Googlebot, meta-webindexer de Meta AI), les fetchers d'agents en direct (ChatGPT-User, Claude-User, Perplexity-User) et ClaudeBot, et elle est reprise dans le rapport, les liens partagés et le PDF. Par ailleurs, si vous avez branché l'ingestion des journaux de crawl, la page Insights de crawl lève une alerte de blocage WAF, doublée d'un signal dans votre boîte de réception, dès que le trafic réel des crawlers d'IA commence à recevoir des HTTP 403/406. « Réel » s'entend littéralement : les requêtes qui ne font qu'emprunter le nom d'un crawler d'IA (une IP en dehors des plages publiées par l'opérateur, ou un nom réservé à robots.txt comme Google-Extended ou Applebot-Extended, que Google et Apple n'envoient jamais) sont écartées, car un pare-feu qui les refuse fait son travail ; l'alerte les liste à part. Parmi les blocages qu'elle compte, elle indique combien viennent des plages d'IP publiées de l'opérateur et combien n'ont pas pu être vérifiés (la plupart des opérateurs d'IA ne publient pas de plages, donc il peut très bien s'agir du vrai crawler). Trois autres cas ne déclenchent plus l'alarme depuis le 27 septembre 2026, après qu'un client a retracé une alarme rouge jusqu'à son pare-feu qui refusait des scanners de vulnérabilités : les refus sur des chemins de scanner comme /.env ou /wp-config.php (une sonde reste une sonde, quel que soit le nom qu'elle se donne), les requêtes d'IP qui ont utilisé les noms de crawlers de deux opérateurs d'IA différents ou plus dans la fenêtre (aucune IP de vrai crawler ne se réclame à la fois d'OpenAI et d'Anthropic : c'est un seul scanner qui fait tourner les user agents), et l'alarme est rétrogradée en simple note informative « non vérifié » lorsque les éléments contredisent une règle sur les bots : tous les crawlers dont les plages d'IP sont publiées sont passés, ou tous les refus sont des HTTP 406, signature d'une règle sur le motif de la requête comme ModSecurity plutôt que d'une règle sur l'identité. La carte affiche la répartition 403/406 pour la même raison. Vous repérez donc un blocage en périphérie de deux façons : par un audit à un instant donné, et par le trafic réel entre deux audits. Depuis le 15 septembre 2026, ce constat a une cause courante qu'il vaut la peine de connaître. À partir de cette date, Cloudflare bloque par défaut les crawlers qu'il classe comme Agent (ChatGPT-User, Claude-User et Perplexity-User, les fetchers qui agissent en direct quand un assistant répond à une question sur vous) et comme Training (GPTBot, ClaudeBot et autres) sur les pages qui affichent des publicités, pour les nouvelles zones, les nouveaux sites de clients existants et chaque zone du forfait Free, tandis que les crawlers de recherche seule comme OAI-SearchBot restent autorisés. Les crawlers qui servent à la fois la recherche et l'entraînement sont bloqués par la même règle (Cloudflare cite Googlebot, Applebot et Bingbot) : sur ces pages, un site peut donc aussi perdre sa couverture dans Google Search et AI Overviews. Cela ne change rien à nos scans (nous appelons les API des moteurs), mais un site qui a ainsi perdu ses fetchers d'agents répond dans le vide aux assistants. La sonde en direct couvre donc les trois classes, si bien que ce schéma apparaît comme « A refusé notre test » sur les lignes des agents et de l'entraînement, généralement aussi sur Googlebot, alors qu'OAI-SearchBot passe. Quand les réponses portent les marqueurs de périphérie de Cloudflare, le constat nomme la cause et vous renvoie vers Cloudflare → AI Crawl Control (ou une règle de contournement WAF). Sans ces marqueurs, il garde la formulation générique et attribue un demi-point au lieu d'un échec : l'audit n'affirme jamais Cloudflare sans l'avoir vu. Le schéma par défaut de Cloudflare est l'exception à « un indice, pas une preuve » : des crawlers d'agents et d'entraînement refusés alors que les crawlers de recherche seule passent correspondent à une politique documentée qui s'applique aussi aux crawlers vérifiés ; ce cas reste donc un échec. Un test anti-bot qui frappe notre propre requête d'audit est signalé comme non concluant de notre point de vue, jamais comme un blocage des crawlers. Un autre signal de robots.txt mérite d'être surveillé : une carte « Politique d'utilisation du contenu » apparaît lorsque votre site publie la directive Content-Signal de Cloudflare (search / ai-input / ai-train = yes/no). C'est un signal de préférence, pas un contrôle appliqué : aucun moteur de réponse n'est confirmé comme la respectant et Google a dit publiquement qu'il l'ignore. Elle n'affecte donc jamais votre score GEO et ne change pas, à elle seule, le fait que vous soyez cité ou non. Nous la faisons apparaître pour une seule raison : Cloudflare a ajouté automatiquement des valeurs par défaut à des millions de fichiers robots.txt gérés, de sorte que votre site peut annoncer ai-input=no (demander aux moteurs d'IA de ne pas utiliser votre contenu comme entrée en direct pour leurs réponses) sans que personne l'ait choisi. Si vous visez la visibilité IA, c'est l'inverse de ce que vous voulez : la carte le signale (et note quand cela ressemble à la valeur par défaut de Cloudflare) pour que vous puissiez régler ai-input=yes ou supprimer la ligne. Elle est aussi disponible comme dimension de rapport « Politique d'utilisation du contenu ». (ai-train=no est un refus légitime de l'entraînement sans effet sur les citations dans les réponses en direct : la carte le dit, et ne le signale jamais.)

Ouvrez le projet Visibilité IA d'un client, allez dans Audit GEO : le domaine est prérempli à partir du site enregistré du client. Cliquez sur Lancer l'audit et CrunchJunkie vérifie robots.txt, llms.txt, le sitemap et un échantillon représentatif de pages : la page d'accueil plus une page par section du site, en privilégiant les pages plus profondes, pour que les articles de blog et les pages produit soient jugés, pas seulement le premier niveau. La liste des pages vient de tous les sitemaps que le site publie, y compris les index de sitemaps et les sitemaps déclarés dans robots.txt, et des liens de la page d'accueil lorsqu'il n'y a pas de sitemap. Une page de l'échantillon qui refuse ou fait échouer notre requête (403, 429, erreur serveur) est écartée plutôt que notée ; une 404 reste, car une URL morte dans votre propre sitemap est un constat. Les résultats sur la page sont agrégés honnêtement sur l'échantillon (« 3/6 pages échantillonnées réussissent »), et la section Résultats par page détaille les mêmes contrôles page par page : un résultat mitigé se ramène donc toujours à la page exacte à corriger. Chaque exécution est enregistrée, vous pouvez donc relancer un audit après vos modifications et voir le score bouger : la bande d'historique montre chaque instantané avec sa date. L'audit se relance aussi automatiquement, chaque semaine par défaut, car les signaux sur le site évoluent lentement et chaque audit lit des pages du site du client. Vous pouvez passer un projet à des réaudits quotidiens dans son onglet Paramètres, et un Lancer l'audit manuel reste toujours possible. Les exécutions automatiques sont de simples lectures de pages, sans contrôle par IA : elles ne coûtent donc jamais rien. Si la page d'accueil n'est pas le site au moment de l'audit, l'audit le dit au lieu de présenter un score. Cela couvre une page de suspension d'hébergement, un domaine expiré ou parqué, une page serveur par défaut, une erreur serveur et une page d'accueil qui ne répond pas. La page indique ce que le serveur a affiché et propose de relancer l'audit, avec un lien vers le dernier audit du site en ligne. Le score est affiché barré comme non comparable, et aucun correctif ni aucun insight IA n'en est tiré, car ils décriraient la page provisoire plutôt que le site. Un tel audit ne déclenche aucune alerte de score (c'est le signal distinct « Le site n'est pas servi » qui s'en charge), et les rapports et les content briefs utilisent à la place le dernier audit du site en ligne. L'API et le connecteur CrunchJunkie renvoient l'audit avec un champ homepageUnavailable qui indique ce que le serveur a affiché. Les contrôles qui ont bien tourné restent à un clic, sous « Afficher ce qui a été mesuré sur cette page ». Comme l'audit ne reflète que les signaux sur le site, il ne voit pas les facteurs hors site qui jouent aussi sur la visibilité IA (mentions de la marque sur le web, présence sur Reddit/Wikipedia) ni si un modèle a été entraîné sur votre contenu. Lisez un score élevé comme « ce site est bien positionné pour être cité », et associez-le à l'onglet Visibilité pour voir si ce positionnement se traduit par de vraies mentions dans l'IA.

La plupart des crawlers d'IA récupèrent une page par une simple requête HTTP et n'exécutent pas le JavaScript (les crawlers d'OpenAI, d'Anthropic et de Perplexity ne sont pas documentés comme le rendant) : tout ce qu'un site affiche dans le navigateur après le chargement leur est donc invisible. Google fait exception : Googlebot rend dans Chromium headless chaque page qui répond 200 et n'est pas en noindex, mais plus tard, dans une file de rendu, et AI Overviews et le mode IA ne renvoient que vers des pages indexées et éligibles à un extrait. Le rendu côté serveur sert à tous les moteurs le contenu dès la première récupération. L'audit le vérifie directement. Le contrôle du signal SSR mesure la quantité de contenu réel dans le HTML initial (les mots présents dans le <body> brut avant toute exécution de JavaScript) : il réussit quand la quantité est significative, signale un partiel quand il y en a peu, et échoue sur une coquille vide. Le contrôle « côté client uniquement » cherche les empreintes d'un framework de single-page app (React, Next.js, Vue, Nuxt, Angular, Svelte et d'autres) posé sur un corps initial presque vide, le schéma classique d'un site qui s'affiche très bien pour les personnes mais ne renvoie presque rien à un crawler. Être rendu côté serveur ne fait cependant que la moitié du chemin pour être lisible par une machine : la page doit aussi permettre au crawler de distinguer le contenu principal de la navigation, de l'en-tête et du pied de page. L'audit cherche un repère sémantique de contenu principal (un élément <main> ou <article>, ou role="main") : avec un tel repère, un crawler isole en une seule étape le contenu qui mérite d'être cité ; sans lui, une page construite uniquement avec des <div> génériques oblige le moteur à deviner quel bloc est la réponse. C'est une incitation douce, jamais un échec définitif, et le correctif consiste à envelopper le contenu principal dans <main>. L'audit vérifie aussi la présence d'un noindex dans la balise meta robots : si une page porte <meta name="robots" content="noindex">, elle demande aux moteurs de recherche et de réponse IA de l'écarter entièrement ; c'est donc signalé avec le correctif exact. Ensemble, ces contrôles détectent les raisons techniques pour lesquelles une page parfaite dans un navigateur peut rester pratiquement invisible pour l'IA.

En plus du score GEO composite, chaque audit produit désormais un sous-score distinct de maturité pour les agents (Agent Readiness) sur 100. Là où le score GEO porte sur le fait d'être exploré et cité, la maturité pour les agents concerne la classe plus récente des agents d'IA : les fetchers d'assistants en temps réel et les appelants d'outils qui agissent en direct pour le compte d'un utilisateur. Elle note trois signaux concrets et maîtrisables : robots.txt laisse-t-il passer les user agents d'agents en temps réel (ChatGPT-User, Claude-User, Perplexity-User, Gemini Deep Research et similaires) ; votre contenu est-il lisible sans JavaScript (les agents récupèrent le HTML brut et n'exécutent généralement pas le JS) ; et l'étendue de vos données structurées (combien de types schema.org distincts vous exposez à un agent pour qu'il les lise). En bref, elle vérifie si les agents d'IA peuvent accéder à votre site, le lire sans JavaScript et lire ses données : ce sont les préconditions, pas un test prouvant qu'un agent peut mener une tâche à bien. Une étude de MERJ (septembre 2026) montre pourquoi la différence compte : une page peut passer tous les contrôles de maturité alors qu'un agent échoue quand même à la tâche sur cette page. Chacun de ces contrôles comporte un bouton « Rédiger la correction avec Crunch », exactement comme l'audit principal. Ce sous-score est volontairement séparé, et non intégré à votre score GEO, pour deux raisons : c'est un domaine émergent, et l'un de ses signaux, un descripteur d'interface d'agent à /.well-known/mcp.json, suit une convention (MCP) encore en cours de normalisation. Le contrôle de ce descripteur est purement informatif : si nous en trouvons un, nous le signalons comme un positionnement tourné vers l'avenir et affichons un badge « Endpoint MCP détecté », mais son absence ne fait jamais baisser votre sous-score. Rien ici ne pénalise un site de ne pas avoir adopté une convention pré-normalisée. Le garder séparé signifie aussi que vos scores GEO passés restent directement comparables dans le temps. Deux contrôles suivent Lighthouse de Google, qui a ajouté un groupe Agent Discoverability à sa catégorie Agentic Browsing dans la version 13.5 (septembre 2026) et l'amène dans PageSpeed Insights, de sorte que le verdict corresponde à ce qu'un client voit dans Chrome DevTools. Le premier est Agent Resource Discovery. Nous cherchons un ai-catalog.json comme le fait Lighthouse : une ligne Agentmap dans robots.txt, une balise link rel="ai-catalog", un en-tête Link, puis /.well-known/ai-catalog.json. S'il y en a un, nous le vérifions selon les règles ARD 1.0 que Lighthouse applique (version de la spécification, entrées, identifiants urn:air:, nom d'affichage, type, exactement l'un de url ou data). La spécification ARD actuelle (v0.91, 26 août 2026) a renommé le fichier en ard.json et le lien en rel="ard" ; Lighthouse 13.5 ne les lit pas encore, nous cherchons donc les deux formes, ard.json d'abord, et le résultat indique laquelle a été trouvée et si Lighthouse la verra. Un ard.json n'a pas besoin de version de spécification. Comme le descripteur MCP, il est informatif, et ne pas en publier est acceptable ; Lighthouse le marque lui aussi comme non applicable. La seule chose que nous n'exécutons pas est la passe supplémentaire de validation stricte par schéma JSON de Lighthouse, et le contrôle le dit. Un troisième contrôle de ce groupe, « Markdown for agents », demande à la page d'accueil de se présenter elle-même avec un en-tête Accept: text/markdown, comme le font désormais les agents de Vercel, Cloudflare et d'autres, et indique si le site répond par une version Markdown (Content-Type text/markdown, idéalement avec Vary: Accept pour que les caches gardent les deux séparées) ou par la page HTML ; si la page annonce un jumeau Markdown avec un link rel="alternate" type="text/markdown", la voie qu'emprunte Applebot, ce jumeau est récupéré et jugé lui aussi. Il est affiché à titre indicatif et jamais noté : aucun moteur de réponse n'a confirmé qu'une réponse Markdown influence les citations, il est donc formulé comme llms.txt, une hygiène de lisibilité pour les agents, peu coûteuse, que des hébergeurs comme Vercel et Cloudflare peuvent activer sans modification de contenu. Le second contrôle Lighthouse est la validité de llms.txt dans la section llms.txt, qui applique désormais les trois règles de Lighthouse : un H1, au moins un lien, et au moins 50 caractères.

Chaque audit produit aussi un sous-score distinct de balisage d'entité (Entity markup) sur 100, une lecture de la solidité de votre graphe d'entités schema.org. Il mesure uniquement le balisage de votre site, pas la notoriété ni l'autorité de votre marque : une marque célèbre sans schéma Organization obtient quand même un score bas. Là où la catégorie « Données structurées » du score composite demande « y a-t-il un schéma, quel qu'il soit », le balisage d'entité pose la question plus précise de savoir si le site indique lui-même qui est derrière lui (les signaux de type E-E-A-T) : une Organization complète (name, url, logo et un tableau sameAs), des liens vers des profils externes faisant autorité (LinkedIn, Crunchbase, Wikidata, réseaux sociaux officiels ; trois ou plus constituent un signal fort), les personnes nommées derrière la marque (un fondateur ou des auteurs d'articles déclarés comme entités Person), et une vraie attribution d'auteur sur vos articles. N'utilisez que de vraies personnes : les consignes de Google sur le contenu utile (mises à jour le 1 octobre 2026) considèrent les profils de créateurs fabriqués comme une forme de tromperie, et l'audit lit votre balisage sans pouvoir vérifier qu'une personne nommée existe. Il est déterministe (il ne lit que les données structurées que vous publiez réellement, sans jamais deviner un type de schéma à partir du texte de votre page) et honnête : si les pages échantillonnées ne comportent aucun nœud article, l'attribution d'auteur est marquée « non notée » plutôt que comptée contre vous (et BlogPosting compte comme un Article, donc un blog n'est jamais signalé à tort comme « Article manquant »). Comme la maturité pour les agents et Local GEO, il reste en dehors du score GEO principal, pour que votre historique reste comparable, et chaque écart comporte un bouton « Rédiger la correction avec Crunch ». Vous le verrez aussi comme dimension de rapport « Balisage d'entité » qui est reprise dans les liens partagés et le PDF. Un chemin de diagnostic mérite d'être connu : les équipes dotées d'un solide SEO technique (schéma propre, robots.txt correct) sont régulièrement surprises par une faible visibilité IA, car les moteurs de réponse pèsent plus que la conformité du balisage. Si vos contrôles de données structurées réussissent mais que la visibilité reste faible, regardez ici ensuite : un graphe d'entités mince (pas de profils sameAs, pas de personnes nommées, pas d'attribution d'auteur) est une raison courante pour laquelle les moteurs ne parviennent pas à établir qui vous êtes et s'il faut faire confiance à une citation. Et après cela, l'écart ne se situe généralement plus sur le site mais dans l'autorité hors site, que les vues Domaines et Analyse des écarts mesurent directement.

Si un client est une entreprise locale (un commerce, un restaurant, une clinique, un artisan, tout ce qui a un lieu physique ou une zone d'intervention), activez « Ce client est une entreprise locale » dans l'onglet Visibilité IA → Paramètres. L'audit GEO produit alors un sous-score distinct de Local GEO sur 100, à côté du score GEO composite et du score de maturité pour les agents. Comme la maturité pour les agents, il reste en dehors de votre score GEO principal (un SaaS sans schéma LocalBusiness ne doit pas être pénalisé pour cela), pour que votre historique reste comparable. Local GEO note les signaux sur le site qui font ressortir une entreprise dans les réponses IA à intention locale (« meilleur fleuriste près de chez moi », « plombier à Berlin ») : le schéma LocalBusiness et son degré de complétude, le nom, l'adresse et le téléphone affichés en vrai texte et conformes au schéma, un lien vers votre Fiche d'établissement Google, des pages de lieux dédiées, votre ville et votre région nommées dans les titres et les intertitres, le balisage des avis, une carte intégrée et des liens vers des annuaires réputés. Il reste honnête : si vous n'avez pas défini de ville cible, il indique « non évalué » plutôt que de vous faire échouer, et il ne récompense jamais les pages de lieux dupliquées où seule la ville change. Deux champs affinent les contrôles. Renseignez la Ville principale et la Région du client pour que l'audit puisse confirmer que vous nommez l'endroit où vous opérez, et collez l'URL de la Fiche d'établissement Google, le lien d'entité qui rattache votre site à votre fiche Maps et l'un des signaux locaux les plus forts. Pour trouver cette URL : ouvrez Google Maps, cherchez l'entreprise, ouvrez sa fiche, cliquez sur Partager et copiez le lien (il ressemble à https://maps.app.goo.gl/… ou https://www.google.com/maps/place/…). Lancez ensuite l'audit pour voir la carte Local GEO, avec un bouton « Rédiger la correction avec Crunch » sur chaque problème, comme dans l'audit principal.

Chaque problème que l'audit lève s'accompagne d'une explication en langage clair de ce qui a été trouvé et de la façon de le modifier. Pour ceux dont vous préférez ne pas rédiger le correctif vous-même, chaque problème a un bouton « Rédiger la correction avec Crunch ». Cliquez dessus et Crunch rédige un correctif concret, prêt à copier-coller, pour ce problème précis, fondé sur le constat réel et la page auditée, pas sur des conseils génériques, avec un bouton Copier pour le reprendre directement dans un ticket ou le remettre au développeur du client. Le correctif rédigé est généré à la demande pour le problème que vous avez sous les yeux et n'est pas enregistré dans l'audit ; relancez-le quand vous voulez. Comme le reste de Crunch, il a besoin d'un modèle d'IA disponible (Managed AI ou votre propre clé). Il transforme l'audit d'une liste de problèmes en une liste de modifications rédigées. Considérez chaque brouillon comme un point de départ : relisez-le et modifiez-le avant de le publier, en remplaçant les éventuels espaces réservés par vos vraies valeurs. Les consignes de Google sur le contenu d'IA générative (mises à jour le 1 octobre 2026) citent les titres, les meta descriptions, les données structurées et les textes alternatifs comme des endroits où un texte généré non relu peut mal tourner. Les problèmes Organization et sameAs sont traités différemment, car ils portent sur des faits qu'un modèle ne peut pas connaître. Pour eux, Crunch lit votre page d'accueil et les pages à propos, contact et mentions légales vers lesquelles elle renvoie, et construit un bloc connecté à partir de ce qui s'y trouve : une Organization, le WebSite qu'elle publie et la page d'accueil, reliés par @id. Votre nom et votre logo viennent de votre propre balisage ou de vos balises ; si le site n'indique aucun nom nulle part, le nom de marque que vous avez donné au projet est utilisé, mais seulement si le titre de votre page d'accueil le confirme. Sur un site dont la racine redirige vers un dossier de langue comme /de, l'entrée de la page d'accueil décrit la page effectivement lue. sameAs ne contient que des liens de profils présents sur votre site : déclarés dans votre balisage, ou liés depuis les pages lues. Un profil lié depuis une seule page interne est listé comme écarté, jamais supposé vous appartenir, et il n'y a aucun espace réservé à remplir. Sous le bloc, vous voyez d'où vient chaque valeur et ce qui a été écarté volontairement. Ce chemin n'a besoin d'aucun modèle d'IA. Chaque bloc est vérifié avant que vous le voyiez : le JSON doit être analysable, et chaque type et chaque propriété doivent exister dans le vocabulaire schema.org actuel et figurer sur un type qui les autorise. La même vérification s'applique à tout JSON-LD contenu dans un correctif rédigé par un modèle, et le résultat est affiché sous le brouillon. Elle ne remplace pas le Rich Results Test de Google, qui vérifie aussi les formats de valeur et les champs requis sur la page en ligne. Un problème a son propre bouton dédié. Quand le contrôle /llms.txt ne réussit pas, la catégorie llms.txt affiche Générer llms.txt avec Crunch : il rédige un /llms.txt de départ complet à partir de la structure PROPRE du site (les vraies URL de son sitemap.xml plus le titre et la description de la page d'accueil), regroupées en sections avec une courte description par lien. Chaque lien est une vraie page du site, jamais une page inventée ; enregistrez le résultat à la racine de votre domaine sous le nom /llms.txt après une relecture rapide.

Le même moteur d'audit alimente aussi une version publique et gratuite, à l'adresse crunchjunkie.io/products/geo-audit, sans connexion ni compte. N'importe qui peut saisir un domaine et obtenir en quelques secondes le score de 0–100, la répartition par catégorie et une liste de correctifs priorisée. C'est pratique pour les agences : lancez un contrôle GEO rapide sur le site d'un prospect avant un pitch, ou envoyez le lien pour qu'un client voie lui-même le problème. L'outil public est limité en débit et ne lit que les pages publiques et robots.txt. Tout le reste de ce guide (le réaudit hebdomadaire, les résultats par page, le benchmark des crawlers concurrents, la maturité pour les agents, Local GEO et la rédaction des correctifs) correspond à la version dans l'application, qui suit en plus le score dans le temps au sein du projet du client. Deux guides longs vont plus loin si vous voulez remettre au client le raisonnement : « How to run a GEO audit: the complete 2026 checklist » et « GEO audit vs SEO audit », tous deux sur le blog CrunchJunkie. Chaque audit gratuit dispose d'une page de résultat permanente (crunchjunkie.io/products/geo-audit/r/<id>) avec une image de partage, pour qu'un visiteur puisse publier ou transférer le score, les deux sous-scores autonomes et la liste des correctifs. Les pages de résultat ne sont pas indexées par les moteurs de recherche, n'affichent jamais l'e-mail du visiteur, et chacune renvoie directement vers le contrôle gratuit de visibilité IA pour le même domaine. C'est la suite logique et honnête, car un score GEO trouve des blocages et ne prédit pas la fréquence à laquelle les moteurs nomment une marque.