Em setembro de 2025, a Cloudflare lançou o Content Signals Policy prometendo dar aos donos de sites um jeito simples de dizer “sim” para aparecer na busca e “não” para virar dado de treino de IA. Foi vendido como o primeiro passo de um padrão que a indústria toda ainda não tem, e boa parte do mercado abraçou a ideia justamente por isso.
Quase um ano depois, em julho de 2026, John Mueller, especialista da equipe de Relações de Pesquisa do Google, respondeu a um tópico no Reddit sobre desambiguação de entidades, e foi nessa resposta, meio de passagem, que a frase que devolveu esse debate ao centro do radar apareceu: a diretiva “não tem efeito nenhum para nenhum crawler ou LLM”.
Não foi um desmentido tímido nem um “ainda estamos avaliando”. Mueller foi direto ao dizer que, até onde ele sabe, nenhum crawler ou modelo de IA usa esses sinais, e que adicioná-los ao robots.txt só cria peso e manutenção futura para o arquivo. Na visão dele, é esforço sem retorno técnico nenhum.
O problema é de escala, e é aí que a notícia dói de verdade. A Cloudflare protege cerca de 21,3% de todos os sites da internet, e mais de 3,8 milhões de domínios ativaram esse robots.txt gerenciado acreditando que estavam sinalizando alguma restrição real.
Vale entender como o recurso funciona, por que ele não pegou entre os crawlers, o que o próprio Google já oferece como alternativa funcional, e o que de fato bloqueia bot hoje.
Como funciona o Content Signals Policy da Cloudflare no robots.txt
Antes de qualquer confirmação de Mueller, vale relembrar rápido o que a Cloudflare tentou resolver com esse recurso, porque é esse mecanismo específico que está no centro da polêmica.
O robots.txt tradicional sempre disse a um crawler onde ele podia ou não entrar, mas nunca disse o que fazer com o conteúdo depois de acessá-lo. Foi essa lacuna que a Cloudflare tentou preencher com três categorias declaradas direto no arquivo: search (aparecer em resultado de busca), ai-input (alimentar resposta de IA em tempo real, como um AI Overview) e ai-train (treinar ou ajustar um modelo). Cada uma podia receber um simples “yes” ou “no”.
Para quem usa o robots.txt gerenciado da Cloudflare, o texto já vem pronto, algo como Content-signal: search=yes, ai-train=no, use=reference. Só que, caractere por carctere, isso continua sendo uma declaração de intenção. Não é bloqueio, e a própria Cloudflare nunca escondeu essa limitação: no lançamento, a empresa já reconhecia que robots.txt pode não impedir raspagem indesejada, e recomendava combinar o sinal com gerenciamento de bots e regras de firewall.
O que John Mueller disse sobre a diretiva Content Signals
Foi justamente sobre esse mecanismo declarativo que a confirmação surgiu, e de um jeito quase informal, o que ajuda a explicar por que ela pegou o mercado de surpresa mesmo sem ser, tecnicamente, uma novidade completa.
Um usuário do Reddit testava se os cabeçalhos de Content Signal e o arquivo llms.txt ajudavam na desambiguação de uma entidade de pessoa, e foi respondendo a essa pergunta pontual que Mueller derrubou duas expectativas de uma vez só. Primeiro, disse que o Google não usa llms.txt nem llms-author.txt, e que não conhece nenhum outro crawler ou LLM que confirme usá-los, fora ferramentas de SEO que leem esses arquivos por conta própria.
Depois, foi ao ponto que interessa aqui: “até onde eu sei, nenhum crawler ou LLM usa as diretivas ‘content-signal’ do robots.txt. Isso foi inventado por uma CDN, e, até onde eu sei, não tem efeito nenhum para nenhum crawler ou LLM. Usar isso só adiciona peso e manutenção futura ao seu arquivo robots.txt.”
Vale um parêntese aqui: declaração oficial de big tech também merece ser lida com um pé atrás, principalmente quando ela é taxativa desse jeito.
O próprio Google segue recomendando práticas como marcação estruturada (schema) e organização semântica de conteúdo para leitura de IA, mesmo sem confirmar publicamente qual peso exato cada uma delas carrega. Dizer que “não tem efeito nenhum” fecha a porta de um jeito bem definitivo para um cenário que, na prática, ainda está sendo desenhado.
Por que a diretiva Content Signals não impede raspagem nem uso em treino de IA
O motivo técnico por trás disso é simples de explicar, mesmo que a decepção de quem confiou no recurso não seja pequena.
Um crawler só respeita uma diretiva de robots.txt se o operador daquele crawler decidiu, do lado dele, implementar suporte para aquela instrução específica.
Não existe hoje um padrão amplamente adotado pela indústria que obrigue Google, OpenAI, Anthropic, Meta ou qualquer outro operador de crawler a validar o campo content-signal. Sem esse acordo coletivo, é a velha história do “só faltou combinar com os russos”: a Cloudflare definiu a regra do próprio lado, mas ninguém do outro lado assinou embaixo, e cada empresa segue lendo o robots.txt do jeito que já lia antes, ignorando qualquer coisa que não reconheça.
Isso conecta com um ponto que já vale para a rastreabilidade de site de um jeito mais amplo, e que sempre foi verdade, mesmo antes de existir Content Signals: robots.txt é orientação voluntária, nunca mecanismo de controle de acesso. Um crawler mal-intencionado, ou simplesmente um crawler que não reconhece aquela diretiva nova, ignora o arquivo inteiro sem consequência técnica alguma.
Content Signals ou bloqueio de bot: qual é a diferença real
Aqui mora a armadilha mais comum de todo esse assunto, e é importante separar bem os dois mecanismos antes de tirar qualquer conclusão apressada sobre o que proteger e como.
O Content Signals Policy é puramente declarativo, um texto dentro do robots.txt que informa uma preferência, sem qualquer capacidade de barrar acesso sozinho. É esse mecanismo, especificamente, que Mueller diz não ter efeito nenhum.
Já o gerenciamento de bots da própria Cloudflare, incluindo o bloqueio por categoria (Search, Agent e Training) anunciado em julho de 2026, opera em outra camada bem diferente: no nível de rede, via WAF e detecção de assinatura de tráfego. Esse sim barra a requisição antes mesmo de ela chegar ao servidor, independente de o crawler do outro lado “concordar” com a regra ou não.
A partir de 15 de setembro de 2026, a Cloudflare passa a aplicar esse bloqueio de rede por padrão para as categorias Agent e Training, em páginas com anúncio, para todo domínio novo cadastrado na plataforma. Crawlers de propósito misto, que combinam Search e Training numa mesma visita, também entram na trava.
Ou seja: o texto declarativo no robots.txt não funciona, mas o bloqueio técnico por trás dele, feito por firewall e reconhecimento de bot, funciona sim.
A alternativa que o próprio Google já oferece: o botão Search generative AI control
Se o objetivo de quem ativou o Content Signals sempre foi sair do AI Overviews sem perder a busca tradicional, existe hoje um caminho que não depende de o Google validar sinal de terceiro nenhum, porque ele foi construído pelo próprio Google.
Em 3 de junho de 2026, a empresa lançou o Search generative AI control dentro do Search Console, um interruptor que fica em Settings > Search generative AI.
Por ali, o proprietário do site escolhe entre manter o conteúdo incluído nas funcionalidades de IA generativa, excluir o site do AI Overviews, do AI Mode e do AI Overviews no Discover, ou herdar a configuração de uma propriedade pai.
A diferença central em relação ao Content Signals é justamente essa: como o controle vive dentro da própria infraestrutura do Google, não existem dúvidas sobre se ele será respeitado ou não. É o Google decidindo, sobre o próprio sistema, honrar a preferência que o site declarou.
Vale só o alerta de que o recurso ainda está sendo liberado por etapas, começando por um subconjunto de sites, então nem todo domínio tem acesso imediato ao botão.
O que fazer se sua estratégia dependia do Content Signals
Abandonar o robots.txt não é a resposta, e nem é isso que Mueller sugere. O arquivo continua útil para orientar crawlers que já respeitam a convenção tradicional, só nunca deveria ter sido tratado como cadeado contra raspagem ou uso indevido.
Quem realmente quer restringir raspagem de conteúdo ou uso por bot de IA precisa migrar essa conversa para controle técnico de fato, seja WAF, gerenciamento de bots por assinatura de tráfego, autenticação para acesso a conteúdo sensível, ou regras de firewall específicas por user-agent e comportamento.
E, especificamente para AI Overviews e AI Mode do Google, o Search generative AI control já resolve boa parte do que o Content Signals prometia e não entregava.
Vale também revisar a estrutura técnica do site pelo ângulo oposto, pensando em quem quer ser bem citado em resposta de IA em vez de bloqueado. Entender como as LLMs leem e indexam conteúdo ajuda a enxergar que a conversa técnica por trás de crawler de IA é mais complexa do que uma linha declarada no robots.txt, e passa também por deixar o site pronto para navegação de agente, algo que já discutimos quando o Google inseriu auditoria de navegação por agentes de IA no Lighthouse.
Resumindo o pacote prático:
- Revisar se a organização depende do Content Signals como única camada de proteção.
- Migrar controle real de acesso para WAF, autenticação ou gerenciamento de bots.
- Ativar o Search generative AI control no Search Console, se o objetivo for sair especificamente do AI Overviews e do AI Mode.
- Acompanhar o prazo de 15 de setembro de 2026 da Cloudflare, caso o domínio dependa dos novos padrões de bloqueio por categoria.
O que fica depois dessa confirmação
O Google não fechou de vez a porta para um padrão futuro, e é bem possível que esse assunto volte a mudar de figura daqui a um ano. Mueller só confirmou o que grande parte do mercado já desconfiava desde o lançamento do recurso: sem adoção da indústria inteira, sinal declarativo em robots.txt é carta de intenção, não trava de acesso.
Isso não invalida a tentativa da Cloudflare, e também não significa que o assunto morreu aqui. Mostra só que o problema de fundo, a falta de um padrão comum entre buscadores, plataformas de IA e provedores de infraestrutura, segue sem solução, e que, enquanto isso não muda, cada empresa segue decidindo sozinha o que vale a pena honrar.
Para quem cuida de SEO no dia a dia, a lição prática é separar sempre o que é declaração do que é imposição técnica, e usar o controle nativo do Google quando ele existir, em vez de apostar tudo numa diretiva que ninguém do outro lado confirma que lê. Quem confunde essas camadas corre o risco de achar que está protegido justamente quando não está.
Quer estruturar a proteção de conteúdo e a estratégia de visibilidade em IA com quem acompanha esse tipo de mudança de perto? Vale conhecer os programas da EducaSEO.
Referências
- Search Engine Roundtable (Barry Schwartz). Google Says Cloudflare Content Signals Robots.txt Directive Has No Effects Whatsoever. Disponível em: https://www.seroundtable.com/google-cloudflare-content-signals-41631.html
- Cloudflare Blog. Giving users choice with Cloudflare’s new Content Signals Policy. Disponível em: https://blog.cloudflare.com/content-signals-policy/
- Cloudflare Blog. Your site, your rules: new AI traffic options for all customers. Disponível em: https://blog.cloudflare.com/content-independence-day-ai-options/
- Cloudflare Developers Docs. Block AI Bots. Disponível em: https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/
- Search Engine Land (Danny Goodwin). Cloudflare offers way to block AI Overviews – will Google comply?. Disponível em: https://searchengineland.com/cloudflare-content-signals-462538
