Faut-il créer une page par jour pour un événement multi-jours ou canoniser vers une page unique ?

Pourquoi Google recommande-t-il une page unique pour un événement multi-jours ?

La logique de Google repose sur le schema Event qui dispose nativement de propriétés temporelles. Les propriétés startDate et endDate permettent de décrire précisément la période de l'événement, rendant théoriquement inutile la multiplication des URLs.

Martin Splitt insiste sur l'usage de la balise canonical vers cette page unique. L'objectif sous-jacent : concentrer les signaux de pertinence et éviter que Google interprète plusieurs jours comme des événements distincts. C'est une approche qui favorise la consolidation du PageRank et simplifie le crawl.

Quels sont les cas d'usage couverts par cette recommandation ?

Cette directive s'applique principalement aux événements dont la nature reste identique sur toute la durée — festivals, conférences, salons professionnels. Un festival de trois jours partage la même thématique, le même lieu, les mêmes organisateurs.

Mais dès qu'un événement propose des sessions distinctes avec des intervenants différents, des horaires spécifiques et des contenus autonomes, la question se complexifie. Google ne précise pas où placer la limite entre « même événement étalé » et « série d'événements liés ».

Que dit réellement le markup Event Schema sur les événements récurrents ?

Le schema.org définit un type Event avec des sous-propriétés pour les horaires (startDate, endDate, eventSchedule). Il existe aussi EventSeries pour les événements récurrents, mais son adoption reste marginale.

La documentation officielle de schema.org suggère que chaque sous-événement distinct peut être marqué comme un Event séparé via la propriété subEvent. Cette possibilité entre en tension avec la recommandation de Martin Splitt : Google simplifie le message, mais le standard technique offre plus de nuances.

• Un Event Schema unique avec startDate/endDate suffit techniquement pour un événement continu
• La canonisation vers une page unique concentre les signaux SEO
• Les sous-événements peuvent être déclarés via la propriété subEvent, mais Google ne détaille pas l'impact sur le classement
• La recommandation s'applique surtout aux événements dont la nature ne varie pas d'un jour à l'autre
• Google ne fournit pas de seuil clair entre événement multi-jours et série d'événements distincts

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Paradoxalement, de nombreux sites performants dans les SERPs événementiels font exactement l'inverse. Ils créent une page par session, par jour, voire par intervenant — et ça fonctionne. Eventbrite, Meetup, ou les sites de grandes conférences tech structurent souvent leur arborescence autour de sessions individuelles.

La raison ? Chaque session répond à une intention de recherche spécifique. Un utilisateur cherchant « conférence IA Paris mardi » a une attente différente de celui qui cherche l'événement global. Google classe ces pages séparées parce qu'elles correspondent à des requêtes distinctes. [A vérifier] : l'impact réel de la canonisation forcée sur la visibilité de ces sous-requêtes reste flou.

Quelles nuances faut-il apporter à cette recommandation ?

Martin Splitt parle d'un événement « sur plusieurs jours » sans distinguer les typologies d'événements. Un festival de musique où les groupes changent chaque soir n'est pas structurellement équivalent à une formation étalée sur trois journées avec le même contenu.

Si les journées ont des programmes distincts, des intervenants différents, et génèrent des recherches spécifiques (« programme vendredi », « speakers samedi »), alors une page unique devient un goulot d'étranglement pour l'expérience utilisateur. Tu forces les visiteurs à scanner un contenu long pour trouver l'info du jour précis qui les intéresse.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle contre-productive ?

Trois situations où la page unique pose problème. D'abord, les événements avec billetterie différenciée par jour : si tu vends des billets jour par jour, chaque URL de vente mérite sa propre page optimisée. Canoniser vers une page générique dilue la conversion.

Ensuite, les événements dont les sessions génèrent du trafic organique propre. Une conférence avec 20 talks de référence, chacun cherché par nom d'intervenant ou sujet précis, bénéficie de pages dédiées. Tout regrouper sur une page-fleuve nuit au ranking sur ces requêtes longue traîne.

Enfin, les événements récurrents hebdomadaires ou mensuels. Un cours de yoga tous les mardis pendant trois mois : une page unique ou 12 pages ? Google suggère une seule, mais l'UX et la capacité à capter « cours yoga mardi 15 mars » plaident pour des pages individuelles. [A vérifier] sur des volumes de recherche réels.

Que faut-il faire concrètement pour un événement multi-jours ?

Commence par auditer la nature de ton événement. S'il s'agit d'une expérience continue (festival, salon, séminaire) sans sessions autonomes, applique la recommandation de Google : une page, un Event Schema, des canonicals depuis toute variation d'URL (ex : /evenement?jour=2 → canonical vers /evenement).

Si ton événement propose des contenus distincts par jour, teste une approche hybride. Crée une page principale avec le Event Schema global (startDate du jour 1, endDate du dernier jour), puis des pages secondaires pour chaque session majeure, sans canonical mais avec un markup Event individuel marqué comme subEvent de l'événement parent. Google ne garantit pas que ça fonctionne mieux, mais c'est cohérent avec schema.org et l'UX.

Quelles erreurs éviter dans l'implémentation du markup Event ?

Ne mélange pas les formats de dates. Utilise ISO 8601 systématiquement (YYYY-MM-DDTHH:MM:SS+TZ). Une erreur fréquente : oublier le fuseau horaire, ce qui crée des ambiguïtés pour les événements internationaux ou diffusés en ligne.

Autre piège : déclarer un Event Schema sur plusieurs pages sans cohérence entre les propriétés. Si tu as une page par jour avec un markup Event distinct, assure-toi que les champs name, location, organizer restent identiques. Des variations dans ces propriétés font croire à Google qu'il s'agit d'événements différents, ce qui fragmente les signaux.

Comment vérifier que l'implémentation est correcte et conforme ?

Passe ton markup dans le Rich Results Test de Google, puis dans le validateur schema.org. Ces outils détectent les erreurs de syntaxe, mais pas les incohérences sémantiques. Pour ça, il faut une revue manuelle.

Surveille la Search Console section Améliorations > Événements. Google remonte les erreurs de parsing et les avertissements sur les propriétés manquantes (image, location, offers). Si tu as plusieurs pages pour un événement multi-jours, vérifie qu'une seule remonte comme « valide » si tu as canonisé — sinon, c'est que Google ignore tes canonicals.

• Vérifie que startDate précède endDate et couvre bien toute la durée de l'événement
• Ajoute une image de haute qualité (min 1200px de large) dans le markup Event
• Renseigne location avec un schema Place complet (address, geo) même pour les événements en ligne
• Si billetterie, inclus la propriété offers avec price, priceCurrency, validFrom, url
• Teste le markup dans plusieurs outils (Google Rich Results Test, schema.org validator, Bing Markup Validator)
• Implémente un monitoring des erreurs Event Schema dans Search Console pour détecter les régressions