Données structurées schema.org pour une entreprise locale : ce qu'il faut baliser, et comment

Ce que les données structurées font, et ne font pas

Elles aident les moteurs à comprendre une page sans ambiguïté — cette adresse est celle de l’entreprise, ces horaires sont les siens, cette question et cette réponse forment une foire aux questions — et elles permettent des affichages enrichis dans les résultats : questions dépliables, fil d’Ariane, étoiles d’avis sous conditions. Elles alimentent aussi les moteurs génératifs, qui y lisent l’entité. Elles ne font pas classer une page qui n’a pas de contenu, et elles ne doivent jamais décrire ce que la page ne montre pas : Google sanctionne les données structurées trompeuses.

LocalBusiness : l’entreprise elle-même

Le type LocalBusiness — ou un sous-type précis quand il existe : Plumber, Dentist, Restaurant, LegalService, Electrician — décrit l’entreprise : nom, adresse complète, coordonnées géographiques, téléphone si vous l’affichez, horaires d’ouverture, zone desservie, image, identifiant unique, liens vers les profils. Il est placé sur toutes les pages, une seule fois, avec des valeurs strictement identiques à la fiche Google et aux mentions du site. Ce site utilise ProfessionalService, avec l’adresse du 6e, les horaires et la zone de vingt kilomètres.

Service : chaque prestation

Sur chaque page de service, un type Service décrit la prestation — nom, description, fournisseur qui renvoie à l’entreprise, zone desservie, type de service —, relié à l’entité LocalBusiness par son identifiant. Cela dit à Google que cette page est l’offre de cette entreprise pour cette prestation. Les prix ne sont ajoutés que s’ils sont affichés sur la page ; une offre chiffrée dans le code et absente de la page est une donnée trompeuse.

FAQPage : les questions-réponses

Sur une page qui contient une foire aux questions visible, le type FAQPage liste chaque question et sa réponse, texte pour texte. Google l’affiche parfois en questions dépliables sous le résultat, et les moteurs génératifs y puisent des réponses directes. Deux règles : les questions et réponses balisées doivent être exactement celles affichées, et une FAQPage ne se met pas sur une page qui n’a pas de foire aux questions visible. Chaque page de ce site qui a une section de questions porte ce balisage.

BreadcrumbList : le fil d’Ariane

Le type BreadcrumbList décrit le chemin de la page — accueil, section, page — et permet à Google d’afficher ce chemin à la place de l’adresse dans les résultats. Il doit correspondre au fil d’Ariane visible sur la page, dans le même ordre, avec les mêmes noms. C’est le balisage le plus simple et l’un des plus utiles pour la lisibilité des résultats.

Article et Person : le blog et l’auteur

Chaque article porte un type Article avec son titre, sa description, ses dates de publication et de mise à jour, son auteur — un type Person qui décrit la personne, relié à l’entreprise — et son image. C’est ce qui permet aux moteurs de dater le contenu et de l’attribuer à un auteur identifié, un signal d’expérience et d’expertise que Google et les IA utilisent. Les articles de ce site sont attribués à Nathan Levy avec sa page, son rôle et son image.

Review et AggregateRating : seulement avec de vrais avis

Les types Review et AggregateRating décrivent des avis et une note moyenne ; ils peuvent afficher des étoiles dans les résultats. Google les encadre strictement : les avis doivent être réels, publiés sur la page, non rédigés par l’entreprise, et une entreprise ne peut pas baliser ses propres avis Google pour obtenir des étoiles sur sa fiche. Un balisage d’avis inventés ou copiés est une donnée trompeuse, sanctionnée. Ce site n’utilise pas ces types tant qu’il n’affiche pas d’avis réels avec leur source — c’est écrit sur sa page d’avis clients.

Les erreurs qui invalident ou trompent

Une adresse dans le code différente de celle de la page. Des horaires périmés dans le code. Une FAQPage sur une page sans foire aux questions visible. Des étoiles balisées sans avis réel sur la page. Un type Product sur une page de service. Deux blocs LocalBusiness contradictoires sur la même page. Une erreur de virgule qui invalide tout. Un identifiant d’entité différent d’une page à l’autre, qui empêche de relier le service à l’entreprise. Chacune se détecte avec l’outil de test, et chacune coûte soit l’affichage enrichi, soit la confiance de Google.

Écrire, valider, maintenir

Le JSON-LD s’écrit dans une balise de script dans l’en-tête de la page — un objet par type, ou un graphe qui relie les entités par leurs identifiants. Il se valide avec l’outil de test des résultats enrichis de Google et le validateur de schema.org ; une seule erreur de syntaxe invalide tout le bloc. Il se maintient : un horaire qui change, une adresse, un service ajouté doivent être mis à jour dans le code comme sur la page. Sur ce site, les données sont générées depuis la même source que les pages, ce qui garantit la cohérence.