Siete de sesenta y ocho proveedores de visibilidad en IA declaran Content Signals. Ninguno usa el campo nuevo.

Content Signals es la única forma legible por máquina de decir qué puede hacer un rastreador de IA con tu página después de leerla. Vive en el robots.txt, tiene una especificación detrás y es gratis. Pedimos el robots.txt a los 69 proveedores de nuestro catálogo el 14 de agosto de 2026. De los 68 proveedores que sirvieron un fichero legible, 7 declaran Content Signals y 0 declaran el cuarto campo.

Es una categoría cuyo producto entero consiste en que las máquinas te lean bien. Y es también una categoría que, con siete excepciones, no ha usado el único campo diseñado para decirlo.

Aviso: EchoWi es uno de los 69 y uno de los siete, y vendemos medición de visibilidad en IA, así que un estudio sobre quién declara bien sus preferencias es un estudio con interés. El método es una petición GET a /robots.txt y una búsqueda de líneas que empiecen por Content-Signal:. La fecha es el 14 de agosto de 2026, cada proveedor que declara sale nombrado abajo con su redacción exacta, y los recuentos están en nuestro registro de mediciones. Cualquiera puede repetirlo contra nosotros en un minuto, y la sección sobre lo que nuestro propio barrido anterior hizo mal está ahí porque lo corrimos primero contra nosotros.

La versión corta

1. 68 de los 69 proveedores sirven un robots.txt. Uno devuelve un reto de bot en su lugar, que es un reto y no un fichero ausente, y por eso se cuenta aparte.
2. 7 de los 68 declaran Content Signals. Eso es aproximadamente uno de cada diez, en una categoría construida sobre ser legible por máquina.
3. 0 declaran content-use, el cuarto campo que se está probando ahora. Ni un proveedor de la categoría lo ha adoptado.
4. Seis de los siete declaran permisividad total, alguna versión de search sí, ai-input sí, ai-train sí.
5. Uno declara ai-train=no manteniendo ai-input=yes. Eso no es una contradicción, y tratarlo como tal sería el error fácil que esta pieza tiene cuidado de no cometer.
6. Nuestro propio recuento anterior de esta misma convención estaba mal sobre ese proveedor, por un motivo de instrumento que describimos en vez de corregir en silencio.

Qué es un Content Signal, y el campo que acaba de aparecer

Un fichero robots.txt siempre ha podido decir dónde puede ir un rastreador. Nunca ha podido decir qué puede hacer un rastreador con lo que encuentra. Content Signals cubre ese hueco con tres campos, escritos como una línea de directiva dentro de un grupo:

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

Los tres significan cosas distintas y la diferencia es justo el motivo de que existan:

• search cubre construir un índice de búsqueda sobre el contenido.
• ai-input cubre meter el contenido en un modelo para producir una respuesta en tiempo real. Este es el que gobierna la citación.
• ai-train cubre usar el contenido para entrenar o afinar un modelo.

Un editor puede sostener cualquier combinación de posturas entre esos tres, y el vocabulario existe para que sostener una postura matizada se pueda expresar en vez de aproximarla bloqueando un rastreador entero.

Cloudflare está probando ahora un cuarto campo, content-use, que describe qué se puede conservar y reutilizar después del acceso. Toma uno de tres valores, de menos a más permisivo: use=immediate significa interactuar sin guardar nada, use=reference significa indexar, citar un extracto y enlazar de vuelta, y use=full significa resumir y reproducir. El propio robots.txt gestionado de Cloudflare escribe use=reference junto a su valor por defecto de search=yes, ai-train=no.

Al mismo catálogo se le hizo una pregunta vecina el mismo día, con el mismo instrumento: la mayoría de los dominios que se llevan citas no publica un llms.txt mientras que la mayoría de proveedores sí, que es la otra convención que vende esta categoría.

Ese cuarto campo es el motivo de que mereciera la pena correr este barrido ahora y no más tarde. Es lo bastante nuevo como para que la adopción sea una pregunta de verdad, y la respuesta sale limpia.

Qué dicen sesenta y nueve ficheros robots.txt

El instrumento pide /robots.txt al origen de cada proveedor, sigue redirecciones y lee todas las líneas Content-Signal: del cuerpo. Es deliberadamente poco vistoso, y tres de sus decisiones importan:

Usa GET, nunca HEAD. Un servidor no está obligado a responder a una petición HEAD, y esto no es teórico aquí: un comprobador de enlaces anterior de este proyecto reportó dos páginas perfectamente vivas como muertas por exactamente ese motivo antes de corregirse.

Un reto no es un fichero ausente. Los estados 401, 403, 429 y 999 significan que una comprobación de bots se puso en medio. Eso es evidencia sobre el borde, no sobre si el fichero existe, y meterlo en «no tiene robots.txt» fabricaría un número. Un proveedor cae en este cubo.

Un 200 no es automáticamente un robots.txt. Algunos alojamientos responden cualquier ruta con una página de marketing. El cuerpo tiene que contener una directiva de verdad antes de que la fila cuente.

Los recuentos del 14 de agosto de 2026:

Y los siete, con lo que dice cada uno de verdad:

Dos cosas hay que leer en esa tabla antes de sacar ninguna conclusión del titular.

La primera es que un robots.txt lleva una línea Content-Signal por grupo, así que el recuento de la columna del medio no es decoración. Rankability escribe once, que es un acto deliberado de decirle lo mismo a once grupos de rastreadores distintos. Omnibound escribe tres, y no dicen todas lo mismo.

La segunda es que la declaración de Rankability omite ai-input por completo. Según la especificación un campo ausente no es un no, es silencio, así que esto no es un rechazo de la citación. Es un proveedor que ha pensado sobre entrenamiento y búsqueda y no ha dicho nada sobre el campo que gobierna ser usado en una respuesta.

El único proveedor que dice no, y por qué esa es la respuesta pensada

Omnibound es el único de los siete que declara una preferencia restrictiva en algún sitio: ai-train=no, junto a ai-input=yes.

La lectura tentadora es que un proveedor que vende visibilidad en IA diciéndole a los rastreadores de IA que no usen su contenido es una contradicción que señalar. Esa lectura es falsa, y merece la pena deletrear por qué, porque todo el valor de este vocabulario descansa en la distinción que hace.

Entrenar y responder son usos distintos. Un modelo entrenado con tu contenido lo ha absorbido en sus pesos, no cita nada y no manda a nadie. Un modelo que usa tu contenido como entrada de una respuesta puede citarlo, atribuirlo y enlazarlo. Un editor que quiere lo segundo y no lo primero no está confundido. Está expresando exactamente la postura que los tres campos fueron diseñados para dejar expresar, y es el único proveedor de esta categoría que se ha molestado en expresarla.

Con los números tal y como los encontramos, Omnibound tiene la declaración más pensada del conjunto. Todos los demás que declaran algo han dicho que sí a todo, que es una postura defendible para un negocio que quiere el máximo alcance de máquina, y es también lo que escribes cuando no has pensado en la diferencia.

El instrumento estaba mal primero, y nuestro propio recuento anterior también

Corrimos una versión de este barrido tres días antes, el 11 de agosto, dentro de una auditoría más amplia de lo que envía esta categoría. Aquel recuento registró que Omnibound declaraba search=yes, y punto.

Eso era nuestro instrumento, no su fichero. Leía la primera línea Content-Signal: y la reportaba como si fuera la declaración. Omnibound tiene tres, y la primera resulta ser la menos interesante de todas. El registro publicado tuvo por tanto la postura de un proveedor puesta del revés durante tres días, y nada avisó, porque un valor recortado se ve exactamente igual que uno completo.

No editamos la cifra anterior. Es un hecho congelado de lo que nuestro instrumento vio en su propio día, y sus recuentos están citados en varios sitios. Lo que hemos hecho en su lugar es registrar el barrido nuevo aparte, guardar cada línea con su recuento al lado, y escribir dentro de los propios datos por qué las dos fechas no coinciden. Si Omnibound cambió el fichero entre el once y el catorce, o si nuestro instrumento anterior simplemente lo leyó mal, ya no se puede recuperar. Elegir la explicación que nos favorezca sería inventarse un hecho.

La regla general que sacamos: cuando un formato permite que un campo aparezca más de una vez, el instrumento las recoge todas y el registro guarda cuántas había. Un recuento al lado de un valor es lo que hace visible el siguiente recorte.

Y los sitios que sí se llevan las citas no lo hacen mejor

La objeción evidente a todo lo de arriba es que medimos a la gente equivocada. Los proveedores venden visibilidad, no necesariamente se la llevan. Así que hicimos la misma pregunta a los dominios que sí.

La población es cada dominio que este registro tiene anotado como citado en tres o más filas de sonda distintas, que son 122 de los 1.019 dominios distintos que ha visto. El umbral es arbitrario y lo declaramos: lo bastante alto para que un dominio haya sido citado en varias preguntas y no en una, lo bastante bajo para dejar una muestra mayor que el catálogo de proveedores. De esos 122, 113 sirvieron un fichero legible, 5 devolvieron un reto, 3 no resolvieron y 1 respondió 200 con algo que no es un robots.txt.

9 de los 113 dominios citados declaran Content Signals. Frente a 7 de 68 de los proveedores, es la misma tasa dentro de cualquier error que merezca ese nombre.

Eso va en contra del marco con el que abre esta pieza, así que lo decimos claro: la categoría no es especialmente negligente con una convención de la que depende su propio producto. Es normal. Lo normal es simplemente muy bajo, en las dos poblaciones, y un hallazgo sobre un sector se escribe con menos comodidad que uno sobre un conjunto de competidores.

Sobreviven dos diferencias a la comparación, y una es más pequeña de lo que parece.

El cuarto campo existe fuera y no en la categoría. Ningún proveedor declara content-use. Dos dominios citados sí. Pero los dos escriben la cadena idéntica byte a byte search=yes,ai-train=no,use=reference, espaciado incluido, así que dos adoptantes no son evidencia de dos decisiones. La explicación más probable es un plugin o un fragmento copiado, y lo anotamos así y no como adopción.

Rechazar el entrenamiento es más común fuera de la categoría. Cuatro de los nueve dominios citados que declaran dicen ai-train=no, frente a uno de siete proveedores. Son recuentos y no tasas a propósito: con un solo dígito un porcentaje sería teatro, y lo honesto es decir que la única población donde decir que no al entrenamiento es común es la que no construimos nosotros.

Qué no enseña esto

Una convención, un día, un catálogo. Son 69 proveedores que seguimos, el 14 de agosto de 2026. No es una muestra de la web y no es una afirmación sobre nadie fuera de esa lista.

Declarar no es cumplir, y no declarar no es bloquear. Content Signals expresa una preferencia. No fuerza nada, un rastreador es libre de ignorarlo, y un proveedor sin declaración no ha negado nada por ello. La lectura correcta de los 61 que no declaran es que están callados, no que sean hostiles.

Un robots.txt es lo que sirve el borde, no lo que contiene el repositorio. Esto lo sabemos por experiencia: nuestra propia declaración fue invisible para un barrido anterior porque una CDN seguía sirviendo una versión cacheada con un año de TTL. Una medición de lo que un sitio declara es una medición de lo que su caché está entregando ese día.

Cero adopción de un campo no es evidencia de que el campo sea malo. content-use es nuevo y todavía se describe como una prueba. Que nadie lo haya adoptado aún es un hecho sobre el momento tanto como sobre el campo, y lo honesto es volver a medirlo más adelante en vez de concluir nada ahora.

No hemos medido si nada de esto cambia la citación. Aquí no hay nada que conecte una declaración con ser citado más o menos. Eso necesitaría otro diseño, y preferimos decirlo a insinuar el vínculo.

Preguntas frecuentes sobre Content Signals

¿Qué son los Content Signals en robots.txt?

Content Signals son directivas legibles por máquina dentro de un fichero robots.txt que declaran qué puede hacer un rastreador con el contenido después de acceder a él. Hay tres campos: search para construir un índice de búsqueda, ai-input para meter contenido en un modelo y generar una respuesta en tiempo real, y ai-train para entrenar o afinar un modelo. Se escriben como una línea de directiva dentro de un grupo de rastreador, por ejemplo Content-Signal: search=yes, ai-input=yes, ai-train=yes, y cada campo toma yes o no.

¿Cuántos proveedores de visibilidad en IA declaran Content Signals?

7 de los 68 que sirvieron un robots.txt legible, medido el 14 de agosto de 2026 sobre los 69 proveedores de nuestro catálogo. Un proveedor más devolvió un reto de bot en vez de un fichero, y lo contamos aparte porque un reto no es evidencia de que falte un fichero. Los siete salen nombrados en la tabla de arriba con sus declaraciones exactas.

¿Qué es el campo content-use?

content-use es un cuarto campo de Content Signals que se está probando ahora, y describe qué se puede conservar y reutilizar después del acceso. Sus tres valores van de menos a más permisivo: use=immediate significa interactuar sin guardar ni reutilizar nada, use=reference significa indexar, citar un extracto y enlazar de vuelta, y use=full significa resumir y reproducir. A 14 de agosto de 2026, ninguno de los 68 proveedores que pudimos leer lo declara.

¿Declarar ai-train=no perjudica tu visibilidad en IA?

Por sí solo no, porque entrenar y responder son usos separados. ai-train gobierna si tu contenido puede absorberse en los pesos de un modelo, mientras que ai-input gobierna si puede usarse como material de origen para una respuesta generada, que es el que produce citas y enlaces. Un editor puede rechazar lo primero y permitir lo segundo, y un proveedor de este barrido hace exactamente eso.

¿Debería añadir Content Signals a mi robots.txt?

Es gratis, es una línea por grupo de rastreador, y es la única forma estandarizada de expresar la diferencia entre que te entrenen y que te citen. Declarar permisivo o restrictivo es una decisión de derechos y no técnica, así que el paso útil es decidir qué quieres de verdad para cada uno de los tres usos antes de escribir nada. Declarar no fuerza nada, así que va junto a los controles de acceso que ya tengas y no en su lugar.

¿Cómo compruebo qué declara un sitio?

Pide /robots.txt al origen del propio sitio con un GET, no con un HEAD, y lee todas las líneas que empiecen por Content-Signal:. Puede haber más de una, porque un fichero lleva una por grupo de rastreador, y leer solo la primera es como nos equivocamos con la postura de un proveedor en un barrido anterior. Si la petición devuelve 401, 403, 429 o 999 has topado con un reto de bot y no has aprendido nada sobre el fichero.