Content Signals es una directiva de robots.txt, creada por Cloudflare en septiembre de 2025, que declara qué se puede hacer con tu contenido después de que un crawler ya lo descargó. No dice quién entra: eso lo sigue diciendo Disallow. Dice si lo que se llevó puede usarse para indexar, para alimentar una respuesta generativa o para entrenar un modelo.
Esa distinción es toda la propuesta. En palabras del propio anuncio de Cloudflare, robots.txt "does not, however, let them know what they are able to do with your content after accessing it".
Nuestra postura, sin vueltas: es una declaración de intención con peso legal declarado, no un control de acceso. Si querés que un bot no se lleve tu contenido, Content Signals no sirve. Para eso necesitás Disallow por user-agent, WAF o Bot Management. Ponerlo cuesta casi nada; creer que hace algo hoy es el error.
La especificación publicada en contentsignals.org define exactamente tres señales:
search — construir un índice de búsqueda y devolver resultados: hipervínculos y extractos cortos. La definición oficial excluye explícitamente los resúmenes generados por IA. search=yes no autoriza AI Overviews.ai-input — meter el contenido en un modelo en tiempo real: RAG, grounding, respuestas generativas.ai-train — entrenar o hacer fine-tuning de modelos.Los valores son únicamente yes o no.
Hay una cuarta, use, que Cloudflare introdujo en julio de 2026 y describe literalmente como una extensión opcional en pruebas. Sus valores, de menos a más permisivo: use=immediate (interactuar, no almacenar ni reutilizar), use=reference (indexar, citar y linkear — el default), use=full (resumir y reproducir).
Detalle que importa: use no está documentado en contentsignals.org. Lo verificamos hoy contra el bundle del sitio: la palabra no aparece. La fuente primaria de la spec y la implementación en producción de Cloudflare están desincronizadas.
La forma canónica del generador oficial:
User-Agent: *
Content-Signal: ai-train=no, search=yes, ai-input=no
Allow: /
Va dentro de un grupo de robots.txt, al lado de User-Agent, Allow y Disallow. Pares clave=valor separados por coma.
Se puede segmentar por bot repitiendo el bloque con otro User-Agent. Y también por ruta, con una sintaxis poco obvia: la ruta va antes de los pares, separada por espacio y sin coma.
User-Agent: *
Content-Signal: /blog/ ai-train=no, search=yes, ai-input=no
Allow: /blog/
Una advertencia sobre la gramática: no existe ABNF, ni RFC, ni documento normativo versionado. Y se nota. Cloudflare escribe el campo de tres maneras distintas según la fuente: Content-Signal: con espacio tras la coma en el blog y en contentsignals.org, Content-signal: sin espacios en su documentación, y Content-Signal: search=yes,ai-train=no,use=reference en la salida real de producción. En la práctica es irrelevante (los nombres de campo en robots.txt se tratan como case-insensitive), pero es sintomático: una spec cuyo autor la escribe de tres formas no tiene gramática normativa, tiene ejemplos.
Este es el matiz que más se pierde. El texto normativo dice que si el operador del sitio no incluye una señal para un uso determinado, no otorga ni restringe permiso respecto de ese uso. Es neutral, no negativo.
Por eso el default que Cloudflare aplicó a sus clientes omite ai-input a propósito: no conoce la preferencia del titular y no quiere adivinarla.
Lo cual abre la pregunta incómoda de por qué sí adivinó las otras. Cloudflare desplegó la política automáticamente sobre 3,8 millones de dominios con managed robots.txt, y en julio les agregó use=reference sin acción del titular. Bajo la teoría legal de la propia política, la ausencia de señal es neutra pero una señal presente es una declaración de voluntad. O sea: hay millones de sitios declarando una voluntad que nadie en esos sitios formuló.
El boilerplate oficial lo dice en mayúsculas: cualquier restricción expresada vía content signals constituye una reserva expresa de derechos bajo el Artículo 4 de la Directiva (UE) 2019/790. Ese artículo condiciona la excepción de minería de textos y datos a que los derechos no hayan sido reservados "in an appropriate manner, such as machine-readable means".
Además intenta apoyarse en una teoría contractual: el texto arranca diciendo que, como condición de acceso al sitio, quien accede acepta cumplir estas señales.
Ahora la letra chica del mismo sitio: Cloudflare advierte que tribunales y reguladores podrían concluir que robots.txt no impone obligaciones legales exigibles, y recomienda consultar a un abogado. El blog baja aún más el tono: dice que el párrafo final recuerda que estas señales podrían tener efectos legales en algunas jurisdicciones.
Nuestra lectura: la afirmación en mayúsculas es una aserción de parte, no una determinación judicial. Ningún tribunal adjudicó todavía que un Content-Signal: constituya reserva válida del Art. 4(3).
La jurisprudencia disponible corta para los dos lados. En Kneschke v. LAION, el OLG Hamburg (10 de diciembre de 2025, ref. 5 U 104/24) revirtió el criterio generoso de primera instancia: una reserva en lenguaje natural no cumplía el estándar de legibilidad por máquina para el momento del uso. A favor de Content Signals: confirma que la reserva debe ser machine-readable, y esta claramente lo es. En contra: el tribunal ancla la validez a la tecnología desplegada al momento del acto. Ser legible por máquina en teoría no es lo mismo que ser leída por las máquinas que importan.
Y el ámbito es sólo la UE. No hay teoría equivalente articulada para Estados Unidos, donde el debate es fair use, ni para Argentina o LATAM.
Cloudflare lo admite en sus tres fuentes. El blog: las señales expresan preferencias, no son contramedidas técnicas contra el scraping, y algunas empresas simplemente pueden ignorarlas. La documentación es más directa todavía: si querés forzar el bloqueo en vez de pedirlo, usá AI Crawl Control.
Del lado de los crawlers, la evidencia es peor que ambigua:
google/robotstxt agregando content-signal a la lista kUnsupportedTags. Google la reconoce para no reportarla como desconocida. No actúa sobre ella.Hay además un estándar competidor con más legitimidad de proceso: el working group aipref del IETF define el campo Content-Usage con vocabulario de dos categorías (train-ai, search) y valores y/n, camino a Proposed Standard. No comparte un solo token con Content Signals. Ironía verificable: el propio robots.txt de contentsignals.org declara usar vocabulario del estándar IETF y después emite Content-Signal, que no es de ahí.
Asimetría total de adopción: millones de emisores, cero receptores confirmados. Como control técnico, su eficacia medida hoy es cero.
Nuestra recomendación, que es un juicio y no una certeza:
Content-Signal no sirve. Usá Disallow por user-agent, WAF o AI Crawl Control. Nada más.content-signal de su lista de no soportadas, o que el draft del IETF avance a RFC. Una recomendación sin criterio de medición está incompleta.Un supuesto que no podemos verificar: la ausencia de anuncio público no prueba que ningún crawler la consuma en silencio. En el caso de Google, el commit sí prueba el no-uso.
Escribir esta línea a mano en una tienda Tiendanube tiene un problema previo: la plataforma genera el robots.txt y no te deja editarlo. El archivo tiene que responder en la raíz del mismo dominio y no hay forma de subirlo.
Por eso el editor de robots.txt de IndexNow Connect tiene un selector por señal —search, ai-input, ai-train y use— que arma la línea por vos, junto a los interruptores por bot y las rutas prohibidas. Lee tu archivo real, te dice quién parece estar escribiéndolo y te deja diseñar uno nuevo.
Dos cosas que no hace, y conviene decirlas:
Allow específicos, los Crawl-delay ni los grupos por bot con reglas parciales. Sobreviven las señales del grupo *, las rutas prohibidas, los bloqueos totales por bot y los sitemaps.El editor incluso avisa cuando declarás ai-train=no y dejás bots de IA sin bloquear, porque la lectura intuitiva ("ya lo bloqueé") es exactamente la equivocada. Si querés verificar antes qué bots entran hoy a tu sitio, el test de accesibilidad para bots de IA sale a la red con cada User-Agent y te lo dice.
Content Signals es la capa declarativa. La capa que sí mueve la aguja hoy —que tus URLs nuevas lleguen rápido a los índices que las buscan— es otra, y es la que resuelve IndexNow Connect: avisar en el momento en que un producto cambia, en vez de esperar a que alguien pase. Si venís de cero con el protocolo, empezá por qué es IndexNow y seguí con qué es GEO para entender el otro lado del problema.
No. Es una declaración de uso, no un control de acceso. Convive con Allow: / en la política por defecto de Cloudflare. El bloqueo real lo hacen las líneas Disallow: / por user-agent (GPTBot, ClaudeBot, CCBot, Google-Extended y compañía), que son un mecanismo distinto y anterior.
search=yes aparezco en AI Overviews?No, al menos no según la definición oficial. El texto de la spec excluye explícitamente los resúmenes generados por IA del alcance de search. Eso se declara con ai-input. Dicho lo cual, ningún crawler está honrando ninguna de las dos señales hoy, así que en la práctica esto no determina nada.
Nada, y es deliberado. El texto normativo dice que la ausencia de una señal no otorga ni restringe permiso: es neutra. No equivale a un no. Por eso Cloudflare omite ai-input en su default: no quiere adivinar la preferencia de sus clientes.
Google Search Console puede reportar "Syntax not understood" para esta y otras directivas nuevas. Cloudflare declara no haber observado impacto en tasas de rastreo ni en SEO. El riesgo real de tocar un robots.txt no viene de esta línea: viene de una regla Disallow mal escrita, que sí puede sacarte de los buscadores.
Son mecanismos distintos y no excluyentes: Content-Signal (Cloudflare) y Content-Usage (IETF) no comparten vocabulario ni valores. Con cc-signals y llms.txt también en la cancha, el desenlace más probable no es que gane el mejor, sino que ninguno alcance masa crítica del lado del crawler — que es el único lado que importa. Emitir las dos líneas cuesta dos renglones; asumir que alguna se está obedeciendo, no.