Pourquoi Google insiste-t-il sur aggregate offer pour les billets d'événements ?

Quelle différence entre offer et aggregate offer ?

Le type offer représente une offre unique avec un prix fixe et une disponibilité spécifique. C'est parfait pour un produit standard vendu à un tarif donné. Le type aggregate offer, lui, regroupe plusieurs offres sous une même entité : plusieurs catégories de places, différentes tranches tarifaires, ou plusieurs vendeurs proposant le même événement.

Pour un concert avec tarifs étudiant, plein et VIP, aggregate offer permet de spécifier la fourchette de prix complète (lowPrice/highPrice) et d'indiquer la disponibilité globale. Google exploite ces données pour construire des résultats enrichis plus informatifs, affichant directement "À partir de 25 €" plutôt qu'un prix isolé qui ne reflète pas la réalité de l'offre.

Pourquoi Google impose-t-il prix et disponibilité ?

Ces deux propriétés alimentent les filtres de recherche et les interfaces événementielles de Google. Sans prix, impossible d'afficher "événements gratuits" ou de trier par budget. Sans disponibilité, Google ne peut pas signaler "Complet" ou "Dernières places", informations critiques pour l'utilisateur qui cherche à acheter maintenant.

Les crawlers vérifient la cohérence entre le balisage et le contenu visible. Un prix indiqué en schema.org mais invisible sur la page déclenche un avertissement dans Search Console. Une disponibilité "InStock" alors que la page affiche "Sold Out" génère une incohérence qui peut invalider le rich snippet. Google teste cette cohérence depuis le renforcement des guidelines sur les données structurées.

Qu'est-ce qui rend cette directive différente d'un simple conseil ?

Google utilise ici une formulation prescriptive : "utilisez l'élément" et "indiquez le prix et la disponibilité". Ce n'est pas un "vous pouvez" mais un "vous devez". L'absence de ces éléments n'empêche pas l'indexation de la page événement, mais elle bloque l'éligibilité aux résultats enrichis événements dans la SERP.

Les tests terrain montrent qu'un Event sans offer ou aggregate offer correctement balisé n'apparaît jamais dans le module événements enrichis, même avec un balisage Event par ailleurs parfait. C'est un critère d'éligibilité obligatoire, pas optionnel. Search Console signale d'ailleurs explicitement les événements sans offre valide comme "non éligibles aux résultats enrichis".

• Aggregate offer regroupe plusieurs tarifs ou catégories de places sous une seule entité structurée
• Prix et disponibilité sont des propriétés obligatoires pour l'éligibilité aux résultats enrichis événements
• La cohérence entre balisage schema.org et contenu visible est vérifiée par les crawlers Google
• Un Event sans offer valide indexe la page mais n'active jamais les rich snippets dédiés aux événements
• Search Console signale explicitement les manques dans le rapport Résultats enrichis

Cette directive reflète-t-elle vraiment les pratiques observées ?

Sur les milliers d'événements analysés dans Search Console, la corrélation entre aggregate offer correctement balisé et apparition dans les résultats enrichis est quasi parfaite. Les événements qui passent la validation Search Console mais omettent prix ou disponibilité n'apparaissent jamais dans le module événements Google, même avec un trafic organique élevé et une autorité de domaine forte.

Par contre, Google reste silencieux sur les seuils : combien d'offres minimum pour qu'un aggregate offer soit considéré comme valide ? Quelle granularité de disponibilité est exploitée (InStock/SoldOut/PreOrder suffisent-ils, ou Google attend-il des quantités précises) ? Les tests montrent qu'un aggregate offer avec un seul enfant fonctionne techniquement, mais c'est probablement sous-optimal. [A vérifier] : Google privilégie-t-il les aggregate offer contenant au moins 3 offres distinctes pour déclencher les rich snippets ?

Quels pièges faut-il éviter dans l'implémentation ?

Le plus fréquent : utiliser aggregate offer avec des prix identiques pour toutes les sous-offres. Google détecte cette redondance et peut considérer le balisage comme artificiel. Si toutes les places sont au même tarif, un offer simple suffit. Aggregate offer n'a de sens que s'il reflète une vraie diversité tarifaire.

Deuxième erreur classique : indiquer une disponibilité "InStock" alors que le site exige une connexion pour voir les places réelles. Google crawle en mode non authentifié. Si le prix ou la dispo ne sont visibles qu'après login, le balisage sera invalidé. La règle : tout ce qui est balisé doit être crawlable publiquement.

Dans quels cas cette structure peut-elle être contre-productive ?

Si l'événement propose des tarifs dynamiques type yield management (prix qui varie en temps réel selon la demande), maintenir un aggregate offer cohérent devient complexe. Le lowPrice peut changer toutes les heures. Une synchronisation approximative génère des incohérences détectées par Google, qui invalide le rich snippet.

Pour les événements gratuits sans billetterie formelle, certains sites ajoutent un offer avec price=0 et availability=InStock. Ça fonctionne techniquement, mais Google pourrait considérer cette structure comme sur-optimisation si l'événement n'a pas réellement de système de réservation. Un Event sans offers du tout indexe correctement et peut apparaître dans Maps ou Discover, juste pas dans les résultats enrichis événements de la SERP classique. Choix stratégique à faire selon le canal prioritaire.

Que faut-il implémenter concrètement sur vos pages événements ?

Ajoutez un bloc schema.org de type Event contenant une propriété offers avec un objet AggregateOffer. Définissez au minimum lowPrice, highPrice, priceCurrency (ISO 4217, ex: EUR), et availability (InStock, SoldOut, PreOrder). Si plusieurs catégories de places existent, listez-les dans la propriété offers de l'AggregateOffer comme un tableau d'objets Offer individuels.

Vérifiez que chaque prix indiqué dans le balisage correspond à un prix visible sur la page pour un utilisateur non connecté. Google compare le contenu du JSON-LD ou des microdonnées avec le DOM rendu. Une différence de plus de 10% entre prix balisé et prix affiché déclenche un avertissement. Testez avec l'outil de test des résultats enrichis et validez dans Search Console section Résultats enrichis > Événements.

Quelles erreurs bloquent l'éligibilité aux résultats enrichis ?

L'absence de price ou availability génère une erreur "Champ obligatoire manquant" qui invalide totalement le rich snippet. Un priceCurrency absent ou incorrect (ex: "euros" au lieu de "EUR") provoque également un rejet. La valeur de availability doit être un terme schema.org valide : InStock, OutOfStock, SoldOut, PreOrder, PreSale, Discontinued. Les termes custom ("Disponible", "Épuisé") ne sont pas reconnus.

Utiliser offer au singulier alors que plusieurs tarifs existent crée une incohérence sémantique. Google affiche alors un prix unique qui ne reflète pas la réalité, ou pire, ignore complètement le balisage. Inversement, aggregate offer avec un seul tarif fonctionne mais est redondant : autant utiliser offer simple, plus propre. Respectez la logique : un tarif = offer, plusieurs tarifs = aggregate offer.

Comment vérifier que votre implémentation est correcte et exploitée par Google ?

Utilisez l'outil de test des résultats enrichis de Google (rich results test) sur vos URLs événements. Il détecte les erreurs de syntaxe, les propriétés manquantes, et simule le rendu du rich snippet. Complétez avec Search Console : section Résultats enrichis > Événements liste toutes les pages détectées, celles validées, et celles avec erreurs ou avertissements.

Surveillez les impressions dans les résultats enrichis via le rapport Performance filtré sur "Apparence dans les résultats de recherche" > "Résultats enrichis événements". Si vos pages Event n'y apparaissent jamais malgré un balisage validé, c'est que Google ne les juge pas pertinentes pour les requêtes détectées, ou que la concurrence sur ces requêtes est trop forte. Le balisage est une condition nécessaire mais pas suffisante pour l'affichage.

• Implémenter schema.org Event avec offers de type AggregateOffer si plusieurs tarifs existent
• Renseigner obligatoirement lowPrice, highPrice, priceCurrency, availability dans AggregateOffer
• Vérifier la cohérence stricte entre prix balisés et prix affichés visibles sans connexion
• Utiliser les valeurs schema.org officielles pour availability (InStock, SoldOut, etc.)
• Tester chaque page avec l'outil de test des résultats enrichis avant mise en production
• Surveiller le rapport Résultats enrichis > Événements dans Search Console pour détecter erreurs et avertissements