À l'heure actuelle, rien dans Schema.org ne permet à une entreprise de communiquer directement les périodes de vacances (par exemple, Noël) aux robots Google et aux autres robots d'exploration de sites Web. Il semble y avoir un numéro en cours sur le référentiel GitHub de Schema.org cependant, rien ne permet de savoir quand ou si quelque chose sera ajouté.
J'ai déjà vu deux solutions à ce problème:
Utilisez openingHoursSpecification
sans les propriétés opens
et closes
.
<p property="openingHoursSpecification" typeof="OpeningHoursSpecification">
Closed between <time datetime="2015-12-24" property="validFrom">24th of December</time> and <time datetime="2015-12-26" property="validThrough">26th of December</time>.
</p>
Cela semble être une bonne solution, mais avons-nous des preuves que Google bots va bien comprendre cela? Cela semble valider dans l'outil de test de données structurées de Google, mais cela signifie-t-il que les propriétés opens
et closed
ne sont pas requises par Google?
Utilisez openingHoursSpecification
avec les mêmes propriétés opens
et closes
.
<p property="openingHoursSpecification" typeof="OpeningHoursSpecification">
Closed between <time datetime="2015-12-24" property="validFrom">24th of December</time> and <time datetime="2015-12-26" property="validThrough">26th of December</time>.
<meta content="00:00:00" property="opens" />
<meta content="00:00:00" property="closes" />
</p>
Encore une fois, une solution intéressante, mais il semble y avoir peu ou pas de preuves que les robots d'exploration du Web comprennent correctement cela et ne le traitent pas comme un balisage incorrect. En outre, il semble un peu illogique de devoir spécifier qu'une entreprise est ouverte pendant zéro seconde.
La seule autre solution à laquelle je puisse penser consiste à utiliser les propriétés openingHoursSpecification
avec validFrom
et validThrough
pour spécifier toutes les périodes en même temps (même lorsque les heures d'ouverture par défaut sont valides).
<div property="openingHoursSpecification" typeof="OpeningHoursSpecification">
<meta content="10:00:00" property="opens" />
<meta content="18:00:00" property="closes" />
<meta content="2015-12-23" property="validThrough" />
</div>
<p>
Closed between <time datetime="2015-12-24">24th of December</time> and <time datetime="2015-12-26">26th of December</time>.
</p>
<div property="openingHoursSpecification" typeof="OpeningHoursSpecification">
<meta content="10:00:00" property="opens" />
<meta content="18:00:00" property="closes" />
<meta content="2015-12-27" property="validFrom" />
</div>
Bien sûr, cette solution est également défectueuse:
Cela nécessite potentiellement beaucoup de balisage en double.
Il utilise principalement des éléments "invisibles" meta
au lieu de marquer des données visibles, comme le recommande Google.
Alors, laquelle de ces solutions est la meilleure/la moins incorrecte? Y a-t-il une meilleure solution?
Comme vous l'avez dit, il y a un problème en suspens sur schema.org, il est donc préférable d'essayer vos propres solutions et de faire des essais pour voir si Google le détecte correctement. J'utiliserais la solution 2. Parce que cela donne des heures fermées et semble plus clair, cela ressemblait à la solution suggérée du fil schema.org https://github.com/schemaorg/schemaorg/issues/240#issuecomment- 95458846
Les dates ne sont pas un problème - les dates lisibles par machine sont une des exceptions lorsqu’on envisage l’utilisation de données non visibles et radiables par machine , selon - politiques de Google cela peut inclure des dates, des prix, des devises, etc.
Bien que la documentation officielle de Google indique qu'il faudra peut-être des mois pour récupérer les modifications, j'ai trouvé Fetch-As-Google et une attente de 2 à 3 jours au plus fonctionne pour les microdonnées et JSON-LD, par exemple dans le fichier longue liste de commentaires sur une question relative aux microdonnées schema.org vous pouvez voir que l’affiche originale tente plusieurs modifications différentes à quelques jours d’écart, avec 3 jours entre la dernière modification et la reprise par Google.