Pas d’option “Extrait vocal” dans l’éditeur

Bonjour rodman38,
Merci pour les captures, elles m’aident beaucoup ! Votre configuration est bonne (VEO bien activé, score GEO 11/12). Le critère « Extrait vocal » s’affiche en rouge dans le score GEO parce que le champ n’est pas encore rempli — c’est normal.

Le souci est ailleurs : le champ « Extrait vocal » (Voice Snippet) n’est PAS dans le panneau latéral OGEEAT à droite que vous avez ouvert. Il se trouve dans la metabox OGEEAT classique qui s’affiche EN BAS, sous la zone de contenu de l’éditeur (et qui porte malheureusement le même nom « OGEEAT » que le panneau latéral, désolé pour la confusion, je vais améliorer ça).

Pour le trouver :
1. Cliquez sur « Sortir de l’éditeur de code » (le lien bleu en haut à gauche de votre capture) pour revenir à l’éditeur visuel.
2. Scrollez tout en bas de l’éditeur, sous la zone d’écriture du contenu.
3. Vous y trouverez une grande zone repliable intitulée « OGEEAT » avec 5 onglets (GEO & E-E-A-T, Google, Facebook, X/Twitter, LinkedIn).
4. Dans le premier onglet (GEO & E-E-A-T) actif par défaut, sous le score GEO, vous verrez l’encadré « Voice Snippet (VEO) » avec une icône microphone violette et un textarea pour écrire votre extrait vocal (max 40 mots).

Si vous ne voyez pas cette metabox du tout en bas :
– En haut à droite de l’éditeur, cliquez sur les trois points → Préférences → onglet « Panneaux » → assurez-vous que « OGEEAT » est bien activé dans la section « Boîtes supplémentaires ».

Pour info, j’ai pris note que c’est très peu découvrable : je vais ajouter le champ Voice Snippet directement dans le panneau latéral OGEEAT dans une prochaine version, pour qu’il soit au même endroit que le critère GEO qui le réclame.

Bien cordialement,
Fabrice

Bonjour rodman38,
Merci pour ce retour très complet, je réponds point par point.

1. Voice Snippet dans le panneau latéral

C’est déjà disponible : la v2.2.3 est sortie il y a quelques jours sur wp.org. Le champ Voice Snippet (VEO) apparaît désormais directement dans le panneau latéral OGEEAT à droite de l’éditeur, entre « Score GEO » et « Profil E-E-A-T ». Mettez à jour depuis Tableau de bord → Mises à jour et plus besoin de scroller jusqu’en bas de l’éditeur.

2. Détection du E-E-A-T implémenté hors plugin

Réponse honnête : c’est volontairement hors scope d’OGEEAT. Le plugin est conçu pour être la source du E-E-A-T et générer le JSON-LD, pas pour auditer ce qu’un autre code injecte dans le . Auditer le DOM rendu, c’est le rôle d’outils spécialisés (Schema Markup Validator, Rich Results Test).

Pour votre cas précis, le filter ogeeat_geo_checks est exactement fait pour ça. Dans votre mu-plugin, 5 lignes suffisent à aligner le score sur la réalité :

add_filter( 'ogeeat_geo_checks', function ( $checks, $post_id ) {
    if ( isset( $checks['organization'] ) ) $checks['organization']['status'] = 'green';
    if ( isset( $checks['author'] ) )       $checks['author']['status']       = 'green';
    return $checks;
}, 10, 2 );

Vous gardez votre architecture et le score GEO reflète enfin votre situation réelle.

3. Distinguer l’auteur de l’expert qui valide (YMYL)

OGEEAT a déjà la feature pour ça depuis la v2.2.0 : c’est Reviewed By, accessible dans la metabox OGEEAT classique, juste sous le Voice Snippet. Ça génère le reviewedBy Person dans le JSON-LD Article et affiche « Relu et validé par [Nom], [Fonction] » sous l’Author Box.

La feature exige effectivement un utilisateur WordPress comme reviewer. Mon conseil : créez un utilisateur dédié à l’expert avec le rôle Abonné. Aucun accès admin, juste un profil rempli avec ses diplômes, certifications, expérience et sameAs. C’est la pratique standard YMYL sur WP, ça reste cohérent avec l’écosystème (Gravatar, get_userdata, etc.) et c’est plus simple à long terme qu’un modèle parallèle d’experts non-WP.

Je ne prévois pas d’ajouter un modèle d’experts externes dans le plugin : le pattern user-Abonné couvre l’écrasante majorité des cas YMYL.

4. llms.txt — bonnes pratiques, exclusions, utilité de llms-full.txt

Bonne pratique : oui, mieux vaut limiter aux contenus à forte valeur (articles, pages ressources type FAQ/guides/glossaire). Pas la peine d’inclure mentions légales, politique de confidentialité, panier, mon compte, pages techniques.

Exclure une page individuellement : la case existe déjà ! Dans la metabox OGEEAT classique (en bas de l’éditeur), tout en bas du panneau, vous avez « Exclure ce contenu de llms.txt ». Cochez-la sur vos mentions légales et politique de confidentialité.

Exclure en masse via mu-plugin : le hook ogeeat_llms_query_args permet de filtrer la requête. Exemple pour plusieurs slugs d’un coup :

add_filter( 'ogeeat_llms_query_args', function ( $args, $post_type ) {
    if ( 'page' === $post_type ) {
        $args['post__not_in'] = get_posts( array(
            'post_type'      => 'page',
            'name__in'       => array( 'mentions-legales', 'politique-de-confidentialite', 'cgv' ),
            'posts_per_page' => -1,
            'fields'         => 'ids',
        ) );
    }
    return $args;
}, 10, 2 );

Utilité de llms-full.txt sur les gros sites : franchement, sur un blog de plusieurs centaines d’articles, l’intérêt est très discutable. La spec llms-full a été pensée pour les sites de doc/référence où le contenu complet tient dans un fichier raisonnable. Pour un site éditorial, le llms.txt (liens + résumés) suffit largement : les crawlers IA n’ont ni la capacité ni l’envie d’avaler plusieurs Mo de markdown. Pour la v2.5, je prévois d’ajouter un toggle pour désactiver llms-full.txt indépendamment de llms.txt.

Merci encore pour la qualité du dialogue, vos retours alimentent directement la roadmap.

Bien cordialement,
Fabrice