Balises meta Open Graph : le guide complet des aperçus de liens sociaux
Les balises meta Open Graph sont des balises <meta property="og:…"> que vous placez dans le <head> d’une page HTML. Elles contrôlent le titre, la description et l’image affichés lorsqu’une personne partage votre lien sur Facebook, LinkedIn, Slack, Discord, WhatsApp et la plupart des autres plateformes. Définissez-les une fois et presque tous les réseaux affichent un aperçu enrichi au lieu d’une URL nue. X (Twitter) lit ses propres balises Twitter Card, mais bascule sur vos balises Open Graph lorsque la balise correspondante est absente : un seul jeu de balises bien conçu couvre donc presque tous les endroits où un lien peut circuler.
Ce protocole décide si votre lien s’affiche avec un titre, un résumé et une image nette en 1200×630, ou comme une adresse brute sur laquelle personne ne clique.
Ce guide passe en revue l’ensemble des balises meta pour le partage social : les quatre balises Open Graph obligatoires, les règles de dimensionnement d’og:image, le repli sur la Twitter Card, la façon dont chaque plateforme affiche et met en cache les aperçus, les erreurs qui laissent les partages vides, et comment déboguer le résultat une fois en production.
Que sont les balises meta Open Graph ?
Open Graph est un protocole ouvert, créé à l’origine chez Facebook et documenté sur ogp.me, qui permet à n’importe quelle page web de se décrire comme un objet enrichi. Plutôt que de deviner le sujet de votre lien, une plateforme lit une poignée de balises et les transforme en carte d’aperçu.
La syntaxe est une simple balise meta HTML dotée d’un attribut property et d’une valeur content, placée dans le <head> du document :
<meta property="og:title" content="How Open Graph Tags Work">Remarquez l’attribut property. Les balises meta HTML classiques dédiées au SEO (la meta description, robots, viewport) utilisent name. Open Graph utilise property, et Twitter Card revient à name. Bien choisir cet attribut compte : un robot qui attend property="og:title" ne lira pas name="og:title".
Presque toutes les plateformes qui transforment un lien en carte lisent Open Graph : Facebook, LinkedIn, Slack, Discord, WhatsApp, Pinterest et Telegram le parlent tous. X est l’exception notable. Il privilégie ses propres balises twitter:*, mais bascule sur vos balises og:* pour tout ce qu’il ne trouve pas, ce qui explique pourquoi vous avez rarement besoin de les dupliquer.
Open Graph accompagne les balises meta SEO classiques plutôt que de les remplacer. Le <title> et le lien canonique pilotent toujours la recherche ; la meta description façonne toujours votre extrait dans les résultats. Les balises Open Graph ne touchent pas au classement : elles régissent la carte sociale. Un <head> complet réunit généralement les trois familles.
Les écrire à la main est répétitif et propice aux erreurs subtiles. Le Générateur de balises meta & Open Graph construit tout le bloc à partir d’un court formulaire, l’affiche en direct et garde cohérents les détails délicats (noms d’attributs, URL absolues, dimensions d’image), pour que vous n’ayez pas à les mémoriser.
Les balises Open Graph essentielles dont vous avez vraiment besoin
Open Graph définit des dizaines de propriétés, mais un bon partage n’en exige qu’une poignée. Commencez par les quatre obligatoires, ajoutez une description, et arrêtez-vous là pour la plupart des pages.
Les quatre balises obligatoires : og:title, og:type, og:image, og:url
Quatre balises sont obligatoires selon le protocole. S’il en manque une, les plateformes abandonnent la carte ou comblent le vide par une supposition médiocre.
<meta property="og:title" content="How Open Graph Tags Work">
<meta property="og:type" content="website">
<meta property="og:image" content="https://example.com/og/cover.png">
<meta property="og:url" content="https://example.com/open-graph-guide">og:title est le titre en gras de la carte. og:type classe l’objet (nous y reviendrons plus bas). og:image est l’image d’aperçu, et elle doit être une URL HTTPS absolue. og:url est l’adresse canonique de la page, que les plateformes utilisent pour dédupliquer les partages et agréger l’engagement.
og:description et en quoi elle diffère de la meta description SEO
og:description est le court résumé imprimé sous le titre sur une carte de partage :
<meta property="og:description" content="A practical guide to og:title, og:image and Twitter Card tags.">C’est une balise distincte de la <meta name="description"> du SEO, et elle s’adresse à un autre lecteur. La meta description se dispute les clics sur une page de résultats Google et se mesure à environ 155 caractères. La description Open Graph se lit sur une carte sociale, où l’espace est plus restreint et où la première phrase porte tout le poids. Si vous omettez og:description, la plupart des plateformes se rabattent sur votre meta description : vous pouvez donc souvent vous en passer. N’en rédigez une dédiée que lorsque l’accroche sociale doit différer de l’extrait de recherche.
og:type et ce qu’elle débloque
og:type indique aux plateformes de quel type de contenu il s’agit. Les valeurs courantes sont website, article, product et profile. Une page d’accueil ou une landing page est un website ; un article de blog est un article.
Choisir article débloque des propriétés et des fonctionnalités supplémentaires qu’un simple type website ne peut pas exploiter :
<meta property="og:type" content="article">
<meta property="article:published_time" content="2026-07-16T00:00:00Z">
<meta property="article:author" content="Ada Lovelace">Ces balises article:* alimentent les cartes avec les dates de publication et les signatures, et elles rendent la page éligible aux Rich Pins de Pinterest, qui tirent les données structurées directement de votre balisage Open Graph. Réglez og:type sur article pour les articles et sur website pour tout le reste, et les champs correspondants suivent.
Voici un aide-mémoire des balises que la plupart des pages utilisent réellement :
| Balise | Ce qu’elle contrôle | Exemple de valeur |
|---|---|---|
og:title | Titre affiché sur la carte | How Open Graph Tags Work |
og:type | Type d’objet : website, article, product, profile | article |
og:image | Image d’aperçu (URL HTTPS absolue) | https://example.com/og/cover.png |
og:url | URL canonique de la page | https://example.com/open-graph-guide |
og:description | Résumé sous le titre | A practical guide to social meta tags. |
og:site_name | Nom global du site | Example |
og:locale | Langue et région du contenu | en_US |
og:image : tailles, ratio et les règles qui cassent les partages
L’image est la partie d’un aperçu que l’on voit en premier, et c’est là que la plupart des partages échouent. Réussissez la taille et le format de l’og:image, et un seul fichier fonctionne partout.
Le standard universel 1200×630 (1.91:1)
La taille d’og:image recommandée est de 1200×630 pixels, soit un ratio de 1.91:1. Cette seule image s’affiche correctement sur Facebook, LinkedIn, Slack, Discord et la carte summary_large_image de X : vous n’avez donc pas besoin d’un fichier différent par plateforme.
Les seuils minimaux comptent aussi. Facebook ignore toute image de moins de 200×200 et affiche une vignette carrée à l’étroit pour tout ce qui est en dessous de 600×315. En dessous de 1200 pixels de large, les grandes cartes commencent à paraître floues. Visez 1200×630 et vous franchissez tous les seuils d’un coup.
Pourquoi og:image:width et og:image:height comptent
Lorsqu’une plateforme rencontre votre lien pour la première fois, elle n’a pas encore téléchargé l’image ; elle la récupère de façon asynchrone. Si vous déclarez les dimensions d’emblée, la plateforme peut réserver le bon espace et mettre la carte en page immédiatement :
<meta property="og:image" content="https://example.com/og/cover.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Open Graph guide cover with the title in large type">Omettez-les et le tout premier partage d’une page peut s’afficher vide, le temps que le robot rattrape son retard. Ajoutez-les et la carte est correcte dès le premier collage. La balise og:image:alt décrit l’image pour les lecteurs d’écran sur les plateformes qui la prennent en charge.
Format et taille du fichier
Utilisez du JPG ou du PNG. Les deux se décodent de manière fiable sur tous les robots, ce qui est tout l’intérêt d’une og:image : elle doit s’afficher sur des serveurs que vous ne contrôlez pas. Gardez le fichier sous 1 MB en règle générale, et sous 300 KB pour WhatsApp, plus strict que les autres. Si votre export est plus lourd, faites-le passer par le compresseur d’images en ligne pour le ramener sous 1 MB sans nuire visiblement à la qualité.
On est tenté d’opter pour un format moderne ici, mais c’est le seul endroit où il faut résister. Les formats récents économisent des octets pour les navigateurs, mais certains robots sociaux les décodent de façon inconstante : une og:image en WebP ou AVIF peut donc revenir vide sur une plateforme incapable de la lire. Les compromis sont détaillés dans le guide WebP vs AVIF vs JPEG : quel format choisir en 2026 ? ; pour les images de partage en particulier, restez sur du JPG ou du PNG. Comme les plateformes rognent les bords différemment, gardez votre logo et votre titre dans une zone de sécurité de 1080×600 centrée, pour que rien d’important ne soit coupé.
La règle de l’URL HTTPS absolue
og:image et og:url doivent être des URL https://… complètes, pas des chemins relatifs. Un chemin comme /cover.png se résout bien dans votre éditeur et sur votre page en ligne, mais un robot qui récupère votre URL n’a aucune base pour le résoudre : le partage revient donc vide. L’image doit aussi être accessible publiquement : si robots.txt bloque le robot ou si le fichier est derrière une authentification, l’aperçu reste vide.
Une dernière contrainte conditionne tout ce qui précède : les robots n’exécutent pas de JavaScript. Facebook, LinkedIn, WhatsApp, Telegram et Discord récupèrent votre HTML brut et lisent ce qui s’y trouve. Les balises injectées côté client par un framework après le chargement de la page leur sont invisibles : vos balises Open Graph doivent donc résider dans du HTML rendu côté serveur ou statique.
Twitter/X Cards : une balise, puis repli sur Open Graph
X utilise ses propres balises meta Twitter Card, mais le recoupement avec Open Graph fait que vous en écrivez bien moins que prévu. En pratique, vous ajoutez une seule balise et laissez le reste se replier sur Open Graph.
twitter:card est la seule balise Twitter obligatoire
X n’affiche aucune carte tant que twitter:card est absente, même lorsque vous disposez d’un jeu complet de balises Open Graph. C’est la seule balise Twitter Card obligatoire :
<meta name="twitter:card" content="summary_large_image">La valeur choisit la mise en page. summary_large_image donne la grande carte bannière conçue pour une image 1200×630. summary donne une carte compacte avec une petite vignette carrée à côté du texte :
<meta name="twitter:card" content="summary">Remarquez l’attribut name. Les balises Twitter Card utilisent name, et non le property d’Open Graph.
Comment X se replie sur og:* pour le titre, la description et l’image
Pour le titre, la description et l’image, X lit vos og:title, og:description et og:image lorsque la balise twitter:* correspondante est absente. C’est pourquoi vous n’écrivez que rarement twitter:title ou twitter:image. Définissez twitter:card, gardez vos balises Open Graph propres, et X assemble la carte à partir d’elles.
Le piège du twitter:image vide
Le repli a un piège tranchant : une balise vide compte comme présente. Si vous émettez twitter:image avec une valeur vide, X utilise cette valeur vide au lieu de se rabattre sur og:image, et votre carte perd son image.
<!-- Faux : bloque le repli et laisse la carte sans image -->
<meta name="twitter:image" content="">
<!-- Correct : omettez entièrement la balise et X lit og:image -->La règle est simple : n’émettez jamais de balise sociale vide. Laissez-la de côté quand vous n’avez pas de valeur.
Spécificités de Slack et Discord
Slack lit d’abord la Twitter Card, puis Open Graph, et peut faire apparaître deux champs supplémentaires via twitter:label et twitter:data :
<meta name="twitter:label1" content="Reading time">
<meta name="twitter:data1" content="11 minutes">
<meta name="twitter:label2" content="Written by">
<meta name="twitter:data2" content="Ada Lovelace">Ceux-ci apparaissent comme de petits détails étiquetés sous un aperçu déplié dans Slack. Discord lit Open Graph et ajoute une touche que personne d’autre n’utilise : il colore la barre d’accentuation gauche de l’embed avec le theme-color de votre page.
<meta name="theme-color" content="#5865F2">Comment les aperçus de liens s’affichent sur chaque plateforme
Les mêmes balises produisent des aperçus de liens différents sur les réseaux sociaux selon qui les lit. Chaque plateforme sélectionne son propre sous-ensemble de balises, met en cache selon sa propre fenêtre, et ajoute une bizarrerie ou deux. Ce tableau récapitule ces différences.
| Plateforme | Balises lues | Cache | Comportement notable |
|---|---|---|---|
| Open Graph | ~30 jours | Ignore les images de moins de 200×200 ; affiche un petit carré en dessous de 600×315 | |
| Open Graph | ~7 jours | Videz un aperçu périmé avec le Post Inspector | |
| X (Twitter) | twitter:card + repli sur og:* | court | Pas de twitter:card, pas de carte du tout |
| Slack | Twitter Card, puis Open Graph | par message | Affiche twitter:label/twitter:data comme champs supplémentaires |
| Discord | Open Graph | par message | Utilise theme-color pour la barre d’accentuation de l’embed |
og:title + og:image | par message | Veut les métadonnées près du début ; gardez l’image sous 300 KB | |
| Telegram | Open Graph | par message | Ne s’affiche de façon fiable qu’à partir de JPEG ou PNG |
| Open Graph ou Schema.org | — | Les Rich Pins d’article nécessitent og:type=article |
La colonne cache explique une surprise fréquente : vous corrigez vos balises, repartagez, et Facebook affiche encore l’ancien titre pendant des semaines. Facebook conserve les données Open Graph pendant environ 30 jours et LinkedIn pendant environ 7 : une modification n’apparaîtra donc pas tant que le cache n’a pas expiré ou que vous ne forcez pas un rafraîchissement. Les débogueurs ci-dessous font exactement cela.
Erreurs Open Graph fréquentes (et comment les repérer)
La plupart des aperçus cassés remontent à une courte liste d’erreurs. Chacune semble correcte en local et n’échoue que lorsqu’un robot récupère la page en ligne.
Chemin og:image relatif
Un chemin relatif s’affiche dans votre navigateur et casse au partage, car le robot n’a aucune URL de base pour le résoudre.
<!-- Vide au partage -->
<meta property="og:image" content="/cover.png">
<!-- S'affiche partout -->
<meta property="og:image" content="https://example.com/cover.png">og:url manquante ou canonique en désaccord avec elle
Sans og:url, le décompte des partages et l’engagement se dispersent entre les variantes d’URL (avec et sans www, avec des paramètres de suivi, avec une barre oblique finale). Faites pointer votre lien canonique et og:url vers une seule et même URL, pour que les signaux restent groupés.
Image trop petite ou mauvais ratio
Une image en dessous de 200×200 est ignorée purement et simplement, et une image éloignée du 1.91:1 se fait rogner d’une manière que vous n’aviez pas prévue. Livrez du 1200×630 et le cadrage devient prévisible sur toutes les plateformes.
Oublier twitter:card
Un jeu complet de balises Open Graph ne produit toujours aucune carte sur X sans twitter:card. C’est la raison la plus fréquente pour laquelle un lien s’affiche parfaitement sur LinkedIn mais reste vide sur X.
Balises rendues côté client qu’un robot ne peut pas voir
Si une application monopage injecte les balises Open Graph après le chargement, les robots qui n’exécutent pas de JavaScript ne les voient jamais. Rendez les balises côté serveur ou pré-générez le HTML.
charset placé après les 1024 premiers octets
La déclaration <meta charset="utf-8"> doit apparaître dans les 1024 premiers octets du document, sinon le navigateur l’ignore et peut brouiller les caractères non-ASCII de votre titre et de votre description. Placez-la en premier dans le <head> :
<head>
<meta charset="utf-8">
<!-- tout le reste suit -->
</head>Comment tester et déboguer vos balises Open Graph
Ne faites jamais confiance à un aperçu que vous n’avez pas vérifié sur une URL en ligne. Trois outils couvrent les plateformes qui comptent, et tous peuvent forcer un rafraîchissement du cache.
Facebook Sharing Debugger
Le Facebook Sharing Debugger récupère votre URL en ligne, montre exactement ce que Facebook a analysé et liste toute balise manquante ou mal formée. Son bouton le plus utile est « Scrape Again », qui rafraîchit à la demande le cache d’environ 30 jours de Facebook : c’est le moyen le plus rapide de faire apparaître une correction sans attendre un mois.
LinkedIn Post Inspector
Le LinkedIn Post Inspector fait le même travail pour LinkedIn. Collez une URL et il récupère à nouveau la page et vide le cache d’environ 7 jours de LinkedIn : un titre ou une image mis à jour apparaît alors dès votre prochain partage, au lieu de plusieurs jours plus tard.
La validation des cartes X est passée dans le portail développeur
X a retiré son Card Validator autonome. Depuis 2026, la validation des cartes se trouve dans le portail développeur de X plutôt qu’à une URL publique : la plupart des équipes vérifient donc les cartes X autrement. Comme X se replie sur og:*, les débogueurs Facebook et LinkedIn confirment déjà les balises que X lira, et un outil d’aperçu tiers comble le manque pour la mise en page twitter:card elle-même.
Prévisualisez avant de déployer
Les débogueurs ne peuvent inspecter qu’une URL déjà en ligne, ce qui est un bien mauvais moment pour découvrir une image vide. Prévisualisez la carte pendant que vous êtes encore en train d’éditer. Le Générateur de balises meta & Open Graph affiche les aperçus Google, Facebook, X, LinkedIn, Slack et Discord à partir des valeurs que vous saisissez, lit les dimensions réelles de votre og:image dans le navigateur pour détecter un mauvais ratio, et peut importer un <head> existant afin que vous diagnostiquiez un partage cassé avant sa mise en production.
Aide-mémoire express
Voici le minimum que chaque page devrait porter. Copiez-le, remplacez par vos valeurs, et vous obtenez un aperçu qui s’affiche partout :
<meta charset="utf-8">
<title>Your page title</title>
<meta name="description" content="Your 150-character summary.">
<link rel="canonical" href="https://example.com/page">
<meta property="og:title" content="Your page title">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page">
<meta property="og:image" content="https://example.com/og/page.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:description" content="Your 150-character summary.">
<meta name="twitter:card" content="summary_large_image">Passez en revue l’essentiel avant de livrer : une og:image HTTPS absolue en 1200×630, og:url correspondant à votre canonique, twitter:card présente, et des balises rendues côté serveur. Si vous voulez un tour d’horizon plus complet des utilitaires qui accélèrent tout cela, le guide du débutant : outils de développement rassemble le reste. Quand vous êtes prêt à générer et prévisualiser tout le bloc d’un coup, le Générateur de balises meta & Open Graph l’écrit, le vérifie et montre chaque carte avant que vous ne déployiez.
Questions fréquentes
Quelle est la différence entre les balises Open Graph et Twitter Card ?
Open Graph est un protocole multiplateforme lu par Facebook, LinkedIn, Slack et d’autres ; les balises Twitter Card (twitter:*) sont propres à X. X se replie sur vos balises OG lorsque la balise twitter:* correspondante est absente : vous n’avez donc généralement besoin que d’OG plus une seule valeur twitter:card.
Les balises Open Graph influencent-elles le classement dans Google ?
Non. Les balises Open Graph et Twitter Card n’influencent pas le classement dans Google : elles contrôlent l’apparence des liens lors du partage, ce qui génère du trafic social. Les balises classiques <title> et canonique comptent pour le SEO ; la meta description façonne votre extrait et votre taux de clics, mais n’est pas un facteur de classement direct.
Où placer les balises Open Graph dans le HTML ?
Dans l’élément <head>, au sein du HTML rendu côté serveur ou statique. Les robots de Facebook, LinkedIn, WhatsApp et Telegram n’exécutent pas de JavaScript : les balises injectées côté client ne seront donc pas vues. Placez <meta charset> en premier pour qu’elle tombe dans les 1024 premiers octets.
Une seule image peut-elle convenir à Facebook, X et LinkedIn ?
Oui. Une seule image 1200×630 (1.91:1) s’affiche correctement sur Facebook, LinkedIn, Slack, Discord et la carte summary_large_image de X. Servez-la en HTTPS depuis une URL publique et déclarez og:image:width/og:image:height pour que le premier partage ne soit pas vide.
Pourquoi mon aperçu de lien n’affiche-t-il aucune image ?
Causes fréquentes : un chemin og:image relatif au lieu d’une URL HTTPS absolue, une image en dessous de 200×200, une balise twitter:card manquante sur X, ou des balises injectées par du JavaScript que le robot ne peut pas exécuter. Relancez un scrape avec le Facebook Sharing Debugger après correction.
Toutes les pages ont-elles besoin de leurs propres balises Open Graph ?
Idéalement oui : chaque page devrait avoir un og:title, une og:description, une og:image et une og:url canonique reflétant cette page précise, afin que les liens partagés affichent des aperçus pertinents. Un repli valable pour tout le site vaut mieux que rien, mais des balises par page remportent bien plus de clics sociaux.