Le 27 juillet 2026, le consultant SEO indépendant Javier Lorente Murillo a publié sur LinkedIn une question technique adressée à l’équipe Search de Google, en taguant John Mueller, Gary Illyes et Martin Splitt.

Son client gère un site d’annonces qui maintient environ 5 000 URL indexées stables et publie autour de 10 000 nouvelles annonces par mois, avec une durée de vie de 24 à 72 heures. Il veut utiliser la balise unavailable_after sur ces annonces éphémères pour éviter les 404 en masse et économiser du budget de crawl.

Problème : les annonceurs peuvent prolonger leur annonce, ce qui obligerait le site à repousser la date d’expiration à la volée.

Gary Illyes, analyste chez Google, répond d’abord qu’il n’en sait rien et qu’il doit vérifier. Puis il livre une intuition : repousser la date lui semble acceptable, mais Google devra recrawler la page pour voir la nouvelle date.

Sauf que la page de référence de Google sur les balises meta robots, mise à jour le 24 mars 2026, contient une phrase qui rend cette intuition problématique. Elle précise que si vous avez utilisé la valeur d’attribut « unavailable_after » Googlebot réduit considérablement la fréquence de crawl d’une URL après la date et l’heure indiquées. Donc certes on peut repousser la date de validité et la valeur de « unavailable_after », mais cela ne sert à rien car la nouvelle date risque fort de ne pas être découverte par Google à temps pour que cela serve à quelque chose.

Conclusion : sur un inventaire qui connait beaucoup de changements, unavailable_after est structurellement inutilisable, et Google recommande par ailleurs, noir sur blanc, un autre outil pour ce cas précis.

La question qui n’avait jamais été posée en public

unavailable_after n’est pas une nouveauté. Google la prend en charge depuis juillet 2007, soit dix-neuf ans.

Sa fonction est décrite en une ligne dans la page de référence sur les balises meta robots : ne pas afficher la page dans les résultats de recherche après la date et l’heure spécifiées.

Voici la syntaxe en html :

<meta name="robots" content="unavailable_after: 2026-10-15T23:59:59+02:00">

et la version « en-tête http »

X-Robots-Tag: unavailable_after: 2026-10-15T23:59:59+02:00

A quoi cela sert : à piloter des cas d’expiration bien définis :

• Une offre d’emploi avec date de clôture légale.
• Une page d’événement.
• Un jeu-concours.
• Une promotion bornée dans le temps.

Dans tous ces cas, cette date d’expiration est connue au moment de la publication et ne bouge plus.

Le cas soumis par Lorente Murillo est différent, et c’est ce qui le rend intéressant.

Sa formulation est précise : le système pousserait dynamiquement la date d’expiration plus loin dans le futur, à la volée. Sa question portait sur le risque que Googlebot finisse par se méfier d’une date qui glisse en permanence sur la même URL, voire par ignorer la balise.

Ce n’est pas une hypothèse d’école. Les sites d’annonces, les job boards, la billetterie, les plateformes d’enchères, la disponibilité hôtelière et les catalogues à rotation rapide produisent tous des URL dont la durée de vie utile se compte en heures ou en jours, avec un mécanisme de prolongation contrôlé par un tiers.

Le problème en détails

Le tableau des règles valides publié par Google décrit unavailable_after en deux temps.

D’abord la fonction : la page n’est plus affichée après la date.

Ensuite une conséquence que presque personne ne relève, et que la couverture anglophone du fil a intégralement manquée : après la date et l’heure spécifiées, Googlebot diminue fortement la fréquence de crawl de l’URL.