Vérificateur d’aperçu de lienVoyez la carte avant de publier le lien.
Collez une URL et récupérez la carte de partage telle que Facebook, X, LinkedIn, WhatsApp, Discord, Slack, Telegram et iMessage vont chacun l’afficher, en clair et en sombre, avec la liste de ce qui manque et les balises à coller pour corriger.
L’URL est récupérée par notre serveur, car un navigateur ne peut pas lire un autre site à votre place. Elle n’est jamais journalisée, jamais stockée, jamais transmise à un tiers.
Collez une URL pour voir ses cartes de partage
Vous obtenez la carte telle que Facebook, X, LinkedIn, WhatsApp, Discord, Slack, Telegram et iMessage vont chacun l’afficher, plus la liste de ce qui manque.
Pourquoi mon aperçu de lien affiche la mauvaise image ?
Presque toujours l’une de ces cinq causes, et cet open graph checker vous dit laquelle, au lieu de vous conseiller d’ajouter og:image alors que vous l’avez déjà.
Il y a plusieurs og:image
Le thème en ajoute une, une extension en ajoute une autre, et les plateformes prennent très majoritairement la première rencontrée dans le head. L’image que vous attendiez se trouve en général plus bas. Le tableau des balises ci-dessus liste chaque candidate et signale celle qui l’emporte.
L’image est un chemin relatif
og:image="/img/card.png" n’est pas une URL qu’un robot peut charger. Elle doit être absolue, et se résoudre depuis l’adresse finale après redirections, pas celle que vous avez tapée. Si votre site redirige vers www, un chemin qui marche en local peut ne mener nulle part en production.
L’image est protégée contre le hotlinking
Elle s’ouvre très bien dans votre navigateur parce que vous avez une session et le bon referer. Un robot n’a ni l’un ni l’autre, reçoit un 403, et la carte se retrouve sans image. Cet outil charge l’image comme le ferait un inconnu, la panne apparaît donc ici plutôt qu’après publication.
La plateforme affiche encore son cache
Vous avez corrigé la balise il y a une heure et l’ancienne image est toujours là. Chaque plateforme met l’aperçu en cache de son côté et certaines le gardent des semaines. Rien de ce que vous changez chez vous ne l’efface, il faut relancer la lecture de l’URL avec l’outil de la plateforme.
La page n’a jamais eu ces balises
Si votre site s’affiche côté client, les balises existent dans votre inspecteur et pas dans le HTML renvoyé par le serveur. Aucun robot n’attend le JavaScript. C’est la cause la plus fréquente sur les stacks modernes, et celle que l’on croit le moins vite.
De quelles balises Open Graph avez-vous vraiment besoin ?
Quatre portent la carte. Le reste relève du réglage fin, et un aperçu des balises meta qui signale les vingt comme aussi urgentes ne vous aide pas.
og:title et og:description
Le titre et les deux lignes en dessous. Sans og:title, une plateforme retombe sur <title>, en général écrit pour les résultats de recherche et qui passe mal en titre de carte. Sans description, le corps de la carte reste simplement vide.
og:image, absolue et large d’au moins 1200 px
Facebook documente 200x200 comme plancher et 1200x630 comme recommandation. LinkedIn documente 1200x627, et précise qu’une image de moins de 401 px de large s’affiche en petite vignette au lieu d’une bannière. Une seule image en 1200x630 satisfait toutes les plateformes à la fois.
twitter:card
La seule balise dont X a vraiment besoin de votre part. Mettez-la sur summary_large_image et vos balises Open Graph font le reste : X retombe sur og:title, og:description et og:image quand les équivalents twitter: sont absents, inutile donc de les dupliquer.
og:url, et celles qui ne font que peaufiner
og:url évite qu’une même page compte pour plusieurs quand elle est partagée avec des paramètres de tracking différents. og:image:width et height permettent de dessiner la carte avant l’arrivée de l’image. og:type, og:site_name, og:locale et og:image:alt sont de la finition.
Faut-il des balises Twitter si j’ai déjà Open Graph ?
Le plus souvent non, et c’est de là que vient beaucoup de balisage dupliqué. Deux points à comprendre avant de copier un extrait de quinze lignes trouvé sur un blog.
X retombe tout seul sur Open Graph
Si twitter:title, twitter:description ou twitter:image manquent, X lit og:title, og:description et og:image à la place. La seule balise que vous devez vraiment ajouter est donc twitter:card, qui indique s’il faut dessiner le petit carré summary ou la grande bannière. Ajouter le reste ne sert que si vous voulez que X dise autre chose que partout ailleurs.
property= contre name=, et pourquoi les deux marchent
La spécification Open Graph pose ses balises sur property=, et la spécification des cartes X pose les siennes sur name=. En pratique les deux plateformes lisent les deux, c’est pourquoi un vérificateur qui ne reconnaît qu’une écriture déclare la moitié de vos balises manquantes. Celui-ci analyse les deux et vous indique l’écriture utilisée, à titre d’information et non d’erreur.
Pourquoi mon aperçu affiche-t-il encore l’ancienne image ?
Parce que la plateforme ne regarde pas votre page. Elle regarde la copie prise la première fois que quelqu’un a partagé le lien, et elle continuera tant que rien ne l’oblige à regarder de nouveau.
Chaque plateforme a son propre cache
Corriger la balise ne prévient personne. Facebook, LinkedIn et X gardent chacun leur copie, un lien peut donc être correct à un endroit et périmé à deux autres en même temps.
Relancez la lecture avec les outils officiels
Le Facebook Sharing Debugger, le X Card Validator et le LinkedIn Post Inspector ont chacun un bouton qui force une nouvelle lecture. C’est le seul moyen fiable de vider le cache, et c’est immédiat.
Les messageries ne mettent presque rien en cache
WhatsApp, Telegram, Discord et Slack relisent en général la page à chaque nouveau message, c’est donc le moyen le plus rapide de confirmer une correction sans dépendre de personne.
Une nouvelle URL est la porte de sortie
Si une plateforme refuse de se rafraîchir, partager une URL qu’elle n’a jamais vue contourne complètement le cache. Ajouter un paramètre suffit en général.
Vous ne savez pas où mène vraiment un lien raccourci ? Déroulez-le avec le résolveur de QR code
Besoin d’un lien propre à partager une fois les balises corrigées ? Créez-en un avec le raccourcisseur de liens gratuit
L’aperçu est la moitié facile. Savoir ce que le clic a donné est l’autre.
Une bonne carte déclenche le clic. Ensuite, une URL brute ne vous apprend rien : ni d’où vient la visite, ni quelle plateforme a réellement livré, et elle ne peut plus être redirigée une fois publiée. C’est ce manque que LinkScale comble.
Voyez quelle plateforme a livré
Les clics par source, pays et appareil, pour savoir si c’est le post LinkedIn ou la newsletter qui a travaillé.
Changez la destination, plus tard
Redirigez un lien déjà publié, sans demander à personne de le partager de nouveau.
Gardez la carte intacte
Un lien LinkScale porte ses propres balises de partage, le raccourcir ne vous coûte donc pas l’aperçu que vous venez de corriger.
Questions sur les aperçus de lien
Encore des questions ?
En ligneDe vrais humains, réponse en quelques minutes en général.
Il est gratuit, sans compte et sans limite d’usage digne de ce nom. L’URL est récupérée par notre serveur, parce qu’un navigateur ne peut pas lire un autre site à votre place, et c’est la seule chose que fait ce point d’entrée : charger la page, extraire les balises, les renvoyer. Elle n’est pas journalisée, pas écrite en base, pas transmise à un tiers. Si vous préférez que rien ne quitte votre machine, le mode collage de HTML fait toute l’analyse dans votre navigateur.
Allez plus loin avec LinkScale
La carte est corrigée. Voyez maintenant ce que le clic a rapporté.
LinkScale vous montre d’où vient chaque clic et vous laisse changer la destination d’un lien après sa publication.
Free 14-day trial on every plan