Rapport findable-audit

Vérifie que /robots.txt existe et est servi en text/plain plutôt qu'en page HTML de repli. C'est le premier fichier que demandent les robots de recherche et d'IA pour savoir ce qu'ils peuvent explorer : s'il manque ou est mal servi, ils n'ont aucune politique d'exploration explicite ni de renvoi vers votre sitemap.

Contrôle que le robots.txt est syntaxiquement correct — texte brut, uniquement des directives reconnues (User-agent, Allow, Disallow, Sitemap…), et aucun Allow/Disallow avant la première ligne User-agent. Un fichier mal formé est interprété de façon imprévisible selon les robots, modifiant en silence ce qu'ils explorent.

Vérifie que le robots.txt ne bloque pas les robots de recherche classiques (Googlebot, Bingbot et le défaut *) à la racine. Un blocage à l'échelle du site pour ces agents fait disparaître le site de la recherche classique, sur laquelle s'appuient encore la plupart des moteurs de réponse IA.

Vérifie que le robots.txt ne bloque pas les robots d'IA, en distinguant les robots de citation en temps réel (échec) des robots d'entraînement seul (simple avertissement). Si un robot de citation est interdit, l'assistant ne peut tout simplement pas lire ni citer votre site dans ses réponses en direct — c'est le contrôle au poids le plus élevé. Remarque de transparence : le respect du robots.txt repose sur la bonne foi du robot — il ne fonctionne que si celui-ci choisit de le respecter. Ni ce check ni aucun audit sans accès aux journaux serveur ne peut confirmer qu'un robot se présentant comme « GPTBot » ou « ClaudeBot » est authentique ; seul un reverse-DNS côté serveur le peut. Un résultat vert ici signifie que la politique déclarée est correcte, pas que toute usurpation est impossible.

Vérifie que l’URL racine répond en HTTP 200. Si la page d’accueil renvoie une erreur ou est injoignable, les robots n’ont aucun point d’entrée à indexer et les assistants n’ont rien à citer.

Recherche sur la page d'accueil des directives robots bloquantes (noindex/noai) dans l'en-tête X-Robots-Tag ou la balise meta robots. Une telle directive sur la page d'accueil demande aux robots de recherche et d'IA d'ignorer entièrement la page, la rendant invisible dans les résultats et les réponses des IA.

Recharge la page d'accueil et quelques pages échantillonnées avec des user-agents de robots IA (GPTBot, ClaudeBot) et un navigateur mobile, puis compare le code HTTP, la taille du corps, le titre et le contenu principal à la récupération par défaut. Révèle le cloaking ou le blocage en périphérie — lorsqu'un CDN/WAF remet aux robots IA un document bloqué, redirigé ou allégé au lieu de la page que voit un navigateur.

Vérifie si les pages autorisent des aperçus complets de texte, d’image et de vidéo (max-snippet, max-image-preview, max-video-preview) au lieu de les restreindre avec nosnippet ou des limites à zéro. Des directives d’aperçu généreuses permettent aux résultats de recherche et aux réponses des IA d’afficher de riches extraits de votre contenu, ce qui améliore le taux de clic et les citations.

Vérifie que les pages échantillonnées ne sont pas bloquées à l’indexation par noindex/none dans la balise meta robots ou l’en-tête X-Robots-Tag (et signale les conflits en-tête/meta ainsi que nofollow). Une page en noindex est invisible pour les moteurs de recherche comme pour les crawlers IA : elle ne peut donc jamais être trouvée ni citée.

Vérifie que /llms.txt existe, est servi en texte brut et bien structuré (un titre H1, un résumé d’une ligne, une section « ## » et au moins 5 liens descriptifs de même origine). Ce fichier est une carte soigneusement sélectionnée qui aide les moteurs de réponse IA à découvrir et comprendre vos pages les plus importantes. Nuance honnête : llms.txt est un signal à la valeur non prouvée — les grandes études 2025-26 (Ahrefs 137K sites, SE Ranking 300K, Otterly 62K, Trakkr 37,9K) ne mesurent aucun gain de citation, l’adoption est d’environ 3,2 %, et Google annonce un impact nul sur le classement. Il garde un poids modeste comme pari peu coûteux ; la valeur vient de l’ensemble combiné des contrôles, pas de ce seul fichier. Depuis 2026, Chrome Lighthouse audite ce fichier dans sa propre catégorie « Agentic Browsing », et son échantillon 2026 constate que 96,8 % des sites en sont toujours dépourvus — un contrôle réussi ici représente donc une vraie longueur d’avance, même modeste, sur l’essentiel du web.

Vérifie que /llms-full.txt existe en texte brut avec un contenu substantiel (environ 2000 mots ou plus sous au moins 2 titres). Il fournit aux crawlers IA le texte intégral de vos pages clés dans un fichier propre, pour qu’ils puissent vous citer avec exactitude. Comme llms.txt, c’est un signal peu coûteux à la valeur non prouvée — aucune grande étude n’a mesuré de gain de citation — d’où son faible poids ici.

Vérifie que chaque page échantillonnée expose au moins 200 caractères de texte visible sans exécuter JavaScript. Les crawlers IA n’exécutent généralement pas le JS : un contenu qui n’apparaît qu’après un rendu côté client leur reste invisible.

Examine le HTML brut de chaque page échantillonnée à la recherche d'un point de montage client vide (#root, #__next, #app, <app-root>…) accompagné de quasiment aucun texte rendu côté serveur. Ces pages ne se remplissent qu'une fois le JavaScript exécuté : les robots IA, qui n'exécutent généralement pas le JS, ne voient donc qu'une coquille vide. Un rendu SSR/SSG authentique qui embarque en plus du balisage de framework n'est pas pénalisé.

Vérifie que le contenu principal de chaque page atteint un seuil de mots (≥300 mots pour les articles, ≥150 pour les autres pages). Les pages trop minces offrent peu de matière à extraire ou à citer pour les moteurs de recherche et d’IA.

Vérifie que chaque page commence par une réponse ou définition directe et concise (≈40–320 caractères), ou un bloc TL;DR, juste après le H1. Les moteurs de réponse privilégient le contenu qui énonce l’essentiel d’emblée plutôt que de l’enfouir.

Sur les pages longues (≥300 mots), vérifie qu’au moins un H2/H3 est formulé comme une question (commence par quoi/comment/pourquoi… ou se termine par « ? »). Ces sous-titres reflètent la façon dont on interroge les assistants IA et facilitent la reprise de passages comme réponses.

Sur les pages substantielles (≥150 mots), recherche des listes (<ul>/<ol>) ou des tableaux de données avec en-têtes <th> dans le contenu principal. Un contenu structuré est bien plus facile à analyser et à réutiliser pour les moteurs d’IA qu’un long bloc de prose.

Sur les pages substantielles, vérifie la présence d’au moins un lien sortant externe et non social dans le contenu principal. Citer des sources primaires faisant autorité renforce la crédibilité que les moteurs de réponse IA valorisent au moment de choisir leurs citations.

Compare le texte principal des pages échantillonnées via une similarité de shingles/Jaccard pour repérer les corps quasi identiques (recouvrement ≥0,8). Le contenu dupliqué dilue le classement et empêche les moteurs d’IA de savoir quelle URL privilégier et citer.

Vérifie que des pages /about et /contact accessibles existent et qu’un moyen de contact (tel, email ou ContactPoint) est exposé. Ces signaux de confiance aident les utilisateurs et les moteurs d’IA à confirmer qu’une organisation réelle et responsable se trouve derrière le site.

Vérifie si le site publie un manifeste de découverte /.well-known/ai.json — une convention émergente permettant aux agents IA de trouver des informations lisibles par machine sur le site (nom, description, contact, politiques). Indicatif : l'absence ne produit qu'un avertissement, et une réponse 200 doit être un véritable objet JSON plutôt qu'un fallback HTML de SPA.

Recoupe les trois signaux de fraîcheur qu'une page peut émettre — l'en-tête HTTP Last-Modified, le dateModified JSON-LD (ou article:modified_time) et le <lastmod> du sitemap — et signale leurs contradictions ou une date située dans le futur. Une fraîcheur contradictoire ou factice pousse les moteurs à se méfier du signal et à l'ignorer complètement.

Sur les pages substantielles (≥150 mots), compte les formules évasives (peut-être, il semble, maybe, it seems…) dans les deux premiers paragraphes. Les moteurs génératifs citent de préférence les affirmations nettes et assumées : un chapô évasif réduit donc les chances d'être cité.

Sur les pages piliers (≥300 mots), recherche au moins une « unité de réponse » : un énoncé court et autosuffisant (8 à 40 mots) portant un chiffre, une date ou une entité nommée, qui commence sans anaphore et sans formule évasive. Ce sont les passages qu'un moteur génératif peut reprendre et citer tels quels.

Sur les pages substantielles (≥150 mots), signale les structures DOM qui se disloquent lorsqu'une page est découpée en fragments de retrieval : tableaux longs sans cellules d'en-tête, réponses de FAQ détachées de leur question par du balisage décoratif, et listes orphelines de tout titre. Un fragment de retrieval perd le contexte situé en dehors de lui : ces frontières isolent donc le sens.

Découpe les pages piliers (≥300 mots) en fenêtres d'environ 512 tokens comme le ferait un pipeline de retrieval, puis mesure combien de ces fenêtres tiennent encore seules : chacune doit porter un ancrage thématique (un nombre ou une entité nommée, en comptant le fil d'intertitres qu'un moteur préfixe) et commencer sans renvoyer à la fenêtre précédente. Un moteur reçoit une fenêtre, jamais la page entière.

Recherche le texte qu'un assistant ingère mais qu'un visiteur ne voit jamais : contenu masqué par un style en ligne ou l'attribut hidden, instructions destinées au modèle dissimulées à l'intérieur, et liens contribués par des tiers sans rel="ugc". Des instructions cachées constituent une charge d'injection de prompt, et des liens tiers non attribués laissent d'autres parler au nom du site.

Demande si un agent peut AGIR sur le site, pas seulement le lire : chaque formulaire doit avoir un bouton de soumission non désactivé, une action qui ne soit pas réservée au JavaScript et un name sur chaque champ, et le site doit exposer au moins un moyen lisible par machine de joindre un humain (mailto:, tel:, un formulaire soumettable, ou email/telephone/contactPoint dans le JSON-LD). Un assistant qui agit pour un visiteur ne peut pas exécuter vos gestionnaires de clic.

Vérifie que la page d’accueil contient au moins un bloc JSON-LD valide. Les données structurées permettent aux moteurs de recherche et aux moteurs de réponse IA d’identifier de façon fiable votre entreprise, votre contenu et vos informations clés, au lieu de les deviner à partir du texte brut.

Confirme que le JSON-LD déclare une entité significative (Organization, LocalBusiness ou Article) et, pour les entreprises, inclut le nom, l’adresse et le téléphone. Une entité claire est ce que les assistants IA citent lorsqu’ils nomment et décrivent votre site.

Vérifie combien de pages échantillonnées contiennent des données structurées JSON-LD valides. Les données structurées aident les moteurs de recherche et les assistants IA à comprendre le sujet d’une page et la rendent éligible aux résultats enrichis et aux citations.

Vérifie que la page d’accueil expose des balises Open Graph complètes, avec notamment une image en https absolu. Elles déterminent l’apparence des liens du site lorsqu’ils sont partagés ou cités sur les réseaux sociaux et par les assistants IA, améliorant le taux de clic et la reconnaissance.

Vérifie que la page déclare une Twitter Card (ou un repli Open Graph complet avec titre, description et image HTTPS absolue). Cela contrôle l’affichage des aperçus enrichis lorsqu’un lien est partagé, améliorant le taux de clic et la façon dont les outils IA et sociaux résument la page.

Valide que chaque bloc JSON-LD s’analyse sans erreur et possède un @context schema.org ainsi qu’un @type explicite sur chaque nœud. Des données structurées mal formées sont ignorées silencieusement par les robots : une seule erreur de syntaxe peut réduire tout votre balisage à néant.

Vérifie qu’un nœud Organization ou LocalBusiness porte name, url, un logo HTTPS absolu et des liens de profils sameAs. Ces champs alimentent les panneaux de connaissances et permettent aux moteurs IA d’associer une identité et un logo vérifiés à votre marque.

Détecte le contenu de type FAQ sur la page (paires question/réponse en schéma, blocs dépliables ou titres formulés comme des questions) et le signale lorsqu'il n'est pas adossé à des données structurées FAQPage ou QAPage. Baliser les FAQ en schéma rend chaque question-réponse lisible par les machines, afin que les moteurs de recherche et les assistants IA puissent afficher des réponses directes.

Sur les pages internes (hors page d'accueil), recherche un BreadcrumbList valide avec des positions et des noms ordonnés de façon continue, ou un élément de navigation en fil d'Ariane visible. Le fil d'Ariane exprime la hiérarchie de votre site, améliore les résultats enrichis et aide les moteurs de recherche et IA à situer chaque page.

Vérifie que chaque référence @id du graphe JSON-LD pointe vers un nœud existant et qu’aucun @id n’est déclaré deux fois. Des références rompues ou dupliquées perturbent les analyseurs et peuvent leur faire écarter des entités de votre graphe de données structurées.

Compare les valeurs clés du JSON-LD (name, headline, prix, note) au texte visible de la page pour repérer un balisage décrivant du contenu masqué ou absent. Des données structurées en contradiction avec la page peuvent être considérées comme du spam et entraîner la rétrogradation ou la suppression de vos résultats enrichis.

Construit le graphe d'entités JSON-LD à travers les pages échantillonnées et vérifie sa cohérence : chaque @id référencé est bien défini (aucune référence pendante) et les entités d'identité principales du site (Organization, WebSite, Person, LocalBusiness) sont reliées en un graphe connexe. Un graphe d'entités propre et connecté permet aux moteurs d'IA de comprendre qui vous êtes et de relier vos pages, votre marque et vos auteurs.

Vérifie que le site publie un sitemap XML valide (repéré via les lignes Sitemap de robots.txt ou aux emplacements habituels), doté d’une racine urlset/sitemapindex et d’au moins un <loc>, et qu’il est référencé dans robots.txt. Un sitemap permet aux robots des moteurs de recherche et aux moteurs de réponse IA de découvrir chaque page importante, et pas seulement celles atteintes en suivant les liens.

Vérifie que chaque page échantillonnée déclare une URL canonique unique, absolue et pointant vers elle-même sur la même origine, plutôt qu’une canonique globale vers l’accueil. Cela indique aux moteurs de recherche et aux robots d’IA quelle URL fait autorité et évite la dilution due au contenu dupliqué.

Suit chaque lien interne trouvé sur les pages échantillonnées et signale ceux qui renvoient un code d’erreur (≥ 400) ou ne se chargent pas. Les liens morts gaspillent le budget de crawl et empêchent les moteurs de recherche et d’IA d’atteindre certaines parties de votre site.

Pour chaque alternative hreflang déclarée, vérifie qu’elle se charge (200) et renvoie réciproquement vers la page qui la référence. Un hreflang correct et réciproque indique aux moteurs de recherche et de réponse quelle version linguistique ou régionale servir, évitant qu’une mauvaise variante ne remonte.

Récupère chaque cible <link rel="canonical"> déclarée et vérifie qu'elle renvoie un code HTTP 200, qu'elle est indexable (pas en noindex) et qu'elle ne redirige pas elle-même. Une canonique qui pointe vers une page cassée, en noindex ou avec redirection perturbe les moteurs de recherche et les robots d'IA sur l'URL à indexer.

Vérifie qu'une seule variante d'hôte (www ou apex) sert le site avec un 200 tandis que l'autre renvoie une unique redirection permanente 301 vers elle, sans chaîne ni boucle. Si les deux hôtes servent du contenu, les moteurs de recherche et les robots d'IA voient des sites dupliqués et dispersent leurs signaux de classement.

Pour chaque chemin échantillonné, récupère la forme à la barre oblique finale inversée et la signale si cette variante renvoie aussi un 200 (contenu dupliqué à deux URL). Servir la même page à la fois sur /page et /page/ disperse les signaux de classement entre les deux URL.

Suit la chaîne de redirections de la page d'accueil et des URL échantillonnées, en signalant les chaînes à plusieurs sauts, les boucles ou les redirections temporaires utilisées pour des déplacements permanents. Les sauts supplémentaires ralentissent les robots, gaspillent le budget de crawl et peuvent laisser une page non indexée.

Demande un chemin inexistant aléatoire et vérifie que le serveur renvoie un vrai code 404/410 plutôt qu'un 200 ou une redirection vers la page d'accueil (un soft 404). Les moteurs de recherche s'appuient sur le code HTTP pour retirer les pages manquantes ; un soft 404 laisse des routes vides s'indexer comme du vrai contenu.

Récupère une route inexistante et vérifie que la page 404 renvoyée offre une issue — liens internes, une navigation ou un champ de recherche — au lieu d'être une impasse. Une page 404 utile retient les visiteurs sur le site et donne aux robots des liens à suivre.

Examine les URL échantillonnées et liées pour repérer les problèmes de lisibilité : longueur excessive, majuscules, tirets bas, imbrication trop profonde ou paramètres de session/suivi. Des URL propres et prévisibles sont plus faciles à analyser, partager et dédupliquer pour les utilisateurs comme pour les robots.

Recherche dans les pages les redirections côté client <meta http-equiv="refresh">. Elles sont lentes et mal comprises par les robots, qui peuvent ne pas transmettre les signaux de classement ou ne pas les suivre du tout — une 301 côté serveur en est l'équivalent fiable.

Sur les pages qui utilisent hreflang, valide les codes de langue BCP-47 et vérifie la présence d'un alternate x-default, d'une entrée autoréférencée et d'URL absolues. Un hreflang correct indique aux moteurs de recherche quelle version linguistique ou régionale servir ; des lacunes font remonter la mauvaise version ou font ignorer l'ensemble.

Construit un graphe de liens internes sur les pages échantillonnées et signale les pages sans lien interne sortant, les pages orphelines (aucun lien vers elles) ou situées à plus de 3 clics de la page d'accueil. Les pages orphelines ou trop profondes sont rarement découvertes, explorées ou classées.

Construit le graphe de liens internes sur les pages échantillonnées, puis calcule pour chaque page son degré entrant et un PageRank limité à l'échantillon afin de nommer les pages les mieux classées ainsi que les pages orphelines (aucun lien vers elles) ou en impasse (aucun lien interne sortant). Là où internal-linking repère la profondeur et le sous-maillage, ce contrôle cartographie la répartition réelle du jus de lien et met au jour les pages gagnantes et perdantes.

Compte les liens de navigation et signale les pages où trop d'entre eux nécessitent JavaScript pour fonctionner (href="#", javascript: ou pas de href). Les robots des moteurs de réponse IA (GPTBot, ClaudeBot, PerplexityBot) et le premier passage de Google n'exécutent pas JavaScript, si bien qu'une navigation uniquement en JS leur cache ces pages.

Vérifie que les entrées du sitemap portent des dates <lastmod> réelles, valides (ISO-8601), non futures et variées, plutôt qu’absentes, erronées ou toutes identiques à la date de build. Des dates de dernière modification exactes indiquent aux robots quelles pages ont réellement changé, afin qu’ils réexplorent rapidement le contenu mis à jour.

Échantillonne des URL du sitemap et confirme que chacune est de même origine, en HTTPS, renvoie un 200 sans redirection, n’est pas en noindex et est auto-canonique. N’y lister que des URL propres, finales et indexables évite aux robots de gaspiller leur budget sur des redirections, des liens morts ou des pages à ne pas indexer.

Recoupe le sitemap avec le graphe de liens internes du site, en signalant les URL du sitemap vers lesquelles rien ne pointe et les pages liées en interne absentes du sitemap. Les pages importantes doivent à la fois figurer dans le sitemap et être liées en interne, pour que les robots et les moteurs IA les découvrent et leur accordent de l’importance.

Vérifie que la page d’accueil possède un `<title>` et une meta description de longueur adéquate. Ce sont le titre et le résumé que les moteurs de recherche et les moteurs de réponse IA affichent et utilisent pour comprendre le sujet de la page.

Vérifie que chaque page échantillonnée possède un <title> et une meta description distincts. Des titres ou descriptions en double rendent les pages indiscernables dans les résultats de recherche et les citations des IA, ce qui nuit à la pertinence.

Vérifie que chaque page échantillonnée possède un <title> de 10 à 70 caractères et une meta description de 50 à 160 caractères. Ce sont les éléments que les moteurs de recherche et les moteurs de réponse IA affichent et utilisent pour comprendre une page : bien dimensionnés et uniques, ils améliorent le taux de clic et la justesse du résumé de votre page.

Vérifie que le <title> de la page d’accueil commence par le sujet et place la marque après un séparateur. Un titre qui met le sujet en avant indique aux moteurs de recherche et aux assistants IA de quoi parle la page avant le nom de marque, ce qui améliore la pertinence dans les résultats.

Vérifie que le <title> et le <h1> de la page d’accueil partagent des mots significatifs une fois la marque exclue. Lorsque le titre et le titre principal s’accordent sur le sujet, les moteurs de recherche et les modèles d’IA reçoivent un signal cohérent sur le thème de la page.

Vérifie que chaque page échantillonnée comporte exactement un <h1> et ne saute jamais de niveau de titre. Une hiérarchie de titres propre permet aux robots et aux modèles d’IA d’analyser la structure de la page et d’en extraire les sections à citer.

Mesure la proportion de liens internes utilisant un texte générique comme « cliquez ici », « en savoir plus » ou une URL brute. Un texte de lien descriptif indique aux moteurs de recherche et à l’IA de quoi parle la page liée, ce qui facilite à la fois la navigation et la compréhension.

Vérifie que la page d’accueil déclare un encodage de caractères, idéalement UTF-8. Sans charset déclaré, les navigateurs et les robots peuvent mal interpréter les caractères accentués ou non latins et corrompre votre contenu.

Vérifie la présence d’un favicon et d’une apple-touch-icon sur la page d’accueil. Ces icônes rendent le site reconnaissable dans les onglets du navigateur, les favoris et sur les écrans d’accueil mobiles, ce qui renforce la confiance dans la marque.

Estime le niveau de lecture du texte principal de la page d’accueil à l’aide d’une formule de Flesch-Kincaid. Des phrases plus courtes et plus simples sont plus faciles à lire et permettent aux modèles d’IA de résumer et de citer votre contenu avec justesse.

Mesure la taille du document HTML et signale tout ce qui dépasse 100 Ko. Un HTML surchargé ralentit le premier rendu et coûte plus cher à récupérer et analyser pour les robots de recherche et d'IA.

Compte, sur chaque page échantillonnée, les scripts du <head> qui bloquent le rendu. Ces scripts bloquants retardent l'affichage de la page, ce qui dégrade la vitesse perçue et les Core Web Vitals.

Compte les feuilles de style bloquantes dans le <head>. Chacune bloque le premier affichage tant qu'elle n'est pas téléchargée, retardant le moment où les visiteurs et les robots voient le contenu.

Vérifie, sur les pages échantillonnées, la proportion d'images qui déclarent une largeur/hauteur explicite (ou une propriété CSS aspect-ratio). Sans dimensions, la mise en page saute au chargement des images, ce qui dégrade la métrique CLS.

Vérifie que l'image principale (probable LCP) se charge immédiatement tandis que les images sous la ligne de flottaison sont en chargement différé. Différer l'image principale retarde le plus grand affichage, et charger d'emblée les images hors écran gaspille de la bande passante.

Mesure la proportion d'images matricielles proposées dans des formats nouvelle génération comme WebP ou AVIF. Ces formats sont bien plus légers que le JPEG/PNG, donc les pages se chargent plus vite et coûtent moins cher à récupérer pour les robots.

Vérifie si les scripts et feuilles de style provenant d'autres domaines disposent d'un indice preconnect ou dns-prefetch. Ces indices permettent au navigateur d'établir tôt les connexions tierces, ce qui réduit le temps de chargement.

Compte le nombre d'éléments du DOM et la profondeur d'imbrication maximale de la page d'accueil. Un DOM volumineux ou trop imbriqué ralentit le rendu et rend la page plus difficile à analyser pour les navigateurs et les robots.

Vérifie si le HTML est servi avec une compression Brotli, zstd ou gzip. Compresser les réponses texte réduit fortement la taille transférée, ce qui accélère la livraison aussi bien aux visiteurs qu'aux robots d'IA.

Mesure le volume de <style> et <script> en inline dans le <head> et signale tout dépassement de 14 Ko. Trop de code inline alourdit chaque chargement de page et ne peut pas être mis en cache séparément.

Mesure le score de performance Lighthouse issu de PageSpeed Insights, une note globale synthétique de la vitesse de la page. Une page qui se charge vite retient les visiteurs et aide les crawlers IA à récupérer et indexer votre contenu de façon fiable.

Vérifie le Largest Contentful Paint — le temps avant l’affichage du contenu principal de la page — à partir des données de terrain (CrUX) issues de vrais utilisateurs, avec repli sur les données de laboratoire. Un contenu principal lent nuit au classement et peut faire expirer les crawlers avant qu’ils ne le voient.

Vérifie le Time To First Byte — la rapidité avec laquelle votre serveur commence à répondre — à partir des données de terrain réelles, avec repli sur le laboratoire. Un serveur lent retarde tout le reste et peut pousser les crawlers IA à abandonner avant de récupérer la page.

Mesure le Total Blocking Time à partir des données de laboratoire — la durée pendant laquelle le thread principal reste bloqué et incapable de répondre aux interactions — comme substitut de l’interactivité en l’absence de données de terrain. Un temps de blocage élevé signale une page saccadée et peu réactive.

Vérifie le First Contentful Paint (recoupé avec le LCP de laboratoire) à partir des données de laboratoire de PageSpeed Insights — la rapidité d’apparition du premier contenu — comme indicateur de vitesse en l’absence de données d’utilisateurs réels. Un premier affichage rapide rassure visiteurs et crawlers sur le fait que la page se charge.

Mesure la proportion d’éléments <img> possédant un attribut alt sur les pages échantillonnées. Le texte alternatif permet aux lecteurs d’écran et aux modèles d’IA de comprendre les images, améliorant l’accessibilité et la richesse sémantique que les moteurs peuvent extraire de la page.

Vérifie la présence d’une balise meta viewport pour mobile sur la page d’accueil. Sans elle, les pages s’affichent à la largeur bureau sur téléphone, ce qui nuit à l’ergonomie mobile, un critère pris en compte par les moteurs de recherche pour le classement.

Vérifie que chaque page échantillonnée déclare un code de langue BCP-47 valide dans `<html lang>`. Les lecteurs d'écran s'en servent pour prononcer correctement le contenu, et les moteurs de recherche et d'IA l'utilisent pour proposer la page au public de la bonne langue.

Vérifie que chaque page utilise des repères sémantiques : un seul `<main>` plus au moins deux parmi `<header>`/`<nav>`/`<footer>`. Ces régions permettent aux technologies d'assistance et aux robots d'IA de distinguer le contenu principal de la navigation et des éléments répétitifs.

Vérifie que chaque champ input, select et textarea (hors champs cachés et boutons) possède un nom accessible fourni par un `<label>`, un `aria-label` ou un `aria-labelledby`. Sans cela, les utilisateurs de lecteurs d'écran ne savent pas à quoi sert un champ et le formulaire devient inutilisable.

Vérifie que les liens disposent d'un nom accessible issu de leur texte, d'un `aria-label` ou de l'alt d'une image enfant. Les liens icônes ou images sans nom sont inutilisables au lecteur d'écran et ne donnent aux robots de recherche et d'IA aucune indication sur leur destination.

Vérifie que la balise meta viewport ne bloque pas le zoom tactile via `user-scalable=no` ou un `maximum-scale` inférieur à 2 (WCAG 1.4.4). Désactiver le zoom exclut les personnes malvoyantes qui ont besoin d'agrandir le texte pour lire la page.

Confirme que le site est servi en HTTPS une fois les redirections suivies. Le transport sécurisé est un signal de base pour le classement et la confiance, et de nombreux robots et agents IA ignorent ou déclassent les pages qui ne sont pas en HTTPS.

Vérifie que la version http:// du site redirige de façon permanente (301) vers https:// en inspectant le tout premier saut de la chaîne de redirection. Une redirection permanente regroupe les signaux de référencement sur une seule origine canonique sécurisée et évite aux crawlers de rester sur une version non sécurisée ou dupliquée.

Vérifie qu’une page HTTPS ne charge pas de sous-ressources (scripts, feuilles de style, iframes, images ou médias) via http:// non sécurisé. Le contenu mixte déclenche des avertissements de sécurité du navigateur et peut bloquer discrètement des ressources, ce qui affaiblit les signaux de confiance sur lesquels s’appuient les moteurs de recherche et d’IA.

Vérifie la présence d’un en-tête Strict-Transport-Security avec un max-age d’au moins 180 jours, qui force les navigateurs à ne joindre le site qu’en HTTPS. Le HTTPS imposé protège les visiteurs des attaques de rétrogradation et renforce la posture de sécurité qui bâtit la confiance des moteurs de recherche et d’IA.

Confirme que le site envoie `X-Content-Type-Options: nosniff`, qui empêche les navigateurs de deviner (MIME-sniffing) le type d’un fichier au lieu de se fier au type déclaré. Bloquer le MIME-sniffing prévient toute une catégorie d’attaques par injection et constitue un signal de sécurité de base attendu des sites dignes de confiance.

Vérifie la présence d’une Content-Security-Policy qui restreint les scripts, styles et connexions que la page peut charger, et alerte lorsqu’elle autorise encore « 'unsafe-inline' » ou des sources joker. Une CSP solide limite les attaques par injection de scripts (XSS) et signale aux moteurs de recherche et d’IA un site bien sécurisé et digne de confiance.

Vérifie que la page se protège contre son intégration dans un cadre hostile, via un en-tête X-Frame-Options ou une directive CSP frame-ancestors transmise en HTTP. La protection anti-clickjacking empêche les attaquants d’abuser les utilisateurs au moyen d’une surcouche invisible de votre site et constitue un signal de sécurité standard d’une page digne de confiance.

Vérifie la présence d’un en-tête Referrer-Policy valide et non fuyant, qui contrôle la part de votre URL partagée lorsque les visiteurs suivent des liens vers d’autres sites. Une politique respectueuse de la vie privée évite de divulguer des URL sensibles et reflète l’hygiène de sécurité qui renforce la confiance globale envers le site.

Vérifie la présence d’un en-tête Permissions-Policy (ou de l’ancien Feature-Policy) qui désactive par défaut des fonctionnalités puissantes du navigateur comme la caméra, le microphone et la géolocalisation. Verrouiller les fonctionnalités inutilisées réduit la surface d’attaque et constitue un signal de sécurité moderne d’un site bien entretenu et digne de confiance.

Vérifie la présence de /.well-known/security.txt (RFC 9116), l'adresse lisible par machine qu'un chercheur utilise pour signaler une faille, et contrôle que le champ Contact obligatoire est présent et que la date Expires est encore dans le futur. Un fichier périmé ou sans contact signale un site laissé à l'abandon — un signal de confiance que lisent aussi bien les moteurs que les scanners de sécurité.