Vous avez installé un schéma LocalBusiness à Taïwan, mais les moteurs d’IA ne mentionnent toujours pas votre établissement ? Le problème tient probablement moins au code qu’au manque de cohérence des données. Lorsqu’un utilisateur demande à Perplexity ou ChatGPT : « Pouvez-vous me recommander un dentiste dans le district de Xinyi, à Taipei ? », l’IA commence par recouper le nom, l’adresse et le numéro de téléphone de votre site avec votre fiche d’établissement Google, les services de cartographie et les annuaires professionnels. Si elle trouve 3 versions différentes, elle préférera généralement ne pas vous mentionner plutôt que de deviner laquelle est correcte. Le véritable facteur déterminant est donc la cohérence du NAP — name, address, phone, soit nom, adresse et téléphone. La syntaxe du schéma ne fait qu’organiser ces faits dans un format lisible par les machines. Cet article suit l’ordre de mise en œuvre : choisir le type, renseigner l’adresse, définir les horaires, puis harmoniser le NAP sur toutes les plateformes.
Pourquoi les moteurs d’IA sont-ils particulièrement sensibles aux données LocalBusiness ?
Pour répondre à une recherche locale, un moteur d’IA doit pouvoir extraire des faits sans ambiguïté : où se trouve l’établissement, s’il est ouvert à cet instant et quel numéro appeler. Or, les adresses chinoises sont difficiles à interpréter automatiquement. « No. 7, Section 5, Xinyi Road, Taipei City » et « No. 7, Section 5, Xinyi Road, Xinyi District, Taipei City » désignent manifestement le même lieu pour une personne, mais un modèle d’extraction peut y voir deux entités distinctes. Le schéma LocalBusiness sépare ces informations dans des champs normalisés. Vous fournissez ainsi directement les éléments de réponse au moteur, sans lui imposer de les deviner ni de les comparer. Moins il subsiste d’incertitude, plus le moteur peut vous intégrer à sa réponse en toute confiance.
Étape 1 : choisissez le bon @type au lieu d’utiliser systématiquement LocalBusiness
Schema.org propose des dizaines de sous-types de LocalBusiness. Plus votre choix est précis, mieux le moteur comprend votre activité. Une société d’expertise comptable peut certes être balisée avec le type générique LocalBusiness, mais AccountingService lui correspond bien mieux. Pour une IA qui cherche à déterminer s’il s’agit du service professionnel demandé, la différence est importante. Commencez par sélectionner le sous-type le plus proche de votre activité. Si aucun ne convient réellement, remontez alors d’un niveau et utilisez un type générique.
- Restaurants et cafés : Restaurant, CafeOrCoffeeShop
- Dentistes et cliniques : Dentist, MedicalClinic
- Avocats et agents fonciers : Attorney, LegalService
- Cabinets comptables et services de tenue de livres : AccountingService
- Commerces de détail : Store, avec des sous-types comme ClothingStore, HardwareStore, etc.
- Instituts de beauté et salons de coiffure : BeautySalon, HairSalon
- N’utilisez le type générique LocalBusiness que lorsqu’aucun sous-type ne correspond réellement à votre activité.
Champ d’adresse : transposer les divisions administratives de Taïwan dans PostalAddress
L’adresse est le champ qui génère le plus d’erreurs. PostalAddress repose sur des propriétés fixes auxquelles chaque niveau administratif taïwanais doit correspondre précisément. Ne regroupez pas toute l’adresse, jusqu’au numéro, dans streetAddress : le moteur ne pourrait plus distinguer le comté ou la municipalité du district administratif.
- addressCountry : indiquez le code pays « TW », et non « Taiwan » ou « Taïwan »
- addressRegion : indiquez la municipalité ou le comté, par exemple « Taipei City » ou « New Taipei City »
- addressLocality : indiquez le district ou le canton, par exemple « Xinyi District »
- streetAddress : indiquez la voie, la section, la ruelle et le numéro, par exemple « No. 7, Section 5, Xinyi Road »
- postalCode : indiquez le code postal au format 3+3, par exemple « 110011 »
- geo : indiquez la latitude et la longitude ; les coordonnées doivent correspondre à l’emplacement de l’épingle sur Google Maps
Horaires d’ouverture : renseigner openingHoursSpecification sans erreur
Utilisez OpeningHoursSpecification pour les horaires d’ouverture, dayOfWeek pour les jours concernés, puis opens et closes pour les heures au format 24 heures HH:MM. Si votre établissement ferme à midi, n’indiquez pas une plage continue de 09:00 à 21:00 : créez deux créneaux, par exemple 11:00–14:00 et 17:00–21:00. Sinon, l’IA pourrait annoncer à l’utilisateur que vous êtes ouvert à 3 heures de l’après-midi. Pour un jour férié où l’établissement reste fermé, ne renseignez aucun horaire. S’il est ouvert 24 heures sur 24, indiquez 00:00 dans opens comme dans closes. Pour les modifications temporaires liées au Nouvel An lunaire ou aux jours fériés nationaux, utilisez specialOpeningHoursSpecification en précisant les dates concernées ; c’est plus sûr que de modifier directement les horaires habituels. Pensez ensuite à synchroniser ces changements avec les horaires exceptionnels de votre fiche d’établissement Google. Les deux sources doivent fournir exactement la même information.
Cohérence NAP : le schéma n’est qu’un point parmi d’autres
Même un schéma parfaitement rédigé ne sert à rien si les autres sources se contredisent. Le nom, l’adresse et le numéro de téléphone doivent être strictement identiques sur chaque plateforme, ponctuation et formatage compris. Le téléphone est particulièrement propice aux écarts : le site officiel affiche « 02-1234-5678 », la fiche d’établissement Google « (02)12345678 » et le schéma « +886-2-1234-5678 ». Une personne comprend qu’il s’agit du même numéro ; une machine peut y voir 3 informations différentes. Pour les données structurées, utilisez systématiquement le format E.164 « +886212345678 ». Vous pouvez présenter le numéro autrement aux visiteurs, mais ne conservez qu’un seul format dans le schéma.
- Fiche d’établissement Google
- Schéma, pied de page et page de contact du site officiel
- Pages professionnelles Facebook et Instagram
- Apple Maps et autres plateformes de navigation
- Annuaires professionnels et Pages Jaunes locales
Lorsque nous auditons les sites officiels locaux de nos clients, l’erreur la plus fréquente n’est pas l’absence de schéma. C’est le même numéro de téléphone écrit de quatre manières sur quatre plateformes. Pour un moteur d’IA, il ne s’agit alors plus d’un seul établissement, mais de quatre établissements qui se ressemblent beaucoup.— Tenten GEO audit notes
Liste de contrôle avant la mise en ligne
- Utilisez le test des résultats enrichis de Google pour vérifier que le schéma peut être analysé et ne contient aucune erreur
- Utilisez Schema Markup Validator pour contrôler la syntaxe de chaque champ
- Placez le NAP du schéma à côté de celui de la fiche d’établissement Google et comparez-les mot pour mot afin de repérer le moindre écart
- Posez directement une question locale à un moteur d’IA et vérifiez si l’adresse et les horaires fournis sont exacts
- Effectuez des contrôles réguliers après la mise en ligne. Dès que l’adresse ou le numéro de téléphone change, synchronisez toutes les plateformes
La difficulté du schéma LocalBusiness n’a jamais résidé dans le bloc JSON-LD lui-même, mais dans la cohérence durable de faits dispersés sur une douzaine de plateformes. Vous ignorez combien d’établissements différents votre NAP et vos données structurées semblent représenter aux yeux des moteurs d’IA ? L’audit GEO de 30 jours de Tenten GEO permet d’identifier tous ces écarts en une seule fois. Si vous souhaitez d’abord obtenir rapidement une première orientation, vous pouvez également prendre rendez-vous pour un diagnostic GEO de 30 minutes. Nous effectuerons une recherche locale à partir de l’adresse réelle de votre site.
