Durante años diseñamos sitios pensando principalmente en dos usuarios.
El primero era obvio: la persona.
El segundo no siempre era tan visible, pero condicionaba buena parte del trabajo: el buscador.
Ahora empieza a aparecer un tercero.
Un agente de IA que no entra únicamente a leer una página, sino que intenta hacer algo dentro de ella en nombre de una persona.
Buscar un producto. Comparar opciones. Completar un formulario. Reservar una cita. Añadir algo al carrito. Solicitar una cotización.
Ese cambio todavía está en una etapa temprana y sería un error venderlo como si mañana todo el tráfico web fuera a funcionar así.
Pero también sería un error ignorarlo.
Chrome está desarrollando nuevas herramientas específicamente para esta llamada agentic web, entre ellas WebMCP y una nueva categoría de auditoría en Lighthouse para evaluar qué tan bien puede interactuar un agente con un sitio.
La pregunta ya no es únicamente:
¿Puede alguien encontrar y entender mi web?
También empieza a ser:
¿Puede un agente utilizarla correctamente?
De “encontrar una web” a “usar una web”
Esta distinción ayuda a entender prácticamente todo el tema.
Google la formula de manera bastante sencilla:
1. Los agentes buscan en la web.
2. Los agentes utilizan la web.
Cuando un agente está intentando encontrar información, muchos de los principios que ya conocemos siguen aplicando: SEO, contenido, rastreo, arquitectura, accesibilidad de la información y autoridad.
Cuando el agente llega a una web e intenta completar una acción, aparece un problema diferente.
Pensemos en estas peticiones:
“Busca una consulta con este abogado para el próximo martes.”
“Reserva un tour privado en Roma para cuatro personas.”
“Cotiza el reemplazo de este techo.”
“Añade este producto al carrito y comprueba el coste del envío.”
Para una persona, resolver estas tareas implica interpretar botones, leer labels, abrir menús, rellenar campos y reaccionar a cambios visuales.
Un agente tiene que reconstruir ese mismo recorrido mediante información legible por máquinas.
Y ahí es donde una web aparentemente “bonita y funcional” puede empezar a fallar.
¿Qué ve realmente un agente cuando entra en una web?
No necesariamente ve la página como nosotros.
Los agentes pueden utilizar distintas representaciones, entre ellas screenshots, HTML y, de manera especialmente importante, el árbol de accesibilidad de la página.
Eso tiene una consecuencia interesante.
Muchas decisiones que llevamos años defendiendo por accesibilidad, calidad de desarrollo y UX también facilitan el trabajo a los agentes.
Por ejemplo:
- botones con nombres claros;
- formularios correctamente etiquetados;
- HTML semántico;
- estados previsibles;
- navegación coherente;
- elementos interactivos identificables;
- layouts estables;
- mensajes de éxito y error comprensibles.
Una interfaz que depende excesivamente de animaciones, posiciones cambiantes, iconos sin labels o comportamientos visuales implícitos puede ser perfectamente comprensible para una persona y mucho más difícil de interpretar automáticamente.
Por eso la llamada web agent-ready no empieza necesariamente instalando una nueva tecnología.
Empieza haciendo bien la web.
Entonces, ¿qué es WebMCP?
WebMCP, o Web Model Context Protocol, es un estándar web propuesto para que una página pueda exponer herramientas estructuradas a agentes de IA.
En lugar de obligar al agente a deducir:
“Creo que ese botón sirve para reservar y después tengo que rellenar esos cinco campos…”
la web puede explicarle directamente:
“Tengo una acción llamada bookAppointment y necesita estos datos.”
Chrome describe WebMCP como una forma de proporcionar herramientas mediante JavaScript o anotaciones en formularios HTML para que el agente sepa con mayor claridad cómo interactuar con determinadas funciones de la página.
La idea importante no es el nombre del API.
Es el cambio de modelo.
Antes:
Agente → observa interfaz → intenta interpretar acciones → simula clics → espera que funcione.
Con herramientas estructuradas:
Agente → descubre capacidades disponibles → conoce los parámetros necesarios → ejecuta una acción definida por la propia web.
Eso puede hacer determinadas tareas mucho más fiables.
Un ejemplo sencillo
Imagina una clínica.
En la web existe un formulario con:
- especialidad;
- médico;
- fecha;
- hora;
- nombre;
- teléfono.
Un agente podría intentar completar ese proceso navegando visualmente por el sitio.
Pero la aplicación también podría exponer una herramienta conceptual como:
Reservar cita
que necesita:
- especialidad;
- fecha;
- horario;
- datos del paciente.
El agente ya no tiene que descubrir toda la lógica mirando el formulario.
La propia aplicación le está diciendo qué puede hacer y qué necesita para hacerlo.
Chrome plantea WebMCP precisamente alrededor de este tipo de acciones y utiliza ejemplos como reservar slots o añadir productos al carrito.
¿Significa esto que todas las webs necesitan implementar WebMCP?
No.
Y aquí conviene frenar un poco el entusiasmo tecnológico.
WebMCP sigue siendo un estándar propuesto, no una característica universal que todas las empresas deban integrar inmediatamente. Chrome lo mantiene dentro de un proceso experimental y la especificación continúa evolucionando.
Además, hay una diferencia enorme entre una web corporativa donde el usuario principalmente lee información y una plataforma donde los usuarios necesitan ejecutar acciones complejas.
Una web corporativa sencilla
Probablemente obtiene más valor inmediato de:
- HTML semántico;
- buena accesibilidad;
- estructura clara;
- formularios comprensibles;
- buena arquitectura;
- performance;
- SEO.
Ecommerce
Puede empezar a tener casos mucho más interesantes:
- buscar productos;
- consultar inventario;
- añadir al carrito;
- comparar opciones;
- calcular costes.
SaaS
Todavía más:
- crear recursos;
- consultar datos;
- cambiar configuraciones;
- ejecutar workflows.
Reservas y servicios
También resulta natural:
- comprobar disponibilidad;
- reservar;
- cotizar;
- cancelar;
- modificar citas.
Por eso la pregunta correcta no es:
“¿Instalamos WebMCP?”
Es:
¿Qué tareas críticas realizan nuestros usuarios y tendría sentido que un agente pudiera realizarlas de forma fiable?
La mejor preparación para agentes sigue siendo una buena web
Aquí hay una parte del tema que me parece más importante que WebMCP.
Chrome lanzó en 2026 una nueva categoría de Agentic Browsing dentro de Lighthouse.
¿Y qué revisa?
No únicamente si existe WebMCP.
También elementos mucho más familiares.
Accesibilidad
Los agentes dependen en buena medida del árbol de accesibilidad.
Por eso es importante que los elementos interactivos tengan nombres programáticos claros.
Estabilidad visual
Lighthouse utiliza señales relacionadas con estabilidad de layout porque un elemento que cambia inesperadamente de posición puede provocar que un agente interactúe con algo diferente de lo previsto.
WebMCP
También puede revisar herramientas registradas, formularios que podrían exponerse declarativamente y la validez de los esquemas utilizados.
Y hay un detalle importante.
Google indica que, por ahora, esta categoría es informativa y no está benchmarkeada como una puntuación tradicional de Lighthouse.
Es decir, todavía no existe un “92/100 en agent-ready” que debamos perseguir como nueva obsesión.
Estamos hablando de señales de preparación, no de otro número para poner en un reporte.
7 cosas que revisaría antes de llamar “agent-ready” a una web
1. HTML semántico
Un botón debería comportarse como botón.
Un enlace debería ser un enlace.
Un formulario debería utilizar controles reconocibles.
Cuanto más inventamos nuestra propia interfaz visual ignorando el comportamiento natural de HTML, más trabajo añadimos a personas, tecnologías de asistencia y ahora también agentes.
2. Accesibilidad
La accesibilidad sigue siendo primero para personas.
Que también beneficie a agentes no debería invertir esa prioridad.
Labels, nombres accesibles, jerarquía, focus y estados claros ayudan a crear una representación más comprensible de la interfaz.
Chrome señala precisamente el árbol de accesibilidad como una de las principales formas en que un agente puede interpretar una página.
3. Formularios previsibles
Un formulario para pedir presupuesto puede parecer una cosa trivial.
Pero si los campos no tienen labels, la información aparece solo mediante placeholders, las validaciones cambian sin explicación, los estados de error desaparecen o los pasos dependen de animaciones, el proceso se vuelve más frágil.
Una buena UX para agentes empieza muchas veces con la misma pregunta que para una persona:
¿Está claro qué debo hacer ahora?
4. Estados estables
Una interfaz donde botones se desplazan, contenido aparece encima de otros elementos o el layout cambia continuamente puede generar interacciones incorrectas.
Chrome incluye precisamente estabilidad visual dentro de sus auditorías orientadas a agentic browsing.
Esto también recuerda algo importante:
Las animaciones no son el enemigo.
Las animaciones sin control sí pueden serlo.
5. Acciones bien definidas
Aquí empieza a tener sentido WebMCP.
En una aplicación con acciones importantes podríamos preguntarnos:
- ¿qué debería poder hacer un agente?;
- ¿qué parámetros necesita?;
- ¿qué devuelve?;
- ¿cuándo necesita confirmación?;
- ¿qué no debería ejecutar automáticamente?
No se trata de exponer cada botón de la web como una herramienta.
Chrome recomienda diseñar WebMCP alrededor de critical user journeys, es decir, recorridos realmente importantes para el usuario.
6. Seguridad y confirmaciones
Permitir que un agente ejecute acciones abre problemas que una web puramente informativa no tenía.
Chrome dedica documentación específica a la seguridad de WebMCP porque los agentes basados en LLM pueden ser vulnerables a indirect prompt injection: contenido que intenta manipular el comportamiento del agente.
Por eso las acciones sensibles necesitan controles.
No querríamos que una instrucción escondida en una página pudiera provocar automáticamente:
- una compra;
- una eliminación;
- un cambio crítico;
- una transferencia de información.
Las acciones irreversibles necesitan guardrails y, cuando corresponde, confirmación explícita del usuario.
Agent-ready no puede significar darle permiso a todo.
7. Medición y testing
No basta con declarar una herramienta y asumir que un agente la utilizará correctamente.
Los flujos necesitan probarse.
Chrome está desarrollando herramientas específicas para reproducir, depurar y validar estos recorridos.
El objetivo es muy parecido al QA tradicional:
¿La tarea que diseñamos realmente puede completarse?
WebMCP no es lo mismo que MCP
Los nombres se parecen demasiado y eso probablemente generará bastante confusión.
MCP, o Model Context Protocol, y WebMCP no resuelven exactamente el mismo problema.
Chrome explica expresamente que WebMCP no reemplaza a MCP.
Simplificando mucho:
MCP
Permite conectar sistemas, herramientas y datos con agentes a nivel de aplicación, backend o ecosistema.
WebMCP
Ayuda a que un agente que ya está interactuando con una página conozca mejor las capacidades que esa web le ofrece.
Una empresa podría terminar utilizando ambos.
No necesitamos elegir uno u otro como si fueran tecnologías competidoras.
Un buen sitio para humanos probablemente empieza con ventaja
Hay una conclusión interesante detrás de todo esto.
Muchas recomendaciones para hacer una web más accesible a agentes llevan años siendo recomendaciones para hacer mejores sitios.
HTML correcto.
Accesibilidad.
Formularios claros.
Layouts estables.
Estados previsibles.
Arquitectura comprensible.
Performance.
Eso me parece mucho más importante que perseguir el último atributo experimental.
La estrategia de diseño y desarrollo web debería tener esos fundamentos antes de preguntarse qué API nueva incorporar.
WebMCP puede convertirse en una capa adicional.
No debería convertirse en una excusa para ignorar problemas básicos.
Qué tipo de empresas deberían prestar atención primero
No todas tienen la misma urgencia.
Yo empezaría por negocios donde existe una tarea digital claramente ejecutable.
Ecommerce
Porque existe una secuencia bastante clara:
buscar → comparar → elegir → carrito → checkout.
Travel y hospitality
buscar disponibilidad → comparar opciones → reservar.
Salud y citas
servicio → profesional → fecha → reserva.
SaaS
consultar → configurar → crear → modificar → ejecutar.
Servicios profesionales
calificar necesidad → pedir información → reservar consulta → solicitar propuesta.
Marketplaces
buscar → filtrar → seleccionar → transaccionar.
Cuanto más importante sea la interacción dentro de la web, más interesante se vuelve este tema.
En una web editorial cuyo objetivo principal sea leer contenido, la prioridad probablemente seguirá estando mucho más cerca de Search, contenido, accesibilidad y experiencia.
Un framework sencillo: Find → Understand → Act → Confirm
Para analizar una web desde esta perspectiva no empezaría por WebMCP.
Empezaría por cuatro preguntas.
Find
¿Puede el agente encontrar la página o funcionalidad correcta?
Aquí entran:
- SEO;
- navegación;
- arquitectura;
- enlaces;
- búsqueda interna.
Understand
¿Puede interpretar qué puede hacer?
Aquí entran:
- HTML;
- accesibilidad;
- labels;
- semántica;
- estados;
- estructura.
Act
¿Puede completar la tarea de forma fiable?
Aquí pueden entrar:
- formularios claros;
- UI estable;
- WebMCP;
- herramientas estructuradas;
- APIs internas.
Confirm
¿Puede entender qué ocurrió después?
Compra completada.
Reserva confirmada.
Error.
Solicitud enviada.
Acción pendiente.
Una experiencia no termina cuando el agente hace clic.
Termina cuando sabe si la acción funcionó.
El gran cambio: la web empieza a tener dos interfaces
Esta es quizá la idea que más me interesa de todo este tema.
Hasta ahora pensábamos la interfaz principalmente como algo visual.
Botones.
Menús.
Cards.
Forms.
Pero WebMCP propone una segunda interfaz paralela:
la interfaz estructurada que una máquina puede consumir directamente.
Una persona podría seguir viendo:
Reservar cita
mientras que el agente descubre:
book_appointment
con un esquema preciso de los datos que necesita.
No significa que la web visual deje de importar.
Al contrario.
Las dos capas tienen que representar la misma lógica de negocio.
Eso abre una conversación mucho más interesante que “¿qué color debería tener el botón?”.
Es arquitectura de producto.
Lo que no haría todavía
No reconstruiría una web corporativa simplemente porque WebMCP existe.
No añadiría herramientas agentic a todas las funciones.
No expondría acciones sensibles sin un modelo de seguridad.
No vendería “agent-ready” como certificación.
No prometería que implementar WebMCP produce más tráfico.
No presentaría la experimentación actual como un estándar universal ya adoptado por todos los navegadores.
Y tampoco ignoraría el tema.
Estamos justo en el momento donde tiene sentido entenderlo, experimentar con casos concretos y mantener la arquitectura preparada, sin convertir cada experimento en una necesidad comercial urgente.
¿Qué debería hacer hoy una empresa?
Para la mayoría, empezaría por una auditoría bastante poco futurista.
1. Revisar accesibilidad.
2. Revisar HTML y semántica.
3. Revisar formularios y journeys críticos.
4. Revisar estabilidad y performance.
5. Identificar qué acciones tendría sentido delegar a un agente.
Solo entonces preguntaría:
¿Existe aquí un caso real para WebMCP?
Si la respuesta es sí, ya podemos definir herramientas, parámetros, permisos y confirmaciones.
Ese orden evita implementar tecnología simplemente porque está de moda.
¿Estamos ante el nuevo SEO?
No.
Al menos no de la manera en que se está planteando a veces.
Chrome distingue explícitamente entre:
agentes que buscan
y
agentes que actúan dentro de sitios.
Para la primera parte siguen aplicando principios de Search y descubrimiento.
Para la segunda aparecen nuevas necesidades de UX, accesibilidad, estabilidad e interfaces agentic como WebMCP.
Eso significa que estamos viendo una expansión del problema.
SEO ayuda a que la web sea encontrada.
El diseño y desarrollo ayudan a que pueda utilizarse.
La web agent-ready añade una pregunta nueva:
¿Puede también utilizarla correctamente un agente?
Para Cubo SEO, esa conexión entre Search + Web + IA es bastante más interesante que convertir WebMCP en otra sigla aislada.
Preguntas frecuentes
¿Qué es WebMCP?
WebMCP es un estándar web propuesto que permite que una página exponga herramientas estructuradas a agentes de IA mediante JavaScript o anotaciones de formularios HTML. Su objetivo es mejorar la fiabilidad con la que un agente puede ejecutar determinadas tareas dentro de una web.
¿WebMCP ya es un estándar definitivo?
No. Actualmente sigue siendo una propuesta en evolución y Chrome continúa experimentando con su implementación.
¿Necesito WebMCP para que ChatGPT o Google encuentren mi web?
No. WebMCP está orientado principalmente a interacción y acciones dentro de una web. Para descubrimiento y búsqueda siguen existiendo otras capas como SEO, crawling, indexación y contenido.
¿WebMCP reemplaza MCP?
No. Chrome especifica que WebMCP y MCP resuelven necesidades diferentes y pueden coexistir.
¿WordPress puede utilizar WebMCP?
Conceptualmente sí, porque WebMCP puede incorporarse sobre determinadas capacidades de una página. La conveniencia y la forma exacta de implementarlo dependen del sitio, sus formularios, su lógica y sus funcionalidades. Eso no significa que exista un plugin universal que convierta automáticamente cualquier WordPress en una web agent-ready.
¿Una web accesible funciona mejor para agentes?
En muchos casos sí. Chrome explica que los agentes pueden utilizar el árbol de accesibilidad como una fuente importante para interpretar la página, y sus auditorías agentic incluyen comprobaciones relacionadas con accesibilidad.
¿Implementar WebMCP mejora el SEO?
No existe evidencia oficial para afirmarlo. WebMCP está orientado a mejorar interacción y ejecución de tareas por agentes, no a aumentar rankings orgánicos.
La web no va a dejar de ser para personas
La parte más interesante de la web agentic no es imaginar un futuro donde desaparecen las interfaces.
Es entender que empieza a existir otra forma de utilizarlas.
Las personas seguirán necesitando buenas webs.
Los buscadores seguirán necesitando entenderlas.
Y algunos usuarios empezarán a delegar tareas a agentes que también tendrán que navegar, interpretar y actuar dentro de ellas.
Prepararse para eso no significa instalar mañana cada tecnología experimental.
Significa hacer algo bastante más útil:
construir una web clara, semántica, accesible, estable y preparada para exponer de forma estructurada las acciones que realmente importan.
Si quieres revisar si tu sitio tiene una buena base para humanos, buscadores y las nuevas experiencias agentic, puedes solicitar una evaluación estratégica con Cubo SEO.
