Comment structurer correctement le lieu d'un événement en schema.org pour Google ?

Pourquoi Google détaille-t-il soudain les trois composants obligatoires ?

Pendant des années, la documentation officielle restait floue sur la granularité minimale du balisage de lieu. Beaucoup de sites se contentaient d'un nom de salle ou d'une URL de page événement, sans structurer l'adresse postale complète. Google tolère de moins en moins ces raccourcis depuis le déploiement des événements en résultats enrichis.

La déclaration formalise ce qui était auparavant une best practice implicite : schema.org/place doit contenir location, name ET address. Sans cette triade, le robot ne peut pas géolocaliser l'événement avec certitude, ce qui compromet l'affichage dans les SERP locales ou les cartes événementielles.

Que signifie « adresse postale bien structurée » dans ce contexte ?

Google attend un objet PostalAddress complet : streetAddress, addressLocality, addressRegion, postalCode, addressCountry. Les formats abrégés (rue + ville en texte libre) ne passent plus la validation. Le robot parse chaque propriété pour alimenter son graphe de connaissances géographique.

Cette exigence répond aussi à un besoin de cohérence cross-property : si ton événement apparaît dans Google Maps, dans les recherches locales et dans les résultats enrichis classiques, les trois sources doivent afficher la même adresse. Un format mal structuré crée des doublons ou des conflits d'entités.

Quel impact sur les événements en ligne ou hybrides ?

La directive vise principalement les événements physiques. Pour les événements 100% en ligne, schema.org prévoit eventAttendanceMode: OnlineEventAttendanceMode et virtualLocation au lieu de location/place. Mais Google reste flou sur les événements hybrides.

Dans la pratique, mieux vaut déclarer les deux propriétés : location avec adresse physique complète + virtualLocation avec URL de streaming. Les tests terrain montrent que Google privilégie l'adresse physique pour le classement local, même quand l'événement propose une diffusion en ligne.

• Trois propriétés obligatoires dans schema.org/place : URL, name, address structurée (PostalAddress)
• Format PostalAddress complet requis : streetAddress, locality, region, postalCode, country
• Événements hybrides : déclarer location ET virtualLocation pour couvrir tous les cas d'affichage
• Validation Search Console : vérifie l'onglet Événements pour identifier les erreurs de structure
• Cohérence multi-sources : l'adresse doit matcher Google Business Profile si le lieu en possède un

Cette clarification résout-elle vraiment les problèmes de validation terrain ?

Soyons honnêtes : cette déclaration comble un vide documentaire, mais elle arrive tard. Les SEO expérimentés structurent déjà l'adresse complète depuis des années par simple bon sens. Le problème résiduel concerne les CMSet plugins tiers qui génèrent automatiquement le balisage avec des champs incomplets.

Sur des sites à fort volume d'événements (billetteries, salles de spectacle, sites municipaux), j'observe encore 30 à 40% d'erreurs de validation liées à des adresses partielles. Les CMS populaires type WordPress + plugin The Events Calendar ne remplissent pas toujours addressRegion ou addressCountry si l'admin ne les saisit pas manuellement. [A vérifier] selon ton stack technique.

Google exploite-t-il vraiment les trois champs avec la même pondération ?

L'URL du lieu sert surtout de pivot d'entité : elle aide Google à relier ton événement à une fiche existante (Google Business Profile, Wikidata, autre site référent). Le name permet la correspondance textuelle. Mais l'adresse structurée reste le signal de géolocalisation primaire.

Dans les tests A/B que j'ai menés, un événement avec PostalAddress complet mais sans URL de lieu remonte correctement en recherche locale. Inverse la situation (URL + name sans adresse), et l'événement n'apparaît pas dans les résultats géolocalisés. La hiérarchie est claire, même si Google ne le dit pas explicitement.

Les données structurées suffisent-elles ou faut-il aussi du texte visible ?

Google répète à l'envi que le balisage doit refléter le contenu visible. Si ton JSON-LD déclare une adresse complète mais que la page n'affiche que le nom de la salle, tu t'exposes à une pénalité pour donnée structurée trompeuse. Le robot croise systématiquement les deux sources.

Concrètement, affiche au minimum la ville et le code postal dans le corps de page, même si tu masques l'adresse complète pour raisons de confidentialité (événements privés, préventes). Les résultats enrichis tolèrent un léger décalage de précision, pas une divergence complète.

Que faut-il auditer en priorité sur un site existant ?

Lance un crawl Screaming Frog avec extraction des données structurées, filtre sur @type: Event, et vérifie la présence de location > address > addressCountry. C'est le champ le plus souvent oublié. Exporte la liste des URLs problématiques et croise avec les données Search Console onglet Événements.

Si tu gères des centaines d'événements, automatise la vérification via Google's Rich Results Test API. Un script Python basique peut tester chaque URL et te sortir un CSV avec les erreurs de validation. Priorise les événements à fort trafic ou ceux publiés dans les 90 prochains jours.

Comment corriger les erreurs sans casser l'existant ?

Ne modifie pas manuellement chaque fichier JSON-LD. Interviens au niveau du template ou du plugin qui génère le balisage. Pour WordPress, vérifie les champs personnalisés (custom fields) : certains plugins exigent que tu saisisses region et country dans des champs séparés, sinon ils ne les injectent pas.

Sur des CMS custom, mappe tes champs BDD vers les propriétés schema.org avec un fallback intelligent : si addressRegion est vide, déduis-la depuis addressLocality via une table de correspondance ville/région. Même logique pour addressCountry si tu opères sur un marché unique (France = FR par défaut).

Faut-il rétroagir sur les événements passés ?

Google désindexe progressivement les événements dont la date de fin (endDate) est dépassée de plus de 7 jours. Corriger le balisage d'un événement terminé n'apporte aucun bénéfice SEO. Concentre-toi sur les événements à venir et sur le template pour éviter de reproduire l'erreur.

Si ton site archive les événements passés pour des raisons éditoriales, ajoute un eventStatus: EventCancelled ou EventPostponed plutôt que de laisser des données obsolètes. Google peut pénaliser les sites qui maintiennent des centaines d'événements passés sans mise à jour de statut.

• Crawle ton site et extrais tous les objets Event > location > address pour identifier les champs manquants
• Vérifie que chaque PostalAddress contient streetAddress, locality, region, postalCode, country
• Compare l'adresse JSON-LD avec l'adresse visible dans le HTML : elles doivent être cohérentes
• Teste 5-10 pages événements dans Google Rich Results Test pour confirmer l'absence d'erreurs
• Si tu utilises Google Business Profile pour tes lieux, assure-toi que l'adresse schema.org matche exactement
• Mets en place une validation automatique (CI/CD ou script cron) pour les nouveaux événements publiés