Vérifiez vos cartes de partage avant de publier
Dernière mise à jour:
Une carte de partage est le petit aperçu — un titre, une description et une image — qu’un réseau social ou une application de messagerie construit lorsque quelqu’un colle un lien vers votre page. Pour la plupart des personnes qui rencontreront cette page, la carte est la seule version qu’elles verront : elles la croisent en plein défilement, la jugent en environ une seconde et décident si la page derrière elle mérite un toucher. Le côté inconfortable, c’est que les échecs de carte sont silencieux. Votre page peut sembler parfaite dans votre propre navigateur pendant que sa carte n’affiche aucune image, un titre du mois dernier ou une description coupée au milieu d’un mot, parce que la carte ne se construit pas à partir de ce que vous voyez à l’écran — elle se construit à partir d’une poignée de balises meta dans le head de la page, récupérées une seule fois par un scraper que vous ne regardez jamais. Alors, avant de publier quoi que ce soit que vous comptez partager, passez l’URL du brouillon dans le vérificateur Open Graph et regardez votre page comme vos lecteurs la verront : sous la forme de quatre petites cartes.
Le lien est la publicité
Quand un lien est collé dans un fil social ou une conversation, aucun humain ne visite votre page en premier. La plateforme envoie un scraper — un petit crawler impatient — qui récupère la page une fois et construit la carte à partir des balises meta qu’il trouve dans le head. Personne dans cette chaîne ne voit votre mise en page, votre typographie, votre section héroïque soigneusement réglée ni la capture d’écran placée au-dessus du pli. Ils voient exactement trois champs et une image : og:title, og:description et og:image. Si ces trois-là sont faux, absents ou périmés, alors, aux yeux de votre public, votre page est fausse, absente ou périmée — la belle page derrière la carte n’a jamais l’occasion de corriger l’impression.
La carte est aussi têtue. Les plateformes mettent ce scrape en cache, généralement contre l’URL exacte, si bien que la première version construite par un scraper est souvent celle qui continue d’être partagée pendant des semaines ou des mois, longtemps après que vous avez modifié la page. C’est pourquoi une carte de partage mérite le même respect qu’un visuel publicitaire : pour un billet dont tout l’objet est d’être partagé, le lien est la publicité, et les balises meta sont le texte. Les écrire comme une formalité — ou laisser un générateur de site les remplir avec le texte qui se trouve par hasard à côté — revient à lancer une campagne dont personne n’a relu le visuel.
Ce que chaque plateforme lit réellement
Commencez par la base. Facebook et LinkedIn lisent Open Graph : og:title, og:description, og:image, og:url et og:type, tels que les définit le protocole Open Graph. Si ces cinq sont présents et sensés, les deux plus grandes surfaces de partage professionnelles sont couvertes. X lit d’abord ses propres balises Twitter Card — twitter:card, twitter:title, twitter:description, twitter:image — et se rabat sur les équivalents Open Graph quand les balises Twitter sont absentes. Slack lit Open Graph en premier, avec les balises Twitter Card comme repli. Autrement dit, les plateformes sont d’accord sur les ingrédients et légèrement en désaccord sur l’étagère vers laquelle elles se tournent d’abord.
Partout, le dernier recours est le même : le simple élément <title> et la meta description, appelés en renfort quand ni Open Graph ni les balises Twitter n’existent. Ce repli compte pour la façon dont vous lisez n’importe quel vérificateur, y compris le nôtre. Quand un outil vous montre le titre d’une carte, la question honnête est d’où vient la valeur — d’une balise dédiée que vous avez écrite exprès, ou d’un repli sauvé d’un élément title écrit pour une page de résultats de recherche et un budget de caractères que votre carte ne partage pas. Un vérificateur qui substitue les replis en silence et les présente comme des balises vous ment par omission, et c’est pourquoi le vérificateur Open Graph étiquette chaque repli comme un repli au lieu de prétendre que la balise existe.
Les échecs qui donnent des cartes cassées
Le classique, c’est l’og:image relatif. La balise dit content="/images/share.png" — un chemin, pas une URL — et cela fonctionne dans votre navigateur, parce que le navigateur sait sur quel site il se trouve. Un scraper ne le résoudra pas : il veut une URL complète et absolue commençant par https://, et quand il ne l’obtient pas, il construit simplement une carte sans image, devant laquelle les lecteurs défilent sans jamais savoir ce qu’ils ont manqué. Juste derrière vient l’image qui existe mais ne convient pas : bien plus petite que les 1200×630 pixels recommandés par les plateformes, ou dans un ratio que le recadrage centré transforme en absurdité. Traitez 1200×630 pour ce que c’est — un conseil de plateforme largement publié, pas une norme que quiconque a ratifiée — mais un conseil ignoré reste une carte dont le titre est coupé hors de l’image.
Le reste est plus discret. Une balise twitter:card absente signifie que X se rabat sur une petite carte de résumé — une miniature à côté du texte — même lorsque vous avez fourni une grande et belle image et attendiez le traitement pleine largeur de summary_large_image. Les valeurs de balise vides sont pires que les balises absentes : un og:title avec content="" ne déclenche pas le repli, il l’écrase avec du vide. Et un mauvais og:url — pointant vers le domaine de préproduction, la page d’accueil ou l’article de la semaine dernière, comme le font si souvent les modèles copiés — dit à chaque plateforme que la page canonique est ailleurs, éparpillant partages, compteurs et entrées de cache loin de la page que vous avez réellement publiée.
Pourquoi l’ancienne carte continue de s’afficher après votre correction des balises
Vous avez corrigé les balises, redéployé, recollé le lien — et l’ancien titre est toujours là, à vous sourire. Rien n’est cassé. Chaque plateforme met en cache la carte qu’elle a construite contre votre URL, et ce cache ne surveille pas votre site à la recherche de changements ; du point de vue de la plateforme, elle sait déjà à quoi ressemble votre page, et re-récupérer chaque URL à chaque partage représenterait une énorme quantité d’exploration pour très peu de bénéfice. La carte périmée n’est pas la preuve que votre correction a échoué. C’est la preuve que le cache n’a pas été invité à regarder à nouveau — et tant qu’il ne l’est pas, chaque collègue et chaque lecteur qui partage le lien ressert l’ancien scrape.
Alors dites-le-lui. Chaque grande plateforme offre un moyen de forcer un nouveau scrape d’une URL unique : le Sharing Debugger de Facebook et le Post Inspector de LinkedIn re-récupèrent la page et vous montrent la carte qu’ils ont reconstruite — X proposait historiquement un validateur de cartes pour le même travail. Passez votre URL dans l’outil approprié après toute correction de balises et confirmez la nouvelle carte avant d’annoncer le billet. Là où aucun outil de re-scrape n’existe, changer l’URL change la clé de cache : ajouter une chaîne de requête comme ?v=2 fait traiter le lien par la plateforme comme un lien qu’elle n’a jamais vu, une astuce parfaitement respectable pour un partage ponctuel. Et gardez un peu de patience en réserve — les caches peuvent mettre un moment à lâcher prise même après un re-scrape, alors vérifiez, attendez et vérifiez encore une fois avant de commencer à modifier des balises qui étaient déjà correctes.
Une routine de deux minutes avant publication
Faites-en une routine, pas une enquête. Un : collez l’URL du brouillon dans le vérificateur Open Graph — l’URL de préproduction ou d’aperçu convient, tant que c’est la page que les scrapers récupéreront. Deux : confirmez que les quatre cartes — Facebook, X, LinkedIn et Slack — affichent le titre, la description et l’image que vous vouliez, et notez tout ce qui est étiqueté comme repli, parce qu’un repli choisi est acceptable et un repli sur lequel vous avez trébuché est une balise qui attend d’être écrite. Trois : confirmez que l’URL de l’image est absolue et que l’image elle-même mesure au moins 1200×630. Quatre : confirmez que twitter:card vaut summary_large_image partout où vous voulez le grand format sur X, et que og:url nomme la page canonique que vous êtes sur le point de publier.
Cinq : publiez — puis collez vous-même le lien quelque part une fois, pour forcer le premier scrape pendant que vous regardez encore, et observez la carte qui revient. Si elle est périmée ou fausse, re-scrapez-la avec l’outil propre à la plateforme au lieu de modifier en panique. Deux minutes, cinq étapes, et la version de votre page que la plupart des gens verront jamais est une version que vous avez réellement approuvée. Pour le balayage plus large avant publication — TLS, en-têtes de sécurité, redirections, le reste des vérifications de routine qu’une page mérite avant de sortir — exécutez à côté la vérification de santé du site web ; les cartes sont la porte d’entrée, mais ce n’est pas toute la maison.