Verificação de Bots nos Logs do Servidor

Qualquer cliente consegue enviar uma user agent de Googlebot, e na maioria dos sites públicos uma fatia significativa dos acessos que dizem sê-lo são scrapers, ferramentas de monitorização e crawlers de IA a usar o nome emprestado. Trabalho de crawl budget construído sobre um log não verificado já está errado antes de a análise começar, e as regras de firewall escritas a partir dele bloqueiam as coisas erradas. Isto aplica-se sempre que os logs são a prova, e sempre antes de alguém bloquear um crawler na edge.

O ficheiro da competência

---
name: server-log-bot-verification
description: Use quando uma análise de rastreio, um pico de largura de banda ou uma proposta para bloquear um crawler assentam em linhas de log que dizem Googlebot, e ninguém verificou se eram mesmo.
---

# Verificação de Bots nos Logs do Servidor

Qualquer cliente consegue enviar uma user agent de Googlebot, e na maioria dos sites públicos uma fatia significativa dos acessos que dizem sê-lo são scrapers, ferramentas de monitorização e crawlers de IA a usar o nome emprestado. Trabalho de crawl budget construído sobre um log não verificado já está errado antes de a análise começar, e as regras de firewall escritas a partir dele bloqueiam as coisas erradas. Isto aplica-se sempre que os logs são a prova, e sempre antes de alguém bloquear um crawler na edge.

## O que precisa primeiro

- Logs de acesso em bruto com IP, user agent, estado, bytes e timestamp, no mínimo 14 dias e sem amostragem
- A possibilidade de fazer consultas de DNS inverso e directo a partir do host dos logs, ou os intervalos de IP publicados para os crawlers que lhe interessam
- robots.txt mais quaisquer regras de bots já activas no CDN ou no WAF
- Uma lista dos crawlers que importam comercialmente, mantendo pesquisa e assistentes de IA em separado

## Método

1. Agrupe os pedidos por string de user agent distinta, com contagens e bytes. É ordenar primeiro pela identidade declarada que torna a falsificação visível.
2. Verifique cada acesso que diz ser de um crawler de pesquisa por DNS inverso sobre o IP, depois resolva o hostname devolvido no sentido directo e confirme que aponta de volta para o mesmo IP. Onde não haja DNS inverso, compare com o ficheiro de intervalos de IP publicado pelo operador, obtido de novo em vez de recordado.
3. Marque cada pedido como verificado, não verificado ou outro, e guarde o conjunto não verificado em vez de o apagar. É o seu retrato de scraping e de carga, e é o único sítio onde um impostor se vê.
4. Volte a calcular a frequência de rastreio, a profundidade de rastreio e a distribuição de estados apenas sobre o segmento verificado. Todas as conclusões sobre crawl budget saem deste segmento e de mais nenhum.
5. Quantifique o que o tráfego não verificado custa de facto em tempo de resposta na origem, taxa de 5xx sob carga e largura de banda. Aplique limitação de débito quando a origem ainda possa ser uma ferramenta de que alguém depende, e reserve o bloqueio puro e simples para volume que esteja demonstravelmente a prejudicar a origem.
6. Decida os crawlers de IA e de treino em separado dos crawlers de pesquisa, e ponha a razão por escrito. Isto é genuinamente contestado: permiti-los compra visibilidade em respostas de assistentes que pode nunca gerar um clique, bloqueá-los protege conteúdo que está a ser usado sem contrapartida, e nenhuma das posições está fechada.
7. Repita passados 30 dias. Os impostores mudam de user agent, os crawlers legítimos mudam de intervalos de IP, e uma verificação feita uma só vez degrada-se numa falsa sensação de log limpo.

## O que isto produz

Um segmento de log com crawlers verificados, uma decisão de permitir, limitar ou bloquear por crawler com a razão declarada, e o tráfego não verificado remanescente quantificado em pedidos e largura de banda.

## Onde isto corre mal

- Verificar pela user agent, ou contra um ficheiro de intervalos de IP descarregado há meses, deixando um scraper dentro dos seus números de crawl budget e fora dos seus limites de débito
- Bloquear no WAF antes de tentar um Disallow no robots.txt, o que transforma um crawler que teria obedecido a uma regra num caudal de 403 que agora tem de explicar
- Amostrar um dia em cada sete, já que o rastreio chega em rajadas e um dia amostrado é ou só rajada ou nenhuma
- Ler uma string de Googlebot vinda de um intervalo de alojamento cloud como prova de interferência, quando emuladores e ferramentas de teste de terceiros enviam legitimamente a mesma string

---

Da biblioteca de competências da QuQi - https://www.quqi.io/pt/skills/server-log-bot-verification

O que precisa primeiro

• Logs de acesso em bruto com IP, user agent, estado, bytes e timestamp, no mínimo 14 dias e sem amostragem
• A possibilidade de fazer consultas de DNS inverso e directo a partir do host dos logs, ou os intervalos de IP publicados para os crawlers que lhe interessam
• robots.txt mais quaisquer regras de bots já activas no CDN ou no WAF
• Uma lista dos crawlers que importam comercialmente, mantendo pesquisa e assistentes de IA em separado

Método

1. 01 Agrupe os pedidos por string de user agent distinta, com contagens e bytes. É ordenar primeiro pela identidade declarada que torna a falsificação visível.
2. 02 Verifique cada acesso que diz ser de um crawler de pesquisa por DNS inverso sobre o IP, depois resolva o hostname devolvido no sentido directo e confirme que aponta de volta para o mesmo IP. Onde não haja DNS inverso, compare com o ficheiro de intervalos de IP publicado pelo operador, obtido de novo em vez de recordado.
3. 03 Marque cada pedido como verificado, não verificado ou outro, e guarde o conjunto não verificado em vez de o apagar. É o seu retrato de scraping e de carga, e é o único sítio onde um impostor se vê.
4. 04 Volte a calcular a frequência de rastreio, a profundidade de rastreio e a distribuição de estados apenas sobre o segmento verificado. Todas as conclusões sobre crawl budget saem deste segmento e de mais nenhum.
5. 05 Quantifique o que o tráfego não verificado custa de facto em tempo de resposta na origem, taxa de 5xx sob carga e largura de banda. Aplique limitação de débito quando a origem ainda possa ser uma ferramenta de que alguém depende, e reserve o bloqueio puro e simples para volume que esteja demonstravelmente a prejudicar a origem.
6. 06 Decida os crawlers de IA e de treino em separado dos crawlers de pesquisa, e ponha a razão por escrito. Isto é genuinamente contestado: permiti-los compra visibilidade em respostas de assistentes que pode nunca gerar um clique, bloqueá-los protege conteúdo que está a ser usado sem contrapartida, e nenhuma das posições está fechada.
7. 07 Repita passados 30 dias. Os impostores mudam de user agent, os crawlers legítimos mudam de intervalos de IP, e uma verificação feita uma só vez degrada-se numa falsa sensação de log limpo.

O que isto produz

Um segmento de log com crawlers verificados, uma decisão de permitir, limitar ou bloquear por crawler com a razão declarada, e o tráfego não verificado remanescente quantificado em pedidos e largura de banda.

Onde isto corre mal

• Verificar pela user agent, ou contra um ficheiro de intervalos de IP descarregado há meses, deixando um scraper dentro dos seus números de crawl budget e fora dos seus limites de débito
• Bloquear no WAF antes de tentar um Disallow no robots.txt, o que transforma um crawler que teria obedecido a uma regra num caudal de 403 que agora tem de explicar
• Amostrar um dia em cada sete, já que o rastreio chega em rajadas e um dia amostrado é ou só rajada ou nenhuma
• Ler uma string de Googlebot vinda de um intervalo de alojamento cloud como prova de interferência, quando emuladores e ferramentas de teste de terceiros enviam legitimamente a mesma string

Use esta skill na sua própria IA

O ficheiro é markdown simples, com o nome e o gatilho no frontmatter. Quando um assistente consegue carregar skills sozinho, é esse frontmatter que lê para decidir que esta se aplica.

Mais em SEO técnico