Hay tres generaciones de optimización web y la mayoría de los sitios está atrapada en la primera.
La primera generación es SEO tradicional. Optimizar títulos, meta descriptions, keywords, backlinks para que Google te indexe y te posicione. Funciona. Lleva 25 años funcionando. Pero resuelve un solo problema: que humanos te encuentren en una lista de 10 resultados azules.
La segunda generación es GEO, Generative Engine Optimization. Optimizar estructura semántica, JSON-LD, llms.txt, Content Signals para que los modelos de IA te citen cuando generan respuestas. Resuelve un problema más nuevo: que las máquinas te reconozcan como fuente confiable.
La tercera generación es lo que llamo Agentic SEO. No optimizar para que te lean ni para que te citen sino para que te usen. Que un agente de IA pueda llegar a tu sitio, descubrir tus herramientas, y usarlas directamente sin intervención humana. Tu sitio deja de ser un documento para convertirse en un servicio que las máquinas consumen.
De documento a servicio: qué significa en la práctica
Un sitio optimizado para SEO tradicional es como un libro en una biblioteca. Google lo cataloga y los humanos lo buscan. Un sitio optimizado para GEO es como un libro con un resumen ejecutivo que las IAs pueden leer rápido y decidir si citar. Un sitio optimizado para Agentic SEO es como una herramienta en un taller. No necesitas leerla para usarla. Simplemente funciona.
Mi blog tiene un generador de llms.txt. Hoy, un humano tiene que abrir la URL, escribir su dominio en el campo, y hacer click en generar. Un agente de IA debería poder hacer exactamente lo mismo: descubrir que la herramienta existe, entender qué hace, navegar a ella, llenar el campo, y obtener el resultado. Sin que un humano lo guíe paso a paso.
Eso requiere tres capas que la mayoría de sitios no tiene.
Capa 1: Descubrimiento — Agent Skills
El agente necesita saber que la herramienta existe. Para eso sirve el archivo /.well-known/agent-skills/index.json que ya implementé. Es una lista de las herramientas disponibles en el sitio con nombre, URL y descripción.
{
"skills": [
{
"name": "llms.txt Generator",
"url": "https://shinobis.com/tools/llmstxt-generator",
"description": "Generate a valid llms.txt file for any website. Enter a URL and get a formatted llms.txt ready to deploy."
}
]
}La descripción no es para humanos. Es para el LLM del agente. Tiene que ser lo suficientemente clara para que el modelo decida si esta herramienta resuelve la tarea que tiene asignada.
Capa 2: Permisos — agent-permissions.json
El agente necesita saber qué puede hacer. Mi archivo de permisos permite read_content y follow_link globalmente, pero habilita click_element y set_input_value solo en /tools/**. Un agente que respeta estos permisos sabe que puede interactuar con las herramientas pero no debe hacer click en ninguna otra parte del sitio.
Capa 3: Estructura semántica del DOM
Esta es la capa que nadie está documentando. El agente llega a la página de la herramienta. Ve un formulario. ¿Cómo sabe qué campo llenar y qué botón presionar?
La respuesta está en los atributos HTML que ya existen pero que nadie usa pensando en agentes. Label explícito con for apuntando al input correcto. Placeholder descriptivo. Atributo name semántico. Atributo aria-label para contexto adicional. Botón submit con texto claro.
<label for="url-input">Website URL</label>
<input
type="url"
id="url-input"
name="website_url"
placeholder="https://example.com"
aria-label="Enter the URL of the website to generate llms.txt for"
required
/>
<button type="submit" aria-label="Generate llms.txt file">
Generate llms.txt
</button>Este HTML es exactamente el mismo que un humano vería. No hay nada extra. La diferencia es que cada elemento tiene suficiente contexto semántico para que un agente entienda qué hacer sin necesitar instrucciones adicionales.
El test: le pedí a Claude que usara mi herramienta
Para validar si la estructura funciona, le pedí a Claude que actuara como un agente navegando mi sitio. Le di las tres capas: el agent-skills para descubrir la herramienta, el agent-permissions para saber qué puede hacer, y la URL de la herramienta.
Claude identificó correctamente el formulario, entendió que necesitaba llenar el campo de URL, y describió los pasos que ejecutaría para obtener el resultado. Sin instrucciones adicionales. La semántica del HTML fue suficiente.
Esto no es una demo académica. Es la dirección real de la web. Cloudflare lanzó Browser Rendering para agentes. OpenAI tiene Operator. Google tiene agentes de navegación. El sitio que esté preparado para ser usado por agentes tendrá una ventaja que los demás no podrán replicar fácilmente.
La evolución del stack completo
Si miro lo que construí en los últimos cuatro meses como un stack, tiene cinco capas:
Identidad: llms.txt dice quién soy. Accesibilidad: Markdown for Agents sirve contenido limpio. Descubrimiento: Agent Skills lista las herramientas. Permisos: agent-permissions.json declara las reglas. Usabilidad: HTML semántico permite la interacción.
Cada capa se construye sobre la anterior. Sin identidad, el agente no sabe si el sitio es relevante. Sin accesibilidad, no puede leer el contenido eficientemente. Sin descubrimiento, no sabe qué herramientas hay. Sin permisos, no sabe qué puede hacer. Sin usabilidad semántica, no puede interactuar aunque tenga permiso.
Un blog con PHP vanilla, hosting compartido y cero frameworks tiene las cinco capas implementadas. Si esto es posible sin infraestructura enterprise, la pregunta no es si vale la pena sino por qué no lo tiene todo el mundo.
