Pantalla blanca en WordPress tras actualizar PHP: solución - ilustracion

Cómo actualizar PHP en WordPress en 4 pasos

Actualizado el 21/04/2026: Agregamos una guía completa para resolver la pantalla blanca de WordPress tras actualizar PHP, con métodos paso a paso para diagnosticar y solucionar el error sin perder datos.

En 30 segundos

La pantalla blanca de WordPress (WSOD) es uno de los errores más comunes tras actualizar PHP. Aparece cuando un plugin, tema o configuración del servidor no es compatible con la nueva versión. La solución pasa por activar el modo debug, revisar el memory limit, desactivar plugins o corregir el archivo .htaccess. En la mayoría de los casos se resuelve en menos de 10 minutos siguiendo los pasos de esta guía.

El preprocesador de hipertexto (PHP) es un lenguaje de programación de código abierto que se utiliza para la personalización avanzada y para garantizar que los sitios web de WordPress funcionen al máximo.

PHP es la base del software, los temas y los plugins de WordPress. El lenguaje también es utilizado por los sitios web de WordPress para interactuar con sus bases de datos.

Tener la versión más reciente de PHP en tu sitio web mejora la seguridad y el rendimiento, y garantiza que el tema y los complementos estén al día. Sin embargo, actualizar PHP puede traer una consecuencia inesperada: la pantalla blanca. Si te encontrás con eso, no entres en pánico. Tiene solución.

¿Por qué debería actualizar PHP en WordPress?

PHP recibe actualizaciones y parches con frecuencia, al igual que los temas y plugins de WordPress. Usar una versión antigua puede causar problemas de rendimiento y aumentar la vulnerabilidad del sitio ante ataques.

Mejor rendimiento. Con cada actualización, PHP mejora su eficiencia y puede aumentar la velocidad de carga notablemente.
Mayor seguridad. Las versiones sin soporte activo ya no reciben parches de seguridad. Cualquier vulnerabilidad descubierta queda expuesta indefinidamente.
Nuevas funciones. PHP 8.2 incorporó atributos para parámetros sensibles, mejoras en el sistema de tipificación y soporte para constantes en traits. PHP 8.3 sumó tipado más granular y mejor manejo de fechas.
Compatibilidad mejorada. Los plugins y temas modernos se optimizan para PHP 8.x. Correr versiones viejas genera incompatibilidades silenciosas.

Compatibilidad con las versiones PHP de WordPress

WordPress admite múltiples versiones de PHP, pero no todas las combinaciones funcionan igual. Usá la siguiente tabla como referencia antes de actualizar:

WP Versión	5.6	7.0	7.1	7.2	7.3	7.4	8.0	8.1	8.2	8.3
6.5+	N	N	S	S	S	S	S#	S#	S*	S*
6.3	N	S	S	S	S	S	S#	S#	S*	N
6.2	S	S	S	S	S	S	S*	S*	S*	N
6.1	S	S	S	S	S	S	S*	S*	S*	N

S = Compatible, S* = Compatible con advertencias, S# = Compatible con notices, N = No compatible

pantalla blanca wordpress php diagrama explicativo

¿Qué es la pantalla blanca de WordPress (WSOD)?

La pantalla blanca de WordPress —conocida en inglés como White Screen of Death o WSOD— es exactamente lo que el nombre dice: entrás a tu sitio y encontrás una página completamente en blanco. Sin mensaje de error, sin indicación de qué salió mal. Solo blanco.

Lo que pasa por debajo es que PHP encontró un error fatal y WordPress no puede ejecutar el código necesario para mostrar siquiera una pantalla de error. El servidor procesa la solicitud, falla, y devuelve una respuesta HTTP 200 (o 500, según el servidor) con un cuerpo vacío. Para el visitante, es como si el sitio hubiera desaparecido. Para más detalles técnicos, mirá consultar la comunidad de WordPress.

Esto es particularmente frustrante porque no hay nada visible que te diga dónde buscar. Ahí entra el modo debug, que es el primer paso para cualquier diagnóstico serio. Según la documentación oficial de WordPress, la WSOD figura entre los errores más frecuentes reportados por administradores de sitios.

Causas principales de pantalla blanca tras actualizar PHP

No todas las pantallas blancas tienen el mismo origen. Identificar la causa correcta ahorra tiempo y evita soluciones a ciegas. Estas son las más comunes cuando el problema aparece justo después de cambiar la versión de PHP:

Incompatibilidad de plugins o temas. El caso más frecuente. Un plugin desarrollado para PHP 7.4 puede usar funciones que en PHP 8.0+ fueron eliminadas o modificadas. El plugin falla silenciosamente y arrastra al resto del sitio.
Funciones deprecated en PHP 8.x. PHP 8.0 eliminó o cambió el comportamiento de varias funciones: create_function(), each(), implode() con argumentos invertidos, y el manejo de errores con @ en algunos contextos. PHP 8.2 deprecó la sintaxis callable dinámica. Si un plugin usa cualquiera de estas, revienta.
Memory limit agotado. PHP tiene un límite de memoria configurable. Si un proceso lo supera, se corta la ejecución. En servidores compartidos, 64MB o 128MB es insuficiente para WordPress con plugins activos.
Archivo .htaccess corrupto. Ocurre cuando una actualización de WordPress o un plugin modifica el .htaccess y lo deja con reglas inválidas para la versión actual del servidor.
Conflictos entre versiones. WordPress core + plugins + tema + PHP forman una cadena. Un eslabón incompatible rompe todo. Actualizar PHP sin verificar compatibilidad de plugins es el camino más rápido a la WSOD.

Método 1: Habilitar el modo debug de WordPress

El primer paso antes de tocar cualquier otra cosa es activar el debug. Sin información del error, cualquier otra acción es un disparo en la oscuridad. El modo debug de WordPress registra todos los errores PHP en un archivo de log que podés leer desde FTP o el administrador de archivos de tu hosting.

Accedé al archivo wp-config.php en la raíz de tu instalación (vía FTP o el administrador de archivos del panel de control) y buscá la línea que dice define( 'WP_DEBUG', false );. Reemplazala por este bloque:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_LOG escribe los errores en el archivo /wp-content/debug.log. WP_DEBUG_DISPLAY en false evita que los errores aparezcan en pantalla para los visitantes, lo que es importante si el sitio está en producción.

Una vez activado, recargá el sitio y después abrí el archivo debug.log. Las últimas líneas van a mostrar el error exacto: el archivo PHP que falló, la línea y el tipo de error. Ese dato es lo que necesitás para saber si el problema está en un plugin específico, en el tema, o en otra parte.

Eso sí: desactivá el debug apenas termines el diagnóstico. Dejar WP_DEBUG en true en producción expone información del sistema que no debería ser pública.

Método 2: Aumentar el límite de memoria PHP

Si el debug.log muestra algo como Allowed memory size of X bytes exhausted, el problema es el memory limit. WordPress con un conjunto típico de plugins puede requerir entre 128MB y 256MB para operar sin problemas. Muchos hostings compartidos arrancan con valores menores.

La solución más directa es agregar esta línea en wp-config.php, antes de la línea que dice /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );

Si eso no alcanza (porque el límite del servidor está configurado por debajo del valor que pedís), hay que subirlo desde otra capa. Podés intentarlo agregando esta línea al archivo .htaccess: Cubrimos ese tema en detalle en si tu tienda usa WooCommerce.

php_value memory_limit 256M

O directamente en el php.ini si tenés acceso:

memory_limit = 256M

Si ninguna de esas opciones tiene efecto, el límite lo está imponiendo el servidor a nivel de configuración global y necesitás contactar a tu proveedor de hosting para que lo ajuste. En DonWeb, este ajuste se puede gestionar directamente desde el panel de control sin necesidad de abrir un ticket.

Método 3: Desactivar todos los plugins

Si el debug log apunta a un plugin específico, la solución es directa: desactivarlo. Pero si la pantalla blanca impide acceder al panel de administración, no podés usar la interfaz de WordPress. Hay que hacerlo por FTP.

Conectate por FTP o el administrador de archivos de tu hosting y navegá hasta la carpeta /wp-content/. Ahí vas a encontrar la carpeta plugins. Renombrala a plugins_desactivados. WordPress no va a encontrar la carpeta y va a desactivar todos los plugins automáticamente. Si el sitio vuelve, el problema estaba en alguno de ellos.

El paso siguiente es identificar cuál. Volvé a renombrar la carpeta a plugins y entrá al panel de administración (que ahora debería cargar). Desde ahí, activá los plugins de a uno, recargando el sitio después de cada activación. Cuando la pantalla blanca vuelva, encontraste al culpable.

PHP 8.x rompió compatibilidad con varios plugins conocidos en versiones antiguas: algunos constructores de páginas, plugins de caché que usan eval(), y plugins de formularios con sintaxis de PHP 7. Revisá el repositorio oficial del plugin para ver si hay una versión actualizada o si el mantenedor ya publicó un fix.

Método 4: Restaurar el archivo .htaccess

El .htaccess es un archivo de configuración de Apache que WordPress usa para gestionar las URLs y los permalinks. Si está corrupto o tiene reglas inválidas, puede causar una pantalla blanca que el debug.log no siempre muestra claramente.

Para descartarlo como causa: navegá por FTP a la raíz de tu instalación y renombrá el archivo .htaccess a .htaccess_old. Recargá el sitio. Si cargó, el .htaccess era el problema.

La solución permanente no es dejarlo renombrado, sino regenerarlo. Desde el panel de WordPress, andá a Ajustes → Enlaces permanentes y hacé clic en «Guardar cambios» sin modificar nada. WordPress va a generar un .htaccess nuevo y limpio. Si el problema era una regla corrupta de un plugin de caché o de redirección, esta regeneración la elimina.

Si el sitio no cargó después de renombrar el .htaccess, el problema está en otra parte. Restaurá el archivo a su nombre original y pasá al siguiente método. Relacionado: crear una página de prueba.

Método 5: Verificar compatibilidad con PHP 8.0, 8.1, 8.2 y superiores

PHP 8.0 fue un salto importante que eliminó o cambió el comportamiento de varias funciones que existían desde PHP 5.x. Eso generó una ola de incompatibilidades en plugins que llevaban años sin actualizarse. PHP 8.1 y 8.2 continuaron esa tendencia, deprecando más patrones de código heredado.

Lo que cambió con PHP 8.0 que más afecta a WordPress:

Eliminación de funciones deprecadas: create_function(), each(), y varias funciones de Mcrypt fueron eliminadas definitivamente.
Cambios en el manejo de strings y arrays: operaciones que antes devolvían false ahora lanzan excepciones tipadas, lo que rompe código que no las manejaba.
JIT Compiler: mejora el rendimiento, pero puede exponer bugs latentes en código que antes «funcionaba por suerte».

Con PHP 8.2, la deprecación de la sintaxis callable dinámica ($obj->method pasado como string) afectó a varios plugins que usaban ese patrón para registrar callbacks. PHP 8.3 continuó esa dirección con tipado más estricto.

Para verificar qué versión de PHP está corriendo tu sitio, podés crear un archivo phpinfo.php en la raíz con el contenido <?php phpinfo(); ?>, acceder a él desde el navegador, y borrarlo inmediatamente después. Otra opción es revisar la sección de PHP en el panel de tu hosting.

Ahora bien: PHP 8.0 y 8.1 ya no reciben soporte de seguridad desde finales de 2024. Correr esas versiones expone el servidor a vulnerabilidades sin parche. En 2026, PHP 8.2 es el mínimo recomendable, y PHP 8.3 es la opción más segura.

Comparativa: pantalla blanca según la versión de PHP

Versión PHP	Estado de soporte	Riesgo de WSOD	Causa más común
7.4	Sin soporte desde dic 2022	Bajo (plugins viejos compatibles)	Memory limit en sitios grandes
8.0	Sin soporte desde nov 2023	Alto (muchos cambios de ruptura)	Funciones eliminadas, plugins desactualizados
8.1	Sin soporte desde dic 2024	Medio	Callable syntax deprecated, tipos estrictos
8.2	Soporte activo (hasta dic 2026)	Bajo si plugins están actualizados	Plugins con dynamic properties deprecadas
8.3	Soporte activo (hasta dic 2027)	Muy bajo	Código extremadamente antiguo

Tabla de riesgo de pantalla blanca en WordPress según versión de PHP activa.

Cómo prevenir la pantalla blanca en futuras actualizaciones

El error ya ocurrió, lo resolviste, y ahora querés que no vuelva a pasar. Hay algunas prácticas concretas que reducen el riesgo a casi cero.

Hacé un backup completo antes de cualquier actualización. Parece obvio, pero se salta constantemente. Un backup del día anterior a la actualización de PHP te permite revertir en minutos si algo sale mal. Usá un plugin como UpdraftPlus o el sistema de backups de tu hosting. En DonWeb, los planes de hosting incluyen backups automáticos que podés restaurar desde el panel.

Usá un entorno de staging. Es una copia del sitio en producción donde probás las actualizaciones antes de aplicarlas en el sitio real. Si la actualización de PHP rompe algo en staging, lo resolvés ahí sin impacto para los visitantes. Muchos hostings lo ofrecen con un clic.

Verificá la compatibilidad de plugins antes de cambiar PHP. La mayoría de los plugins populares publican en su página del repositorio de WordPress.org con qué versiones de PHP fueron probados. Si el plugin dice «tested up to PHP 7.4» y vas a subir a 8.2, tomalo con pinzas. Esto se conecta con lo que analizamos en probar cambios en un entorno seguro.

Mantené WordPress, plugins y temas actualizados. La mayoría de las incompatibilidades con PHP 8.x ya están resueltas en las versiones actuales. Un sitio con plugins sin actualizar desde 2022 va a tener problemas al saltar a PHP 8.2.

Revisá los logs regularmente. No esperes a ver la pantalla blanca para saber que algo está fallando. El archivo debug.log (si lo tenés activado en modo verbose) o los logs de error del servidor suelen mostrar warnings y notices antes de que el error se vuelva fatal.

Preguntas Frecuentes

¿Por qué aparece la pantalla blanca en WordPress tras actualizar PHP?

Porque algún componente del sitio —un plugin, el tema activo, o un archivo del core— usa funciones o sintaxis que la nueva versión de PHP no acepta. PHP 8.x eliminó varias funciones que existían desde las versiones 5.x, y cualquier código que las use genera un error fatal que impide que WordPress renderice cualquier página. El resultado visible es una pantalla en blanco sin mensaje de error.

¿Cómo solucionar la pantalla blanca de WordPress rápido?

El camino más rápido es activar el modo debug en wp-config.php para ver el error exacto, luego actuar sobre él: desactivar el plugin problemático, aumentar el memory limit, o regenerar el .htaccess. En la mayoría de los casos, desactivar todos los plugins por FTP (renombrando la carpeta plugins) restaura el acceso al admin en menos de dos minutos y permite identificar el culpable.

¿Cómo activar debug mode en WordPress para ver errores?

Editá el archivo wp-config.php en la raíz de tu instalación y agregá: define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); y define( 'WP_DEBUG_DISPLAY', false );. Los errores se guardarán en /wp-content/debug.log. Recordá desactivar estas líneas (o cambiarlas a false) una vez que resolvás el problema, ya que dejarlas activas en producción puede exponer información sensible del sistema.

¿Cómo aumentar el memory limit en WordPress para resolver la pantalla blanca?

Agregá define( 'WP_MEMORY_LIMIT', '256M' ); en tu wp-config.php antes de la línea /* That's all, stop editing! */. Si el servidor tiene un límite global más bajo, ese valor no va a tener efecto y necesitás modificar también el php.ini o el .htaccess con php_value memory_limit 256M. Si ninguna opción funciona, contactá a tu proveedor para que lo ajuste en la configuración del servidor.

¿La pantalla blanca de WordPress afecta también el panel de administración?

Puede afectar solo el frontend, solo el admin, o ambos, dependiendo de dónde esté el código que falla. Si el error está en un plugin activo en todo el sitio, probablemente afecte las dos áreas. Si está en el tema activo, puede que el admin cargue pero el frontend no. Por eso el debug log es útil: el error va a indicar exactamente qué archivo y qué línea fallaron, lo que permite determinar el alcance antes de empezar a tocar cosas.

Conclusión

Actualizar PHP es una de las mejores cosas que podés hacer por la seguridad y el rendimiento de tu sitio WordPress. El problema es que hacerlo sin preparación puede dejarte con una pantalla blanca y sin acceso al panel. Eso, con la metodología correcta, dura minutos y no horas.

El flujo recomendado en 2026 es claro: backup previo, staging para probar, activar debug ante cualquier error, y actuar sobre el dato concreto del log en lugar de disparar soluciones al azar. La mayoría de las WSOD tienen una causa puntual —un plugin viejo, un memory limit insuficiente, o un .htaccess corrupto— que se resuelve en el primer o segundo intento.

Lo que conviene seguir de acá en adelante: mantener PHP en 8.2 o 8.3 (las únicas versiones con soporte activo), actualizar plugins con frecuencia, y no saltear el backup antes de cualquier cambio de versión. La pantalla blanca no es un problema difícil, pero sí es uno que se evita fácilmente con estas precauciones.

Fuentes

Volver a

Guias