Données structurées WordPress : vérifier le balisage d’un site média

Les données structurées décrivent le contenu d’une page dans un format que les moteurs peuvent interpréter. Sur un site média WordPress, elles peuvent préciser qu’une page est un article, qui l’a rédigé et à quelle date elle a été publiée. Elles ne remplacent ni une structure Hn claire ni un contenu utile, et leur présence ne garantit pas l’affichage d’un résultat enrichi. L’enjeu éditorial consiste surtout à fournir des informations exactes, cohérentes et maintenues dans le temps.

Le type de balisage dépend de la nature réelle de la page. Un article d’actualité peut relever de NewsArticle, tandis qu’un dossier pratique ou un billet de fond correspond généralement à Article ou BlogPosting. Une page d’accueil peut plutôt être décrite avec des données relatives au site ou à l’organisation, et un fil d’Ariane avec BreadcrumbList. Il ne s’agit pas de sélectionner le type qui semble le plus avantageux, mais celui qui représente fidèlement le contenu présenté au lecteur.

Dans WordPress, le balisage peut être ajouté par le thème, une extension SEO ou un outil dédié. Avant d’installer une nouvelle extension ou d’ajouter du code, vérifiez ce que le site publie déjà : deux sources peuvent produire des blocs de données structurées redondants ou contradictoires. Une extension peut, par exemple, déclarer un auteur tandis que le thème en indique un autre, ou générer une date différente de celle affichée sur la page. Ce contrôle est particulièrement utile après une refonte, un changement de thème ou l’ajout d’un nouvel outil éditorial.

Les champs déclarés doivent correspondre aux éléments visibles et fiables de la page. Le titre balisé doit refléter le titre éditorial, l’image doit être pertinente et accessible, et les informations d’auteur ne doivent pas désigner une personne qui n’a pas contribué au contenu. Vérifiez aussi les dates de publication et de mise à jour : une date modifiée dans le balisage sans changement réel de l’article donne une indication trompeuse. Si une donnée n’existe pas ou ne peut pas être vérifiée, mieux vaut ne pas la renseigner que de la déduire automatiquement.

Un contrôle technique se déroule en deux temps. Un outil de test des résultats enrichis permet de repérer les erreurs et les champs attendus pour les fonctionnalités prises en charge par Google ; un validateur Schema.org aide à examiner plus largement la syntaxe et les types employés. Une alerte n’a pas toujours la même portée qu’une erreur bloquante : certaines propriétés sont recommandées, sans être obligatoires. Après correction, inspectez plusieurs modèles de pages, car un article, une page d’auteur et une archive de catégorie ne reposent pas nécessairement sur le même balisage.

Pour garder des données structurées fiables, intégrez leur vérification au processus de publication et aux changements techniques du site. Un contrôle ponctuel des principaux modèles WordPress, complété par une vérification après chaque modification de thème ou d’extension, aide à détecter les incohérences avant qu’elles ne se répètent sur des centaines d’URL. Consignez les types utilisés et l’outil qui les génère : cette information évite les ajouts en double lorsque l’équipe évolue. Le balisage reste ainsi un reflet technique du contenu éditorial, plutôt qu’une couche indépendante de la page.