Esta semana Moz publicó un Whiteboard Friday explicando NLWeb, la iniciativa open source de Microsoft para preparar las webs para la era agéntica. El tema me pareció relevante para The Clic Lab, pero cuando empecé a analizarlo en profundidad me surgieron varias preguntas técnicas que creo que vale la pena responder antes de hablar de implementación. Porque NLWeb es interesante, pero hay una consecuencia que nadie está señalando todavía.
Qué es NLWeb
NLWeb, abreviatura de Natural Language Web, es un proyecto open source lanzado por el equipo de Microsoft en primavera de 2025 que ha ganado tracción significativa en los últimos meses. Su objetivo es que cualquier web pueda comunicarse directamente con agentes de IA a través de lenguaje natural.
Detrás del proyecto está R.V. Guha, la misma persona que inventó Schema.org y RSS. No es casualidad: NLWeb es en buena medida la evolución lógica de todo ese trabajo de estructuración de datos que el sector lleva haciendo más de una década.
El funcionamiento básico es este: cuando un agente o un usuario hace una consulta compleja a una web con NLWeb activado, en lugar de rastrear página por página, puede usar el protocolo ASK para obtener una respuesta directa. Crystal Carter, Head of AI Search en Wix, lo ilustra bien en el vídeo de Moz con un ejemplo concreto: alguien que busca una zapatilla de tenis para pista de arena, talla específica, con un presupuesto determinado. Una búsqueda tradicional daría un resultado genérico. NLWeb puede responder esa consulta con precisión porque accede directamente a los datos estructurados del sitio.
La pregunta técnica que me surgió: ¿cómo funciona realmente el endpoint ASK?
Hasta aquí, la explicación habitual de NLWeb. Pero cuando intenté entender el mecanismo real, me surgió una duda básica: si el schema markup está en el HTML de cada página, ¿no tiene el agente que rastrear e interpretar ese HTML igualmente? ¿Qué cambia realmente respecto a lo que ya ocurre hoy?
La respuesta está en entender qué es el endpoint ASK. No es que el agente vaya página por página leyendo schemas. Lo que NLWeb hace es exponer un punto de acceso específico en tu servidor, algo como tudominio.com/ask, donde el agente puede hacer una pregunta en lenguaje natural y tu servidor responde consultando directamente tu base de datos interna, sin que el agente tenga que cargar ningún HTML.
Es más parecido a una API que a un rastreador. El schema markup no es la base de datos del endpoint, sino el lenguaje común que hace que tus datos sean interpretables de forma estándar. NLWeb sabe cómo leer tus datos porque están organizados según vocabularios conocidos de Schema.org. Pero la consulta no pasa por renderizar páginas: el agente pregunta, tu servidor busca en sus propios datos y devuelve la respuesta.
La consecuencia que nadie está mencionando: el coste se traslada a tu servidor
Y aquí está el punto que me parece más relevante y que no he visto discutido en ningún sitio.
En el modelo tradicional de rastreo, el coste computacional es del lado del agente o del buscador: son ellos quienes cargan tu HTML, interpretan tu contenido y procesan la información. Tu servidor simplemente sirve las páginas.
Con NLWeb el modelo se invierte. El agente hace una pregunta limpia al endpoint. Es tu servidor quien procesa la consulta, busca en sus datos, genera la respuesta y la devuelve. El coste computacional se traslada al lado del propietario del sitio.
Esto conecta directamente con algo que ya analizamos en este medio: el 57% del tráfico web ya es automatizado. Si los agentes empiezan a adoptar NLWeb de forma masiva y cada consulta agéntica genera una carga de procesamiento en tu servidor, el impacto en la infraestructura puede ser significativo. NLWeb democratiza la web agéntica, pero traslada el coste operativo a los propietarios de los sitios. Es algo que cualquiera que esté pensando en implementarlo debería tener en cuenta.
Para quién tiene sentido NLWeb realmente
El protocolo ASK funciona muy bien cuando hay una base de datos real detrás que responder: un catálogo de productos, un directorio de servicios, un sistema de reservas, un inventario. Para ese tipo de webs, NLWeb tiene un valor claro e inmediato: un agente puede obtener información precisa sobre disponibilidad, precios o especificaciones en una sola consulta sin rastrear cientos de fichas.
Para webs de contenido informacional, el beneficio es mucho más difuso. Y esto conecta con algo que ya hemos analizado aquí: el contenido informacional lleva tiempo perdiendo relevancia como fuente de tráfico. El schema markup para artículos y contenido editorial es comparativamente limitado frente al de productos o negocios locales, y el endpoint ASK tiene poco que responder cuando no hay una base de datos transaccional detrás.
Dicho de otra forma: si tienes un e-commerce, un directorio o cualquier web con datos estructurados en una base de datos real, NLWeb merece atención ahora. Si tienes un blog o un medio de contenido, la prioridad es otra: seguir trabajando la autoridad, la citabilidad y la estructura del contenido para ser relevante en las respuestas de los LLMs, no montar un endpoint que responda consultas que nadie va a hacer.
Cómo implementarlo si decides hacerlo
Para quienes sí encajan en el primer perfil, la implementación tiene dos vías. La primera es técnica: el proyecto está disponible en GitHub con documentación completa, y si tienes desarrolladores en el equipo pueden montar el endpoint siguiendo la documentación del repositorio oficial liderado por R.V. Guha. La segunda es más accesible: Wix ya tiene una integración nativa que se activa con un solo toggle para webs premium con dominio personalizado.
En cualquier caso, el punto de partida sigue siendo el mismo de siempre: tener bien implementados los schemas correctos con los campos relevantes, y una estructura HTML limpia y semántica. Todo el trabajo que ya deberías tener hecho es exactamente la base sobre la que NLWeb construye. La pregunta no es si tienes que empezar de cero, sino si tienes bien hecho lo que ya deberías tener.
