Google-Agent no WordPress aparece quando um agente hospedado na infraestrutura do Google visita uma página para navegar ou executar uma ação solicitada por uma pessoa. O cuidado é não confundir essa visita com Googlebot, nem liberar o firewall só porque alguém escreveu “Google-Agent” no cabeçalho. A verificação precisa combinar log, IP oficial e contexto da requisição.
Resumo rápido
- Google-Agent é um agente acionado por usuário, não o robô de indexação do Google.
- O texto do user-agent ajuda a localizar o acesso, mas não prova a origem.
- Valide o IP no arquivo oficial e, quando necessário, confirme DNS reverso e direto.
- Não use robots.txt como controle de segurança: fetchers acionados por usuário podem ignorá-lo.
- Faça allowlist estreita, preserve autenticação e acompanhe erros, volume e URLs acessadas.
Fonte e revisão: guia revisado em 9 de agosto de 2026 com base na documentação oficial da infraestrutura de rastreamento do Google e na lista de IPs de agentes acionados por usuários, atualizada em 7 de agosto de 2026.
O que é o Google-Agent no WordPress?
O Google descreve o Google-Agent como o identificador usado por agentes hospedados em sua infraestrutura para navegar na web e realizar ações a pedido de um usuário. Isso o coloca na categoria de user-triggered fetchers: acessos iniciados por uma pessoa dentro de um produto ou experiência, não uma varredura automática para descobrir páginas.
A página oficial de fetchers acionados por usuários publica os formatos móvel e desktop do cabeçalho. Para quem administra WordPress, o dado mais útil não é decorar a string inteira, mas entender a fronteira: Google-Agent não substitui Googlebot e uma visita dele não indica indexação, ranking ou inclusão em respostas de IA.
Esse recorte complementa o nosso checklist de SEO para AI crawlers. O guia geral organiza acesso e conteúdo; aqui, a tarefa é operacional: reconhecer uma requisição específica, evitar falsificação e decidir o que liberar.
Regra prática: trate “Google-Agent” no log como uma pista, não como identidade comprovada. Qualquer cliente HTTP pode copiar um user-agent; a origem precisa bater com os intervalos publicados pelo Google.
Por que robots.txt não resolve esse acesso?
Robots.txt comunica preferências de rastreamento. Ele não é autenticação, firewall nem barreira de privacidade. A própria documentação informa que fetchers acionados por usuários geralmente ignoram suas regras porque o acesso foi solicitado por uma pessoa.
Isso muda uma decisão comum. Se uma URL não deveria ser acessada sem permissão, ela precisa continuar protegida por login, autorização, regra de aplicação ou resposta HTTP adequada. Colocar Disallow no robots.txt não transforma uma página privada em privada.
Também não vale criar uma regra apressada só para o Google-Agent. Antes, revise o objetivo de cada área do site. Conteúdo público pode ser servido normalmente; painel, preview, staging, endpoints administrativos e dados de cliente devem depender dos mesmos controles que já protegem qualquer visitante.
Como identificar uma visita do Google-Agent?
Comece no log de acesso do servidor, da hospedagem ou da CDN. Filtre pelo trecho Google-Agent e preserve pelo menos horário, IP de origem, método, URL, status HTTP, bytes enviados, referer e user-agent completo. Sem esses campos, a investigação vira adivinhação.
- Localize a requisição: registre quando ocorreu, qual URL recebeu acesso e qual resposta o WordPress entregou.
- Separe o IP: não copie apenas o user-agent; o endereço de origem será comparado com a lista oficial.
- Consulte os intervalos publicados: o Google mantém o arquivo user-triggered-agents.json em formato CIDR.
- Confirme a correspondência: use a função de IP/CIDR do firewall, SIEM ou script de observabilidade. Comparação por prefixo de texto não é segura.
- Revise o contexto: volume, sequência de URLs, erros e método precisam ser compatíveis com navegação, não com varredura agressiva ou tentativa de exploração.
| Evidência | O que ela prova | Decisão |
|---|---|---|
| User-agent contém Google-Agent | Só identifica o que o cliente declarou | Insuficiente para liberar |
| IP está no JSON oficial | Origem pertence ao intervalo publicado para agentes | Base adequada para regra automática estreita |
| DNS reverso e direto coincidem | Reforça a validação em investigação manual | Útil para incidente ou acesso isolado |
| Origem válida e padrão de acesso coerente | Une identidade técnica e comportamento observado | Permitir com monitoramento e limites |
Como verificar o IP sem confiar apenas no nome?
Para um caso isolado, o Google orienta verificar o DNS em duas etapas: resolver o IP para um hostname e depois resolver esse hostname de volta para o mesmo IP. Os domínios esperados variam conforme a categoria do fetcher; por isso, use a página oficial de verificação de requisições do Google, não uma lista copiada de fórum.
Em volume, a opção mais estável é automatizar a comparação com os prefixos do JSON. Baixe uma cópia em intervalo controlado, valide que o conteúdo é JSON, mantenha a última versão válida e atualize a regra de allowlist de forma atômica. Se o download falhar, não troque a lista atual por um arquivo vazio.
Checklist da automação
- Buscar somente em URL HTTPS oficial do Google.
- Validar esquema, data de criação e presença de prefixos IPv4/IPv6.
- Aplicar a nova lista em transação ou arquivo temporário validado.
- Guardar a versão anterior para rollback.
- Alertar quando a atualização falhar ou reduzir prefixos de forma inesperada.
Como ajustar firewall e CDN com segurança?
Evite uma regra ampla do tipo “se o cabeçalho contém Google-Agent, permita tudo”. Isso entrega ao atacante uma porta fácil de imitar. A regra deve combinar IP em CIDR oficial, método esperado, área pública e limites de taxa compatíveis com seu ambiente.
Para páginas públicas, permita GET e HEAD quando a origem estiver validada e não houver outro sinal de abuso. Para login, painel, XML-RPC, REST privada, preview protegido e rotas de comércio, preserve os controles existentes. Um agente legítimo não precisa receber privilégio administrativo para ler uma página pública.
Se você usa uma CDN ou WAF, documente onde a decisão acontece. Não adianta liberar no plugin de segurança quando a CDN bloqueia antes; também não adianta liberar na borda e deixar o servidor de origem exposto a acessos diretos. O artigo sobre Agent Readiness Score e Cloudflare ajuda a separar configuração real de uma nota simplificada.
Cuidado: allowlist de IP reduz falso positivo, mas não substitui autorização. Uma requisição legítima do Google ainda deve receber 401 ou 403 quando tenta acessar algo que aquele usuário não pode ver.
O que revisar dentro do WordPress?
O WordPress pode gerar robots.txt virtual, aplicar regras por plugin, bloquear REST e alterar cache. Faça a revisão por camada para não “corrigir” a parte errada.
- Hospedagem: confirme se os logs registram o IP real depois do proxy e se o horário está no fuso esperado.
- CDN/WAF: identifique regras gerenciadas, desafios, bloqueios por país e rate limits aplicados antes da origem.
- Plugin de segurança: revise bloqueio por user-agent, lista de bots e proteção contra varredura.
- Cache: verifique se páginas públicas entregam resposta consistente e se cookies desnecessários não criam variações.
- Privacidade: mantenha conta, checkout, dados pessoais, preview e staging atrás de autenticação real.
- Conteúdo: use HTML acessível, links claros e dados estruturados válidos; não crie uma versão “especial para agente”.
Se a dúvida é se um arquivo adicional ajuda sistemas de IA a entender o site, veja a análise de llms.txt no WordPress. Ele não substitui acesso HTTP, arquitetura, conteúdo útil ou segurança.
Como medir sem inventar tráfego de IA?
A fonte primária é o log do servidor ou da CDN. Conte requisições validadas por IP, URLs acessadas, status HTTP, bytes, tempo de resposta e repetição. Analytics baseado em JavaScript pode não registrar todos os acessos e não deve ser usado sozinho para afirmar que um agente visitou a página.
Também não atribua ranking, citação ou receita só porque houve uma requisição. O guia técnico de crawlers e fetchers explica que essas famílias executam funções diferentes. Para estratégia editorial, o guia de SEO e inteligência artificial ajuda a conectar acessibilidade técnica com utilidade real para o leitor.
Registro mínimo por 14 dias
- Total de requisições com origem validada.
- URLs públicas mais acessadas e respostas 2xx, 3xx, 4xx e 5xx.
- Bloqueios legítimos preservados em áreas privadas.
- Picos de volume, latência e consumo de cache.
- Mudanças na lista oficial de IPs e data da última sincronização.
Perguntas frequentes
Google-Agent é o mesmo que Googlebot?
Não. Googlebot é um crawler comum ligado à descoberta e ao rastreamento para produtos como a Busca. Google-Agent é usado por agentes hospedados no Google para navegar e agir após solicitação de um usuário.
Bloquear Google-Agent derruba o ranking?
Não há base para afirmar isso. O acesso do Google-Agent não é o mesmo processo do Googlebot. Qualquer decisão deve considerar função, segurança e experiência do usuário, sem transformar uma visita em promessa de SEO.
Posso liberar apenas pelo user-agent?
Não é recomendável. O cabeçalho pode ser falsificado. Compare o IP com os prefixos oficiais e, em investigação manual, use também DNS reverso e direto.
Disallow no robots.txt protege páginas privadas?
Não. Robots.txt expressa preferência de rastreamento e pode ser ignorado por fetchers acionados por usuário. Proteja páginas privadas com autenticação e autorização.
Conclusão
Tratar Google-Agent no WordPress com segurança exige separar identificação declarada de origem comprovada. Encontre a requisição no log, valide o IP oficial, revise o contexto e faça uma liberação estreita apenas para conteúdo público.
O ganho não vem de abrir o site para qualquer bot com nome convincente. Vem de permitir navegação legítima sem enfraquecer login, dados privados, staging e controles administrativos.
Seu firewall já registra o IP real de agentes e proxies ou você ainda depende apenas do user-agent? Compartilhe o cenário nos comentários.
