Fabrice Ducarme

Bonjour Charlie,

Merci pour le retour, et content que la mise à jour ait réglé le sujet.

1. Votre cas est couvert, quelle que soit la structure de votre HTML

Puisque vous surveillez le comportement ces prochains jours, autant vous dire précisément ce que la 2.6.18 sait faire, cela vous évitera des tests inutiles.

Votre accordéon est reconnu quel que soit son emplacement dans la page : à l’intérieur de votre bloc HTML personnalisé, à l’intérieur de votre section ffr-faq, et même imbriqué dans un groupe ou des colonnes. La détection cherche vos balises details et summary partout dans le contenu, sans se soucier de la profondeur, et le générateur de schémas les lit de la même façon. Sur un accordéon comme le vôtre, le score et le schéma sont donc toujours d’accord.

Le seuil est de deux questions. En dessous, ni le score ni le schéma ne se déclenchent, c’est volontaire : une question isolée n’est pas une FAQ.

2. Le doublon de JSON-LD

Votre idée se tient, et c’est bien la bonne question à poser. Je la note. Je ne l’annonce pas pour autant, ni pour une version ni pour une date : je préfère ne rien promettre plutôt que promettre à la légère.

En attendant, vous avez deux moyens d’agir tout de suite, et ils ne se valent pas.

Le bon, celui que je vous recommande : retirez votre JSON-LD manuel des contenus où OGEEAT génère déjà le schéma. Ce n’est pas seulement pour éviter le doublon. Un schéma généré est reconstruit à chaque affichage depuis votre accordéon : si vous corrigez une réponse, il suit. Votre JSON écrit à la main, lui, reste figé au jour où vous l’avez collé. Le doublon se voit ; la divergence silencieuse entre le texte affiché et le schéma déclaré ne se voit pas, et c’est elle qui coûte cher à terme.

L’autre, si vous préférez garder la main : désactivez la famille de schémas Contenu dans OGEEAT > Réglages > E-E-A-T. OGEEAT cesse alors de produire le FAQPage, et le vôtre reste seul. Vous perdez au passage les schémas HowTo et VideoObject, qui appartiennent à la même famille.

Ce qu’il vaut mieux éviter, dans les deux cas, c’est de laisser les deux blocs en place le temps de la transition. Si vous devez procéder par étapes sur vos anciens contenus, coupez la famille Contenu le temps du nettoyage, puis réactivez-la une fois vos JSON manuels retirés : vous ne serez jamais en doublon.

Bonjour Charlie,
Votre question part d’une observation juste, mais la comparaison ne tient pas : les deux fichiers n’ont pas la même origine.

1. Le llms.txt de WPFormation n’est pas produit par OGEEAT

Il est écrit à la main. C’est un fichier éditorial, pensé section par section pour ce site précis : un résumé en anglais destiné aux moteurs anglophones, des directives d’usage pour les agents, l’adresse de mon serveur MCP, mes catégories avec leur nombre d’articles, mes articles piliers, mes pages importantes, mes outils. Rien de tout cela ne se déduit d’un site WordPress quelconque.

Le vôtre, lui, est généré. Il ne peut contenir que ce qu’OGEEAT sait lire sans se tromper. Comparer les deux revient à comparer une page rédigée et un index automatique : le second est plus complet et toujours à jour, le premier est plus expressif. Aucun des deux n’est en défaut.

2. L’anglais des intitulés est un choix, pas un oubli

Les intitulés de structure (About This Site, Authors, Content Index, Last updated) restent en anglais volontairement. Ce ne sont pas des textes lus par vos visiteurs : ce sont des repères de structure lus par des machines, et la convention llmstxt.org est anglophone. Un modèle qui rencontre « Content Index » sait immédiatement ce qui suit, quelle que soit la langue du site.

En revanche, tout ce qui vient de votre site est bien en français, et je l’ai vérifié sur ffr.community :

• les intitulés de types de contenu suivent la langue de WordPress, vous avez donc « Articles » et « Pages » ;
• les descriptifs de vos articles sont en français, puisqu’ils viennent de vos extraits, ou à défaut des trente premiers mots de vos contenus ;
• votre titre, votre description, vos auteurs et votre pied de page sont exactement ce que vous avez saisi.

Autrement dit, ce qui reste en anglais, ce sont les intitulés de sections et les étiquettes de champs : dans llms-full.txt, vous verrez aussi URL, Author, Published, Modified, Categories, Tags. Ce sont des repères, pas du contenu. Tout ce qui vient de vos publications est dans votre langue.

3. Ce que vous pouvez déjà personnaliser, sans attendre

Dans OGEEAT > Réglages > onglet IA, GEO & Firewall, trois champs sont à votre main : Titre personnalisé, Description personnalisée et Pied de page personnalisé. Vous avez d’ailleurs déjà rempli le dernier, votre fichier renvoie vers votre llms-full.txt.

Deux autres réglages existent au niveau de chaque publication, dans la métaboîte OGEEAT : une Note LLMS personnalisée, qui remplace le descriptif de cet article dans l’index, et une case d’exclusion, pour qu’une publication n’apparaisse pas du tout.

Et si vous voulez le rendu de WPFormation à l’identique, il y a l’Éditeur llms.txt, dans le menu OGEEAT. Il remplace intégralement le fichier généré par le texte que vous écrivez. Vous y écrivez ce que vous voulez, dans l’ordre que vous voulez. Une limite à connaître avant de vous lancer : cet éditeur ne concerne que llms.txt. Le fichier llms-full.txt reste généré automatiquement, et c’est voulu, personne ne maintient à la main l’index complet de plusieurs centaines d’articles.

4. Les catégories

Elles sont déjà là, mais dans llms-full.txt et par article : chaque publication liste ses catégories et ses étiquettes, si le réglage Inclure les taxonomies est actif. Ce que vous demandez est autre chose : un regroupement par catégorie dans l’index, comme sur WPFormation. C’est une évolution, pas une correction, et je la note. Je ne m’engage sur aucune date.

Même réponse pour les champs pré-remplis par défaut : je préfère un fichier qui ne contient que ce que vous avez validé plutôt qu’un fichier rempli de texte générique qu’aucun site n’assume vraiment. Un pied de page vide est un pied de page honnête.

Bonjour Charlie,
J’ai repris votre code tel quel et je l’ai testé. Il y a deux enseignements, et le second est plus utile que le premier.

1. Votre code, collé dans le contenu de l’article, passe déjà au vert

Je l’ai reproduit à l’identique sur une installation de test, avec la version 2.6.17 que vous utilisiez : la vérification Section FAQ est verte. La règle actuelle reconnaît un titre contenant le mot « questions », et votre <h2>Questions fréquentes</h2> la déclenche.

Si chez vous elle reste rouge, c’est donc que cette FAQ ne se trouve pas dans le contenu de la publication elle-même. Le score lit le contenu enregistré, sans effectuer le rendu des blocs : une FAQ placée dans une composition synchronisée, produite par un bloc dynamique, lue depuis un champ personnalisé ou ajoutée par le thème lui est invisible. Pouvez-vous me dire comment cette section est insérée dans vos pages ? Selon la réponse, la 2.6.18 règle peut-être déjà votre cas.

2. Ce que j’ai trouvé au passage, et qui vous concerne directement

Sur votre exemple, la page publie deux blocs FAQPage identiques : le vôtre, écrit à la main, et un second qu’OGEEAT génère tout seul à partir de vos cinq <details> et <summary>. Je l’ai vérifié sur la page rendue, les deux blocs contiennent les mêmes cinq questions.

Vous pouvez donc supprimer votre JSON-LD manuel : OGEEAT le produit déjà depuis votre accordéon, et il restera synchronisé avec le contenu si vous modifiez une réponse. Si vous préférez garder le vôtre, désactivez la famille de schémas Contenu dans OGEEAT > Réglages > E-E-A-T. Ce qu’il vaut mieux éviter, c’est de laisser les deux.

3. Ce que la 2.6.18 corrige

La version 2.6.18 est publiée depuis aujourd’hui sur WordPress.org. Votre message a révélé une incohérence de fond : le score et le générateur de schémas se prononçaient chacun de leur côté, avec des règles différentes. Un accordéon écrit en HTML pouvait produire un schéma FAQPage sur la page pendant que le score annonçait « aucune FAQ trouvée ». C’est précisément le genre de contradiction que votre cas illustre.

Les deux partagent désormais les mêmes règles. Le score reconnaît maintenant, en plus des blocs FAQ de Yoast, Rank Math, SEOKEY et Spectra :

• un accordéon <details> et <summary> écrit en HTML brut, à partir de deux questions ;
• au moins deux titres se terminant par un point d’interrogation, y compris avec l’espace insécable de la typographie française ;
• un bloc JSON-LD FAQPage déjà présent dans le contenu, comme le vôtre. Le message le dit alors explicitement.

Il voit aussi le contenu des compositions synchronisées, dont il ne lisait auparavant que la référence. Et pour tout ce qui est produit hors du corps de la publication, un nouveau filtre ogeeat_geo_content permet de fournir ce contenu au score :

add_filter( 'ogeeat_geo_content', function ( $content, $post ) { $faq = get_post_meta( $post->ID, '_ma_faq_html', true ); if ( '' === $faq ) { return $content; } return $content . $faq; }, 10, 2 );

Il alimente les douze vérifications, pas seulement celle de la FAQ.

Dites-moi comment votre section est insérée, je pourrai vous confirmer si le correctif suffit.

Bien cordialement,
Fabrice

Bonjour Charlie,
Merci pour ce signalement. Vous n’avez pas seulement identifié une gêne : vous avez mis le doigt sur un vrai bug, et je ne l’avais pas vu.

Ces notifications ne pouvaient effectivement pas être supprimées

La croix de fermeture était bien là, mais elle ne faisait rien. Le script chargé d’enregistrer votre clic était attaché à jQuery au moment de l’affichage de la notification, or à cet instant jQuery est déjà écrit dans la page : le script n’était donc jamais ajouté, le clic ne partait nulle part, et la notification revenait à l’écran suivant. Vous pouviez cliquer autant de fois que vous vouliez, rien n’était mémorisé.

C’est corrigé dans la version 2.6.18, publiée aujourd’hui sur WordPress.org. Le gestionnaire est désormais écrit en pied de page, où il est réellement pris en compte, et j’ai vérifié la boucle complète sur un site réel : clic, enregistrement du choix, rechargement, la notification ne revient plus.

Trois autres points, dans la même version

L’avertissement sur le fichier robots.txt s’affichait sur la totalité de l’administration, médiathèque et liste des extensions comprises. Il se limite maintenant aux écrans où il a un sens : ceux d’OGEEAT, le Tableau de bord et les listes de contenus. Sa croix ferme désormais l’avertissement pour de bon, le lien texte restant disponible si JavaScript est désactivé.

La notification que vous citez en exemple, celle qui indique que l’Open Graph est géré par votre extension SEO, ne vérifiait aucune permission : les comptes contributeur et auteur la recevaient aussi, alors qu’elle renvoie à un réglage qu’ils ne peuvent pas atteindre. Elle est maintenant réservée aux comptes qui peuvent agir dessus.

Enfin, si tout cela ne suffit pas, un nouveau réglage dans OGEEAT > Réglages > IA, GEO et Firewall masque les notifications de l’extension en dehors de ses propres écrans, pour tout le site. Les mêmes avertissements restent consultables sur les pages d’OGEEAT, là où on les cherche quand on en a besoin.

Merci encore : sans votre message, ce bug de fermeture serait resté en place.

Bien cordialement,
Fabrice

Bonjour Marie-Aude,
Merci pour ce retour détaillé, et pour l’exemple : il m’a servi de cahier des charges. La version 2.6.16 est en ligne sur WordPress.org, elle met en œuvre ce que vous décrivez.

Ce que fait le llms.txt en 2.6.16 sur un site WPML

Le fichier reste unique à la racine (il est identique quel que soit le domaine appelé), mais il est désormais structuré par langue :

• en tête, une ligne Languages qui liste chaque langue avec l’URL d’accueil de son domaine ;
• une section ## Language: Français (fr-FR) puis ## Language: English (en-US), chacune avec son domaine, le nom du site dans cette langue (celui de Traduction de chaînes), puis ses pages et ses articles, titres et URL dans la langue ;
• en fin de fichier, un bloc ## Interaction Rules avec les trois règles de votre exemple : répondre dans la langue de la question, signaler quand une information n’existe que dans une langue, ne pas mélanger les langues sauf demande explicite. Les développeurs peuvent les adapter via le filtre ogeeat_llms_interaction_rules.

Le llms-full.txt suit la même structure. Techniquement, l’extension lit vos langues par l’API publique de WPML et génère chaque section après avoir basculé WPML dans la langue concernée : c’est ce qui garantit les bons domaines et le bon nom de site. Sur un site monolingue, rien ne change.

Le mot « Articles » et les titres de sections restent en anglais, comme tout le squelette du fichier : le lecteur visé est un modèle de langue, et la convention llms.txt est en anglais.

Le wpml-config.xml

Inutile de le faire vous-même : il est livré avec l’extension. Il déclare dans Traduction de chaînes le titre, la description et le pied de page du llms.txt, les libellés du bouton Partager avec l’IA et du badge, ainsi que le nom, l’adresse et la zone de service de l’organisation. Les metas Open Graph et la note llms.txt de chaque contenu sont déclarées comme champs à traduire. Après mise à jour, un passage dans WPML > Réglages > Traduction de chaînes suffit pour voir apparaître les textes d’OGEEAT ; le contournement par mu-plugin proposé précédemment peut être retiré.

Ce que j’aimerais que vous vérifiiez chez vous

Je n’ai pas de licence WPML sur mes sites de test : la configuration a été validée sur Polylang et sur la documentation de l’API WPML, vous êtes donc la première à la voir tourner en réel, avec un domaine par langue qui plus est. Après la mise à jour :

1. videz le cache de l’extension en enregistrant une fois les réglages OGEEAT (ou attendez la régénération automatique) ;
2. ouvrez /llms.txt sur chacun de vos deux domaines : le contenu doit être identique et comporter les deux sections ;
3. vérifiez que les URL de la section anglaise pointent bien sur le domaine anglais, et le nom du site sur sa traduction.

Si quelque chose cloche, collez ici les vingt premières lignes du fichier : c’est tout ce dont j’ai besoin pour corriger.

Merci encore pour vos mots sur OGEEAT et les articles, cela fait plaisir.
Fabrice

Bonjour,
Merci pour cette remontée, elle est très utile : vous avez trouvé un vrai bug, pas une fausse manipulation.

Ce qui se passe

Vous ne ratez rien. Depuis la 2.6.6, les champs Open Graph du panneau OGEEAT ne sont plus enregistrés quand on utilise l’éditeur de blocs. La cause est technique : l’extension déclarait ces champs uniquement dans l’interface d’administration, alors que l’éditeur de blocs enregistre par l’API REST. WordPress recevait donc vos valeurs, ne les reconnaissait pas, et les écartait sans afficher la moindre erreur. D’où l’impression que l’image « disparaît » à l’enregistrement.

Ni la taille de l’image, ni Imagify, ni OceanWP n’y sont pour quelque chose.

Une précision qui va vous surprendre : le titre n’est pas conservé non plus. Ce que vous voyez dans le champ Titre est un texte d’exemple, l’extension y affiche le titre de la page tant qu’aucun titre personnalisé n’est enregistré. Comme le titre a de toute façon un repli sur celui de la page, la perte ne se voit pas, alors que l’image, elle, n’a pas de repli évident.

Le correctif

Il est écrit et testé, il sort en 2.6.12. Après mise à jour, l’image, le titre et la description choisis dans le panneau seront bien enregistrés, et vous les retrouverez après rechargement de l’éditeur.

En attendant, deux contournements :

• renseignez l’image mise en avant de la page. OGEEAT l’utilise automatiquement comme image Open Graph quand aucune image n’est saisie ;
• ou passez par l’éditeur classique, où les champs Open Graph d’OGEEAT ont toujours fonctionné.

Un autre point sur votre page d’accueil

En regardant votre site, j’ai vu que deux jeux complets de balises Open Graph sont publiés : celui de Yoast SEO, puis celui d’OGEEAT. Les réseaux sociaux ne lisent que le premier, donc l’image Yoast, ce qui explique peut-être aussi ce que vous constatez au partage.

Il faut n’en garder qu’un. Deux possibilités :

• si vous voulez qu’OGEEAT gère l’Open Graph, désactivez vraiment la sortie Open Graph de Yoast et vérifiez ensuite le code source de la page, il ne doit plus rester qu’un seul og:image ;
• si vous préférez laisser Yoast s’en charger, désactivez dans les réglages d’OGEEAT l’option qui force la sortie Open Graph malgré la présence d’une extension SEO. OGEEAT s’efface alors automatiquement.

Pour ByteDance

Là, je vais être franc, et la 2.6.12 corrige surtout la façon dont l’extension le présentait.

Le Firewall robots IA ne bloque pas au sens strict. Il fait deux choses : il ajoute une interdiction dans le robots.txt de votre site, et il envoie un en-tête HTTP demandant de ne pas indexer la page. Ce sont deux consignes, pas un refus d’accès : la page est servie normalement. Un robot qui respecte les règles s’arrête, un robot qui ne les respecte pas continue. Bytespider, le robot de ByteDance, est connu pour ignorer robots.txt.

Deux choses aggravent le cas chez vous :

• votre robots.txt actuel ne contient aucune règle ajoutée par OGEEAT. Vérifiez dans les réglages que le module Firewall est bien activé, il ne l’est pas par défaut ;
• vous utilisez WP Rocket. Les pages servies depuis le cache ne passent pas par WordPress, donc l’en-tête d’indexation n’est même pas envoyé sur ces pages.

Ce qui arrête réellement un robot indélicat se situe au niveau du serveur, pas de l’extension : une règle dans le .htaccess ou la configuration Nginx, un pare-feu applicatif, ou une option de votre CDN, par exemple le blocage des robots IA chez Cloudflare. Votre hébergeur saura vous indiquer la voie la plus simple sur votre offre.

La 2.6.12 dit désormais tout cela clairement dans l’écran du Firewall et dans la documentation intégrée, au lieu de laisser croire à un blocage effectif.

Merci encore pour le signalement, et pour la précision du message : c’est ce qui a permis d’identifier la cause en une seule passe.

Fabrice

Bonjour Camille,

Le constat général est correct : OGEEAT 2.6.10 ne génère pas encore de fichiers llms.txt séparés par langue. Le filtre de requête existant ne couvre ni les URL par langue ni les caches distincts.

Cette compatibilité Polylang/WPML est une évolution, pas un bug du fonctionnement annoncé. Je l’ajoute à la to-do pour une version ultérieure, sans échéance à annoncer pour le moment.

Cordialement,
Fabrice

Bonjour Camille,

Merci pour cette suggestion. OGEEAT permet déjà une note LLMS personnalisée par contenu, mais pas encore la récupération automatique d’un champ ACF selon le CPT. Il s’agit d’une nouvelle possibilité d’intégration, pas d’un bug. Je l’ajoute à la to-do pour une version ultérieure, sans échéance annoncée à ce stade.

Cordialement,
Fabrice