Añádelo como fuente preferida en Google
Las páginas de WordPress siempre se han diseñado pensando en las personas. Cuando alguien visita una página, echa un vistazo al sitio, rellena un formulario, hace clic en un botón o se crea una cuenta. El navegador es el centro de esta experiencia, y por eso los desarrolladores construyen la página en torno a las acciones que la gente realiza en la pantalla.
Los agentes de IA no siempre funcionan así; pueden obtener información, llamar a funciones y realizar tareas sin tener que visitar una página ni abrir wp-admin. WordPress está haciendo ajustes con herramientas como la API Abilities y el adaptador MCP, que ofrecen al software formas más directas de detectar y utilizar las funcionalidades del sitio.
A medida que esas interacciones se vuelven más habituales, los desarrolladores tienen que tener en cuenta otro tipo de usuario a la hora de planificar. Desarrollar WordPress tanto personas como agentes de IA cambia tu forma de pensar sobre las APIs, los permisos, la autenticación, el rendimiento y lo que pasa cuando algo sale mal.
Los agentes de IA no usan WordPress como lo hacen las personas
La gente se las arregla bastante bien para ir resolviendo las cosas sobre la marcha. Saben echar un vistazo al menú, fijarse en las pistas visuales, volver a leer las instrucciones o probar con otro botón cuando algo no funciona a la primera.
Los agentes no tienen esa misma flexibilidad. Necesitan un proceso más claro, con acciones bien definidas, datos estructurados, una forma de autenticarse y respuestas que puedan interpretar con fiabilidad.
Esto cambia algunos de los supuestos básicos en los que se basa la arquitectura de WordPress:
| Interacción centrada en las personas | Interacción preparada para los agentes |
| Menús de navegación y botones | Capacidades detectables |
| Formularios | Entradas estructuradas y APIs |
| Pantallas de inicio de sesión | Autenticación programática |
| Respuestas visuales | Respuestas estructuradas y errores |
| Visitas y sesiones | Llamadas a la API y ejecuciones de herramientas |
También es importante diferenciar entre agentes y rastreadores. Los rastreadores se dedican principalmente a recuperar o indexar información. Los agentes pueden ir un paso más allá y realizar acciones en nombre del usuario. Eso puede significar consultar el inventario, recuperar información de la cuenta, crear un borrador, enviar datos o activar un flujo de trabajo.
Una vez que el software es capaz de hacer algo más que leer contenido, la arquitectura tiene que tener en cuenta los permisos, la autenticación, los estados de error y las consecuencias de cada acción. Por eso, una web que funcione bien para los agentes de IA necesita algo más que contenido fácil de encontrar para las máquinas. Necesita formas claramente definidas para que las máquinas interactúen con WordPress de manera segura y fiable.
Capacidades de diseño, no solo páginas
El diseño web tradicional empieza con el recorrido del usuario. Alguien llega a una página, va haciendo clic, rellena un formulario y llega a una pantalla de confirmación.
Un agente de IA puede saltarse esa ruta por completo. No necesita ver la interfaz si puede acceder directamente a la función subyacente.
Esa función podría buscar en la documentación, consultar el inventario, enviar una solicitud de presupuesto o crear un borrador. En lugar de pedirle a un agente que reproduzca en pantalla los mismos pasos que da una persona, los desarrolladores pueden expresar esas acciones en un formato que el software pueda entender y utilizar.
La API Abilities de WordPress ofrece a los desarrolladores una forma más sencilla de aprovechar esa funcionalidad. En lugar de hacer que una herramienta externa funcione a través de una página o extraiga información del HTML, puedes definir una acción directamente, junto con los datos que necesita, lo que devuelve y quién puede usarla.
Eso no significa que cada botón tenga que tener un equivalente accesible para máquinas. Lo que realmente importa es qué funciones merece la pena hacer accesibles, quién debería poder usarlas y qué límites deberían aplicarse.
Para los desarrolladores, esto plantea una nueva cuestión en el proceso de planificación: ¿qué pueden hacer en este sitio, de forma segura, tanto las personas como las máquinas?
La autenticación y los permisos cobran mayor importancia
En cuanto un agente de IA puede actuar dentro de WordPress, la pregunta ya no es «¿Puede conectarse?», sino «¿Qué se le debería permitir hacer realmente?»
Esa distinción es importante, ya que cada vez más programas funcionan con sus propias credenciales y permisos. El informe «2025 Identity Security Landscape» de CyberArk reveló que el 68 % de las organizaciones carece de controles de seguridad de identidades para la IA. Dar acceso a un agente es fácil. Limitar ese acceso a la tarea concreta que debe realizar requiere más planificación.
Para cada funcionalidad orientada a máquinas, los desarrolladores tienen que responder a unas cuantas preguntas básicas:
- ¿Quién realiza la solicitud?
- ¿En nombre de quién actúa?
- ¿Qué información puede consultar?
- ¿Qué puede modificar?
- ¿Qué acciones necesitan aprobación adicional?
Limita el acceso del agente a las tareas que está realizando. Una herramienta que busca en la documentación no tiene por qué editar entradas, y una que redacta borradores no tiene por qué publicarlos. Cuando se trata de cosas como cambiar de cuenta, borrar contenido o gestionar pagos, los requisitos deben ser mucho más estrictos.
La API de capacidades de WordPress ayuda a los desarrolladores a establecer esos límites. Cada capacidad puede incluir sus propias comprobaciones de permisos, junto con entradas y salidas definidas. Eso te da más control que entregar las credenciales de administrador a un servicio externo y confiar en que solo usará lo que necesite.
En gran parte, todo esto se reduce a las prácticas habituales de seguridad. Cualquier cosa que envíe un agente debe revisarse antes de que WordPress actúe en consecuencia. Las credenciales tampoco deberían aparecer en ventanas de solicitud, código front-end ni registros. Si el agente está a punto de hacer algo costoso o difícil de deshacer, es un buen momento para parar y pedir la aprobación de una persona.
El hecho de que un agente tenga que hacer una tarea concreta no debería darle acceso general a WordPress. Dale solo los permisos necesarios para llevar a cabo esa tarea, y nada más.
Los usuarios de máquinas cambian los requisitos de rendimiento
Los visitantes humanos navegan a un ritmo natural. Cargas una página, la lees, haces clic en algo y esperas la siguiente respuesta. Los agentes de IA pueden moverse mucho más rápido. Pueden enviar varias solicitudes en cuestión de segundos mientras recopilan contexto, activan herramientas, comparan resultados y llevan a cabo una tarea de varios pasos.
Las normas de seguridad habituales no desaparecen solo porque haya un agente involucrado. WordPress sigue teniendo que comprobar lo que entra, y las credenciales deben seguir sin aparecer en las ventanas de solicitud, el código del front end ni los registros. Si el flujo de trabajo llega a un punto en el que puede realizar un cambio costoso o difícil de revertir, ahí es donde debe intervenir una persona antes de que continúe.
Los flujos de trabajo automatizados pueden afectar mucho más a WordPress que una persona navegando por la web, así que merece la pena reducir el trabajo extra. Eso puede significar combinar llamadas a la API, almacenar en la caché las respuestas de solo lectura, limitar el número de solicitudes que se ejecutan a la vez o pasar las tareas más lentas a segundo plano. Los límites de frecuencia y los tiempos de espera razonables también pueden evitar que un flujo de trabajo automatizado acapare los recursos para el resto de usuarios.
El objetivo es evitar que WordPress tenga que trabajar más de lo que realmente requiere la tarea. Si un agente necesita tres datos, por ejemplo, puede que sea mejor usar un único endpoint bien diseñado que varias peticiones por separado, cada una de las cuales genera su propia carga de trabajo en la base de datos.
Los tiempos de espera son complicados porque la solicitud podría haber funcionado aunque el agente nunca reciba la respuesta. Si vuelve a enviar la misma solicitud, puede que eso no importe si solo se trata de una consulta. Pero sí que importa mucho más si la primera solicitud creó o modificó algo. Antes de volver a intentarlo, el agente necesita una forma de comprobar si la tarea ya se ha ejecutado.
Las necesidades de infraestructura de IA en general ya están bien documentadas. La clave está en algo más concreto: a la hora de planificar el rendimiento, ya no se puede dar por hecho que todas las interacciones se produzcan a la velocidad de un ser humano.
A medida que los agentes se convierten en otro tipo de usuario de WordPress, la infraestructura tiene que gestionar picos de actividad impulsados por máquinas sin que esos flujos de trabajo ralenticen a las personas que usan la web al mismo tiempo.
Los agentes necesitan respuestas predecibles y flujos de trabajo observables
Los agentes necesitan tener claro qué ha pasado después de cada solicitud. Si la respuesta es ambigua, se quedan sin saber si la tarea sigue en marcha, ha fallado por completo o ha terminado sin enviar una respuesta.
Los flujos de trabajo más largos hacen que sea más difícil recuperarse de esto. Si un paso devuelve un resultado poco claro, el agente puede repetirlo, saltarse ese paso o seguir adelante antes de que la tarea anterior se haya completado realmente.
Eso no siempre es un problema. Recuperar la misma documentación dos veces no suele ser grave. Crear el mismo pedido dos veces, sí que lo es. Lo mismo ocurre con publicar o borrar contenido. El agente necesita saber qué ha pasado antes de volver a enviar la solicitud.
La API de Kinsta realiza esta función para algunas acciones de larga duración mediante un ID de operación. En lugar de mantener la solicitud abierta, devuelve un ID que el software puede consultar más tarde para ver si la tarea sigue en marcha o ya ha terminado.
También necesitas suficiente visibilidad para averiguar qué ha fallado cuando un flujo de trabajo se interrumpe. Es posible que un mensaje de error final no te diga gran cosa. Quizá necesites ver qué solicitud se ha atascado, si WordPress ha llamado a otro servicio, qué ha pasado en la base de datos o si el agente ha enviado la misma solicitud más de una vez.
Kinsta APM y los registros del servidor pueden ayudarte a rastrear esa actividad, mientras que el entorno staging ofrece a los equipos un lugar más seguro para probar los flujos de trabajo controlados por agentes antes de que puedan afectar a los datos de producción.
Cuando hay un visitante humano, suele ser fácil detectar rápidamente un fallo en el flujo de trabajo. Alguien ve el error y lo comunica. Con un agente, el fallo puede quedar oculto entre varios pasos automatizados. Las respuestas predecibles y una buena observabilidad hacen que esos problemas sean mucho más fáciles de detectar y solucionar.
La capa de alojamiento también puede tener una interfaz para máquinas
La arquitectura preparada para agentes no se limita al propio WordPress. Piensa en dos capas orientadas a las máquinas: el sitio y la infraestructura que lo sustenta.
A nivel de WordPress, la API Abilities y el adaptador MCP pueden exponer contenido y funcionalidades a herramientas externas. Un agente podría recuperar datos, crear contenido o activar el flujo de trabajo de un plugin. A nivel de alojamiento, las APIs pueden exponer tareas operativas que, de otro modo, requerirían que alguien las realizara a través de un panel de control.
La API de Kinsta ofrece a los desarrolladores acceso programático a tareas como recuperar información del sitio y del entorno, gestionar dominios, trabajar con la caché y gestionar otras operaciones de alojamiento. Esto abre la puerta a flujos de trabajo que van más allá de la propia aplicación de WordPress. Una herramienta puede comprobar un entorno antes de realizar una acción, activar una tarea de infraestructura o incorporar información a un proceso automatizado más amplio.
Kinsta también ha presentado un servidor MCP basado en su API, que permite a un cliente de IA utilizar determinadas funciones de alojamiento como herramientas. Esto puede incluir inspeccionar entornos, vaciar la caché, clonar un sitio o consultar la información de los plugins sin que haya que ir haciendo clic en MyKinsta en cada paso.
Un agente puede hacer muchas cosas sin tener acceso a toda la cuenta de alojamiento. Si solo necesita borrar la caché, comprobar un entorno o extraer datos de plugins, eso es todo a lo que debería poder acceder. No tiene sentido concederle permisos más amplios solo porque exista la conexión.
MyKinsta sigue encargándose de la parte humana, como comprobar la configuración, solucionar problemas y gestionar los sitios a diario. Las APIs son útiles cuando esas mismas tareas de alojamiento necesitan conectarse con algo más, ya sea un proceso de despliegue, una herramienta interna, un flujo de trabajo de una agencia o un sistema de IA.
Las agencias deberían incluir la compatibilidad con agentes en sus revisiones de arquitectura
No hace falta que incluyas a la fuerza agentes de IA o MCP en todos los proyectos de WordPress ahora mismo. Lo más inteligente es evitar tomar decisiones que dificulten añadir esos flujos de trabajo más adelante, sobre todo si un cliente vuelve a pedirlos cuando la web ya está creada.
Ya sea para una construcción nueva o una reforma importante, vale la pena preguntarse:
- ¿Qué tareas podrían delegar los clientes o los empleados a un agente?
- ¿A qué datos o funciones del sitio debería poder acceder el software?
- ¿Qué acciones deberían requerir siempre la aprobación de una persona?
- ¿Cómo demostrará el agente quién es y qué está autorizado a hacer?
- ¿Qué pasa si el tráfico automatizado se dispara?
- ¿Cómo detectará y solucionará el equipo los problemas cuando se rompa un flujo de trabajo?
Esas respuestas pueden influir en todo, desde la elección de plugins y el diseño de la API hasta los permisos y el alojamiento. También afectan a decisiones más pequeñas. Un flujo de trabajo escondido en una pantalla de administración puntual es más difícil de reutilizar más adelante que una función a la que otro sistema pueda llamar directamente.
El caso de estudio de Sod muestra cómo se puede aplicar este tipo de flexibilidad en la práctica. La agencia gestiona más de 400 sitios web de WordPress y usa la API de Kinsta para automatizar tareas que, de otro modo, requerirían supervisión manual.
No se trata de un flujo de trabajo con agentes de IA, pero sí que pone de manifiesto el valor de una infraestructura que ofrece al software una forma soportada de interactuar con las operaciones de alojamiento, en lugar de obligar a que todas las tareas se realicen a través de un panel de control.
Esa flexibilidad resulta cada vez más útil a medida que cambian las expectativas de los clientes. Un flujo de trabajo que hoy empieza como una automatización interna podría conectarse más adelante con un asistente de IA, un cliente de MCP u otro sistema empresarial. Si la función subyacente ya cuenta con una interfaz clara y unos permisos bien definidos, añadir esa nueva capa resulta mucho más fácil.
El mismo principio se aplica a la hora de planificar los agentes. Las agencias no tienen por qué automatizar todos los flujos de trabajo ahora mismo. Lo que deben evitar es crear sitios web partiendo de la idea de que siempre será una persona quien recupere la información, active las acciones o gestione el sistema subyacente.
Incluir la preparación para los agentes en las revisiones de arquitectura te da más margen para adoptar nuevos flujos de trabajo más adelante sin tener que replantearte el sitio desde cero.
Crea para las personas y para el software que actúa en su nombre
WordPress sigue teniendo que pensar primero en las personas. Las páginas, los formularios, la navegación y una experiencia de usuario sólida no van a desaparecer. Lo que cambia es que ya no son la única forma en que alguien, o algo, pueda usar el sitio.
Cada vez hay más tareas de este tipo que se llevan a cabo sin que nadie tenga que hacer clic en WordPress. Un agente puede extraer información, activar una acción y pasar al siguiente paso en cuestión de segundos. Por eso, la infraestructura técnica cobra mucha más importancia. Los desarrolladores tienen que saber exactamente a qué puede acceder el agente, qué nivel de acceso tiene, si el sitio puede seguir el ritmo y dónde buscar cuando algo falla.
No hace falta que hoy mismo reestructures todos los sitios de WordPress pensando en los agentes de IA. Pero sí que tienes que dejar de dar por hecho que todas las interacciones futuras empezarán con una persona abriendo un navegador. El alojamiento administrado para WordPress de Kinsta ofrece a los desarrolladores el rendimiento, la visibilidad y las herramientas necesarias para dar soporte tanto a los visitantes humanos como a los flujos de trabajo cada vez más automatizados.
Puede que tu próximo cliente siga siendo humano. La diferencia es que el software puede interactuar con tu sitio web en su nombre.
