Découvrez quels types de schéma conviennent aux articles de blog, aux termes de glossaire et aux actualités, et suivez des étapes simples pour tester le balisage schema afin d'obtenir des résultats enrichis.
Le balisage schema est un petit bloc de données structurées que vous ajoutez à une page pour que les moteurs de recherche lisent des faits clés de façon claire et cohérente. Pensez-y comme une étiquette sur une boîte : le contenu reste le contenu, mais l'étiquette facilite le tri et l'affichage.
Quand les moteurs comprennent mieux votre page, ils peuvent l'afficher comme résultat enrichi plutôt qu'un simple lien bleu. Un résultat enrichi peut inclure des informations supplémentaires comme un titre, une date de publication, l'auteur, un fil d'Ariane, ou un bref aperçu. Cela n'arrive pas pour toutes les pages et c'est toujours à la discrétion du moteur de recherche.
Il est utile de savoir ce que le schéma peut et ne peut pas faire. Les données structurées améliorent la clarté et l'éligibilité à certaines fonctionnalités de recherche, mais elles n'augmentent pas le classement à elles seules. Si une page est pauvre, obsolète ou difficile à crawler, le schéma ne le réparera pas. Et il ne peut pas forcer l'apparition d'un résultat enrichi.
Sur la plupart des sites, quelques règles simples comptent plus que tout le reste :
Un exemple simple : vous publiez une définition dans le glossaire et un article de blog qui s'y réfère. Avec le bon balisage, un moteur de recherche peut traiter plus sûrement une page comme définition et l'autre comme guide, plutôt que deux « articles » concurrents.
Si vous publiez beaucoup de pages (surtout à partir de modèles ou d'une API), le schéma devient encore plus utile car il maintient la cohérence de vos sorties en ajoutant des blogs, des actualités et des entrées de glossaire au fil du temps.
Pour la plupart des blogs, le point de départ recommandé est BlogPosting, qui est une version plus spécifique de Article.
Les plus grands bénéfices viennent généralement du fait d'avoir les éléments de base corrects sur chaque article. Les moteurs de recherche accordent plus d'importance à des signaux précis et stables qu'à une longue liste de propriétés optionnelles.
Rendez ces champs précis sur chaque article :
Si vous rafraîchissez un guide ancien, conservez datePublished comme date d'origine et mettez dateModified à la date de la mise à jour. Ne changez pas datePublished juste pour paraître récent, et ne modifiez dateModified que lorsqu'un vrai changement a eu lieu.
Les champs optionnels peuvent aider, mais seulement s'ils sont précis et faciles à maintenir. keywords peut fonctionner si vous affichez déjà des tags ou des catégories. wordCount est utile pour des pages longues principalement statiques, mais évitez-le si le contenu change souvent après publication. speakable n'a de sens que si vous maintenez un court résumé conçu pour être lu à voix haute.
Si votre pipeline génère automatiquement du JSON-LD (par exemple via un modèle CMS ou un rendu piloté par API), visez la cohérence et la correction avant d'ajouter des champs supplémentaires.
Les pages d'actualité sont fortement évaluées sur la fraîcheur et la clarté. Les moteurs veulent savoir ce qui s'est passé, quand cela a été publié et qui l'a publié. C'est pourquoi le balisage d'actualité est moins indulgent.
Utilisez NewsArticle lorsque la page rapporte un événement ou un développement opportun qui deviendra obsolète (même s'il reste dans vos archives). Utilisez Article pour les reportages evergreen, les éditoriaux et les longs formats qui ne sont pas liés à un moment précis.
Règle pratique :
Les dates comptent plus pour l'actualité que pour presque tout autre type de contenu. Incluez à la fois datePublished et dateModified et assurez-vous qu'elles correspondent à ce que le lecteur voit sur la page. Si vous mettez à jour une histoire, mettez à jour dateModified. Si vous « republiez » un ancien article comme neuf, assurez-vous que les dates visibles et les données structurées racontent la même histoire.
Pour de nombreuses pages d'actualité, un petit ensemble de champs porte la majeure partie de la valeur : titre, description, image (une vraie image accessible), auteur, éditeur (en tant qu'Organization), mainEntityOfPage, datePublished et dateModified.
Si vous avez un paywall ou un abonnement, signalez-le clairement avec isAccessibleForFree et les détails correspondants. Ne prétendez pas qu'un contenu est gratuit s'il ne l'est pas.
Pour les histoires republiées ou syndiquées, évitez de ressembler à une source dupliquée. Conservez une URL canonique par histoire, gardez les données structurées cohérentes sur cette version canonique, et évitez de changer les titres sur les copies. Si la même histoire existe à plusieurs endroits, précisez quelle page est la version principale.
Les pages de glossaire peuvent obtenir des extraits plus clairs quand les moteurs comprennent que vous définissez des termes, pas que vous publiez des articles standards. Même si votre objectif principal est le balisage schema pour les blogs, le balisage de définition aide les moteurs à classer plus rapidement le contenu du glossaire.
Utilisez DefinedTerm lorsqu'une page explique un seul terme. Utilisez DefinedTermSet lorsqu'une page est une collection de termes, comme un glossaire A–Z ou une page de catégorie avec de nombreuses entrées. Utilisez FAQPage seulement quand la page est vraiment une liste de questions-réponses, pas une définition unique.
Règle simple : si l'objectif de la page est « définir ceci », choisissez DefinedTerm. Si l'objectif est « parcourir plusieurs définitions », choisissez DefinedTermSet.
Pour une page de terme unique, concentrez le balisage sur un seul terme et sa définition, ainsi que son emplacement dans l'ensemble.
{
"@context": "https://schema.org",
"@type": "DefinedTerm",
"name": "Canonical tag",
"alternateName": ["rel=canonical", "canonical URL"],
"description": "A canonical tag tells search engines which URL is the preferred version of a page.",
"inDefinedTermSet": {
"@type": "DefinedTermSet",
"name": "SEO Glossary"
}
}
Pour une page de catégorie, utilisez DefinedTermSet. Ajoutez un ItemList des pages de termes seulement si cette liste est visible pour les utilisateurs sur la page.
Quand vous avez des synonymes, utilisez alternateName pour les vraies variations, acronymes et différences d'orthographe. Restez court et honnête ; n'entassez pas de mots-clés.
Alignez le texte de la définition avec ce que les utilisateurs peuvent lire. Si la description JSON-LD dit une chose et que la définition visible en dit une autre, les résultats enrichis deviennent moins probables.
Certains types de schéma aident presque toutes les pages, qu'il s'agisse d'un article de blog, d'une entrée de glossaire ou d'une actualité.
BreadcrumbList est l'un des gains les plus simples. Il montre où une page se situe sur votre site en utilisant le même fil que les utilisateurs voient (Home > Blog > Topic > Post). Cela peut clarifier l'apparence de votre résultat et réduit la confusion quand des pages similaires existent dans différentes sections.
Organization et WebSite donnent des signaux de marque clairs. Organization couvre votre nom, logo et informations de contact de base. WebSite peut décrire le site et, optionnellement, une action de recherche interne. N'incluez le balisage de recherche que si les utilisateurs peuvent réellement rechercher sur votre site.
Les images méritent aussi de l'attention. Si les pages reposent sur des images hero ou featured, ajouter ImageObject (ou décrire complètement l'image dans votre schéma principal) aide les moteurs à comprendre ce qu'est l'image, où elle se trouve et ses propriétés clés.
Le balisage auteur cause souvent des incohérences évitables. Choisissez une approche et tenez-vous-y : utilisez Person quand un individu réel écrit et est crédité sur la page, et Organization quand le contenu est publié sous le nom de la marque. Évitez d'alterner entre Person et Organization pour un même nom d'auteur.
Utilisez sameAs uniquement pour des profils officiels que vous contrôlez. Si vous n'êtes pas sûr, ne l'ajoutez pas. Des profils obsolètes ou incorrects peuvent nuire à la confiance.
JSON-LD est souvent la manière la plus sûre d'ajouter des données structurées car il vit dans un seul bloc \u003cscript type="application/ld+json"\u003e et n'altère pas ce que voient les utilisateurs. Placez-le dans le HTML de la page (souvent dans le \u003chead\u003e ou près de la fin du \u003cbody\u003e), et assurez-vous qu'il est rendu sur la page finale, pas seulement dans un aperçu.
Partir du contenu visible, puis mappez-le aux champs schema. Si la page affiche un titre, le nom de l'auteur, la date de publication, l'image mise en avant et une courte description, votre JSON-LD doit correspondre exactement à ces valeurs. Les décalages sont une cause fréquente d'échec d'obtention de résultats enrichis.
Créez un modèle reproductible par type de contenu (article de blog, actualité, terme de glossaire). La configuration la plus sûre est lorsque le modèle puise dans la même source que le contenu de la page, afin que les mises à jour restent synchronisées.
Un flux de déploiement qui limite les risques :
@id.Voici un petit modèle pour des ID stables (remarquez @id basé sur l'URL) :
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://example.com/blog/my-post#blogposting",
"headline": "My Post Title",
"datePublished": "2026-01-16",
"mainEntityOfPage": "https://example.com/blog/my-post"
}
Si votre site est construit avec un framework comme Next.js, générez ce bloc au moment du rendu à partir de votre CMS ou API de contenu.
La validation se fait en deux temps. D'abord, vérifiez que votre JSON-LD est valide et respecte les règles du schéma. Ensuite, contrôlez si Google le juge éligible aux résultats enrichis. Passer des contrôles de syntaxe ne garantit pas que vous obtiendrez un résultat enrichi.
Commencez par copier le JSON-LD rendu exact depuis la page en ligne (pas un fichier modèle) et validez-le pour détecter les problèmes généraux de schéma. Le Schema Markup Validator est utile pour repérer les noms de propriétés incorrects, les champs obligatoires manquants et les incompatibilités de types.
Ensuite, testez l'éligibilité aux résultats enrichis avec l'outil Rich Results Test de Google. Cela se concentre sur les fonctionnalités que Google affiche réellement et met en évidence les champs manquants qui bloquent l'éligibilité même quand le balisage est techniquement valide. Pour le contenu de blog, de petites lacunes comme une image manquante ou un auteur absent sont des raisons fréquentes d'absence d'enrichissement.
Traitez les résultats différemment :
Si vous modifiez un modèle partagé et que le Rich Results Test signale des datePublished manquantes sur certaines pages, c'est souvent un problème de données (champ vide dans votre CMS), pas un problème de schéma.
Retestez après chaque changement de modèle, même s'il semble mineur. Si vous générez du contenu via une API, validez une nouvelle page publiée de chaque type de contenu avant de déployer les changements partout.
Les résultats enrichis échouent souvent pour des raisons simples : les moteurs lisent vos données structurées, mais ne leur font pas confiance.
La règle d'or est de correspondre à ce que voient les utilisateurs. Si votre JSON-LD affirme un nom d'auteur, un titre ou une date de publication, ces éléments doivent être visibles sur la page. Ne cachez pas d'informations clés uniquement dans le balisage et n'utilisez pas des formulations différentes.
L'absence de champs obligatoires est un autre frein courant. Pour les pages de type Article, le titre, l'image et les dates de publication ou de mise à jour sont souvent requis. Si votre image est trop petite, manquante ou inaccessible, la page peut rester exclue des résultats enrichis même si tout le reste est correct.
Utiliser le mauvais type de schéma peut aussi nuire. Ajouter FAQPage à une page qui n'est pas une section Q&A peut faire ignorer ou signaler le balisage. Choisissez des types qui reflètent la page réelle : BlogPosting pour un article de blog, NewsArticle pour une actualité, DefinedTerm pour une définition.
Quelques problèmes récurrents :
Exemple : une équipe publie un post d'actualité et la page affiche « Mis à jour le 16 janv. », mais le balisage contient encore la date de la semaine dernière issue d'un modèle réutilisé. Même avec un schéma NewsArticle correct, les moteurs peuvent juger la page peu fiable tant que le contenu visible et les données structurées ne correspondent pas.
Avant de publier, faites un contrôle de cohérence rapide. La plupart des problèmes de résultats enrichis ne sont pas des erreurs graves. Ce sont de petites incohérences entre ce que montre la page et ce que dit le balisage.
Si vous ajoutez du balisage schema pour les blogs, commencez par décider ce qu'est la page (BlogPosting, NewsArticle ou page de définition). Tout le reste doit soutenir ce choix.
Si vous publiez une actualité puis réutilisez le même modèle pour une entrée de glossaire, ne laissez pas des champs NewsArticle derrière. Une page de définition qui prétend encore être un NewsArticle échoue souvent les contrôles d'éligibilité.
Imaginez un petit site qui publie trois choses : des billets de blog hebdomadaires, un glossaire de termes clés et un hub d'actualités pour les communiqués d'entreprise. L'objectif est d'obtenir des extraits de recherche plus clairs et l'éligibilité aux résultats enrichis sans changer la conception des pages.
Les choix de schéma diffèrent selon l'intention. Les articles de blog conviennent souvent à BlogPosting (ou Article). Les actualités correspondent à NewsArticle uniquement quand elles sont vraiment opportunes. Les entrées de glossaire doivent se concentrer sur DefinedTerm et DefinedTermSet (souvent associées à WebPage) pour indiquer aux moteurs « cette page définit un terme », pas « c'est une histoire ».
Voici un déploiement pratique sur 2 semaines qui limite les risques :
BreadcrumbList et un profil Organization (éditeur).Après le déploiement, confirmez deux choses : que le balisage est toujours présent sur la page en ligne (et qu'il n'est pas supprimé par votre moteur de rendu ou des outils de consentement), et que les moteurs crawlent les pages mises à jour et rapportent les données structurées dans leurs rapports d'enrichissement.
Le succès ressemble généralement à plus d'impressions pour des pages déjà bien classées, l'apparition d'éléments enrichis pour les types éligibles et une légère hausse du CTR grâce à des titres, dates et fils d'Ariane plus propres.
Le schéma n'est pas une tâche ponctuelle. Il casse le plus souvent quand un modèle change, qu'un champ est renommé, ou qu'un nouveau bloc de contenu est ajouté sans que le JSON-LD soit mis à jour.
Intégrez les données structurées dans le processus de publication. Si vous gérez un blog, un hub d'actualité et un glossaire, décidez quels champs sont requis pour chaque type de contenu, puis traitez ces champs comme vous traitez le titre et l'URL : ils doivent être fournis à chaque publication.
La façon la plus simple de maintenir la cohérence du balisage schema pour les blogs est de le lier à la même source de vérité que celle qui génère la page : titre, auteur, date de publication, images, catégorie et corps principal. Quand le contenu est créé avec différents outils par plusieurs personnes, des champs manquants apparaissent (pas d'auteur, mauvais format de date, tableau d'images vide) et les résultats enrichis deviennent moins probables.
Une routine légère qui fonctionne pour la plupart des équipes :
Si vous publiez à grande échelle, l'automatisation aide. Par exemple, GENERATED (generated.app) peut générer du contenu de blog, d'actualité et de glossaire via une API et maintenir la cohérence des champs de données structurées entre les modèles, y compris lorsque vous traduisez ou rafraîchissez du contenu.
Exemple : si vous introduisez un nouveau badge « dernière mise à jour », mettez aussi à jour votre JSON-LD pour inclure dateModified, puis validez un article de blog d'exemple, une page NewsArticle et une page de terme de glossaire avant la mise en production.
Le balisage schema est des données structurées qui aident les moteurs de recherche à lire les informations clés d'une page de façon cohérente. Il peut rendre votre page éligible à des résultats enrichis (affichage des dates, fil d’Ariane, ou détails supplémentaires), mais il n'améliore pas le classement à lui seul.
Utilisez BlogPosting lorsque la page est clairement un article de blog (guide, récapitulatif, opinion, mise à jour). Utilisez Article lorsque votre contenu est plus large, éditorial, ou si votre système génère déjà Article et que vous souhaitez garder les types cohérents sur le site.
Commencez par les champs qui doivent être précis et stables : headline, author, datePublished, image et mainEntityOfPage. Si ces éléments correspondent à ce que voit l'utilisateur sur la page, vous avez couvert l'essentiel pour l'éligibilité et la confiance.
Conservez datePublished comme date de publication initiale et ne mettez à jour que dateModified lorsque vous effectuez une vraie modification du contenu. Changer datePublished pour donner l'impression que l'article est récent peut se retourner contre vous si cela ne correspond pas à ce que montre la page.
Utilisez NewsArticle uniquement pour des sujets d'actualité avec un moment de publication clair, comme des annonces ou des informations urgentes qui deviendront obsolètes. Utilisez Article pour les contenus evergreen (explications, éditoriaux, longs formats) qui ne sont pas liés à un événement précis.
Utilisez DefinedTerm quand une page définit un seul terme, et DefinedTermSet quand la page est une collection de termes (par exemple un glossaire A–Z). Assurez-vous que la définition structurée correspond à la définition visible sur la page pour éviter les incohérences.
BreadcrumbList aide les moteurs de recherche à afficher un fil d’Ariane clair plutôt qu’une URL longue, ce qui réduit la confusion quand des pages similaires existent dans des sections différentes. C’est aussi un type de schéma facile à maintenir puisqu’il reflète votre navigation visible.
Placez un seul bloc JSON-LD dans une balise script (type="application/ld+json") dans le HTML rendu final, souvent dans le head ou près de la fin du body. Générer le JSON-LD à partir des mêmes données que celles qui affichent le titre, les dates, l'auteur et l'image est la méthode la plus sûre pour rester synchronisé.
Validez en deux étapes : d'abord vérifiez que le JSON-LD est conforme au schéma et utilise les bonnes propriétés et types ; ensuite testez l'éligibilité aux résultats enrichis séparément. Un schéma valide n'implique pas nécessairement l'apparition d'un résultat enrichi.
Les blocages les plus courants sont des incohérences entre le balisage et ce que voit l'utilisateur, l'absence de champs clés (image accessible, date de publication), ou des blocs de schéma conflictuels qui donnent des informations différentes (URL, titres, auteurs). Assurez-vous d'un type principal clair par page et évitez d'ajouter des types qui ne correspondent pas au contenu réel.