Un de mes premiers articles a passé six mois en ligne avant que je m'aperçoive qu'il envoyait à Google un signal contradictoire : la date de publication annoncée dans mes données structurées ne correspondait pas à celle affichée dans le fil d'Ariane. Résultat, deux versions de la même page dans les résultats, et une position qui dansait entre la page 2 et la page 4. Tout ça pour deux lignes de JSON dans le <head>.
Depuis, je vérifie chaque balise Schema.org à la main, même quand mon CMS jure qu'il s'en occupe. Et c'est précisément pour ça que je vous écris cet article : parce que la documentation officielle vous montre le quoi, jamais le pourquoi ça casse. Le balisage Schema.org pour les articles de blog, c'est le sujet, et on va le prendre par le concret.
Points clés à retenir
- Le type
BlogPostingest presque toujours préférable àArticlepour un blog, mais la différence se joue sur des détails, pas sur la nature du contenu. - Le format JSON-LD dans le
<head>reste la méthode la plus fiable, loin devant Microdata et RDFa. - Google exige certaines propriétés pour afficher des rich results (image, auteur, éditeur) et en ignore d'autres complètement.
- Une erreur de date est plus fréquente qu'une erreur de syntaxe — et fait plus de dégâts.
- Valider ne suffit pas : le Rich Results Test et le Schema Markup Validator répondent à deux questions différentes.
- Sur un site à plusieurs auteurs, la propriété
authordoit pointer vers unPerson, pas vers une chaîne de texte.
Pourquoi le balisage Schema.org change vraiment la donne pour vos articles
Google ne lit pas votre article comme vous. Il le découpe en signaux : titre, entités, dates, auteur, structure. Le balisage Schema.org sert à lever l'ambiguïté quand plusieurs interprétations sont possibles. Une page qui parle d'un livre peut être une critique, une fiche produit ou une page d'archive — les données structurées disent laquelle.
Sur un blog, l'enjeu est plus prosaïque : être considéré comme le créateur original du contenu. Sans balisage correct, vous laissez Google deviner qui a publié quoi en premier. Et quand un agrégateur reprend votre article, cette ambiguïté coûte cher.
Ce que Google fait réellement de ces données
Deux choses distinctes, souvent confondues :
- Comprendre la page (son type, son auteur, sa date) pour le classement et l'indexation.
- Décider d'afficher un rich result, avec vignette, auteur et date visibles directement dans les résultats.
La première fonction ne dépend pas de la syntaxe parfaite. La seconde, oui. Un rich result ne s'affiche que si les propriétés requises sont présentes et cohérentes avec le contenu visible de la page. C'est là que la plupart des implémentations échouent : elles balisent ce qui devrait être là, pas ce qui est affiché.
Choisir entre Article, NewsArticle et BlogPosting : la décision qui compte
Franchement, les trois types partagent 90 % de leurs propriétés. La question n'est pas « lequel est le meilleur » mais « lequel Google attend sur ce type de page ».
| Type | Usage typique | Propriété distinctive |
|---|---|---|
BlogPosting | Article de blog, publication régulière | Aucune propriété exclusive, mais sous-type explicite de SocialMediaPosting |
Article | Contenu éditorial générique, evergreen | Fourre-tout : fonctionne partout, ne se distingue nulle part |
NewsArticle | Actualité, presse en ligne | dateline (lieu et date de rédaction) |
Pour un blog, je recommande BlogPosting dans la quasi-totalité des cas. Pas parce qu'il déclenche un traitement magique, mais parce qu'il envoie un signal cohérent : ceci est un article de blog, avec un auteur identifié, publié dans le cadre d'une publication régulière. Google s'en sert pour distinguer les blogs des sites d'actualité, notamment dans les contextes d'actualité chaude où la fraîcheur compte.
Quand faut-il vraiment utiliser NewsArticle ?
Uniquement si votre site est référencé comme source d'actualité et que le rythme de publication est quotidien ou presque. NewsArticle ouvre l'accès à des fonctionnalités spécifiques (Top Stories, notamment dans les contextes d'actualité), mais il impose aussi une exigence de fraîcheur que vous ne pourrez peut-être pas tenir. J'ai vu des blogs d'entreprise se baliser en NewsArticle pour « faire sérieux ». Ils ont perdu en cohérence et rien gagné. Ne faites pas ça.
Un exemple de JSON-LD complet, propriété par propriété
Voici ce que j'utilise sur mes propres articles. J'ai retiré les fioritures et gardé ce qui a un effet mesurable.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Configurer le balisage Schema.org pour les articles de blog",
"description": "Guide pratique pour implémenter les données structurées BlogPosting.",
"image": {
"@type": "ImageObject",
"url": "https://exemple.fr/images/article-schema.jpg",
"width": 1200,
"height": 630
},
"datePublished": "2026-07-27T09:00:00+02:00",
"dateModified": "2026-07-27T09:00:00+02:00",
"author": {
"@type": "Person",
"name": "Prénom Nom",
"url": "https://exemple.fr/auteurs/prenom-nom"
},
"publisher": {
"@type": "Organization",
"name": "Nom du site",
"logo": {
"@type": "ImageObject",
"url": "https://exemple.fr/images/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://exemple.fr/article-schema-org"
}
}
</script>Propriétés obligatoires vs recommandées
Google ne sanctionne pas l'absence d'une propriété recommandée. Il se contente de ne pas afficher le rich result correspondant. La distinction est importante, parce qu'elle détermine ce sur quoi vous devez vous battre.
- headline — le titre. Il doit correspondre au titre affiché, sans y ajouter de mots-clés.
- image — requise pour les rich results. Une URL cassée et le rich result disparaît, sans avertissement explicite.
- datePublished — la date de première publication, au format ISO 8601 avec fuseau horaire.
- author — un objet
Personavec unnameet idéalement unurlvers une page auteur. - publisher — un objet
Organizationavec un logo. C'est le champ le plus souvent mal renseigné.
Ah, et dateModified : ne la remplissez pas avec la date du jour à chaque rechargement. J'ai fait ça sur deux cents articles, pensant bien faire. Google a fini par ignorer le champ. Une date de modification doit refléter une vraie modification de contenu.
Valider, corriger, et comprendre les avertissements
Deux outils, deux rôles. Le Rich Results Test de Google vous dit si votre page est éligible à un affichage enrichi. Le Schema Markup Validator vérifie la conformité syntaxique et sémantique au vocabulaire Schema.org, sans se soucier de ce que Google en fait. Vous avez besoin des deux.
Ce que j'ai appris en corrigeant mes propres erreurs :
- Un avertissement n'est pas une erreur. Le validateur signale des propriétés optionnelles manquantes ; ça n'empêche rien.
- Les erreurs de type « champ manquant » disparaissent souvent si vous remplissez
imagecorrectement. - Search Console remonte les problèmes de données structurées avec un délai de plusieurs jours, parfois une semaine. Ne cherchez pas la cause immédiate.
Où tester un Schema validator sérieusement ?
Le Schema Markup Validator valide la syntaxe pure. Le Rich Results Test simule le rendu Google. Le premier est utile pour repérer une virgule mal placée dans votre JSON ; le second pour savoir si votre article aura droit à sa vignette. Utilisez-les dans cet ordre : syntaxe, puis rendu. J'ai perdu une heure à chercher une erreur de rendu qui venait en réalité d'une accolade en trop.
Intégrer le balisage dans un CMS réel
WordPress, Joomla, Shopify : tous proposent des extensions qui injectent des données structurées. Le problème n'est pas l'outil, c'est ce que l'outil produit. La plupart génèrent un balisage par défaut qui ne correspond pas exactement à votre configuration éditoriale.
Test que j'applique systématiquement :
- Publier un article de test avec l'extension active.
- Copier le HTML source, le passer dans le validateur.
- Comparer avec le contenu visible. Si une propriété annonce un auteur différent de celui affiché, l'extension fait fausse route.
- Désactiver l'extension et injecter le JSON-LD manuellement dans le
headvia une fonction ou un snippet. Sur mon site, ça a réglé trois problèmes d'un coup.
Sur un blog multi-auteurs, chaque author doit pointer vers une entité Person distincte, avec un url vers la page de profil. Un site que je suivais balisait tous ses articles avec le nom de l'entreprise comme auteur. Résultat : aucune attribution d'auteur dans les résultats, et un signal d'expertise dilué. Corrigé en une après-midi.
Ce qu'on me demande le plus souvent
BlogPosting ou Article : ça change vraiment quelque chose ?
Pour le classement, pas directement. Pour la cohérence et pour l'accès à certains affichages, oui. BlogPosting est un sous-type plus précis qui indique à Google la nature éditoriale du contenu. Un blog qui se balise en Article ne perd rien, mais ne se distingue pas non plus. Je choisis toujours le type le plus spécifique.
Combien de temps avant de voir un effet ?
Pour l'indexation des données structurées, comptez de quelques jours à deux semaines. Pour voir un changement dans les rich results, davantage. Ce qui est immédiat, en revanche : la détection des erreurs dans Search Console. C'est déjà ça de gagné — vous saurez vite si quelque chose cloche.
Le JSON-LD est-il obligatoire ?
Non. Google lit aussi Microdata et RDFa. Mais JSON-LD est le format recommandé, le plus simple à maintenir et le plus lisible. Injecter du RDFa dans du HTML éditorial, c'est se condamner à des balises imbriquées illisibles. Sur un blog, je ne vois aucune raison de faire autrement.
Ce qui reste après avoir tout validé
Un balisage propre ne remplace pas un bon article. Il lève une ambiguïté, il clarifie un signal, il donne à Google de quoi trancher quand plusieurs pages se ressemblent. Rien de plus.
Ce que j'ai fini par comprendre, à force de corriger des dates incohérentes et des auteurs fantômes, c'est que les données structurées sont un exercice de rigueur avant d'être un levier SEO. Elles obligent à répondre à des questions simples qu'on évite : qui a écrit ceci, quand, sous quelle identité, avec quelle image associée. Quand on y répond honnêtement, le balisage suit tout seul. Quand on triche, Google finit par le voir.
La prochaine fois que vous publiez, ouvrez le validateur. Pas pour cocher une case, mais pour vérifier une chose : ce que votre <head> raconte correspond-il à ce que vos lecteurs voient ? Si la réponse est non, vous savez quoi corriger.
