Llevas meses apañándote. Reintentas la importación hasta que sale, desactivas plugins para poder actualizar otros y entras al escritorio a las once de la noche porque a las seis de la tarde no hay quien trabaje. Nada está roto del todo, pero cada semana cuesta un poco más.
Puede que tu hosting se haya quedado pequeño o puede que tu WordPress esté mal montado, y la solución de cada caso es la contraria. Aquí tienes cómo distinguirlo: qué síntoma corresponde a qué recurso agotado y cómo confirmarlo en un par de minutos antes de gastarte un euro.
Casi siempre que un WordPress va lento, el servidor va sobrado y lo que frena es la instalación. Plugins que cargan sus scripts en todas las páginas aunque solo se usen en una, temas que piden quince fuentes distintas, una tabla wp_options llena de transients caducados y miles de revisiones de entradas que nadie va a recuperar. Si ese es tu caso, cambiar de plan te sale caro y no arregla nada.
La prueba que lo separa es sencilla. Sube al servidor un archivo prueba.html con una sola línea de texto y mide cuánto tarda en responder (el TTFB). Un HTML plano no ejecuta PHP ni consulta la base de datos, así que te dice lo rápida que es la máquina sin tu WordPress de por medio. Si el HTML vuela y WordPress no, el problema es tuyo y no del hosting. Tienes el procedimiento completo en cómo saber si tu web va lenta por tu conexión, tu web o tu hosting, y para encontrar al plugin culpable, X-Ray desde cPanel. Si lo que pesa es la base de datos, empieza por reducir la tabla wp_options.
Si el HTML plano también va lento, o si lo que te pasa no es lentitud sino errores, sigue leyendo.
Cada plan de hosting pone límites a tu cuenta (memoria, CPU, procesos simultáneos, conexiones a la base de datos, tiempo de ejecución), y casi todos los síntomas de abajo son uno de esos límites tocando techo. La tabla te dice qué mirar y el enlace de cada fila, cómo hacerlo.
| Lo que ves | Qué se ha agotado | Cómo confirmarlo |
|---|---|---|
| «Ha habido un error crítico en esta web» o pantalla en blanco al actualizar un plugin | Memoria de PHP (memory_limit) |
Modo debug: «Allowed memory size of … bytes exhausted» |
| Importaciones o copias de seguridad que se cortan a medias | Tiempo de ejecución de PHP o del servidor web | Registro de errores: «Maximum execution time exceeded», o un 504 |
| «Error al establecer una conexión con la base de datos», a ratos | Conexiones simultáneas a MySQL | Coincide con picos de tráfico y no sale siempre |
| El escritorio va lento y la web pública no | CPU | TTFB de una página sin caché frente al del HTML plano |
| Error 508 en hora punta, y la web se recupera sola | Procesos simultáneos | «Uso de recursos» de cPanel, cruzado con tu tráfico |
| Imágenes que no suben o que no se procesan | Límite de subida, o memoria al redimensionar | El mensaje de WordPress dice cuál de los dos |
| Una actualización falla y deja la web «en mantenimiento» o rota | Tiempo, memoria o espacio en disco | Archivo .maintenance y verificación de integridad |
Desde WordPress 5.2 ya casi nunca ves la pantalla en blanco de antes, sino el aviso «Ha habido un error crítico en esta web». Detrás suele estar un proceso PHP que ha pedido más memoria de la que tiene permitida. Activa el modo debug y busca «Allowed memory size of … bytes exhausted» en el registro. Si el límite estaba bajo, se sube desde el php.ini o en el wp-config.php. Si no puedes ni entrar al escritorio, desactiva el plugin desde el administrador de archivos.
Es una señal de hosting cuando el límite ya está en el máximo que permite tu plan y el error vuelve, o cuando cada pocos meses tienes que subirlo otra vez.
Aquí hay dos límites distintos que se confunden mucho. Si PHP pasa de su max_execution_time, el registro dice «Maximum execution time of 30 seconds exceeded» y lo que ves es un error crítico o un 500. Si el que se cansa de esperar es el servidor web, lo que te sale es un 504. En los dos casos la tarea pesa más de lo que el plan deja hacer en una sola petición. Lo confirmas en el registro de errores de cPanel.
Antes de cambiar de plan, prueba a lanzar esas tareas desde la línea de comandos. Si accedes por SSH, wp-cli no depende del tiempo límite del servidor web, y muchas importaciones que fallan desde el navegador terminan sin problema.
El mensaje literal es «Error al establecer una conexión con la base de datos», y lo que importa es cuándo aparece. Si sale siempre, lo más probable es que las credenciales del wp-config.php no coincidan con las de la base de datos, y eso no tiene nada que ver con el hosting. Si aparece en momentos de tráfico y al rato desaparece, se están agotando las conexiones simultáneas a MySQL que permite tu cuenta. Apunta la hora de cada vez que lo veas y compárala con tus visitas.
Las páginas públicas salen de la caché y apenas gastan servidor, pero el escritorio de WordPress no se cachea nunca y cada clic ejecuta PHP y consulta la base de datos. Por eso es el primer sitio donde se nota que falta CPU. Para confirmarlo, mide el TTFB de una página pública saltándote la caché (añade ?nocache=123 a la URL) y compáralo con el del HTML plano. Si los dos son altos, a la máquina le falta CPU. Si solo es alto el de WordPress, X-Ray te dirá qué plugin se come el tiempo.
Es la señal más clara de todas. La web se cae cuando mandas la newsletter o arranca una campaña, aparece «508 Resource Limit Is Reached» y a los diez minutos vuelve sola. Has llegado al tope de procesos simultáneos de tu plan: cada visita que no sale de caché ocupa un proceso PHP mientras se genera, y cuando se llenan todos los huecos, las siguientes peticiones se rechazan. En «Uso de recursos» de cPanel ves a qué horas has tocado el límite. Si coincide con tus picos de tráfico, no hay mucho más que discutir.
Fíjate en el mensaje, porque te dice cuál es el problema. Si WordPress avisa de que el archivo supera el tamaño máximo de subida, el límite es upload_max_filesize (y post_max_size, que tiene que ser igual o mayor), y eso se ajusta en el php.ini. Si la imagen sube pero sale «El servidor no puede procesar la imagen», lo que falta es memoria para redimensionarla. Esta segunda sí apunta a recursos, sobre todo si pasa con fotos normales de móvil.
Mientras actualiza, WordPress crea un archivo .maintenance y muestra «No disponible por mantenimiento programado». Si el proceso muere por tiempo, por memoria o porque la cuenta se ha quedado sin espacio en disco, ese archivo se queda huérfano. WordPress lo ignora pasados diez minutos, así que el aviso se va solo, pero la actualización puede haber dejado archivos copiados a medias. Compruébalo con la verificación de integridad con wp-cli, y la próxima vez actualiza con wp-cli, que no depende del tiempo límite del navegador.
Un síntoma suelto no demuestra nada. Si se repite, coincide con picos de tráfico o sigue ahí después de subir los límites al máximo de tu plan, entonces sí es el hosting.
Van después de la tabla por una razón: si has llegado hasta aquí con uno de estos, cambiar de plan no te lo va a arreglar.
.htaccess, que ha perdido las reglas de reescritura, o un plugin que las pisa. Se arregla regenerando los enlaces permanentes, y no necesitas más servidor para eso.DISABLE_WP_CRON sin crear una tarea en el servidor, no se ejecuta nunca. Salud del sitio te avisa si las peticiones internas están bloqueadas. La solución es programar wp-cron desde el servidor.En la página de cada plan damos una cifra orientativa de visitas al mes: unas 15.000 para el NVMe Mini, 50.000 para el Basic, 150.000 para el Medium y 300.000 para el Executive. Son útiles para empezar, pero lo que tumba una web no son las visitas al mes, sino cuántas llegan a la vez.
Trescientas mil visitas repartidas a lo largo del mes son unas pocas personas al mismo tiempo. Las mismas visitas concentradas en la hora en que sale tu newsletter son cientos de peticiones en el mismo minuto. Por eso el límite que más importa es el de procesos simultáneos, y ahí hay un detalle que conviene saber: todos los planes NVMe tienen el mismo límite de procesos. Subir de Mini a Executive te da más CPU y más memoria, pero no más huecos para atender visitas a la vez. Lo tienes en la tabla de recursos asignados a cada servicio.
El tipo de web también cuenta mucho. En un blog casi todas las páginas salen de caché y cada visita cuesta muy poco. En un WooCommerce, el carrito, el pago, «Mi cuenta» y la búsqueda no se pueden cachear, así que cada cliente que compra ocupa un proceso PHP y lanza consultas a la base de datos. Con el mismo tráfico, una tienda gasta bastante más servidor que un blog, y se queda corta antes. Si quieres hacer números de memoria, en cuánta RAM necesita un WordPress según su tráfico lo tienes desglosado.
Depende de qué señal te haya salido, y no todas se arreglan con lo mismo:
El traslado no tienes que hacerlo tú. Si vienes de otro proveedor con cPanel, la migración es gratuita siempre que la pidas en los 30 días siguientes a contratar. Y si quieres ver todo lo que incluye nuestro hosting WordPress, lo tienes en su página.
Si abres un tique diciendo «mi WordPress va mal», lo primero que te van a pedir son estos datos, y cada ida y vuelta es un día perdido. Rellénalo antes de abrir el ticket. Sirve con cualquier proveedor.
CHECKLIST WORDPRESS · ANTES DE ABRIR EL TIQUE URL afectada: Hora exacta del último fallo (con zona horaria): ¿Pasa siempre o a ratos? ¿A qué horas? Mensaje de error exacto (copiado, no resumido): CONFIGURACIÓN Versión de PHP: memory_limit actual: max_execution_time actual: upload_max_filesize / post_max_size: Plugins activos (wp plugin list --status=active): MEDICIONES (página sin caché, mediana de 3) TTFB de la portada con ?nocache=: ms TTFB de /wp-admin/ con sesión iniciada: ms TTFB de un HTML plano en el mismo servidor: ms REGISTROS Últimas 20 líneas del registro de errores (adjuntas) ¿Aparece un 508 en «Uso de recursos» de cPanel? (sí / no, a qué horas) CAMBIOS RECIENTES Plugins, tema, campañas o picos de tráfico de los últimos días:
La versión de PHP y los límites los ves en el escritorio, en Herramientas → Salud del sitio → Información → Servidor. Con wp-cli, wp --info te da la versión y wp eval 'echo ini_get("memory_limit");' el límite de memoria.
Sube un HTML de una línea al servidor y mide su tiempo de respuesta. Si el HTML responde rápido y WordPress no, el problema está en plugins, tema o base de datos. Si el HTML también va lento, al servidor le faltan recursos.
Que tu cuenta ha llegado al límite de procesos simultáneos de su plan. Suele aparecer en picos de tráfico y desaparece solo cuando baja la carga. Lo confirmas en «Uso de recursos» de cPanel.
Si aparece y desaparece, lo normal es que se agoten las conexiones simultáneas a MySQL en los picos. Si sale siempre, casi seguro que los datos de conexión del wp-config.php no son correctos, y eso no es cosa del hosting.
Si el límite estaba bajo, sí. Si ya lo tienes en el máximo que permite tu plan y el error vuelve, o el plan no da más memoria o un plugin la consume sin control. X-Ray y el modo debug te dicen cuál de las dos.
Si ya eres cliente y después de repasar las señales sigues sin tenerlo claro, abre un ticket. El equipo de sistemas mira tus gráficas de recursos y te dice si toca cambiar de plan, aunque la respuesta sea que el servidor va sobrado y lo que sobran son dos plugins.
Fran Navoz