Données structurées pour thérapeutes : baliser ce qui existe vraiment

Schema.org ne rend pas une page plus crédible par magie. Le balisage traduit sous une forme standard des informations déjà exactes et visibles : auteur, établissement, adresse, article ou fil d’Ariane.

Les données structurées sont des informations ajoutées au code d’une page pour aider les machines à en identifier certains éléments. Google peut les utiliser pour comprendre la page et, pour des types pris en charge, rendre celle-ci éligible à des résultats enrichis.

Deux limites doivent être posées immédiatement :

• un balisage valide ne garantit aucun affichage enrichi ;
• les données structurées ne compensent pas un contenu vague, une activité non vérifiable ou une page non indexée.

Sur Squarespace, une partie du balisage peut déjà être générée par la plateforme. La première étape n’est donc pas d’ajouter un nouveau bloc, mais de vérifier ce qui existe.

JSON-LD, Schema.org et résultats enrichis : trois notions différentes

Schema.org est un vocabulaire partagé qui décrit des entités et leurs propriétés : une personne, une organisation, un article ou un établissement local.

JSON-LD est une manière d’écrire ces informations dans le code. Google le recommande pour les données structurées, même s’il prend aussi en charge Microdata et RDFa.

Un résultat enrichi est une présentation particulière dans les résultats Google. Seuls certains types et propriétés y sont éligibles selon la documentation de Google. Un type Schema.org peut être valide sans produire de fonctionnalité visible dans Google.

Cette distinction évite une erreur fréquente : ajouter beaucoup de types parce qu’ils existent dans Schema.org et promettre ensuite une amélioration de position ou une présence dans les réponses d’IA.

Choisir le type en fonction de la page

Page d’accueil : Organization ou LocalBusiness

Organization décrit l’organisation : nom, URL, logo, coordonnées et profils officiels lorsque ces informations existent.

LocalBusiness convient à une activité disposant d’un établissement physique répondant aux critères applicables. Il peut inclure l’adresse, le téléphone et les horaires.

Le choix dépend de la réalité. Un professionnel exerçant uniquement à distance ne doit pas inventer une adresse publique pour utiliser LocalBusiness. Un cabinet avec plusieurs lieux peut nécessiter une entité par établissement et des pages clairement associées.

Utilisez le sous-type le plus précis uniquement s’il correspond au statut réel. Physician ne désigne pas automatiquement tout thérapeute. MedicalClinic ne convient pas à un espace qui n’est pas une clinique médicale.

Page de présentation : Person

Person peut décrire le professionnel présenté : nom, fonction, URL de la page, image réelle, organisation et profils officiels. Les propriétés doivent reprendre ce qui est visible et vérifiable.

N’ajoutez pas des diplômes, titres ou affiliations qui n’apparaissent pas sur la page. Le balisage ne doit pas devenir un CV caché plus flatteur que le contenu.

Article : Article ou BlogPosting

Pour un article, BlogPosting est un sous-type approprié de Article. Les propriétés recommandées incluent notamment le titre, l’auteur, la date et l’image lorsqu’une image pertinente et accessible existe.

Le nom de l’auteur doit correspondre à la signature visible. Une date de mise à jour ne doit être changée que lorsque le contenu a réellement été révisé.

Navigation : BreadcrumbList

Un fil d’Ariane peut être balisé avec BreadcrumbList lorsqu’il correspond à une navigation réelle et logique. Il aide à décrire la position de la page dans le site.

Ne créez pas un fil d’Ariane fictif uniquement dans le code. Les consignes de Google demandent que le balisage représente le contenu visible et pertinent.

FAQPage : ne plus le traiter comme une fonctionnalité Google

Le type FAQPage existe toujours dans le vocabulaire Schema.org et peut décrire une véritable foire aux questions. Google a cependant retiré son résultat enrichi FAQ de la recherche à partir du 7 mai 2026, puis supprimé la documentation correspondante. Pour un site de cabinet ou d’agence, une FAQ doit donc être créée pour aider le lecteur. Il n’y a plus de résultat enrichi Google à obtenir avec ce balisage.

Vérifier ce que Squarespace produit déjà

Avant d’ajouter du JSON-LD :

1. testez l’URL dans le Rich Results Test ;
2. consultez le code rendu si nécessaire ;
3. identifiez les entités déjà présentes ;
4. vérifiez les erreurs et les propriétés inexactes ;
5. n’ajoutez que ce qui manque et peut être maintenu.

Deux blocs décrivant la même organisation avec des noms, URL ou adresses différents créent davantage d’ambiguïté. La duplication n’est pas automatiquement interdite, mais les entités devraient être reliées par des identifiants cohérents ou regroupées lorsqu’elles décrivent la même chose.

Sur un site simple, quelques blocs exacts valent mieux qu’un graphe complexe impossible à maintenir.

Exemple de balisage pour un article

L’exemple suivant contient des champs génériques. Il doit être adapté à la page réelle ; ne le copiez pas avec les valeurs entre crochets.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "[Titre exact de l’article]",
  "description": "[Description fidèle au contenu]",
  "datePublished": "[AAAA-MM-JJ]",
  "dateModified": "[AAAA-MM-JJ]",
  "author": {
    "@type": "Person",
    "name": "[Nom réel de l’auteur]",
    "url": "[URL de sa page de présentation]"
  },
  "publisher": {
    "@type": "Organization",
    "name": "[Nom de l’organisation]",
    "url": "[URL canonique du site]"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "[URL canonique de l’article]"
  }
}
</script>

Ajoutez image uniquement avec l’URL d’une image pertinente, indexable et réellement présente sur la page. N’inventez pas de logo ou de portrait pour remplir une propriété recommandée.

Exemple minimal pour un établissement local

Ce modèle montre la logique, sans supposer le statut professionnel. Choisissez ensuite le sous-type exact qui correspond à l’activité.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://www.exemple.ch/#etablissement-neuchatel",
  "name": "[Nom public exact]",
  "url": "https://www.exemple.ch/neuchatel",
  "telephone": "[Téléphone public]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "[Rue et numéro]",
    "postalCode": "[Code postal]",
    "addressLocality": "[Localité]",
    "addressCountry": "CH"
  }
}
</script>

N’ajoutez les horaires qu’après avoir vérifié le format attendu et leur stabilité. Pour plusieurs lieux, créez des identifiants distincts et associez chaque entité à sa véritable page locale.

Notre guide sur les pages locales pour thérapeutes explique quelles informations visibles doivent accompagner ce balisage.

Utiliser des identifiants stables

La propriété @id peut servir d’identifiant pour relier plusieurs descriptions de la même entité. Une organisation pourrait utiliser :

https://www.exemple.ch/#organisation

Un établissement :

https://www.exemple.ch/#cabinet-neuchatel

Et une personne :

https://www.exemple.ch/a-propos#personne

L’@id n’a pas besoin d’être une page distincte. Il doit surtout rester stable et unique. Si plusieurs blocs utilisent des identifiants différents pour la même organisation, ils ne se relient pas automatiquement.

Ce que le balisage ne doit jamais inventer

• une note moyenne calculée à partir d’avis non visibles ;
• des avis écrits par l’entreprise sur elle-même ;
• une adresse de cabinet inexistante ;
• des horaires non publiés ;
• une spécialité ou un titre professionnel inexact ;
• un auteur absent du contenu ;
• une date de mise à jour automatique sans révision ;
• une FAQ cachée ;
• un prix qui ne correspond pas à la page ;
• une image sans rapport avec le contenu.

Google exige que les données structurées représentent le contenu principal visible et ne soient ni trompeuses ni hors sujet.

Données structurées et visibilité dans les réponses d’IA

Le balisage standardisé peut faciliter l’interprétation d’une entité, mais aucune documentation ne permet de promettre qu’un bloc JSON-LD fera citer une page par un assistant ou une fonctionnalité de recherche générative.

Google indique que les pratiques fondamentales du SEO restent valables pour ses fonctions d’IA : contenu utile, page indexable, liens explorables, expérience correcte et informations fiables. Il n’existe pas de balisage spécial obligatoire pour apparaître dans AI Overviews ou AI Mode.

Présentez donc les données structurées comme une couche de clarté technique, non comme une technique autonome de « référencement IA ».

Tester en deux étapes

1. Rich Results Test

Le test de Google indique les fonctionnalités enrichies détectées et les erreurs liées aux types qu’il prend en charge. Une absence de résultat enrichi ne signifie pas forcément que tout le vocabulaire Schema.org est invalide.

2. Schema Markup Validator

Le validateur Schema.org contrôle plus largement le vocabulaire et la syntaxe. Il peut reconnaître des types que Google n’utilise pas pour un résultat enrichi.

Après la mise en ligne, inspectez l’URL dans Search Console. Testez toujours la page publiée, pas uniquement un extrait de code isolé, car le CMS peut ajouter ou modifier son propre balisage.

Erreurs fréquentes sur Squarespace

• ajouter un deuxième balisage Article alors que la collection en produit déjà un ;
• coller le même LocalBusiness sur toutes les pages avec des adresses différentes ;
• laisser les données d’exemple dans le code ;
• ajouter un H1 ou du contenu uniquement pour « correspondre au schéma » ;
• oublier de mettre à jour le JSON-LD après un déménagement ;
• utiliser une virgule finale ou des guillemets typographiques qui cassent le JSON ;
• confondre validation technique et garantie de résultat enrichi.

Conservez un document indiquant où le balisage a été ajouté. Lorsqu’un site est repris plusieurs années plus tard, cette trace évite de chercher des blocs dispersés dans chaque page.

Checklist de mise en ligne

1. Le type correspond-il à l’entité réelle ?
2. Les informations apparaissent-elles aussi sur la page ?
3. Les URL utilisent-elles le domaine canonique ?
4. L’auteur et les dates sont-ils exacts ?
5. L’image est-elle pertinente et accessible ?
6. Le CMS produit-il déjà un bloc similaire ?
7. Les identifiants @id sont-ils stables ?
8. Le JSON est-il valide ?
9. La page passe-t-elle les tests appropriés ?
10. Une personne sait-elle comment mettre le balisage à jour ?

Questions fréquentes

Les données structurées améliorent-elles directement le classement ?

Google les utilise pour comprendre les pages et déterminer leur éligibilité à certains affichages enrichis. Il ne garantit ni affichage ni amélioration de position après leur ajout.

Faut-il ajouter du JSON-LD sur toutes les pages ?

Non. Ajoutez les types pertinents là où ils décrivent réellement la page. Un balisage plus abondant n’est pas forcément plus utile.

Peut-on ajouter le code dans un bloc Squarespace ?

Oui, un bloc Code peut accueillir un script application/ld+json. Vérifiez néanmoins le balisage déjà généré, le fonctionnement de votre version Squarespace et la page publiée avec les outils de test.