Tag do Google não corta os 50% de acessos do Googlebot que terminam em 404
Site de classificados gera 10.000 anúncios por mês com validade de 24 a 72 horas sobre uma base de 5.000 URLs. Illyes diz que o Google precisa rastrear de novo.
Uma pergunta pública sobre uma diretiva de robots pouco discutida rendeu uma resposta incomumente franca de um analista do Google e expôs a distância entre o que a tag unavailable_after controla e o que operadores de sites gostariam que ela resolvesse.
Gary Illyes, analista do Google, respondeu no LinkedIn a uma pergunta técnica sobre a diretiva de robots unavailable_after admitindo não saber a resposta e, em seguida, ofereceu uma avaliação com ressalvas: empurrar a data de expiração para frente provavelmente não é problema, mas o Google precisa buscar a página de novo antes de registrar a mudança. A troca foi capturada hoje, cerca de dezoito horas depois da publicação original.
A pergunta partiu de Javier Lorente Murillo, consultor independente de SEO. Foi endereçada à equipe de Search do Google e marcou três de seus integrantes mais visíveis: John Mueller, Gary Illyes e Martin Splitt. No momento da captura, o post acumulava 28 reações e 5 comentários.
O problema: 10.000 anúncios por mês, a maioria morta em três dias
Lorente Murillo descreveu um site com descompasso estrutural entre o inventário estável e o transitório. Segundo seu post, a plataforma mantém uma base de aproximadamente 5.000 URLs indexadas enquanto gera cerca de 10.000 novos anúncios por mês. Esses anúncios têm vida útil que ele situou entre 24 e 72 horas.
A proporção importa. O volume mensal de anúncios novos equivale ao dobro de todo o índice estável, e quase toda essa massa expira em até três dias. O resultado é um padrão de rotatividade em que a esmagadora maioria das URLs que o Googlebot poderia descobrir no site terá desaparecido antes que qualquer ciclo relevante de indexação se complete.
O objetivo declarado ao recorrer à diretiva unavailable_after era duplo: evitar o que ele chamou de erros 404 em massa e administrar o crawl budget. A complicação está nas renovações. Usuários de plataformas de classificados costumam prorrogar seus anúncios, o que obrigaria o site a empurrar dinamicamente a data de expiração em URLs já rastreadas com uma data anterior.
Daí a pergunta específica: se o Googlebot trataria uma data que se desloca continuamente para frente na mesma URL como sinal para desconfiar da tag e, no limite, ignorá-la por completo.
Illyes: “não faço ideia, preciso verificar”
A resposta foi direta quanto aos próprios limites. “essa é uma ótima pergunta... não faço ideia, preciso verificar” (”that’s a great question... I have no idea, I have to check”), escreveu Illyes.
Na sequência apresentou uma hipótese de trabalho, não um comportamento documentado. “minha impressão é que não há problema em empurrar a data de unavailable_after para frente, MAS é preciso ter em mente que vamos precisar rastrear a página de novo para ‘ver’ a nova data” (”my gut feeling is that it’s fine to push forward the unavailable_after date BUT you need to keep in mind that we’ll need to crawl the page again to ‘see’ the new date”), escreveu. O comentário prossegue além do que o trecho capturado exibe, e o restante da frase aparece truncado na fonte.
A restrição operativa está nessa segunda oração. Uma diretiva embutida no código de uma página ou em seus cabeçalhos HTTP é invisível a um buscador até que o buscador busque a página. Uma data de expiração que muda em tempo real, portanto, não se propaga em tempo real. Ela se propaga no calendário de rastreamento do Google, que o site não controla.
Para uma página com vida útil de 72 horas, a questão prática passa a ser se um novo rastreamento chega a ocorrer dentro dessa janela. Quando não ocorre, o valor da tag como mecanismo de gestão de ciclo de vida se estreita bastante, porque a data que o Google guarda será com frequência a errada.
O problema das requisições HEAD
Um segundo comentário de Illyes, publicado mais adiante na conversa, fechou uma saída que parte dos operadores poderia supor disponível. Em resposta a outro participante, escreveu: “Andrew Glyntzos, raramente vemos requisições HEAD, então ainda assim faríamos o download do conteúdo” (”Andrew Glyntzos we rarely see HEAD requests so we’d still download the content”).
O método HTTP HEAD recupera os cabeçalhos de resposta sem o corpo da resposta. Em tese, um rastreador poderia consultar uma URL de forma barata, com requisições HEAD, para verificar se um cabeçalho X-Robots-Tag de expiração havia mudado, sem arcar com o custo de banda de baixar o documento inteiro. O comentário de Illyes indica que não é assim que a busca do Google costuma funcionar na prática.
A consequência é aritmética. Se cada verificação de uma data de expiração alterada exige o download completo do conteúdo, a tag não entrega redução alguma de custo de rastreamento por requisição. Ela pode apenas reduzir o número de URLs elegíveis para exibição nos resultados de busca, objetivo distinto de reduzir o que o Googlebot transfere.
Essa distinção ficou mais aguda à medida que o Google apertou as próprias restrições de busca. O PPC Land noticiou que o Google documentou um limite de 2MB para as buscas do Googlebot (em inglês) em um post no blog do Search Central de 31 de março de 2026, assinado por Illyes, ao lado da mudança de endereço dos arquivos com as faixas de IP dos rastreadores. No início do mesmo mês, Illyes e Martin Splitt explicaram que o Googlebot não é um programa autônomo(em inglês), e sim um cliente de uma plataforma interna de rastreamento compartilhada entre produtos do Google.
A metade que a tag não alcança
Lorente Murillo voltou à conversa com um comentário que redimensionou o escopo do problema. “De qualquer forma, isso resolveria apenas 50% do problema - especificamente, usuários que caem em páginas 404 (como acontece atualmente, com o error_404.html entre as 10 páginas mais vistas). Também vemos mais de 50% dos acessos do Googlebot indo para páginas 404, e temo que a tag unavailable_after não resolva isso”, escreveu.
Dois números desse comentário merecem separação.
O primeiro é a presença de um arquivo de template de erro entre as dez páginas mais vistas do site. Trata-se de uma medida de tráfego humano real chegando a becos sem saída, seja a partir de resultados de busca, de links externos, de favoritos ou da navegação interna apontando para anúncios já expirados.
O segundo é que mais da metade das requisições do Googlebot ao site resulta em respostas 404. Esse é um indicador de eficiência de rastreamento, e descreve um rastreador que gasta a maior parte da atenção em URLs que não devolvem mais conteúdo.
A diretiva unavailable_after não trata de nenhum dos dois diretamente. Ela determina se o Google deve parar de exibir uma URL nos resultados de busca a partir de determinado momento. Não altera o código de status HTTP que o servidor devolve quando um anúncio expirado é solicitado, e não remove os links para anúncios expirados hospedados em outros sites ou nas próprias páginas da plataforma.
Uma alternativa vinda do ecommerce
Andrew Glyntzos, profissional de SEO que se apresentou na conversa como tendo duas décadas de atuação na área, descreveu o tratamento de um padrão comparável em um grande site de ecommerce em que produtos e peças de reposição mudavam com frequência.
Segundo seu comentário, a abordagem adotada foi de página órfã ou de arquivo: manter a página acessível, informar que o produto não estava mais disponível e apresentar uma lista de alternativas relevantes. Algumas URLs foram marcadas como 404. Ele descreveu o resultado como gerador de alguns problemas de SEO, mas observou que as conversões ficaram acima do patamar registrado quando o site simplesmente aplicava redirecionamentos 301.
É uma troca reconhecida, não resolvida. Páginas de arquivo retêm link equity e dão ao visitante que chega um próximo passo, ao custo de um conjunto crescente de URLs indexáveis descrevendo inventário que não pode ser comprado.
O que o Google já disse sobre erros 404
A conversa reabre um tema em que a posição pública do Google tem sido consistente, ainda que lida com frequência de forma equivocada.
Em junho de 2024, Illyes apresentou uma classificação em duas partes dos erros 404 (em inglês): URLs que deveriam devolver status 200 e falham por defeito técnico, e URLs que nunca foram concebidas para devolver conteúdo. A primeira categoria pede correção. A segunda, na formulação dele, divide-se novamente entre URLs que ainda podem ser úteis a visitantes e URLs irrelevantes.
Dois meses depois, nas SEO office hours de agosto de 2024, John Mueller e Martin Splitt trataram diretamente da questão de ranqueamento, afirmando que erros 404 não afetam as posições das demais páginas de um site (em inglês). Mueller argumentou contra redirecionar páginas excluídas para conteúdo vagamente semelhante ou para a home, por degradar a experiência do visitante, e apontou para páginas 404 informativas, com redirecionamentos reservados aos casos em que existe substituto genuíno.
A documentação do Google também ficou mais específica sobre como páginas de erro são processadas. Em dezembro de 2025, a empresa esclareceu que a renderização de JavaScript pode ser ignorada em códigos de status HTTP diferentes de 200 (em inglês), incluindo respostas 404, 301, 401 e 403. A mesma atualização alertou que páginas com tag noindex no HTML inicial podem nunca ter seu JavaScript executado, o que restringe qualquer abordagem que tente adicionar ou remover diretivas de indexação pelo lado do cliente.
Esse último ponto incide sobre o caso dos classificados. Uma plataforma que renderiza o status do anúncio via JavaScript, e espera que o Google capte uma diretiva de expiração escrita dinamicamente, depende de uma etapa de renderização que pode não ser executada.
Por que isso importa além dos classificados
Inventário de alta rotatividade não se restringe a anúncios classificados. Sites de vagas, agendas de eventos, disponibilidade em viagens, venda de ingressos, plataformas de leilão e catálogos de varejo com giro rápido de estoque geram URLs cuja vida útil se mede em dias ou horas, não em meses.
Para o lado de marketing e de publishers, a troca comporta três leituras práticas.
Crawl budget não se compra por marcação. A diretiva unavailable_after opera sobre elegibilidade de exibição, e o comentário de Illyes sobre requisições HEAD indica que verificar uma data alterada continua custando uma requisição completa. Sites que esperam da tag um afinamento da carga de rastreamento depositam essa expectativa em um mecanismo desenhado para outra finalidade.
Diretivas documentadas não são necessariamente bem instrumentadas. Um analista do Google responder a uma pergunta sobre uma diretiva de robots suportada admitindo que precisaria verificar é um dado sobre quanta atenção operacional a tag recebe. A diretiva existe nas especificações do Google. Seu comportamento sob modificação rápida e repetida parece ser território não documentado.
Desperdício de rastreamento tem custo cumulativo. Metade das requisições do Googlebot a um site resolvendo em erro é um número com consequências para além da Busca do Google. A cobertura do PPC Land sobre a infraestrutura de rastreamento da empresa estabeleceu que o Googlebot opera como um consumidor de uma plataforma interna compartilhada, o que significa que a ineficiência na camada de busca alcança várias superfícies do Google. Em separado, o PPC Land documentou dados da Cloudflare sobre a razão entre rastreamento e referência de IA (em inglês), que variam de 118 rastreamentos por visitante humano a quase 50.000, indicação de quanto tráfego automatizado chega hoje a sites comerciais à margem da busca.
A conversa não produziu desfecho. Illyes disse que iria verificar. O que a troca produziu foi um enunciado mais nítido da restrição: qualquer sinal de expiração que um site escreva em uma página é apenas tão atual quanto a busca mais recente do Google por aquela página e, em inventário que expira em 24 a 72 horas, esse é um padrão exigente.
Linha do tempo
Junho de 2024 - Gary Illyes estabelece uma classificação dos erros 404 em duas categorias (em inglês), separando defeitos técnicos de URLs que nunca deveriam servir conteúdo
Agosto de 2024 - John Mueller e Martin Splitt afirmam nas SEO office hours que erros 404 não afetam o ranqueamento das demais páginas (em inglês), e desaconselham redirecionamentos indiscriminados para a home
20 de novembro de 2025 - Google migra a documentação de rastreamento para um site dedicado de infraestrutura de crawling (em inglês), cobrindo cache HTTP, protocolos de transferência e codificação de conteúdo
15 a 18 de dezembro de 2025 - Google esclarece que a renderização de JavaScript pode ser ignorada em códigos de status diferentes de 200 (em inglês) e em páginas com noindex no HTML inicial
12 de março de 2026 - Illyes e Martin Splitt explicam que o Googlebot é um cliente de uma plataforma interna central de rastreamento (em inglês), no episódio 105 do Search Off the Record
31 de março de 2026 - Google publica o post Inside Googlebot documentando o limite de 2MB por busca (em inglês) e muda de lugar os arquivos com as faixas de IP dos rastreadores
27 de julho de 2026 - Javier Lorente Murillo publica no LinkedIn a pergunta sobre datas de unavailable_after deslocadas dinamicamente em um site de classificados, marcando John Mueller, Gary Illyes e Martin Splitt
27 de julho de 2026 e hoje - Gary Illyes responde que não sabe a resposta, acrescenta que o Google precisaria rastrear a página de novo para registrar uma data nova e, em comentário separado, observa que o Google raramente emite requisições HEAD
Hoje - Conversa capturada com 28 reações e 5 comentários, entre eles o de Andrew Glyntzos descrevendo uma abordagem de página de arquivo em um grande site de ecommerce
Cobertura relacionada
Google clarifies when to fix 404 errors (em inglês) - Illyes divide as respostas 404 entre defeitos técnicos que pedem correção e URLs que nunca deveriam devolver conteúdo, um quadro diretamente aplicável a páginas de anúncios expirados.
404 Errors don’t hurt rankings, says Google Search Relations Team (em inglês) - Mueller e Splitt tratam do impacto dos 404 no ranqueamento e argumentam contra redirecionar páginas excluídas para destinos apenas vagamente relacionados.
Googlebot is not a program - Google engineers finally explain what it really is (em inglês) - Illyes e Splitt descrevem o Googlebot como um cliente de uma plataforma interna compartilhada de rastreamento, com respostas 403 e 404 tratadas como erros de cliente rotineiros, sem efeito de throttling.
Google rewrites Googlebot’s rulebook: 2MB limits, IP moves, and what crawlers really are (em inglês) - O post Inside Googlebot, de 31 de março de 2026, estabelece limites de tamanho por busca e restrições de renderização, em texto assinado por Illyes.
Google clarifies JavaScript rendering for error pages in December documentation update (em inglês) - Documentação que fixa a possibilidade de a renderização ser ignorada em respostas diferentes de 200 e em páginas com noindex no HTML inicial.
Google updates crawling infrastructure documentation with new technical details (em inglês) - Orientações sobre gestão da taxa de rastreamento, incluindo o modo como códigos de erro reduzem a taxa em todo um hostname.
Google’s secret crawl logic, finally explained in one page (em inglês) - Panorama em nove pontos sobre como o Googlebot descobre, renderiza e administra o acesso a sites, publicado em 3 de março de 2026.
Gary Illyes: the web’s JavaScript mess is an AI agent nightmare (em inglês) - Illyes sobre como a complexidade do JavaScript atrapalha a recuperação automatizada, pano de fundo para as restrições de renderização que afetam diretivas dinâmicas.
Google: Gary Illyes and Lizzi Sassman on Web Crawlers (em inglês) - Explicação de base sobre crawl budget como o conjunto de recursos que um buscador está disposto a gastar com um determinado site.
Managing faceted navigation URLs: new Google documentation (em inglês) - Orientação do Google sobre uma das fontes mais comuns de desperdício de rastreamento, cobrindo o excesso de rastreamento de conteúdo duplicado e a descoberta mais lenta de páginas novas.
Resumo
Quem: Gary Illyes, analista do Google e integrante da equipe de Search Relations, em resposta a Javier Lorente Murillo, consultor independente de SEO, em uma conversa pública no LinkedIn que também atraiu comentário do profissional de SEO Andrew Glyntzos. O post marcou John Mueller, Gary Illyes e Martin Splitt.
O quê: Uma pergunta sobre se empurrar repetidamente para frente a data de expiração de unavailable_after na mesma URL carrega consequências negativas de SEO. Illyes disse que não sabia e que precisaria verificar, apresentou a avaliação preliminar de que mover a data para frente provavelmente não é problema e afirmou que o Google precisa rastrear a página de novo para registrar a data nova. Em comentário posterior, observou que o Google raramente emite requisições HEAD, de modo que o conteúdo seria baixado integralmente de qualquer forma. Lorente Murillo acrescentou que a tag resolveria apenas metade do seu problema, citando um template de erro entre as dez páginas mais vistas do site e mais de 50 por cento dos acessos do Googlebot terminando em respostas 404.
Quando: O post original foi publicado cerca de dezoito horas antes da captura da conversa, feita hoje, com a primeira resposta de Illyes cerca de doze horas antes da captura e o comentário seguinte cerca de três horas antes.
Onde: No LinkedIn, em post público dirigido à equipe de Search do Google. O site em discussão é uma plataforma de classificados com aproximadamente 5.000 URLs indexadas estáveis e cerca de 10.000 novos anúncios gerados por mês, cada um com vida útil de 24 a 72 horas.
Por quê: A troca esclarece um limite do que a diretiva unavailable_after consegue fazer. Como a diretiva vive dentro da página, um buscador só toma conhecimento de uma data de expiração alterada ao buscar a página outra vez e, como o Google raramente usa requisições HEAD, essa busca traz consigo o download integral do conteúdo. Sites que operam inventário de alta rotatividade, incluindo portais de vagas, agendas de eventos, venda de ingressos e catálogos de varejo com giro rápido, enfrentam a mesma lacuna estrutural entre a eficiência de rastreamento que desejam e o controle de exibição que a diretiva de fato oferece.