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.
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.
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.
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 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.
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:
google/robotstxt acrescentando content-signal à lista kUnsupportedTags. O Google a reconhece para não reportá-la como desconhecida. Não age sobre ela.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.
Nossa recomendação, que é um juízo e não uma certeza:
Content-Signal não serve. Use Disallow por user-agent, WAF ou AI Crawl Control. Nada mais.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.
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:
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 move o ponteiro hoje — que as suas URLs novas cheguem rápido aos índices que as procuram — é outra, e é a que o IndexNow Connect resolve: avisar no momento em que 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.
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.
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.
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.
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.
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.