Vérificateur Open Graph
Les balises Open Graph sont les balises meta qui décident de l’apparence d’une page lorsque son lien est collé dans Facebook, X, LinkedIn, Slack ou une application de messagerie. Saisissez une URL et ce vérificateur récupère la page une seule fois, montre exactement quelles balises et quels replis chaque plateforme utilisera, dessine les quatre cartes de partage et contrôle les dimensions réelles de l’image. Le guide associé, vérifiez vos cartes de partage avant de publier, explique comment corriger ce que vous trouverez ; pour le bilan large et routinier, utilisez plutôt le bilan de santé du site.
Dernière mise à jour:
Vous voulez une surveillance continue ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Comment fonctionne la vérification
Le vérificateur effectue une seule récupération protégée côté serveur de l’URL que vous saisissez, suit les redirections et lit le HTML statique de la page finale — le même HTML que voit le robot d’une plateforme. Il analyse les balises meta og: et twitter:, le <title> de la page et la méta-description, puis calcule, plateforme par plateforme, quelle valeur chaque carte affichera réellement et d’où vient cette valeur. Les valeurs fournies par un repli sont étiquetées comme des replis, pour qu’une carte qui semble complète ne cache pas une balise manquante en dessous.
Une limite conditionne tout le reste : il s’agit d’une simple récupération HTTP, pas d’un navigateur, et les robots des plateformes ne sont pas des navigateurs non plus — aucun n’exécute JavaScript. Les balises injectées par un script, rendues côté client ou ajoutées uniquement après connexion sont invisibles ici et invisibles sur Facebook, X, LinkedIn et Slack exactement de la même façon. Si une balise n’existe que dans votre paquet JavaScript, elle n’existe pas pour le partage. Ce que vous voyez dans le résultat — URL finale, statut HTTP, le tableau brut des balises et les quatre cartes dessinées — est la vérité statique avec laquelle les robots doivent travailler.
Replis, piège de l’image relative et caches des robots
Chaque plateforme se replie différemment, et c’est pourquoi une même page peut sembler correcte dans une application et cassée dans une autre. Facebook lit directement les balises og:. X lit d’abord ses propres balises twitter: et se replie sur les balises og: correspondantes quand elles manquent. LinkedIn ne lit que les balises og:, donc une configuration Twitter Card parfaite ne lui sert à rien. Slack lit d’abord les balises og:, puis les balises twitter:. La liste ci-dessous signale chaque champ manquant, chaque champ vide et chaque champ qu’une plateforme remplirait par un repli, en nommant la source vers laquelle elle se replierait.
L’échec silencieux le plus fréquent est un og:image relatif : une valeur comme /images/share.jpg semble correcte dans votre modèle et dans votre navigateur, mais la plupart des robots ne peuvent la résoudre par rapport à rien, donc la carte n’affiche tout simplement aucune image. La correction est toujours une URL absolue, schéma inclus. Le second piège est le cache : chaque plateforme met en cache ce que son robot a récupéré, donc corriger les balises ne met pas à jour les publications déjà en circulation, et même un aperçu frais peut continuer à servir l’ancienne carte jusqu’à ce que vous demandiez à la plateforme de réanalyser l’URL. Corrigez d’abord les balises, vérifiez-les ici, puis forcez la réanalyse — dans cet ordre, sinon vous remettrez en cache la version cassée.
Limites d’honnêteté : un aperçu ici est une simulation du comportement documenté de chaque plateforme, pas une capture d’écran d’une publication réelle. Les plateformes recadrent, arrondissent et tronquent différemment, changent la présentation de leurs cartes sans préavis et peuvent traiter différemment les visiteurs connectés et déconnectés ; considérez donc les cartes comme un modèle fidèle, pas comme une garantie. Une chose n’est pas simulée : les dimensions de l’image sont lues dans les en-têtes du fichier image réel, et non dans les valeurs og:image:width et og:image:height déclarées par la page — les valeurs déclarées sont des affirmations, et ce vérificateur les confronte au fichier lui-même.
Ce qui est vérifié, et les règles qui le sous-tendent
| Balises vérifiées | og:title, og:description, og:image, og:url, og:type et og:site_name, plus twitter:card, twitter:title, twitter:description et twitter:image — et, comme sources de repli, le <title> de la page et la méta-description. |
| Taille d’image recommandée — 1200 × 630 px | 1200 × 630 est une recommandation des plateformes, pas une norme formelle : c’est la taille que Facebook recommande et la taille de grande carte que X, LinkedIn et Slack traitent le mieux. Les images plus petites s’affichent quand même, mais les cartes peuvent les recadrer ou se replier sur une petite miniature. |
| Lit directement les balises og: — og:title, og:description et og:image — et ne se replie sur le <title> de la page et la méta-description que lorsque les balises og: manquent. | |
| X (Twitter) | Lit d’abord twitter:title, twitter:description et twitter:image ; chacun se replie sur la balise og: correspondante quand il manque. twitter:card choisit la présentation de la carte, et sans elle, X devine à partir de ce qu’il trouve. |
| LinkedIn et Slack | LinkedIn ne lit que les balises og: — les balises twitter: n’y aident pas. Slack lit d’abord les balises og:, puis les balises twitter:, c’est donc le plus tolérant des quatre. |
| URL d’image relatives | og:image et twitter:image doivent être des URL absolues, schéma inclus. La plupart des robots ne peuvent pas résoudre un chemin relatif, et le résultat est une carte sans image et sans aucune erreur nulle part. |
| Dimensions de l’image | Lues dans le fichier image réel — ses en-têtes PNG, JPEG, GIF ou WebP — avec sa taille en octets et son format. Les valeurs déclarées og:image:width et og:image:height sont affichées pour comparaison, mais on ne leur fait jamais confiance à elles seules. |
| Dimensions inconnues | Signifie que le vérificateur n’a pas pu récupérer ni analyser le fichier image — délai dépassé, demande refusée, ou format dont il ne peut pas lire l’en-tête. Les dimensions déclarées par la page, s’il y en a, sont alors tout ce que quiconque possède, robots compris. |
Questions fréquentes
Pourquoi mon lien partagé n’affiche-t-il aucune image ?
Les causes habituelles, dans l’ordre : il n’y a aucun og:image ; l’og:image est une URL relative que les robots ne peuvent pas résoudre ; l’image est trop petite ou se trouve à un endroit que le robot ne peut pas récupérer (derrière une connexion, bloquée par des règles robots ou répondant par une erreur) ; ou la plateforme affiche encore son analyse en cache datant d’avant l’existence de l’image. Lancez la vérification ci-dessus — elle nomme laquelle s’applique —, corrigez la balise, puis demandez à la plateforme de réanalyser.
Balises Open Graph ou Twitter — faut-il les deux ?
En pratique, oui. Facebook et LinkedIn ne lisent que les balises og:, tandis que X préfère ses propres balises twitter: et utilise les balises og: comme repli. Un ensemble og: complet plus une balise twitter:card couvre la plupart des cas, mais un twitter:title, une twitter:description et une twitter:image explicites sont le seul moyen de rendre la carte X différente de la carte Facebook — et Slack lit les deux ensembles, og: d’abord.
Pourquoi la publication réelle diffère-t-elle de cet aperçu ?
Presque toujours, à cause du cache. Le robot de chaque plateforme met en cache ce qu’il a récupéré pour une URL, et modifier vos balises n’invalide pas ce cache. Une publication faite avant la correction conserve l’ancienne carte, et même le débogueur de la plateforme peut continuer à afficher la version en cache jusqu’à ce qu’une réanalyse soit forcée. Plus rarement, la différence vient du recadrage : les plateformes recadrent et tronquent selon leur présentation actuelle, et cet aperçu est une simulation du comportement documenté, pas une capture d’écran.
Ce vérificateur exécute-t-il JavaScript ?
Non — et c’est délibéré. Le vérificateur récupère le HTML statique une seule fois, exactement comme le fait le robot d’une plateforme, et les robots n’exécutent pas JavaScript non plus. Une balise ajoutée par un script ou un framework côté client manque donc ici pour la même raison qu’elle manquerait sur Facebook, X, LinkedIn et Slack. Si vos balises sont rendues par JavaScript, elles doivent figurer dans le HTML rendu côté serveur pour compter lors du partage.
Quelle taille doit faire og:image ?
Utilisez 1200 × 630 px chaque fois que vous le pouvez. C’est une recommandation des plateformes, pas une norme formelle — c’est ce que Facebook recommande et la taille autour de laquelle sont construites les grandes cartes de X, LinkedIn et Slack. Gardez le fichier raisonnablement petit, utilisez PNG ou JPEG (la prise en charge de WebP varie selon le robot) et référencez-le toujours par une URL absolue. Ce vérificateur signale les images inférieures à 1200 × 630 et vous indique les dimensions réelles qu’il a mesurées dans le fichier.