Ler um access log em 30 minutos: o que os robots de IA fazem realmente no seu site

Nenhum painel diz a um editor se o ChatGPT, o Claude ou a Perplexity leem as suas páginas. A Search Console só cobre o Google, e os motores generativos não fornecem nada. A única fonte que existe é o registo dos pedidos do servidor, o access log, que qualquer alojamento produz e que quase ninguém abre. Em meia hora, com as ferramentas presentes em qualquer servidor Linux, lê-se ali quem vem, para fazer o quê, e o que o servidor lhe respondeu. Eis o método que aplicamos, etapa a etapa, com os comandos. Como se reparte a meia hora: cinco minutos para a extração, cinco para a contagem por robot, dez para a verificação dos endereços, cinco para os códigos de resposta, cinco para os caminhos e a cadência.

Todos os comandos que se seguem pressupõem um log em formato combined e correm sobre o ficheiro extraído na etapa 1. Usam apenas grep, awk, sort e uniq.

O que contém uma linha

Um access log em formato combinado, o do Apache e do nginx por defeito, contém uma linha por pedido. Cada linha dá, por ordem: o endereço IP do cliente, a data e a hora, o método e o caminho pedidos, o código de resposta, o tamanho enviado, o referer e o user-agent. Para a análise dos robots, contam quatro campos:

Primeira verificação, antes de qualquer análise: o endereço IP registado é o do visitante ou o de um intermediário? Por trás de um CDN ou de um proxy, o servidor vê o endereço do intermediário, a menos que esteja configurado para ler o cabeçalho que transporta o endereço de origem. Se todos os pedidos parecerem vir de algumas dezenas de endereços, a etapa de verificação descrita mais abaixo não será possível, e é preciso corrigir a configuração antes de continuar. Descrevemos esta armadilha em «O que a firewall esconde dos seus logs».

Etapa 1: isolar o período e os robots de IA

Trabalha-se sobre um período completo, sete dias no mínimo, porque os robots de IA não passam todos os dias e as conclusões tiradas de vinte e quatro horas são quase sempre falsas. Extraem-se depois as linhas cujo user-agent contém um dos tokens publicados pelos fornecedores: GPTBot, ChatGPT-User, OAI-SearchBot para a OpenAI; ClaudeBot, Claude-User, Claude-SearchBot para a Anthropic; PerplexityBot e Perplexity-User para a Perplexity; o Google-Extended não aparece nos logs, já que é um token de robots.txt e não um robot. As listas de referência são as da OpenAI, da Anthropic e da Perplexity.

Um filtro grep sobre estes tokens, dirigido para um ficheiro de trabalho, chega. Num meio de comunicação de dimensão média, obtêm-se de algumas centenas a alguns milhares de linhas por semana.

zcat -f access.log* \
  | grep -E 'GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User' \
  > ia.log

Etapa 2: contar por robot e por papel

Cada fornecedor opera vários robots que não fazem a mesma coisa, e essa é a distinção mais útil de toda a análise. Um robot de treino recolhe páginas para modelos futuros. Um robot de pesquisa constrói um índice para responder a perguntas. Um robot a pedido vai buscar uma página para uma pessoa que faz uma pergunta ao assistente. Detalhámos os papéis e os tokens em «robots.txt e IA».

Contam-se então as linhas por user-agent e agrupam-se em três colunas: treino, pesquisa, agente de utilizador. O resultado lê-se assim:

• Pedidos de treino sozinhos significam que o site é recolhido, mas nada diz que é citado.
• Pedidos de pesquisa indicam que o site está indexado pelo motor generativo, condição necessária para ser citado.
• Os pedidos de agente de utilizador são o sinal mais valioso: cada um corresponde a uma pergunta de utilizador para a qual o assistente foi buscar esta página.

grep -oE 'GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User' ia.log \
  | sort | uniq -c | sort -rn

Etapa 3: verificar que os robots são autênticos

Um user-agent declara-se livremente. Qualquer script se pode apresentar como GPTBot. Antes de contar, verifica-se que os endereços IP pertencem às gamas publicadas por cada fornecedor: a OpenAI, a Anthropic e a Perplexity publicam ficheiros de gamas, e a Google documenta a verificação dos seus robots por reverse DNS. Extraem-se os endereços distintos por user-agent, comparam-se com as gamas, e afasta-se o que não figura nelas. O método completo, com as suas armadilhas, está em «Um robot é mesmo quem diz ser?».

Encontramo-los na maioria dos sites que auditamos: pedidos que se declaram Googlebot ou GPTBot a partir de endereços que não pertencem nem à Google nem à OpenAI. Não temos uma volumetria publicável para lhes associar; o teste, esse, cabe num comando. Contar sem verificar é arriscar medir scrapers disfarçados.

# os endereços distintos de um robot, a confrontar com as gamas publicadas
awk '/GPTBot/ {print $1}' ia.log | sort -u

Etapa 4: ler os códigos de resposta

Para cada robot autêntico, repartem-se os códigos de resposta. O quadro esperado num site saudável é quase todo em 200, com alguns 304 se o servidor trata os pedidos condicionais, e alguns 404 em URL retirados. Três anomalias merecem uma ação:

Uma nota sobre as recusas: um 403 devolvido pelo servidor de origem aparece no log. Um 403 devolvido pelo CDN não aparece, já que o pedido nunca chegou. Um log sem erro nenhum não é, portanto, a prova de que nenhum pedido é recusado.

# o código de resposta é o 9.º campo do formato combined
awk '/GPTBot/ {print $9}' ia.log | sort | uniq -c | sort -rn

Etapa 5: ver que páginas são lidas

Muitos editores param antes desta etapa, que é justamente a que mais ensina. Contam-se, para cada robot de pesquisa e cada agente de utilizador, os caminhos pedidos, e comparam-se com a lista das páginas publicadas. A contagem responde a perguntas que nenhuma outra ferramenta decide:

1. Que páginas nunca são lidas? Um artigo publicado há dois meses que nenhum robot de pesquisa pediu está provavelmente fora do sitemap, ou não é alcançável por uma ligação.
2. Que páginas são lidas pelos agentes de utilizador? São aquelas que os assistentes citam realmente. A comparação com as páginas que se gostaria de ver citadas diz onde pôr o esforço de escrita.
3. O robot volta a ler as páginas modificadas? Se uma página atualizada na semana passada não voltou a ser pedida, o sinal de atualidade não passa. Explicámos porquê em «Sitemap XML: um lastmod igual em todos os URL torna o seu sitemap inútil».

# os caminhos mais lidos pelo robot de pesquisa, 7.º campo
awk '/OAI-SearchBot/ {print $7}' ia.log | sort | uniq -c | sort -rn | head -30

Etapa 6: anotar a cadência e repetir a medição

A última leitura incide sobre o tempo. Para cada robot, regista-se o número de dias de visita no período, o intervalo entre duas passagens e a hora habitual. Um robot de pesquisa que passa todos os dias integrou o site no seu ciclo; um robot que passou uma vez para ler tudo e depois só voltou ao sitemap está à espera de um sinal de mudança. Esta cadência é a referência com que se compararão as medições seguintes, uma vez por semana ou uma vez por mês consoante o ritmo de publicação.

É preciso também guardar o ficheiro de trabalho. A duração de conservação depende do alojamento e do contrato, e conta-se muitas vezes em dias e não em meses: verifique a sua antes de precisar dela. Passado esse prazo, o dado já não existe, e uma pergunta feita em dezembro sobre o que se passou em setembro ficará sem resposta.

# dias de visita, depois a hora habitual
awk '/GPTBot/ {print substr($4,2,11)}' ia.log | sort -u
awk '/GPTBot/ {print substr($4,14,2)}' ia.log | sort | uniq -c

Os três erros que quase sempre se cometem à primeira vez

O primeiro é concluir sobre uma amostra: as últimas horas, a primeira página de uma ferramenta, um único dia. Um robot pode ter lido o site inteiro numa terça-feira à noite e não voltar a aparecer durante oito dias. Olha-se para o período inteiro antes de dizer que não vem.

O segundo é testar a partir do próprio posto de trabalho. Enviar um pedido com o user-agent do GPTBot a partir de uma rede de escritório e receber um 403 prova apenas que os usurpadores são recusados; o robot verdadeiro, esse, pode passar. O único teste que vale é a comparação entre o que o log mostra para o robot autêntico e o que se obtém por si próprio.

O terceiro é esquecer o que não chega até ao log. Um site por trás de um CDN que recusa os robots de IA terá um access log perfeitamente limpo e vazio de qualquer IA. A leitura dos logs começa pela leitura da configuração do CDN, e pelos registos do próprio CDN quando estão acessíveis.

O que esta meia hora rende

No fim do exercício, um editor sabe três coisas que nenhum painel lhe dará: que motores generativos indexam o seu site, que páginas leem, e se pessoas reais lá chegam por um assistente. É a base de qualquer estratégia de visibilidade nas IA, antes das medições de share of voice que descrevemos em «Medir a visibilidade nas IA». Uma plataforma editorial pode automatizar esta leitura e mostrá-la todos os dias; mas à primeira vez é preciso tê-la feito à mão, para saber o que se está a ver.