Durante a madrugada

Às 3h da manhã, horário do Pacífico, meu site de produção está servindo mais requisições do que em qualquer momento do horário comercial. Não para usuários. Para bots.

O Googlebot está rastreando 21.000 páginas. O Bingbot está rastreando 10.000. Meu nightcheck completo está processando 15.000 posts de blog e páginas de empresas. Um warm pass está aquecendo o cache de borda do Cloudflare para o tráfego do dia seguinte. Juntos, os processos noturnos tocam mais páginas do que todos os visitantes humanos combinados.

O site que eu construo durante o dia não é o site que mais importa. O site que mais importa é o que os crawlers veem às 3h da manhã.

O censo de rastreamento

Todo dia eu executo um censo de rastreamento que conta o que os bots viram nas últimas 24 horas. O censo usa a API de analytics do Cloudflare filtrada por user agent. Os números contam uma história sobre o que os mecanismos de busca valorizam:

Google:     21,463  (67%)
Bing:       10,620  (33%)
Combined:   32,083

Jobs:       16,111  (50% of all crawls)
Blog:       298
Locale:     1,233
Programmatic: 257
Companies:  14

Vagas consomem metade do orçamento de rastreamento. O Googlebot rastreia 10.654 páginas de vagas por dia. O sitemap de vagas não tem limite. Toda vaga elegível está incluída. A alocação do orçamento de rastreamento me diz o que o Google considera o conteúdo de maior valor no site.

Posts de blog recebem 298 rastreamentos por dia, apesar de serem o conteúdo de maior qualidade. A proporção de investimento em rastreamento (vagas 50x mais que blog) não corresponde ao investimento em conteúdo (blog exige 100x mais esforço por página do que vagas). Mecanismos de busca rastreiam o que podem indexar em escala, não o que exigiu mais esforço para produzir.

Empresas recebem 14 rastreamentos por dia, apesar de terem mais de 7.000 páginas no sitemap. Isso é um problema de inanição do orçamento de rastreamento: as páginas de vagas consomem tanto orçamento que as páginas de empresas mal são descobertas. Os dados noturnos revelaram esse problema. Sem o censo, eu não saberia que 7.000 páginas de empresas são essencialmente invisíveis para os crawlers.

O que o 410 revela

O censo rastreia códigos de status HTTP. O status mais interessante é o 410: Gone.

Google 410s:  7,614  (35.5% of crawls)
Bing 410s:    4,494  (42.3% of crawls)

Mais de um terço de todas as requisições de crawlers atinge páginas de vagas expiradas que retornam 410. São vagas que existiam quando o crawler as descobriu pela primeira vez, foram indexadas e desde então foram removidas. O 410 diz ao crawler “esta página existiu, mas foi permanentemente removida, pare de requisitá-la.”

A taxa de 410 está caindo. Na semana passada era 8.858 para o Google. Esta semana é 7.614. Os crawlers estão aprendendo. A cada dia, o número de requisições fantasma diminui conforme os mecanismos de busca atualizam seus índices. Porém, o aprendizado é lento. A taxa de 410 do Bing (42,3%) é maior que a do Google (35,5%) porque o Bing é mais lento para processar sinais de remoção.

A tendência do 410 é o sinal noturno mais claro. Ela me diz a velocidade com que os mecanismos de busca estão convergindo para o estado atual do site. Uma taxa de 410 crescente significa que estou removendo conteúdo mais rápido do que os crawlers conseguem se adaptar. Uma taxa de 410 decrescente significa que o índice está alcançando. O equilíbrio é zero 410s, o que significa que toda página que o crawler requisita ainda existe.

O problema do 524

O Cloudflare retorna 524 quando o servidor de origem não responde dentro da janela de timeout. Em um dia de deploy intenso (87 commits), o censo mostrou:

Google 524s:  68  (0.3%)
Bing 524s:    0

Sessenta e oito timeouts de origem em 24 horas. Cada um significa que o Googlebot requisitou uma página, o Cloudflare encaminhou a requisição para o Railway, e o Railway não respondeu a tempo. A causa mais provável foram reinícios dos workers do Railway durante deploys frequentes. Cada deploy reinicia a aplicação, criando uma breve janela onde as requisições expiram.

Para 0,3% dos rastreamentos, o Google viu um site quebrado. Os erros 524 não apareceram em nenhum log da aplicação porque a aplicação não estava rodando quando eles ocorreram. O erro existia apenas no espaço entre o Cloudflare e o Railway, visível apenas através do censo de rastreamento.

Na manhã seguinte, a contagem de 524 caiu para zero. Os deploys haviam parado. Os workers estavam estáveis. Os dados noturnos confirmaram que o problema era rotatividade transitória de deploys, não um problema estrutural.

O warm pass

Antes dos crawlers chegarem, o warm pass é executado. Ele busca cada post de blog, cada variante de locale e 50 páginas de empresas através do cache de borda do Cloudflare. O objetivo é garantir que, quando o Googlebot acessar uma página, receba uma resposta em cache em vez de esperar por uma renderização na origem.

A diferença importa. Um post de blog em cache retorna em 80ms. Um post de blog sem cache leva 1,5 segundo da origem. O Googlebot tem um orçamento de taxa de rastreamento medido em requisições por segundo. Respostas mais rápidas significam mais páginas rastreadas na mesma janela. Um cache aquecido dobra a cobertura efetiva de rastreamento.

O warm pass é invisível para os usuários. Nenhum visitante humano se beneficia de um post de blog cacheado às 2h da manhã. Contudo, o warm pass determina se o Googlebot descobre 300 posts de blog ou 600 em sua janela noturna. O impacto no SEO é real, mesmo que nenhum humano veja o mecanismo.

O que a madrugada revela

Toda manhã eu leio os logs noturnos. O padrão é o mesmo: majoritariamente verde, algumas anomalias, uma ou duas coisas que valem investigar. O ritmo é entediante. O valor está no ritmo entediante.

Uma madrugada entediante significa que os deploys não quebraram nada, os crawlers encontraram o que esperavam, o cache está funcionando e o site está pronto para o tráfego do dia seguinte. Uma madrugada interessante significa que algo mudou: um novo padrão de erro, uma regra de cache que parou de funcionar, uma mudança no orçamento de rastreamento que indica uma alteração no sinal de ranking.

O censo de rastreamento me mostrou que 7.000 páginas de empresas são invisíveis para o Google. Nenhuma métrica diurna teria revelado isso. Analytics de usuários mostram zero tráfego em páginas de empresas, o que eu atribuía à baixa demanda. O censo mostrou zero rastreamentos em páginas de empresas, o que significa que o Google nem sequer avaliou as páginas. O problema não é demanda. O problema é descoberta.

A análise do 524 me mostrou que deploys no Railway criam janelas de timeout de origem que o Googlebot atinge. Nenhum monitoramento de aplicação teria revelado isso porque a aplicação não está rodando durante o timeout. O problema existe na lacuna de infraestrutura entre o deploy e a disponibilidade.

A tendência do 410 me mostrou que o Bing processa sinais de remoção 20% mais lentamente que o Google. Isso importa para SEO: páginas de vagas expiradas permanecem no índice do Bing por mais tempo, potencialmente servindo resultados desatualizados para usuários que buscam em superfícies alimentadas pelo Bing (DuckDuckGo, Yahoo).

Cada uma dessas descobertas veio dos dados noturnos. O dia te mostra o que os usuários fazem. A madrugada te mostra o que a infraestrutura faz quando você não está olhando. Ambos importam. A madrugada importa mais para SEO.

FAQ

Como você executa o censo de rastreamento?

O censo usa a API de analytics GraphQL do Cloudflare (httpRequestsAdaptiveGroups) filtrada por padrões de user agent (%Googlebot% e %bingbot%). Ele categoriza páginas por prefixo de caminho de URL e agrega códigos de status. O script roda em 30 segundos e produz uma comparação lado a lado do comportamento de rastreamento do Google e do Bing.

Por que não usar o Google Search Console para dados de rastreamento?

O Google Search Console reporta estatísticas de rastreamento com um atraso de 2-3 dias e granularidade limitada. O censo do Cloudflare é em tempo real (últimas 24 horas) e inclui códigos de status, categorias de conteúdo e status de cache que o GSC não reporta. O GSC é útil para tendências. O censo é útil para decisões operacionais.

O warm pass aumenta os custos do Cloudflare?

Não. Os caches do Cloudflare são populados por qualquer requisição, independentemente da origem. O warm pass usa requisições HTTP padrão que contam contra a cota normal de requisições. No plano gratuito, não há limite de requisições para respostas em cache. As requisições de origem durante o warm pass contam contra a largura de banda do Railway, mas com 15.000 páginas com média de 50KB cada, o total é aproximadamente 750MB por warm pass.

E se os crawlers mudarem o comportamento?

O censo captura o que quer que os crawlers façam, independentemente de mudanças. Uma alteração no padrão de rastreamento (mais páginas de vagas, menos páginas de blog) aparece imediatamente no próximo censo. Os dados de tendência ao longo dos dias revelam se a alteração é uma anomalia pontual ou uma mudança sustentada.

Fontes

Este artigo se baseia em dados diários do censo de rastreamento coletados via API GraphQL do Cloudflare desde março de 2026. Ferramenta do censo: ~/Projects/Utility/crawl_census.py. Ferramenta de nightcheck: ~/.claude/skills/nightcheck/.