La idea clave: la mayoría de los errores de WordPress — pantalla blanca, error 500, memoria agotada, 404 tras una migración — se remontan a una de cuatro causas raíz: un conflicto de plugin/tema, un límite de memoria o ejecución de PHP, un archivo .htaccess corrupto, o un problema de conexión a la base de datos. Diagnosticar cuál está ocurriendo, en lugar de probar correcciones al azar, hace que un sitio vuelva a funcionar más rápido.
Por qué siguen volviendo los mismos errores
WordPress funciona sobre PHP, un servidor web y una base de datos, y la mayoría de los errores con los que se topan los propietarios de sitios son en realidad fallos en una de esas tres capas que salen a la superficie a través de WordPress, más que errores del propio núcleo de WordPress. Es útil saberlo porque significa que la solución no suele ser "reinstalar WordPress" — sino identificar qué capa falló y abordar eso específicamente.
Las cuatro causas raíz de abajo representan la gran mayoría de los errores de WordPress reportados en foros de soporte y tickets de hosting, y cada una tiene una solución específica y repetible en lugar de un vago "prueba a vaciar la caché".
La Pantalla Blanca de la Muerte (WSOD)
Una página completamente en blanco, sin ningún mensaje de error visible, casi siempre significa que ocurrió un error fatal de PHP, pero la configuración por defecto de WordPress oculta los errores a los visitantes en lugar de mostrarlos. Los dos desencadenantes más comunes son un plugin o tema incompatible con la versión de PHP actual del sitio, y que el sitio agote su límite de memoria PHP asignado a mitad de una solicitud.
Para diagnosticarlo: activa el modo de depuración añadiendo dos líneas a wp-config.php — define('WP_DEBUG', true); y define('WP_DEBUG_LOG', true); — lo que escribe el error real de PHP en un archivo debug.log dentro de wp-content en lugar de ocultarlo. Esto está documentado en la propia guía oficial de depuración de WordPress. Una vez visible el error específico y el archivo, la solución suele ser desactivar el único plugin o tema mencionado en el registro.
Si el FTP o un gestor de archivos es el único acceso disponible (porque el WSOD también bloquea el panel de administración), renombrar la carpeta plugins dentro de wp-content obliga a que todos los plugins se desactiven a la vez — el sitio debería volver a cargar, y los plugins pueden reactivarse uno por uno para encontrar al culpable.
500 Internal Server Error
A diferencia de la pantalla blanca, un error 500 es un mensaje de fallo genérico a nivel de servidor, no específico de WordPress — puede provenir de un archivo .htaccess corrupto, un conflicto de plugins, un tiempo de espera de ejecución de PHP agotado, o una mala configuración del servidor totalmente ajena al propio código de WordPress. Por eso revisar el registro de errores real del servidor (disponible en la mayoría de los paneles de control de hosting) es un primer paso más fiable que adivinar.
Soluciones comunes, ordenadas por frecuencia con la que resuelven el problema:
- Renombra .htaccess temporalmente (WordPress regenera uno por defecto al volver a guardar los ajustes de Enlaces Permanentes) — soluciona de inmediato los errores 500 relacionados con corrupción.
- Desactiva todos los plugins vía phpMyAdmin renombrando la fila active_plugins de la tabla wp_options, si el acceso al administrador está roto.
- Aumenta el límite de tiempo de ejecución de PHP si el error solo ocurre en operaciones pesadas como importaciones grandes.
Error "Allowed Memory Size Exhausted"
Este error específico y detallado de PHP ("Allowed memory size of X bytes exhausted") significa que un script intentó usar más memoria de la que PHP permite, y es uno de los errores de WordPress más autoexplicativos, ya que nombra el problema exacto en el propio mensaje.
La solución tiene dos niveles. Primero, aumenta el propio límite de memoria de WordPress añadiendo define('WP_MEMORY_LIMIT', '256M'); a wp-config.php. Segundo, si eso no lo resuelve, puede que también haya que aumentar el memory_limit de PHP subyacente definido por el propio entorno de hosting — la constante de WordPress no puede superar lo que el servidor permite, así que a veces es inevitable un ticket de soporte con el hosting o una edición de php.ini.
Tabla de referencia rápida
| Error | Causa más común | Primera solución a probar |
|---|---|---|
| Pantalla blanca (WSOD) | Error fatal de PHP de plugin/tema | Activar WP_DEBUG, revisar debug.log |
| 500 Internal Server Error | .htaccess corrupto o conflicto de plugins | Regenerar .htaccess vía Enlaces Permanentes |
| Memoria agotada | Límite de memoria PHP demasiado bajo | Aumentar WP_MEMORY_LIMIT en wp-config.php |
| 404 en todas las páginas excepto la portada | Reglas de reescritura desincronizadas | Volver a guardar los ajustes de Enlaces Permanentes |
| Error de conexión a la base de datos | Credenciales incorrectas o tabla corrupta | Verificar credenciales de BD en wp-config.php |
Errores 404 tras una migración o actualización
Si la portada carga pero todas las demás páginas devuelven un 404, la estructura de enlaces permanentes almacenada en la base de datos de WordPress se ha desincronizado de las reglas de reescritura almacenadas en .htaccess — un efecto secundario común de cambiar de hosting, restaurar una copia de seguridad o cambiar de servidor. Volver a guardar la página de ajustes de Enlaces Permanentes en el panel de WordPress (Ajustes → Enlaces Permanentes → Guardar Cambios, sin necesidad de un cambio real) regenera .htaccess y normalmente lo soluciona de inmediato.
Errores de conexión a la base de datos
"Error establishing a database connection" significa que WordPress no puede alcanzar la base de datos MySQL/MariaDB en absoluto, lo cual es distinto de los errores anteriores ya que ocurre antes de que WordPress pueda siquiera cargar lo suficiente como para mostrar su propio estilo de error. Las dos causas más comunes son credenciales de base de datos incorrectas en wp-config.php (a menudo tras una migración) y una tabla de base de datos corrupta, más frecuentemente wp_options. Verificar las constantes DB_NAME, DB_USER, DB_PASSWORD y DB_HOST en wp-config.php contra el panel de hosting real resuelve el caso de credenciales; una herramienta de reparación de base de datos proporcionada por el hosting suele resolver la corrupción de tablas.
Una forma sistemática de diagnosticar cualquier error de WordPress
- Revisa el error real, no solo el síntoma — activa WP_DEBUG o revisa el registro de errores del servidor en lugar de adivinar a partir de una pantalla en blanco o un mensaje genérico.
- Prueba en una copia, no en el sitio en producción, siempre que la solución implique desactivar plugins o editar archivos del núcleo — un sitio de staging existe exactamente para esto.
- Cambia una sola cosa a la vez — desactivar todos los plugins simultáneamente te dice que un plugin es la causa, no cuál.
- Descarta causas a nivel de hosting — las incompatibilidades de versión de PHP y los límites de memoria bajos suelen ser un problema de configuración del hosting, no de WordPress; consulta nuestra guía más amplia de velocidad y configuración de WordPress para los factores a nivel de hosting que también afectan las tasas de error.
Prevenir estos errores desde el principio
Los plugins mal programados — especialmente galerías de imágenes pesadas o herramientas de procesamiento de medios que cargan grandes bibliotecas en memoria en cada solicitud — son una fuente desproporcionadamente común de fallos por agotamiento de memoria. Una alternativa más ligera que usa las bibliotecas de imágenes nativas del servidor en lugar de cargar una pila de procesamiento externa, como Erdo Image Optimizer, añade notablemente menos sobrecarga de memoria que plugins de medios todo en uno más pesados.
Más allá de la elección de plugins, los mismos hábitos que previenen errores también los hacen más rápidos de solucionar cuando sí ocurren: mantener copias de seguridad regulares, probar actualizaciones en una copia de staging antes de subirlas a producción, y mantener PHP y el núcleo de WordPress razonablemente actualizados para que los errores de incompatibilidad no se acumulen año tras año por negligencia.
Errores comunes al solucionar errores de WordPress
- Reinstalar el núcleo de WordPress como primera respuesta, cuando la causa real es casi siempre un plugin, tema o ajuste a nivel de hosting específico.
- Desactivar y reactivar plugins uno por uno en el sitio en producción durante horas laborales, cuando una copia de staging permitiría encontrar al culpable sin tiempo de inactividad visible para los visitantes.
- Ignorar por completo el registro de errores e intentar soluciones al azar basadas en el síntoma visible (una página en blanco) en lugar del error real de PHP detrás de él.
- Editar wp-config.php sin una copia de seguridad previa, convirtiendo un error recuperable en un sitio que no carga en absoluto si se introduce un error tipográfico.
- Asumir que un error 500 siempre es culpa de WordPress, cuando la mala configuración a nivel de servidor y los fallos genéricos de PHP producen el mismo mensaje.
Para terminar
En resumen, la pantalla blanca, los errores 500, el agotamiento de memoria y los enlaces permanentes rotos que constituyen la mayoría de las solicitudes de solución de problemas de WordPress se remontan todos a un pequeño conjunto de causas raíz — conflictos de plugin/tema, límites de PHP, corrupción de .htaccess o problemas de base de datos — cada una con una solución específica y repetible. Activar el modo de depuración y leer el error real, en lugar de adivinar a partir del síntoma visible, es el único hábito que convierte una interrupción estresante en una solución de cinco minutos.