Como implementar, testar e monitorar a diretiva unavailable_after via URL Inspection, com o passo extra de forçar recrawl para não travar no cache do Googlebot.
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↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) →, 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.
- No Search Console, cole a URL na Inspeção de URL.
- Clique em Testar URL ativa para ver o HTML renderizado como o Googlebot recebe.
- Procure a meta
robotsno HTML retornado, ou o headerX-Robots-Tagna resposta HTTP. Se for via header, vale conferir também comcurl -I https://seusite.com/paginapra 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:
- Faça a alteração da tag em produção.
- Valide no URL Inspection com Testar URL ativa (confirma o valor novo).
- 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)
Este artigo foi escrito por Sabrina Santos, colunista de SEO. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de SEO técnico e descoberta. Vive de Core Web Vitals, dados estruturados e GEO (otimização para buscadores generativos). Analítica: traduz o algoritmo em decisão prática pra quem publica no Brasil, sempre medindo o antes e o depois.
