Comment forcer une image de partage par article avec Yoast SEO ?

Un article partagé sans image, ou avec la mauvaise image, perd une grande partie de son attrait dans un fil de discussion. Yoast SEO gère très bien ce sujet, mais son fonctionnement repose sur une cascade de sources qui n'est pas évidente, et beaucoup de sites finissent avec une image de partage unique pour l'ensemble du contenu sans que personne ne comprenne pourquoi. Maîtriser l'image Open Graph par article demande de connaître cet ordre de priorité, les formats réellement attendus par les plateformes, et surtout la manière dont elles mettent en cache ce qu'elles ont vu la première fois. Ce dernier point explique à lui seul la majorité des situations où une correction pourtant effectuée ne se voit nulle part.

La cascade des sources d'image

Yoast détermine l'image de partage en interrogeant plusieurs sources dans un ordre précis, et s'arrête à la première qui répond. Comprendre cet ordre permet d'agir au bon niveau plutôt que d'empiler des réglages qui se neutralisent. C'est la même logique de priorité que celle qui gouverne les autres champs de l'extension, décrite dans notre article sur la manière de compléter la meta box de Yoast.

L'image définie explicitement sur le contenu

Le premier niveau est le champ dédié de l'onglet social de l'extension, rempli article par article. Il l'emporte sur tout le reste, et c'est exactement ce qu'on attend d'un réglage explicite. Ce champ est distinct de l'image à la une, ce qui permet de choisir un visuel spécifiquement composé pour le partage, avec un cadrage différent et éventuellement un texte incrusté, sans modifier l'illustration affichée sur le site. Deux champs existent en réalité, l'un pour les réseaux qui suivent le protocole Open Graph, l'autre pour la carte de partage de X, et l'un peut hériter de l'autre.

L'image à la une du contenu

À défaut d'image sociale explicite, Yoast reprend l'image à la une, ce qui couvre correctement la grande majorité des cas et constitue le comportement souhaitable par défaut. C'est aussi la raison pour laquelle un site dont les articles n'ont pas d'image à la une tombe systématiquement sur le niveau suivant, et affiche partout le même visuel. Sur un site existant, vérifier d'abord la couverture en images à la une règle donc le problème plus efficacement que n'importe quel réglage.

L'image de repli définie globalement

Le troisième niveau est l'image par défaut renseignée dans les réglages généraux de l'extension. Elle a son utilité pour les pages qui n'ont légitimement aucune illustration propre, mais elle devient un problème dès qu'elle apparaît sur des dizaines d'articles. Un repli bien pensé porte une identité de marque neutre plutôt qu'un visuel qui semble décrire le contenu, précisément parce qu'il sera associé à des sujets très différents.

Ce que Yoast ne fait pas

Contrairement à une idée répandue, l'extension ne va pas chercher la première image du corps de l'article. Ce comportement existait dans d'anciennes versions ou dans d'autres outils, et son absence surprend souvent. Si l'on souhaite ce fonctionnement, il faut l'ajouter soi même par un filtre, ce qui est parfaitement possible et se justifie sur les sites dont beaucoup d'articles anciens contiennent des illustrations sans avoir d'image à la une.

Les conflits avec le thème et les autres extensions

Un cas fréquent brouille complètement cette cascade : la présence d'une seconde source de balises de partage. Beaucoup de thèmes commerciaux en produisent d'origine, certaines extensions de partage social en ajoutent également, et le résultat est une page qui déclare deux images différentes. Les plateformes choisissent alors, en général la première rencontrée, ce qui donne l'impression que les réglages de Yoast sont ignorés. Le diagnostic est immédiat en lisant le code source de la page et en comptant les occurrences de la balise concernée : il ne doit y en avoir qu'une seule. La correction consiste à désactiver la source redondante, dans les options du thème quand elles le permettent, ou par un filtre qui supprime l'ajout concurrent, et jamais en désactivant celle de Yoast, qui est la seule pilotable contenu par contenu.

Choisir une image qui fonctionne réellement

Une image déclarée n'est pas une image affichée. Les plateformes appliquent leurs propres contraintes de format, de poids et d'accessibilité, et rejettent silencieusement ce qui ne leur convient pas. Ces contraintes complètent les principes généraux exposés dans notre article sur les balises Open Graph.

Les dimensions attendues

Le format de référence reste un rapport large, autour de mille deux cents pixels par six cent trente, qui donne un affichage en grande carte sur la plupart des réseaux. En dessous d'une certaine largeur, la plupart des plateformes basculent sur un affichage en vignette réduite, nettement moins visible dans un fil. Une image carrée n'est pas fausse mais produit un rendu très différent, souvent recadré de manière imprévisible, et il vaut mieux la réserver aux contextes où on l'a explicitement choisie.

Le poids et le format de fichier

Les plateformes imposent un poids maximal, généralement de quelques mégaoctets, et refusent au delà. Elles acceptent les formats classiques, et leur prise en charge des formats plus récents reste inégale : une image de partage au format le plus moderne peut parfaitement s'afficher sur le site et ne rien produire dans un aperçu de partage. C'est un cas où la prudence commande de ne pas généraliser un format à toute la médiathèque sans vérifier ce point précis, quitte à conserver une version classique dédiée au partage.

L'adresse doit être absolue et publique

Une image de partage déclarée avec une adresse relative n'est comprise par aucune plateforme. Elle doit être absolue, servie en HTTPS, accessible sans authentification et sans redirection. Ce dernier point piège les sites qui viennent de changer de domaine ou de structure : l'image répond bien, mais après une redirection, et plusieurs plateformes abandonnent dans ce cas. Une image hébergée sur un service tiers qui limite les requêtes automatisées pose le même type de problème.

Le texte dans l'image

Incruster un titre dans l'image de partage améliore nettement la lisibilité dans un fil, à condition de rester lisible en très petite taille et de ne pas dépendre du texte pour comprendre le visuel. Cette pratique impose en revanche de produire une image par article, ce qui suppose soit un travail manuel, soit une génération automatique. Elle rend aussi la traduction impossible et interdit toute réutilisation du visuel ailleurs, ce qui doit entrer dans la décision.

Le texte alternatif et le titre de la carte

L'image n'est qu'une partie de l'aperçu. Le titre et la description utilisés par les plateformes proviennent également de l'extension, avec leur propre cascade, et ils peuvent être définis indépendamment du titre de la page et de la méta description. Cette séparation est utile : un titre de partage peut être plus accrocheur et moins littéral qu'un titre destiné aux résultats de recherche, sans nuire à ce dernier. La carte de X accepte par ailleurs un texte alternatif pour l'image, souvent oublié, qui est le seul élément d'accessibilité disponible dans un aperçu de partage et qui ne coûte rien à renseigner.

Décliner par réseau quand cela en vaut la peine

Rien n'oblige à servir la même image partout, et l'extension permet de distinguer au moins deux cas. Cette possibilité mérite d'être utilisée avec parcimonie : elle double le travail de production et le nombre de fichiers à maintenir, pour un gain qui n'est réel que sur les contenus effectivement partagés en volume. La règle raisonnable consiste à servir une image unique par défaut, et à ne décliner que pour une poignée de contenus stratégiques, une page d'offre ou un article destiné à une campagne, où la différence de cadrage entre les réseaux justifie l'effort.

Le cache des plateformes, source de la plupart des surprises

C'est le point qui fait perdre le plus de temps, parce qu'il donne l'impression que la correction n'a pas fonctionné. Chaque plateforme conserve pendant plusieurs jours ce qu'elle a lu la première fois qu'une adresse a été partagée, et ne revient pas d'elle même vérifier.

Comprendre ce qui est mis en cache

Ce n'est pas seulement l'image qui est mémorisée mais l'ensemble des métadonnées de partage : titre, description, type et image. Une correction du titre subit donc exactement le même délai. Sur certaines plateformes, la durée de conservation dépasse la semaine, et sur d'autres l'aperçu est figé au premier partage de l'adresse, ce qui est particulièrement pénible pour un article publié puis corrigé dans la foulée.

Forcer la relecture

Chaque grande plateforme met à disposition un outil de débogage qui affiche ce qu'elle a lu et permet de demander une nouvelle lecture. C'est le seul moyen fiable de voir apparaître une correction immédiatement, et c'est aussi le meilleur outil de diagnostic, puisqu'il indique précisément quelles balises ont été trouvées et lesquelles posent problème. Prendre l'habitude de passer chaque nouvel article dans cet outil au moment de la publication évite la totalité de ces incidents.

Le cas de la republication

Modifier un article ancien et le repartager n'entraîne aucune relecture automatique, y compris si la date de publication est mise à jour. Une adresse déjà connue reste associée à son aperçu initial. La seule solution propre reste la demande explicite de relecture ; changer l'adresse de l'article pour contourner le problème est une très mauvaise idée, qui casse les liens existants et l'historique de la page pour un bénéfice cosmétique.

Vérifier ce que le serveur envoie réellement

Avant d'incriminer le cache, il faut s'assurer que la page sert bien les balises attendues, ce qui se vérifie en lisant le code source servi par le serveur et non l'inspecteur du navigateur. Les métadonnées de partage doivent être présentes dès la source, car les plateformes n'exécutent pas les scripts de la page. Une extension qui les injecterait après coup produirait un aperçu vide, quelle que soit la qualité de l'image choisie.

Vérifier sur plusieurs plateformes, pas une seule

Les plateformes n'appliquent ni les mêmes contraintes ni les mêmes replis, et un aperçu correct sur l'une ne garantit rien sur les autres. Certaines acceptent le format carré, d'autres recadrent systématiquement en large ; certaines lisent les balises du protocole Open Graph, d'autres cherchent d'abord leurs propres balises et ne se rabattent sur les premières qu'en dernier recours ; les messageries instantanées, qui représentent une part importante des partages réels, ont chacune leur comportement. Un contrôle sur trois plateformes différentes au moment de la mise en place suffit à repérer les écarts, et se refait ensuite uniquement en cas de changement de format d'images.

Traiter le sujet à l'échelle d'un site entier

Régler un article prend une minute, régler quinze cents articles demande une méthode. La bonne nouvelle est que le travail se scripte largement, et qu'il produit un résultat durable si l'on installe en même temps le contrôle qui l'entretient.

Mesurer d'abord la couverture

Le premier geste consiste à compter combien d'articles ont une image à la une, combien ont une image sociale explicite, et combien tombent sur le repli global. Cette mesure se fait par une requête simple sur les métadonnées et donne immédiatement l'ampleur du chantier. Elle gagne à être croisée avec le trafic : sur un site de contenu, quelques centaines d'articles concentrent l'essentiel des partages, et ce sont eux qu'il faut traiter en premier. Cette mesure a aussi un intérêt en soi : elle donne un chiffre à présenter, et il est bien plus facile de faire accepter une journée de production de visuels quand on peut annoncer que quatre cent soixante articles se partagent aujourd'hui avec la même image générique.

Automatiser le repli sur la première image du contenu

Pour les articles anciens dépourvus d'image à la une mais riches en illustrations, un filtre appliqué à la sortie de l'extension permet de reprendre la première image du corps du texte. Ce filtre doit vérifier que l'image existe, qu'elle est hébergée sur le site et qu'elle atteint la largeur minimale, faute de quoi il remplacerait un repli correct par une icône de quarante pixels. Écrit avec ces précautions, il traite en une fois des centaines d'articles sans aucune saisie.

Suivre l'état dans la liste des articles

Le suivi devient beaucoup plus simple si l'information est visible directement dans le tableau d'administration, ce qui se met en place comme décrit dans notre article sur la manière d'ajouter une colonne personnalisée à la liste des articles. Une colonne indiquant la source réellement retenue pour l'image de partage permet de trier, de filtrer et de traiter par lots, ce qui transforme un contrôle fastidieux en tâche de quelques minutes. La même colonne sert ensuite de tableau de bord permanent, puisqu'un article publié sans image y apparaît immédiatement, sans qu'aucun audit ne soit nécessaire.

Contrôler à la publication plutôt qu'après

La dernière mesure est préventive : bloquer ou signaler la publication d'un article dépourvu d'image à la une. Un message d'avertissement dans l'écran d'édition suffit dans la plupart des équipes, et évite de reconstituer le retard plus tard. C'est le même principe que pour les autres champs de référencement, et il fonctionne pour la même raison : le coût de renseigner un champ au moment de la rédaction est sans commune mesure avec celui de le rattraper sur quinze cents contenus. Le message doit rester un avertissement plutôt qu'un blocage dur, faute de quoi il finit par être contourné par une image quelconque déposée à la hâte, ce qui est exactement le résultat qu'on cherchait à éviter.

Générer les visuels de partage automatiquement

Sur un site qui publie beaucoup, la production manuelle d'un visuel par article finit par céder. La génération automatique d'une image de partage, composée à partir du titre de l'article, d'un fond aux couleurs de la marque et éventuellement d'une illustration existante, résout durablement le problème. Elle se met en place de deux manières : une génération à la publication, qui produit un fichier stocké dans la médiathèque et se comporte ensuite comme n'importe quelle image, ou une génération à la volée par une adresse dédiée, plus souple mais qui doit impérativement mettre son résultat en cache, les plateformes n'attendant pas plusieurs secondes. La première approche est préférable dans la plupart des cas, parce qu'elle produit un fichier réel, visible, corrigeable à la main quand le titre se prête mal à la composition automatique. Le fichier produit se range dans la médiathèque comme n'importe quelle autre image, ce qui le rend remplaçable sans intervention technique.