Métadonnées contradictoires et unavailable_after : deux précisions de Google

L’essentiel

• Le 28 juillet 2026, John Mueller a déclaré que Google ne publie aucun ordre de priorité entre métadonnées contradictoires.
• Sa consigne : corriger le conflit au lieu de chercher à deviner quel signal l’emporte.
• Gary Illyes, qui parle d’une intuition, pense qu’une date unavailable_after peut être repoussée, à condition que Googlebot explore la page à nouveau.
• Selon lui, la règle ne joue que sur la sélection pour l’index.

Métadonnées en conflit : aucune hiérarchie publiée

L’échange démarre sur Bluesky le 13 juillet. Sebastián Galanternik y signale une fiche produit du site Frávega, classée en première position du bloc « Popular Products » (produits populaires) sur la requête « notebook gigabyte ». La page rendue affichait le produit en rupture de stock. Le HTML servi et les données structurées, eux, le déclaraient disponible. Il précisera plus tard que ce n’est pas son site. John Mueller avait répondu le jour même qu’il valait mieux ne pas fournir de métadonnées qui se contredisent, car « cela complique l’identification de ce qui est pertinent » (traduction), et suggérait de passer par un flux.

Le 28 juillet, Sebastián Galanternik relance : quand le flux et le balisage de la page divergent sur la disponibilité, lequel fait foi pour les fiches gratuites ? John Mueller répond qu’« il n’existe pas d’ordre de priorité défini publiquement pour réconcilier les métadonnées ». Et d’ajouter : « si vous fournissez des métadonnées contradictoires, il faut les corriger, pas chercher à savoir si cela fonctionnera malgré tout » (traduction). Les dates affichées sur une page sont, selon lui, un cas fréquent.

Nouvelle question dans la foulée, cette fois sur la date visible, la propriété dateModified et le lastmod du sitemap. Là encore, pas de classement. Ces signaux peuvent avoir « des pondérations et des filtres différents », qui « évolueront avec le temps » (traduction). Il rappelle que le web change sans cesse et que les métadonnées sont difficiles à interpréter : plus le site rend la bonne valeur facile à choisir, plus elle a de chances d’être retenue (reformulation).

Barry Schwartz, qui a relayé l’échange sur Search Engine Roundtable, prend un autre exemple : une redirection 301 de l’URL A vers l’URL B, alors que la canonique de B pointe vers A. Il s’attend à ce que la redirection l’emporte, mais c’est son hypothèse, pas une réponse de Google. Pour les directives robots, en revanche, la documentation de Google fixe une règle : la plus restrictive s’applique (nosnippet prime sur max-snippet:50). La réponse de John Mueller vise un autre cas, celui d’informations venues de sources différentes (flux, balisage, contenu visible).

unavailable_after : la nouvelle date n’est lue qu’au crawl suivant

Pour rappel, Google prend en charge la règle unavailable_after depuis juillet 2007. Placée dans la balise meta robots ou dans l’en-tête X-Robots-Tag, elle demande que la page n’apparaisse plus dans les résultats après une date et une heure données. La documentation accepte les formats courants, dont RFC 822, RFC 850 et ISO 8601. Sans date valide, la règle est ignorée. Une fois l’échéance passée, Googlebot explore l’URL beaucoup moins souvent.

La question vient de Javier Lorente Murillo, sur LinkedIn. Il gère un site de petites annonces qui compte environ 5 000 URL indexées stables et génère près de 10 000 annonces par mois, avec une durée de vie de 24 à 72 heures en général. Les utilisateurs peuvent renouveler leur annonce, ce qui obligerait à repousser la date. Son objectif : éviter une masse d’erreurs 404 et mieux gérer le budget de crawl. Il demandait si ces changements fréquents de date risquaient de pousser Googlebot à ignorer la balise.

Gary Illyes admet d’abord qu’il n’en sait rien et qu’il doit vérifier. Son intuition : repousser la date ne poserait pas de problème, mais « nous devrons explorer la page à nouveau pour “voir” la nouvelle date ». La règle n’agirait que sur la sélection pour l’index, comme un signal « vous pouvez retirer ceci maintenant » (traduction). Ce n’est donc pas une confirmation officielle.

Search Engine Roundtable pointe le risque de calendrier : si Google ne repasse pas sur la page avant l’échéance initiale, il peut la retirer à l’ancienne date. J’y ajoute une interprétation personnelle. Comme le crawl ralentit après l’échéance, une page sortie trop tôt risque d’attendre longtemps la visite qui la ferait revenir.

Usages de la règle et conflits à corriger

La règle convient aux contenus dont la fin est connue et ferme : un événement, une promotion à durée fixe, une annonce non renouvelable, un produit dont la vente s’arrête à une date prévue. Pour les offres d’emploi, la documentation JobPosting ne la cite pas. Elle prévoit trois moyens de retirer une offre expirée (une propriété validThrough passée, une page en 404 ou 410, ou la suppression du balisage JobPosting) et recommande en plus l’Indexing API pour demander le retrait de l’URL. Elle prévient aussi qu’une offre expirée traitée trop tard peut valoir une action manuelle.

Côté conflits, voici les combinaisons à contrôler en premier. Plusieurs figurent déjà dans la documentation de Google sur la canonicalisation :

• une URL canonique qui diffère de celle déclarée dans le sitemap ;
• une balise link canonique et un en-tête HTTP qui désignent deux URL différentes, ou une canonique réécrite par JavaScript ;
• une canonique vers une page d’une autre langue alors que des annotations hreflang déclarent les versions alternatives ;
• une page en noindex listée dans le sitemap, ou une redirection 301 dont la cible renvoie sa canonique vers l’URL d’origine ;
• une disponibilité ou un prix qui diffèrent entre le flux Merchant Center, le balisage Product et la page rendue ;
• une date visible, un dateModified et un lastmod qui ne concordent pas.

Ce que j’en retiens

La réponse de John Mueller coupe court à un exercice assez répandu : chercher la règle cachée qui départagerait deux signaux. Il n’en existe pas de publique, et le poids de chaque signal bouge. Le travail consiste donc à aligner les sources. Un crawl qui compare canonique, sitemap, hreflang, noindex et dates fait ressortir l’essentiel des conflits. L’outil d’inspection d’URL de la Search Console montre ensuite la canonique retenue par Google. Sur les dates, j’avais déjà relayé la position de Gary Illyes : un lastmod faux vaut moins que pas de lastmod du tout.

Je réserverais unavailable_after aux pages dont la fin est certaine. Sur des annonces de 24 à 72 heures que l’on peut prolonger, l’écart entre la mise à jour de la date et le passage de Googlebot est trop court pour s’y fier, et la réponse de Gary Illyes reste une intuition. Pour un test, mieux vaut repousser la date bien avant l’échéance, signaler la modification par un lastmod exact, puis contrôler dans la Search Console que la page a été réexplorée.