Ajouter un balisage Schema.org Event pour une billetterie de spectacle

Comment Google sait-il qu’un spectacle se joue le mardi à vingt heures trente et le vendredi à quinze heures, avec des tarifs différents selon la catégorie de place ? La réponse tient dans un balisage JSON-LD de type Event, correctement structuré, que le site d’une salle de spectacle vivant a mis en place pour ses douze représentations mensuelles réparties sur trois spectacles différents.

Avant ce chantier, la page de chaque spectacle affichait les dates de représentation uniquement sous forme de texte libre dans le contenu, sans aucune structure exploitable par un moteur de recherche pour générer un résultat enrichi de type événement dans les pages de résultats.

Étape 1 : identifier l’unité de balisage pertinente

Le premier arbitrage a consisté à déterminer ce que représente une entité Event dans ce contexte précis. Un spectacle générique, joué à douze dates différentes sur le mois, ne constitue pas un seul événement mais douze événements distincts, chacun avec sa propre date, éventuellement son propre horaire et parfois sa propre grille tarifaire selon le jour de la semaine.

Balisez un seul Event par spectacle, sans détail de date, aurait produit un balisage incomplet et inexploitable pour un résultat enrichi, qui exige une date de début précise et non une plage vague.

Étape 2 : construire le JSON-LD pour chaque représentation

Chaque représentation dispose de sa propre entrée dans un champ personnalisé de type répéteur, associé au spectacle parent. Le balisage est généré dynamiquement à partir de ces entrées :

function billetterie_json_ld_event( $representation ) {
    return array(
        '@context'  => 'https://schema.org',
        '@type'     => 'Event',
        'name'      => $representation['nom_spectacle'],
        'startDate' => $representation['date_heure_iso'],
        'location'  => array(
            '@type'   => 'Place',
            'name'    => 'Salle des Terrasses',
            'address' => array(
                '@type'           => 'PostalAddress',
                'streetAddress'   => '14 rue des Terrasses',
                'addressLocality' => 'Bourges',
                'postalCode'      => '18000',
                'addressCountry'  => 'FR',
            ),
        ),
        'offers' => array(
            '@type'         => 'Offer',
            'price'         => $representation['prix_min'],
            'priceCurrency' => 'EUR',
            'url'           => $representation['url_billetterie'],
            'availability'  => 'https://schema.org/InStock',
        ),
    );
}

Le champ date_heure_iso stocke la date au format ISO 8601 complet, avec fuseau horaire, une exigence stricte de la spécification Event qu’une date au format libre ne satisferait pas.

Étape 3 : gérer le prix de la catégorie la moins chère

Chaque représentation propose trois catégories de places à des tarifs différents. La spécification Offer attend un prix unique ou une fourchette, pas trois entités distinctes pour une même représentation. Le choix retenu a été de renseigner le tarif de la catégorie la plus accessible, cohérent avec la pratique recommandée pour éviter qu’un visiteur ne se sente trompé par un prix affiché plus bas dans le résultat enrichi que celui réellement payé pour la place qu’il choisira :

$prix_min = min( array_column( $representation['tarifs'], 'montant' ) );

Cette approche reste transparente tant que la billetterie elle-même affiche clairement les tarifs par catégorie une fois le visiteur arrivé sur la page.

Étape 4 : injecter le balisage sur la page de représentation

Le JSON-LD généré est injecté dans le <head> de chaque page de spectacle, avec une boucle produisant une entité Event par représentation à venir. Les représentations passées ne sont plus balisées, une fois leur date dépassée, pour éviter de présenter aux moteurs de recherche des événements qui ne sont plus d’actualité :

• Filtrage des représentations dont date_heure_iso est postérieure à la date courante
• Génération d’une entité Event distincte par représentation restante
• Encodage en JSON via wp_json_encode() pour éviter toute erreur de syntaxe

Ce qui reste hors du périmètre de ce balisage

Ce chantier concerne uniquement l’exposition des données de représentation aux moteurs de recherche. Le système de vente de billets lui-même, avec sa gestion des places disponibles en temps réel et son intégration au terminal de paiement, reste un système entièrement séparé, dont le balisage se contente de refléter l’état à un instant donné sans jamais s’y substituer.

Un balisage Event mal daté vaut moins qu’aucun balisage : mieux vaut ne rien afficher qu’afficher une date passée ou un prix qui ne correspond à rien de réellement disponible.

Pour aller plus loin

La validation du balisage via l’outil de test des résultats enrichis de Google reste une étape indispensable avant mise en production, en particulier pour vérifier le format exact de la date et la présence de tous les champs obligatoires. Une fois validé, ce type de balisage améliore sensiblement la visibilité des dates de représentation directement dans les pages de résultats, sans que le visiteur n’ait besoin de cliquer pour connaître l’horaire exact.