wpformation

Bonjour Nicolas,
Ce n’est jamais immédiat. Ça prend toujours du temps et même l’indexation par les LLMs prend également du temps

Si votre fichier llms-full.txt est accessible, n’est pas bloqué et que vous pouvez vous-même y accéder, alors tout va bien et les LLMs indexeront ce fichier au fil du temps

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,
Merci beaucoup pour ce retour, vous avez mis le doigt sur un vrai bug.

Le toggle « Empêcher l’énumération des auteurs et autrices » est censé bloquer une technique d’énumération côté public : un attaquant qui appelle /?author=1, /?author=2, etc. récupère normalement les identifiants de login WordPress un par un via les redirections 301 automatiques. Login Armor coupe cette fuite en redirigeant ces URLs vers la home.

Le problème que vous remontez : cette protection ne distinguait pas l’usage public anonyme de l’usage légitime dans wp-admin (cliquer sur « les miens » ou sur un nom d’auteur dans la liste des articles ou des pages utilise exactement la même URL ?author=N). Du coup, dès qu’un éditeur ou un administrateur cliquait sur ce lien dans la liste d’articles, il était renvoyé sur la home.

Le fix est simple et conservateur : Login Armor laisse passer ?author=N uniquement dans le contexte wp-admin et uniquement pour les utilisateurs connectés ayant la capacité edit_posts (administrateur, éditeur, auteur, contributeur). Toutes les autres requêtes restent bloquées exactement comme avant. La protection anti-énumération côté public n’est pas affaiblie.

La version 2.1.14 qui inclut ce correctif est en préparation, elle sera publiée dans la journée sur ww.wp.xz.cn. Vous pourrez réactiver le toggle dès la mise à jour faite, le tri admin fonctionnera normalement.

Merci encore pour le test précis et le rapport clair, c’est exactement le genre de retour qui aide à corriger vite.

Fabrice

Re-bonjour graphandco,
Petit complément après inspection du code de Defender (que je suspecte être l’autre plugin qui fonctionnait pour vous) : Defender ne fait pas de SSO cross-domain, il fait simplement du multisite-aware site_url() avec switch_to_blog(). C’est exactement ce que Login Armor V2.1.9 fait depuis ce matin.

Donc en pratique, votre setup multisite + domain mapping devrait marcher avec Login Armor 2.1.10 si vous accédez directement à domaineexterne1.com// au lieu de passer par admin.monsupersite.com. Chaque sous-site a son propre flow login indépendant sur son domaine, cookie posé sur le bon hostname, redirect /wp-admin sur ce hostname, no cross-domain issue.

N’hésitez pas à tester si c’est ce que vous cherchez. Bonne soirée.

Bonjour graphandco,
Merci d’avoir confirmé que V2.1.9/V2.1.10 résolvent votre cas principal. Pour vos sous-sites mappés sur des domaines externes : de notre côté on s’arrête là sur Login Armor, pour la raison que vous avez identifiée vous-même : un cookie d’auth ne peut pas traverser deux domaines DNS distincts (monsupersite.com ≠ domaineexterne1.com). C’est une limite cookie HTTP, pas quelque chose qu’un plugin peut contourner sans monter un système SSO complet (avec tokens + redirects), ce qui sort du périmètre de Login Armor.

Deux pistes pour vous selon ce que vous voulez :

1. Auth séparée par domaine externe (le plus simple)

Chaque sous-site garde son propre flow login. Vos admins se connectent directement sur domaineexterne1.com/<slug-du-sous-site>/, le cookie est posé sur domaineexterne1.com, le redirect post-login va sur domaineexterne1.com/wp-admin/. Login Armor stocke le slug en blog_option (per-site) et V2.1.9+ génère l’URL de login depuis site_url() — donc si vos sous-sites ont leur siteurl correctement mappé sur le domaine externe (cas standard du domain mapping), ça fonctionne sans rien faire de plus.

Si pour une raison X vous voulez forcer un hostname différent de site_url() (par exemple siteurl reste sur le réseau d’origine mais vous voulez que la page de login soit servie sur le domaine externe), le filtre login_armor_login_url_base introduit en V2.1.9 permet de l’overrider per-site. Snippet générique à laisser ici pour quiconque tombe sur ce thread avec un cas similaire — à déposer dans wp-content/mu-plugins/la-multisite-login-domain.php :

<?php
/**
 * Plugin Name: Login Armor — Per-Site Login Domain Override
 * Description: Override Login Armor's login URL hostname per blog_id
 *              when site_url() doesn't match where you want the login
 *              page to be served (typical: multisite + external domain
 *              mapping with siteurl on a different host than the public one).
 */
if ( ! defined( 'ABSPATH' ) ) { exit; }

add_filter( 'login_armor_login_url_base', function ( $url, $path, $scheme, $slug ) {
    $custom_hosts = [
        // blog_id => hostname (avec scheme)
        2 => 'https://domaineexterne1.com',
        3 => 'https://domaineexterne2.com',
        // une ligne par sous-site à customiser
    ];
    $blog_id = get_current_blog_id();
    if ( isset( $custom_hosts[ $blog_id ] ) ) {
        return $custom_hosts[ $blog_id ] . $path;
    }
    return $url; // default site_url() pour les autres
}, 10, 4 );

2. SSO centralisé sur admin.monsupersite.com

Tous les admins se connectent au même endroit puis sont redirigés vers leur sous-site via tokens. Le plugin WP MU Domain Mapping (gratuit, mature) propose exactement ça avec son option “Login Mapping”. C’est la voie standard pour ce cas, hors périmètre Login Armor.

Votre retour a directement déclenché V2.1.9 + V2.1.10 sur WP.org, encore merci. Bonne route !

Bonjour graphandco,

Merci pour ce retour très précis : c’est exactement le cas limite qu’on ne voit qu’avec un setup headless réel.

Vous avez raison sur toute la ligne. Login Armor utilisait home_url() pour générer l’URL de login alors que WordPress core lui-même utilise site_url() dans sa fonction wp_login_url(). C’est un héritage du fork d’origine du module Hide Login, et ça casse silencieusement dès que siteurl ≠ home (multisite headless, WordPress dans un sous-dossier /wp/, reverse-proxy avec WP_HOME ≠ WP_SITEURL). Sur les installs standard les deux valeurs sont identiques donc personne ne s’en rend compte.

C’est corrigé en 2.1.9, publiée à l’instant sur WP.org. Tout le flux Hide Login bascule sur site_url() (URL login, redirections, password-reset cookie scope, lostpassword, register, logout, lockout page, prévisualisation Settings). Côté multisite Network Admin, les liens “Dashboard” utilisaient déjà get_site_url($blog_id, $slug), ce qui était correct, donc rien à toucher de ce côté.

J’ai aussi ajouté un filtre login_armor_login_url_base au cas où vous auriez encore un setup plus exotique (3e hostname behind reverse-proxy, plugin de subdomain mapping qui réécrit l’admin URL) :

add_filter( 'login_armor_login_url_base', function( $url, $path, $scheme, $slug ) {
    // $url contient site_url($path, $scheme) par défaut
    return 'https://votre-hostname-custom.com' . $path;
}, 10, 4 );

Mettez à jour depuis Extensions > Mises à jour et l’URL de login devrait pointer sur admin.monsupersite.com/<votre-slug>/ comme attendu. Je suis preneur d’un retour si quelque chose cloche.

Merci d’avoir signalé : c’est notre premier retour terrain sur du multisite headless avec Login Armor, et ça aurait pu rester silencieux longtemps.

Hi martineva,
Thank you for your kind words, and congratulations on reaching 11/12 so quickly!

You’ve found a genuine bug : the GEO score check was looking for the organization data under the wrong internal key, so it could never detect it even when everything is properly configured.

I checked your site and I can confirm that everything is actually working perfectly on the front-end:

Your Organization schema (ProfessionalService) is properly generated with your name, address, phone, logo, sameAs, geo coordinates, etc.
Your Person schema for your author profile is there too
The Article schema correctly links author => publisher => organization
OGEEAT properly defers Open Graph to Yoast, no conflicts
So the only issue is the GEO score display : it shows 11/12 instead of 12/12. Your actual SEO structured data is already complete and correct.

I’ve already fixed it and it will be included in the next update (v2.2.1). In the meantime, you can safely ignore that one missing point : your organization is properly detected by search engines and AI.

Thanks for reporting this, first bug report and it’s a real one!