Content Signals no robots.txt: o que declara, como se escreve e por que não bloqueia nada

Content Signals é uma diretiva de robots.txt, criada pela Cloudflare em setembro de 2025, que declara o que pode ser feito com o seu conteúdo depois que um crawler já baixou. Ela não diz quem entra: isso continua sendo função do Disallow. Diz se aquilo que foi levado pode ser usado para indexar, para alimentar uma resposta generativa ou para treinar um modelo.

Essa distinção é toda a proposta. Nas palavras do próprio anúncio da Cloudflare, o robots.txt "does not, however, let them know what they are able to do with your content after accessing it".

Nossa posição, sem rodeios: é uma declaração de intenção com peso legal declarado, não um controle de acesso. Se você quer que um bot não leve o seu conteúdo, Content Signals não resolve. Para isso você precisa de Disallow por user-agent, WAF ou Bot Management. Colocar custa quase nada; acreditar que faz alguma coisa hoje é o erro.

Os três sinais (e o quarto, que é experimental)

A especificação publicada em contentsignals.org define exatamente três sinais:

• search — construir um índice de busca e devolver resultados: hiperlinks e trechos curtos. A definição oficial exclui explicitamente os resumos gerados por IA. search=yes não autoriza AI Overviews.
• ai-input — colocar o conteúdo em um modelo em tempo real: RAG, grounding, respostas generativas.
• ai-train — treinar ou fazer fine-tuning de modelos.

Os valores são unicamente yes ou no.

Existe um quarto, use, que a Cloudflare introduziu em julho de 2026 e descreve literalmente como uma extensão opcional em testes. Seus valores, do menos ao mais permissivo: use=immediate (interagir, não armazenar nem reutilizar), use=reference (indexar, citar e linkar — o padrão), use=full (resumir e reproduzir).

Detalhe que importa: use não está documentado em contentsignals.org. Verificamos hoje contra o bundle do site: a palavra não aparece. A fonte primária da spec e a implementação em produção da Cloudflare estão dessincronizadas.

Como se escreve

A forma canônica do gerador oficial:

User-Agent: *
          Content-Signal: ai-train=no, search=yes, ai-input=no
          Allow: /
          

Vai dentro de um grupo do robots.txt, ao lado de User-Agent, Allow e Disallow. Pares chave=valor separados por vírgula.

Dá para segmentar por bot repetindo o bloco com outro User-Agent. E também por rota, com uma sintaxe pouco óbvia: a rota vai antes dos pares, separada por espaço e sem vírgula.

User-Agent: *
          Content-Signal: /blog/ ai-train=no, search=yes, ai-input=no
          Allow: /blog/
          

Um alerta sobre a gramática: não existe ABNF, nem RFC, nem documento normativo versionado. E dá para notar. A Cloudflare escreve o campo de três maneiras diferentes conforme a fonte: Content-Signal: com espaço depois da vírgula no blog e em contentsignals.org, Content-signal: sem espaços na documentação, e Content-Signal: search=yes,ai-train=no,use=reference na saída real de produção. Na prática é irrelevante (os nomes de campo em robots.txt são tratados como case-insensitive), mas é sintomático: uma spec cujo autor a escreve de três formas não tem gramática normativa, tem exemplos.

A ausência de sinal não é um "não"

Esta é a nuance que mais se perde. O texto normativo diz que, se o operador do site não incluir um sinal para um uso determinado, ele não concede nem restringe permissão a respeito desse uso. É neutro, não negativo.

Por isso o padrão que a Cloudflare aplicou aos seus clientes omite ai-input de propósito: ela não conhece a preferência do titular e não quer adivinhá-la.

O que abre a pergunta incômoda de por que adivinhou as outras. A Cloudflare aplicou a política automaticamente em 3,8 milhões de domínios com managed robots.txt, e em julho acrescentou use=reference sem ação do titular. Sob a teoria legal da própria política, a ausência de sinal é neutra, mas um sinal presente é uma declaração de vontade. Ou seja: há milhões de sites declarando uma vontade que ninguém nesses sites formulou.

O status legal: uma afirmação de parte

O boilerplate oficial diz em letras maiúsculas: qualquer restrição expressa via content signals constitui uma reserva expressa de direitos sob o Artigo 4 da Diretiva (UE) 2019/790. Esse artigo condiciona a exceção de mineração de textos e dados a que os direitos não tenham sido reservados "in an appropriate manner, such as machine-readable means".

Além disso, tenta se apoiar em uma teoria contratual: o texto começa dizendo que, como condição de acesso ao site, quem acessa aceita cumprir esses sinais.

Agora as letras miúdas do mesmo site: a Cloudflare adverte que tribunais e reguladores poderiam concluir que o robots.txt não impõe obrigações legais exigíveis, e recomenda consultar um advogado. O blog baixa ainda mais o tom: diz que o parágrafo final lembra que esses sinais poderiam ter efeitos legais em algumas jurisdições.

Nossa leitura: a afirmação em maiúsculas é uma asserção de parte, não uma determinação judicial. Nenhum tribunal julgou ainda que um Content-Signal: constitua reserva válida do Art. 4(3).

A jurisprudência disponível corta para os dois lados. Em Kneschke v. LAION, o OLG Hamburg (10 de dezembro de 2025, ref. 5 U 104/24) reverteu o critério generoso da primeira instância: uma reserva em linguagem natural não cumpria o padrão de legibilidade por máquina para o momento do uso. A favor do Content Signals: confirma que a reserva deve ser machine-readable, e esta claramente é. Contra: o tribunal ancora a validade à tecnologia implantada no momento do ato. Ser legível por máquina em tese não é o mesmo que ser lida pelas máquinas que importam.

E o âmbito é apenas a UE. Não há teoria equivalente articulada para os Estados Unidos, onde o debate é fair use, nem para o Brasil ou a América Latina.

O que não faz: a evidência dura

A Cloudflare admite nas suas três fontes. O blog: os sinais expressam preferências, não são contramedidas técnicas contra scraping, e algumas empresas simplesmente podem ignorá-los. A documentação é ainda mais direta: se você quer forçar o bloqueio em vez de pedi-lo, use o AI Crawl Control.

Do lado dos crawlers, a evidência é pior que ambígua:

• Em 19 de fevereiro de 2026, o Google mergeou o commit 4af32e5 em google/robotstxt acrescentando content-signal à lista kUnsupportedTags. O Google a reconhece para não reportá-la como desconhecida. Não age sobre ela.
• John Mueller, em julho de 2026, disse publicamente que nenhum crawler nem LLM usa essas diretivas, que ela foi inventada por uma CDN, e que adicioná-la só soma peso e manutenção futura ao seu arquivo.
• Não há um único operador de crawler — OpenAI, Anthropic, Perplexity, Google, Microsoft — que tenha anunciado suporte.
• O Google Search Console pode reportar "Syntax not understood" ao ver a linha. Os próprios docs da Cloudflare avisam disso e esclarecem que não observaram impacto em rastreamento nem em SEO.

Há ainda um padrão concorrente com mais legitimidade de processo: o working group aipref do IETF define o campo Content-Usage com vocabulário de duas categorias (train-ai, search) e valores y/n, a caminho de Proposed Standard. Não compartilha um único token com o Content Signals. Ironia verificável: o próprio robots.txt de contentsignals.org declara usar vocabulário do padrão IETF e depois emite Content-Signal, que não é de lá.

Assimetria total de adoção: milhões de emissores, zero receptores confirmados. Como controle técnico, sua eficácia medida hoje é zero.

Então, coloco ou não?

Nossa recomendação, que é um juízo e não uma certeza:

1. Se o objetivo é que não levem o conteúdo: Content-Signal não serve. Use Disallow por user-agent, WAF ou AI Crawl Control. Nada mais.
2. Se o objetivo é construir evidência de reserva expressa diante de um litígio futuro na UE: o custo marginal é próximo de zero e o valor opcional não é nulo. Coloque.
3. Como saber se isso começa a importar: há dois sinais objetivos e baratos de monitorar — que algum operador relevante tire content-signal da sua lista de não suportadas, ou que o draft do IETF avance a RFC. Uma recomendação sem critério de medição é incompleta.

Um pressuposto que não podemos verificar: a ausência de anúncio público não prova que nenhum crawler a consuma em silêncio. No caso do Google, o commit prova o não uso.

Como nós geramos

Escrever essa linha à mão em uma loja Nuvemshop tem um problema anterior: a plataforma gera o robots.txt e não deixa você editá-lo. O arquivo tem que responder na raiz do mesmo domínio e não há como subi-lo.

Por isso o editor de robots.txt do IndexNow Connect tem um seletor por sinal — search, ai-input, ai-train e use — que monta a linha para você, junto com os interruptores por bot e as rotas proibidas. Ele lê o seu arquivo real, diz quem parece estar escrevendo-o e deixa você desenhar um novo.

Duas coisas que ele não faz, e convém dizer:

• Publicar no nosso app não toca no seu domínio. Enquanto você não adicionar a rota no Worker da Cloudflare, o seu site continua servindo o arquivo de sempre. É o passo mais esquecido.
• Ao regenerar o arquivo não se preservam os Allow específicos, os Crawl-delay nem os grupos por bot com regras parciais. Sobrevivem os sinais do grupo *, as rotas proibidas, os bloqueios totais por bot e os sitemaps.

O editor inclusive avisa quando você declara ai-train=no e deixa bots de IA sem bloquear, porque a leitura intuitiva ("já bloqueei") é exatamente a errada. Se você quiser verificar antes quais bots entram hoje no seu site, o teste de acessibilidade para bots de IA sai para a rede com cada User-Agent e te diz.

Content Signals é a camada declarativa. A camada que de fato atua hoje — avisar os índices que uma URL mudou — é outra, e é a que o IndexNow Connect, a ferramenta da CookingMetrics, cobre: avisar quando um produto muda, em vez de esperar que alguém passe. Se você está começando do zero com o protocolo, comece por o que é IndexNow e siga com o que é GEO para entender o outro lado do problema.

Perguntas frequentes

O Content Signals bloqueia o ChatGPT ou o Claude?

Não. É uma declaração de uso, não um controle de acesso. Convive com Allow: / na política padrão da Cloudflare. O bloqueio real é feito pelas linhas Disallow: / por user-agent (GPTBot, ClaudeBot, CCBot, Google-Extended e companhia), que são um mecanismo diferente e anterior.

Se eu colocar search=yes apareço nos AI Overviews?

Não, ao menos não segundo a definição oficial. O texto da spec exclui explicitamente os resumos gerados por IA do alcance de search. Isso se declara com ai-input. Dito isso, nenhum crawler está honrando nenhum dos dois sinais hoje, então na prática isso não determina nada.

O que acontece se eu não declarar um sinal?

Nada, e é deliberado. O texto normativo diz que a ausência de um sinal não concede nem restringe permissão: é neutra. Não equivale a um no. Por isso a Cloudflare omite ai-input no seu padrão: não quer adivinhar a preferência dos seus clientes.

Adicionar essa linha ao meu robots.txt quebra alguma coisa?

O Google Search Console pode reportar "Syntax not understood" para esta e outras diretivas novas. A Cloudflare declara não ter observado impacto nas taxas de rastreamento nem no SEO. O risco real de mexer em um robots.txt não vem dessa linha: vem de uma regra Disallow mal escrita, que sim pode tirar você dos buscadores.

Vale a pena esperar o padrão do IETF?

São mecanismos diferentes e não excludentes: Content-Signal (Cloudflare) e Content-Usage (IETF) não compartilham vocabulário nem valores. Com cc-signals e llms.txt também em campo, o desfecho mais provável não é que vença o melhor, mas que nenhum alcance massa crítica do lado do crawler — que é o único lado que importa. Emitir as duas linhas custa duas linhas; supor que alguma está sendo obedecida, não.