Schema Service et LocalBusiness : que faut-il vraiment intégrer à vos données structurées ?

L’essentiel à retenir

Les schémas Service et LocalBusiness sont souvent confondus, alors qu’ils répondent à deux besoins distincts. Schema.org définit Service comme une prestation proposée par une organisation, par exemple un service de livraison ou d’impression, avec des champs clés tels que provider, serviceType, areaServed et hasOfferCatalog. Schema.org décrit au contraire un établissement physique précis, comme un restaurant, une agence bancaire ou un cabinet médical. Sur une page de prestation associée à un établissement unique, il est généralement pertinent de combiner les deux : LocalBusiness pour le lieu, Service pour les prestations proposées.

Points clés

• LocalBusiness exige au minimum un nom et une adresse : Google n’accepte que les balises contenant ces informations pour les résultats enrichis locaux.
• Chaque établissement doit disposer de ses propres données structurées : si vous avez plusieurs adresses, chaque site physique doit être défini séparément avec un type LocalBusiness, comme l’indique Google.
• Service décrit votre offre, pas votre implantation : utilisez serviceType et areaServed pour préciser ce que vous proposez et dans quelle zone, indépendamment de l’adresse de votre établissement.
• Les avis ne sont pas obligatoires : aggregateRating dans LocalBusiness n’est recommandé que pour les sites qui recensent eux-mêmes les avis sur d’autres entreprises locales, et non pour toute entreprise ayant reçu des commentaires de ses clients (Google).
• Les résultats enrichis ne sont jamais garantis : Google précise qu’un balisage correct ne garantit pas un affichage visuel particulier dans les résultats de recherche.

Pourquoi Google ne reconnaît-il pas ma page de prestation comme un établissement local ?

Une entreprise de dépannage publie une page avec son adresse, ses horaires et la liste de ses prestations. Pourtant, dans les résultats de recherche, aucune fiche établissement, aucun horaire, aucune étoile n’apparaît. Les informations sont bien présentes, mais les moteurs ne les interprètent pas comme des données d’entreprise. C’est toute la différence entre un contenu conçu pour les visiteurs et des données structurées lisibles par les machines (des pages de service qui répondent aux acheteurs).

Le problème vient rarement du contenu de la page. Il réside le plus souvent dans l’absence de balisage schema, ou dans une mise en œuvre inadaptée. Sans JSON-LD ni microdonnées, Google ne voit que du texte brut : il doit alors deviner si « 12 rue de la République, Lyon » est une adresse, une note de bas de page ou un simple élément au milieu d’un paragraphe. Les données structurées lèvent cette ambiguïté en indiquant précisément à quoi correspond chaque information.

La carte de visite et la carte des prestations

Considérez LocalBusiness comme la carte de visite de votre entreprise : nom, adresse, numéro de téléphone et horaires. Service correspond à votre carte des prestations : ce que vous proposez, à qui et dans quelle zone. Une page qui ne contient que le balisage LocalBusiness indique aux moteurs où vous vous trouvez, mais pas clairement ce que vous faites. À l’inverse, une page limitée au balisage Service décrit l’offre sans dire où le client peut vous trouver. Pour la plupart des entreprises de services disposant d’un point d’accueil, les deux sont nécessaires.

Que se passe-t-il lorsque vous choisissez le mauvais type ?

Utiliser LocalBusiness pour une prestation proposée uniquement en ligne ou à distance laisse entendre qu’il existe un lieu d’accueil physique, alors que ce n’est pas le cas. À l’inverse, n’utiliser que Service pour une boutique ou un cabinet doté d’une adresse fixe vous prive de la possibilité d’afficher une fiche locale avec carte, horaires et itinéraire. Dans les deux cas, vous réduisez une visibilité que le bon balisage aurait pu renforcer.

Quel schéma choisir selon votre activité ?

Le choix entre Service, LocalBusiness ou une combinaison des deux dépend de la manière dont vos clients accèdent à vos prestations.

LocalBusiness seul convient aux activités pour lesquelles le lieu fait partie intégrante de l’expérience : restaurant, salle de sport ou magasin. Le client se déplace chez vous et la prestation est réalisée sur place.

Service seul est adapté aux professionnels qui n’accueillent pas dans un lieu fixe ou dont la prestation peut être fournie partout : rédacteur freelance, entreprise de nettoyage intervenant à l’échelle nationale, consultant informatique travaillant à distance. Dans ce cas, areaServed est plus déterminant qu’une adresse.

Service intégré à LocalBusiness correspond à la majorité des prestataires de proximité : une entreprise d’installation avec un établissement et une zone d’intervention, une étude notariale ou un cabinet de kinésithérapie proposant aussi des soins à domicile. Vous définissez alors l’établissement avec LocalBusiness, puis vous ajoutez vos prestations via la propriété makesOffer ou hasOfferCatalog, sous forme d’objets Service.

Exemple concret des champs à prévoir

Pour une entreprise de plomberie disposant d’un seul établissement et intervenant dans trois communes, un ensemble minimal et correct comprend :

• @type: LocalBusiness ou un sous-type plus précis, tel que Plumber
• name, address, telephone, openingHours
• areaServed avec les communes couvertes
• hasOfferCatalog contenant un ou plusieurs objets Service, chacun avec son propre serviceType

Cette structure donne aux moteurs de recherche comme aux assistants AI une vision complète et sans ambiguïté : qui vous êtes, où vous êtes implanté et ce que vous proposez exactement.

Voici comment procéder :

• Déterminez d’abord si votre prestation dépend d’un lieu physique ou si elle peut être délivrée partout
• Choisissez LocalBusiness, ou un sous-type plus spécifique, si l’adresse est utile au client
• Ajoutez des objets Service via hasOfferCatalog pour chaque prestation distincte
• Renseignez systématiquement le nom et l’adresse, car il s’agit de l’exigence minimale de Google pour les résultats enrichis
• Testez votre balisage avec le Rich Results Test avant sa mise en ligne

À quoi ressemble un balisage correct pour une entreprise ayant plusieurs établissements ?

Prenons l’exemple d’un cabinet de kinésithérapie régional comptant trois établissements dans des villes différentes. Chaque site possède ses propres horaires, son équipe et une offre en partie commune, en partie spécifique.

Cas pratique : une PME de services fictive disposant de plusieurs établissements

Si ce cabinet utilise un unique balisage LocalBusiness générique pour ses trois sites, avec l’adresse du siège, les moteurs reçoivent un signal confus : quel établissement correspond à la recherche d’un client situé à proximité ? En séparant les données en trois objets LocalBusiness distincts, avec pour chacun son adresse, son numéro de téléphone, ses horaires et ses objets Service correspondant à l’offre locale, des entreprises comparables constatent généralement une amélioration sensible de l’affichage du bon établissement lors des recherches locales. Les résultats varient selon le secteur et le contexte, mais le principe recommandé par Google, à savoir définir chaque établissement séparément, explique structurellement cette différence.

La leçon n’est pas uniquement technique, elle est aussi organisationnelle : traiter les données structurées comme un paramétrage unique pour toute l’entreprise revient à se priver du principal bénéfice qu’elles peuvent apporter.

Quels bénéfices concrets attendre d’un balisage Service et LocalBusiness correct ?

Un balisage bien conçu agit à deux niveaux. D’abord, il favorise les résultats enrichis classiques : fiches d’établissement, horaires et itinéraires directement visibles dans les résultats de recherche. Google est clair sur ce point : les données structurées sont une condition nécessaire, mais non une promesse d’affichage. Même un balisage irréprochable peut ne pas générer de résultat enrichi, simplement parce que Google décide de ne pas l’afficher.

Ensuite, et cet aspect pèse désormais tout autant, elles améliorent la lisibilité de vos pages par les assistants AI. Lorsqu’un internaute demande à ChatGPT ou Perplexity « quel plombier à Lyon assure les dépannages d’urgence ? », ces outils peuvent plus facilement exploiter des données structurées que des informations dispersées dans un paragraphe. Un objet Service renseigné avec un serviceType précis et un areaServed clair est aussi exploitable par un modèle de langage que par un moteur de recherche, et souvent plus simple à interpréter qu’un texte libre.

Cette approche gagne en importance à mesure que les entreprises adoptent l’AI dans leurs activités commerciales et marketing. Selon CBS, en 2025, une entreprise néerlandaise sur six utilisait l’AI, soit deux fois plus qu’il y a deux ans, le marketing et les ventes étant les usages les plus cités. En rendant dès aujourd’hui leurs pages de prestations lisibles par les machines, les entreprises se préparent à un environnement de recherche où Google, mais aussi les assistants AI, fondent leurs recommandations sur des informations structurées et clairement qualifiées.

Quelles erreurs retrouve-t-on le plus souvent dans les balisages existants ?

Trois situations reviennent régulièrement lors d’un audit des données structurées.

Ajouter des avis sans disposer de son propre système de collecte

Certaines entreprises ajoutent aggregateRating à leur balisage LocalBusiness alors qu’elles ne disposent d’aucun système de collecte d’avis. Google est explicite : cette propriété n’est recommandée que pour les sites qui recueillent réellement des avis sur d’autres entreprises locales, et non comme note globale de votre propre entreprise sans dispositif de collecte sous-jacent.

Utiliser une seule adresse générique pour plusieurs établissements

Comme dans l’exemple précédent, recourir à un objet LocalBusiness commun pour plusieurs adresses est une erreur fréquente. Résultat : aucun établissement ne se positionne de manière optimale dans les recherches locales, car les signaux se retrouvent mélangés.

Limiter les informations sur les prestations au texte visible

La page présente clairement les services proposés pour le visiteur, mais ces informations n’existent nulle part dans le code sous forme d’objets Service. Elles sont compréhensibles pour une personne, mais ne peuvent pas être exploitées comme données structurées par un moteur de recherche ou un assistant AI.

En corrigeant ces trois points, vous avez généralement déjà consolidé l’essentiel de la base technique. Le reste relève de la maintenance : mettez vos données structurées à jour dès qu’un horaire, une adresse ou une prestation évolue.

Questions fréquentes

Quelle est la différence entre les schémas Service et LocalBusiness ?

LocalBusiness décrit un établissement physique avec son adresse et ses horaires. Service décrit ce qu’une organisation propose, comme une prestation ou un soin. Un professionnel disposant d’un lieu fixe combine souvent les deux : LocalBusiness pour l’établissement et Service, intégré via hasOfferCatalog, pour son offre.

Faut-il ajouter le balisage LocalBusiness sur chaque page de mon site ?

Non. Seules les pages décrivant un établissement physique précis nécessitent un balisage LocalBusiness. Pour les prestations sans lieu d’accueil fixe, privilégiez un objet Service avec areaServed.

L’adresse est-elle obligatoire dans le balisage LocalBusiness ?

Oui. Selon Google, le nom et l’adresse constituent le minimum requis pour être éligible aux résultats enrichis d’établissement local. Sans ces champs, le balisage n’est pas considéré comme valide pour cette fonctionnalité.

Un balisage correct garantit-il un résultat enrichi dans Google ?

Non. Google indique explicitement qu’il ne garantit pas l’affichage des fonctionnalités liées aux données structurées dans les résultats de recherche, même si leur mise en œuvre est techniquement correcte. Le balisage augmente vos chances, sans constituer une certitude.

Comment Launchmind aide-t-il à mettre en place le balisage Service et LocalBusiness ?

Alex, le collègue AI de Launchmind, enrichit vos pages de prestations avec une réponse immédiate, une indication tarifaire, votre méthode de travail, des éléments de preuve et les questions issues de vos propres échanges clients. Il ajoute aussi les données structurées lues par Google et les assistants AI. Après votre validation, Alex publie la page sur votre site en un clic, avec le balisage Service et LocalBusiness adapté à votre situation.

Conclusion

Les schémas Service et LocalBusiness ne sont pas un simple détail technique. Ils déterminent si Google et les assistants AI interprètent correctement votre page comme un établissement, comme une offre de services ou comme les deux. La règle est simple : LocalBusiness indique où vous êtes installé, Service explique ce que vous proposez, et chaque établissement doit être défini séparément si vous en avez plusieurs. Négliger ces éléments, c’est se priver de résultats enrichis et d’une visibilité auprès des assistants AI pourtant accessibles avec des ajustements relativement simples.

Pour en savoir plus sur le contenu à prévoir sur ce type de page, consultez que faut-il inclure sur une page de prestation qui convertit vraiment. Vous ne souhaitez pas intervenir vous-même dans le code, mais voulez vous assurer que vos pages de prestations sont irréprochables sur le fond comme sur la technique ? Réservez un rendez-vous conseil gratuit et découvrez comment Alex conçoit et publie vos pages avec les données structurées appropriées.

À propos de l’entreprise

Launchmind est le collègue AI qui rédige, contrôle et publie chaque jour du contenu SEO sur votre propre blog, dans 8 langues, tout en s’améliorant à partir des données réelles de Search Console. Alex enrichit également les pages de prestations avec une réponse immédiate, une indication tarifaire, une méthode de travail, des éléments de preuve et les données structurées lues par Google et les assistants AI, pour les responsables marketing, entrepreneurs et CMO de PME et d’entreprises en croissance.