Cómo solucionar el error crítico de WordPress

Es el mensaje con el que las versiones modernas de WordPress avisan que algo en el código del sitio falló de una manera tan grave que no puede terminar de cargar la página. Vino a reemplazar a la antigua pantalla blanca de la muerte, que era simplemente una página en blanco sin ninguna explicación, por un mensaje más informativo que además dispara un aviso automático por correo al administrador. Aunque el nombre suene alarmante, en la enorme mayoría de los casos no significa que el sitio esté perdido ni que los datos se hayan borrado: el contenido sigue intacto en la base de datos, y lo que ocurre es que algún componente impide que la página se muestre. Las causas más frecuentes son un plugin —recién actualizado, mal programado o incompatible—, el tema, un conflicto entre dos plugins, o la falta de memoria disponible para PHP. Identificar cuál de estas es la responsable constituye casi todo el trabajo de solución, y existe un método ordenado para hacerlo sin tocar cosas al azar.

De lejos, la causa más común es un plugin o el tema. Dentro de esa categoría, el escenario típico es una actualización reciente de un plugin o del tema que introdujo una incompatibilidad o un fallo, seguido por plugins mal programados, plugins incompatibles con la versión actual de WordPress o de PHP, y conflictos que surgen cuando dos plugins intentan hacer cosas que chocan entre sí. La segunda causa más habitual, ya fuera de los plugins, es la falta de memoria asignada a PHP: cuando el sitio necesita más memoria de la que el servidor le permite usar, la ejecución se corta y aparece el error. Menos frecuentes son los problemas en archivos del propio núcleo de WordPress, que normalmente no hay que tocar. La buena noticia de que la causa casi siempre sea un plugin o el tema es que el diagnóstico es sistemático: desactivando plugins y probando con un tema por defecto se acorrala al responsable en pocos pasos, sin necesidad de conocimientos avanzados de programación.

Es una funcionalidad de las versiones modernas de WordPress pensada justamente para poder solucionar el error crítico sin quedar bloqueado fuera del sitio. Cuando ocurre un error crítico, WordPress envía automáticamente un correo a la dirección del administrador, y ese correo suele indicar qué plugin o componente provocó el fallo y ofrece un enlace especial. Al abrir ese enlace, se accede al panel de administración en un modo seguro llamado modo de recuperación, en el que el componente problemático aparece desactivado, de manera que el panel carga aunque el sitio público estuviera caído. Desde ahí se puede desactivar definitivamente el plugin o el tema que causaba el problema, actualizarlo, o tomar la medida que corresponda, y luego el sitio vuelve a funcionar con normalidad. Es la vía más rápida y cómoda para resolver el error cuando el correo llega correctamente y se puede acceder al enlace, y resuelve la mayoría de los casos sin necesidad de tocar ningún archivo por FTP ni recurrir a métodos más manuales.

Cuando no llega el correo de recuperación o no se puede acceder al panel ni siquiera en modo seguro, se recurre al diagnóstico manual a través de FTP o del gestor de archivos que ofrece el panel del hosting, aplicando una técnica de aislamiento. El primer paso es entrar a los archivos del sitio y renombrar la carpeta que contiene los plugins, habitualmente ubicada dentro de wp-content, por ejemplo cambiándole el nombre a plugins-off; esto desactiva todos los plugins de una sola vez. Luego se recarga el sitio: si vuelve a funcionar, queda confirmado que el problema estaba en un plugin. A continuación se devuelve el nombre original a la carpeta y, desde el panel que ya vuelve a estar accesible, se reactivan los plugins de a uno, recargando el sitio después de cada activación, hasta que al activar uno reaparece el error, momento en el que se identifica al culpable. Si desactivar los plugins no soluciona nada, se repite la misma lógica con el tema, cambiando temporalmente a un tema por defecto de WordPress. Es exactamente el método de dividir y probar que se usa en cualquier depuración.

Por el error crítico en sí, normalmente no. El contenido del sitio —las entradas, las páginas, los comentarios, la configuración— vive en la base de datos, y un error crítico casi siempre es un problema de ejecución del código, provocado por un plugin, el tema o la falta de memoria, que impide mostrar la página pero no borra ni corrompe esos datos. Por eso, en la gran mayoría de los casos, una vez identificado y desactivado el componente que causaba el fallo, el sitio vuelve a aparecer con todo su contenido intacto. El riesgo real de pérdida no viene tanto del error como de las acciones apresuradas que a veces se toman durante el pánico, como editar archivos del núcleo sin saber, borrar cosas al azar o hacer cambios masivos sin registro. Precisamente por eso la recomendación transversal es contar siempre con backups automáticos: no porque el error crítico borre datos, sino porque tener una copia reciente permite restaurar el sitio de inmediato si el diagnóstico se complica o si, al intentar arreglar, se comete un error mayor. El backup convierte cualquier problema en algo reversible.

Con unas pocas prácticas de mantenimiento que atacan sus causas más frecuentes. La primera y más importante es actualizar con cuidado, ya que la causa número uno del error es una actualización de un plugin o del tema que rompió algo: conviene actualizar de a poco en lugar de todo a la vez y, en sitios importantes, probar primero las actualizaciones en un entorno de pruebas separado antes de aplicarlas en producción. La segunda es reducir la cantidad de plugins al mínimo necesario y usar solo los que provengan de fuentes confiables y estén bien mantenidos, porque cada plugin es una fuente potencial de conflictos y de fallos. La tercera es mantener actualizadas tanto la versión de WordPress como la de PHP, dado que las incompatibilidades entre versiones son otra causa habitual. Y la cuarta, transversal, es tener backups automáticos configurados, que actúan como red de seguridad definitiva: si a pesar de todo algo sale mal, restaurar una copia reciente devuelve el sitio a funcionamiento en minutos. Estas medidas combinadas reducen drásticamente la probabilidad de encontrarse otra vez con la pantalla del error crítico.