DocsMétricasCategorias

Categorias de tráfego

Toda visita ao seu site é classificada em uma de 9 categorias mutuamente exclusivas. Esse guia explica como cada categoria se manifesta, exemplos reais, e o que fazer quando você vê padrões fora do normal.

A classificação é determinística (regex + reverse DNS + bot score), não usa IA. Roda em < 1ms por evento. Cada request entra em exatamente uma categoria — sem overlap, sem percentuais.

Resumo

CategoriaO que éVolume típicoAtenção?
humanVisitante real10–60% (varia muito)É o número que importa
verified_botCrawler legítimo validado1–10%Não — quer mais Googlebot
ai_crawlerBots de IA (Claude, GPT, etc.)2–25%Sim, está explodindo
seo_crawlerBots de SEO (Ahrefs, SEMrush)1–10%Vigilar consumo de banda
feed_readerRSS/Atom readers0–5%Indicador de audiência fiel
health_checkMonitores de uptime1–3%Confirmar que são os seus
wp_internalWordPress internal calls0–10%Reduzir se for excessivo
attackerProbes/scans/brute-force5–40%Sempre — mas é normal ter
unknownUA presente, não classificável3–15%Vigiar se cresce muito
human

Humanos

Bot score: 0–29 · Detecção: UA conhecido de browser + sinais negativos para bot

Visitante real usando um browser comum (Chrome, Firefox, Safari, Edge, Brave, Opera). Bot score baixo, sem padrões headless, headers consistentes (Accept, Accept-Language, etc. presentes).

Exemplos reais que entram aqui:

  • Visitante chegou pelo Google e leu seu artigo no celular.
  • Cliente do e-commerce navegou e comprou.
  • Usuário interno logado fazendo edições — se você desativou "Excluir admins".

NÃO entram aqui: headless browsers (Puppeteer, Playwright sem mascarar), browsers automatizados, qualquer UA com keyword de bot.

O que fazer com esse número
É o número de "visitantes verdadeiros" do seu site — equivalente a "Users" no GA4 ou "Visitors" no Plausible. Métricas de Web Vitals e funil de conversão se aplicam só aqui. Se cair de repente, pode ser problema técnico (404, página fora do ar) ou queda de SEO.
verified_bot

Verified bot

Detecção: Reverse DNS (PTR record) validado contra domínio do operador

Crawler oficial cuja autenticidade foi confirmada por DNS reverso. Pra Googlebot, validamos que o PTR contém googlebot.com ou google.com; pra Bingbot, contra search.msn.com. Resultado cacheado por IP por 24h.

Exemplos reais:

  • Googlebot crawleando seu sitemap.
  • Bingbot indexando novas páginas.
  • DuckDuckBot, YandexBot, Baiduspider — todos com PTR validável.
  • FacebookExternalHit fetching Open Graph quando alguém compartilha seu link.

NÃO entram aqui: bots que dizem "sou Googlebot" no UA mas têm IP de hosting genérico (vão pra attacker ou unknown). Spoof de UA é comum — por isso validamos por DNS.

O que fazer com esse número
Você QUER que esse número seja saudável — significa que motores de busca estão indexando. Se Googlebot some por > 7 dias, abra Search Console e veja se há erros de crawl. Picos não são preocupantes (Googlebot faz batches).
ai_crawler

AI crawler

Detecção: Match de UA contra lista de bots de IA conhecidos, atualizada continuamente

Bots de empresas de IA que coletam conteúdo pra treinar modelos ou pra alimentar respostas em tempo real (RAG). Lista atual:

  • ClaudeBot, Anthropic-AI — Anthropic (Claude).
  • GPTBot, OAI-SearchBot, ChatGPT-User — OpenAI.
  • PerplexityBot — Perplexity.
  • Google-Extended — Google Bard/Gemini (separado do Googlebot tradicional).
  • Applebot-Extended — Apple Intelligence training.
  • Bytespider — ByteDance (TikTok).
  • cohere-ai, YouBot, Amazonbot, Meta-ExternalAgent.

Exemplos do que provoca picos:

  • Publicou um artigo novo — ClaudeBot e GPTBot fazem batch crawl em 1-3 dias.
  • Você está rankeando bem em SERPs — Perplexity busca seu conteúdo pra cita-lo.
  • Conteúdo viral — todos os AI crawlers fazem re-crawl simultaneamente.
O que fazer com esse número
Esta categoria importa muito em 2026. Os primeiros sites a aparecer em respostas de ChatGPT/Claude/Perplexity vão ganhar a próxima década de SEO. Se um AI crawler nunca aparece, considere: (1) publicar llms.txt com sua política, (2) garantir que o conteúdo é acessível sem JavaScript, (3) checar se você não bloqueou no robots.txt sem querer. Se quiser bloquear AI crawlers específicos, adicione User-agent: GPTBot\nDisallow: / ao robots.txt (alguns respeitam, outros não).
seo_crawler

SEO crawler

Detecção: Match de UA contra lista de ferramentas SEO comerciais

Bots de ferramentas de SEO/competitive intel que indexam a web pra alimentar dashboards de seus clientes:

  • AhrefsBot — Ahrefs. Crawl agressivo, alto volume.
  • SemrushBot — SEMrush. Idem.
  • DotBot — Moz.
  • MJ12bot — Majestic. Notoriamente agressivo.
  • Sogou, Screaming Frog, outros menores.

Exemplos do que provoca picos:

  • Um concorrente adicionou seu site à lista de monitoramento dele no Ahrefs/SEMrush — crawl recorrente começa.
  • Você foi adicionado a um dataset público (Common Crawl, etc.) e bots SEO descobriram em massa.
O que fazer com esse número
Útil pra entender se sua concorrência está te monitorando (provavelmente sim, se você ranqueia). Se o consumo de banda incomoda, dá pra bloquear bots SEO específicos via robots.txt — Ahrefs, SEMrush e Majestic respeitam. Cuidado: bloquear AhrefsBot significa que dados teus param de aparecer no Ahrefs (visível pra seus concorrentes), o que pode ser bom OU ruim dependendo da estratégia.
feed_reader

Feed reader

Detecção: UA conhecido de leitor RSS/Atom + acesso a /feed, /rss, /atom.xml

Aplicativos que checam periodicamente seu feed RSS pra notificar leitores sobre novos posts:

  • Feedly, Inoreader, FreshRSS, NewsBlur.
  • FeedFetcher-Google (Google News).
  • SimplePie, Tiny Tiny RSS — self-hosted, leitores comprometidos.
O que fazer com esse número
Indicador de audiência fiel. Cada hit de feed reader = uma pessoa que adicionou seu blog ao reader dela. É um sinal de qualidade — gente que volta sem clicar em link. Se cair, pode ser que você parou de publicar (e leitores desistiram) ou que seu RSS está quebrado. Confira manualmente abrindo seusite.com/feed num browser.
health_check

Health check

Detecção: UA conhecido de monitor de uptime + padrão de acesso periódico

Monitores que pingam seu site a cada 1-5 minutos pra confirmar que está no ar:

  • UptimeRobot, Pingdom, StatusCake, HetrixTools, UptimeMonster.
  • Monitores internos do hosting (Cloudways, Kinsta, etc.).
O que fazer com esse número
Geralmente os seus próprios monitores. Bom pra confirmar que health checks estão de fato disparando. Se você não configurou nenhum monitor e está vendo health_check no Radar, alguém está te monitorando — pode ser cliente, parceiro, ou competidor.
wp_internal

WP interno

Detecção: UA prefixo WordPress/ ou padrão de wp-cron / self-call

Requests originados pelo próprio WordPress: wp-cron, REST API self-calls, plugin updates checks, etc. Não é tráfego de visitante.

Exemplos:

  • wp-cron disparando jobs agendados (UA: WordPress/6.x; https://seusite.com).
  • Plugin checando se há update disponível (calls pro wordpress.org).
  • Yoast/RankMath gerando sitemap rebuilds.
O que fazer com esse número
Útil pra distinguir tráfego "real" de overhead da plataforma. Se wp_internal está > 20% do total, vale auditar wp-cron (pode haver job em loop) ou desabilitar wp-cron HTTP e usar cron real do sistema (DEFINE('DISABLE_WP_CRON', true) + cron de servidor).
attacker

Atacante

Detecção: Bot score ≥ 70 — combinação de sinais (UA, paths sensíveis, frequência, fingerprint)

Requests com alta probabilidade de tentativa de ataque. Sinais que somam pro bot score:

  • UA vazio ou suspeito (curl, python-requests sem customização).
  • Headless markers (HeadlessChrome, PhantomJS).
  • Inconsistência entre UA e headers (claim "Chrome 120" mas sem Accept-Language).
  • Frequência alta da mesma IP em pouco tempo.
  • Acesso a paths sensíveis: /wp-admin/, /xmlrpc.php, /.env, /.git/, /wp-config.php.
  • Match de JA3/JA4 com botnet conhecido.
  • Padrões de scanner (sqlmap, nuclei, wpscan, nikto).

Exemplos reais:

  • Bot fazendo brute-force em /wp-login.php com 50 senhas/min.
  • Scanner buscando vulnerabilidade conhecida em /wp-content/plugins/<plugin>/exploit-path.
  • Botnet probando se você expôs /.env com credenciais AWS.
  • sqlmap testando injection em URLs com query params.
O que fazer com esse número
Ter atacantes é normal — todo site exposto à internet recebe. O que importa é o ratio: 5-15% é típico. Se ultrapassa 30%, vale instalar SysWP Shield ou outro WAF pra bloquear na borda em vez de só observar. Use o painel "Top atacantes" pra ver IPs específicos e o painel "Top probed paths" pra ver o que estão buscando — isso te diz qual plugin/CMS eles acham que você tem.
unknown

Desconhecido

Detecção: Bot score entre 30 e 69 — sinais ambíguos, sem match em listas

Catch-all pra UAs que NÃO são humanos óbvios mas também não são atacantes óbvios. Não inflaciona "atacante" com falsos positivos.

Exemplos:

  • Bots customizados de empresas (scrapers internos, integrações B2B).
  • Ferramentas de devs (curl manual, httpie, Postman pra validar webhook).
  • Bots novos não catalogados ainda.
  • Apps mobile não identificáveis pelo UA padrão.
  • Tráfego de SDKs (preview de link em iMessage, link unfurl de Slack, etc.).
O que fazer com esse número
Em condições normais, < 15% do total. Se cresce muito rápido, vale investigar — pode ser scraping novo ou bot emergente. Use o painel de UAs únicos pra ver se há um UA específico responsável pelo crescimento.

Como o classifier decide

Em ordem de prioridade — primeiro match decide:

  1. Health check — UA conhecido de monitor + padrão periódico.
  2. WP interno — UA prefixo WordPress/.
  3. Feed reader — UA conhecido + path RSS.
  4. AI crawler — match em lista de bots de IA.
  5. SEO crawler — match em lista de ferramentas SEO.
  6. Verified bot — UA claim ser Google/Bing/etc + reverse DNS confirma.
  7. Atacante — bot score ≥ 70.
  8. Unknown — bot score 30–69.
  9. Human — bot score 0–29 + UA reconhecível.

Detalhes técnicos completos do bot score em Como funciona → Bot score.

Filtrar por categoria no dashboard

Em qualquer view de dashboard:

FAQ

Por que vejo "atacantes" mesmo sem WAF instalado?

Atacante é uma classificação, não um bloqueio. O Radar só observa — quem decide bloquear é seu WAF (Shield, Cloudflare, Wordfence, etc.). Ver atacantes no Radar significa que eles chegaram até seu servidor. Se quiser bloquear, integre com Shield ou configure regras no Cloudflare.

Bot do Google às vezes aparece em "unknown" — por quê?

Acontece quando o reverse DNS falha temporariamente ou demora pra responder. O classifier exige PTR validável pra entrar em verified_bot — se a validação não conclui, cai em unknown. Não é falha do Radar, é proteção contra UA spoofing. Em batches de hits, < 2% costuma cair nesse caso.

Se o ratio de humanos é baixo (< 20%), meu site está mal?

Não necessariamente. Sites de conteúdo viral, APIs públicas, ou sites grandes naturalmente atraem muito bot tráfego. O que importa é a tendência absoluta de humanos, não o ratio. Se humanos cai > 30% em 7d, aí sim é sinal de alerta (SEO, problema técnico, ou queda de aquisição).

Como eu reduzo o consumo de banda dos crawlers?

3 opções em ordem de impacto: (1) habilite cache full-page no servidor (crawler ainda hit mas response é cache, custa ~0 CPU); (2) bloqueie crawlers específicos via robots.txt (cuidado com bloquear Googlebot por engano); (3) firewall por UA no Cloudflare/nginx pra bots que ignoram robots.txt.

Posso adicionar minha própria categoria customizada?

Hoje não. As 9 categorias são fixas pra garantir comparabilidade entre sites e clientes. Em planos Agency, você pode adicionar tags customizadas via API que não substituem mas complementam a categoria.

← AnteriorWeb Vitals