WebMCP es, probablemente, el estándar del que más se está hablando este año en la parte técnica del SEO. Y también uno de los que más confusión está generando. Lo impulsan Google y Microsoft, está en origin trial en Chrome desde mayo de 2026 y Gemini in Chrome ya lo usa. Es decir: esto ya no es una propuesta en un papel. Se puede probar hoy en una web real.
Esto ya lo adelanté en LinkedIn cuando salió el origin trial, y la conversación que se montó me confirmó que había que bajarlo a tierra con calma. Así que en este artículo te cuento qué es WebMCP explicado para SEOs (no para developers), cómo encaja con el SEO y el GEO, y qué encontré al analizar la preparación agéntica de 12 grandes webs españolas con el scanner de Clicandseo.
Qué es WebMCP (explicado para SEOs, no para developers)
WebMCP (Web Model Context Protocol) es un estándar web propuesto por Google y Microsoft, incubado en el W3C, que permite que tu web declare de forma explícita qué acciones puede ejecutar un agente de IA en ella: buscar, filtrar, reservar, añadir al carrito, enviar un formulario.
Hasta ahora, cuando un agente entra en tu web, va a ciegas: hace capturas de pantalla, interpreta el HTML y adivina dónde clicar. Con WebMCP, la web le entrega una lista de «tools» —herramientas con nombre, descripción y parámetros— y el agente deja de adivinar.
Aunque sí es cierto que tú puedes declarar lo que quieras, al final son ellos los que van a decidir.
Información que debes tener clara:
- Quién lo impulsa: Google y Microsoft, dentro del Web Machine Learning Community Group del W3C.
- Estado real: origin trial público desde Chrome 149 (mayo de 2026). Es decir, fase experimental abierta: puedes probarlo en tu web real, pero la especificación puede cambiar.
- Quién lo consume ya: Gemini in Chrome. Y el ecosistema se mueve: Cloudflare ya ofrece activar WebMCP desde su panel y OpenAI ha lanzado retos para construir apps sobre el estándar.
- Cómo probarlo: activando el flag
chrome://flags/#enable-webmcp-testingy con la extensión oficial Model Context Tool Inspector para depurar.
WebMCP vs MCP vs llms.txt vs Schema.org
Aquí hay un lío importante que veo repetirse en LinkedIn: confundir WebMCP con MCP. No son lo mismo, y no compiten entre sí. Son cuatro capas distintas de la web máquina-legible:
| Capa | Qué hace | Dónde vive | Para qué sirve |
|---|---|---|---|
| Schema.org | Describe qué ES tu contenido | En tu HTML | Que buscadores y LLMs entiendan tus entidades |
| llms.txt | Guía de lectura para LLMs | Archivo en tu raíz | Orientar qué contenido leer y citar |
| MCP | Conecta agentes con tu backend | Servidor aparte | Integraciones servidor a servidor (API) |
| WebMCP | Declara qué se puede HACER en tu web | En tu navegador, en la propia página | Que un agente ejecute tareas en tu interfaz, con tu sesión y tu lógica |
Es decir: MCP conecta agentes con backends y requiere montar un servidor aparte. WebMCP vive en el navegador, dentro de la sesión del usuario, y reutiliza la lógica, la autenticación y el estado que tu web ya tiene. Se complementan, no se sustituyen.
Cómo funcionan ambas APIs
No te voy a soltar un tutorial de programación (para eso ya está la documentación de Chrome). Pero sí necesitas entender las dos vías, porque la decisión de cuál usar es más estratégica que técnica.
La API declarativa: atributos sobre lo que ya tienes
Es la vía rápida. Coges un formulario que ya existe en tu web y le añades atributos HTML que describen qué hace:
<form toolname="reservar-cita"
tooldescription="Reserva una primera consulta en la clínica">
<input name="fecha" type="date"
toolparamtitle="Fecha"
toolparamdescription="Día preferido para la consulta">
<button type="submit">Reservar</button>
</form>Nada más. Sin programar lógica nueva. Chrome sintetiza la tool a partir del formulario, el agente la rellena y el usuario confirma. Para la mayoría de webs, esta vía es el 80% del valor.
La API imperativa: JavaScript para flujos complejos
Para lo que un formulario no cubre —flujos de varios pasos, validaciones, estado— existe navigator.modelContext.registerTool(): registras la tool con JavaScript, defines sus parámetros con JSON Schema y controlas exactamente qué se ejecuta.
navigator.modelContext.registerTool({
name: "buscar-vuelo",
description: "Busca vuelos por origen, destino y fecha",
inputSchema: { /* JSON Schema */ },
async execute({ origen, destino, fecha }) {
// tu lógica de siempre
}
});El humano sigue al mando. Y esto es importante
Un detalle que casi nadie cuenta: la propia especificación declara como non-goal los flujos totalmente autónomos. WebMCP está diseñado para que el usuario supervise: el agente propone, rellena y compara; la persona confirma. Human in the loop de serie.
Esto desmonta el discurso apocalíptico de «los agentes van a sustituir tu web». No: van a usarla. Y la usarán mejor o peor según cómo la tengas preparada.
Cómo encaja WebMCP con el SEO y el GEO
Vamos a lo que nos interesa. Y empiezo con una aclaración, porque veo que se están mezclando cosas que no son lo mismo: WebMCP no tiene mucho que ver con el GEO como tal. El GEO no deja de ser una serie de estrategias nuevas —con bastante debate alrededor, porque quienes venimos del SEO defendemos que forma parte de él— cuyo objetivo es que los LLMs te escojan como fuente y ganar así visibilidad en sus respuestas. WebMCP es otra cosa distinta: un protocolo que le permite a tu web decirle a los agentes qué pueden hacer en ella.
Ahora bien, aunque sean cosas distintas, se tocan en el mismo recorrido del agente. Por eso me gusta verlo como un embudo de dos capas:
Capa 1 — Descubrimiento. Nada nuevo por aquí: SEO clásico y GEO (lo desarrollo en la guía de estrategias para aparecer en ChatGPT). Que Google te posicione, que ChatGPT, Perplexity y Gemini te citen y te recomienden. En las peticiones genéricas —«compárame vuelos a Roma», «búscame una clínica de fertilidad en Madrid»— el agente tirará, con mayor probabilidad, de las webs mejor posicionadas y más citadas. Pero sin absolutismos, porque un agente también puede llegar a tu web aunque tu posicionamiento sea flojo. Si un cliente le pide «cómprame un jamón en RH Gourmet», el agente irá a la web de RH Gourmet a por ese jamón, esté como esté su SEO para «jamones». La marca también trae agentes.
Capa 2 — Ejecución. Esta es la nueva. El agente aterriza en tu web —porque te ha elegido o porque el cliente te ha pedido por marca— con una tarea concreta: reservar, comprar, pedir presupuesto. Si puede completarla, conviertes. Si no puede —porque tu formulario solo envía con JavaScript custom, porque tus botones son divs con onclick, porque tu WAF le cierra la puerta—, el agente se va a ejecutar a la web de tu competencia. Eso es una conversión perdida que no verás en ningún informe de posiciones.
Aspectos que no cambian
Crawling, indexación, enlaces, autoridad, EEAT, contenido útil. Todo eso sigue mandando, porque es lo que alimenta la capa de descubrimiento. WebMCP no sustituye nada de esto.
Qué sí cambia
- El HTML semántico pasa de consejo a requisito funcional. Llevamos años diciendo «usa un botón de verdad, no un div». Ahora un div con onclick no es solo mala accesibilidad: es una acción que el agente no puede ejecutar.
- Nace una capa nueva de indexación: la de capacidades. Los agentes no solo indexarán qué dices, sino qué se puede hacer en tu web. Las descripciones de tus tools serán tan importantes como hoy lo son tus titles.
- Métricas nuevas. Tool success rate, invocaciones de agente, tareas completadas frente a abandonadas. El «rebote agéntico» —el agente que llega y no puede actuar— va a doler más que el rebote clásico.
Qué he descubierto gracias a un análisis propio de 12 grandes webs españolas
No es teoría. Para este artículo pasé 12 webs españolas de primer nivel —retail, viajes, banca, seguros, telco y salud— por el Agent-Ready Scanner de Clicandseo, que mide con la misma vara si los sistemas de IA pueden leer, entender y actuar en cada web: acceso real de bots, datos estructurados, renderizado, contenido para LLMs y superficie de capacidades/acciones. Configuración completa, con render JavaScript activado.
Los resultados, de mejor a peor:
| Web | Sector | Nota /100 | Veredicto del scanner |
|---|---|---|---|
| vithas.es | Salud | 58,8 | Agent-aware |
| mapfre.es | Seguros | 54,7 | Mejorable |
| elcorteingles.es | Retail | 54,0 | Agent-aware |
| movistar.es | Telco | 49,2 | Mejorable |
| bancosantander.es | Banca | 44,3 | Legible, no operable |
| iberia.com | Viajes | 40,9 | Flojo |
| zara.com | Retail | 38,8 | ⚠ No evaluable (bloqueo total) |
| sanitas.es | Salud | 37,5 | Legible, no operable |
| vueling.com | Viajes | 36,7 | Flojo |
| quironsalud.com | Salud | 36,6 | Puerta cerrada a agentes |
| renfe.com | Viajes | 36,3 | Puerta cerrada a agentes |
| pccomponentes.com | Retail | 33,4 | Legible, no operable |
Media: 43,4 sobre 100. Y ninguna —ninguna— alcanza el nivel «Agent-ready». Las mejores se quedan en «Agent-aware»: saben que los agentes existen, pero no les dan una superficie real de acción.
Lo que más me llamó la atención:
- 4 de 12 tienen problemas serios de acceso. Zara directamente no es evaluable: su WAF bloquea la sonda. Renfe y Quirónsalud se sirven con normalidad a un navegador pero rechazan a los bots de IA: el veredicto literal del scanner es «un agente que intente leerla se topa con el muro». Y PcComponentes bloqueó el acceso normal; su contenido solo se pudo leer identificándose como ChatGPT-User. Estas webs están invirtiendo en SEO mientras le cierran la puerta en las narices al canal que viene.
- La identidad y control de bots es el punto más débil de todos. Ni una sola de las 12 pasa del 43 sobre 100 en esa categoría, y casi todas comparten el mismo aviso: sin política de bots documentada. Es decir, ni siquiera han decidido qué quieren hacer con los agentes. No es que hayan elegido bloquear: es que no han elegido.
- Leen, pero no dejan actuar. El patrón dominante es «Legible, no operable»: te leen, no te entienden bien, no te usan. Mucho contenido, cero superficie de acción. Santander, Mapfre y Movistar puntúan decente en contenido y renderizado, y luego se desploman en capacidades y acciones (20, 0 y 20 respectivamente).
La lectura que hago es que las grandes webs españolas están, a medias, preparadas para ser leídas por la IA. Para que un agente haga algo en ellas, no lo está prácticamente ninguna. Y esa es exactamente la brecha que WebMCP viene a cerrar: quien la cierre primero en su sector se lleva las tareas completadas de todos los demás.
¿Quieres saber dónde está tu web (y la de tus competidores)? Puedes comprobarlo tú mismo con el Agent-Ready Scanner de Clicandseo: metes tu dominio y hasta dos competidores, y te devuelve el desglose completo con evidencias. Y la otra mitad del recorrido —cuánto te mencionan y citan los LLMs— se mide con Clicandseo.
Cómo prepararte: el checklist en 4 fases
Esta es la parte práctica, la misma que compartí en LinkedIn y que aquí te desarrollo. La buena noticia es que casi todo lo que pide WebMCP es higiene técnica que ya deberías tener.
Fase 1 — Audita. Identifica tus 5-10 flujos críticos: contacto, demo, checkout, búsqueda, reserva. Lista los formularios que más conversiones generan. Y mide tu baseline de visibilidad en IA (ChatGPT, Perplexity, Gemini) antes de tocar nada: sin punto de partida no hay forma de medir el impacto. Aquí es donde el scanner de arriba te hace el trabajo sucio.
Fase 2 — Limpia el HTML. HTML semántico en lugar de divs con JavaScript custom. Labels claras, inputs predecibles, redirecciones estables. Si tu formulario solo envía con JavaScript, replantéalo antes de seguir. Hecho significa que un agente (o un usuario con lector de pantalla, que para el caso es lo mismo) puede completar tus flujos sin adivinar.
Fase 3 — Implementa la API declarativa. Empieza por 3 formularios clave, no por toda la web. Añade toolname y tooldescription, anota cada input con toolparamtitle y toolparamdescription. Chrome rellena por defecto y el usuario confirma. Mide antes de escalar.
Fase 4 — Refuerza y mide. Schema.org en las páginas que exponen tools. Activa el flag de Chrome 149 y prueba con el Model Context Tool Inspector. Y vigila las métricas nuevas: tool success rate, latencia, flujos completados. Documenta tu política de bots —en el análisis de arriba, casi ninguna web la tiene, y es lo primero que penaliza.
Preguntas frecuentes sobre WebMCP
¿WebMCP sustituye al SEO?
No, WebMCP no sustituye al SEO. El SEO y el GEO influyen en que el agente te encuentre y te elija (aunque también puede llegar directo si el cliente pide tu marca); WebMCP determina qué puede hacer una vez está en tu web. Son capas complementarias del mismo recorrido.
¿Cuál es la diferencia entre MCP y WebMCP?
La diferencia entre MCP y WebMCP está en dónde viven: MCP conecta agentes con backends mediante servidores dedicados, mientras que WebMCP vive en el navegador, dentro de la página y de la sesión del usuario, y reutiliza la lógica y autenticación que tu web ya tiene.
¿Qué navegadores soportan WebMCP?
Los navegadores que soportan WebMCP hoy son Chrome a partir de la versión 149 y los basados en Chromium, dentro del origin trial. Safari y Firefox no lo soportan por ahora, aunque al tratarse de una propuesta de estándar en el W3C la puerta está abierta a que se sumen.
¿Cómo pruebo WebMCP en Chrome?
Pruebas WebMCP en Chrome activando el flag chrome://flags/#enable-webmcp-testing (Chrome 149 o superior) y usando la extensión Model Context Tool Inspector para ver e invocar las tools registradas. Para probarlo en producción, apúntate al origin trial de Chrome.
¿Funciona en WordPress?
Sí, WebMCP funciona en WordPress. La API declarativa son atributos HTML sobre formularios: se pueden añadir en cualquier CMS. Para la API imperativa necesitas poder insertar JavaScript, que en WordPress es trivial.
¿Cómo sé si mi web está preparada para los agentes de IA?
Sabes si tu web está preparada para los agentes de IA revisando tres cosas: que los bots de IA puedan acceder a tu web (robots.txt, WAF, CDN), que tu HTML sea semántico y tus flujos clave funcionen sin depender de JavaScript custom, y que tengas datos estructurados en condiciones. Puedes automatizar el diagnóstico con el Agent-Ready Scanner de Clicandseo, que analiza 45 factores y te compara con tu competencia.
¿Debería implementar WebMCP ya?
Sí, deberías implementar ya las fases 1 y 2 de WebMCP (auditar y limpiar HTML): es higiene técnica que te beneficia hoy. La fase 3 (anotar formularios), en 3-5 formularios clave si tu negocio depende de reservas, leads o ecommerce. Migraciones masivas, todavía no.
Mi opinión y cierre de todo esto
Te lo digo como se lo diría a un cliente que me lo preguntara mañana: WebMCP no te va a mover la aguja este trimestre. No es un quick win, no es «implementa esto ya o mueres», y quien te lo venda así te está vendiendo humo. Es un origin trial: experimental, solo Chromium, y puede cambiar.
Pero —y este pero es importante— sí creo que va a ir más rápido de lo que muchos prevén. Lo pienso porque llevamos apenas tres o cuatro años de auge de ChatGPT, y mira todo lo que ha conseguido en ese tiempo. La gente ya no dice «lo he buscado en Google» para cualquier duda rápida; va a ChatGPT, sea tech o no lo sea. Esa masa de usuarios es la que empuja. El día que los LLMs funcionen de verdad como agentes —«oye, entra aquí y resérvame esto»— la adopción no va a ser gradual, va a ser exponencial. Como todo en esta ola.
¿Quién podía pensar hace diez meses que íbamos a tener agentes de verdad trabajando por nosotros en tantos sitios? Parecía utopía. Y aquí estamos.
Eso sí, tengo igual de claro que el humano no va a soltar el volante del todo. No vamos a querer que la IA elija por nosotros en todo. Querremos que el agente compare precios, rellene el formulario, prepare la compra… y tomar nosotros la decisión final. Por eso el diseño human-in-the-loop de WebMCP me parece un acierto y no una limitación: encaja con cómo vamos a querer usar esto de verdad.
Mi predicción honesta es que en uno o dos años, WebMCP (o lo que evolucione a partir de él) va a ser bastante más importante de lo que hoy visualizamos. No mañana. Pero la web se está reorganizando para los agentes, y esto tiene toda la pinta de ser una pieza central. Lo que sí es un hecho: quien llegue con la web ordenada cuando eso ocurra, jugará con ventaja. Mientras tanto los agentes ya navegan por su cuenta: Claude estrenó navegador propio en Cowork.
La conclusión que saqué escribiendo esto es la misma que defiendo desde el primer post: no corras, pero no mires a otro lado. La media de un 43 sobre 100 en las grandes webs españolas significa que nadie tiene esto resuelto — y que la ventaja de moverse con cabeza es real.
Aporta algo que solo tú tengas y deja tu web lista para que la usen. Las dos cosas.
¿Quieres que analicemos tu web y la de tus competidores? Comprueba tu agent readiness aquí o escríbeme y lo vemos juntos. Es justo el trabajo que hago en la auditoría Web Agent.
