Données structurées pour un site de service : les 4 blocs utiles

Pour un site de service, quatre blocs de données structurées font l’essentiel du travail : Organization (ou LocalBusiness si vous recevez des clients sur place), Service avec son Offer, FAQPage et Person. Ils disent à Google et aux IA, sans ambiguïté, qui vous êtes, ce que vous vendez, à quel prix, et qui écrit. Le reste est du détail.

Que sont les données structurées, en une phrase ?

C’est un bloc de texte invisible pour le visiteur, écrit dans un format standard (JSON-LD, vocabulaire Schema.org), qui décrit la page en termes qu’une machine comprend sans deviner. Votre page dit « Je suis coach à Bayonne » en français ; le bloc dit "@type": "LocalBusiness", "address": { "addressLocality": "Bayonne" }.

Quand j’ai calibré mon LP1 Score sur huit sites réels, plusieurs n’avaient aucune donnée structurée décrivant l’entreprise. Google et les IA devaient deviner le métier, la ville et l’offre à partir du texte. Ils y arrivent parfois. Pourquoi les laisser deviner ?

Quels sont les quatre blocs utiles pour un site de service ?

Bloc	Ce qu’il dit	Où le mettre	Champs essentiels
Organization ou LocalBusiness	Qui vous êtes, comment vous joindre	Toutes les pages	name, url, logo, telephone, address, sameAs
Service + Offer	Ce que vous vendez, à quel prix	Page de chaque offre	name, provider, areaServed, price, priceCurrency
FAQPage	Les questions qu’on vous pose et vos réponses	Pages avec une FAQ visible	question, acceptedAnswer
Person	Qui est derrière, avec quelles preuves	Accueil, à propos, articles	name, jobTitle, alumniOf, sameAs

Organization ou LocalBusiness : l’identité

C’est le bloc de base. LocalBusiness convient si vous avez une adresse où les clients viennent, ou une zone d’intervention précise. Organization suffit pour un service à distance. Le champ sameAs relie le site à vos profils (LinkedIn, fiche Google) : c’est ce qui permet aux moteurs de reconnaître que toutes ces pages parlent de la même entité.

Service et Offer : ce que vous vendez

Un bloc Service par offre, placé sur la page de cette offre. Le prix va dans Offer. Si votre prix est affiché sur la page, mettez-le aussi dans le bloc : une IA qui répond à « combien coûte un coaching Pilates à Bayonne » cherche précisément cette donnée. Un prix « sur devis » peut rester absent du bloc.

FAQPage : les questions et les réponses

Soyons honnêtes : depuis août 2023, Google n’affiche plus les FAQ en résultat enrichi que pour quelques sites officiels et de santé. Votre FAQ ne s’ouvrira plus en accordéon sous votre lien. Je continue pourtant à la baliser, pour deux raisons. Les questions et réponses restent lues par Google pour comprendre la page. Et les moteurs IA adorent ce format : une question formulée comme l’utilisateur la pose, une réponse courte juste en dessous, c’est exactement ce qu’ils citent. J’en parle plus en détail dans comment se faire citer par ChatGPT et Perplexity.

Une règle : le bloc ne doit contenir que des questions visibles sur la page. Baliser une FAQ cachée est contraire aux consignes de Google.

Person : qui se porte garant

C’est le bloc le plus sous-estimé. Google insiste sur l’expérience et l’expertise de l’auteur, et les IA cherchent qui parle. Un bloc Person avec jobTitle, alumniOf (votre école ou diplôme) et sameAs vers LinkedIn transforme « un site » en « un professionnel identifiable ». Mettez-le en founder dans Organization, et en author dans chaque article de blog.

À quoi ressemble un bloc complet ?

Voici un exemple court pour un coach indépendant. Les valeurs sont fictives, la structure est celle que j’utilise :

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Exemple Coaching",
  "url": "https://exemple-coaching.fr",
  "telephone": "+33600000000",
  "address": { "@type": "PostalAddress", "addressLocality": "Bayonne", "postalCode": "64100", "addressCountry": "FR" },
  "areaServed": ["Bayonne", "Anglet", "Biarritz"],
  "sameAs": ["https://www.linkedin.com/in/exemple"],
  "founder": {
    "@type": "Person",
    "name": "Prénom Nom",
    "jobTitle": "Coach sportif diplômé d’État"
  },
  "makesOffer": {
    "@type": "Offer",
    "price": "60",
    "priceCurrency": "EUR",
    "itemOffered": { "@type": "Service", "name": "Séance de coaching individuel" }
  }
}

Ce bloc se place dans une balise <script type="application/ld+json"> dans le code de la page. Il ne change rien à l’affichage.

Comment savoir si c’est bien fait ?

Trois vérifications, dans cet ordre :

1. Le test des résultats enrichis de Google : il signale les erreurs bloquantes.
2. Le validateur de schema.org : il signale les propriétés mal nommées.
3. La cohérence avec la page : chaque prix, adresse ou question du bloc doit être visible sur la page. Un bloc qui contredit la page fait plus de mal que de bien.

Ce que je mets sur les sites que je livre

Sur LandingPage1 lui-même, vous trouverez Organization, Service avec ses deux Offer à prix affiché, FAQPage, Person (avec INSA Lyon et LinkedIn) et BlogPosting sur chaque article. Sur un site client, c’est la même base, adaptée : LocalBusiness si le client reçoit sur place, un Service par offre, une FAQ par page qui en a une.

Tout cela est compris dans mon pack Site à 1 500 € HT, livré en 7 jours avec 20 landing pages : ce n’est pas une option, c’est la base d’un site qui veut être compris. Les données structurées vont de pair avec un title et une meta description bien écrits : ce sont les deux premières choses qu’un moteur lit.

Et votre site, que disent ses données ?

Mon outil vérifie la présence d’un bloc JSON-LD valide et d’un type qui décrit l’entreprise, parmi 30 critères. Entrez l’adresse de votre site ici : vous aurez un score sur 100 en une minute, puis mon analyse écrite à la main par email sous 24 heures. C’est gratuit.