Metodología · reglas versión 2
Qué medimos y qué podemos afirmar
Este estudio separa dos cosas que suelen mezclarse: lo que se observa y lo que se infiere de lo observado. Con telemetría web pasiva no se puede distinguir de forma fiable a una persona, un rastreador y un agente autónomo, así que registramos dimensiones observables y aceptamos «indeterminado» como resultado válido, no como fallo.
Diccionario de eventos
Un mismo acceso puede generar varios eventos. No se suman como «visitas»: cada tipo se cuenta por separado y con su propio denominador.
| Evento | Qué significa |
|---|---|
| peticion_servidor | El servidor recibió y respondió una petición de una página. |
| navegacion_spa | Cambio de página sin recargar, dentro de una visita ya abierta. |
| beacon_js | Se ejecutó código de navegador y llegó su aviso. Es un evento propio, no una visita. |
| ruta_canario | Se pidió una de las rutas únicas mencionadas en el texto de una ficha. |
| correo_entrante | El proveedor de correo aceptó un mensaje en una dirección única de ficha. |
| recurso_maquina | Se pidió una representación pensada para máquinas: JSON, Markdown, feed o llms.txt. |
Seis dimensiones por sesión
| Dimensión | Valores | Qué permite afirmar |
|---|---|---|
| Identidad declarada | buscador · herramienta · navegador · desconocido | Solo lo que la petición dice de sí misma. Es falsificable. |
| Verificación técnica | operador verificado · no verificado | Comprobación de DNS inverso y directo cuando el operador publica el procedimiento. Indica procedencia de infraestructura, no finalidad. |
| Mecanismo observado | HTTP sin beacon · ejecución JS · endpoint estructurado · mixto | Cómo se accedió. No dice quién accedió. |
| Patrón de acceso | enumeración · consulta puntual · seguimiento de referencias · insuficiente | Comportamiento compatible con varias causas distintas. |
| Procedencia | externo · ejecución controlada · monitor · propio · desconocida | Solo en ejecución controlada existe verdad de referencia. |
| Evidencia de agencia | conocida en experimento · compatible · insuficiente | Fuerza de la inferencia, separada de la inferencia misma. |
El resumen categórico (persona, rastreador, agente, indeterminado) se conserva como etiqueta secundaria derivada de estas dimensiones. Las puntuaciones de reglas no son probabilidades mientras no estén calibradas contra ejecuciones conocidas.
Matriz de afirmaciones permitidas
| Afirmación | Cuándo se permite | Qué no permite concluir |
|---|---|---|
| Se pidió esta ruta única | Sí, es un hecho registrado. | No dice que fuera un sistema automático ni que desobedeciera nada. |
| Se aceptó un mensaje en esta dirección | Sí, es un hecho del proveedor de correo. | No prueba envío autónomo ni falta de autorización de la persona usuaria. |
| Aparece este código de referencia en una salida | Solo si observamos esa salida legítimamente. | No prueba que el modelo visitara el sitio. |
| Se observó un beacon JS | Sí, se ejecutó código de navegador. | No significa persona: la automatización de navegador también lo ejecuta. |
| Este operador cumplió las reglas de rastreo | Solo dentro de un experimento controlado y publicando la interpretación aplicada. | robots.txt no es control de acceso ni una licencia general. |
Agrupación de eventos
Los eventos se agrupan por un identificador técnico derivado del agente declarado, el idioma y la familia aproximada de red, firmado con una clave que solo conoce el servidor. Una agrupación se cierra cuando pasan 30 minutos sin ningún evento (cada petición cuenta como un evento propio: no fusionamos peticiones distintas por caer en la misma franja de tiempo), y el siguiente evento abre una nueva: no usamos bloques fijos de reloj, que partían por la mitad una lectura en curso. Las ejecuciones controladas se agrupan aparte del tráfico externo. No es una identidad de visitante y no lo llamamos «usuarios únicos»: puede juntar accesos de personas distintas y partir accesos del mismo actor.
Reglas evaluables y controles negativos
Contar visitas no dice nada sobre conducta. Para poder decir algo, publicamos reglas explícitas y comprobables: una ruta excluida en robots.txt sin contenido de valor (/zona-excluida), una pareja permitida con el mismo texto (/zona-abierta), un límite de peticiones declarado y respuestas 429 con tiempo de espera. La pareja permitida es el control negativo: sin ella, una petición a la ruta excluida sería indistinguible del recorrido normal del sitio.
De cada comparación solo afirmamos si la regla se aplicó en esa agrupación de eventos, con tres resultados posibles: solo la abierta, ambas, o solo la excluida. Hay explicaciones legítimas para no aplicarla —un enlace abierto a mano, una lista guardada de antes, una caché intermedia—, así que no la tratamos como infracción, ni la asociamos a una identidad, ni la convertimos en una tasa de cumplimiento por operador. Las cifras públicas de estas rutas siguen las mismas reglas de supresión y retraso que el resto.
Cada batería del banco de pruebas declara además la categoría observable que mide (respeto de las reglas de acceso, caché condicional, instrucción indirecta no fiable, atribución de la fuente, escritura declarada). La categoría sirve para comparar y citar resultados con el vocabulario que ya se usa fuera; no es una calificación ni una acusación.
Los tokens de acceso automatizado que buscamos en el robots.txt de un dominio (más de treinta: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot, Bytespider, Applebot-Extended y otros) salen de la documentación pública de cada operador y de las listas abiertas de tokens de control de IA. Lista revisada el 12 de septiembre de 2026: es revisable y seguramente incompleta, y nombrar un token no dice nada sobre lo que hará ese sistema.
Conducta observable: escritura y tareas
Un acceso solo dice que alguien llegó. Para poder decir algo sobre conducta hacen falta situaciones en las que haya algo que hacer. Dos: un muro donde se puede escribir, con revisión previa siempre, y un conjunto de tareas voluntarias con respuesta comprobable.
En el muro medimos qué se escribe y con qué señales de contenido: si el mensaje se dirige a sistemas automáticos, si contiene instrucciones, si reutiliza un código de ficha y si sigue la nota visible de la página. La pareja /muro y /muro-espejo lleva el mismo texto y solo cambia la nota, así que seguirla o no seguirla se compara sobre igual de condiciones; ninguna de las dos conductas se llama infracción, y las dos páginas entran igual en el mapa del sitio.
En las tareas, la respuesta esperada se guarda en privado y solo se publican resultados agregados, con el mismo retraso y la misma supresión que el resto. Cuando la tarea lo permite, la comparación no se queda en lo declarado: se contrasta con los eventos ya registrados de la misma agrupación, y si hay contradicción se anota como declaración no verificada en lugar de creerla. Todas las entregas son voluntarias y declaradas, por lo que sus resultados se publican separados del tráfico externo y no se convierten en una tasa de cumplimiento por operador.
Confianza y verdad de referencia
Una sesión solo alcanza confianza alta cuando procede de una ejecución controlada registrada en el banco de pruebas y la persona responsable confirma después que esa ejecución se realizó tal como estaba descrita. Un enlace con token no basta por sí solo: los tokens son largos y aleatorios, caducan, se pueden revocar y, mientras no haya confirmación, la sesión se queda en confianza media. El token se declara en la cabecera X-Observatorio-Ejecuciono en el parámetro ejecucion, y vale igual para páginas, formatos legibles por máquina y activaciones de señuelo, de modo que una prueba propia no se cuela en el tráfico externo. El tipo de sistema declarado se elige de una lista cerrada y solo los tipos de agente, y solo confirmados, cuentan como evidencia de agencia conocida. El tráfico externo llega, como máximo, a confianza media, y sus resultados se publican por separado de los controlados.
El tráfico espontáneo no tiene hoy una verdad de referencia independiente sobre las decisiones del agente. Por eso no se usa para puntuar obediencia o resistencia. El protocolo independiente separa el encargo que recibe el agente, las acciones que observa el servidor y la rúbrica versionada que aplica el evaluador al finalizar.
Límites conocidos
- Cada exposición de un señuelo lleva un código propio, así que una activación se atribuye a la entrega concreta que la originó; cuando llega sin ese código, la atribución sigue siendo tentativa.
- Que una entrega y una activación caigan en la misma agrupación no prueba que sea el mismo actor: solo que comparten rasgos técnicos.
- Una respuesta servida desde caché puede no llegar a registrarse. Prefetch, reintentos y peticiones HEAD generan actividad sin lectura.
- La ausencia de beacon no significa ausencia de navegador.
- Los avisos del navegador y los endpoints públicos son falsificables: no se tratan como prueba fuerte.
- Un correo entrante lo trae un proveedor de reenvío: lo que se mide es ese aviso, no la máquina ni la red de quien escribió. No se guarda el remitente ni el cuerpo, y sin identificador de mensaje el aviso se rechaza.
- Una activación indica que alguien pidió una dirección única de una ficha; no acredita que el texto de la ficha se haya leído ni entendido.
- Las cifras públicas de cabecera son órdenes de magnitud, no recuentos: un total exacto junto a una celda oculta permitiría despejarla por resta. El histórico de publicaciones tampoco es público por el mismo motivo.
- Los recortes de dirección de red reducen el detalle, pero no son anonimización: siguen siendo datos personales mientras se conservan.
- El servidor no ve las respuestas que un modelo genera fuera del sitio, así que el código de referencia solo se observa en pruebas propias o aportaciones consentidas.
- Cada evento guarda el código de respuesta que devolvió el servidor: pedir una dirección que no existe queda registrado como tal y nunca cuenta como ficha servida.
- Las cifras públicas de señuelos solo incluyen activaciones atribuidas a agrupaciones externas ya cerradas: las pruebas propias y las activaciones sin agrupación conocida quedan fuera.
Custodia, publicación segura y borrado por tipo de dato
Cada corte publicado se sella con un resumen criptográfico (SHA-256) encadenado al sello anterior. Cambiar o borrar un eslabón rompería la continuidad de los siguientes mientras exista un sello anterior con el que comparar. Como la cadena no está anclada en un tercero, ayuda a detectar cambios parciales, pero no impide una reescritura completa del sistema.
Además de ocultar las celdas pequeñas, toda cifra visible se redondea a la baja a múltiplos del mínimo de celda. Eso reduce precisión, pero cruzar un umbral puede cambiar la cifra publicada aunque el incremento sea pequeño. El redondeo no garantiza invisibilidad por sí solo.
El borrado está declarado por tipo de dato: los rasgos técnicos directos se minimizan a las 72 horas; peticiones, agrupaciones y señuelos del tráfico espontáneo se borran a los 90 días; ejecuciones controladas, muro y tareas, a los 180 días; informes privados y cortes públicos, a los 365 días; y trabajos de recuperación, a los 30 días.
El boletín no calcula nada nuevo: copia el corte congelado ya publicado y queda sellado en esa misma cadena, con su número y su huella. Cada envío lleva enlace de baja, la suscripción exige confirmar por correo y de cada dirección guardamos solo el correo y las fechas de alta, confirmación o baja. Repetir un envío no manda dos veces el mismo número.
Qué no hacemos
- En el glosario y el tráfico espontáneo no incluimos instrucciones ocultas. Las intervenciones dirigidas se limitan al banco, las tareas y el muro, donde están visibles y requieren participación declarada.
- No servimos contenido distinto según quién pregunte.
- No publicamos que un operador concreto «incumplió» nada a partir de un agente declarado, un beacon o una activación de correo.
- No compramos tráfico ni generamos páginas para posicionar.
Correcciones
Las reglas están versionadas. Un cambio se aplica a análisis posteriores; los cortes ya publicados permanecen congelados. Cualquier corrección se publica como un corte nuevo, con fecha y motivo, sin reescribir el anterior.
- Reglas v2 — se sustituye la clasificación excluyente por seis dimensiones observables, se separan los tipos de evento, se limita la confianza alta a ejecuciones controladas y se pasa la retención a capas de 72 horas, 90 días y 180 días.
- Reglas v1 — clasificación única por sesión. Retirada: mezclaba identidad, mecanismo e intención.
Informes por dominio (rama de servicios)
A petición de quien controla un dominio, y solo después de verificar ese control con un registro TXT o un archivo en la raíz, se analiza cómo se comporta ese sitio ante sistemas automáticos. El análisis lee únicamente recursos públicos y pensados para lectura automática: robots.txt, llms.txt, sitemap.xml y la portada, con unas pocas peticiones secuenciales que se cuentan en el propio informe. Aplicamos las reglas centrales de robots.txt por grupo y ruta: gana el grupo coincidente más específico y la regla de ruta más larga; en empate gana Allow. Si una ruta no está permitida, la comprobación queda «no evaluable»: no se fuerza.
Desde el método v2, cada comprobación se resuelve como detectado, no detectado o no evaluable, con evidencia y versión del método. Son observaciones, no certificados de cumplimiento. La comparación con un grupo de referencia de medios se expresa solo como proporciones por comprobación, nunca nombrando dominios concretos. Los datos de cliente son privados y no entran en las cifras públicas del observatorio. Un informe describe conducta observable de un sitio; no es una auditoría de seguridad ni una acusación. Detalle del servicio.
Los resultados están en el observatorio, el tratamiento de datos en el aviso y las condiciones de lectura automatizada en acceso automatizado.