Una pantalla blanca o un 500 en WordPress rara vez aparecen por casualidad: suelen señalar un fallo concreto en PHP, un plugin, el tema o el servidor. Cuando la web cae, cada minuto cuenta y la prioridad no es probar opciones al azar, sino leer bien las pistas para recuperar el servicio con seguridad y sin agravar la incidencia.
Errores comunes: pantalla blanca (WSOD), 500 y debug suelen indicar fallos distintos, pero se diagnostican mejor con un orden claro: revisar logs, aislar plugins y tema, comprobar .htaccess, memoria PHP, permisos y cachés, y luego escalar a restauración de backup o ajustes del servidor si el problema persiste.
Resumen del proceso
- Identifica el síntoma exacto: WSOD, 500 o mensajes de debug.
- Revisa el último cambio antes de tocar archivos o plugins.
- Lee los logs y localiza archivo, línea y hora del fallo.
- Aísla plugins y tema con un orden seguro.
- Comprueba
.htaccess, memoria PHP, permisos y cachés.
- Si el admin está roto, desactiva por base de datos o restaura backup.
- Valida el servicio y deja una prevención mínima para no repetir la caída.
1Detecta el síntomaWSOD, 500 o debug roto
2Lee el logArchivo, línea y hora
3Aísla la causaPlugin, tema, caché o servidor
4Corrige con ordenSin romper más el sitio
5Valida y previeneBackup, caché y revisión final
Diferencia entre WSOD, error 500 y debug roto
La WSOD, el error 500 y un debug mal leído no significan lo mismo. La pantalla blanca suele ocultar un fatal error de PHP, el 500 apunta muchas veces al servidor o a una regla rota, y el debug solo sirve si se interpreta con contexto.
La frase que evita más errores es esta: no se corrige igual un fallo de PHP que un fallo del servidor web. Esa diferencia ahorra tiempo y evita tocar cosas que sí funcionaban.
Qué indica una pantalla blanca
La pantalla blanca de la muerte, o WSOD, aparece cuando WordPress no puede mostrar nada útil. Suele pasar por un plugin roto, un tema con un error o una incompatibilidad de PHP.
El error típico aquí es desactivar cosas al azar. Eso funciona a veces, pero en la práctica suele borrar la pista buena y obliga a repetir pruebas.
Un caso habitual: un plugin de caché falla tras una actualización y deja la home en blanco. Al revisar el log aparece el archivo exacto y la línea que rompe la carga, y la web vuelve en minutos.
Cuándo el 500 apunta al servidor
El error 500 dice que el servidor no pudo responder bien. Puede venir de .htaccess, permisos, PHP-FPM, una regla de seguridad o una caché mal servida.
Los datos apuntan a que muchos 500 se resuelven antes de tocar WordPress si se revisa primero el servidor web. La propia documentación de PHP recuerda que los errores deben registrarse para poder leerlos con precisión.
Cuando el 500 aparece justo tras cambiar reglas, casi nunca conviene rehacer todo el sitio. Primero toca revertir el último cambio, porque ahí suele estar la pista buena.
Qué muestra el debug de verdad
WP_DEBUG no arregla nada por sí solo. Solo activa mensajes que luego hay que leer, y eso exige mirar el archivo, la línea y la hora exacta.
Lo que omiten la mayoría de guías sobre debug es que el log sin contexto engaña. Un aviso de hace dos días no sirve para una caída de hoy, y un aviso antiguo puede no tener nada que ver.
Si el mensaje apunta a un archivo de plugin, la prioridad es ese plugin. Si apunta a un tema, el foco cambia. Si apunta a PHP o al servidor, WordPress ya no es el único sospechoso.
Lee los logs y localiza la causa exacta
El log correcto te dice qué archivo falló, en qué línea y a qué hora. Esa combinación acorta mucho el diagnóstico y evita probar soluciones que no tocan el origen.
Qué buscar en error_log y debug.log
Busca cuatro cosas: archivo, línea, tipo de error y fecha. Si ves un fatal error, una llamada a una función inexistente o un problema de memoria, ya tienes un punto de partida real.
Un log útil no dice solo que algo falló. Dice qué falló, dónde falló y cuándo empezó a fallar.
La mayoría de guías dicen “activa debug”. Lo que no mencionan es que, sin leer el log completo, eso solo añade ruido. El archivo de error del hosting suele dar más contexto que la pantalla.
Cómo leer archivo, línea y fecha
El nombre del archivo te dice qué pieza se rompió. La línea te lleva al punto exacto. La fecha te ayuda a cruzarlo con la última actualización, migración o cambio de caché.
Si el log dice algo como “in wp-content/plugins/nombre-del-plugin/... on line 214”, el foco está casi siempre ahí. Si la ruta acaba en themes/, el tema entra en la lista de sospechosos.
En la captura adjunta se ve muy bien esta relación entre hora, archivo y línea. Ese patrón es el que permite ir directo al origen, sin dar vueltas.
Cómo cruzarlo con el último cambio
Revisa la última acción hecha antes de la caída. Puede ser una actualización automática, un cambio de PHP, una regla nueva en el servidor o una caché que no se vació bien.
Esto funciona bien en teoría, pero en la práctica la coincidencia temporal manda. Si el error aparece justo después de tocar un plugin, el orden de sospecha es casi obvio.
Un fallo frecuente es mirar solo el mensaje y olvidar el contexto. Un mismo error puede venir de causas distintas según la hora en que aparece y el cambio que lo precede.
Cuando el debug devuelve una ruta y una línea, el siguiente paso útil es interpretar el patrón del mensaje. No es lo mismo un fatal error PHP por una función inexistente que un Allowed memory size exhausted o un problema de permission denied. El primero suele señalar código incompatible o una actualización rota; el segundo, un límite de memoria insuficiente; el tercero, permisos de archivos o una ruta mal resuelta. En logs del servidor también conviene mirar si el error se repite cada pocos segundos o solo al cargar una URL concreta, porque esa frecuencia ayuda a distinguir entre un fallo global y uno puntual.
En muchos casos, un mensaje como Call to undefined function dentro de plugins conflictivos o un theme broken apunta directamente a la pieza dañada sin necesidad de más pruebas.
Aísla plugins, tema y caché sin romper más el sitio
Aislar componentes permite encontrar al culpable sin desmontar toda la web. Primero se aparta lo que cambia más, luego lo que afecta menos, y por último la capa de caché.
Qué desactivar primero si no entra al admin
Si el panel no carga, desactiva plugins por base de datos o por FTP antes de borrar nada. Es la forma rápida y segura cuando el escritorio está roto.
Empieza por plugins de caché, seguridad y constructores visuales. Suelen tocar más capas y, cuando fallan, dejan síntomas muy parecidos a WSOD o 500.
WordPress nació en 2003 de la mano de Matt Mullenweg y Mike Little, y esa base modular sigue siendo su fuerza y su riesgo. WordPress.org explica cómo funciona su arquitectura abierta.
Cuándo tocar tema, plugins o memoria PHP
Si el log apunta a un plugin, el tema no va primero. Si el error menciona una función del tema, no sirve revisar una extensión que no participa en esa ruta.
Subir memoria PHP puede ayudar si el error habla de límite agotado. Si el problema real es un archivo corrupto, ese aumento solo tapa el síntoma durante un rato.
El orden correcto ahorra tiempo. Primero se localiza el archivo o función rota, luego se cambia la pieza justa, y solo después se ajustan límites o memoria.
| Síntoma |
Qué revisar primero |
Acción rápida |
| WSOD tras actualizar |
Plugins y tema |
Desactivar el último cambio y leer el log |
| Error 500 tras tocar reglas |
.htaccess, permisos y servidor web |
Restaurar el archivo previo y probar |
| Debug con aviso concreto |
Archivo, línea y fecha |
Ir al origen exacto, no al síntoma |
Ajusta apache, nginx o LiteSpeed según el caso
El servidor cambia el diagnóstico. Apache suele dar pistas en .htaccess, Nginx mira más a reglas y fastcgi, y LiteSpeed mezcla caché de servidor con PHP y plugins de optimización.
Apache: reglas, permisos y .htaccess
En Apache, un 500 tras guardar enlaces permanentes suele apuntar a .htaccess. Si el archivo está mal escrito, el servidor corta la respuesta de golpe.
Revisa también permisos de carpetas y archivos. Un permiso roto puede parecer un fallo de WordPress cuando en realidad es una restricción del servidor.
Si el error aparece tras activar una regla de seguridad, vuelve al estado anterior. Lo más seguro es restaurar la versión válida y validar una sola cosa cada vez.
Nginx: fastcgi y caché
En Nginx, el problema no suele estar en .htaccess porque no se usa igual que en Apache. Aquí pesan más las reglas del bloque de sitio, fastcgi y la caché intermedia.
Si el log habla de backend agotado, PHP-FPM puede estar detrás. Un pool caído o saturado deja errores que parecen de WordPress, pero nacen en el servicio de PHP.
LiteSpeed y WooCommerce
LiteSpeed y WooCommerce hacen buena pareja cuando todo está bien. Cuando no, la caché puede servir páginas viejas, carritos rotos o respuestas mezcladas tras un cambio.
Para WooCommerce, limpia primero la caché del plugin, luego la del servidor y por último la CDN. Si se hace al revés, la página puede seguir mostrando el fallo aunque ya se haya corregido.
El orden de diagnóstico cambia según la plataforma y el servidor. En WordPress y WooCommerce, lo más eficaz suele ser aislar la incidencia empezando por plugins, tema y caché, porque la capa de aplicación es la que más cambia. En PrestaShop, en cambio, es frecuente que el error aparezca tras una actualización de módulos, una modificación en el server web o una caché mal invalidada. En Apache, .htaccess y permisos de archivos suelen ser los primeros sospechosos; en Nginx, pesan más fastcgi, reglas del bloque de sitio y caché; y en LiteSpeed, la combinación de caché y optimización puede provocar una pantalla blanca o un error 500 aunque el código esté correcto.
Un flujo priorizado evita perder tiempo probando lo mismo en todos los casos y ayuda a atacar la capa más probable desde el inicio.
Recupera acceso cuando el admin está roto
Si el panel no entra, la recuperación pasa por la base de datos, el FTP o el panel del hosting. Esa vía devuelve control sin depender del escritorio de WordPress.
Desactiva plugins desde la base de datos
Cambia el nombre de la carpeta de plugins o desactívalos desde la base de datos si no hay acceso al panel. Es una medida rápida cuando el fallo impide entrar al administrador.
El error más frecuente en este punto es desactivar todo y no dejar rastro. Mejor registrar qué se desactivó y en qué orden, porque luego hace falta volver atrás con cabeza.
Un caso habitual: un WooCommerce queda en WSOD tras una actualización automática. Al desactivar el plugin conflictivo desde la base de datos, el admin vuelve y el resto del sitio queda disponible para revisar con calma.
Fuerza un tema por defecto
Si el log apunta al tema, fuerza uno por defecto como Twenty Twenty-Four. Esto separa el problema del diseño y deja claro si la incidencia vive en el tema activo.
No hace falta tocar todos los temas. Basta con probar uno estable y reciente para saber si el fallo desaparece.
Cuándo restaurar un backup limpio
Restaura un backup cuando la causa ya no merece más pruebas o cuando el sitio debe volver ya mismo. Es la opción más limpia si la caída coincide con una actualización grande o una migración fallida.
El backup debe ser anterior al fallo, no posterior. Parece obvio, pero aquí se rompe más de una recuperación por elegir una copia ya contaminada.
En incidencias que no se resuelven con WordPress o el tema, conviene revisar la capa de infraestructura. Un PHP-FPM saturado, un límite de procesos demasiado bajo o una caché a nivel servidor corrupta pueden provocar error 500 intermitente, tiempos de espera o una white screen of death que solo aparece bajo carga. También tiene sentido comprobar si la restauración de backup debe hacerse desde una copia limpia anterior al fallo, especialmente cuando la actualización dejó la base de datos a medias o rompió la compatibilidad entre archivos y contenido.
En sitios con tráfico o tienda online, volver a una versión estable puede ser más rápido y seguro que seguir probando cambios aislados cuando el servidor ya muestra signos de saturación.
Evita que el mismo fallo vuelva a caer
La recuperación no termina al ver la home otra vez. Hace falta cerrar el origen y dejar una base mínima para que el siguiente cambio no repita la caída.
Memoria PHP, timeouts y versiones
Revisa memoria PHP, límites de ejecución y versión activa. Si el log ya avisaba de falta de memoria, el sitio puede volver a caer en cuanto aumente la carga.
PHP tiene ciclos de versión y compatibilidad que cambian con frecuencia. Muchos fallos se ven al saltar entre versiones sin comprobar la compatibilidad real.
Actualizaciones seguras de plugins y
Actualiza primero en una copia o en un entorno de pruebas si el sitio es crítico. Después aplica cambios pequeños, uno por uno, y valida el log tras cada paso.
Eso reduce sorpresas en tiendas y webs con tráfico. En Madrid y Barcelona, donde muchas webs de negocio no pueden parar ni un rato, este orden ahorra llamadas urgentes.
Caché, CDN y servidor web
Limpia la caché en el orden correcto: plugin, servidor y CDN. Si no, una capa vieja puede seguir enseñando el error aunque la causa ya esté corregida.
WP_DEBUG, WP_DEBUG_LOG y WP_DEBUG_DISPLAY ayudan, pero no sustituyen la lectura del log. La documentación oficial de WordPress.org explica cómo activarlos con cuidado.
Errores que arruinan el resultado
Los fallos más caros aquí no son técnicos. Son de orden. Se rompe más por tocar cinco cosas a la vez que por el error original.
Desactivar a ciegas
Desactivar plugins o cambiar el tema sin revisar el log primero suele borrar la pista más útil. El sitio puede volver, sí, pero nadie sabrá por qué cayó.
Eso obliga a repetir el trabajo y deja la incidencia abierta para la próxima actualización.
Reescribir .htaccess sin mirar más
Rehacer .htaccess no arregla un fallo de PHP ni una caída de PHP-FPM. Solo ayuda si el origen está en reglas o reescrituras.
Si el log apunta a otro sitio, el cambio solo maquilla el síntoma durante un rato.
Activar debug y dejarlo así
Dejar WP_DEBUG_DISPLAY activo en producción muestra rutas y detalles que no deberían verse. También puede crear ruido en la web y asustar a usuarios o clientes.
La práctica segura es activar debug para diagnosticar, leer el resultado y volver a dejarlo cerrado.
Esto no funciona como primera solución si el problema es de dominio, DNS, certificado SSL, caída total del servidor o mantenimiento externo al propio WordPress. Tampoco sirve si la web carga bien y solo muestra un fallo visual menor sin error técnico real.
Preguntas frecuentes sobre WSOD, 500 y debug
¿Cuáles son los errores 500 más comunes?
Los más comunes son reglas rotas en .htaccess, permisos incorrectos, caché corrupta y fallos de PHP-FPM. En WordPress, también aparece tras actualizar un plugin o un tema. Si el log marca un archivo concreto, la solución suele ser más rápida que rehacer toda la configuración.
¿Qué es el error 500 y cómo solucionarlo?
El error 500 es un fallo interno del servidor. Se corrige revisando primero el último cambio, luego .htaccess, permisos, caché y logs. Si el servidor usa Nginx o LiteSpeed, también conviene mirar la capa de PHP y la caché del propio servidor.
¿Qué significa el error 500 en la pantalla?
Significa que el servidor no pudo devolver una página válida. No apunta por sí solo a WordPress, y por eso no conviene empezar por el panel. La pista buena suele estar en el log del hosting o en el archivo de error de PHP.
¿Cuáles son las causas del error 500?
Las causas más habituales son un .htaccess mal escrito, permisos defectuosos, memoria PHP baja, una actualización fallida o un conflicto con caché. En sitios WooCommerce, también puede venir de un plugin de pago, seguridad o rendimiento.
¿Cómo saber si es WSOD o un fatal error de PHP?
Si la pantalla queda en blanco y el log muestra un fatal error, casi seguro es un fallo de PHP. La WSOD es el síntoma visible, no la causa. El archivo, la línea y la hora del log confirman el origen real.
¿WP_DEBUG basta para encontrar el problema?
No, solo ayuda a verlo mejor. WP_DEBUG muestra pistas, pero hay que leer el log con contexto y cruzarlo con el último cambio hecho. Sin esa parte, el debug añade ruido y puede llevar a una solución equivocada.
¿Cuándo conviene restaurar un backup en lugar de seguir probando cambios?
Conviene restaurar un backup cuando el sitio crítico debe volver ya, el log no da una causa clara o la incidencia empezó tras una actualización grande. Es mejor volver a una copia limpia que seguir tocando piezas a ciegas y ampliar la caída.
Si el log apunta a un archivo concreto, ese archivo manda. Si el panel no entra, desactiva plugins por base de datos y revisa el último cambio antes de tocar memoria o `.htaccess`.
Revisa logs, restaura con orden y cierra la causa
La salida más segura combina lectura de logs, aislamiento de la pieza rota y recuperación por capas. Primero se localiza el origen. Después se corrige. Al final se valida que no haya quedado otra puerta abierta.
Un diagnóstico limpio suele tardar entre 10 y 20 minutos si el log está accesible y el último cambio está claro. Si interviene servidor, caché o PHP-FPM, la revisión puede irse a 30 o 40 minutos. Eso sigue siendo más rápido que probar a ciegas y romper más cosas.
La clave no es saber muchos trucos. Es seguir el orden correcto y no saltarse la pista buena cuando ya está delante.
