unavailable_after: guia prático para expirar conteúdo no Google sem furos

Toda vez que uma promoção, um evento ou uma vaga tem prazo, aparece a mesma dúvida: como fazer o Google parar de mostrar aquela URL na data certa, sem precisar deletar a página nem despejar noindex cedo demais? A resposta é a diretiva unavailable_after, e neste tutorial eu mostro como implementei, testei e, principalmente, o tropeço que quase me fez achar que ela estava quebrada.

O que a diretiva faz (e o que ela não faz)

Segundo a documentação do Google Search Central, unavailable_after: [data/hora] diz ao Google para não mostrar a página nos resultados após a data especificada. A página continua no ar, continua rastreável, continua com index normal até o momento marcado. Não é um noindex agendado no sentido estrito: é uma regra de exibição com validade.

Dois detalhes que a fonte deixa explícitos e que valem ouro:

• A data aceita formatos amplamente adotados, incluindo RFC 822, RFC 850 e ISO 8601. Se a data for inválida, a regra é simplesmente ignorada.
• Depois da data, o Googlebot reduz consideravelmente a taxa de rastreio da URL. Guarde isso, porque é a origem da armadilha que explico no fim.

Implementação: meta tag ou header

Para páginas HTML, a forma mais simples é a meta tag no :

<meta name="robots" content="unavailable_after: 2025-12-31T23:59:59-03:00">

Usei ISO 8601 com fuso -03:00 (horário de Brasília) de propósito. Data sem fuso vira aposta: você não sabe se o Google vai assumir UTC ou outra coisa, e num Black Friday que vira as 23h59 isso importa.

Para recursos não-HTML (um PDF de edital, por exemplo) ou quando você quer aplicar a regra no servidor, use o header X-Robots-Tag. No Apache:

<Files "vaga-dev-junior.html">
Header set X-Robots-Tag "unavailable_after: 2025-12-31T23:59:59-03:00"
</Files>

No NGINX:

location = /vagas/vaga-dev-junior.html {
 add_header X-Robots-Tag "unavailable_after: 2025-12-31T23:59:59-03:00";
}

A fonte mostra que dá pra combinar diretivas no mesmo header, separadas por vírgula ou em headers múltiplos. Então nada impede algo como X-Robots-Tag: max-image-preview:large, unavailable_after: ... na mesma resposta.

Alerta de robots.txt: a documentação é taxativa. Regras de indexação e exibição só são lidas quando a URL é rastreada. Se você bloquear a página no robots.txt, o Google nunca vê o unavailable_after e a regra é ignorada. Bloqueio de crawl e diretiva de exibição são mutuamente exclusivos aqui.

Testando com o URL Inspection

Depois de subir, não confie no deploy: confirme que o Googlebot enxerga a tag.

1. No Search Console, cole a URL na Inspeção de URL.
2. Clique em Testar URL ativa para ver o HTML renderizado como o Googlebot recebe.
3. Procure a meta robots no HTML retornado, ou o header X-Robots-Tag na resposta HTTP. Se for via header, vale conferir também com curl -I https://seusite.com/pagina pra ver o header cru.

Se a tag não aparece no teste ao vivo, o problema é entrega (cache de CDN, regra de servidor que não bateu, ou a página não estar realmente com a tag) e não interpretação do Google.

A armadilha do valor travado no cache

Aqui está o tropeço que me custou algumas horas. Publiquei uma promoção com a data certa, validei no URL Inspection, tudo lindo. Semanas depois, precisei estender o prazo e troquei a data na tag. E o conteúdo sumiu na data antiga mesmo assim.

O motivo está escondido naquela frase da documentação: após a data, o Googlebot reduz muito o rastreio da URL. Ou seja, se o Google já processou a versão antiga e a data expirou, ele não volta com pressa pra ver que você mudou o valor. Ele opera com base no último rastreio, e esse rastreio ficou "travado" na data velha.

A solução é forçar o recrawl assim que você alterar a data:

1. Faça a alteração da tag em produção.
2. Valide no URL Inspection com Testar URL ativa (confirma o valor novo).
3. Clique em Solicitar indexação para empurrar a URL de volta pra fila de rastreio.

A lição prática: qualquer mudança em unavailable_after depois da data original (ou perto dela) precisa de recrawl manual. Antes da data, o rastreio normal costuma pegar a mudança sozinho, mas eu solicito indexação de qualquer jeito quando o prazo é curto.

Como medir se funcionou

Monitore de duas formas. Na inspeção de URL, cheque o status de indexação depois da data: a página deve deixar de estar "nos resultados". No relatório de Desempenho, filtre pela URL e acompanhe impressões caindo para zero após a data marcada. Se as impressões persistirem dias depois, é sintoma clássico do cache travado, volte e force o recrawl.

unavailable_after é engenharia, não mágica: entrega correta, data com fuso, sem bloqueio de robots.txt e recrawl quando muda. Com esses quatro pontos, conteúdo com prazo some na hora certa sem você precisar torcer.

Fonte: Google Search Central — Robots Meta Tag (unavailable_after)