C'est quoi, une donnée structurée ?
Votre page dit « Boulangerie Martin, au coeur de Lyon depuis 1987 ». Un humain comprend tout. Une machine, elle, doit deviner : Martin est-il un nom de personne ou d'entreprise ? 1987 est-elle une date de création ou une adresse ? Les données structurées suppriment la devinette : c'est un bloc de code au format JSON-LD, posé dans le <head> de la page, qui déclare les mêmes informations dans le vocabulaire normalisé de schema.org, celui que Google, Bing et les IA lisent nativement.
C'est la deuxième des 4 conditions GEO : être compréhensible. Un site sans données structurées peut être bien classé, mais il laisse les machines interpréter, et les machines interprètent mal.
Est-ce que ça fait monter dans Google ?
Non, et c'est important de le dire avant de vous faire perdre un après-midi. Les données structurées ne sont pas un facteur de classement : poser un bloc JSON-LD ne vous fera pas passer de la page 3 à la page 1. Google le répète depuis des années, et quiconque vous vend l'inverse vend autre chose.
Ce qu'elles changent est ailleurs, et vaut quand même le quart d'heure de travail. Elles rendent votre page éligible à des affichages enrichis qu'elle n'aurait sinon jamais : la fiche d'établissement, l'étoile d'un avis, le fil d'Ariane sous votre lien, l'encart d'un article. Elles rendent surtout votre entreprise identifiable comme entité, pas seulement comme suite de mots. C'est ce second effet qui pèse le plus lourd aujourd'hui : un moteur de réponse qui doit citer un artisan à Nantes préfère celui dont il connaît le nom exact, l'adresse et le métier, à celui qu'il doit deviner à partir d'un texte de présentation.
Les 5 schémas utiles à une TPE-PME
| Type | Ce qu'il déclare | Où le poser |
|---|---|---|
Organization / LocalBusiness | Nom, activité, adresse, horaires, réseaux sociaux | Page d'accueil |
WebSite | Le nom du site et son URL canonique | Page d'accueil |
FAQPage | Vos questions-réponses, prêtes à citer | Pages avec une FAQ |
Article / BlogPosting | Titre, auteur, dates de publication | Chaque article de blog |
Person | Le dirigeant ou les experts, leur rôle | Page équipe ou à propos |
Utilisez LocalBusiness plutôt qu'Organization si vous avez une adresse physique où l'on vous rend visite : c'est ce qui alimente votre présence dans les recherches locales. Les autres types (Product, Event, Recipe...) ne servent que si votre activité les justifie.
Un exemple complet à adapter
Le bloc ci-dessous combine Organization et FAQPage pour une entreprise de services. Remplacez les valeurs, collez-le dans le <head> de votre page d'accueil :
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"@id": "https://votresite.fr/#org",
"name": "Durand Rénovation",
"description": "Entreprise de rénovation intérieure pour particuliers, Nantes et agglomération.",
"url": "https://votresite.fr/",
"telephone": "+33 2 40 00 00 00",
"address": {
"@type": "PostalAddress",
"streetAddress": "12 rue des Artisans",
"addressLocality": "Nantes",
"postalCode": "44000",
"addressCountry": "FR"
},
"areaServed": "Nantes et agglomération",
"sameAs": ["https://www.linkedin.com/company/durand-renovation"]
},
{
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Quels sont vos délais d'intervention ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Un devis sous 48 h, un début de chantier sous 3 semaines en moyenne."
}
}]
}
]
}
</script>Comment relier vos blocs entre eux ?
C'est le détail qui sépare un balisage bricolé d'un balisage qui tient. Dans l'exemple ci-dessus, l'entreprise porte un identifiant : "@id": "https://votresite.fr/#org". Cet identifiant est une adresse interne, il ne correspond à aucune page réelle et n'a pas besoin d'exister sur le web.
Son intérêt : sur vos autres pages, vous n'avez plus à redéclarer l'entreprise en entier. Un article de blog peut se contenter de "publisher": { "@id": "https://votresite.fr/#org" } et le moteur sait de qui il parle. Sans cet identifiant, chaque page déclare une entreprise du même nom sans jamais dire que c'est la même, et vous obtenez dix entités floues au lieu d'une entité nette. C'est exactement ce que vous ne voulez pas quand l'enjeu est d'être reconnu comme une entreprise identifiée.
Deux règles suffisent : l'entité complète n'est déclarée qu'une fois, sur la page d'accueil, et le même identifiant est réutilisé partout ailleurs, à l'octet près. Une majuscule de différence crée une deuxième entité.
Quelles propriétés sont vraiment obligatoires ?
Beaucoup d'audits confondent deux notions que Google distingue soigneusement, et vous font corriger dans l'urgence ce qui n'est qu'une suggestion.
- Les propriétés requises conditionnent l'éligibilité. Leur absence produit une erreur dans le test de résultats enrichis, et l'affichage enrichi est perdu. Exemple : une
FAQPagesansacceptedAnswer, ou une fiche locale sansnameniaddress. - Les propriétés recommandées améliorent le rendu sans être exigées. Leur absence produit un avertissement. Pour un article,
image,author,datePublishedetdateModifiedsont dans cette catégorie : les omettre ne casse rien, mais prive l'article de sa vignette et de son signal de fraîcheur.
La règle pratique : traitez les erreurs le jour même, les avertissements à la prochaine révision. Et méfiez-vous du réflexe inverse, plus coûteux : ajouter une propriété avec une valeur inventée pour faire taire un avertissement. Une image déclarée qui renvoie une erreur 404 est bien pire que pas d'image du tout, parce qu'elle transforme un avertissement bénin en erreur véritable.
Les erreurs qui invalident tout
- Un JSON invalide. Une virgule en trop et le bloc entier est ignoré, sans message d'erreur visible. Validez toujours après modification.
- Déclarer ce qui n'est pas sur la page. Une FAQPage dont les questions n'apparaissent pas dans le contenu visible est considérée comme trompeuse par Google. Le schéma décrit la page, il ne la remplace pas.
- Les incohérences entre pages. Deux adresses différentes dans deux blocs, un nom qui change selon les pages : chaque contradiction affaiblit la confiance des machines dans vos données.
- Le bloc injecté par JavaScript. Certains modules de CMS ajoutent le JSON-LD après le chargement de la page. Google finit souvent par le voir, mais les robots des IA n'exécutent pas de JavaScript : pour eux, votre balisage n'existe pas. Le bloc doit être dans le code source servi par le serveur, celui que vous voyez avec « afficher le code source de la page ».
Comment vérifier que ça marche ?
Deux outils : le test de résultats enrichis de Google pour une page précise, et notre audit qui vérifie automatiquement la présence, la validité et la cohérence de vos données structurées sur les pages clés, parmi 160 vérifications mesurées. Complément naturel : le fichier llms.txt, qui résume votre activité pour les IA au même endroit.