La web se construyó para navegadores. Parece obvio, pero explica mucho. Un sitio suele evaluarse por lo que ocurre después de que un navegador lo carga: ¿se ve bien?, ¿es suficientemente rápido?, ¿la persona encuentra lo que vino a buscar?, ¿el texto tiene sentido?, ¿la interfaz transmite confianza?
Con el tiempo, la web también se volvió legible para otros sistemas. Los buscadores aprendieron a indexarla. Las plataformas sociales, a mostrar vistas previas. Las herramientas de analítica, a observarla. Las API expusieron partes de ella. Feeds, sitemaps, metadatos y datos estructurados se convirtieron en maneras de que un sitio dijera algo más sobre sí mismo que lo que mostraba la página visible.
Ahora se está volviendo habitual otro lector: los agentes. No lo digo en un sentido de ciencia ficción, sino como software común que puede obtener una página, resumirla, compararla con otra, monitorearla, responder preguntas o decidir el próximo paso. Algunos sistemas son simples; otros tienen más capacidades. Lo importante es que intentan construir una comprensión operativa del sitio, además de mirar una página una vez.
La mayoría de los sitios no los ayuda demasiado, y no por falta de contenido. La web tiene más contenido del que cualquiera puede leer. El problema es que muchos sitios no se explican con claridad. Muestran páginas, pero rara vez dicen qué significan dentro de su estructura. Exponen enlaces, pero no siempre cuáles importan. Devuelven HTML, pero no siempre suficiente para entender la página sin ejecutar una gran aplicación cliente. Los metadatos pueden faltar, estar duplicados, desactualizados o escritos sólo para vistas previas.
Una persona tolera bastante ambigüedad. Podemos leer por encima, inferir, recorrer enlaces y reconocer que una página es importante porque está en la navegación, que una descripción faltante no es fatal o que un error probablemente se deba a un límite de solicitudes.
El software tiene más dificultades. Puede adivinar, y los sistemas modernos lo hacen sorprendentemente bien, pero adivinar no es entender. Esa es la brecha que sigo viendo: un sitio puede estar muy bien diseñado y revelar casi nada sobre sus rutas, los artefactos que son la fuente de referencia, qué se generó, qué falló durante un rastreo, si faltan metadatos, si se necesitó JavaScript o qué límites condicionaron el resultado. La página es visible. El sistema, no. Creo que esa distinción va a importar cada vez más.
Una capa de registros
«Web legible para agentes» puede sonar más futurista de lo necesario. No creo que la web necesite una enorme capa de magia, que cada sitio deba convertirse en una API ni que haya que optimizar cada página para sistemas automatizados a costa de las personas. Propongo algo más simple: que los sitios publiquen mejores registros de lo que ocurre.
Un registro, o *receipt*, no es una presentación comercial, una declaración de marca ni un resumen seguro de sí mismo pensado para impresionar. Es constancia de lo que pasó.
En un sitio, podría significar:
- se descubrieron estas rutas;
- se obtuvieron estas páginas;
- se generaron estos archivos;
- se declaran estas capacidades;
- ocurrieron estos fallos;
- se aplican estas advertencias;
- estos límites condicionaron el resultado.
Son datos simples, cercanos a logs, manifiestos, comprobaciones de salud, salida de builds y diagnósticos. Dan algo para inspeccionar en vez de pedir que lo creas.
Por eso encuentro útil, pero incompleta, la conversación sobre `llms.txt`. Un punto de entrada en texto plano para herramientas que quieren entender un sitio es mucho mejor que pedirle a cada sistema que extraiga todo desde cero. Le da al sitio una puerta de entrada, pero una puerta no es un mapa.
Un archivo de texto puede presentar el sitio, pero no puede contener todo lo que un agente o una persona cuidadosa necesitaría: cobertura del rastreo, metadatos faltantes, fallos parciales, inventario de rutas, capacidades del runtime, artefactos generados o la diferencia entre lo observado y lo inferido. Eso hace de `llms.txt` el comienzo de una estructura más amplia.
El próximo paso no tiene que ser necesariamente un estándar. Quizás sea temprano para eso. Puede ser un hábito: cuando el software observa o genera un sitio, debería dejar pequeños artefactos que expliquen qué sabe.
El problema de los rastreos exitosos
Un problema curioso de muchos rastreadores es que están demasiado interesados en parecer exitosos. Si una página falla, el error suele perderse en los logs. Si faltan metadatos, continúan en silencio. Si el sitio es principalmente una aplicación cliente y el HTML estático casi no contiene información significativa, pueden devolver igual un resultado que parece terminado.
Eso crea confianza sin observabilidad. Un resultado limitado no es en sí el problema: algunas páginas están protegidas, algunos sitios limitan solicitudes, otros necesitan JavaScript, faltan metadatos o se rompen enlaces. La web es desordenada. El problema es aparentar que el resultado contiene más de lo que contiene.
Si el rastreo sólo vio tres páginas, hay que decirlo. Si una ruta falló con un 429, hay que registrarlo. Si faltan descripciones, hay que advertirlo. Si no se ejecutó JavaScript, hay que hacerlo explícito. Si se obtuvo `robots.txt` sólo para conocer sus directivas y no para aplicarlas, hay que decirlo claramente.
Un artefacto así no exagera ni se desarma porque el mundo sea imperfecto. Dice: esto observé, esto no pude observar y estos son los límites del resultado.
Es mucho más útil que una mentira bien presentada.
Un pequeño prototipo
Construí un prototipo llamado `agentify` para explorar esta idea. Es deliberadamente modesto. Obtiene un sitio, sigue enlaces del mismo origen desde la página de inicio hasta un límite pequeño de páginas, extrae metadatos básicos de las rutas y escribe un conjunto de archivos explicativos:
agent/
system.json
runtime.json
context.json
llms.txtNo ejecuta JavaScript, no rastrea en profundidad, no inicia sesión, no infiere el comportamiento privado del backend ni afirma que el sitio sea seguro, completo o esté bien documentado. Esa moderación es parte de la idea.
La versión actual se identifica como un renderizador de HTML estático. Registra que no se ejecutó JavaScript ni se hizo un rastreo recursivo. Registra si el rastreo fue completo o parcial. Genera códigos de advertencia para títulos y descripciones faltantes, páginas que dependen mucho de JavaScript y rastreos parciales.
Además de un resumen, produce un registro de lo ocurrido. El conjunto es lo suficientemente pequeño para leerlo a mano. Una persona puede empezar por `llms.txt` para ver la explicación en lenguaje natural. Un script puede leer `runtime.json` para saber qué pasó durante la generación. Otra herramienta puede leer `context.json` para encontrar rutas y encabezados. `system.json` puede describir la estructura descubierta del sitio.
No es infraestructura espectacular. Me gusta justamente por eso: tiene la estructura necesaria para reducir las conjeturas.
La demo que parecía un fracaso
La prueba que más aclaró la idea fue una aplicación que dependía mucho de JavaScript. El resultado era limitado: había pocos metadatos útiles de título y descripción; el HTML estático revelaba poco de las rutas. El artefacto advertía que parecía necesario ejecutar JavaScript para acceder al contenido significativo.
A primera vista parece que el rastreador falló. Creo lo contrario: hizo exactamente lo que quería. No simuló que una página casi opaca se había vuelto comprensible. Esa distinción importa.
Si un rastreador dice «completo» pero la comprensión real es mayormente ficticia, el sistema que recibe el resultado parte de una base falsa. Puede resumir con confianza, recomendar mal, comparar dos sitios como si ambos fueran igualmente visibles o tratar la falta de evidencia como evidencia.
Un rastreo honesto ofrece un contrato mejor. Puede decir: el resultado está completo dentro de los límites declarados, pero la página estática tenía poco contenido. O: el rastreo es parcial porque una ruta falló. O: estos archivos se generaron sin ejecutar JavaScript, así que no los trates como un renderizado completo de la aplicación. Ahí empieza la confianza.
Por qué también importa para las personas
Es fácil presentar esto como una necesidad de las máquinas. Pero las personas también lo necesitamos. Quien haya heredado una base de código conoce la sensación de intentar entender un sistema desde afuera. ¿Dónde están las rutas importantes? ¿Qué genera el build? ¿Qué archivos son fuente y cuáles generados? ¿Qué cambió? ¿Qué falló? ¿Qué cree ser este proyecto?
La buena documentación, el buen código y los buenos nombres ayudan. Pero los sistemas también necesitan hechos actuales, simples y generados sobre sí mismos.
Por eso exploro ideas similares en Paideia, el pequeño framework con el que está construido este blog. Además del sitio, genera artefactos del runtime: una descripción del sistema, un archivo de identidad, contexto compacto y un punto de entrada `llms.txt`.
La filosofía es la misma que en `agentify`, desde la dirección opuesta. `agentify` adapta algo existente: intenta describir lo que se puede observar. Paideia genera de forma nativa: ya sabe qué creó y puede describir el sistema directamente. Los dos caminos importan.
Adaptar importa porque la mayor parte de la web ya existe. No podemos pedirle a cada sitio que se reconstruya antes de volverse más inspeccionable. Una herramienta pequeña que produzca un registro útil desde afuera es práctica.
La generación nativa importa porque es más directa. Un framework no necesita adivinar sus propias rutas, artefactos, capacidades o diagnósticos: puede publicarlos como parte del build. Adaptar sirve; generar la explicación desde el origen es más sólido. Ambos caminos apuntan a que el software haga más fácil inspeccionar su estructura.
Salvedades
Hay varias. Algunos sitios no pueden exponer demasiada estructura sin crear problemas de seguridad o abuso. Algunos rastreos deberían respetar `robots.txt` con más profundidad que un prototipo. Algunas páginas necesitan contexto autenticado. Algunos sitios son dinámicos a propósito. Hay metadatos difíciles de resumir y agentes que van a usar mal incluso buenos artefactos.
También existe el riesgo de inventar demasiados archivos demasiado rápido. La web no necesita otra pila de formatos ceremoniales que nadie mantiene. Si estos registros resultan útiles, tendrán que seguir siendo pequeños, simples y cercanos a hechos que el software ya conoce.
Por eso me interesan más los ejemplos que funcionan que las declaraciones. Una lista de rutas sirve. El estado de un rastreo sirve. Un código de advertencia y un inventario de artefactos sirven. Una afirmación vaga de que un sitio está «listo para IA» no sirve.
El estándar debería llegar después del hábito, si llega.
Qué quiero decir con legible para agentes
Un sitio legible para agentes publica suficiente contexto para que otro sistema se comporte con más cuidado. No necesita halagar agentes, llenarse de palabras clave para modelos de lenguaje, reemplazar los textos humanos con instrucciones para máquinas ni asumir que la automatización es su audiencia principal.
Puede ser algo modesto.
Puede significar una guía en texto plano, un inventario de rutas, metadatos precisos, un registro del runtime, advertencias cuando un rastreo queda incompleto o decir «esta página necesita JavaScript» cuando el resultado estático no era significativo.
La web pasó décadas optimizando su presentación. Ese trabajo sigue importando y las personas deberían seguir siendo la primera audiencia de la mayoría de los sitios. Pero la presentación y la posibilidad de inspeccionar son cosas distintas.
A medida que más software lee, compara y actúa sobre la web, la posibilidad de inspeccionar pasa a formar parte de la superficie pública del sitio. No todos necesitan la misma profundidad: un blog personal, un servicio estatal, documentación, una tienda y un dashboard privado tienen riesgos y responsabilidades distintos.
El principio compartido es pequeño: no obligar a otros sistemas a adivinar más de lo necesario. Publicar lo que existe, decir qué falló, marcar los límites, mantener los artefactos legibles y permitir que personas y herramientas inspeccionen los mismos hechos.
Esa es la web legible para agentes que quiero: una web que siga siendo humana y donde el software sea más honesto sobre lo que sabe.