Schema LocalBusiness : données structurées pour la recherche locale

Quand tu gères une entreprise locale en Autriche, on te trouve presque exclusivement via Google. Le leader du marché y détient 81,87 % de part de marché parmi les moteurs de recherche (chiffres de mai 2026), devant Bing avec 9,01 % et DuckDuckGo avec 2,75 %. Avec 8,69 millions d'internautes et un taux de pénétration de 95,3 %, la recherche organique et locale détermine dans une large mesure si un cabinet, un artisan ou un restaurant gagne des clients.

Pour que Google, et de plus en plus les systèmes d'IA, saisissent de manière fiable les informations clés d'un établissement local, un simple texte ne suffit pas. Le balisage Schema local fournit ces données sous une forme lisible par les machines. Malgré son utilité, il reste peu répandu : selon le Web Almanac 2024, le balisage LocalBusiness n'apparaît que sur 3,97 % des pages mobiles, ce qui en fait certes le troisième type JSON-LD le plus fréquent, mais encore loin d'une pratique standard. C'est précisément là que se trouve une vraie occasion de se démarquer. Cet article montre comment le balisage LocalBusiness est structuré, comment l'implémenter correctement pour un établissement autrichien et quelles erreurs expliquent le plus souvent l'absence de résultats enrichis.

Pourquoi le balisage Schema local compte pour la visibilité locale

Les données structurées sont des annotations de code qui décrivent explicitement le contenu d'une page au lieu de seulement l'afficher. Google recommande pour cela le format JSON-LD, un objet de données intégré dans une balise <script>. Le Web Almanac 2024 confirme la tendance : JSON-LD est passé de 34 % en 2022 à 41 % de toutes les pages en 2024 et est considéré comme le format privilégié par Google et celui qui progresse le plus vite.

Pour les entreprises locales, le balisage LocalBusiness remplit trois fonctions. Il rend l'emplacement, les horaires d'ouverture et les coordonnées exploitables sans ambiguïté, il peut enrichir l'affichage de l'établissement dans les résultats de recherche, et il fournit aux systèmes d'IA comme Google AI Overviews ou Perplexity des faits structurés pour leurs réponses. Contrairement à un Google Business Profile, que tu gères sur une plateforme, le balisage fait partie de ton propre site web et renforce son autorité en tant que source de données principale.

Il faut toutefois garder des attentes réalistes : le schema n'est pas un facteur de classement direct. Il n'améliore pas la position, mais la compréhension et l'affichage. Sa valeur naît indirectement d'une meilleure qualité des données, d'une plus forte incitation au clic grâce aux résultats enrichis et de signaux cohérents envoyés aux moteurs de recherche et aux systèmes d'IA.

Le balisage LocalBusiness face à Organization et WebSite

Trois types de schema sont souvent confondus. Organization : décrit l'entreprise en tant qu'entité juridique ou commerciale, sans ancrage local obligatoire. Il convient aux marques et aux entreprises suprarégionales. WebSite : décrit le site web lui-même, par exemple pour le nom du site que Google affiche dans les résultats de recherche. Le champ de recherche de liens annexes, pour lequel on utilisait auparavant le balisage WebSite, n'est plus affiché par Google depuis le 21 novembre 2024. LocalBusiness : est une spécialisation d'Organization et de Place et décrit un établissement disposant d'un lieu physique et d'une zone de chalandise locale. Seul LocalBusiness transmet l'adresse, les coordonnées géographiques et les horaires d'ouverture comme propriétés centrales.

Le choix du bon sous-type est décisif. Google recommande expressément d'utiliser le sous-type LocalBusiness le plus spécifique, par exemple Restaurant, DaySpa ou HealthClub. Schema.org définit une hiérarchie étendue : Dentist pour un cabinet dentaire, Plumber pour un plombier, Restaurant pour la restauration, LegalService pour un cabinet d'avocats. S'il n'existe pas de sous-type adapté, tu utilises le type général LocalBusiness. Un type erroné ou trop générique fait perdre le contexte que les sous-types spécialisés apportent grâce à des propriétés supplémentaires comme servesCuisine ou menu.

Propriétés obligatoires et recommandées en détail

Dans sa documentation, Google cite deux propriétés obligatoires : name et address de type PostalAddress. Sans ces deux champs, le balisage n'est pas valide. Toutes les autres propriétés sont recommandées et en augmentent considérablement l'intérêt.

• name : le nom exact de l'entreprise, identique à celui de Google Business Profile et des citations.
• address (PostalAddress) : adresse structurée avec streetAddress, postalCode, addressLocality (localité), addressRegion (Land) et addressCountry (pour l'Autriche, AT).
• geo (GeoCoordinates) : latitude et longitude en degrés décimaux. Des coordonnées précises améliorent l'attribution dans Maps, surtout pour les adresses ambiguës.
• telephone : le numéro de téléphone au format international avec l'indicatif du pays, commençant par +43 pour l'Autriche.
• openingHoursSpecification : horaires d'ouverture lisibles par les machines avec dayOfWeek, opens et closes au format 24 heures.
• priceRange : le niveau de prix, par exemple sous forme de symbole (€€) ou de fourchette.
• areaServed : la zone desservie, utile surtout pour les entreprises sans clientèle de passage qui se déplacent chez leurs clients.
• url, image, sameAs : site web, photo et liens vers des profils comme Google Business Profile, Facebook ou des annuaires professionnels.

JSON-LD étape par étape : exemple pour un établissement viennois

L'exemple suivant montre un balisage valide pour un cabinet dentaire fictif à Vienne. Note le formatage propre à l'Autriche : addressCountry sur AT, le numéro de téléphone au format +43 et le point décimal (pas la virgule) dans les coordonnées géographiques.

```html
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Dentist",
"@id": "https://www.zahnarzt-beispiel.at/#praxis",
"name": "Zahnarztpraxis Dr. Beispiel",
"image": "https://www.zahnarzt-beispiel.at/praxis.jpg",
"url": "https://www.zahnarzt-beispiel.at",
"telephone": "+43 1 5550123",
"priceRange": "€€",
"address": {
"@type": "PostalAddress",
"streetAddress": "Mariahilfer Straße 100",
"postalCode": "1070",
"addressLocality": "Wien",
"addressRegion": "Wien",
"addressCountry": "AT"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 48.198765,
"longitude": 16.345678
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday"],
"opens": "08:00",
"closes": "17:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Friday",
"opens": "08:00",
"closes": "13:00"
}
],
"sameAs": [
"https://www.google.com/maps/place/?q=place_id:BEISPIEL",
"https://www.facebook.com/zahnarztbeispiel"
]
}
</script>
```

Place le bloc dans le <head> ou le <body> de la page concernée, idéalement sur la page d'accueil ou sur la page de contact qui contient toutes les données de l'établissement. L'attribut @id avec une URL unique devient important dès que tu relies plusieurs entités ou que tu représentes plusieurs établissements. Chaque information indiquée doit aussi figurer de manière visible sur la page.

Cohérence NAP : schema, Google Business Profile et citations

NAP signifie Name, Address, Phone. Ces trois données doivent être identiques dans toutes les sources : dans le balisage LocalBusiness, dans Google Business Profile et dans les citations locales comme herold.at, firmenabc.at ou les annuaires professionnels. Les incohérences, par exemple « Str. » contre « Straße » ou des formats de téléphone différents, affaiblissent la confiance du moteur de recherche dans les données et peuvent nuire à la visibilité locale.

Le schema est la confirmation lisible par les machines de ce qui figure dans Google Business Profile et dans les citations. La propriété sameAs relie explicitement ton site web à ces profils externes et aide les moteurs de recherche à reconnaître ces fiches comme une seule et même entité. Définis donc une seule graphie NAP de référence et reprends-la partout à l'identique. La cohérence entre plusieurs plateformes compte, car les consommateurs consultent de toute façon plusieurs sources : selon une enquête américaine de BrightLocal, 77 % des consommateurs utilisent au moins deux plateformes d'avis pour leurs recherches, et 41 % en utilisent même trois ou plus.

AggregateRating et balisage des avis pour les entreprises locales

Les avis sont un levier puissant au niveau local. Selon l'étude américaine de BrightLocal, 81 % des consommateurs lisent les avis sur les entreprises locales via Google, et 75 % lisent les avis en ligne « toujours » ou « régulièrement ». Le balisage AggregateRating permet d'indiquer la note moyenne et le nombre d'avis. Sur le propre site d'un établissement local, cela ne génère toutefois pas d'étoiles dans les résultats de recherche.

La raison tient à la règle de Google sur les avis self-serving. Si l'entreprise évaluée contrôle les avis qui la concernent, les pages avec un balisage LocalBusiness ou Organization ne sont pas éligibles aux étoiles d'avis. Cela vaut aussi pour les vrais avis clients publiés sur son propre site, qu'ils figurent directement dans le balisage ou qu'ils proviennent d'un widget intégré affichant des avis Google ou Facebook. Google recommande aggregateRating et review dans le balisage LocalBusiness uniquement pour les sites qui recueillent des avis sur d'autres entreprises locales, par exemple les plateformes d'avis. Les étoiles d'un établissement local apparaissent donc via son Google Business Profile, par exemple dans le Local Pack, ou sur ce type de plateformes. Pour tout balisage d'avis, une règle s'applique en outre : ratingValue, reviewCount et bestRating doivent correspondre exactement aux données affichées de manière visible. Des valeurs inventées ou agrégées sans justification visible enfreignent les consignes et peuvent entraîner des actions manuelles.

Multi-établissements, entreprises de zone de service et liaison par @id

Les entreprises qui ont plusieurs établissements ont besoin, pour chacun d'eux, d'un objet LocalBusiness distinct avec sa propre adresse, ses propres coordonnées géographiques et son propre @id. Crée une landing page dédiée pour chaque établissement et places-y le balisage correspondant. Avec @id, les établissements peuvent être référencés de manière cohérente et rattachés à un objet Organization de niveau supérieur qui décrit la maison mère.

• Plusieurs établissements : pour chaque site, une URL propre, un @id propre et un objet LocalBusiness distinct avec des données précises pour ce site.
• Entreprise de zone de service : les entreprises sans adresse ouverte au public, comme les artisans itinérants, omettent la rue et le numéro, mais indiquent dans address la localité, le code postal, le Land et le pays, car Google considère address comme un champ obligatoire. Elles définissent en plus areaServed avec les localités ou régions desservies.
• @id comme ancre : un @id unique par entité empêche les moteurs de recherche de fusionner plusieurs établissements en une seule entité et permet des liaisons propres entre Organization et chaque établissement.

Validation et correction des erreurs

Un balisage publié doit être vérifié. Trois outils se complètent.

• Test des résultats enrichis : cet outil de Google indique si le balisage peut produire un résultat enrichi et quelles propriétés manquent ou sont erronées. C'est le premier point de contrôle pour LocalBusiness.
• Schema Markup Validator (schema.org) : ce validateur contrôle l'exactitude syntaxique et structurelle selon la spécification Schema.org, indépendamment des résultats enrichis de Google.
• Inspection d'URL dans la Search Console : avec « Tester l'URL en ligne », elle montre comment Google effectue actuellement le rendu de la page. Elle ne liste pas LocalBusiness parmi les éléments détectés. Le HTML rendu te permet cependant de voir si le bloc JSON-LD arrive dans la version explorée, par exemple avec du JavaScript rendu côté client.

Traite les avertissements et les erreurs séparément. Les erreurs empêchent les résultats enrichis et doivent être corrigées ; les avertissements concernent des propriétés recommandées manquantes, qu'il vaut mieux compléter, mais ils ne sont pas bloquants.

Le balisage Schema local dans le contexte de la recherche IA et de l'AEO

Les données structurées gagnent en importance avec l'essor de la recherche assistée par l'IA. Google AI Overviews, ChatGPT et Perplexity puisent de préférence leurs informations dans des sources clairement structurées et attribuées sans ambiguïté. Le balisage LocalBusiness fournit exactement cela : des informations lisibles par les machines sur l'emplacement, les horaires d'ouverture et les prestations, qu'un système d'IA peut reprendre directement dans une réponse.

Pour l'Answer Engine Optimization (AEO), cela signifie que des données cohérentes, visibles et confirmées par le schema augmentent la probabilité qu'un établissement local soit correctement cité dans les réponses de l'IA. Le balisage ne remplace pas un bon contenu, mais il réduit l'ambiguïté. Si l'adresse, le numéro de téléphone et les horaires d'ouverture concordent à la fois dans le texte visible et dans le JSON-LD, le risque qu'un système d'IA utilise des données obsolètes ou erronées issues de sources tierces diminue. Vu la faible diffusion du balisage LocalBusiness, une implémentation soignée constitue une avance réaliste sur la concurrence.

Erreurs fréquentes dans le balisage Schema local

• Sous-type erroné ou trop générique : LocalBusiness au lieu de Dentist ou Restaurant fait perdre du contexte spécifique et des propriétés supplémentaires.
• Données NAP incohérentes : les écarts entre le schema, Google Business Profile et les citations affaiblissent la confiance du moteur de recherche.
• Balisage sans contenu visible sur la page : des données dans le JSON-LD qui ne figurent pas sur la page enfreignent les consignes de Google et peuvent être ignorées ou sanctionnées.
• Balisage d'avis self-serving : avec LocalBusiness, un balisage d'avis portant sur son propre établissement et publié sur son propre site ne donne pas d'étoiles, même avec de vrais avis clients.
• Formats incorrects : des numéros de téléphone sans +43, des horaires d'ouverture qui ne sont pas au format 24 heures ou des coordonnées géographiques avec une virgule au lieu d'un point entraînent des erreurs.
• Plusieurs établissements dans un seul objet : les établissements sans @id propre ni page dédiée fusionnent et perdent leur visibilité individuelle.

Mesurer l'impact : résultats enrichis, impressions et CTR

Tu mesures l'impact du balisage Schema local principalement dans la Google Search Console. Elle ne propose toutefois pas de rapport d'amélioration dédié à LocalBusiness : la Search Console ne fournit des rapports d'état des résultats enrichis que pour certains types, comme les fils d'Ariane, les extraits de produits ou les extraits d'avis. Pour vérifier si Google peut lire le balisage, utilise donc le test des résultats enrichis. Il prend en charge LocalBusiness et effectue le rendu de la page comme Google la traite. L'effet se mesure dans le rapport sur les performances, à travers les impressions et le CTR.

• Corriger les erreurs : vérifie chaque page modifiée avec le test des résultats enrichis et corrige rapidement les erreurs signalées.
• Suivre les impressions : une hausse des impressions sur les requêtes locales après l'implémentation indique une meilleure prise en compte des données. Pour cela, filtre le rapport sur les performances par Autriche et par noms de localités.
• Comparer le CTR : compare le CTR des pages concernées avant et après le balisage, pour les mêmes requêtes.
• Vérifier l'indexation : contrôle avec l'inspection d'URL si la page est indexée et si le bloc JSON-LD figure dans le HTML rendu.

Garde à l'esprit que les résultats enrichis ne sont pas garantis. Google décide selon la requête et la qualité s'il affiche un extrait enrichi. Évalue donc l'impact à partir de la combinaison d'un balisage sans erreur, des impressions et du CTR, et non d'un indicateur isolé.

Pour aller plus loin

Le balisage Schema local est une base technique qui ne déploie sa valeur qu'avec des données cohérentes. Commence par le sous-type LocalBusiness le plus spécifique, remplis les champs obligatoires name et address ainsi que les principales propriétés recommandées, et garde un NAP identique sur le site web, dans Google Business Profile et dans les citations. Valide le résultat avec le test des résultats enrichis et l'inspection d'URL, puis suis l'effet dans la Search Console. Comme seule une petite partie des pages utilise le balisage LocalBusiness, une implémentation soignée représente pour les entreprises autrichiennes un avantage concret et accessible dans la recherche classique comme dans la recherche assistée par l'IA.