BrowserTools
Accueil / Validateurs / Aperçu de lien

Aperçu de lien

Voyez à quoi ressemblera un lien vers votre page sur les réseaux sociaux et les moteurs de recherche, et corrigez les balises manquantes.

Chargement de Aperçu de lien… Si rien ne se passe, activez JavaScript.

Quand quelqu'un colle un lien dans WhatsApp, Slack ou une publication LinkedIn, l'application récupère la page en arrière-plan et construit une petite carte à partir de quelques balises du head : og:title, og:description, og:image et og:url du protocole Open Graph, plus twitter:card pour X. Si ces balises manquent, sont trop longues ou pointent vers un chemin relatif, la carte s'affiche comme une URL nue, un titre suivi de "| Nom de l'entreprise" ou une image recadrée au mauvais endroit. Cet outil vous montre le résultat avant la publication. Collez le code source de votre page (ou seulement la section head) : il lit chaque balise meta avec l'analyseur HTML du navigateur, détermine la valeur que chaque plateforme utilisera et dessine côte à côte une carte d'aperçu pour la recherche Google, Facebook, X, LinkedIn, WhatsApp, Slack et Discord.

Questions fréquentes

Pourquoi ne puis-je pas simplement saisir mon URL ?
Une page web ne peut pas récupérer un autre site : les règles de même origine du navigateur l'en empêchent, sauf si ce site l'autorise explicitement, ce que très peu font. Contourner cela exigerait un serveur qui télécharge la page pour vous, et ce site fait volontairement tout sur votre appareil. Ouvrez votre page, utilisez Afficher le code source de la page (Ctrl+U ou Cmd+Option+U), copiez-le et collez-le ici. Seule la section head compte, vous pouvez donc ne coller que celle-ci.
Quelle est la meilleure taille pour og:image ?
1200 sur 630 pixels, soit un rapport de 1,91:1, est la taille recommandée par Facebook, et elle fonctionne bien sur LinkedIn, WhatsApp, Slack et Discord. X recadre les grandes cartes en 2:1 : éloignez donc le texte important et les visages des bords supérieur et inférieur. Les images de moins de 600 pixels de large s'affichent en petite vignette carrée sur plusieurs plateformes, et Facebook ignore celles de moins de 200 sur 200. Utilisez du JPG ou du PNG de moins de 300 Ko environ si WhatsApp compte pour vous, et jamais de SVG.
De quelles balises ai-je vraiment besoin ?
Pour une carte fiable partout : og:title, og:description, og:image (URL absolue), og:url (l'adresse canonique) et twitter:card avec la valeur summary_large_image. og:type, og:site_name, og:image:width, og:image:height et og:image:alt sont des ajouts recommandés. X lit les balises Open Graph en secours, donc twitter:title, twitter:description et twitter:image ne servent que si vous voulez un autre texte ou une autre image sur X.
Pourquoi Google affiche-t-il un autre titre que Facebook ?
La recherche Google n'utilise pas Open Graph. Elle construit le résultat à partir de l'élément title du HTML et de la meta description, et peut réécrire l'un ou l'autre si elle estime qu'une autre partie de la page la décrit mieux. Les applications sociales préfèrent og:title et og:description. C'est pourquoi l'aperçu Google lit ici l'élément title, tandis que les autres cartes lisent les valeurs Open Graph.
J'ai corrigé mes balises mais Facebook ou LinkedIn affichent toujours l'ancien aperçu. Pourquoi ?
Les plateformes mettent les aperçus de liens en cache, souvent pendant des jours ou des semaines. Le Sharing Debugger de Facebook et le Post Inspector de LinkedIn vous permettent de saisir l'URL et de déclencher une nouvelle lecture. X rafraîchit son cache de lui-même, généralement en une semaine. WhatsApp et Slack gardent un cache par conversation : partager le lien avec un paramètre comme ?v=2 est un moyen rapide de voir la nouvelle version.
Pourquoi og:image et og:url doivent-elles être des URL absolues ?
Les robots de ces plateformes lisent vos balises comme du texte brut et beaucoup ne résolvent pas les chemins par rapport à l'adresse de la page. Une valeur comme /images/card.jpg peut marcher sur une plateforme et échouer sans bruit sur une autre. Utilisez l'adresse complète, commençant par https://. L'outil signale les valeurs relatives et sans protocole et, si vous saisissez l'URL de la page, écrit la version absolue résolue dans le bloc de balises corrigé.
Les aperçus sont-ils fidèles au pixel près ?
Ce sont des approximations proches de la mise en page actuelle de chaque plateforme, dessinées avec les styles de ce site, pour juger de la longueur du texte, du recadrage de l'image et des éléments affichés. Les vraies applications changent régulièrement de design, et la coupure du texte dépend de la largeur d'écran, de la police et de la langue. Les seuils utilisés (environ 60 caractères pour les titres Google, 160 pour les descriptions, 600 pixels pour les grandes images) suivent les recommandations publiées par les plateformes et le comportement observé.
Mon HTML ou mon image sont-ils envoyés quelque part ?
Non. Le HTML est analysé avec le DOMParser intégré au navigateur, qui n'exécute jamais de scripts et ne charge jamais d'images ni de feuilles de style depuis le code collé. Une image importée est affichée depuis une URL d'objet locale et ne quitte jamais votre appareil. La page n'envoie aucune requête à votre site ni à aucun réseau social.

À propos de Aperçu de lien

La page ne peut pas récupérer votre URL à votre place : les navigateurs bloquent ce type de requête entre sites, et ce site garde tout sur votre appareil, il ne contacte donc jamais votre serveur non plus. Les images distantes ne sont donc pas téléchargées. Les cartes affichent un emplacement avec l'adresse de l'image, et si vous importez le fichier image, vous le voyez recadré comme chaque application le ferait, 1,91:1 pour les grandes cartes, 2:1 sur X et carré pour les petites vignettes, avec sa taille réelle en pixels et son poids. Si la page est encore en conception, passez au formulaire, saisissez directement le titre, la description, l'URL et l'adresse de l'image, et surveillez les compteurs à l'approche des limites.

Sous les aperçus, une liste de vérifications explique ce qui poserait problème et pourquoi : balises Open Graph absentes, valeur de twitter:card que X ne reconnaît pas, titres dépassant la soixantaine de caractères affichés par Google, descriptions de plus de 160 caractères, URL relatives ou sans protocole, images SVG qu'aucune application n'affiche, images de moins de 600 pixels de large qui passent en petite vignette, balises en double que chaque application interprète à sa façon, et balises placées hors du head, là où certains robots ont déjà cessé de lire. Enfin, l'outil génère un bloc de balises propre et corrigé, avec des URL absolues, les dimensions de l'image déclarées et les bons attributs, prêt à copier dans votre modèle. Une fois les nouvelles balises en ligne, n'oubliez pas que Facebook, LinkedIn et X mettent les aperçus en cache : utilisez leurs outils de débogage pour forcer une nouvelle lecture.

Open Graph a été créé pour un bouton J'aime

Facebook a présenté le protocole Open Graph lors de sa conférence pour développeurs f8, en avril 2010, en même temps que le bouton J'aime que n'importe quel site pouvait intégrer. L'idée était de transformer des pages web ordinaires en objets du graphe social de Facebook : une page consacrée à un film pouvait se déclarer comme film, avec un titre, une image et une URL canonique, et cliquer sur J'aime vous reliait à cet objet comme à une page de fans.

Le protocole a été conçu pour rester volontairement simple, en empruntant l'attribut property de RDFa afin que les éditeurs n'aient qu'à ajouter quelques balises meta. C'est cette simplicité qui l'a fait sortir de Facebook. Twitter a lancé ses Cards en 2012, mais a choisi de se rabattre sur les valeurs Open Graph en l'absence de ses balises twitter:, puis LinkedIn, Pinterest, Slack, Discord, WhatsApp, iMessage et Telegram se sont tous mis à lire les mêmes balises og:. Aujourd'hui, un standard né pour alimenter un seul bouton décide discrètement de l'apparence de presque tous les liens partagés sur internet.

Soutenir