Pantalla blanca en WordPress: el error sigue ahí, solo que no te lo está diciendo
No hay mensaje, no hay aviso, no hay nada. Eso no significa que no haya una causa: significa que WordPress tiene apagados los avisos. El primer trabajo es hacerla hablar.
lo que ves · GET / · HTTP 200 · body: 0 bytes
lo que hay · el mismo fallo, con la voz encendida
Qué es la pantalla blanca y por qué desespera tanto
Se le conoce como la pantalla blanca de la muerte WordPress —WSOD, para los amigos—. El nombre suena peor de lo que es.
Lo que ocurre es que el código se detuvo a media ejecución y la página se quedó sin contenido que enviar. El navegador recibe una respuesta vacía y la muestra tal cual: en blanco. Cuando tu WordPress página en blanco no da ni un mensaje, no es que no haya error: es que nadie lo está mostrando.
Es exactamente el mismo tipo de fallo que un error crítico. La diferencia es que en un error crítico WordPress alcanza a mostrarte el mensaje, y aquí no: o los avisos están desactivados, o el proceso se cortó antes de poder escribir nada.
Por qué desespera más que cualquier otra falla: no te da un hilo del que tirar. Con un error crítico al menos tienes una frase que buscar. Aquí no tienes nada, y esa ausencia es lo que hace que la gente empiece a probar cosas al azar. Ahí es donde se complica de verdad.
Lo importante: tu contenido está intacto. La base de datos no se toca por esto. Cuando tu WordPress no muestra nada, lo que falló es la ejecución, no tu información.
Cómo hacer que la pantalla blanca te diga qué pasa
Esto puedes hacerlo tú y no puede empeorar nada: lo único que hace es pedirle a WordPress que escriba lo que está callando.
Comprueba si es todo el sitio o solo una parte
Prueba el escritorio en /wp-admin/. Si el panel abre y lo público está en blanco, el culpable casi siempre es el tema o un plugin que solo actúa de cara al visitante. Si también está en blanco el panel, el problema es más de fondo. Esa sola comprobación parte el diagnóstico en dos.
Mira el registro de errores del hosting
Es la vía más rápida y no requiere tocar el sitio. En el panel de tu proveedor busca el registro de errores, o un archivo llamado error_log en la carpeta principal. Las últimas líneas suelen nombrar el archivo exacto que falló.
Pide a WordPress que escriba el registro
Si el hosting no te da el registro, se activa desde el propio WordPress. En el archivo wp-config.php, antes de la línea que dice que ahí termina la edición, va esto:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Esa combinación es importante: escribe el error en un archivo privado y no lo muestra en pantalla. Mostrarlo en público sería revelar rutas internas del servidor a cualquiera. Recarga el sitio una vez y el registro aparecerá en /wp-content/debug.log.
Copia las últimas líneas y mándanoslas
No hace falta que las entiendas. Con el nombre del archivo y el número de línea, el diagnóstico suele estar hecho.
Cuando termines, quita esas cuatro líneas o ponlas en false. Dejar el registro activo de forma permanente llena el disco y, si alguien cambia WP_DEBUG_DISPLAY a true, expone información del servidor. Si no te sientes cómodo tocando wp-config.php, no lo hagas: mándanos la dirección y lo activamos nosotros.
Lo que no conviene hacer
No desactives plugins al azar
Es el consejo que más circula y el peor de todos cuando se hace a ciegas. Desactivar y reactivar en serie puede dejar configuraciones a medias, y si aciertas por casualidad nunca sabrás por qué fallaba, así que volverá.
No cambies de tema para "ver si así carga"
Puede confirmarte que el problema es el tema, sí. También puede perderte las personalizaciones del que tenías, los widgets colocados y los ajustes del personalizador. El precio de esa prueba es demasiado alto para lo poco que te dice.
No restaures un respaldo antes de saber la causa
Si el fallo vino de un cambio en el servidor —la versión de PHP, por ejemplo— el respaldo se cae exactamente igual, y encima habrás perdido lo publicado desde esa fecha.
No muestres los errores en pantalla en un sitio público
Activar la visualización de errores de cara al visitante expone rutas del servidor y nombres de archivos. Es un regalo para quien esté buscando por dónde entrar.
No lo dejes "a ver si se arregla solo"
Esta es la única falla que no se cura con el tiempo: no es un pico de tráfico ni una incidencia del proveedor. Algo se rompió y va a seguir roto.
Qué provoca una pantalla blanca, en orden de frecuencia
Memoria agotada
La causa más frecuente de todas, y la más silenciosa: cuando el proceso se queda sin memoria se corta en seco, sin alcanzar a escribir un mensaje. Por eso la pantalla queda vacía en vez de mostrar un error. Suele aparecer en el editor, al importar, al generar informes o en páginas con muchos productos.
Error fatal de PHP con los avisos apagados
Mismo fallo que un error crítico, pero el sitio tiene la visualización desactivada. Esta es la razón por la que dos sitios con el mismo problema muestran cosas distintas.
Un plugin incompatible tras actualizar
Clásico. Si el panel sigue abriendo y solo lo público está en blanco, mira primero aquí.
El tema
Temas sin mantenimiento que dejan de llevarse con la versión de PHP del servidor. Síntoma típico: funcionaba el viernes, el lunes no, y nadie tocó nada. Porque nadie tocó el sitio; tocaron el servidor.
Código a medida en el functions.php
Un fragmento copiado de un tutorial, un cierre de etiqueta de más, una función que ya no existe. Es la causa más común cuando la pantalla blanca aparece justo después de que alguien "hizo un cambio chiquito". Si ese cambio lo hizo alguien de fuera, eso es desarrollo a medida sin entorno de pruebas.
Bucle de redirección o caché corrupta
El sitio entra en un ciclo y acaba devolviendo vacío. A veces es la caché del plugin, a veces la del servidor, a veces las dos peleándose. Cuando es eso, entra en el terreno de optimización y velocidad.
Permisos de archivos mal cambiados
Después de una migración o de un intento de "arreglo" por FTP. WordPress no puede leer lo que necesita y se detiene.
Cómo la resolvemos
Respaldamos antes de tocar
Archivos y base de datos, en el estado en que estén.
La hacemos hablar
Activamos el registro en archivo privado, nunca en pantalla. En la mayoría de los casos, el error aparece en la primera recarga.
Separamos público de administración
Saber si el panel abre o no reduce las posibilidades a la mitad antes de tocar nada.
Vamos al componente que señala el registro
Solo a ese. No desactivamos de más ni probamos en serie.
Comprobamos los límites del servidor
Memoria, tiempo máximo de ejecución, versión de PHP. Cuando la causa es memoria agotada, cambiar el plugin no sirve de nada: hay que ampliar el límite o encontrar qué lo está consumiendo.
Corregimos en copia y validamos
A producción solo pasa lo que ya funcionó en el entorno de pruebas.
Revisamos qué quedó a medias
Tareas programadas, correos, procesos interrumpidos por el corte.
Te explicamos qué pasó
Y, si la causa fue memoria o versión de PHP, te decimos qué tendría que cambiar en tu alojamiento para que no vuelva.
Qué pasa con tus datos y con tu posicionamiento
Los datos. Intactos. La pantalla blanca es un fallo de ejecución: no borra ni modifica contenido. De todas las urgencias, es junto con el error crítico la más inofensiva para tu información. El riesgo real no es la falla, es la reparación improvisada.
El posicionamiento. Aquí hay un matiz que conviene conocer, porque es la diferencia con un sitio caído: una pantalla en blanco a menudo responde como si todo estuviera bien. El servidor devuelve una página correcta que resulta estar vacía. Google la lee como una página sin contenido, no como una caída temporal.
googlebot: "vuelve luego, es temporal"
googlebot: "esta página ya no tiene nada"
Eso sí hace daño si dura. Un sitio caído con el código correcto le dice a Google "vuelve luego"; una pantalla blanca le dice "esta página ya no tiene nada". Por eso conviene no dejarla días.
Cuánto cuesta y cuánto tarda
Depende por completo de lo que diga el registro, y por eso ese es el primer paso. Un límite de memoria se ajusta en minutos. Un tema sin licencia que ya no se lleva con la versión de PHP del servidor no es una reparación: es decidir entre regularizar o sustituir, y eso es otro trabajo y otra conversación.
Esta es, de las cuatro urgencias, la única en la que el presupuesto no existe hasta que el registro habla. Mientras la pantalla siga muda, cualquier cifra es inventada, incluida la nuestra.
Por eso el primer paso no se cobra como reparación: se cobra como diagnóstico, y se descuenta entero de lo que contrates después. Antes de eso, mirar tu sitio desde fuera no te cuesta nada. Y una vez que sabemos qué dice el registro, la ejecución se cotiza con alcance cerrado y antes de tocar nada.
Lo que evita que vuelva
La primera es tener un entorno de pruebas. Casi todas las pantallas blancas que atendemos aparecieron tras un cambio que nadie probó en otro lado primero.
La segunda es saber en qué versión de PHP corre tu sitio y qué pasa el día que el hosting la actualice. Ese cambio no lo decides tú y suele llegar sin aviso claro. Quien lo tiene vigilado lo vive como un correo; quien no, como una pantalla en blanco un lunes por la mañana. Las dos cosas viven dentro de un plan de mantenimiento y administración serio.
Preguntas rápidas
Es una pista excelente: significa que el fallo está en algo que solo se ejecuta en cierto tipo de contenido, casi siempre una plantilla concreta del tema o un plugin que actúa en productos, entradas o un formulario. Dinos qué páginas sí y cuáles no, y eso acota el diagnóstico enormemente.
Que el problema está casi seguro en el tema o en un plugin que solo actúa de cara al visitante. Es la mejor noticia posible: acota mucho y se resuelve más rápido.
Suele significar que el proceso se corta antes de poder escribir, y eso apunta a memoria agotada o a un límite del servidor. Es un dato útil, no un callejón sin salida.
Es el mismo tipo de fallo con los avisos apagados. Por eso lo primero que hacemos es encenderlos.
Entonces ya sabemos dónde mirar. Si tienes la versión anterior del archivo, guárdala y mándanosla.
Casi nunca, pero vale la pena descartarlo en veinte segundos: ábrelo en una ventana de incógnito o desde el teléfono con datos móviles. Si ahí sí carga, no tienes una pantalla blanca, tienes una caché local y se resuelve limpiándola. Si sigue en blanco, el problema es del sitio.
Mándanos la dirección de tu sitio
Y dinos una sola cosa: si el escritorio en /wp-admin/ abre o también está en blanco. Con ese dato empezamos con la mitad del diagnóstico hecho.