Una página web ya no la leen solo las personas. También la recorren motores de búsqueda, crawlers IA, sistemas de previsualización, herramientas SEO y automatizaciones que a menudo necesitan respuestas distintas de las pensadas para un navegador humano.
La web ya no tiene un solo lector
Durante años diseñamos sitios imaginando a un usuario delante de una pantalla. Hoy eso es solo una parte de la historia. La misma página puede ser solicitada por Googlebot, un crawler IA, una herramienta de previsualización o un navegador tradicional.
El problema es que todos estos clientes no leen el sitio de la misma forma. Un navegador puede gestionar JavaScript, animaciones e interacciones. Un crawler IA puede preferir contenido compacto y legible. Un motor de búsqueda necesita metadatos claros, canonicals coherentes y datos estructurados.
LLM Proxy Worker nace de esta idea: no cambiar el sitio de origen, sino añadir delante una capa capaz de adaptar la respuesta según quién está leyendo.
Un proxy edge como capa inteligente
El Worker corre sobre Cloudflare Workers y se comporta como un middleware en el edge. Recibe la solicitud, observa URL, query params, User-Agent y headers, y decide qué recorrido aplicar.
Si llega un navegador humano, el sitio sigue respondiendo de forma normal, con posible enriquecimiento SEO. Si llega un crawler IA o una ruta de debug LLM, el Worker puede transformar el HTML en markdown. Si llega un crawler que tiene problemas con JavaScript, puede servir HTML prerenderizado.
Esta arquitectura es interesante porque añade capacidades transversales sin reescribir el CMS, el frontend ni el backend principal.
- navegador: página original o enriquecida con metadatos
- crawler IA: versión markdown más limpia y legible
- crawler de búsqueda: HTML prerenderizado cuando hace falta
- ruta de debug: respuestas diagnósticas para entender el comportamiento
Markdown para LLM: menos ruido, más contenido
Una página HTML completa contiene mucho más de lo que un modelo lingüístico necesita leer realmente: scripts, estilos, footer, navegación, banners, SVG, formularios y otros elementos técnicos.
Para un crawler IA, ese ruido consume tokens y puede alejar la atención del contenido real. La conversión a markdown sirve para devolver una versión más compacta, ordenada y cercana al texto útil de la página.
No es un atajo mágico. Es una decisión de interfaz entre el sitio y los sistemas automáticos: si el lector no es humano, la respuesta puede adaptarse a su forma de procesar información.
SEO generada con IA, pero con límites
La parte delicada no es llamar a un modelo. Es evitar que el modelo se convierta en una caja negra. En el proyecto, la generación SEO parte de datos reales: HTML de la página, keyword, datos SERP, intención de búsqueda, competidores y reglas calculadas por el código.
OpenAI es el proveedor principal, Claude es el fallback, pero el output no se acepta a ciegas. El resultado debe ser JSON válido y superar controles sobre title, description, Open Graph, canonical y JSON-LD.
Esto cambia el papel de la IA: no decide sola qué es importante, sino que trabaja dentro de un perímetro definido por el sistema.
Prerender solo cuando realmente sirve
Muchas páginas modernas dependen de JavaScript. Un navegador humano las ve correctamente, pero algunos crawlers pueden quedarse en el HTML inicial y perder parte del contenido.
Para estos casos el Worker puede usar Cloudflare Browser Rendering con Puppeteer: abre la página, deja ejecutar JavaScript y devuelve el HTML final. Es potente, pero también costoso comparado con una solicitud normal.
Por eso el prerender no se aplica a todos. Se activa solo para crawlers, reglas específicas o debug explícito. Los usuarios humanos se mantienen en el recorrido más ligero.
Cache, fallback y sostenibilidad
Una solución basada en LLM y Chromium puede volverse frágil si cada solicitud genera trabajo costoso. Por eso el proyecto usa Cloudflare KV para guardar metadatos SEO y HTML prerenderizado.
La primera solicitud puede generar el resultado. Las siguientes pueden reutilizarlo. Esto reduce tokens, llamadas externas, latencia y variabilidad del output.
La parte más importante es el comportamiento ante errores. Si DataForSEO no responde, si OpenAI falla, si Claude no está disponible o si Chromium entra en timeout, el sitio no debe romperse. El Worker vuelve a fallbacks razonables o a la página original.
La parte senior: decidir qué no hacer
Lo interesante de un proyecto así no es usar el mayor número posible de servicios. Es decidir cuándo no usarlos. Un LLM en cada solicitud sería llamativo, pero costoso, lento y poco predecible. Un navegador headless para cada visita sería potente, pero desproporcionado. Una cache usada como base de datos se convertiría pronto en un problema de coherencia.
El trabajo arquitectónico consiste en definir límites claros: qué solicitudes merecen IA, cuáles merecen prerender, cuáles pueden seguir el recorrido estándar y qué ocurre cuando un proveedor externo no responde.
Esa es la diferencia entre una demo que funciona en el caso ideal y un sistema capaz de vivir delante de tráfico real. No basta con añadir inteligencia: hay que contenerla, medirla y hacerla sustituible.
Una web legible también para las máquinas
LLM Proxy Worker no intenta sustituir el sitio. Intenta hacerlo más legible para los distintos lectores de la web moderna: personas, motores de búsqueda, crawlers IA y herramientas automáticas. Es un pequeño ejemplo de arquitectura adaptativa: mismo origen, respuestas distintas, costes controlados y fallbacks siempre presentes.
Seguir leyendo