WordPress lento o roto: cómo diagnosticarlo y reparar WordPress paso a paso

Un sitio con WordPress lento, o directamente caído, no se arregla probando cambios al azar: desactivar plugins a ciegas, tocar ajustes sin anotar qué se cambió, o reinstalar algo "por si acaso".
Antes de reparar WordPress conviene un diagnóstico ordenado: aislar la causa, leer lo que el propio sistema dice sobre el error y recién después actuar.
Esta guía sigue ese orden, con las causas y soluciones más frecuentes según el síntoma: pantalla en blanco o error crítico, error 500, o un sitio que carga pero va lento.

Antes de reparar WordPress: aislar la causa

Antes de tocar nada, hay tres pasos que sirven para casi cualquier síntoma.
Hacerlos en este orden es criterio propio, no un procedimiento fijado por la documentación, pero reduce el tiempo de diagnóstico y evita corregir varias cosas a la vez sin saber después cuál de ellas resolvió el problema.

1. Desactiva los plugins y reactívalos de a uno.
   Si puedes entrar al panel, desactiva todos los plugins y prueba si el problema desaparece.
   La documentación oficial de WordPress recomienda, ante un conflicto, "desactivar los plugins uno por uno hasta encontrar el origen del problema".
   Si no puedes entrar al wp-admin, renombra por FTP la carpeta wp-content/plugins (por ejemplo a plugins_old), tal como describe la documentación sobre errores comunes.
2. Compara con el tema por defecto.
   Activa un tema por defecto, como Twenty Twenty-One, para descartar que el problema venga del tema.
   Es otro de los pasos que recomienda la misma documentación para aislar la pantalla en blanco.
3. Revisa el registro de errores.
   Ante un error crítico o una pantalla en blanco, el registro de depuración, que se explica abajo, suele indicar en qué archivo o plugin ocurrió el fallo, en lugar de tener que adivinarlo.

Pantalla en blanco o error crítico: cómo leer el registro antes de actuar

Cuando WordPress detecta un error fatal de PHP durante la carga normal de una página, algo que suele deberse a un plugin o un tema incompatible, entran en juego dos mecanismos.

El primero es el modo de recuperación (Recovery Mode), incorporado desde WordPress 5.2.
Según la documentación oficial, WordPress envía un correo a la dirección de administrador con un enlace especial: al entrar por ahí, "los plugins o temas con fallas quedan pausados solo para tu sesión de administrador", lo que permite ver el aviso que señala el componente problemático y desactivarlo sin FTP.
La misma fuente advierte que ese correo puede no llegar si un plugin cambia el envío de correos salientes y el error ocurre antes de que cargue: en ese caso, toca recurrir a FTP o a las herramientas de depuración.

El segundo mecanismo es el registro de depuración.
WP_DEBUG es una constante de PHP que activa el modo de depuración; al definirla en wp-config.php como define('WP_DEBUG', true);, aparecen errores y avisos que normalmente quedan ocultos, según la documentación sobre depuración.
Sumar define('WP_DEBUG_LOG', true); guarda esos errores en un archivo, por defecto wp-content/debug.log, en lugar de mostrarlos en pantalla.
La documentación advierte: "no se recomienda usar WP_DEBUG ni las demás herramientas de depuración en sitios en vivo"; en particular, WP_DEBUG_DISPLAY debe permanecer desactivado en producción para no exponer esa información a los visitantes.
En la práctica: activarlo, leer el registro, identificar el archivo o plugin señalado y desactivarlo de nuevo.

Sobre las causas típicas del aviso "Ha ocurrido un error crítico en este sitio web", la documentación de errores comunes menciona conflictos entre plugins, incompatibilidades del tema, una versión de PHP incompatible, el límite de memoria alcanzado o archivos del núcleo dañados.
El límite de memoria tiene su propia constante, WP_MEMORY_LIMIT, que WordPress intenta llevar a 40 MB en un sitio único y 64 MB en multisitio por defecto, según la documentación sobre wp-config.php.
Si el error menciona memoria agotada, se puede subir con define('WP_MEMORY_LIMIT', '96M');.
Un matiz: esa constante no supera el límite real que fija el hosting a nivel de servidor; si el problema persiste, hay que pedirle al proveedor que suba también su propio límite (criterio propio).
La misma documentación insiste en algo previo a editar ese archivo: tener copias de seguridad recientes y saber restaurarlas.

El sitio no carga o da error 500

El error 500 (Internal Server Error) tiene, según la documentación oficial, tres sospechosos habituales.

• Un archivo .htaccess dañado.
  Es, según la misma fuente, "la causa más probable".
  La solución que propone es renombrarlo por FTP (por ejemplo a .htaccess_old) y regenerar uno nuevo desde Ajustes → Enlaces permanentes en el wp-admin.
• El límite de memoria agotado.
  La recomendación es la misma que en el error crítico: subir WP_MEMORY_LIMIT en wp-config.php y, si no alcanza, revisar el límite del hosting.
• Conflictos de plugins o de tema.
  Se diagnostican con el mismo método de la primera sección: desactivar y reactivar de a uno, o comparar con un tema por defecto.

A esto se suma un cuarto sospechoso que puede impedir que el sitio cargue bien: los permisos de archivos.
La documentación oficial sobre permisos recomienda, para un hosting estándar, 644 en archivos y 755 en carpetas, con wp-config.php en 600 por tener las credenciales de la base de datos; en hostings con suexec, valores más restrictivos (640/750, y 440 o 400 para wp-config.php).
La misma fuente advierte contra "solucionarlo rápido" con permisos 777: si alguien sube o modifica un archivo malicioso en una carpeta con ese permiso, puede tomar control completo del sitio.
Revisar permisos es un paso más del diagnóstico, no la primera opción para probar.

Cuando el problema es la base de datos

Dos avisos concretos apuntan a la base de datos, no al código de plugins o temas.

• "Error al establecer una conexión con la base de datos".
  Según la documentación de errores comunes, "suele deberse a un error en el archivo wp-config.php": nombre de la base de datos, usuario, contraseña u host incorrectos.
  También puede deberse a que se agotó la cuota del hosting, a que el servidor de base de datos está caído, o a un sitio comprometido.
  Antes de tocar credenciales, confirma con el hosting que el servidor de base de datos está en pie.
• Tablas dañadas (error 145).
  La misma fuente lo describe así: "indica que una tabla de la base de datos está dañada o corrupta".
  Para repararlas, recomienda usar phpMyAdmin (opción de reparar tablas) o pedirle al hosting que ejecute una revisión y reparación, y aclara: "siempre haz una copia de la base de datos antes de realizar cualquier acción sobre ella".
• Reparación automática con WP_ALLOW_REPAIR.
  WordPress incluye una herramienta propia para esto.
  Según la documentación sobre wp-config.php, se activa agregando define('WP_ALLOW_REPAIR', true); y accediendo después a tu-sitio.com/wp-admin/maint/repair.php.
  La misma fuente advierte algo importante: con esa línea activa, cualquiera puede entrar a esa herramienta sin iniciar sesión, porque está pensada para reparar una base de datos dañada justo cuando el inicio de sesión no funciona.
  Por eso hay que quitar esa línea de wp-config.php en cuanto termina la reparación: dejarla es un riesgo de seguridad real, no una precaución exagerada.

WordPress lento: causas reales y cómo solucionarlo

Un sitio que carga, pero tarda, tiene causas distintas a uno caído, y todas se pueden verificar antes de decidir qué tocar.

• Sin caché activa.
  Un plugin de caché convierte páginas dinámicas en archivos estáticos y evita repetir ese trabajo en cada visita; a esto se suma la caché del navegador, que guarda en el equipo del visitante los archivos que no cambian, y la caché de objetos (Redis, Memcached), que acelera la recuperación de datos consultados seguido, según la documentación oficial sobre caché.
• Imágenes sin optimizar.
  La documentación sobre optimización del rendimiento recomienda asegurarse de que "todos los archivos de imagen estén optimizados", con el formato y la compresión correctos, y considerar un formato moderno como WebP.
• Plugins acumulados.
  La misma fuente lo pone como primer paso: "desactivar y eliminar los plugins innecesarios", porque la cantidad de plugins activos y su calidad individual afectan el rendimiento.
  Para detectar los que ya nadie mantiene, la guía de seguridad de WordPress explica cómo identificarlos.
• Hosting insuficiente.
  Pagar por un nivel de servicio superior, con más CPU, más memoria o almacenamiento SSD o NVMe, puede tener un efecto real sobre la velocidad, según la misma documentación.
  Es la variable que menos se resuelve desde el propio WordPress.
• PHP desactualizado.
  No es solo una cuestión de seguridad: las versiones nuevas de PHP suelen incluir mejoras de rendimiento respecto de las anteriores, apunta la documentación de optimización.
• Base de datos con residuos.
  La misma fuente recomienda reducir la cantidad de revisiones que WordPress guarda de cada publicación y mantener las opciones de carga automática (autoload) por debajo de 800 KB, porque una tabla de opciones inflada ralentiza cada carga.
  Buena parte de ese residuo suele venir de plugins fuera de uso: la guía de seguridad de WordPress explica cómo detectarlos y quitarlos.

Cómo confirmar que ya se resolvió

Esta parte es criterio propio: la documentación no define un procedimiento de verificación, pero sin él es fácil dar un problema por resuelto antes de tiempo.

• Si era un error crítico, una pantalla en blanco o un 500, confirma que el sitio carga sin ese aviso tanto en el frontend como en el wp-admin, y revisa que el registro de depuración (si lo activaste) no siga sumando líneas nuevas del mismo error.
  Después, desactiva WP_DEBUG de nuevo: no debe quedar activo en un sitio en producción.
• Si era lentitud, compara un antes y un después medible.
  No hace falta una herramienta especial: la pestaña de red de las herramientas de desarrollo del navegador muestra el tiempo hasta que la página termina de cargar, y sirve para comparar el mismo sitio, la misma página, antes y después del cambio.
  Sin esa comparación, "se siente más rápido" es una impresión, no una confirmación.

Antes de cualquier cambio: la copia de seguridad

Nada de lo anterior debería aplicarse directamente sobre un sitio en producción sin una copia de seguridad reciente y comprobada.
Editar wp-config.php, renombrar carpetas por FTP, reemplazar el .htaccess o cambiar permisos son operaciones seguras cuando hay forma de volver atrás, y arriesgadas cuando no la hay.
La propia documentación de WordPress sobre wp-config.php lo dice al pasar: antes de modificar esas constantes, hay que tener copias de seguridad regulares y saber restaurarlas.
Cómo hacerlas y comprobar que sirven está en la guía de copias de seguridad de WordPress: no se experimenta sobre producción sin esa red de contención.

Errores frecuentes

• Probar soluciones al azar sin diagnosticar antes.
  Cambiar varias cosas a la vez impide saber después cuál resolvió el problema, y puede sumar uno nuevo.
• Dejar WP_DEBUG o WP_DEBUG_DISPLAY activos en un sitio en producción.
  La documentación oficial lo desaconseja de forma explícita: expone información del error a cualquier visitante.
• Aplicar permisos 777 "para que funcione".
  Resuelve el síntoma y abre una puerta de seguridad seria, según la propia documentación sobre permisos.
• Tocar wp-config.php, el .htaccess o archivos del núcleo sin una copia de seguridad reciente.
  Es el paso que convierte un error solucionable en una noche perdida.
• Dejar plugins y temas sin usar acumulándose.
  Además del riesgo de seguridad que ya explicamos en esa guía, inflan la base de datos y afectan la velocidad de cada carga.
• Confundir "se siente más rápido" con una mejora comprobada.
  Sin medir un antes y un después, no hay forma de saber si el cambio funcionó o si fue una casualidad de esa visita.

TutorWP no diagnostica ni repara errores de WordPress: no escanea el código, no lee registros de errores ni corrige un sitio caído.
Eso sigue siendo un trabajo manual, sitio por sitio, con los pasos de esta guía.
Lo que aporta es lo anterior: un sitio con actualizaciones al día (ver la guía de mantenimiento de WordPress) y copias de seguridad recientes (ver la guía de copias de seguridad) es mucho más fácil de recuperar cuando algo falla.
Con TutorWP puedes ver ese estado —actualizaciones pendientes, última copia— de todos tus sitios en un panel, en lugar de entrar sitio por sitio a revisarlo.
Si quieres saber quiénes estamos detrás, conoce al equipo.