Un asistente de IA no abre tu web como lo hace una persona. Recibe una pregunta, busca fuentes y decide en segundos cuáles merecen una cita. Si tu sitio no le dice qué es cada página, adivina. Yo tenía ese problema con la nueva web de Libelium y lo resolví con un motor propio en WordPress, sin Yoast. Te cuento qué hice, qué salió mal y hasta dónde puedo asegurar que sirve.
Esto encaja dentro de la reescritura completa de libelium.com e iris360. El briefing pedía trabajar tres capas a la vez. SEO para capturar demanda explícita, AIO para que los asistentes comprendan el contenido y GEO para que la marca aparezca en respuestas generativas.
La carta del restaurante
Un comensal con prisa no entra en la cocina a preguntar qué hay. Mira la carta. Si la carta es un folio con 31 platos y cinco recomendados, se pierde el resto de la oferta. Si es un tocho de 98 KB, se cansa antes de pedir.
Un fichero llms.txt hace de carta para un modelo. El reto está en que sea completo sin ser interminable.
Primero, lo básico estaba roto
El 18 de septiembre una auditoría con PageSpeed Insights puntuó el SEO de la home en 61. Esperaba un problema de textos. Al abrir el motor encontré que generaba la descripción para redes sociales desde el extracto, pero nunca imprimía la meta descripción. En ninguna página. El defecto estaba en el código.
Añadí la etiqueta y un filtro que lee el título de un campo propio. Después curé a mano título y descripción de las 29 páginas que registraba entonces el generador de landings, con títulos de 50 a 60 caracteres y descripciones de 137 a 165. Un barrido con curl devolvió HTTP 200, una sola meta descripción y un solo canonical en las 29.
La verificación destapó un segundo fallo. Cada título acababa con "Libelium" duplicado salvo en la portada, porque WordPress añadía su sufijo sobre el título ya curado. Lo corregí sustituyendo el array completo de partes. Sin el barrido, ese error habría salido a producción.
Las entradas de blog y casos de éxito siguieron con el extracto automático. Ese barrido es del 18 de septiembre y no consta que lo repitiera tras retirar el generador de landings.
Datos estructurados según el tipo de página
La producción antigua servía el mismo grafo genérico de WebPage, WebSite, Organization y BreadcrumbList en cualquier página. Yoast solo veía título y resumen. Mi motor lee los campos de negocio que ya rellena cada ficha, porque comparte con ella el modelo de tipos de contenidoGlosarioCPT (Custom Post Type)Tipo de contenido personalizado de WordPress, registrado con register_post_type, que añade a las entradas y páginas nativas tipos propios como un producto, una certificación o un caso de éxito.
Cada CPT define sus campos, sus URLs y sus taxonomías. Separar los tipos de contenido permite modelar datos con relaciones claras, por ejemplo una página pública de producto enlazada a una ficha técnica sin URL propia.Ver término completo →.
Siempre imprime un bloque Organization. En soluciones y productos añade un Product cuya descripción sale del problema que resuelve la solución. En casos de éxito y entradas añade un Article. Las soluciones que lo permiten llevan además un HowTo. Las migas de pan dejan el tramo intermedio sin enlace, porque ninguno de esos tipos tiene archivo público y enlazarlo daría un 404.
El 5 de octubre unifiqué el Article y cambié un detalle de fondo. El editor de los casos de éxito era el nombre del cliente, y ahora apunta a la organización del sitio. El cliente pasa a ser el tema del artículo.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Solución de ejemplo",
"description": "Frase que resume el problema que resuelve la solución.",
"brand": { "@type": "Brand", "name": "Empresa de ejemplo" },
"url": "https://example.com/soluciones/ejemplo/",
"about": [{ "@type": "Thing", "name": "Vertical de ejemplo" }]
}La segunda pestaña muestra el cambio. El publisher apunta por @id al sitio y el cliente vive en about.
El llms.txt, y por qué lo recorté
El generador responde en /llms.txt, ordena páginas clave y tipos públicos, toma cada descripción del mismo campo de negocio que alimenta el JSON-LD y cachea el resultado 12 horas. La cabecera cambia con la marca, así que cada sitio decide la suya, como cuento en el post del monorepo con una carpeta por sitio.
La primera versión, del 22 de septiembre, cubría mucho más que el fichero de Yoast.
| Aspecto | Yoast, producción antigua | Motor propio, primera versión |
|---|---|---|
| Páginas listadas | 31 | 158 |
| Casos de éxito listados | 5 de más de 130 | Todos |
| Peso | 5,2 KB | 78,6 KB |
Las dos columnas salen de entornos distintos, la producción de entonces y el entorno de pruebas. La tabla muestra cobertura y no una mejora medida.
Aquí me incomodé. Dos días después otra medición daba 98 KB y 208 enlaces, unos 25.000 tokens solo de índice. El formato de llmstxt.org pide un índice conciso, con descripciones de una línea y una sección ## Optional. Un fichero que se come la ventana de contexto antes de empezar a responder no ayuda a nadie.
Recorté con tres decisiones. Descripciones de 150 caracteres como máximo. Los casos de éxito, a un segundo fichero enlazado desde ## Optional y agrupado por vertical. Del blog, solo las 10 últimas entradas, sin descripción. El índice quedó en 7,3 KB y 35 enlaces. Ese mismo día reincorporé páginas, equipo y webinars, que Yoast sí listaba y yo había perdido, y cerré en 19 KB con 8 secciones.
Me costaron dos tropiezos. WordPress enviaba cabecera 404 con el cuerpo correcto, y lo arreglé forzando un status_header(200). La caché de página, además, servía un 404 antiguo hasta que la vacié. Los transients viven en Redis, así que borrarlos con WP-CLI no los alcanza y hay que vaciar la caché de objetos.
Abrir la puerta a los bots
El robots.txt por defecto de WordPress ya no bloquea a nadie. Aun así añadí una regla Allow: / explícita para 13 agentes de OpenAI, Anthropic, Perplexity, Google, Apple, Bing y Common Crawl. No cambia lo rastreable. Deja por escrito una decisión, la de permitir tanto a los rastreadores de entrenamiento como a los agentes que navegan en vivo. Un Allow no obliga a ningún bot a visitar el sitio ni a citarlo.
Lo que no puedo afirmar
No tengo medición posterior al corte del 7 de octubre. Faltan las citas en respuestas generativas, el tráfico referido desde asistentes y el posicionamiento. El briefing exige línea base, definición, fuente y responsable antes de prometer una mejora, y aplico esa regla aquí. Ningún dato mío indica que un asistente concreto consulte llms.txt. Tampoco imprimo hreflang, aunque ya existen versiones traducidas con TranslatePress, y no consta una revisión de esas etiquetas. Las cifras del llms.txt son del entorno de pruebas.
Si vas a hacer algo parecido, la lección es esta. Con código solo abres la puerta, y que te citen depende del contenido que haya detrás, que cubro en la regla de verdad de los datos de producto. Audita lo básico antes de sofisticar nada, porque mi mayor ganancia vino de una etiqueta que faltaba. Y trata el llms.txt como una pieza barata de mantener que todavía no ha demostrado nada. La teoría de fondo está en navegación agéntica y SEO para IA, en la referencia de WebMCP y llms.txt y en la lección SEO, AIO y GEO, capas y datos estructurados.