Données structurées JSON-LD pour un cabinet

Les données structurées sont des informations écrites pour les machines : le nom de votre cabinet, son adresse, ses horaires, ses praticiens. Leur usage a changé en 2026, car Google a retiré l’affichage enrichi des FAQ. Ce tutoriel indique ce qui a encore un intérêt, avec un exemple de JSON-LD prêt à adapter pour un cabinet ou une clinique.

À retenir

Google a cessé d’afficher les résultats enrichis FAQ à partir du 7 mai 2026, et a supprimé la documentation correspondante le 15 juin 2026.
Le format recommandé est le JSON-LD, et le balisage doit décrire ce qui est visible sur la page.
Pour un cabinet, le type LocalBusiness et ses sous-types, dont MedicalClinic et Physician côté schema.org, restent la base.
Testez avec le Rich Results Test (Google) et le Schema Markup Validator (schema.org).

Ce que Google supporte encore en 2026

Le journal des mises à jour de Google Search Central est clair sur les FAQ. Le 8 mai 2026, Google a ajouté un avis de dépréciation : la fonctionnalité n’apparaîtrait plus dans la recherche à partir du 7 mai 2026. Le 15 juin 2026, la documentation a été supprimée, avec la mention que la fonctionnalité n’est plus affichée. La galerie actuelle des données structurées ne contient ni FAQ ni HowTo, tandis que Local business, Organization et Breadcrumb y figurent toujours.

Sources : Google Search Central, galerie des données structurées et journal des mises à jour (FAQ : entrées des 8 mai et 15 juin 2026).

Conséquence pratique : ne passez pas de temps à baliser une FAQ en espérant un affichage enrichi. Gardez en revanche vos questions fréquentes sur la page, en texte, car elles servent aux patients. Ce choix rejoint ce que nous disons dans notre article sur les réponses générées par l’IA : le texte visible est ce qui compte d’abord.

Les types schema.org pour un cabinet

Type	Usage	Remarque
MedicalClinic	Clinique, centre, structure de soins	Sous-type de LocalBusiness et de MedicalOrganization. Propriétés utiles : medicalSpecialty, availableService, isAcceptingNewPatients.
Physician	Un médecin ou son cabinet	Défini par schema.org comme « un médecin ou le cabinet d’un médecin » ; sous-types IndividualPhysician et PhysiciansOffice.
LocalBusiness	Entreprise locale générique	Type pris en charge par Google ; il faut préférer le sous-type le plus précis.
Organization	Entité (logo, réseaux)	Fonctionnalité listée par Google.

Les définitions viennent des pages MedicalClinic et Physician de schema.org. Côté Google, la documentation sur les données structurées d’entreprise locale exige deux propriétés, name et address, et en recommande d’autres : geo, openingHoursSpecification, telephone et url. Elle demande d’utiliser le sous-type le plus spécifique, accepte plusieurs types sous forme de liste, et précise que additionalType n’est pas pris en charge.

Pourquoi du JSON-LD plutôt qu’un autre format

Dans son introduction aux données structurées, Google indique recommander le JSON-LD lorsque la configuration du site le permet, parce qu’il est le plus simple à mettre en place et à maintenir à grande échelle. Les formats Microdata et RDFa restent acceptés s’ils sont bien implémentés. Avantage concret pour un site WordPress : le JSON-LD se range dans un bloc séparé du texte, sans toucher au HTML visible, donc sans risque de casser la mise en page.

Un exemple de JSON-LD à adapter

Voici un exemple pour une clinique fictive. Remplacez chaque valeur par vos informations réelles, identiques à celles visibles sur la page. Le bloc se place dans une balise script de type application/ld+json, dans le code de la page concernée.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "name": "Clinique Exemple",
  "url": "https://www.exemple.fr/",
  "telephone": "+33 1 00 00 00 00",
  "image": "https://www.exemple.fr/images/facade.webp",
  "isAcceptingNewPatients": true,
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 rue de l'Exemple",
    "postalCode": "75000",
    "addressLocality": "Paris",
    "addressCountry": "FR"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 48.85660,
    "longitude": 2.35220
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "18:30"
    }
  ]
}
</script>

Pour un praticien installé seul, le même schéma fonctionne avec "@type": "Physician" et le nom du cabinet. Si vous voulez qu’une page décrive le cabinet et que le praticien soit désigné, créez des blocs séparés plutôt que d’imbriquer des informations absentes de la page.

Ce qu’il ne faut pas baliser

Les notes et avis de votre propre cabinet : la documentation Google réserve aggregateRating et review aux sites qui recueillent des avis sur d’autres entreprises locales. Pour un médecin, rappelons aussi que l’Ordre exclut les témoignages de tiers dans la communication.
Des informations invisibles : Google précise qu’il ne faut pas marquer des données que l’utilisateur ne peut pas voir, même exactes.
Des promesses : pas de prix ou de délais que vous ne tenez pas.

Tester le balisage

Ouvrez le Rich Results Test de Google. Il accepte une URL publique ou un extrait de code.
Ouvrez aussi le Schema Markup Validator, l’outil du projet schema.org.
Corrigez les erreurs, puis publiez. Google recommande, après le déploiement, de suivre les rapports d’état des résultats enrichis dans la Search Console, car un modèle de page peut casser le balisage.

Ces vérifications font partie de notre travail de référencement naturel et de maintenance : après une mise à jour du thème ou d’une extension, un balisage qui fonctionnait peut disparaître sans qu’on le remarque.

Mettre en place sur WordPress

Trois voies existent. Une extension SEO génère souvent l’essentiel (organisation, fil d’Ariane) ; un bloc HTML personnalisé permet d’ajouter le JSON-LD d’une page précise ; un développement sur mesure intègre le balisage dans le modèle de page. Selon notre expérience, la deuxième voie suffit pour un cabinet à un seul lieu. Pour un réseau de plusieurs sites, mieux vaut un modèle commun, que nous prévoyons dès la création du site ou lors d’une refonte.

Pourquoi baliser, si les résultats enrichis reculent ?

Le mouvement ne se limite pas aux FAQ. Le même journal de Google signale que plusieurs fonctionnalités ont été abandonnées en 2025 et début 2026 : annonces spéciales, informations de cours, estimation de salaire, vidéo d’apprentissage, annonces de véhicules, puis exercices pratiques en janvier 2026. Pour les données Dataset, Google a précisé en novembre 2025 qu’elles ne servent qu’à Dataset Search, pas à la recherche Google. La leçon est simple : ne bâtissez pas une stratégie sur un affichage enrichi, qui peut disparaître.

Pourquoi baliser alors ? Parce que Google reste clair sur le fond : le balisage décrit le contenu de la page, et la fonctionnalité Local business est toujours documentée, mise à jour en septembre 2026. Pour un cabinet, un balisage propre rend vos coordonnées, vos horaires et votre type d’établissement non ambigus. Il ne garantit aucun affichage particulier, et nous ne le vendons pas comme tel. Google indique d’ailleurs, à propos de ses réponses générées par IA, qu’aucun schema spécifique n’est requis.

La méthode pas à pas

1. Partir de la page, pas du code

Listez ce que la page affiche : nom, adresse, téléphone, horaires, spécialités, accès. Ce sont les seules informations à reprendre dans le JSON-LD. Si une donnée n’est pas lisible par un visiteur, elle ne va pas dans le balisage.

2. Choisir le type le plus précis

Une clinique relève de MedicalClinic. Un cabinet individuel peut utiliser Physician. Un cabinet de kinésithérapie ou de dentiste, qui relève de la santé sans être un médecin, peut commencer par un LocalBusiness plus général : vérifiez dans le vocabulaire schema.org le type le plus proche de votre activité avant de choisir.

3. Renseigner les propriétés requises puis recommandées

Pour Google, name et address sont requis. Ajoutez ensuite telephone, url, openingHoursSpecification et geo (coordonnées avec cinq décimales au moins, selon la documentation). Les horaires saisonniers peuvent utiliser validFrom et validThrough.

4. Tester, publier, retester

Un test avant la mise en ligne ne suffit pas : après toute modification du thème ou d’un plugin, relancez-le. C’est pour cela que nous l’intégrons à un suivi régulier.

Les erreurs courantes

Un téléphone ou une adresse différents du texte visible. Le balisage et la page doivent dire la même chose, ce qui renvoie aussi à la cohérence NAP développée dans notre article sur le SEO local.
Des types inventés ou mal orthographiés. Copiez les noms exacts depuis schema.org.
Un seul bloc recopié sur toutes les pages. Chaque page décrit son propre contenu ; une page de blog n’est pas un cabinet.
Un balisage de FAQ conservé par habitude. Il ne produit plus d’affichage enrichi chez Google ; retirez-le si vous voulez alléger le code, ou laissez-le s’il ne gêne pas, mais ne comptez pas dessus.

Un mot sur les cabinets à plusieurs lieux

Si votre structure exerce sur plusieurs sites, chaque lieu doit avoir sa page et son propre balisage, avec son adresse, ses horaires et son numéro. Google décrit la propriété department comme un sous-ensemble d’entreprise locale pour des services distincts. Pour des lieux différents, pensez plutôt en pages : un lieu, une page, un bloc de données. Cette organisation facilite aussi la maintenance quand un horaire change.

Conclusion

Les données structurées ne sont plus un raccourci vers des résultats enrichis, mais elles restent un moyen propre de décrire votre cabinet. Pour un balisage correct, adapté et testé, contactez-nous ou regardez nos tarifs.

Données structurées JSON-LD pour un cabinet ou une clinique