CookingMetrics Data-Driven Business
Martín Garay·3 de setembro de 2026·9 min de leituraSEO técnicoGEO · IAGuias

O teste de acessibilidade para bots: três camadas, duas perguntas

Quase todo mundo verifica se seus produtos estão acessíveis aos bots. Quase ninguém verifica se o checkout não está.

As duas metades importam igual. Um bot que não chega ao seu catálogo custa visibilidade em buscadores e em respostas geradas. Um bot que chega ao seu carrinho, à área de conta ou às suas páginas de busca interna custa orçamento de rastreamento, e às vezes algo pior.

Este artigo explica como se verifica uma coisa e outra, e por que as respostas vêm de três camadas independentes que falham de formas diferentes.

As três camadas que deixam um crawler de fora

Quando você diz "esse bot não consegue entrar", está misturando três mecanismos que não têm nada a ver entre si. O conserto de cada um é feito por uma pessoa diferente.

Camada 1 — robots.txt. Quem decide é o site, e obedecem os bots que cumprem as regras. É voluntário: nada impede que um rastreador ignore o arquivo. Resolve-se procurando o product token do bot dentro do arquivo, não o User-Agent dele. São campos distintos: o Screaming Frog usa o token screaming frog seo spider e vai para a rede com o UA Screaming Frog SEO Spider/20.0.

Camada 2 — a resposta HTTP com o User-Agent do bot. Quem decide é o servidor, o WAF ou o CDN. É um corte de acesso real, não uma convenção: pode bloquear mesmo que o robots.txt permita, e não depende da boa vontade de ninguém. Os status que valem como bloqueio são 401, 403, 407, 429 e 451.

Camada 3 — as diretivas de indexação. X-Robots-Tag nos cabeçalhos e <meta name="robots"> no <head>. Deixam passar, mas não indexam. O bot acessa, lê, e mesmo assim a página não entra no índice.

As três podem se contradizer. Um robots.txt permissivo com um 403 do WAF por cima dá "bloqueado". Um 200 limpo com noindex no cabeçalho dá "entra, mas não serve". Por isso não basta um semáforo: é preciso ver o dado bruto de cada camada separadamente.

Por que a ordem importa

Quando é preciso resumir as três em um veredicto, a precedência é esta:

  1. Erro de rede — não houve resposta, não há nada a interpretar.
  2. Bloqueio HTTP (401/403/407/429/451) — ganha do robots.txt, porque o bot nem chega a ler a página.
  3. Disallow no robots.txt — o que está proibido, ainda que o servidor tivesse respondido.
  4. Noindex — entra, mas não é indexado.
  5. 5xx / 4xx / robots indeterminado — status que não são nem sim nem não.

Primeiro o que corta o acesso, depois o que o proíbe, por último o que deixa entrar sem indexar. Um Disallow para o GPTBot em um site que além disso devolve 403 a ele não é informação redundante: se amanhã você tirar o bloqueio do WAF, a primeira regra continua de pé.

Os cinco erros de leitura que geram falsos negativos

Verificar isso na mão, com curl e boa vontade, falha em lugares específicos. Estes são os que mais vezes dão um "está permitido" que não é verdade.

Sobre este último ponto convém ser explícito, porque a leitura intuitiva é a errada: declarar ai-train=no e deixar os bots de IA sem bloqueio não os bloqueia. É uma reserva de direitos, não um cadeado.

Como nós fazemos, e o que não faz

No IndexNow Connect o teste roda a partir do painel, contra até 5 URLs e um catálogo de 46 entradas divididas em cinco grupos: IA (21), buscadores (10), SEO (6), redes e mensageria (8), e uma linha de navegador. Cada linha mostra uma coluna por camada mais o veredicto.

Três decisões que vale a pena contar porque têm consequências visíveis:

Há uma linha de navegador e é a mais importante. Chrome no macOS, sem token de robots. Sem ela não há com o que comparar: se o navegador também recebe 403, o problema não é o bot, é a URL. É a primeira pergunta diante de qualquer bloqueio.

Três tokens não recebem requisição. Google-Extended, Applebot-Extended e o legado anthropic-ai não são crawlers: são interruptores de uso para IA sobre o que o Googlebot e o Applebot já baixaram. Mandar uma sonda para eles seria inventar um bot que não existe. Deles se informa o veredicto do robots.txt e nada mais.

O teto é real e é declarado. Máximo de 40 sondas HTTP por execução, 4 em paralelo, 6 segundos de timeout, 200 KB de corpo lido por resposta. Com duas URLs e o catálogo inteiro são pedidas 86 sondas e rodam 40: sobram 46 sem testar, a tela diz isso com um número, e essas linhas saem como "sem testar" em amarelo, nunca como permitido. Um limite silencioso é lido como "testei tudo", e isso é pior do que não medir.

O que não faz, dito sem rodeios:

O teste vive junto com o resto do painel — conheça o IndexNow Connect se quiser ver como ele se encaixa com o envio automático de URLs ao IndexNow quando você publica ou edita um produto.

O que revisar em cada metade

O que deveria entrar. Home, categorias principais, uma ficha de produto representativa, o sitemap. Verifique com o grupo de buscadores e o de IA separadamente: é comum que o Googlebot passe limpo e o GPTBot receba 403 de uma regra de WAF que ninguém lembra de ter colocado. Se o navegador entra e o bot não, o bloqueio é deliberado ou acidental, mas existe.

O que não deveria entrar. Checkout, carrinho, área de conta, páginas de busca interna com query string, filtros facetados, endpoints da API. Aqui o resultado esperado é disallow, e um allow é o achado. Teste com a query string incluída: a avaliação do robots.txt considera pathname + search, e uma regra escrita para /buscar não necessariamente cobre /buscar?q=tenis.

Dois detalhes que mudam o resultado na segunda metade:

Se o seu robots.txt é escrito pela sua plataforma ou reescrito pela Cloudflare, é provável que nenhuma das duas coisas esteja como você imagina. Vale a pena ler também o que são os Content Signals no robots.txt e como manter seu site acessível aos bots de IA com a Cloudflare.

Perguntas frequentes

Um Disallow no robots.txt garante que o bot não entre?

Não. O Robots Exclusion Protocol é voluntário: descreve como um rastreador que quer cumprir as regras deve interpretar o arquivo, não impõe nada. Se você precisa de um corte real de acesso, a camada é HTTP: autenticação, WAF ou regras do CDN. Por isso o teste mede as duas separadamente.

Se eu não tenho robots.txt, está tudo permitido?

Sim para o acesso, mas você perde a declaração padrão de sitemaps. Atenção a uma nuance: um 4xx significa "não há arquivo" e portanto tudo permitido, enquanto um 5xx não equivale a permitido. É um estado desconhecido, e tratá-lo como permissão é inventar uma resposta que o servidor não deu.

noindex e Disallow fazem a mesma coisa?

Não, e combinar os dois costuma ser um erro. Se você proíbe a URL no robots.txt, o bot não consegue ler o noindex que você colocou lá dentro. O Google documenta isso no seu guia de noindex: para que a diretiva seja respeitada, a página precisa ser rastreável. Proibir no robots.txt serve para que não gastem rastreamento; noindex serve para que a página não apareça no índice.

Por que o checkout precisa estar bloqueado se de qualquer forma não ranqueia?

Por duas razões diferentes. A primeira é orçamento de rastreamento: cada URL de carrinho com parâmetros únicos é uma URL nova que o bot descobre e pede, e isso compete com as suas fichas de produto. A segunda é que as páginas de conta e os fluxos de compra às vezes expõem dados ou estados que não deveriam sair do site. A segunda é menos frequente e mais cara.

Quantos bots vale a pena revisar?

Menos do que você imagina, mas os certos. Comece pelo grupo de IA e pela linha de navegador, que é o padrão. O navegador diz se a URL funciona; o grupo de IA é onde aparecem os bloqueios que ninguém decidiu conscientemente, porque muitos WAFs vêm com regras de "AI scrapers" ativadas de fábrica. Os grupos de SEO e de redes agregam ruído, a menos que você esteja diagnosticando um problema concreto de pré-visualização de links ou de uma ferramenta que não consegue rastrear o seu site.