Peut-on repousser la date d'expiration d'une page avec unavailable_after ?

Qu'est-ce que la balise unavailable_after exactement ?

La balise meta unavailable_after permet d'indiquer à Google qu'une page ne sera plus pertinente après une date précise. Elle se place dans le head HTML avec ce format : <meta name="unavailable_after" content="2025-12-31">.

Concrètement ? Google indexe normalement la page jusqu'à la date spécifiée, puis la traite comme si elle portait un noindex. La page disparaît progressivement des résultats de recherche. C'est particulièrement adapté aux contenus événementiels, offres promotionnelles limitées dans le temps, ou annonces d'emploi avec date de clôture.

Cette date peut-elle vraiment être modifiée en cours de route ?

Oui, et c'est précisément ce que confirme Mueller. Si vous changez la date dans le code HTML, Google prendra en compte la nouvelle valeur dès le prochain crawl. Ce n'est pas figé à la première détection.

Prenons un exemple concret : vous avez publié une offre d'emploi avec une date de clôture au 15 mars. Vous prolongez le recrutement jusqu'au 30 avril. En mettant à jour la balise avec la nouvelle date, Google ajustera automatiquement la fenêtre d'indexation — pas besoin de supprimer et recréer la page.

Que se passe-t-il exactement après la date d'expiration ?

Google traite la page comme noindex après la date indiquée, et ce même sans recrawl. C'est un point crucial : vous n'avez pas besoin que Googlebot repasse pour que la désindexation s'opère. Le moteur conserve la date en mémoire et applique la directive de façon automatique.

Cette mécanique soulève une question importante pour les praticiens : combien de temps exactement faut-il pour que la page sorte de l'index ? Google ne donne pas de délai précis. D'expérience terrain, on observe généralement une disparition progressive sur quelques jours à quelques semaines, variable selon l'autorité du site et la fréquence de crawl habituelle.

• La balise unavailable_after indique une date d'expiration de pertinence pour une page
• La date peut être mise à jour dynamiquement — Google prendra en compte la nouvelle valeur au prochain crawl
• Après expiration, la page est traitée comme noindex même sans recrawl
• La désindexation progressive s'opère sur quelques jours à quelques semaines selon le site
• Cas d'usage privilégiés : événements, offres limitées dans le temps, annonces d'emploi, contenus saisonniers

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, globalement. Les tests menés sur des sites gérant des contenus temporaires à forte volumétrie (sites d'événements, jobboards, e-commerce avec ventes flash) confirment que Google respecte effectivement la balise unavailable_after. Les pages disparaissent bien de l'index après la date spécifiée.

Ce qui est nouveau ici, c'est la confirmation explicite que la date peut être modifiée en cours de route. Jusqu'à présent, beaucoup de SEO évitaient de toucher à cette balise par crainte que Google ne prenne en compte que la première valeur détectée. Mueller lève cette ambiguïté — et c'est une bonne nouvelle pour la gestion dynamique des contenus.

Quelles nuances faut-il apporter à cette déclaration ?

Premier point : la désindexation automatique sans recrawl est une affirmation forte. Sur le terrain, on constate que la vitesse de désindexation dépend énormément de l'autorité du domaine et de la fréquence de crawl habituelle. Un site crawlé quotidiennement verra ses pages expirées disparaître plus vite qu'un site crawlé toutes les deux semaines. [A vérifier] : Google maintient-il vraiment un système de rappel automatique pour toutes les dates unavailable_after, ou s'appuie-t-il aussi sur le recrawl pour déclencher la désindexation ?

Deuxième nuance : Mueller ne précise pas ce qui se passe si vous supprimez complètement la balise après l'avoir ajoutée. La page redevient-elle indexable normalement ? D'expérience, oui — mais avec un délai variable selon le recrawl. Ce flou peut créer des situations ambiguës si vous changez de stratégie en cours de route.

Dans quels cas cette balise n'est-elle pas la meilleure solution ?

La balise unavailable_after ne convient pas aux contenus que vous souhaitez archiver tout en gardant accessibles. Si vous voulez qu'une page reste en ligne pour les utilisateurs directs mais sorte des résultats de recherche, un simple noindex classique est plus explicite et réversible.

Autre cas problématique : les contenus récurrents annuels. Si vous organisez un festival chaque année avec une nouvelle édition sur la même URL, unavailable_after devient contre-productif. Vous devrez mettre à jour la date chaque année, et risquez des ratés. Mieux vaut une architecture avec URLs distinctes par édition et une page mère permanente.

Que faut-il faire concrètement pour exploiter cette balise ?

Premièrement, identifiez les types de contenus temporaires sur votre site qui bénéficieraient de cette mécanique. Offres d'emploi avec date de clôture, événements avec date de fin, promotions limitées dans le temps, contenus saisonniers — tous ces cas sont des candidats naturels.

Deuxièmement, implémentez un système de gestion dynamique de la balise. Si vous prolongez un événement ou une offre, la date doit être mise à jour automatiquement dans le code HTML. Sur un CMS, cela passe généralement par un champ de date d'expiration dans l'interface de création de contenu, qui génère la balise meta en frontend. Évitez absolument les mises à jour manuelles page par page — c'est ingérable à l'échelle.

Quelles erreurs éviter absolument avec unavailable_after ?

Erreur numéro un : définir une date d'expiration trop courte sur des contenus qui ont besoin de temps pour se positionner. Si vous lancez un événement dans 3 mois avec une date d'expiration dans 3 mois et 2 jours, Google n'aura pas le temps de crawler, indexer et positionner la page correctement. Donnez-vous une marge confortable — la date d'expiration devrait être au moins 2-3 semaines après la fin réelle de pertinence du contenu.

Erreur numéro deux : utiliser unavailable_after comme solution de contournement pour éviter le duplicate content. Certains SEO pensent pouvoir publier des contenus similaires avec des dates d'expiration échelonnées pour éviter la cannibalisation. Mauvaise idée : Google voit toutes les pages simultanément avant leur expiration, et le duplicate reste un problème. Si vous avez du duplicate structurel, réglez-le avec des canonicals, pas avec des dates d'expiration artificielles.

Comment vérifier que la balise fonctionne correctement sur mon site ?

Contrôlez d'abord que la balise est bien présente dans le HTML rendu côté client. Si votre site utilise du JavaScript pour générer le contenu, assurez-vous que la balise est injectée avant que Googlebot ne prenne son snapshot. Un test rapide avec l'outil d'inspection d'URL dans Search Console vous confirmera ce que Google voit réellement.

Ensuite, suivez la courbe de désindexation sur un échantillon de pages expirées. Utilisez l'opérateur site: dans Google pour vérifier manuellement, ou mieux : intégrez un monitoring automatisé qui vérifie l'indexation via l'API Search Console. Si des pages restent indexées plusieurs semaines après leur date d'expiration, c'est le signe d'un problème — soit la balise n'est pas lue correctement, soit le crawl est trop rare.

• Identifier les contenus temporaires candidats à unavailable_after (événements, offres, annonces)
• Implémenter un système de gestion dynamique de la balise via le CMS
• Définir des dates d'expiration avec une marge de sécurité (2-3 semaines après la fin réelle)
• Vérifier la présence de la balise dans le HTML rendu (test Search Console)
• Monitorer la désindexation effective des pages expirées
• Documenter la stratégie pour éviter les mises à jour manuelles hasardeuses