Comment baliser un événement reporté dans les données structurées ?

Définition : Un événement reporté utilise le type de données structurées Event avec la propriété eventStatus définie sur https://schema.org/EventPostponed tant que sa nouvelle date reste inconnue. Les consignes de Google prévoient de conserver les dates d’origine pendant cette période, puis de passer le statut à EventRescheduled et de mettre à jour les dates lorsque le nouveau calendrier est connu.

Points clés

• La définition d’EventPostponed de Schema.org décrit un événement reporté dont la nouvelle date n’est pas encore fixée.
• Au 17 octobre 2026, la documentation de Google sur les événements demande aux éditeurs de conserver startDate et location lorsqu’ils signalent un report.
• La propriété previousStartDate de Schema.org enregistre la date de début précédemment prévue et peut être répétée lorsqu’un événement est reprogrammé plusieurs fois.
• Les consignes générales de Google sur les données structurées exigent des informations à jour et un contenu visible par les lecteurs.

Que faut-il modifier tant que la nouvelle date est inconnue ?

La propriété eventStatus décrit le statut de l’événement. Les consignes de Google sur les reports indiquent de définir cette propriété sur EventPostponed en conservant les autres valeurs existantes. En particulier, les valeurs d’origine de startDate et de location aident Google à identifier l’événement.

Le fragment de propriétés suivant s’insère dans l’objet de l’événement existant :

{
  "eventStatus": "https://schema.org/EventPostponed"
}

Ce fragment présente uniquement le changement de statut ; le balisage complet conserve les autres propriétés de l’événement, y compris ses dates d’origine. Google exige que chaque événement dispose d’une URL unique et que le balisage figure sur cette page, consacrée à un seul événement.

Que faut-il modifier lorsque la nouvelle date est confirmée ?

Les consignes de Google sur la reprogrammation indiquent de renseigner les nouvelles dates dans startDate et endDate. Ses consignes sur les reports précisent également de passer le statut à EventRescheduled une fois la nouvelle date connue.

La propriété previousStartDate contient l’ancienne date de début. Google la classe parmi les propriétés recommandées ; lorsqu’elle est renseignée, Google exige que eventStatus ait la valeur EventRescheduled.

Cet extrait de l’exemple d’événement reprogrammé fourni par Google montre comment les dates s’articulent. Il s’agit d’un fragment de propriétés à intégrer dans l’objet Event complet :

{
  "startDate": "2025-07-21T19:00-05:00",
  "endDate": "2025-07-21T23:00-05:00",
  "eventStatus": "https://schema.org/EventRescheduled",
  "previousStartDate": "2025-03-21T19:00-05:00"
}

Les nouvelles dates de début et de fin décrivent le nouveau calendrier ; l’ancienne date de début conserve la trace du calendrier précédent. Les consignes de Google sur les dates demandent d’indiquer le décalage horaire approprié lorsqu’une heure est fournie. Lorsque le jour est connu mais que l’heure de début ne l’est pas, elles recommandent d’indiquer la date sans inventer d’heure.

À quoi correspondent les autres valeurs de statut ?

Les valeurs de statut prises en charge par Google distinguent les situations suivantes :

Les vocabulaires présentent une différence : la page EventPostponed de Schema.org indique de renseigner previousStartDate, tandis que les consignes de Google sur cette propriété en réservent l’usage à EventRescheduled. Pour sa fonctionnalité consacrée aux événements, Google documente l’association d’EventPostponed avec la valeur d’origine de startDate jusqu’à ce que le nouveau calendrier soit connu.

Comment vérifier le balisage mis à jour ?

Les étapes de mise en œuvre du balisage d’événement décrites par Google prévoient une validation avec le test des résultats enrichis (Rich Results Test) et la correction des erreurs critiques. Après le déploiement, l’outil d’inspection d’URL permet de vérifier comment Google voit la page ; les mêmes consignes permettent de demander une nouvelle exploration.

Les informations visibles sur l’événement doivent également refléter le changement de statut : les consignes de Google relatives au contenu exigent des informations à jour et interdisent le balisage décrivant un contenu masqué aux lecteurs. Le test du balisage et la vérification de l’annonce de l’événement portent donc sur des aspects différents de la mise à jour.

Termes associés

• Données structurées
• JSON-LD

Questions fréquentes

Dois-je supprimer la date de début d’origine après un report ?

Conservez-la tant que la nouvelle date est inconnue. Les consignes de Google sur le statut des événements utilisent la valeur d’origine de startDate pour aider à identifier l’événement.

Puis-je omettre le statut et simplement conserver les anciennes dates ?

Google interprète l’absence d’eventStatus comme EventScheduled. Définissez la valeur sur EventPostponed pour indiquer que l’événement est reporté.

Que faire si la date de l’événement change plusieurs fois ?

Pour un événement reprogrammé, conservez le calendrier le plus récent dans startDate et endDate. La même documentation autorise plusieurs valeurs de previousStartDate pour les calendriers antérieurs.

Sources

1. Google Search Central, « Event (Event) structured data », mis à jour le 8 septembre 2026
2. Schema.org, « EventPostponed », consulté le 17 octobre 2026
3. Schema.org, « previousStartDate », consulté le 17 octobre 2026
4. Google Search Central, « General structured data guidelines », mis à jour le 10 juillet 2026

---

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO