Un cliente me llamó el octubre pasado, asustado. Su sitio de comercio electrónico estaba recibiendo mucho tráfico de lo que su análisis mostraba como visitas "directas", pero las conversiones habían bajado. Después de revisar los registros del servidor durante aproximadamente una hora, me di cuenta de que una porción significativa de ese tráfico no eran humanos en absoluto. Eran agentes de IA, específicamente asistentes de compra y herramientas de comparación impulsadas por LLM, rastreando sus páginas de productos y rebotando porque no podían analizar el contenido correctamente. Los datos estructurados eran un desastre. Los precios estaban enterrados en JavaScript. Los nombres de los productos vivían en etiquetas <h3> estilizadas para parecer <h2>. Los agentes llegaban, encontraban ruido y se iban.
Así es donde estamos ahora. Los agentes de IA no están viniendo. Ya están aquí, ya están leyendo tus sitios, ya están tomando decisiones basadas en lo que pueden o no extraer. Y la mayoría de los más de 12.000 sitios que he construido o tocado a lo largo de los años en Seahawk Media no fueron construidos teniendo esto en mente. Probablemente los tuyos tampoco.
Qué Significa Realmente "Legible para Agentes"
Déjame ser directo sobre algo. Legible para agentes no significa "amigable con IA" en el sentido vago del marketing. Significa que una máquina puede llegar a una URL, analizar el contenido sin ejecutar tres capas de JavaScript, extraer lo que está buscando y actuar sobre ello. Eso es todo.
Los humanos somos indulgentes. Escaneamos. Inferimos. Vemos un número grande en una página de precios y sabemos que es el precio aunque esté envuelto en un <div class="fancy-number">. ¿Un agente de IA siguiendo un flujo de trabajo estructurado? No tan indulgente. Necesita señales, jerarquía y previsibilidad.
Los agentes que hacen este trabajo ahora incluyen herramientas como la de navegación de OpenAI, el modo en línea de Perplexity, y decenas de agentes personalizados construidos con frameworks como LangChain y AutoGen. Todos comparten una necesidad común: HTML limpio, parseable, semánticamente significativo con datos estructurados de apoyo.
El Problema Real: Arquitectura Orientada a JavaScript
Este es el que veo más frecuentemente. Las agencias y freelancers construyen sitios en React o Next.js (o Vue, o Svelte, está bien), hacen renderizado del lado del cliente, y consideran que el trabajo está terminado. El sitio se ve hermoso. Google puede rastrearlo, más o menos, porque Googlebot ahora tiene un renderizador Chrome headless incorporado.
Pero la mayoría de los agentes de IA no están ejecutando Chrome headless. Están obteniendo HTML sin procesar vía HTTP. Si tu contenido solo existe después de que JavaScript se ejecute, esos agentes obtienen una página en blanco o un spinner de carga serializado como texto.
En 2022, Seahawk tenía un cliente fintech que había construido su sección completa de tasas y comparación de productos en una SPA de React. Sin SSR, sin fallback estático. Ejecutamos un simple curl contra su URL y obtuvimos literalmente 14 líneas de HTML: un <div id="root"> y algunas etiquetas de script. Eso es lo que un agente ve. Catorce líneas.
La solución no es necesariamente abandonar tu framework de JS. Es renderizado del lado del servidor (SSR) o generación de sitios estáticos (SSG). Next.js con getServerSideProps o getStaticProps. Nuxt para Vue. SvelteKit. Incluso solo pre-renderizar páginas clave con algo como Prerender.io si estás atrapado en una configuración heredada. El contenido necesita estar en la carga útil HTML inicial.
HTML Semántico Ya No Es Opcional
Lo sé. Has escuchado "usa HTML semántico" desde 2009. Pero no lo estoy diciendo por razones de SEO ahora. Lo estoy diciendo porque los agentes usan etiquetas semánticas para entender qué tipo de cosa están mirando.
<article>, <nav>, <main>, <aside>, <header>, <footer>, estas no son decorativas. Son señales. Un agente intentando extraer el contenido principal de una página buscará <main> primero. Si has construido tu layout con <div> anidados y nada más, el agente tiene que adivinar. Los agentes que adivinan mal devuelven respuestas incorrectas a los usuarios.
Esto es lo que audito en cada sitio ahora:
- ¿Hay exactamente un elemento <main> por página?
- ¿Los encabezados siguen una jerarquía lógica (<h1> a <h2> a <h3>) sin saltar niveles?
- ¿Los menús de navegación están en elementos <nav>?
- ¿El contenido complementario (barras laterales, posts relacionados) está en <aside>?
- ¿Los listados de elementos son realmente <ul> u <ol>, no una cadena de <div class="item">?
Esto parece básico. Y sin embargo, diría que el 60% de los sitios WordPress que reviso fallan en al menos tres de estas cosas. La de la jerarquía de encabezados es casi universal: los diseñadores estilizan los <h3> para que se vean grandes y los <h2> para que se vean pequeños, y nadie arregla el marcado debajo.
Schema Markup: Haz el Trabajo Real Aquí
Aquí es donde la mayoría de guías se vuelven genéricas. Intentaré no hacerlo.
Los datos estructurados de Schema.org le dicen a los agentes no solo qué hay en la página, sino qué tipo de cosa es. Un producto. Una receta. Un negocio local. Un FAQ. Un evento. Y proporciona esos datos en un formato que los agentes pueden consumir sin analizar prosa.
Los tipos que más importan ahora mismo, en mi experiencia:
- Producto (con ofertas, precio, disponibilidad, los tres siempre)
- LocalBusiness (con openingHoursSpecification y coordenadas geográficas, no solo una cadena de dirección)
- Article (con datePublished, dateModified y author como tipo Person, no una cadena de texto plano)
- FAQPage (más sobre esto abajo)
- BreadcrumbList (subestimado, le da a los agentes un mapa de la jerarquía de tu sitio)
- HowTo (si publicas tutoriales o documentación de procesos)
Para sitios WordPress uso Yoast SEO o Rank Math para lo básico, luego extiendo manualmente con schema personalizado en un bloque <script type="application/ld+json"> para cualquier cosa que no cubran. JSON-LD es el formato a usar. No RDFa, no microdata. JSON-LD. Mantiene el markup limpio y los agentes pueden extraerlo sin tocar tu capa de presentación.
Un error que cometí en 2021: puse schema en las páginas de producto de un cliente pero dejé el campo price vacío porque sus precios eran "contactar para cotizar." El validador de schema lo pasó. Pero los agentes extraían un precio en blanco y lo devolvían a los usuarios como "precio: desconocido," lo que destruyó la confianza. La solución fue incluir un rango de precios realista con minPrice / maxPrice, o eliminar el bloque offers completamente. Los datos parciales pueden ser peor que no tener datos.
Estructura de Contenido: Escribe para Extracción Legible
Lo que pasa con cómo los agentes leen prosa es esto. No la leen como lo haces tú. Están buscando respuestas a preguntas, hechos que puedan extraer, y relaciones claras entre afirmaciones.
Eso significa que tu estructura de contenido debe poner la respuesta al frente. Si alguien (o algo) pregunta "¿cuánto tarda la entrega?", tu página debería tener un encabezado que diga algo como "Tiempos de Entrega" y la primera oración bajo él debería indicar el número real. No un párrafo de contexto sobre las operaciones de tu almacén. El número primero, luego el contexto.
He comenzado a estructurar el contenido así en los sitios de clientes, casi como una pirámide invertida para cada subsección:
- Declara el hecho o la respuesta directamente en la primera oración bajo el encabezado
- Añade una o dos oraciones de contexto de apoyo
- Enlaza a un recurso más profundo si el tema lo justifica
Eso es todo. Sin párrafos de introducción. Sin "excelente pregunta, exploremos este tema juntos". Los agentes se saltan ese ruido y a veces identifican mal dónde comienza la respuesta real.
En un sitio de viajes que reconstruimos la primavera pasada, reestructuramos 80 artículos de esta manera en aproximadamente seis semanas. Las citas de Perplexity para esas páginas aumentaron notablemente. Lo más importante es que las respuestas a las que apuntaban esas citas eran realmente precisas, porque el hecho relevante era localizable.
Robots.txt, llms.txt, y Control de Acceso
Este es más reciente. Existe una convención creciente, aún no un estándar, para un archivo llamado llms.txt ubicado en la raíz de tu dominio. La idea, propuesta por Jeremy Howard, es darles a los LLM un mapa en texto plano del contenido más importante de tu sitio y cualquier preferencia de acceso. Piénsalo como un robots.txt pero escrito en inglés simple para agentes de modelos de lenguaje en lugar de bots de rastreo.
¿Deberías implementarlo? Honestamente, sí. Se tarda 20 minutos en escribir uno. Señala que tu sitio es consciente de los agentes, y a medida que más agentes se entrenen para buscarlo, se convertirá en una señal significativa.
Sobre robots.txt específicamente: sé deliberado. Algunos dueños de sitios están bloqueando reflexivamente todos los rastreadores de IA ahora. Esa es tu decisión, pero bloquear de manera general significa que tu contenido tampoco aparecerá en respuestas generadas por IA, que es un canal de distribución que estás abandonando. Piénsalo de la misma manera en que pensaste sobre bloquear a Googlebot en 2005. Probablemente no sea una gran idea.
Enlaces internos y arquitectura de rastreo
Un agente que sigue un flujo de trabajo no aterriza solo en una página. Sigue enlaces. La calidad de tu estructura de enlaces internos determina cuánto de tu sitio un agente puede realmente recorrer y entender.
Los enlaces internos deficientes significan que los agentes indexan una o dos páginas de tu sitio y se detienen. No obtienen la imagen completa de lo que ofreces.
Buenos enlaces internos significan:
- Cada página importante es alcanzable dentro de tres clics desde la página de inicio
- El texto de anclaje es descriptivo, no "haz clic aquí" o "lee más"
- El contenido relacionado se vincula contextualmente en el cuerpo, no solo en un widget de barra lateral
- Las páginas huérfanas no existen (o si existen, lo sabes y has elegido dejarlas así)
Ejecuto rastreos de Screaming Frog en sitios de clientes antes de cualquier trabajo de legibilidad de agentes. El informe de páginas huérfanas solo suele revelar contenido que los clientes creen que está publicado y es encontrable, pero no lo es. Un cliente tenía 34 páginas huérfanas, incluyendo sus principales casos de estudio. Nadie les estaba vinculando. Ni agentes, ni humanos.
FAQ
¿Necesito reestructurar todo mi sitio para que sea legible por agentes?
No. Comienza con tus páginas de mayor tráfico y tus páginas críticas para conversiones. Generalmente son tu página de inicio, tus páginas principales de servicios o productos, y cualquier contenido que ya está posicionado y generando leads. Hazlo bien primero en esas. Una auditoría de sitio completo es útil eventualmente, pero no es por donde empiezas.
¿El marcado de esquema realmente ayuda con las respuestas de agentes de IA?
Por lo que he observado en sitios de clientes, sí. Los agentes que extraen datos estructurados devuelven respuestas más precisas y atribuyen fuentes de forma más confiable cuando el esquema está presente. Dicho esto, no es una solución mágica. El contenido subyacente aún necesita ser preciso y estar bien estructurado. El esquema ayuda a los agentes a encontrar y confiar en los datos; no soluciona datos deficientes.
¿Qué hay con los sitios que tienen contenido pagado?
Usa la propiedad de esquema isAccessibleForFree en tu tipo Article, y el patrón hasPart / isPartOf para marcar qué secciones están pagadas. Esto le dice a los agentes qué pueden usar. La documentación de Google sobre datos estructurados de contenido pagado cubre esto claramente, y la misma lógica aplica a agentes que no son de Google.
¿llms.txt tiene amplio soporte ya?
No universalmente. Pero implementarlo cuesta casi nada, y la adopción temprana de convenciones como esta tiende a tener retorno. He añadido llms.txt a sitios de clientes de Seahawk desde principios de 2024. Es una señal pequeña ahora. Importará más en 12 meses.
¿Cómo pruebo si un agente puede leer mi sitio?
Comienza con curl -A "Mozilla/5.0" [tu URL] en una terminal y mira qué regresa. Si tu contenido principal no está en esa salida, tienes un problema de renderizado. Luego ejecuta tus páginas a través de la herramienta Rich Results Test de Google para validar schema. Y verifica el auditoría de accesibilidad de Chrome Lighthouse, porque la legibilidad para agentes y la accesibilidad se superponen más de lo que la mayoría de la gente se da cuenta.
---
La web se construyó para humanos y después se adaptó para motores de búsqueda. Ahora necesita otra adaptación, esta vez para agentes que no navegan como lo hace ningún humano. Eso no es una crisis. Es solo la siguiente ronda de trabajo. Y honestamente, la mayoría es buena práctica que hace que los sitios sean mejores para los humanos también. Markup más limpio, contenido más claro, menos expansión de JavaScript. Probablemente deberías haberlo hecho de todas formas.