Ce qu'un vérificateur de métadonnées de site Web fait réellement
Un vérificateur de métadonnées envoie une requête HTTP à votre URL, analyse la section HTML <head> et extrait toutes les balises méta pertinentes. Il recherche <title>, <meta name="description">, <meta property="og:...">, <meta name="twitter:...">, <link rel="canonical">, <link rel="icon">, <link rel="alternate" hreflang="...">, <meta name="viewport">, et tous les blocs <script type="application/ld+json">. Il affiche chaque balise avec le nom d'attribut et la valeur de contenu dans un rapport structuré.
Puis il va plus loin. Il affiche une carte d'aperçu SERP en utilisant le titre et la méta-description tels qu'ils apparaîtraient dans la recherche Google sur ordinateur de bureau et mobile. Il affiche un aperçu de la carte Twitter en utilisant les balises twitter:title, twitter:description et twitter:image. Il affiche un aperçu LinkedIn en utilisant les balises Open Graph. Et il affiche un aperçu de déploiement Slack, qui utilise les balises OG par défaut mais revient au titre de la page s'il manque OG.
Deux problèmes restent invisibles jusqu'à ce que vous voyiez l'aperçu. Le premier est la troncature : les titres plus longs que 60 caractères ou les méta-descriptions plus longues que 160 caractères sont coupés dans Google. Le second est l'absence d'images. Une page peut avoir un titre et une description mais pas de og:image, donc la carte Twitter apparaît en texte uniquement et semble cassée. Les aperçus détectent les deux instantanément.
Comment utiliser ce vérificateur de métadonnées de site Web
- Collez l'URL de la page dans Page URL. Utilisez la version canonique si vous la connaissez : https, www si applicable, pas de paramètres UTM.
- Sélectionnez un User-agent dans la liste déroulante si vous souhaitez voir comment les métadonnées diffèrent pour les utilisateurs mobiles ou Googlebot. Desktop Chrome est la valeur par défaut. Mobile Chrome et Googlebot sont utiles pour tester l'indexation mobile-first ou les métadonnées rendues par JavaScript.
- Collez une deuxième URL dans Compare with si vous souhaitez voir vos métadonnées à côté de celles d'un concurrent ou vérifier la cohérence entre les versions linguistiques de la même page.
- Cliquez sur Check metadata. Vous obtenez un tableau des balises extraites, des avertissements pour les balises manquantes ou invalides, et quatre cartes d'aperçu rendues : Google SERP, Twitter/X, LinkedIn et Slack.
- Développez la section Warnings si des lignes sont signalées. Nous signalons les og:image manquantes, les titres tronqués, les configurations de viewport incorrectes, les schémas invalides et les erreurs hreflang.
Essayez de vérifier l'URL d'un article de blog. Si la page n'a pas d'image Open Graph, vous voyez un aperçu Google avec titre et description, mais les aperçus Twitter et LinkedIn affichent des espaces réservés d'image cassée. Ajoutez une balise og:image pointant vers un PNG 1200x630, revérifiez, et les aperçus se mettent à jour pour afficher l'image en vedette.
Pourquoi les aperçus rendus sont plus importants que les balises brutes
Une balise peut être techniquement présente et échouer quand même en pratique. Un titre de 80 caractères passe la validation mais est tronqué dans Google à 60, donc les 20 derniers caractères sont invisibles aux chercheurs. Une URL og:image peut retourner 404, rendant la balise inutile même si elle existe. Un twitter:card défini sur summary_large_image nécessite une image au ratio d'aspect 2:1, mais si l'image est carrée, Twitter revient à la petite carte de résumé.
Trois conséquences pratiques.
Taux de clics. Les titres tronqués et les images manquantes nuisent au CTR dans la recherche et les réseaux sociaux. Un aperçu soigné avec un titre clair, une description axée sur les avantages et une image frappante reçoit plus de clics qu'un extrait en texte brut. Tester avant de publier vous permet de corriger la mise en page avant de perdre du trafic.
Cohérence de la marque. Si votre page d'accueil a des métadonnées parfaites mais que les pages de produits n'ont pas d'image OG ou se rabattent sur le logo du site, l'expérience utilisateur est incohérente. La vérification en masse des modèles révèle les types de pages qui ont besoin de correctifs.
Différences de plateforme. Google lit la balise titre et la méta-description. Twitter lit twitter:title et twitter:description, ou se rabat sur les balises OG. LinkedIn ne lit que les balises OG. Slack lit les balises OG et parfois le favicon. Une balise manquante peut casser l'aperçu sur une plateforme mais pas sur d'autres. Voir les quatre aperçus à la fois montre les lacunes.
Open Graph vs Twitter Card vs schema.org
Les balises Open Graph ont été inventées par Facebook et sont maintenant utilisées par LinkedIn, Slack, Discord et la plupart des plateformes sociales. Les balises principales sont og:title, og:description, og:image, og:url et og:type. La définition de celles-ci contrôle l'apparence des liens lors du partage.
Les balises Twitter Card : twitter:card, twitter:title, twitter:description, twitter:image remplacent les balises OG sur Twitter/X. Si les deux sont présentes, Twitter lit d'abord les balises Twitter. Si seules les balises OG sont présentes, Twitter les utilise. La plupart des sites définissent les balises OG et sautent les balises Twitter car le repli fonctionne. L'exception est twitter:card, qui doit être défini sur summary_large_image si vous voulez l'aperçu à grande image.
Les données structurées schema.org se trouvent dans les scripts JSON-LD dans le <head> ou le <body>. Elles indiquent à Google quel type de contenu contient la page : Article, Product, Recipe, Event, FAQ, et fournissent des champs lisibles par machine comme l'auteur, la date de publication, le prix et la note. Google utilise ceci pour les résultats enrichis comme les notes étoilées dans la recherche. Notre vérificateur valide la syntaxe JSON-LD et signale les types de schéma trouvés.
Hreflang, canonical et viewport
Les balises Hreflang déclarent les variantes linguistiques et régionales d'une page. Si vous avez des versions anglaise, espagnole et française de /about, chacune doit avoir des balises <link rel="alternate" hreflang="es" href="..."> pointant vers les autres. Google les utilise pour servir la bonne langue dans les résultats de recherche. Notre vérificateur énumère toutes les balises hreflang et signale les erreurs courantes : liens de retour manquants, codes de langue incorrects ou hreflang pointant vers un 404.
La balise canonical indique à Google quelle URL est l'original quand des doublons existent. Un vérificateur de métadonnées signale le canonical et s'il s'auto-référence ou pointe ailleurs. Si vous voyez un canonical pointant vers un domaine différent ou un 404, c'est un signal d'alerte. Utilisez notre vérificateur canonical pour des diagnostics canonical plus approfondis.
La balise méta viewport : <meta name="viewport" content="width=device-width, initial-scale=1"> contrôle le rendu mobile. S'il manque, les navigateurs mobiles rendent la page à la largeur du bureau et l'agrandissent, rendant le texte minuscule. Google pénalise les pages sans balise viewport dans l'indexation mobile-first. Notre vérificateur signale l'absence ou rapporte la valeur de contenu si elle est présente.
Erreurs courantes
- Définir le titre OG différent du titre HTML. Si
<title>fait 70 caractères etog:titlefait 40, votre extrait Google et votre carte de partage social ont un texte différent. Cela confond les utilisateurs. Gardez-les alignés sauf si vous avez une bonne raison de différer. - Utiliser une image carrée pour
og:image. Twitter et LinkedIn attendent 1200x630 ou un ratio 1,91:1. Une image carrée est rognée ou encadrée. Utilisez le même rapport d'aspect partout. - Oublier
og:url. Cette balise indique aux plateformes l'URL canonique à associer au partage. Sans elle, les paramètres d'URL comme?ref=twitterpourraient devenir l'URL partagée, créant un engagement en double sur les variantes. - Pas de texte alt sur l'image OG. Les plateformes n'affichent pas le texte alt pour les images OG, mais les lecteurs d'écran et les outils d'accessibilité en dépendent. Si vous utilisez une balise
imgdans votre balisage pour la même image, définissez le texte alt là. - Définir
twitter:cardsursummaryquand vous voulez la grande image. La valeur par défaut est une petite miniature carrée. Changez-la ensummary_large_imagepour obtenir la mise en page en vedette. - Déployer avec des métadonnées de test. « Titre du message de test » ou « Lorem ipsum » en production arrive plus souvent qu'on ne le pense. Une vérification rapide avant la publication détecte cela.
Conseils avancés
- Utilisez le champ Compare with pour comparer vos métadonnées avec celles d'une page concurrente bien classée. Si leur titre est plus court, leur description plus spécifique et ils ont du schéma tandis que vous n'en avez pas, vous savez ce qu'il faut corriger.
- Testez la même URL avec Desktop Chrome et Googlebot comme user-agents. Si les métadonnées diffèrent, votre page se masque ou sert un contenu différent aux bots, ce qui viole les directives de Google.
- Vérifiez une page par modèle : page d'accueil, produit, catégorie, article de blog, page d'atterrissage. Les erreurs de métadonnées sont généralement au niveau du modèle, pas au niveau de la page, donc corriger une en corrige des centaines.
- Regardez la section schéma. Si vous avez plusieurs blocs JSON-LD, assurez-vous qu'ils sont valides et ne sont pas en conflit. Deux déclarations
@typeen conflit peuvent amener Google à ignorer les deux. - Testez hreflang sur les sites multilingues. Un lien de retour manquant (où la page en espagnol pointe vers la page en anglais mais la page en anglais ne pointe pas en retour) brise hreflang entièrement.
- Téléchargez le rapport en JSON et comparez-le avec une vérification précédente. Utilisez-le dans CI pour détecter les régressions de métadonnées lors du déploiement d'un nouveau thème ou générateur de pages.
Après vérification des métadonnées, si les avertissements mentionnent des canonicals manquants ou des incompatibilités hreflang, exécutez le vérificateur canonical pour tester en masse les variantes d'URL. Si des avertissements de schéma apparaissent, revalidez avec Google's Rich Results Test. Pour voir comment Googlebot rend réellement la page (exécution JavaScript, ressources bloquées, texte visible), le simulateur d'exploration Google affiche le HTML brut et rendu par JS côte à côte. Pour un audit SEO sur page plus complet incluant les métadonnées, la longueur du titre, le H1 et les liens internes, utilisez la liste de contrôle SEO.