Depuis plusieurs années, Google incite les webmasters à structurer davantage leurs contenus grâce aux données structurées. Ces balises permettent aux moteurs de mieux comprendre le contexte des pages, d’en extraire des informations spécifiques et, le cas échéant, d’afficher des extraits enrichis dans les résultats de recherche (Rich Snippets). Le 15 janvier 2015, Google a renforcé cette orientation en lançant un outil de test des données structurées à destination du grand public. Accessible également via Google Webmaster Tools, cet outil permet de vérifier le bon balisage d’une page et d’identifier les erreurs ou les données manquantes.
Avant de Commencer : Les données structurées, c’est quoi ? Définition & histoire
Les données structurées (ou structured data en anglais) désignent une méthode d’organisation de l’information dans le code d’une page web afin de permettre aux moteurs de recherche de mieux comprendre le contenu affiché. Concrètement, ce sont des balises spécifiques ajoutées au HTML d’un site internet, selon une syntaxe bien définie, qui encadrent et qualifient certains éléments (titre, auteur, date, avis, lieu, événement, etc.). Ces balises permettent à des machines, comme les robots d’indexation de Google, Bing ou Yandex, d’interpréter des contenus avec précision — là où le langage naturel pourrait prêter à confusion.
Mais pour comprendre les données structurées dans le contexte moderne du Web, il faut faire un petit retour dans le passé. L’idée d’organiser les données selon des normes machine-compatibles ne date pas d’hier. Dès les années 1970, avec l’essor des bases de données relationnelles (notamment le modèle de Codd chez IBM), les informaticiens ont pris conscience de la nécessité de structurer l’information pour la rendre exploitable à grande échelle. Cette philosophie a été prolongée dans les années 1990 avec le XML (eXtensible Markup Language), promu par le W3C, qui permettait déjà d’encapsuler des contenus dans des balises nommées selon leur fonction ou leur sens. Mais ce n’est véritablement qu’à l’avènement du Web sémantique, à la fin des années 1990, que les premières initiatives visant à structurer les contenus en ligne de manière universelle sont apparues.
Le Web sémantique, conceptualisé par Tim Berners-Lee (inventeur du World Wide Web au CERN en 1989), repose sur un principe simple : enrichir les pages web d’un vocabulaire lisible par les machines. L’objectif ? Aller au-delà du simple affichage, en construisant un réseau de données intelligibles pour permettre aux algorithmes d’agir avec pertinence. Cela conduit à l’apparition de plusieurs standards dans les années 2000 : RDF (Resource Description Framework), OWL (Web Ontology Language), ou encore les microformats comme hCard, hReview ou hEntry.
Cependant, ces technologies souffraient souvent de lourdeur ou d’une adoption fragmentée. C’est alors qu’en 2011, les géants du Web (Google, Microsoft, Yahoo! et Yandex) décident de s’unir pour lancer le projet Schema.org. Ce vocabulaire universel, basé sur le standard JSON-LD (JavaScript Object Notation for Linked Data), a permis de démocratiser l’usage des données structurées sur les sites web. En quelques années, JSON-LD s’impose comme le format privilégié, notamment parce qu’il peut être intégré facilement dans la balise <head> d’une page, sans impacter le code HTML principal.
Depuis, l’usage des données structurées n’a cessé de croître. Elles sont aujourd’hui indispensables pour bénéficier d’extraits enrichis (rich snippets) dans les SERP de Google, comme les étoiles de notation, les FAQ, les événements, les produits ou encore les recettes de cuisine. Elles alimentent également le Knowledge Graph de Google, lancé en 2012, qui centralise les informations sémantiques sur les entités connues (entreprises, personnes, lieux, œuvres, etc.).
On distingue aujourd’hui plusieurs vocabulaires majeurs de données structurées :
- Schema.org : le plus complet, soutenu par les moteurs principaux, utilisé avec JSON-LD, Microdata ou RDFa ;
- Microformats.org : plus ancien, utilisé dans certains CMS comme WordPress ou Typo3, basé sur du HTML enrichi ;
- Dublin Core : utilisé pour les bibliothèques numériques et les métadonnées académiques (notamment en Europe).
Les données structurées ne sont donc pas qu’un gadget SEO. Elles forment la grammaire du Web sémantique. Elles permettent aux moteurs de compréhension automatique d’indexer, catégoriser, comparer, recommander. Elles servent d’intermédiaire entre un contenu humainement lisible et un système automatisé. Si vous avez un site WordPress, Prestashop ou autre, leur intégration peut passer par des extensions que l’on voir un peu plus loins. Sur les sites plus techniques, on utilisera souvent des scripts JSON-LD personnalisés ou des frameworks spécialisés.
WordPress : L’automatisation et les limites des thèmes choisis
WordPress, en tant que système de gestion de contenu (CMS) basé sur des templates et un écosystème de thèmes et de plugins, vise naturellement à automatiser les tâches répétitives, notamment dans le domaine du référencement on-page. Cela inclut de plus en plus l’intégration automatique des données structurées au format Schema.org, essentielles pour améliorer la compréhension sémantique des contenus par les moteurs de recherche.
Des extensions comme Microdata WordPress, Yoast SEO, Rank Math ou Schema Pro permettent d’intégrer automatiquement un balisage JSON-LD ou Microdata selon les pages, les types de publications ou les taxonomies utilisées. Cependant, cette automatisation se heurte souvent aux limites imposées par le thème activé.
En effet, beaucoup de thèmes WordPress, y compris certains thèmes premium dits “SEO-friendly”, ne respectent pas les conventions de balisage attendues par les outils de validation comme le Rich Results Test de Google. Il est fréquent de constater :
- L’absence totale de données structurées dans le HTML généré ;
- Des balises
hentryouhatomutilisées de manière incorrecte ou incomplète ; - Des erreurs de déclaration dans les attributs
itemscope,itempropetitemtype; - Des conflits entre les balises injectées par le thème et celles générées par un plugin
Par exemple, certaines erreurs fréquentes dans les thèmes concernent l’attribution incorrecte des balises author ou updated (souvent liées à hCard ou hAtom), ce qui provoque des avertissements dans la Search Console ou le testeur de données structurées. Ces erreurs, même si elles ne provoquent pas de pénalité, peuvent empêcher vos contenus d’apparaître sous forme d’extraits enrichis dans les SERP.
Le recours à un plugin peut compenser ces manques, mais encore faut-il que le thème ne surcharge pas ou ne bloque pas le DOM (Document Object Model) d’injection. En cas de doute, il est recommandé :
- De désactiver temporairement le thème et tester avec un thème par défaut (comme Twenty Twenty-Four)
- De consulter le code source généré (
Ctrl+Udans votre navigateur) pour repérer l’injection correcte des balises - De valider le tout via les outils officiels de test de Google (ou ceux de Bing ou Yandex si pertinent)
Pour les intégrateurs et développeurs WordPress avancés, une autre option consiste à personnaliser le fichier functions.php ou à créer un plugin personnalisé pour injecter le JSON-LD uniquement là où il est pertinent (ex. : is_single(), is_product(), etc.).
Ainsi, si l’automatisation est une promesse séduisante du CMS WordPress, elle doit toujours être vérifiée manuellement et validée techniquement, surtout en matière de SEO sémantique. Un bon thème SEO n’est pas celui qui promet des balises, mais celui qui les implémente correctement et proprement.
Corriger les erreurs Microformats sur WordPress
De nombreux sites WordPress, y compris certains utilisant des thèmes premium ou populaires, rencontrent des problèmes de validation relatifs aux microformats hérités. Ces erreurs apparaissent fréquemment dans les rapports de la Google Search Console ou lors de tests via le Rich Results Test.
Les messages d’erreur types comme Missing: updated, Missing: author, ou encore Missing: entry-title sont liés à l’implémentation incomplète ou incorrecte des microformats hentry, hAtom et hCard, utilisés pour structurer les métadonnées autour d’un article ou d’un auteur dans le code HTML.
Pourquoi ces erreurs apparaissent-elles ?
Historiquement, ces microformats ont été intégrés à WordPress par défaut dès les premières versions du CMS pour structurer l’information (auteur, date, titre). Cependant, avec le temps et l’évolution des standards (notamment l’adoption de Schema.org et du format JSON-LD), ces balises ne sont plus maintenues par les équipes de WordPress, mais peuvent toujours subsister dans les templates de thèmes.
De nombreux développeurs de thèmes continuent à inclure ces microformats par habitude, sans pour autant les implémenter complètement, ce qui génère des avertissements ou des erreurs.
Comment corriger ces erreurs ?
Deux approches principales s’offrent à vous :
- Correction manuelle : si vous avez des compétences techniques, vous pouvez éditer les fichiers du thème tels que
single.php,content.php, ou encoretemplate-parts/content-single.php. Il s’agit ici de :- Retirer les
class="hentry"ouclass="author vcard"mal implémentées - Ajouter les balises manquantes avec les attributs nécessaires :
class="updated"pour la date de mise à jour,rel="author"pour le lien vers l’auteur, etc.
- Retirer les
- Correction automatisée via plugin : si le code n’est pas votre terrain de jeu favori, il existe une solution pratique sous la forme d’un plugin développé par Nicolas Petrovic. Ce plugin permet de corriger automatiquement les erreurs liées aux microformats
hAtomsur WordPress, y compris les plus courantes.
Le plugin est payant (environ 10 euros) mais il a fait ses preuves, même sur des versions récentes de WordPress. Son fonctionnement est minimaliste : une fois installé, il injecte les balises manquantes de manière conforme dans le flux HTML sans modifier le contenu existant du thème.
Conseil pour aller plus loin
Bien que Google tolère encore les microformats, il est vivement recommandé de migrer progressivement vers une structure basée sur Schema.org en JSON-LD. Ce format est recommandé par Google, plus souple, plus clair et beaucoup plus facilement maintenable ; Il s’agit donc d’un réel conseil SEO. Pour ce faire, vous pouvez :
- Utiliser des plugins comme Yoast SEO, Rank Math ou Schema Pro ;
- Intégrer un bloc
<script type="application/ld+json">personnalisé dans le<head>ou le pied de page ; - Supprimer les vieux fragments microformats redondants pour éviter les conflits dans le balisage.
Corriger les erreurs microformats dans WordPress est un passage obligé pour tout projet SEO sérieux. Cela permet d’éviter des confusions côté moteur, d’améliorer les chances d’éligibilité aux extraits enrichis (rich snippets), et d’assainir le code HTML pour une maintenance future plus sereine.
Données structurées : Un levier SEO puissant !
La structuration des contenus via des données enrichies est devenue un levier stratégique pour améliorer la compréhension d’une page par Google et accroître sa visibilité via les SERP. Plus les données fournies au moteur sont claires, mieux votre contenu sera interprété. Bien sûr, il faut garder à l’esprit que l’on conçoit d’abord un site pour des utilisateurs humains. Mais les moteurs de recherche ont besoin d’une signalétique explicite. C’est là que les balises Schema.org prennent tout leur sens. Même si, pour l’internaute, ces balises sont invisibles, elles permettent à Google d’afficher des résultats enrichis (étoiles, horaires, événements, recettes, etc.) et de booster votre taux de clic.
Parmi les objectifs recherchés :
- Améliorer la visibilité du site dans les résultats (notamment dans les featured snippets ou le knowledge graph)
- Accélérer l’indexation en donnant des indications claires au crawler
- Optimiser les performances SEO globales, notamment pour les pages à forte concurrence
Exemples de données structurées utiles dans WordPress
Les données structurées permettent aux moteurs de recherche de mieux comprendre le contenu de vos pages, en fournissant des informations explicites via des balises JSON-LD ou Microdata. Voici quelques types de balisages largement utilisés dans l’univers WordPress (au-delà du fil d’Ariane largement évoqué dans notre article dédié) :
| Type de données structurées | Utilisation et exemples pratiques sur le Web |
|---|---|
| Organization | Représente une société ou un organisme. Exemple :"@type": "Organization", "name": "Facem Web", "url": "https://facemweb.com", "logo": "https://facemweb.com/logo.png"Très utile sur les pages d’accueil ou de présentation pour Google Business et Knowledge Panel. |
| Person | Utilisé pour valoriser un individu, souvent l’auteur d’un blog, un consultant ou un dirigeant. Exemple : "@type": "Person", "name": "David", "jobTitle": "Consultant SEO", "url": "https://facemweb.com/auteur/david"Permet d’associer une page auteur à une identité forte dans les SERP. |
| Website | Décrit le site Web globalement et son moteur de recherche interne (si présent). Exemple :"@type": "WebSite", "name": "Facem Web", "url": "https://facemweb.com"Peut inclure une fonction de recherche de site via potentialAction. |
| Breadcrumb | Décrit le fil d’Ariane. Exemple :"@type": "BreadcrumbList", "itemListElement": [{"@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://facemweb.com"}]Essentiel pour améliorer la navigation et l’affichage dans les SERP. |
| Event | Indispensable pour les sites qui organisent des conférences, événements en ligne ou séminaires. Exemple : "@type": "Event", "name": "Formation SEO 2025", "startDate": "2025-06-01", "location": "Arras"Affichage possible directement dans Google Agenda ou Maps. |
| Review / AggregateRating | Affiche des avis et évaluations produits ou services, utilisé en e-commerce. Exemple : "@type": "Product", "name": "Carport aluminium", "aggregateRating": {"@type": "AggregateRating", "ratingValue": "4.5", "reviewCount": "32"}Utile pour obtenir des étoiles dans les SERP. |
Ces balises peuvent être insérées manuellement dans le <head> ou dans le footer à l’aide de blocs JSON-LD, ou plus simplement via des extensions comme Rank Math, SEOPress ou Yoast SEO.
L’efficacité de ces données dépend de leur bonne intégration. Tous les thèmes WordPress ne gèrent pas correctement les balises Schema.org par défaut. Il peut donc être nécessaire d’adapter votre thème ou d’utiliser des hooks pour forcer l’injection des scripts.
Les microformats.org encore utiles ?
Les microformats sont des balises HTML enrichies utilisées historiquement pour décrire des informations structurées dans le contenu visible d’une page. Parmi les plus connus, on trouve h-card, h-entry, h-event ou encore h-review. Ces balises sont directement intégrées dans le HTML, à la différence des données structurées plus modernes comme JSON-LD qui sont séparées du contenu visuel.
Bien que toujours reconnus par Google (comme confirmé dans sa documentation développeur), les microformats sont aujourd’hui considérés comme obsolètes dans de nombreux contextes, notamment si vous décidez aujourd’hui de faire faire la création de votre site Internet, en raison de leur manque de souplesse, de leur lisibilité limitée et de l’absence de prise en charge de nombreux types de données disponibles dans Schema.org. Leur usage est ainsi en net recul depuis la généralisation du JSON-LD, recommandé par Google depuis 2015 pour la structuration des données.
Exemple classique de microformat h-card :
<p class="h-card">
<span class="p-name">Jean Dupont</span>
<a class="u-url" href="https://www.monsite.com">Mon site</a>
<span class="p-locality">Paris</span>
</p>
Ce type de balisage est encore fréquemment présent dans certains thèmes WordPress anciens, notamment dans les modèles de page auteur ou blog où les métadonnées de l’auteur (nom, site, localisation) sont intégrées. Toutefois, ces balises peuvent provoquer des erreurs de validation dans la Search Console lorsqu’elles sont mal implémentées ou incomplètes (ex. : absence de updated ou author pour hentry).
Comparaison avec les solutions modernes :
| Technologie | Avantages / Inconvénients |
|---|---|
Microformats (h-card, hentry) |
Avantages : simple à implémenter, fonctionne sans JavaScript Inconvénients : peu de flexibilité, obsolète pour les types complexes, lecture et validation parfois problématiques |
| Schema.org + JSON-LD | Avantages : format recommandé par Google, flexible, maintenable, compatible avec de nombreux types (ex. : job posting, events, local business) Inconvénients : nécessite parfois injection via plugin ou fichier <head>, non visible pour l’utilisateur |
En résumé, si vous partez sur un nouveau site ou que vous refondez votre thème WordPress, que vous décidez de faire un E-commerce par exemple, il est fortement recommandé d’adopter JSON-LD et les vocabulaires de schema.org. Ils offrent une meilleure compatibilité avec les moteurs de recherche, sont plus faciles à valider via l’outil Rich Results Test, et facilitent l’accès aux extraits enrichis dans les résultats Google (avis, événements, FAQ, produit, etc.).
Pour les développeurs WordPress ou les intégrateurs SEO, pensez à auditer vos templates et à remplacer les microformats désuets lorsqu’ils posent problème, ou à les compléter lorsque vous n’avez pas d’autre option (thème figé, site ancien, etc.).
0 commentaires