Documentation
Audit SEO
Explorez le site web d'un client avec notre propre crawler, vérifiez d'abord que les crawlers d'IA peuvent l'atteindre et le lire, et corrigez les problèmes dans l'ordre de ce que valent les pages concernées.
Ce que fait l'audit SEO
L'audit SEO explore le site web propre d'un client et vérifie chaque page atteinte avec 189 contrôles. Ouvrez un client et choisissez Audit SEO sous Site web et robots. La recherche IA passe en premier : les crawlers d'IA ont-ils le droit de récupérer les pages selon robots.txt, un pare-feu les refuse-t-il alors que robots.txt les autorise (nous envoyons pour cela une requête de test à la page d'accueil avec le user-agent publié de chaque crawler d'IA), les journaux du serveur montrent-ils qu'ils sont refusés, et les pages que les réponses IA citent déjà fonctionnent-elles encore. Viennent ensuite les contrôles classiques : crawlabilité et indexabilité, redirections, canoniques, titres et balises meta, contenu, liens internes, sitemaps, HTTPS, réglages internationaux, données structurées, performance et HTML.
Chaque problème est classé selon ce que valent les pages concernées pour le client, et non selon le nombre de pages touchées. Chaque contrôle indique le fondement sur lequel il repose (une norme ou la documentation d'une plateforme, une convention émergente ou une heuristique) et une source que vous pouvez ouvrir, et seul un comportement documenté peut produire une Erreur. Une configuration correcte n'est jamais un constat, et une page que nous n'avons pas pu mesurer est non évaluée, et non en échec.
L'audit GEO reste un outil distinct : il évalue en quelques secondes un petit échantillon de pages pour leur maturité vis-à-vis de la recherche IA. L'audit SEO est un crawl complet.
Lancer un audit
Cliquez sur Lancer l'audit. La première fois, vous confirmez que vous êtes autorisé à auditer le site web au nom de son propriétaire ; la confirmation est conservée avec la personne qui l'a donnée, la date et l'hôte concerné, et elle est redemandée quand le site web du client change. Seul le site web propre du client est exploré, avec et sans www. L'URL de départ peut être n'importe quelle page https du site ; une page de départ qui redirige vers un autre site arrête le crawl.
Dans les paramètres, Paramètres à ignorer accepte jusqu'à 100 noms de paramètres d'URL, un par ligne, sur le même principe qu'une règle de paramètres d'URL dans d'autres crawlers. Une URL que le crawler trouve avec l'un d'eux, dans un lien, un sitemap, la Search Console ou ailleurs, est crawlée sans lui : avec topic dans la liste, /contact/?topic=a et /contact/?topic=b sont une seule page, /contact/, demandée une fois et comptée une fois. Les noms sont comparés sans tenir compte de la casse, et la valeur ne compte jamais : page retire page=1, page=2 et toute autre valeur. L'URL n'est jamais écartée, seul le paramètre l'est, et l'URL de départ est crawlée telle que vous l'avez saisie. Ajouter les paramètres de suivi courants remplit les paramètres UTM et les identifiants de clic de Google, Meta et Microsoft. La liste est vide par défaut, rien n'est donc ignoré sans que vous l'ajoutiez ; elle ne coûte rien, s'applique à partir du prochain crawl, et chaque crawl garde la liste avec laquelle il a tourné.
Notre crawler s'identifie comme CrunchJunkieSiteAudit, lit robots.txt avant toute page, le respecte (il n'existe aucune dérogation), demande au plus une page par seconde et suit un Crawl-delay allant jusqu'à 10 secondes. Il conserve ce dont l'audit a besoin, comme les codes d'état, les titres et les liens, et jamais le texte des pages. Après les pages, il vérifie les scripts, les feuilles de style et les images qu'elles utilisent ainsi que les pages externes vers lesquelles elles pointent, avec une requête légère chacun, et sur un autre site web uniquement ce que le robots.txt de ce site autorise. crunchjunkie.io/bot décrit le crawler pour les propriétaires de sites et explique comment l'autoriser ou le bloquer. Lorsque le pare-feu d'un site répond 429 ou 503, le crawler ralentit et attend ce que le site demande, jusqu'à 10 minutes à chaque fois, et le crawl en cours l'indique : s'il reste lent, demandez à l'hébergeur d'exempter le user agent CrunchJunkieSiteAudit de la limite de débit, à l'aide de la section de cette page sur l'autorisation de notre crawler. Un crawl qui ne peut pas mesurer le site s'arrête et dit pourquoi : robots.txt répond par une erreur serveur (selon la RFC 9309, tout le site compte alors comme fermé), une page d'attente de l'hébergeur s'affiche à la place du site, ou plus de 20 % des requêtes récentes sont refusées. Arrêter met fin à un crawl en cours, puis conserve et analyse ce qu'il a récupéré.
Les pages sont incluses dans votre forfait et rien n'est facturé. Chaque espace de travail dispose d'un quota de pages par période de facturation (le mois civil en UTC sans abonnement) : Solo 5 000, Starter 25 000, Pro 100 000, Agency 250 000, Scale 1 000 000 pages. Un essai dispose de 1 000 pages, au plus 500 par crawl. Chaque page interne que nous demandons compte, quelle que soit sa réponse ; les URL fermées par robots.txt, les scripts, les feuilles de style, les images, les liens externes et le test des crawlers d'IA ne comptent pas. Un crawl réserve sa limite de pages au démarrage et rend à la fin ce qu'il n'a pas utilisé : un crawl qui ne tient pas dans ce qu'il reste ne peut donc pas démarrer. Un crawl demande au plus 5 000 pages et un client peut être audité 5 fois par jour (UTC) ; la boîte de dialogue Lancer l'audit indique la limite de pages, le quota restant et la fin de la période.
Lire la Santé du site et la Santé en recherche IA
La Santé du site est la part de pages sans Erreur : les pages sans Erreur divisées par les pages évaluées, comptées une fois sur l'ensemble du crawl, et toujours affichées avec les deux nombres et la date du crawl (« 1 018 pages sur 1 240 sans erreur »). Une page est évaluée quand nous l'avons demandée et qu'elle a répondu, quel que soit son état. Les URL qui nous sont fermées par robots.txt ou qui refusent notre crawler sont écartées et comptées à côté du score, car une page que nous n'avons pas pu voir n'a pas échoué. Les avertissements et les notices ne le font jamais bouger.
La Santé en recherche IA est la même part, calculée uniquement sur les erreurs de recherche IA. Les deux ne sont jamais moyennées en un seul nombre, pas plus qu'avec le score GEO. Les erreurs qui touchent tout le site, comme un certificat expiré, un robots.txt qui répond par une erreur serveur ou un pare-feu qui refuse les crawlers d'IA, sont nommées à côté des scores au lieu d'être comptées comme des pages ; elles passent toujours en premier dans la liste des corrections.
Priorités et valeur des pages
Chaque page reçoit un niveau de valeur. Une page clé (V1) est la page d'accueil, une page qu'une réponse IA a citée au cours des 30 derniers jours, l'une des pages du plus petit ensemble qui rapporte 80 % des clics Google du client sur 28 jours, ou une page dans le top 10 d'un mot-clé suivi lors de la dernière exécution du Rank Tracker. V2 est toute page avec des impressions dans la Search Console, une position dans le top 20, des visites de crawlers d'IA dans les journaux du serveur ou une place dans un sitemap ; V3 est le reste. Sans Search Console ni données de visibilité IA, les niveaux ne viennent que de la structure du site, et la page le dit.
P1 est une Erreur sur une page clé ou une Erreur qui touche tout le site, P2 une Erreur sur une autre page ou un Avertissement sur une page clé, P3 tout le reste. Un problème prend la meilleure priorité de ses pages, et les problèmes sont triés par priorité, puis par clics Google sur les pages concernées, puis par réponses IA qui les citent, puis par nombre de pages concernées. Chaque problème dit en une ligne pourquoi il est à cette place.
Les colonnes de valeur portent sur les pages concernées, jamais sur ce qu'une correction récupérerait : clics et impressions Google issus de la Search Console sur 28 jours (jours du Pacifique, avec les propriétés lues), réponses IA qui citent les pages sur les 30 derniers jours UTC entiers (chaque réponse comptée une seule fois même si elle cite deux pages concernées ; seuls comptent les moteurs qui nomment des pages, donc Gemini, qui nomme des sites, est écarté), et mots-clés suivis dans le top 20 lors de la dernière exécution du Rank Tracker. Chaque chiffre porte sa fenêtre et sa base. Une source non connectée affiche « non connecté », jamais zéro. Les données sont rattachées sans les paramètres : les chiffres d’une page sont donc comptés une seule fois, sur une URL, celle sans paramètres ou, si seules des variantes avec paramètres ont été crawlées, l’une d’elles. Toute autre variante avec paramètres (par exemple /check?domain=x), qu’elle ait été récupérée ou bloquée par robots.txt, et une page dont le canonical pointe vers une autre URL de la même page n’affichent pas de chiffres propres ; la page nomme l’URL où ils sont comptés. Une telle variante n’est jamais une page clé et ne déclenche aucun problème fondé sur sa valeur, comme « Bloquée par robots.txt, mais avec du trafic de recherche ou d'IA » ; un simple blocage par robots.txt reste signalé.
Problèmes, Pages et Comparer
La Vue d'ensemble montre les deux scores, les erreurs qui touchent tout le site, ce qui a changé depuis le crawl précédent, les clics sur les pages avec erreurs, les problèmes à corriger en premier et une carte par catégorie. Problèmes liste chaque problème, avec des filtres par catégorie, gravité et priorité ; ouvrez-en un pour voir ce que c'est, pourquoi c'est important, comment le corriger, son fondement et sa source, ainsi que les pages concernées avec leurs chiffres de valeur et le détail de chaque constat, comme la cible et l'ancre d'un lien cassé ou les sauts d'une chaîne de redirections. Les notices sont de l'information et ne comptent jamais dans un score.
Pages liste chaque URL du crawl avec son état, son indexabilité, sa profondeur, les liens qui pointent vers elle, ses problèmes, son niveau de valeur et ses chiffres de valeur, avec des filtres et une vue de page qui montre la règle robots.txt que rencontre chaque crawler d'IA. Les deux listes s'exportent en CSV, avec les fenêtres des chiffres de valeur dans le fichier. Les problèmes signalés s'exportent aussi, tous depuis l'onglet Problèmes ou un seul depuis son propre panneau, en CSV, Excel ou PDF. Les fichiers CSV et Excel listent chaque page concernée avec ce que le crawl y a trouvé et conservent les problèmes masqués et ignorés, signalés avec leur motif. Le PDF est un rapport lisible dans votre langue : les 20 premières pages de chaque problème (jusqu'à 500 pour un seul problème), chaque valeur avec sa fenêtre et une note indiquant que la liste complète se trouve dans le CSV ou dans l'Excel.
Comparer met un crawl en regard du crawl précédent de même périmètre, c'est-à-dire avec la même URL de départ, le même appareil et les mêmes paramètres ignorés. Un problème n'est corrigé que si sa page a été vérifiée dans les deux crawls et qu'elle est maintenant conforme ; une page que le nouveau crawl n'a pas vérifiée n'est pas revérifiée, jamais corrigée, et un problème sur une page que le crawl précédent n'avait jamais atteinte se trouve sur des pages nouvellement vérifiées, jamais nouveau. Les crawls d'un autre périmètre ne sont pas comparables, et la page en donne la raison au lieu de chiffres. Le détail des pages est conservé pour les derniers crawls ; les crawls plus anciens gardent leur résumé.
Vue de Google et suivi
Les Signaux Web essentiels viennent du Chrome UX Report : le 75e centile de vrais utilisateurs de Chrome sur 28 jours, pour l'URL ou, si elle a trop peu de trafic, pour toute l'origine, et chaque valeur indique son niveau et ses dates. Voir la tendance lit l'historique en direct sans l'enregistrer ; PageSpeed Insights se lance sur un clic (20 par jour et par client) et seul son score est conservé. Sans clé configurée, l'audit le dit et n'affiche aucune valeur.
L'inspection d'URL lit le verdict et la page canonique de Google via la Search Console du client, jusqu'à 100 des pages les plus précieuses par exploration, et davantage sur un clic. Elle utilise les 2000 inspections quotidiennes de cette propriété, partagées avec les autres outils du client. Les problèmes d'exploration actuels de Bing sont lus dans Bing Webmaster Tools lorsqu'il est connecté. Toutes ces vérifications reposent sur un échantillon ou un autre service : elles sont listées et classées, mais ne comptent jamais dans la Santé du site ni la Santé en recherche IA ; celle qui n'a pas tourné n'est pas vérifiée, jamais corrigée.
Le suivi des pages clés, désactivé par défaut, vérifie des pages choisies chaque jour (chaque heure à partir de Pro) par rapport à leur dernière réponse, sous le même robots.txt et au même rythme, hors du quota de pages. Un statut perdu, un nouveau noindex, une page canonique modifiée ou une page nouvellement fermée par robots.txt déclenche un signal ; un titre ou un H1 modifié, un signal plus discret ; une vérification sans réponse ne change rien, et une erreur serveur ne compte que si la vérification suivante la répète. Les vérifications sont conservées 90 jours.
Si le site ralentit l'audit ou le refuse
Un site peut se défendre contre un robot. Lorsqu'il répond à nos requêtes par un 429 (trop de requêtes) ou un 503 et demande au robot d'attendre, l'audit ralentit et se met en pause comme demandé, il dure donc plus longtemps, et le crawl indique à titre d'information « Le site a limité le débit de notre robot » (site_rate_limited). Rien n'est retenu contre le site sur les pages, et l'audit ne peut pas voir quelle limite les robots d'IA rencontrent en lisant ce même site. Une requête refusée ou arrêtée par un défi est affichée comme refusée, jamais comme une page cassée, et un crawl s'arrête lorsque plus de 20 % de ses requêtes récentes sont refusées.
Pour laisser passer notre robot, autorisez, dans le pare-feu, le CDN ou l'extension de sécurité qui applique la limite, les requêtes dont le user agent contient CrunchJunkieSiteAudit (par exemple Imunify360, Cloudflare ou une extension de sécurité WordPress). Nos requêtes viennent d'adresses cloud qui changent : autorisez donc par user agent, pas par adresse IP. Comment autoriser ou bloquer notre robot indique le user agent, la façon dont il traite le robots.txt et la règle à ajouter.
Agir sur ce que l'audit a trouvé
Masquez ou ignorez un problème, pour tout le site ou pour une page, avec un motif qu'un collègue peut lire. Un problème masqué disparaît des listes, de la liste des corrections et de ses Signals ; la Santé du site et la Santé en recherche IA le comptent toujours. Créer une tâche transforme un problème en tâche dans la file Approbations, avec un responsable, une échéance et les pages qu'elle nomme ; rien n'est envoyé nulle part.
Rédiger la correction avec Crunch écrit la correction exacte d'un problème sur une page (une balise, un bloc JSON-LD, des lignes de robots.txt, une règle de redirection) à partir de ce que le crawl a conservé, uniquement quand vous cliquez. Il n'affirme jamais que la correction fera monter les positions ou les citations, et il marque d'un espace réservé chaque valeur qu'il ne peut pas connaître. Chaque brouillon utilise un message Ask Crunch du quota mensuel de votre forfait et ne compte jamais dans vos contrôles. Un plafond de sécurité de 60 brouillons par espace de travail et par jour s'applique ; avec votre propre clé d'IA, il n'y a pas de compteur.
Une planification est désactivée tant que personne ne l'active. Vous choisissez hebdomadaire ou mensuelle, un jour et une heure en UTC, et vous acceptez le plafond par crawl et le maximum qu'un mois peut en consommer, que les réglages affichent avant l'enregistrement. Un crawl planifié s'exécute dans ce plafond et jamais au-delà du quota de pages ; une échéance que le quota restant ne couvre pas entièrement est ignorée, et non raccourcie, et une notice le signale.
Après chaque crawl, l'audit lève des Signals avec les deux dates de crawl et les pages évaluées comme base : nouvelles Erreurs sur des pages clés, une baisse de la Santé du site de 5 points ou plus entre deux crawls complets de même périmètre avec au moins 50 pages évaluées dans chacun, un crawler d'IA bloqué sur des pages clés, une page citée qui est cassée, un crawl que le site a refusé, un certificat sur le point d'expirer et un crawl planifié ignoré faute de pages. Une situation durable que le prochain crawl complet ne retrouve plus est résolue. Les automatisations peuvent agir sur tous.
Dans les rapports
Audit SEO est une source de rapport dans l'éditeur de rapports et dans Rédiger avec l'IA, rendue de la même façon dans l'application, sur un lien partagé et dans le PDF, dans la langue du rapport et sans notre marque dans un rapport en marque blanche. Ses KPIs sont la Santé du site et la Santé en recherche IA avec leur n, les pages évaluées, les problèmes en Erreur et en Avertissement, les problèmes corrigés et nouveaux depuis le crawl précédent, et les clics Google sur les pages avec erreurs avec leur fenêtre. Le graphique trace la Santé du site par crawl, avec la Santé en recherche IA à côté. Les tableaux sont les principaux problèmes, ce qui a été corrigé depuis le crawl précédent, l'accès des crawlers d'IA (robots.txt et notre requête de test par crawler) et les pages citées avec des problèmes.
Un rapport ne lance jamais de crawl. Il lit le dernier crawl terminé à la fin de la période du rapport ou avant, et indique « Au » suivi de la date de ce crawl ; un changement n'est affiché que par rapport à un crawl de même périmètre. Audit SEO n'est pas un canal : il ne fait donc jamais partie du mélange Tous les canaux.
Avec un assistant (MCP) ou l'API REST
Le connecteur donne à un assistant sept outils de lecture : get_site_audit, list_site_audit_issues, get_site_audit_issue, list_site_audit_pages, get_site_audit_page, compare_site_audits et get_site_audit_history. get_site_audit_issue renvoie aussi les faits et les règles qu'utilise le brouillon de correction dans l'application : votre assistant peut donc rédiger la correction lui-même, sans second appel d'IA. Cinq outils modifient quelque chose et affichent un aperçu avant que quoi que ce soit n'arrive : run_site_audit, stop_site_audit, update_site_audit_settings, set_site_audit_issue_status et create_site_audit_task. run_site_audit exige en plus l'interrupteur « Autoriser les actions qui consomment de l'IA » sous Paramètres → Connecter des assistants IA (MCP), car il lance un crawl qui consomme votre quota de pages : son aperçu indique les pages, le quota restant et la fin de la période. Le prompt guidé site_audit_triage transforme le dernier crawl en une liste de corrections ordonnée.
L'API REST (v1, portée lecture) propose les mêmes lectures sous /api/v1/clients/{id}/seo-audit : l'audit, les problèmes, un problème, les pages, une page (pages/detail?url=), la comparaison et l'historique.
Premiers pas Reporting Modèles de rapport Filtres, dimensions et comparaisons Partager et envoyer des rapports Marque blanche et personnalisation Glossaire des métriques Visibilité IA Vos propres clés d'API IA Perception Visibilité Shopping IA Audit GEO Robots d'IA et explorabilité Trafic IA depuis GA4 Rank Tracker Recherche de mots-clés Liens Surveillance Signaux et automatisations Intégrations Data Studio Connexion à Claude et ChatGPT (MCP) Connecter Claude Connecter Claude Code Connecter ChatGPT Connecter Cursor Connecter VS Code API REST Webhooks Authentification unique (SSO) Compte et facturation Données, confidentialité et sécurité L'assistant Crunch Parrainer un ami FAQ