Journal
Les données structurées décrivent une page aux moteurs dans un langage sans ambiguïté. Elles ne classent pas un site, mais elles le font comprendre, et parfois mieux afficher. Voici ce qu’elles sont, lesquelles choisir, et comment s’assurer qu’elles sont justes.
Une page web est écrite pour des yeux humains. Un moteur y lit des mots, et doit deviner que ce nombre est un téléphone, que cette ligne est une adresse, que ce nom est celui de l’entreprise et non celui d’un client. Les données structurées suppriment cette devinette : elles disent, dans un vocabulaire partagé, ce que la page contient. Cet article explique ce vocabulaire, les types qui servent à une entreprise, ce que Google en fait réellement, et les erreurs qui transforment un atout en problème.
Un vocabulaire partagé, schema.org, qui permet de décrire le contenu d’une page dans un format que les machines lisent sans ambiguïté : cette page parle d’une entreprise, située ici, joignable là, qui propose ces services. Google recommande le format JSON-LD, un bloc placé dans le code de la page, invisible pour le visiteur.
Le vocabulaire schema.org a été créé en 2011 par Google, Microsoft et Yahoo, rejoints ensuite par Yandex, pour que les sites décrivent leurs contenus de la même façon à tous les moteurs. Il définit des types, une entreprise, un article, un produit, une question, et pour chaque type des propriétés : un nom, une adresse, une date, un auteur. Il est maintenu publiquement et évolue chaque année.
Trois syntaxes permettent d’écrire ces descriptions. Google recommande JSON-LD : un bloc de texte structuré, placé dans le code de la page, séparé du contenu visible. Il est plus simple à générer, à relire et à vérifier que les deux autres, qui se glissent dans les balises du texte. Quelle que soit la syntaxe, la règle est la même : les données structurées décrivent ce qui est visible sur la page. Elles ne sont pas un endroit où dire aux moteurs ce que l’on ne dit pas aux visiteurs.
Une poignée suffit : Organization ou LocalBusiness pour l’entreprise, WebSite et WebPage pour le site et ses pages, Service pour chaque prestation, BreadcrumbList pour le fil d’Ariane, Article ou BlogPosting pour les articles, FAQPage pour les questions réellement affichées. L’important est de les relier entre eux.
Le vocabulaire compte des centaines de types ; une entreprise de services en utilise moins de dix. Chacun décrit une entité, et les entités se relient : la page appartient au site, le site est édité par l’entreprise, l’article est écrit par elle, le service est fourni par elle. Ces liens se font par des identifiants stables, ce qui donne aux moteurs un graphe cohérent plutôt qu’une suite de déclarations isolées.
Parfois un résultat enrichi : un fil d’Ariane lisible, des dates d’article, une fiche d’entreprise mieux renseignée, une image à côté du lien. Google documente une trentaine de fonctionnalités, jamais garanties. Les questions FAQ ne s’affichent plus que pour les sites gouvernementaux et de santé depuis août 2023, et les pas-à-pas HowTo ont disparu en septembre 2023.
Google tient une liste publique des fonctionnalités de résultats qu’il peut afficher à partir de données structurées : fil d’Ariane, article, entreprise locale, produit, événement, recette, offre d’emploi, et d’autres. Chacune a ses propriétés obligatoires et ses règles. Google précise à chaque fois que le balisage rend la page éligible, sans garantir l’affichage : ses systèmes décident selon la requête, l’appareil et la qualité de la page.
La liste évolue, et pas toujours dans le sens de l’ajout. En août 2023, Google a restreint le résultat enrichi FAQ à des sites gouvernementaux et de santé reconnus, puis a retiré HowTo. Le gain le plus durable des données structurées n’est donc pas l’affichage, qui va et vient, mais la compréhension : un moteur qui sait sans hésiter qui vous êtes, où vous êtes et ce que vous faites vous affiche sur les bonnes requêtes.
Pas directement : Google indique qu’elles ne sont pas un facteur de classement. Elles aident à comprendre la page, ce qui peut la faire apparaître sur des requêtes mieux ciblées et avec un affichage plus riche. Mal utilisées, elles nuisent : les avis sur soi-même sont interdits depuis 2019, et un balisage trompeur peut entraîner une action manuelle.
Ajouter des données structurées à une page ne la fait pas monter. Ce qu’elles changent, c’est la précision avec laquelle le moteur relie la page à des requêtes, et la forme du résultat affiché. Un fil d’Ariane et une date rendent un résultat plus lisible, donc plus cliqué ; une fiche d’entreprise complète nourrit les résultats locaux. Ce sont des effets indirects, réels mais modestes, qui s’ajoutent à un contenu qui fait déjà son travail.
L’inverse est plus net. Google interdit depuis 2019 le balisage d’avis qu’une entreprise publie sur elle-même, sur son propre site : il ne produit plus d’étoiles et peut être sanctionné. Il en va de même des questions FAQ dupliquées sur toutes les pages, des notes inventées, des contenus balisés mais absents de la page. Ces pratiques valent une action manuelle, c’est-à-dire une pénalité appliquée par une personne de Google, visible dans la Search Console et longue à lever.
Avec le test des résultats enrichis de Google, qui dit ce que Google reconnaît sur une adresse, et avec le validateur de schema.org, qui vérifie la syntaxe et le vocabulaire. Puis, dans la Search Console, la section des améliorations liste les erreurs détectées sur l’ensemble du site, page par page.
Les deux outils se complètent. Le test des résultats enrichis ne signale que les types que Google utilise pour ses fonctionnalités, avec leurs erreurs et avertissements ; le validateur de schema.org relit tout le balisage, y compris les types que Google n’affiche pas, et détecte les propriétés inconnues. Une page qui passe les deux est correcte.
La vérification ne s’arrête pas à la mise en ligne. La Search Console surveille en continu les données structurées qu’elle rencontre et signale, dans ses rapports d’améliorations, les pages où une propriété obligatoire manque ou où une valeur est invalide. Une relecture trimestrielle de ces rapports, et un test après chaque modification de gabarit, suffisent à garder un balisage juste. Le vrai contrôle reste de comparer, de temps en temps, ce que dit le balisage et ce que dit la page.
Un socle commun sur chaque page : l’entreprise, le site, la page, le fil d’Ariane. Puis, selon le rôle de la page, un type spécifique : Service sur une page de prestation, BlogPosting sur un article, FAQPage si des questions y sont affichées. Rien de plus.
JSON-LD, que Google recommande. Il se place dans un bloc séparé du contenu, se génère facilement à partir des données de la page, se relit sans effort et n’oblige pas à modifier le texte visible. Les deux autres syntaxes restent valides mais sont plus lourdes à maintenir.
Pour le socle, souvent oui : entreprise, site, fil d’Ariane, article. Il faut vérifier ce qu’elle produit avec le test des résultats enrichis, compléter les informations qu’elle ne connaît pas, comme les identifiants légaux ou la zone desservie, et s’assurer qu’elle ne balise pas des avis ou des questions absents de la page.
Non. Depuis 2019, Google n’affiche plus les notes issues d’un balisage posé par une entreprise sur elle-même, et considère cette pratique comme intéressée. Les avis se recueillent sur des plateformes tierces, et le site peut y renvoyer.
· Référencement (SEO)
Les boîtes de questions de Google occupent une place que la première position elle-même n’a pas. Aucune balise ne permet d’y entrer ; une manière d’écrire, si. Voici ce que Google affiche, comment il choisit, et comment rédiger pour être repris.
· Référencement (SEO)
Un site qui ne progresse plus n’a pas besoin de plus de pages, mais de savoir ce que valent celles qu’il a. L’audit de contenu répond à cette question avec des données, page par page, et se termine par une liste d’actions.
· Référencement (SEO)
Être trouvé par les gens qui cherchent à deux rues de chez vous ne dépend ni de la chance ni d’un budget publicitaire. Cela dépend de quelques signaux précis, que l’on peut travailler dans l’ordre.
Toutes les questions auxquelles le journal répond, chacune avec sa réponse directe : la page des questions.
Et maintenant
Un premier échange suffit pour savoir si un projet de référencement naturel a du sens pour vous, et ce qu’il demanderait.
05 Comment les écrire correctement ?
En décrivant ce qui est visible sur la page, rien de plus ; en donnant à chaque entité un identifiant stable pour la relier aux autres ; en respectant les propriétés que la documentation de Google déclare obligatoires ; en générant le balisage à partir des mêmes données que la page, pour qu’ils ne divergent jamais ; et en le mettant à jour quand la page change.
La cause la plus fréquente d’erreur n’est pas la syntaxe, ce sont les données qui vieillissent. Un numéro de téléphone changé sur la page mais pas dans le balisage, un article modifié dont la date structurée reste celle de la première publication, un service retiré qui subsiste dans le catalogue. Le remède est de ne jamais écrire le balisage à la main : il doit être produit à partir de la même source que le contenu affiché, de sorte qu’une modification se répercute partout.