Ce que lit vraiment une plateforme
Quand un lien est collé dans Slack, LinkedIn, X ou iMessage, la plateforme récupère la page et crée une carte à partir de ses balises meta. Elle n’exécute jamais ton JavaScript ni ne voit ton CSS - elle lit uniquement les balises dans le head.
La chaîne de secours
La plupart des plateformes résolvent dans le même ordre, et cet aperçu le suit :
- Titre -
twitter:title, puisog:title, puis<title> - Description -
twitter:description, puisog:description, puis la meta description - Image -
twitter:image, puisog:image, puis rien
C’est pourquoi dupliquer chaque balise Open Graph en balise Twitter est souvent inutile. La seule qui mérite vraiment d’être définie séparément est twitter:card, car elle choisit entre l’image large et la petite vignette.
Les trois erreurs qui causent la plupart des cartes cassées
- Un og:image relatif. Le crawler n’a pas de contexte de page pour le résoudre. URL HTTPS absolue ou rien.
- Une image inaccessible. Derrière une authentification, bloquée par robots.txt, ou servie par un hôte qui refuse les user agents inconnus.
- Cache trop agressif. Tu as corrigé les balises mais l’ancienne carte reste visible pendant des jours. Facebook Sharing Debugger et LinkedIn Post Inspector forcent une nouvelle analyse ; le cache de X doit juste expirer.
Pas une fonctionnalité SEO
Aucune de ces balises n’influence le classement. Elles déterminent si un lien donne envie d’être cliqué quand quelqu’un le partage – et un lien affiché en boîte grise avec juste l’URL est partagé et cliqué nettement moins.
Pour écrire les balises dès le départ, utilise le générateur de balises meta à la place.