Données structurées : celles dont un site d'entreprise a vraiment besoin
Les données structurées ne sont pas un facteur de classement. Elles sont une traduction : elles disent aux machines ce que signifie un passage de texte au lieu de les laisser deviner. Et c'est précisément cela qui décide de plus en plus si une page apparaît dans les réponses.
L'essentiel en bref
- Quatre types suffisent à presque tout site d'entreprise : Organization, WebPage ou Article, BreadcrumbList et FAQPage.
- La livraison se fait en JSON-LD dans le
<head>– pas en balisage dans le corps du texte. - L'erreur la plus fréquente est silencieuse et coûteuse : des indications dans les données structurées qui ne figurent pas sur la page elle-même.
- Trois types très discutés peuvent être économisés par une entreprise de services – ils n'agissent qu'avec une offre adaptée ou de vrais avis.
Une machine qui lit une page ne voit d'abord que du texte. Que « Emma Woelk » soit une personne, « TEISENDA GmbH » une entreprise et « 22 août 2026 » une date de publication, elle doit le deviner – ou bien cela y figure expressément.
Les données structurées sont cette mention expresse. Elles n'améliorent aucun classement. Elles décident si une page peut seulement entrer en ligne de compte pour un affichage enrichi et pour des réponses générées.
Les quatre qui suffisent
1. Organization – une fois, sur la page d'accueil
Qui vous êtes : nom, adresse, logo, année de fondation, profils sur d'autres réseaux. C'est l'entrée qui permet à un logo d'apparaître à côté du résultat de recherche – et la raison la plus fréquente de son absence est tout simplement l'absence de cette entrée.
Important : le logo doit exister en image matricielle. Un SVG n'est pas exploité à cet endroit.
2. WebPage ou Article – sur chaque page
Ce qu'est cette page : titre, description, langue, date de publication et de dernière révision. Pour les articles, s'y ajoute Article ou BlogPosting avec l'auteur comme entrée Person distincte – avec son rôle, pas seulement son nom.
Important : la date de modification doit être exacte. Une date réécrite à chaque affichage est un signal qui s'annule lui-même.
3. BreadcrumbList – sur toutes les pages internes
Où se situe cette page dans la structure. Visible sous forme de fil d'Ariane en haut de page, lisible par la machine dans l'en-tête. Les deux vont ensemble – un chemin dans les données qui n'existe pas sur la page est une fausse indication.
4. FAQPage – là où il y a de vraies questions
La section de questions à la fin d'un article. Pour les moteurs de réponse, le type le plus précieux de tous, parce qu'il livre déjà question et réponse en couple – exactement la forme sous laquelle on cite.
Important : uniquement pour des questions réellement visibles sur la page. Des questions inventées qui ne figurent que dans les données constituent une infraction aux consignes.
Trois qu'on peut économiser
Product et Offer. Pour des services sur devis, ils n'apportent rien – sans prix ni disponibilité, ils ne sont de toute façon pas affichés. Pertinents seulement avec une vraie boutique.
AggregateRating. Les étoiles dans les résultats sont tentantes et soumises à des conditions strictes : les avis doivent être authentiques, vérifiables et visibles sur la page. Des avis auto-attribués sont une infraction aux consignes avec un risque réel.
HowTo. Son affichage a été nettement réduit et il ne justifie plus l'effort d'entretien pour la plupart des sites d'entreprise.
Le saviez-vous ?
Les données structurées ne sont pas un facteur de classement – Google l'a précisé à plusieurs reprises. Elles décident de l'affichage, pas de la position.
Pour les moteurs de réponse, la situation est un peu différente. Un modèle chargé de construire une réponse à partir d'une page utilise en priorité ce qui est balisé sans ambiguïté : couples question-réponse, auteur avec rôle, date de dernière vérification. Il n'a alors pas à deviner ce qui va ensemble. L'utilité tient donc moins au classement qu'à la citabilité.
Comment les intégrer
Trois règles qui évitent la plupart des problèmes.
- Du JSON-LD, dans le
<head>. Pas des attributs dans le corps du texte. Le JSON-LD s'entretient séparément de la mise en page et ne se perd pas lors des refontes graphiques. - Un bloc par page, pas cinq. Plusieurs entrées se rangent dans un
@graphet se relient par@id. L'article renvoie ainsi à la même organisation que la page d'accueil au lieu de la répéter. - Les produire depuis la même source que le contenu visible. Si titre, date et auteur viennent des mêmes champs que la page elle-même, ils ne peuvent pas diverger. C'est la prévention la plus efficace qui soit.
L'erreur la plus coûteuse est la plus discrète : les données structurées disent quelque chose qui ne figure pas sur la page. Une date de modification d'hier pour un texte de 2023. Un auteur qui n'apparaît pas dans la zone visible. Des questions dans les données qui n'existent pas sur la page.
Aucun outil de test ne le remarque – les données sont formellement valides. Cela se remarque lors d'un contrôle manuel, et la conséquence ne touche alors pas que le balisage concerné. C'est pourquoi la règle « produire depuis la même source » compte plus que toute exhaustivité.
Vérifier – dans cet ordre
| Étape | Avec quoi | Ce que vous voyez |
|---|---|---|
| 1. Syntaxe | validateur de balisage Schema | si le JSON est valide et le type correct |
| 2. Affichabilité | test des résultats enrichis | si un affichage enrichi serait possible |
| 3. Réalité | Search Console, section améliorations | ce qui a effectivement été reconnu, sur toutes les pages |
| 4. Concordance | lire soi-même | si chaque indication figure aussi visiblement sur la page |
L'étape quatre est la seule qu'aucun outil ne prend en charge – et la seule où les erreurs sérieuses se voient.
Vérifie les données structurées de cette page : exhaustivité et concordance avec le contenu visible. Contenu visible de la page : [coller le texte de la page] JSON-LD de la page : [coller le bloc] Tâches : 1. Nomme chaque indication du JSON-LD absente du contenu visible. C'est le point le plus important – sois minutieux ici. 2. Nomme chaque indication visible qui devrait être balisée mais manque (auteur avec rôle, date de modification, questions, fil d'Ariane). 3. Vérifie si les quatre types de base sont correctement remplis : Organization, WebPage/Article, BreadcrumbList, FAQPage. 4. Nomme les types du bloc qui n'apportent rien à une entreprise de services sans boutique et sans avis vérifiables. 5. Signale toute infraction aux consignes, en particulier des avis auto-attribués et des questions absentes de la page. Restitue à la fin le JSON-LD corrigé en entier. N'invente aucune valeur – marque ce qui manque par [à compléter].
Conclusion
Les données structurées sont vite surestimées et tout aussi vite mal faites. Quatre types couvrent les besoins d'un site d'entreprise, et leur utilité tient moins à la position qu'à la citabilité.
La règle qui porte tout : ne rien baliser qui ne figure pas sur la page. Produire les données depuis la même source que le contenu visible résout le problème structurellement – et dispense largement des contrôles ultérieurs.
Questions fréquentes
De quelles données structurées un site d'entreprise a-t-il besoin ?
Quatre types suffisent : Organization une fois sur la page d'accueil, WebPage ou Article sur chaque page, BreadcrumbList sur toutes les pages internes et FAQPage partout où il y a de vraies questions visibles. Product, AggregateRating et HowTo ne valent en général pas la peine pour une entreprise de services.
Les données structurées améliorent-elles le classement ?
Non. Elles ne sont pas un facteur de classement mais décident de l'affichage – par exemple de la possibilité qu'un logo, un fil d'Ariane ou des questions dépliables apparaissent dans les résultats. Pour les moteurs de réponse, elles augmentent la citabilité, puisque couples question-réponse, auteur et date sont balisés sans ambiguïté au lieu d'être devinés.
Pourquoi Google n'affiche-t-il pas notre logo ?
La raison la plus fréquente est une entrée Organization absente ou incomplète sur la page d'accueil. Deuxième raison la plus courante : le logo déposé n'existe qu'en SVG – à cet endroit, une image matricielle est nécessaire. Même correctement balisé, l'affichage n'est jamais garanti.
Quelle est l'erreur la plus fréquente ?
Des indications présentes dans les données mais absentes du contenu visible : une mauvaise date de modification, un auteur non nommé, des questions inventées. Les outils de test ne le signalent pas, puisque les données sont formellement valides. On l'évite en produisant le balisage depuis la même source que le texte visible.
JSON-LD ou microdonnées ?
Du JSON-LD dans le <head>. C'est la forme recommandée par Google, elle s'entretient séparément de la mise en page et ne se perd pas lors des refontes. Les microdonnées répartissent le balisage dans le corps du texte et cassent à chaque remaniement de la page.
Un marketing qui se met en place tout seul
La bêta du Studio Engine est ouverte. Réservez votre place et participez dès le départ.
Participer à la bêta →