Content-Signal: o que a IA pode fazer com o teu conteúdo
O robots.txt responde a uma única pergunta e nunca respondeu a outra: podes descarregar isto. Sim ou não, caminho a caminho, bot a bot. Não tem vocabulário para a posição que a maioria dos sites realmente defende, que é «indexa-me, cita-me, manda-me leitores, mas não treines um modelo com o que escrevo».
Por isso as pessoas puxam a única alavanca que existe. Bloqueiam tudo com Disallow e levam o tráfego pela frente junto com o treino.
Permissão para descarregar não é permissão para usar
São duas perguntas distintas e só uma tem que ver com a tua largura de banda. Um crawler que lê a tua página de preços e a cita quando alguém pergunta o que contratar está a fazer-te um favor. Os mesmos bytes despejados num conjunto de treino são uma transação completamente diferente, e nessa tu não entras.
Bloquear tudo junta as duas num mesmo «não». Para um arquivo pago pode ser o correto. Para um negócio que quer ser encontrado e recomendado é a opção errada por omissão: desapareces das respostas e os teus concorrentes não.
O Content-Signal é a camada que te permite separá-las.
Os três sinais
Content-Signal: search=yes, ai-input=yes, ai-train=no
search: construir um índice de pesquisa e devolver resultados, ou seja, ligações e excertos curtos. Não inclui os resumos gerados por IA, que são o sinal seguinte.ai-input: passar a tua página a um modelo no momento de responder. RAG, grounding, as fontes listadas por baixo de uma resposta gerada.ai-train: treinar ou afinar um modelo com o teu conteúdo.
São independentes. Qualquer combinação é válida, e várias delas são posições pensadas, não distrações.
Os valores são yes e no. Não há maybe, nem sintaxe por caminho, nem data de validade.
Omitir um sinal não equivale a no. Segundo a convenção, um uso sobre o qual nada dizes não é concedido nem restringido: simplesmente não respondeste. O nosso gerador escreve sempre os três, e é o hábito certo, porque o silêncio é a única resposta com que ninguém consegue fazer nada.
Onde se põe
Em dois sítios, e ambos saem baratos.
No robots.txt, dentro de um grupo de user-agent:
User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no
Sitemap: https://exemplo.com/sitemap.xml
E como cabeçalho de resposta HTTP:
Content-Signal: search=yes, ai-input=yes, ai-train=no
O agentready.md serve os dois. Esse cabeçalho exato sai em cada resposta: cada página, cada versão .md, cada chamada à API.
Para nginx:
add_header Content-Signal "search=yes, ai-input=yes, ai-train=no" always;
Para Apache:
<IfModule mod_headers.c>
Header set Content-Signal "search=yes, ai-input=yes, ai-train=no"
</IfModule>
O cabeçalho merece o lugar. O robots.txt é pedido na raiz, de vez em quando, e um agente que aterra num URL profundo porque alguém colou a ligação pode nunca chegar a lê-lo. O cabeçalho viaja colado àquilo que está a ser levado.
Existe também a forma em meta tag, <meta name="content-signal" content="search=yes, ai-input=yes, ai-train=no">. Usa-a quando não conseguires mexer na configuração do servidor. O cabeçalho é melhor porque cobre também as respostas que não são HTML.
Três casos reais
Um meio que quer atribuição.
Content-Signal: search=yes, ai-input=yes, ai-train=no
Aparecer dentro de uma resposta com ligação é distribuição, o equivalente atual a seres citado. O treino é a parte que ninguém te paga e que também não te devolve ninguém.
Um SaaS que quer ser recomendado.
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Documentação, preços, changelog. Quando alguém pergunta a um assistente o que usar para uma tarefa, queres ser a resposta, e estar nos dados de treino é a forma de te nomearem quando o modelo não descarrega nada. Aqui não há nada a proteger. O material é marketing.
Um arquivo pago.
Content-Signal: search=yes, ai-input=no, ai-train=no
Queres ser encontrado, porque o resultado de pesquisa é o argumento de venda. O que não queres é que a substância do artigo chegue de graça dentro da resposta de outra pessoa. Este é o caso em que o sinal faz um trabalho que um Disallow não sabe fazer: bloquear o crawl levava-te também a ficha no motor de pesquisa.
Se um bot merece condições diferentes, leva o seu próprio grupo:
User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no
User-agent: GPTBot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Aplica-se a precedência de sempre do robots.txt: um bot que encontra o seu próprio nome lê esse grupo e ignora o * por completo.
O que isto é na verdade
Uma convenção jovem. Não é um RFC, nem uma norma do W3C, nem nada que um crawler seja obrigado a respeitar. Ninguém prometeu cumpri-la de uma forma que possas exigir. Se leres que o Content-Signal protege o teu conteúdo, estás a ler publicidade.
Então porquê escrever a linha.
Porque é legível por uma máquina e custa quase nada: uma linha num ficheiro que já serves, um cabeçalho num bloco de configuração que já tens. O preâmbulo que acompanha a convenção apresenta um no como reserva expressa de direitos ao abrigo do artigo 4.º da Diretiva 2019/790 da UE, a exclusão voluntária da prospeção de textos e dados. Se isso se sustenta na tua jurisdição é pergunta para um advogado. Uma preferência que não expressaste não se sustenta em nenhuma.
E porque diz algo para o qual um Disallow não tem palavras. «Não treines comigo» e «vai-te embora» são frases diferentes, e até agora só podias mandar a segunda.
Confirma que o teu chega
curl -sI https://exemplo.com/ | grep -i content-signal
curl -s https://exemplo.com/robots.txt | grep -i content-signal
Repete o primeiro contra uma página que não seja a inicial. Se o cabeçalho estiver posto dentro de um bloco location, pode cobrir menos site do que julgas.
Mais um, se estiveres atrás de uma CDN:
curl -sI https://exemplo.com/robots.txt | grep -i "server\|cf-cache-status"
Confirma que o robots.txt que volta é o teu. O nosso devolveu 404 a partir da origem durante meses enquanto a Cloudflare respondia na borda com um ficheiro de política gerida que nunca tínhamos escrito, e cada verificação que fazíamos recebia um 200 perfeitamente credível.