Chaque version dit ce qui a bougé et pourquoi, presque toujours avec en tête le chiffre qui l’a motivé. Les scores anciens ne sont jamais recalculés : un rapport décrit l’état de ce site le jour de la mesure, selon les critères de ce jour-là, et c’est pourquoi chacun porte sa version imprimée.
0.15.0 · 2026-09-05
Le moteur confondait deux choses qui ne se ressemblent pas : ne pas avoir pu lire un fichier et l’avoir lu en constatant qu’il n’existe pas. Un 404 est un fait dont on déduit quelque chose —s’il n’y a pas de robots.txt, personne n’est bloqué— et là, la vérification doit trancher. Un 401, un 403 ou un 429 disent l’inverse : le fichier existe et on ne nous laisse pas le voir. Ce cas côtoyait le 404 à cause d’une comparaison avec deux cents qui avalait la différence, et il produisait les deux mensonges à la fois. À un site protégé par un pare-feu applicatif, on annonçait qu’il n’a pas de robots.txt lisible, que son sitemap n’est pas déclaré, qu’il ne publie pas de llms.txt et qu’il ne répond pas à la négociation Markdown : quatre affirmations sur des fichiers qui existent et fonctionnent. Et dans le même temps on lui accordait que son robots.txt ne bloque aucun robot de réponse, une réussite sur un fichier jamais lu. Dans l’échantillon de calibration, cela concerne cinquante sites sur deux cent quatre-vingt-dix-neuf, un sur six. À partir de cette version, ces trois codes laissent sans conclusion les cinq vérifications concernées, et le blocage reste signalé par la vérification qui existe pour cela. Le titre de la chaîne de redirections est également corrigé : il parlait toujours de sauts, si bien qu’un site bloqué lisait « atteindre la page d’accueil demande 0 redirections », l’optimum présenté comme un défaut. Les branches qui ne parlent pas de sauts —le statut de la réponse et une destination qui finit en http— ont désormais leur propre texte. Les scores antérieurs ne sont pas recalculés.
0.14.0 · 2026-08-19
Deux vérifications cessent de pénaliser le chinois, le japonais et le coréen parce qu’ils écrivent plus dense. La première : les titres rédigés en question n’étaient pas reconnus, car ces langues ferment par «？», le signe pleine chasse, et seul celui du clavier latin était recherché. Sur notre propre page de méthodologie en chinois, ils donnaient zéro sur quarante et un, alors que tous les titres de section sont des questions. La seconde : les fourchettes de longueur du titre et de la description sont calibrées sur l’alphabet latin, trente à soixante caractères et cent dix à cent soixante, et elles existent parce que les moteurs tronquent selon la largeur. Un caractère chinois occupe le double d’une lettre latine et en dit nettement plus : le titre de cette même page fait vingt-deux caractères et transmet ce que cinquante transmettent en espagnol ; il échouait donc pour le dire en moins de place. Dans ces écritures, les fourchettes sont divisées par deux. En dehors, rien ne change, et la calibration sur l’échantillon de 299 domaines européens et américains a été lancée précisément pour le vérifier. Les scores antérieurs ne sont pas recalculés.
0.13.0 · 2026-08-18
Deux corrections dans le choix de la page intérieure, dont dépendent cinq vérifications à la fois. La première : «www.exemple.fr» et «exemple.fr» sont le même site, et le moteur les traitait comme des origines distinctes. Sur ruanyifeng.com, un blog technique chinois, les dix-huit liens vers des articles de son propre sommaire pointent vers «http://www.ruanyifeng.com/blog/...» ; en analysant le domaine sans «www», les dix-huit étaient écartés, il ne restait aucun article parmi les candidats, et les vérifications de contenu finissaient par mesurer une liste de titres. La seconde : si la page retenue se révèle être un sommaire de rubrique, le moteur descend désormais une seule fois vers son premier article. Un saut et non plusieurs, car ce téléchargement est séquentiel et se prélève sur le même budget de temps que le reste de l’analyse ; si le saut ne rapporte rien de mieux, le sommaire est conservé, car mesurer quelque chose de moins bon vaut mieux que ne rien mesurer. Le choix reste déterministe : un même site donne toujours la même page, sinon le score cesserait d’être reproductible. Reste non résolu le cas où la page retenue est dans une autre langue que le reste du site. Les scores antérieurs ne sont pas recalculés.
0.12.0 · 2026-08-18
La vérification des paragraphes qui tiennent hors de leur contexte recalait presque tous les sites en espagnol. Elle repérait la dépendance au paragraphe précédent en cherchant pronoms et déictiques, mais la liste contenait «la», «los» et «las», qui sont des articles et non des déictiques, et elle les cherchait n’importe où dans la première phrase au lieu de son début. Ainsi, «Los umbrales se calibraron midiendo una muestra propia» ressortait comme dépendant. Un déictique en milieu de phrase a le plus souvent son antécédent dans cette même phrase : il est donc lié ; celui qui laisse un paragraphe en suspens est celui qui l’ouvre. Seule l’ouverture compte désormais, et seulement les formes sans ambiguïté pronominales : «esto», «eso», «ello», «it», «lo anterior» et les anaphores explicites. «Este» et «this» sont écartés à dessein, car ils valent aussi bien comme pronom que comme déterminant et ne se distinguent pas sans analyse morphologique : dans le doute, rien n’est pénalisé, c’est la règle affichée de cette couche. La correction publiée décrivait déjà ce comportement ; le code, non. Les scores antérieurs ne sont pas recalculés, le chiffre de cette vérification dans l’étude de calibration relève donc de l’ancien critère.
0.11.0 · 2026-08-18
Le moteur compte désormais correctement les mots en chinois, en japonais et en coréen. Ces langues ne séparent pas les mots par des espaces, et le moteur comptait en découpant sur les espaces : sur cinq articles réels d’un blog technique chinois, sur 1 579 paragraphes, exactement 2 passaient le filtre de vingt mots. Correctement comptés : 560. Cela laissait tout site chinois, japonais ou coréen sans rien à mesurer, ni pour les paragraphes qui tiennent hors de leur contexte ni pour les données dans le contenu, et faisait échouer les réponses directes même lorsqu’elles répondaient parfaitement au titre. L’en-tête du module lui-même indiquait que le biais de langue va toujours dans le même sens, sans pénaliser en cas de doute ; là, il allait exactement dans l’autre. Le comptage utilise maintenant le segmenteur de mots du système, qui segmente réellement ces langues, plutôt qu’une constante de conversion inventée. Hors de ces écritures, le comptage est identique au précédent, caractère pour caractère : le score d’un site en espagnol, anglais, allemand, français, italien ou portugais ne bouge pas d’un point, et un test le vérifie sur l’ensemble des textes publiés du site. Les scores antérieurs ne sont pas recalculés.
0.10.0 · 2026-08-06
Cinq nouvelles vérifications et un changement sur la page mesurée. Deux des cinq viennent de la seule chose rigoureusement mesurée dans ce domaine : l’étude fondatrice sur l’optimisation pour moteurs génératifs a montré que citer ses sources, fournir des données et ajouter des citations peut augmenter la visibilité dans les réponses jusqu’à 40 %. D’où les liens vers des sources externes, qui comptent vers combien de domaines extérieurs le contenu renvoie, et les données dans le contenu, qui regardent quelle part des paragraphes porte un chiffre concret. Les trois autres viennent de recommandations publiées : les listes et tableaux, fragments qui arrivent déjà découpés ; la date de publication et de révision déclarée dans les données structurées ; et la signature, qui pèse peu à dessein parce que sa preuve vient de cas observés et non d’une mesure. Le choix de la page intérieure change aussi : un article prime désormais sur une page institutionnelle. Cela est né du constat que, sur Xataka, nous mesurions la page équipe, faite de biographies, où les vérifications de contenu tombaient à zéro sur soixante-neuf paragraphes. Xataka n’écrivait pas mal ; nous regardions la mauvaise page. Les vérifications notées passent de 28 à 33. Les scores antérieurs ne sont pas recalculés.
0.9.0 · 2026-08-06
La vérification de cohérence de la description ne compare plus la description de l’éditeur à celle de la page. Une Organization décrit l’éditeur, par définition de schema.org, et dans une entreprise à plusieurs métiers elle n’a aucune raison de ressembler à la page : les comparer imposait une description fausse à l’une des deux — soit l’entreprise décrite comme si elle était le produit, soit l’inverse. La comparaison se fait désormais avec la description de l’entité qui dit ce que le site propose — SoftwareApplication, Product, Service, Article et apparentés —, et ne retombe sur celle de l’éditeur qu’à défaut : le cas d’un site d’entreprise sans produit, où la description de l’entreprise est bel et bien celle de la page. La correction n’est pas une amnistie : une description de produit qui contredit la page échoue toujours, tout comme deux meta descriptions qui divergent entre elles, cas que la vérification détectait déjà bien. Les scores antérieurs ne sont pas recalculés.
0.8.0 · 2026-08-05
Une vérification nouvelle : si les titres sont formulés en question. On vérifiait déjà que chaque titre était suivi d’une réponse autonome de 40 à 80 mots, mais pas que le titre lui-même ressemblait à ce qu’une personne taperait. L’unité que ces systèmes de recherche préfèrent est la paire complète — une question reconnaissable au-dessus, une réponse qui tient seule en dessous — et seule une moitié de cette paire était mesurée. La mesure se fait sur la même page intérieure que les réponses directes, car les mesurer sur des pages différentes décrirait deux endroits et aucune paire. Un titre compte comme question s’il porte un point d’interrogation, et aussi s’il commence par un interrogatif accentué, car en espagnol c’est précisément l’accent qui sépare l’interrogatif du relatif. Les seuils sont un point de départ et seront revus sur l’échantillon de calibration. Les vérifications notées passent de 27 à 28. Les scores antérieurs ne sont pas recalculés.
0.7.0 · 2026-08-04
Les titres situés dans le pied de page, la navigation et les barres latérales ne comptent plus comme du contenu. La mesure d’un échantillon de sites réels a montré que 43 % des titres vivaient dans un <footer> ou un <nav> — 81 % chez HubSpot, 53 % chez Mailchimp — et chacun d’eux était compté. Un <h2>Services</h2> dans un pied de page n’a pas de paragraphe en dessous parce qu’il ne doit pas en avoir : sa présence faisait donc échouer la vérification des réponses directes à tout site doté d’un pied de page ordinaire. Seuls 5 % réussissaient, et la cause n’était pas la façon dont les gens écrivent mais celle dont nous comptions. Cela touche les réponses directes, la hiérarchie des titres et la détection des FAQ, et les trois y gagnent en justesse. Le H1 de l’en-tête compte toujours : beaucoup de sites le placent là. Les scores antérieurs ne sont pas recalculés.
0.6.0 · 2026-08-04
Première version calibrée sur un large échantillon : 299 sites d’Espagne, du Royaume-Uni, des États-Unis et du reste de l’Europe, entre marques, services et entreprises de taille moyenne. Trois changements sortent de ces données. Les deux vérifications de données structurées fusionnent en une seule : la vérification de validité était réussie par 95 % de ceux qui l’atteignaient et ne s’appliquait pas aux 26 % restants, parce que le JSON-LD n’est presque jamais écrit à la main et que ce qu’un plugin génère est rarement cassé ; une seule vérification distingue désormais ne pas en avoir, en avoir de cassées et en avoir de correctes, à poids égal. Les paragraphes autonomes se mesurent désormais sur une page intérieure, comme les réponses directes le faisaient déjà : la page d’accueil n’avait pas trois paragraphes de vingt mots sur 78 des 215 sites mesurés en entier, et sans page lisible portant du contenu la vérification échoue maintenant au lieu de se taire. Et le sceau téléchargeable descend de 80 à 70 points : à 80, il était atteint par 6 sites sur 215, et un sceau que presque personne ne peut afficher ne circule pas. Les vérifications notées passent de 28 à 27. Les scores antérieurs ne sont pas recalculés.
0.5.0 · 2026-08-04
Deux vérifications cessent de se déclarer incapables de trancher là où elles le peuvent. Ne pas avoir de bloc de questions-réponses balisé en FAQPage vaut désormais ÉCHEC et non plus non applicable : c’est ce que les modèles génératifs citent le plus, donc un site qui n’en a pas est moins bien préparé à être cité qu’un site qui en a, et redistribuer son poids sur les autres affirmait le contraire. Avoir les questions à l’écran sans les baliser vaut partiel, parce que cela se corrige en dix minutes tandis que les écrire de zéro, non. Et un site sans sitemap accessible échoue désormais à la vérification de fraîcheur au lieu de rendre un résultat sans conclusion — y compris le cas d’un serveur qui répond à /sitemap.xml par un 200 et la page d’accueil en HTML, ce que font les frameworks monopage. « Sans conclusion » n’est conservé que là où c’est réellement inconnu : une erreur réseau, ou un serveur qui existe et refuse de nous laisser regarder. Sur un échantillon de 24 sites, ces deux-là n’entraient pas dans la note dans 67 % et 42 % des cas. La mention « brouillon » quitte l’identifiant de version pour passer dans le texte, traduite par langue. Les scores antérieurs ne sont pas recalculés.
0.4.0 · 2026-08-04
Les réponses directes se mesurent sur une page intérieure de contenu, et non sur la page d’accueil. Une calibration sur 24 sites réels a montré que les 24 y échouaient, Stripe et Cloudflare compris : la page d’accueil d’un site commercial est une vitrine, et les paragraphes qui suivent ses titres font entre cinq et dix-sept mots, parce qu’ils sont écrits pour être saisis d’un coup d’œil et non pour être cités. Une vérification que tout le monde échoue ne distingue personne, si vraie soit-elle. Une page intérieure est désormais choisie dans le sitemap ou parmi les liens de la page d’accueil — toujours la même pour un site donné, afin que le score reste reproductible — et c’est là que la mesure se fait ; si le site n’a aucune page intérieure lisible, la page d’accueil est utilisée à la place, et le rapport indique laquelle a été mesurée. Les scores antérieurs ne sont pas recalculés.
0.3.0 · 2026-08-03
Les vérifications qui dépendent du robots.txt cessent de se déclarer incapables de trancher quand le fichier n’existe pas. Qu’un site n’ait pas de robots.txt n’est pas de l’ignorance, c’est un fait avec des conséquences : s’il n’y a pas de fichier, personne n’est bloqué, donc la vérification de blocage est désormais RÉUSSIE et celle des règles déclarées ÉCHOUE, puisqu’il n’y en a aucune. Auparavant les deux restaient sans conclusion, avec la vérification informative sur l’entraînement, et ces trois-là suffisaient à pousser tout site sans robots.txt vers le seuil du rapport partiel, ce qui le sortait des statistiques. « Sans conclusion » n’est conservé que lorsque le fichier ne peut pas être téléchargé, là où nous ne savons réellement pas. Les scores antérieurs ne sont pas recalculés.
0.2.0 · 2026-08-03
Les robots d’IA sont séparés en deux familles. Bloquer ceux de l’entraînement (GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider) ne coûte plus de points : c’est une décision légitime sur l’usage de votre travail et elle n’empêche pas un modèle de vous citer. Seul le blocage des robots de réponse (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User) est pénalisé, puisque ce sont eux qui récupèrent la page pendant qu’ils répondent. Ils étaient auparavant comptés ensemble, ce qui faisait échouer comme erreur critique la politique la plus défendable qui existe aujourd’hui. Les scores antérieurs ne sont pas recalculés.
0.1.0 · 2026-08-02
Première version publique de la méthodologie. Les seuils sont provisoires et seront figés en version 1.0, après calibration sur un échantillon de 200 sites. D’ici là, les scores peuvent varier d’une analyse à l’autre.