Un cliente potencial busca un proveedor de servicios, compara lo que ofrece cada uno y quiere concertar una reunión de asesoramiento. Para ello podría ir visitando varias webs por su cuenta. O podría encargar a su asistente de IA que busque proveedores adecuados y le prepare una solicitud. En ese caso, es posible que su empresa ya haya pasado, o no, un primer filtro antes de que nadie abra su web.
Los agentes de IA en la web ya son una realidad, y Google recomienda expresamente a los desarrolladores tenerlos en cuenta como un tipo de visitante propio. En su guía «Build agent-friendly websites», advierte de las interfaces con estados hover complicados y diseños que se mueven, que los agentes no pueden usar de forma fiable. Una web puede resultar atractiva para un usuario y, aun así, ponérselo muy difícil a un agente de IA.
Al mismo tiempo, la web no es la única vía por la que un agente puede trabajar con su empresa. En este artículo vemos las dos cosas: cómo hacer que los agentes puedan usar su web y qué otros accesos se abren más allá de ella.
Qué hace un agente de IA en su web
Un agente de IA recibe un encargo, planifica los pasos necesarios y los ejecuta con ayuda de herramientas. En el navegador, eso puede significar abrir enlaces, comparar información, rellenar campos o completar un proceso de reserva. No se trata de resumir una página, sino de una tarea que exige varias acciones. Google pone como ejemplos, entre otros, los formularios de contacto y las reservas de viajes.
En una empresa de reformas, podría ser así: el agente comprueba si se ofrece el servicio que se busca y si la obra está dentro de la zona de trabajo de la empresa. Después busca los datos necesarios para la solicitud y prepara el formulario de contacto. Si falta un dato esencial o un control no responde de forma fiable, tiene que preguntar, probar otro camino o abandonar.
Para ello, los agentes analizan las webs de distintas maneras. Google describe el análisis de capturas de pantalla, el de la estructura HTML y el uso del llamado árbol de accesibilidad (accessibility tree). Muchos sistemas combinan estas fuentes. Por eso no basta con que una función se entienda a simple vista: su descripción técnica también tiene que dejar claro qué hace.
Por qué un botón bonito no es necesariamente un buen botón
Dos botones pueden verse idénticos en pantalla y estar construidos de forma totalmente distinta. Uno es un auténtico elemento button de HTML. El otro es una superficie cualquiera que solo parece un botón gracias al diseño y a programación adicional. Con el botón real, el navegador ya aporta el manejo con teclado y el rol reconocible de botón; en la versión imitada, los desarrolladores tienen que añadirlo. Ocurre algo parecido con los menús y los formularios, y estas diferencias apenas se notan al echar un vistazo rápido a la web terminada.
| Qué detecta el agente en la estructura | Botón real (elemento HTML «button») | Superficie imitada (convertida en botón por el diseño) |
|---|---|---|
| Rol | Botón | Solo si se ha añadido después |
| Nombre | «Solicitar cita» | No siempre está claro |
| Teclado | Lo aporta el navegador | Solo con programación adicional |
En pantalla, ambos se ven igual. Lo que evalúa un agente de IA depende de cada sistema; la tabla es una representación simplificada.
| Señal en la web | Por qué puede ser un problema | Qué ayuda en la implementación |
|---|---|---|
| Un submenú solo se abre al pasar el ratón por encima. | La navegación depende de un movimiento concreto del ratón. | Hacer que los submenús también funcionen con clic y teclado. |
| Las imágenes u otros contenidos desplazan la página después de cargar. | Un elemento en el que se iba a hacer clic cambia de repente de posición. | Reservar espacio para los contenidos que se cargan después y revisar los desplazamientos del diseño. |
| Una zona clicable no tiene el rol técnico adecuado. | La función no se deduce con claridad de la estructura de la página. | Usar botones reales para las acciones y enlaces reales para ir a otras páginas. |
| Los campos del formulario no tienen etiquetas claras. | No queda claro para qué sirve cada dato ni a qué campo pertenece. | Vincular técnicamente etiquetas descriptivas a cada campo. |
| Tras enviar el formulario no hay un mensaje claro. | No se sabe si el proceso ha funcionado o si hay que corregir algo. | Mostrar con claridad el éxito y los errores, y asignar cada error al campo afectado. |
Esto no significa que haya que renunciar a las animaciones o a las interfaces con diseño propio. Un control bien programado se puede seguir adaptando a su diseño. La clave es que el diseño, la función y la descripción técnica vayan de la mano.
La accesibilidad web también ayuda al nuevo visitante
El árbol de accesibilidad no es una técnica inventada para la IA. A través de él, el navegador ofrece una descripción simplificada y semántica de la página, que usan por ejemplo los lectores de pantalla. Indica qué rol tiene cada elemento, cómo se llama y en qué estado está. Por eso, las recomendaciones de Google para los agentes coinciden en gran parte con los requisitos que ya conocemos para las webs accesibles. Es una ventaja añadida, pero no sustituye al objetivo real: que cualquier usuario pueda usar una web, tenga o no alguna discapacidad y la maneje como la maneje.
En la próxima revisión de su web, no se limite a valorar los colores, las imágenes y los espacios. Antes de dar el proyecto por bueno, compruebe también el manejo con teclado, que las etiquetas se entiendan y que la estructura técnica esté limpia.
En el formulario de contacto, un detalle técnico se convierte en un asunto comercial
Supongamos que un agente ya ha identificado su empresa como un proveedor adecuado. El servicio encaja, la zona de trabajo coincide y las referencias convencen. Ahora tiene que preparar la solicitud. En este punto, de poco sirven más promesas sobre sus servicios si no está claro qué dato va en cada campo.
Los requisitos de un buen formulario no tienen nada de espectacular: etiquetas fáciles de entender, campos obligatorios bien señalados y mensajes de error que permitan corregir el fallo. «Se ha producido un error» no dice qué hay que hacer. «Por favor, indique su código postal» sí nombra el problema. El W3C recomienda además pedir solo los datos que de verdad hacen falta para cada proceso.
Distinga también bien entre una solicitud sin compromiso y una reserva de cita vinculante. Ni el texto ni el proceso deben permitir confundir una cosa con otra. Por eso, las vías de contacto y de reserva son lo primero que hay que revisar, antes de optimizar para los agentes otros elementos menos importantes de la página.
Google ofrece sus propias herramientas de análisis
El 22 de junio de 2026, Google presentó la nueva categoría «Agentic Browsing» para su herramienta de análisis Lighthouse. Entre otras cosas, revisa si las máquinas pueden interpretar las etiquetas, la estabilidad visual de la página y la integración de WebMCP. Eso sí, la categoría todavía es experimental, según la documentación requiere Chrome 150 o posterior y, en lugar de una puntuación global de cero a cien, muestra las pruebas superadas, los errores y las advertencias.
Un informe así no dice si un agente puede completar correctamente una solicitud concreta de un cliente. Un formulario puede tener unas etiquetas técnicamente impecables y, aun así, pedir datos que un cliente potencial todavía no puede dar en ese momento. Por eso, las pruebas técnicas siempre deben ir acompañadas de pruebas prácticas.
WebMCP: ofrecer funciones en lugar de dejar que el agente interprete cada clic
Además de una interfaz fácil de usar, aparece otra vía de acceso. Con WebMCP, las webs pueden ofrecer determinadas funciones de forma expresa a los agentes de IA compatibles. En lugar de deducir el significado de un formulario a partir de su aspecto y su estructura, el agente recibe una descripción definida de la función y de sus datos de entrada. En una reserva de citas, podría ser una función que consulta las citas libres en un periodo concreto, sin que el agente tenga que ir haciendo clic en un calendario. La interfaz para los usuarios no cambia.
A fecha de octubre de 2026, WebMCP todavía no es un estándar consolidado. Google lo desarrolla como propuesta de estándar web y señala que sigue en desarrollo y tiene limitaciones. Hay una que es especialmente importante para planificar: los navegadores y agentes compatibles tienen que abrir la web directamente para descubrir sus funciones. Es decir, WebMCP solo funciona mientras un agente está en su web.
No todos los agentes tienen que pasar por su web
Aquí merece la pena fijarse en el segundo acceso, que la propia Google pone sobre la mesa. WebMCP se inspira en el Model Context Protocol (MCP), pero no lo sustituye. Google explica la diferencia así: WebMCP solo está disponible en su web; MCP, en cambio, en cualquier momento y en cualquier plataforma. Un servidor MCP pone datos y funciones a disposición en segundo plano, tanto si alguien tiene abierta su web como si no. Google recomienda expresamente verlos como complementarios: MCP como base para la lógica principal y WebMCP como complemento directamente en la web.
| WebMCP | Interfaz MCP | |
|---|---|---|
| Qué es | Funciones en su web | Acceso en segundo plano |
| Cómo se llega | El agente visita la web en un navegador compatible | La interfaz está integrada en el asistente de IA conectado |
| Qué permite | La web ofrece funciones, p. ej. consultar directamente las citas libres | Consultar conocimiento autorizado, p. ej. servicios, zona de trabajo y referencias |
| Disponibilidad | Solo durante la visita a la web | Independiente de la visita a la web, una vez conectada |
En ambos casos rige la misma regla: consultar información, sí; los pasos vinculantes, como una reserva o una solicitud, solo con la autorización expresa del usuario. La tabla es una representación simplificada: los dos accesos se complementan y no sustituyen a una web fácil de usar.
Volvamos a la empresa de reformas del principio. Sin otra vía, un agente tiene que extraer de los menús, textos y formularios de la web si se ofrece el servicio, si la obra está dentro de la zona de trabajo y qué referencias encajan. A través de una interfaz MCP, un asistente de IA conectado puede consultar esa información de forma estructurada, tal y como la empresa la ha autorizado. No tiene que adivinar qué dato va en cada campo, porque cada función describe su propósito y sus datos de entrada.
Esta vía también tiene límites. Una interfaz MCP tiene que conectarse en cada asistente de IA y no todos los sistemas la usan automáticamente. Aporta información y funciones, pero la respuesta la sigue redactando el asistente. Y, como con WebMCP, una interfaz adicional compensa cuando resuelve un problema concreto, no por el simple hecho de ser una tecnología nueva.
Que un agente pueda usar su web exige límites
En cuanto un agente envía datos o ejecuta acciones vinculantes, los permisos y las confirmaciones cobran importancia. Google recomienda marcar los procesos con consecuencias para que el agente o el navegador pidan confirmación al usuario. La documentación de seguridad advierte además de los contenidos manipulados que pueden llevar a los agentes a hacer cosas no deseadas.
Por eso, las funciones que solo leen y las que cambian algo deben tratarse por separado. Consultar las citas libres no es lo mismo que reservar una cita de forma vinculante. Esto vale tanto para las funciones de su web como para una interfaz MCP independiente. Preparar una web para los agentes no consiste en quitar mecanismos de protección, sino en describir con claridad qué acciones están permitidas.
AI-Connect: el conocimiento de su empresa, directamente en el asistente de IA
Un asistente de IA no tiene por qué ir haciendo clic por su web para entender su oferta. Con AI-Connect ponemos a disposición de los asistentes la información y las funciones autorizadas de su empresa, a través de una interfaz de IA propia. Los asistentes conectados pueden responder así a preguntas sobre sus servicios, su zona de trabajo y el proceso, y preparar una solicitud que solo se envía cuando el usuario la autoriza.
Qué tiene que ver esto con el SEO y el GEO
En el SEO y el GEO, lo primero es que sus contenidos aparezcan y se tengan en cuenta en los resultados de búsqueda y en las respuestas de la IA. Los agentes afectan al paso siguiente: ¿qué pasa cuando un sistema tiene que hacer algo concreto con su empresa? La propia Google distingue entre los agentes que buscan en la web y los que actúan en las webs. Que su empresa aparezca en una respuesta de la IA no dice nada sobre si un agente podrá preparar después una solicitud.
De ahí salen tres preguntas que conviene revisar por separado: ¿pueden los clientes potenciales encontrar y entender su oferta? ¿Funciona en la web el camino hasta el contacto? ¿Necesitan los asistentes de IA un acceso directo y estructurado a su conocimiento? Ninguna de estas preguntas permite prometer sin más un buen ranking. Para las funciones generativas de la Búsqueda de Google, Google sigue remitiendo a los fundamentos de SEO de siempre. Si quiere profundizar en el potencial de estos sistemas para su marketing, le recomendamos nuestro artículo sobre agentes de IA.
Cómo comprobar si su web está preparada para los agentes de IA
Empiece por una tarea que de verdad importe a su empresa. En una empresa de servicios podría ser: «Comprueba si este proveedor ofrece el servicio que necesito en mi localidad y prepara una solicitud de contacto adecuada». En una tienda, por ejemplo, la elección de un producto con unas características concretas. Defina antes en qué punto debe detenerse el agente y fíjese en cuatro cosas:
- Búsqueda de información: ¿encuentra el agente los datos que necesita y los relaciona con la oferta correcta?
- Manejo: ¿maneja la navegación, los desplegables y los formularios sin ayuda?
- Resultado: ¿son correctos los datos preparados y está claro en qué punto se encuentra el proceso?
- Control: ¿se detiene el agente antes de los pasos que requieren una autorización expresa?
Documente con la mayor precisión posible dónde se atasca el proceso. «La IA no entiende nuestra web» no ayuda mucho. «La cita solo se puede elegir con una flecha sin etiqueta» es una tarea concreta para revisar. Si resulta que el agente falla sobre todo al buscar la información, es una pista de que un acceso directo y estructurado a esa información puede aportar más que seguir optimizando la interfaz.
Conclusión: con agentes de IA en la web, revise el camino hasta la solicitud
Las recomendaciones de Google son una buena ocasión para probar más a fondo las webs actuales y prepararlas para este nuevo visitante. La base sigue siendo una web cuya navegación, formularios y mensajes funcionen de forma fiable. Sobre ella pueden construirse accesos adicionales: WebMCP para los agentes que visitan su web y una interfaz MCP para los asistentes de IA que deban trabajar con su empresa sin necesidad de visitarla.
Hoy todavía no se puede cuantificar con rigor cuánto influirán los agentes de IA en la captación de clientes. Pero la empresa que ahora haga fáciles de entender sus procesos más importantes y pruebe nuevos accesos con un caso de uso concreto ganará una experiencia que a la competencia le costará alcanzar más adelante.
En Wisea le ayudamos a comprobar si su empresa está preparada para este nuevo visitante: revisamos con usted los contenidos, la implementación técnica y el camino desde la primera visita hasta la solicitud. Y si tiene sentido un acceso directo para los asistentes de IA, le mostramos lo que AI-Connect puede aportar. ¿Quiere saber qué pasos le convienen? No dude en ponerse en contacto con nuestra agencia.
Contacto