Un vérificateur Open Graph aide à comprendre pourquoi une page partagée affiche un mauvais titre, des métadonnées manquantes ou une déclaration d’image inattendue. Screpy lit le HTML d’une page publique et montre ses balises Open Graph, les conflits et les groupes d’images. Utilisez ces éléments pour corriger la source publiée, puis vérifiez séparément le fichier image et la plateforme de partage réelle. L’aperçu illustre les valeurs déclarées ; il ne reproduit pas la carte d’un réseau social.
Comment utiliser le vérificateur Open Graph
Saisissez l’URL publique complète de la page à partager, chemin compris, puis lancez la vérification. Vérifier une page d’accueil ne contrôle pas ses articles ni ses fiches produit. Lisez d’abord l’URL finale : si l’adresse redirige, le rapport décrit cette destination. Utilisez le Vérificateur de Redirections si la destination est inattendue.
Examinez le tableau des propriétés dans l’ordre de la source. Chaque ligne montre la déclaration, sa valeur et, lorsqu’elle est disponible, sa ligne d’origine. Ouvrez les groupes d’images pour consulter leurs champs associés, puis lisez les constats et les corrections proposées.
Le rouge signale des valeurs obligatoires absentes ou des valeurs d’URL rejetées. Le jaune indique des conflits ou une couverture partielle. Le vert signifie que les contrôles pris en charge n’ont trouvé aucun problème dans un rapport conservé complet. Il ne confirme ni le chargement d’une image, ni la pertinence du texte, ni l’affichage de la carte souhaitée sur une plateforme.
Vérifier les quatre propriétés Open Graph obligatoires
Le protocole Open Graph définit quatre propriétés de base obligatoires. Vérifiez leur sens autant que leur présence :
| Propriété | Ce qu’il faut vérifier sur cette page |
|---|---|
og:title |
Un titre de partage clair et propre à cette page, sans ancien texte de campagne. |
og:type |
Le type d’objet prévu, par exemple website ou article. |
og:image |
L’adresse de l’image que vous souhaitez associer à la page. |
og:url |
L’adresse stable destinée à identifier cet objet partagé. |
Le contrôle de présence de Screpy exige au moins une déclaration conservée non vide pour chaque nom exact. Un og:type renseigné satisfait ce contrôle même si sa valeur est inappropriée ; l’outil ne valide ni le vocabulaire des types ni toutes leurs exigences particulières.
Ajoutez une og:description utile qui explique la page sans répéter le titre. Son absence ne déclenche pas le contrôle des quatre propriétés obligatoires. Un <title> HTML ou une métadescription ordinaire constitue une déclaration distincte : ne supposez pas qu’elle remplit un champ Open Graph vide dans ce rapport.
Corriger les balises absentes ou contradictoires
Un constat de propriété manquante signifie que le nom obligatoire est absent des lignes conservées ou que toutes ses valeurs correspondantes sont vides. Vérifiez l’orthographe et le contenu avant d’ajouter une autre balise. Le vérificateur reconnaît les noms en minuscules tels que og:title ; un nom écrit autrement peut échapper à ce contrôle.
Un conflit signifie que des valeurs brutes différentes apparaissent pour og:title, og:type, og:url ou og:description. Même une différence d’espaces compte. Des répétitions identiques ne déclenchent pas cet avertissement, mais les déclarations répétées inutilement méritent tout de même un nettoyage.
Une page fictive pourrait, par exemple, publier un og:title vide suivi d’un autre contenant « Itinéraires de randonnée Atlas ». La seconde valeur satisfait le contrôle de présence, mais l’aperçu illustratif utilise la première et reste vide. Les valeurs différentes provoquent aussi un conflit. Un avertissement d’absence et un aperçu vide répondent donc à des questions différentes.
Identifiez le champ du CMS, le thème ou le modèle qui produit chaque ligne. Corrigez cette sortie afin que la valeur souhaitée soit fournie une seule fois pour ces champs à valeur unique. Ajouter une troisième déclaration ne masque aucune des originales. Conservez les déclarations d’images volontairement répétées pour l’examen distinct des groupes ci-dessous.
Associer les propriétés à la bonne image
Plusieurs déclarations og:image peuvent être intentionnelles. Placez les propriétés structurées de chaque image immédiatement après sa déclaration racine et avant l’image suivante. Cet extrait fictif de head montre cette association ; il ne constitue pas un ensemble complet de métadonnées :
<meta property="og:image" content="https://example.com/media/route-map.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<meta property="og:image:alt" content="Carte de l’itinéraire de randonnée Atlas">
<meta property="og:image" content="https://example.com/media/trail.jpg">
<meta property="og:image:alt" content="Sentier au pied d’un versant boisé">
Le premier groupe déclare une carte avec des dimensions et un texte alternatif. Le second possède sa propre description, sans dimensions déclarées. Déplacer son champ alt au-dessus de sa racine l’associerait à la carte. Ces valeurs décrivent la source ; Screpy ne télécharge pas les fichiers et ne mesure pas si la carte possède réellement ces dimensions.
Les champs placés avant toute racine d’image peuvent figurer dans le tableau brut sans être associés à un groupe. Utilisez la source ordonnée pour les corriger. Si la couverture est partielle, vérifiez le head complet avant de vous fier aux groupes conservés.
Le protocole considère og:image:url comme un alias de og:image. Screpy reconnaît cet alias pour le regroupement et la sélection de l’aperçu, mais son contrôle actuel des propriétés obligatoires attend toujours un og:image explicite et non vide. Une page utilisant seulement l’alias peut donc montrer une URL d’image et un constat de propriété manquante simultanément. Il s’agit d’une limite du vérificateur, pas d’une preuve que l’alias est interdit.
Distinguer les contrôles d’URL, d’image et de plateforme
Le contrôle d’URL couvre og:url, og:image, og:image:url et og:image:secure_url. Il tente de résoudre leurs valeurs comme des adresses HTTP ou HTTPS par rapport à l’URL finale. Il n’applique pas une adresse HTML <base> et ne valide pas toutes les URL audio ou vidéo.
Une valeur relative peut passer ce contrôle tout en pointant vers le mauvais fichier. Si la page finale est https://example.com/guides/route/, images/map.jpg se résout sous /guides/route/, et non dans le répertoire /images/ du site. Utilisez si possible l’adresse HTTPS complète souhaitée pour éviter toute ambiguïté. Une syntaxe d’URL valide ne prouve toujours pas que le fichier existe.
Ouvrez l’image séparément et vérifiez que les visiteurs peuvent y accéder sans connexion. Examinez ses dimensions réelles, la taille du fichier et son contenu ; modifier og:image:width ne redimensionne pas l’image. Par exemple, les exigences du module de partage LinkedIn précisent un minimum de 1200 × 627 pixels, une taille maximale de 5 Mo et un rapport recommandé de 1,91:1. Ce sont des exigences LinkedIn, pas des limites Open Graph universelles ni des mesures effectuées ici. Une image protégée peut rester inaccessible même avec des dimensions adaptées.
Distinguez aussi og:url de <link rel="canonical">. Le premier identifie l’objet partagé ; le second exprime une préférence canonique pour la recherche. Vérifiez le second avec le Vérificateur de Balises Canonical. Comme l’explique la documentation canonique de Google, ces signaux ne garantissent pas l’URL retenue par Google.
Vérifier la correction publiée et la couverture du rapport
Mettez à jour le champ du CMS ou le modèle responsable, publiez la modification et soumettez à nouveau la même page. Comparez l’URL finale, l’ordre des propriétés et les constats au rapport précédent. Les balises insérées uniquement après l’exécution de JavaScript sortent du périmètre : inspectez le HTML livré par la page, pas seulement le document modifié par le navigateur.
Lisez la couverture avant de considérer une ligne manquante comme une balise absente. Screpy conserve jusqu’à 200 déclarations Open Graph et 20 groupes d’images. Un rapport partiel peut omettre des déclarations ultérieures et ne permet pas d’établir toutes les associations d’images. Vérifiez la source complète avant de supprimer ou d’ajouter des balises sur cette seule base. Les valeurs sont également limitées à 4096 unités UTF-16 ; cette réduction seule ne déclenche pas l’étiquette de couverture partielle. Examinez donc les valeurs exceptionnellement longues dans la source.
Exportez le rapport JSON pour conserver les déclarations et les constats observés. Si la vérification ne peut pas aboutir, le résultat est indisponible ; cela ne signifie pas que la page a réussi le contrôle. Après avoir corrigé la source et examiné l’image réelle, vérifiez un partage réel sur la plateforme visée. Utilisez l’Analyseur de Balises Meta pour examiner aussi le titre ordinaire, la description et les autres déclarations du head.