Image OG non enregistrée

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,
Content que l’Open Graph soit rentré dans l’ordre. Vos questions tombent bien : deux d’entre elles portent sur de vrais défauts de l’extension, que vous venez de mettre au jour.

Une seule image Open Graph pour tout le site

Oui, en une seule manipulation. Dans les réglages d’OGEEAT, le champ « Image OG par défaut » sert exactement à cela. L’extension applique alors cet ordre, du plus précis au plus général :

1. l’image saisie dans le panneau OGEEAT de la page ;
2. sinon, l’image mise en avant de la page ;
3. sinon, l’image par défaut des réglages.

Vous n’avez donc rien à faire page par page : renseignez l’image par défaut, et toutes les pages qui n’ont ni image OGEEAT ni image mise en avant l’utiliseront.

Sur la crainte de pénalité, vous pouvez être tranquille : aucune. L’image Open Graph ne sert qu’à l’aperçu lors d’un partage, elle n’entre dans aucun critère de classement. Le seul inconvénient est visuel : tous vos partages se ressembleront. Sur un site de quelques pages, c’est un choix parfaitement défendable.

WP Rocket et le robots.txt

Je me suis mal exprimé la première fois, et votre question est légitime. WP Rocket ne contourne pas le robots.txt. Ce sont deux mécanismes distincts, et un seul des deux est affecté par le cache.

Le robots.txt est un fichier unique, servi à la racine du site, indépendant des pages. WP Rocket n’y touche pas. Les règles qu’OGEEAT y ajoute restent valables en toutes circonstances.

L’en-tête HTTP, lui, est envoyé page par page par WordPress au moment où il construit la réponse. Or une page servie depuis le cache de WP Rocket ne passe justement plus par WordPress : le fichier est renvoyé tel quel. L’en-tête n’est donc pas envoyé sur ces pages.

Autrement dit : votre robots.txt fonctionne, l’en-tête complémentaire manque sur les pages en cache. Comme les robots indélicats ignorent de toute façon les deux, cela ne change pas grand-chose à votre cas ByteDance, où seule une règle au niveau du serveur ou du CDN sera efficace.

Une précision utile puisque vous venez de vérifier votre robots.txt : celui d’OGEEAT est virtuel, c’est WordPress qui le génère à la volée. Si un fichier robots.txt physique existe à la racine de votre site, c’est lui qui est servi et les règles d’OGEEAT n’apparaissent jamais. Depuis la 2.6.12, l’extension vous avertit explicitement quand ce cas se présente.

Le score GEO et les pages

Les pages sont bien prises en charge. Dans les réglages, la ligne « Types de contenu : Metabox » coche Articles et Pages par défaut : si vos pages sont cochées, le score GEO s’affiche bien dans le panneau de chaque page.

Ce que vous constatez vient d’ailleurs, et c’est un défaut de l’extension : l’écran d’audit groupé, la liste qui recense tout ce qu’il reste à corriger, ne listait que les articles. Sur un site fait uniquement de pages, cet écran est donc resté vide, ce qui donne exactement l’impression que vous décrivez.

C’est corrigé dans la 2.6.14, qui sortira dans les prochains jours : l’audit groupé recense désormais tous les types de contenu gérés, pages comprises.

Le score de fraîcheur à zéro

Votre intuition est la bonne, et là encore le fautif est l’extension, pas votre site.

Le calcul de la fraîcheur ne regardait que les articles. Un site composé uniquement de pages obtenait donc zéro, quel que soit son rythme de publication, et sans aucun moyen de faire mieux. C’est corrigé dans la même 2.6.14.

Deux choses à savoir en attendant :

Le critère est la date de modification, pas la date de publication. Modifier les dates de publication de vos pages n’aura donc aucun effet sur ce score, et vous pouvez les remettre comme elles étaient. Le simple fait de mettre à jour une page suffit à la rendre « fraîche » aux yeux du calcul, qui retient les contenus modifiés depuis moins de 90 jours.

Et gardez la mesure : la fraîcheur ne compte que pour 5 % du score de visibilité IA. L’essentiel se joue sur le trafic en provenance des IA (40 %) et le passage de leurs robots (35 %). Une fois la 2.6.14 installée, votre score montera donc de quelques points, pas de vingt.

Merci pour ces questions : deux corrections de la prochaine version viennent directement de votre message.

Fabrice