{"id":3881,"date":"2026-10-05T08:00:30","date_gmt":"2026-10-05T06:00:30","guid":{"rendered":"https:\/\/www.nicalia.com\/blog\/?p=3881"},"modified":"2026-10-02T14:41:53","modified_gmt":"2026-10-02T12:41:53","slug":"siete-senales-de-que-tu-wordpress-necesita-mas-servidor","status":"publish","type":"post","link":"https:\/\/www.nicalia.com\/blog\/siete-senales-de-que-tu-wordpress-necesita-mas-servidor\/","title":{"rendered":"Siete se\u00f1ales de que tu WordPress necesita m\u00e1s servidor"},"content":{"rendered":"

Llevas meses apa\u00f1\u00e1ndote. Reintentas la importaci\u00f3n 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\u00e1 roto del todo, pero cada semana cuesta un poco m\u00e1s.<\/p>\n

Puede que tu hosting se haya quedado peque\u00f1o o puede que tu WordPress est\u00e9 mal montado, y la soluci\u00f3n de cada caso es la contraria. Aqu\u00ed tienes c\u00f3mo distinguirlo: qu\u00e9 s\u00edntoma corresponde a qu\u00e9 recurso agotado y c\u00f3mo confirmarlo en un par de minutos antes de gastarte un euro.<\/p>\n

<\/p>\n

Primero, lo inc\u00f3modo: la mayor\u00eda de los WordPress lentos no son culpa del hosting<\/h2>\n

Casi siempre que un WordPress va lento, el servidor va sobrado y lo que frena es la instalaci\u00f3n<\/em>. Plugins que cargan sus scripts en todas las p\u00e1ginas aunque solo se usen en una, temas que piden quince fuentes distintas, una tabla wp_options<\/code> 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.<\/p>\n

La prueba que lo separa es sencilla. Sube al servidor un archivo prueba.html<\/code> con una sola l\u00ednea de texto y mide cu\u00e1nto tarda en responder (el TTFB). Un HTML plano no ejecuta PHP ni consulta la base de datos, as\u00ed que te dice lo r\u00e1pida que es la m\u00e1quina 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\u00f3mo saber si tu web va lenta por tu conexi\u00f3n, tu web o tu hosting<\/a>, y para encontrar al plugin culpable, X-Ray desde cPanel<\/a>. Si lo que pesa es la base de datos, empieza por reducir la tabla wp_options<\/a>.<\/p>\n

Si el HTML plano tambi\u00e9n va lento, o si lo que te pasa no es lentitud sino errores, sigue leyendo.<\/p>\n

Las siete se\u00f1ales, y qu\u00e9 se ha agotado detr\u00e1s de cada una<\/h2>\n

Cada plan de hosting pone l\u00edmites a tu cuenta (memoria, CPU, procesos simult\u00e1neos, conexiones a la base de datos, tiempo de ejecuci\u00f3n), y casi todos los s\u00edntomas de abajo son uno de esos l\u00edmites tocando techo. La tabla te dice qu\u00e9 mirar y el enlace de cada fila, c\u00f3mo hacerlo.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Del s\u00edntoma al recurso agotado<\/caption>\n
Lo que ves<\/th>\nQu\u00e9 se ha agotado<\/th>\nC\u00f3mo confirmarlo<\/th>\n<\/tr>\n<\/thead>\n
\u00abHa habido un error cr\u00edtico en esta web\u00bb o pantalla en blanco al actualizar un plugin<\/td>\nMemoria de PHP (memory_limit<\/code>)<\/td>\nModo debug: \u00abAllowed memory size of \u2026 bytes exhausted\u00bb<\/td>\n<\/tr>\n
Importaciones o copias de seguridad que se cortan a medias<\/td>\nTiempo de ejecuci\u00f3n de PHP o del servidor web<\/td>\nRegistro de errores: \u00abMaximum execution time exceeded\u00bb, o un 504<\/td>\n<\/tr>\n
\u00abError al establecer una conexi\u00f3n con la base de datos\u00bb, a ratos<\/td>\nConexiones simult\u00e1neas a MySQL<\/td>\nCoincide con picos de tr\u00e1fico y no sale siempre<\/td>\n<\/tr>\n
El escritorio va lento y la web p\u00fablica no<\/td>\nCPU<\/td>\nTTFB de una p\u00e1gina sin cach\u00e9 frente al del HTML plano<\/td>\n<\/tr>\n
Error 508 en hora punta, y la web se recupera sola<\/td>\nProcesos simult\u00e1neos<\/td>\n\u00abUso de recursos\u00bb de cPanel, cruzado con tu tr\u00e1fico<\/td>\n<\/tr>\n
Im\u00e1genes que no suben o que no se procesan<\/td>\nL\u00edmite de subida, o memoria al redimensionar<\/td>\nEl mensaje de WordPress dice cu\u00e1l de los dos<\/td>\n<\/tr>\n
Una actualizaci\u00f3n falla y deja la web \u00aben mantenimiento\u00bb o rota<\/td>\nTiempo, memoria o espacio en disco<\/td>\nArchivo .maintenance<\/code> y verificaci\u00f3n de integridad<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

1. Error cr\u00edtico al actualizar un plugin<\/h3>\n

Desde WordPress 5.2 ya casi nunca ves la pantalla en blanco de antes, sino el aviso \u00abHa habido un error cr\u00edtico en esta web\u00bb. Detr\u00e1s suele estar un proceso PHP que ha pedido m\u00e1s memoria de la que tiene permitida. Activa el modo debug<\/a> y busca \u00abAllowed memory size of \u2026 bytes exhausted\u00bb en el registro. Si el l\u00edmite estaba bajo, se sube desde el php.ini<\/a> o en el wp-config.php<\/a>. Si no puedes ni entrar al escritorio, desactiva el plugin desde el administrador de archivos<\/a>.<\/p>\n

Es una se\u00f1al de hosting cuando el l\u00edmite ya est\u00e1 en el m\u00e1ximo que permite tu plan y el error vuelve, o cuando cada pocos meses tienes que subirlo otra vez.<\/p>\n

2. Importaciones y copias que se cortan<\/h3>\n

Aqu\u00ed hay dos l\u00edmites distintos que se confunden mucho. Si PHP pasa de su max_execution_time<\/code>, el registro dice \u00abMaximum execution time of 30 seconds exceeded\u00bb y lo que ves es un error cr\u00edtico 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\u00e1s de lo que el plan deja hacer en una sola petici\u00f3n. Lo confirmas en el registro de errores de cPanel<\/a>.<\/p>\n

Antes de cambiar de plan, prueba a lanzar esas tareas desde la l\u00ednea de comandos. Si accedes por SSH<\/a>, wp-cli no depende del tiempo l\u00edmite del servidor web, y muchas importaciones que fallan desde el navegador terminan sin problema.<\/p>\n

3. La base de datos que falla a ratos<\/h3>\n

El mensaje literal es \u00abError al establecer una conexi\u00f3n con la base de datos\u00bb, y lo que importa es cu\u00e1ndo aparece. Si sale siempre, lo m\u00e1s probable es que las credenciales del wp-config.php<\/code> 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\u00e1fico y al rato desaparece, se est\u00e1n agotando las conexiones simult\u00e1neas a MySQL que permite tu cuenta. Apunta la hora de cada vez que lo veas y comp\u00e1rala con tus visitas.<\/p>\n

4. El escritorio lento y la web p\u00fablica r\u00e1pida<\/h3>\n

Las p\u00e1ginas p\u00fablicas salen de la cach\u00e9 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\u00e1gina p\u00fablica salt\u00e1ndote la cach\u00e9 (a\u00f1ade ?nocache=123<\/code> a la URL) y comp\u00e1ralo con el del HTML plano. Si los dos son altos, a la m\u00e1quina le falta CPU. Si solo es alto el de WordPress, X-Ray<\/a> te dir\u00e1 qu\u00e9 plugin se come el tiempo.<\/p>\n

5. Error 508 en hora punta<\/h3>\n

Es la se\u00f1al m\u00e1s clara de todas. La web se cae cuando mandas la newsletter o arranca una campa\u00f1a, aparece \u00ab508 Resource Limit Is Reached\u00bb y a los diez minutos vuelve sola. Has llegado al tope de procesos simult\u00e1neos de tu plan: cada visita que no sale de cach\u00e9 ocupa un proceso PHP mientras se genera, y cuando se llenan todos los huecos, las siguientes peticiones se rechazan. En \u00abUso de recursos\u00bb de cPanel<\/a> ves a qu\u00e9 horas has tocado el l\u00edmite. Si coincide con tus picos de tr\u00e1fico, no hay mucho m\u00e1s que discutir.<\/p>\n

6. Im\u00e1genes que no suben<\/h3>\n

F\u00edjate en el mensaje, porque te dice cu\u00e1l es el problema. Si WordPress avisa de que el archivo supera el tama\u00f1o m\u00e1ximo de subida, el l\u00edmite es upload_max_filesize<\/code> (y post_max_size<\/code>, que tiene que ser igual o mayor), y eso se ajusta en el php.ini<\/a>. Si la imagen sube pero sale \u00abEl servidor no puede procesar la imagen\u00bb, lo que falta es memoria para redimensionarla. Esta segunda s\u00ed apunta a recursos, sobre todo si pasa con fotos normales de m\u00f3vil.<\/p>\n

7. La actualizaci\u00f3n que se queda a medias<\/h3>\n

Mientras actualiza, WordPress crea un archivo .maintenance<\/code> y muestra \u00abNo disponible por mantenimiento programado\u00bb. Si el proceso muere por tiempo, por memoria o porque la cuenta se ha quedado sin espacio en disco, ese archivo se queda hu\u00e9rfano. WordPress lo ignora pasados diez minutos, as\u00ed que el aviso se va solo, pero la actualizaci\u00f3n puede haber dejado archivos copiados a medias. Compru\u00e9balo con la verificaci\u00f3n de integridad con wp-cli<\/a>, y la pr\u00f3xima vez actualiza con wp-cli<\/a>, que no depende del tiempo l\u00edmite del navegador.<\/p>\n

Un s\u00edntoma suelto no demuestra nada. Si se repite, coincide con picos de tr\u00e1fico o sigue ah\u00ed despu\u00e9s de subir los l\u00edmites al m\u00e1ximo de tu plan, entonces s\u00ed es el hosting.<\/p><\/blockquote>\n

\"\u00bfTu<\/a><\/h2>\n

<\/h2>\n

Cuatro s\u00edntomas que parecen de hosting y casi nunca lo son<\/h2>\n

Van despu\u00e9s de la tabla por una raz\u00f3n: si has llegado hasta aqu\u00ed con uno de estos, cambiar de plan no te lo va a arreglar.<\/p>\n