Bien gérer les balises Open Graph

Q: L'attribut prefix sur html a-t-il de l'importance ?

ogp.me spécifie le préfixe RDFa <html prefix="og: https://ogp.me/ns#"> comme faisant partie du protocole, donc incluez-le. Le guide Cards de X note qu'aucun balisage de ce genre n'est requis pour ses propres balises twitter:. N'attendez pas du préfixe qu'il répare une carte qui échoue pour une autre raison.

Que sont les balises Open Graph ?

Une page déclare ses balises Open Graph sous forme d'éléments <meta> placés dans son <head>, et ces éléments indiquent à un réseau social quel titre, quel type, quelle image et quelle URL mettre dans l'aperçu de lien quand quelqu'un partage la page. La page d'accueil du protocole, ogp.me, s'ouvre sur cette phrase : « The Open Graph protocol enables any web page to become a rich object in a social graph. » Le mécanisme est un crawler : le réseau récupère votre URL, analyse les éléments meta et construit une carte à partir de ce qu'il trouve au lieu de deviner d'après votre corps de texte. Écrivez les quatre balises obligatoires dans le head de chaque page que vous partagez, puis lancez le débogueur de chaque réseau sur l'URL en production.

Un développeur saisit des balises meta dans la section head d'une page sur un ordinateur portable.

Quelles balises Open Graph le protocole exige-t-il ?

Le protocole Open Graph exige quatre propriétés, et ogp.me les nomme og:title, og:type, og:image et og:url. Chacune reçoit une définition d'une ligne dans la spécification.

Propriété	Définition tirée de ogp.me	Valeur d'exemple
`og:title`	« The title of your object as it should appear within the graph »	Planifier des publications sur neuf réseaux
`og:type`	« The type of your object, e.g., 'video.movie' »	`article`
`og:image`	« An image URL which should represent your object within the graph »	`https://example.com/preview.png`
`og:url`	« The canonical URL of your object that will be used as its permanent ID »	`https://example.com/guide`

Au-delà de ces quatre, ogp.me liste des propriétés optionnelles dont og:description, og:site_name, og:locale, og:determiner, og:audio et og:video, plus des enfants structurés comme og:image:secure_url, og:image:type et og:image:alt. La spécification demande aussi un préfixe RDFa sur l'élément racine, <html prefix="og: https://ogp.me/ns#">.

<meta property="og:title" content="Scheduling posts across nine networks" />
<meta property="og:type" content="article" />
<meta property="og:image" content="https://example.com/preview.png" />
<meta property="og:url" content="https://example.com/guide" />
<meta property="og:description" content="What each network reads before it draws a card." />

Quels réseaux lisent les balises Open Graph et lesquels utilisent les leurs ?

Facebook, LinkedIn, Pinterest et Slack lisent directement les propriétés og:, et X lit d'abord son propre espace de noms twitter:. Cette division est le problème concret dès qu'une même page part vers plusieurs réseaux, parce qu'un jeu de balises qui satisfait un crawler peut en laisser un autre afficher une carte vide.

Destination	Ce qu'elle lit	Source
Facebook	propriétés og:	Le guide webmasters de Meta nomme og:url, og:title, og:description, og:image, og:type, og:locale, fb:app_id
LinkedIn	propriétés og:	Page d'aide de LinkedIn : le code source « needs to comply with Open Graph Protocol (OGP) »
Pinterest	propriétés og: ou schema.org	Présentation des Rich Pins par Pinterest : « the most common formats are Open Graph and Schema.org »
X	propriétés twitter:, avec repli sur og:	Guide Cards de X, archivé, cité plus bas
Slack	propriétés og: et métadonnées de carte X	Docs de Slack : le dépliage « looks for common OpenGraph and X (formerly known as Twitter) Card metadata »

Deux conséquences. Un réseau ne lit vos balises que si la publication porte un lien récupérable, donc un format de légende qui n'affiche jamais d'URL ne déclenche jamais de crawl. Et un réseau doté de son propre espace de noms le préfère, ce qui fait de la publication d'une même page partout un problème de métadonnées avant d'être un problème de planification. Le même soin vaut pour n'importe quel workflow de cross-posting : le texte voyage, pas le rendu.

Pourquoi og:url doit-elle être l'URL canonique ?

Le guide de partage de Meta définit og:url comme « The canonical URL for your page. This should be the undecorated URL, without session variables, user identifying parameters, or counters. » Le protocole appelle cette même propriété un identifiant permanent, donc chaque partage d'une variante trackée se replie sur la seule adresse que vous avez déclarée. Mettez dans og:url l'adresse canonique propre, gardez les paramètres de campagne dans le lien partagé et hors de la balise, et lisez le volet campagne séparément quand vous suivez le trafic des réseaux sociaux.

Le même guide définit og:title comme « The title of your article without any branding such as your site name, » parce que Facebook imprime déjà le domaine sur la carte.

Comment X passe-t-il des balises twitter: aux balises og: ?

Le processeur de cartes de X cherche d'abord la propriété twitter: et utilise l'équivalent Open Graph quand la version twitter: manque. X ne publie plus son guide Cards, et l'ancienne URL développeur redirige aujourd'hui vers une page de présentation générique, donc chaque citation ici vient de la capture archivée de décembre 2023 de ce guide et décrit le comportement que X a documenté en dernier. La règle y était formulée ainsi : « When the Twitter card processor looks for tags on a page, it first checks for the Twitter-specific property, and if not present, falls back to the supported Open Graph property. » La seule propriété sans équivalent Open Graph est twitter:card elle-même, décrite comme « The card type, which will be one of 'summary', 'summary_large_image', 'app', or 'player'. »

Deux détails de syntaxe découlent de ce guide. X n'a besoin d'aucun préfixe RDFa, et bien que ses balises utilisent name et content, « Twitter's parser will fall back to using property and content, so there is no need to modify existing Open Graph protocol markup if it already exists. » Au-dessus d'un jeu Open Graph correct, une seule balise supplémentaire couvre X.

<meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:site" content="@yourhandle" />

Combien de temps les plateformes gardent-elles en cache ce qu'elles ont scrapé ?

Facebook et X mettent tous deux le scrape en cache, sur des horloges différentes. La page de bonnes pratiques de Meta propose le Sharing Debugger aux sites qui « need to update them more often than the standard 24 hour update period. » Le guide Cards archivé dit : « Content is cached by Twitter for 7 days after a link to a page with card markup has been published in a Tweet. » Corrigez vos balises avant que le lien parte, parce qu'après son départ vous attendez le cache de quelqu'un d'autre.

Une main faisant défiler un fil d'actualité sur un smartphone, l'écran où apparaît une carte d'aperçu de lien.

Comment vérifier ce qu'un crawler voit vraiment ?

Chaque réseau publie un débogueur qui récupère votre URL comme le ferait son propre crawler et imprime les balises qu'il a analysées. La documentation de Meta dit que son Sharing Debugger « will show which meta tags the crawler scrapes as well as any errors or warnings, » et la même exécution met votre image en cache à l'avance. Pointez-le sur l'URL exacte que vous allez publier, pas sur une copie de préproduction, puis recommencez après chaque modification du head.

Les crawlers sont identifiables dans les logs serveur et les règles robots. Meta liste des user agents dont facebookexternalhit/1.1 et meta-externalagent/1.1, et X utilise « the User-Agent of Twitterbot (with version, such as Twitterbot/1.0). » Son guide avertit que « if a page with card markup is blocked, no card will be shown. »

Qu'est-ce qui rate avec les balises Open Graph ?

Quatre modes d'échec expliquent la plupart des aperçus vides ou faux, et aucun n'est visible dans un navigateur. Un crawler bloqué est le premier, et la page d'aide de LinkedIn le nomme : si une image respecte les exigences et n'apparaît toujours pas, « your website may be blocking us from pulling the image or the image may be located on a protected directory or website. » Le deuxième est le placement, puisque la documentation crawler de Meta affirme que « any Open Graph properties need to be listed before the first 1 MB of your website or app, or it will be cutoff. » Le troisième est un cache périmé. Le quatrième est un chemin d'image relatif, parce que og:image est définie comme une URL d'image et qu'un crawler sur un autre hôte n'a aucune base pour la résoudre.

AdaptlyPost

–

Planifiez vos contenus sur toutes les plateformes

Essai gratuit de 7 jours

Analyses multiplateforme

Boîte sociale

Assistant IA

Pinterest se tient à l'écart de ces quatre cas, parce que les Rich Pins traitent vos métadonnées comme du contenu structuré et pas seulement comme un aperçu, sujet traité à part dans ce guide des Rich Pins. Régler le head une bonne fois est la partie la moins chère de l'optimisation des réseaux sociaux. Quand le même lien part vers plusieurs destinations, adaptlypost publie un post sur plusieurs comptes à la fois, donc le travail sur les balises reste sur votre page et la distribution se fait à un seul endroit. Le rendu appartient toujours à chaque réseau, et c'est le point à emporter dans n'importe quelle stratégie de cross-posting.

Quatre façons dont un aperçu peut casser

Crawler bloquéLes règles robots ou le serveur empêchent le crawler de récupérer l'image

Placement tardifLes balises Open Graph arrivent après le premier 1 Mo de la page et sont coupées

Cache obsolèteLe réseau affiche encore ce qu'il a scrapé avant ta dernière modification

Chemin d'image relatifog:image n'a pas d'URL de base à partir de laquelle un autre hôte peut résoudre

Quatre défaillances expliquent la plupart des aperçus vides ou incorrects, et aucune ne se voit dans un navigateur.

Foire aux questions

Ai-je besoin de og:description si le protocole ne l'exige pas ?

ogp.me liste og:description comme optionnelle, donc une page qui s'en passe respecte quand même le protocole. Le guide de partage de Meta la décrit comme le texte affiché sous le titre sur Facebook, donc la sauter revient à confier au réseau une décision que vous auriez pu prendre. Écrivez-la.

Puis-je utiliser des balises Open Graph et des balises twitter: sur la même page ?

Oui, et le guide Cards archivé de X appelait cela le montage prévu : définir les deux « minimizes the amount of duplicate markup required to describe content and experience. » Le processeur lit la propriété twitter: quand elle existe et la propriété og: quand elle n'existe pas. Ajouter twitter:card par-dessus un jeu Open Graph complet suffit pour X.

Que se passe-t-il si og:url pointe ailleurs que sur la page elle-même ?

Le réseau construit sa carte pour l'adresse inscrite dans og:url, que ogp.me définit comme « The canonical URL of your object that will be used as its permanent ID. » Un écart envoie chaque partageur sur une page différente de celle qu'il lisait. Gardez og:url égale à l'adresse canonique de la page qui porte la balise.

Pourquoi mon aperçu affiche-t-il encore l'ancien titre après correction de la balise ?

Les réseaux mettent le scrape en cache. La page de bonnes pratiques de Meta évoque une « standard 24 hour update period » et propose le Sharing Debugger pour rafraîchir plus tôt, et le guide Cards archivé de X donnait 7 jours à partir du moment où un lien est publié dans un post. Lancez le débogueur concerné, puis repartagez.

L'attribut prefix sur html a-t-il de l'importance ?

ogp.me spécifie le préfixe RDFa <html prefix="og: https://ogp.me/ns#"> comme faisant partie du protocole, donc incluez-le. Le guide Cards de X note qu'aucun balisage de ce genre n'est requis pour ses propres balises twitter:. N'attendez pas du préfixe qu'il répare une carte qui échoue pour une autre raison.

Que font les réseaux quand og:image manque ?

Le protocole ne définit aucun repli, donc le comportement appartient à chaque réseau et à son crawler. La documentation de Slack décrit le dépliage classique comme un crawl de l'URL à la recherche de métadonnées Open Graph et de carte X, avec le rendu de « some micro-approximation of the content, » ce qui décrit honnêtement ce qu'un réseau fait d'un jeu incomplet. Fournissez og:image et gardez ce choix hors d'une heuristique.

Que mettre dans og:type si la page n'est pas un article ?

ogp.me définit og:type comme le type de l'objet et donne video.movie en exemple, la valeur doit donc correspondre à ce qu'est réellement la page. Le tableau de ce guide utilise article pour un billet de blog, mais ce n'est qu'une des valeurs que le protocole accepte. Mets dans og:type le type qui décrit vraiment l'objet de la page.

og:title doit-il inclure le nom de ma marque ?

Le guide de partage de Meta définit og:title comme « le titre de votre article sans élément de marque tel que le nom de votre site », parce que Facebook affiche déjà le domaine sur la carte. Ajouter ta marque là ne fait que répéter ce que le réseau montre déjà de lui-même. Laisse og:title au titre seul et laisse le réseau gérer le domaine.

Un réseau construit-il un aperçu à partir d'une publication sans lien ?

Un réseau ne lit tes balises que si la publication porte un lien exploitable, un format de légende qui n'affiche jamais d'URL ne déclenche donc jamais de crawl. Sans lien, le crawler n'a rien à récupérer, même si le reste des balises est complet. Mets l'URL dans la publication elle-même, pas seulement dans une image ou un texte de légende.

Comment repérer le crawler d'un réseau dans mes logs serveur ?

Meta liste des user agents comme facebookexternalhit/1.1 et meta-externalagent/1.1, identifiables dans les logs serveur et les règles robots. X utilise le user agent de Twitterbot, avec un numéro de version, par exemple Twitterbot/1.0. Chercher ces chaînes montre si le crawler a atteint la page, puisque le guide de X prévient qu'une page bloquée n'affiche aucune carte.