Por Fran Navoz en Hosting, Productos y servicios, WordPress
03 de agosto de 2026
Montar un chatbot de IA en WordPress es cuestión de un plugin y cinco minutos. Que ese chatbot no te tumbe la web cuando varios usuarios escriben a la vez ya es otra historia, y depende casi por completo de tu hosting.
La mayoría de guías se quedan en “instala este plugin y pega el código en el pie de página”. Ninguna te cuenta qué pasa por debajo cuando el bot empieza a recibir tráfico de verdad. Y lo que pasa suele ser esto: peticiones que se acumulan, PHP workers que se agotan, errores 502 y una web que se arrastra justo cuando más gente la visita. Aquí te explico por qué ocurre y qué infraestructura necesitas para que no te pase.
Los chatbots ya no son los arbolitos de decisión de hace unos años. Un asistente moderno procesa lenguaje natural, consulta tu base de datos en tiempo real (productos, historiales, documentación) y genera cada respuesta al vuelo. Todo ese trabajo no ocurre en el navegador del visitante: ocurre en tu servidor.
Y ahí aparece la exigencia real. Si el servidor tarda más de 200 milisegundos en responder, la conversación se siente lenta y el usuario se va. Da igual lo bueno que sea el modelo de IA: si la infraestructura no acompaña, la experiencia se cae. Por eso el hosting no es un detalle de la instalación, es la pieza que decide si el chatbot funciona o estorba.
Muchos plugins de chat mal programados mandan sus peticiones a través de admin-ajax.php. El problema es lo que hay detrás de ese archivo: cada llamada obliga a WordPress a arrancar el entorno administrativo completo y ejecutar el gancho admin_init, aunque solo estés preguntándole al bot por el horario de tu tienda.
Multiplica eso por cada mensaje de cada usuario y tienes un ataque de denegación de servicio que te haces tú solo. Los PHP workers (los procesos que atienden las peticiones) se agotan, y cuando no quedan libres empiezan los errores 502 y 504. La web deja de responder para todos, no solo para quien usa el chat.
La alternativa correcta es la API REST de WordPress. Las peticiones a /wp-json/ se procesan sin cargar todo el backend administrativo, así que son mucho más ligeras y dejan los workers libres para lo que importa. Si tu plugin de chat permite elegir, que use REST y no AJAX.
El widget de chat también pesa en la parte visible. Los scripts de estos plugins suelen ocupar cientos de kilobytes y, si se cargan mal, bloquean el hilo principal del navegador. Eso castiga tu INP (capacidad de respuesta a la interacción) y arrastra el LCP, dos métricas que Google mira para posicionar.
Hay una técnica que ayuda mucho: el Shadow DOM. Encapsula el widget para que sus estilos y su carga no alteren el resto de la página, lo que evita esos saltos de maquetación (CLS) tan molestos en los que el contenido baja de golpe cuando aparece la burbuja del chat. Si tu plugin lo usa, mejor; si no, valóralo al elegirlo.
| Requisito | Por qué lo necesitas |
|---|---|
| PHP workers dedicados y escalables | Cada conversación simultánea ocupa un worker. El hosting compartido básico se queda sin ellos en cuanto varios usuarios chatean a la vez. |
| Almacenamiento NVMe | Las búsquedas del bot leen la base de datos constantemente. Con NVMe esas lecturas son casi instantáneas; con disco lento, cada respuesta se hace esperar. |
| Caché de objetos con Redis | Guarda en memoria las consultas pesadas para que MySQL no repita el mismo trabajo una y otra vez. |
| Cortafuegos y rate limiting | Los endpoints del chat son un blanco fácil para bots de scraping y ataques. Necesitas filtrarlos antes de que lleguen al servidor. |
Un chatbot autoalojado que busca en tu contenido puede lanzar miles de consultas a MySQL para cada respuesta (a tablas como wp_options o wp_postmeta). Redis actúa como una capa de memoria RAM que almacena esas consultas: la primera vez se calcula, las siguientes se sirven al instante. Bien configurado, puede quitarle a tu base de datos la gran mayoría de las consultas repetidas y liberar recursos para las operaciones que sí cuentan, como una compra.
Un detalle que se pasa por alto en hosting compartido: si tienes varios sitios en el mismo servidor, conviene añadir una clave única en wp-config.php para que sus cachés no colisionen entre sí.
define( 'WP_CACHE_KEY_SALT', 'nicalia_secure_prefix_site1_' );Este error es un clásico y desespera a cualquiera que tenga una tienda. Cuando aplicas caché de página completa sin excluir lo dinámico, el servidor sirve una versión “congelada” de la cabecera y el carrito aparece siempre en cero, aunque el cliente haya metido productos. Para compensarlo, WooCommerce dispara peticiones AJAX sin parar intentando actualizar el estado, y vuelves al punto de partida: recursos saturados.
La solución es excluir de la caché las cookies de sesión y los endpoints del chat. En LiteSpeed Cache o WP Rocket, deja fuera al menos estas:
woocommerce_items_in_cartwoocommerce_cart_hashwp_woocommerce_session_*/wp-json/mwai/)Si tu proyecto es una tienda, este ajuste no es opcional. Un hosting para WooCommerce preparado para esto ya trae estas exclusiones configuradas de serie y te ahorra el problema entero.
Los chatbots atraen bots maliciosos que intentan extraer datos o tumbar el servidor a base de peticiones masivas. La defensa a nivel de servidor es el rate limiting, y el algoritmo más habitual es el de la cubeta que gotea (leaky bucket): permite un ritmo constante de peticiones y absorbe ráfagas puntuales sin dejar pasar avalanchas. En Nginx se configura así:
limit_req_zone $binary_remote_addr zone=chatlimit:10m rate=3r/s;
location /wp-json/mwai/ {
limit_req zone=chatlimit burst=6 nodelay;
}Eso limita a 3 peticiones por segundo por IP, con margen para ráfagas cortas de hasta 6. Por encima de la nube, una regla en el WAF de Cloudflare puede añadir un reto (Managed Challenge) a los accesos abusivos hacia /wp-json/ o admin-ajax.php. Eso sí: excluye a Googlebot y a los rastreadores legítimos, o te arriesgas a bloquear tu propio SEO mientras intentas protegerte.
Todo lo anterior se puede montar a mano, pero lleva horas y un buen conocimiento de sistemas. La idea de un hosting especializado es que venga resuelto de fábrica. Esto es lo que aporta el hosting WordPress de Nicalia para este caso concreto:
admin-ajax.php y los endpoints REST se filtra antes de tocar tu servidor.Alojar tu web en una infraestructura pensada para WordPress es la diferencia entre un chatbot que suma y uno que te da sustos. Nuestro hosting WordPress viene con LiteSpeed, Redis y NVMe listos para usar, y soporte técnico en español de administradores de sistemas.
¿Tienes una tienda? Echa un vistazo a nuestro hosting para WooCommerce, optimizado para que el carrito y el chat convivan sin pelearse por los recursos.
/wp-json/), no admin-ajax.php.Para pruebas o tráfico muy bajo, sí. En cuanto varios usuarios chateen a la vez, el hosting compartido tradicional se queda sin PHP workers y empiezan las caídas. Para producción necesitas recursos escalables.
Para las peticiones dinámicas de un chat, sí: es más ligera porque no arranca el entorno administrativo completo de WordPress. El problema es que muchos plugins antiguos siguen usando AJAX; revísalo antes de elegir.
Opcional para una web sencilla, casi imprescindible para un chatbot que consulta la base de datos sin parar. Redis evita que MySQL repita el mismo trabajo y mantiene las respuestas rápidas.
Es la caché de página completa sirviendo una versión congelada de la cabecera. Se arregla excluyendo las cookies de sesión de WooCommerce y los endpoints del chat de la caché.
Fran Navoz