«Se ha producido un error crítico en tu sitio web». Es uno de los mensajes menos tranquilizadores que puede mostrar WordPress, especialmente cuando aparece justo después de actualizar un plugin, cambiar de tema o modificar algunas líneas de código.
La buena noticia es que error crítico de WordPress no significa automáticamente que hayas perdido el sitio, que la base de datos esté destruida o que tengas que empezar de cero. Significa que, durante la ejecución, WordPress ha encontrado un error PHP lo bastante grave como para impedirle completar normalmente la solicitud. El mensaje que ves es, por tanto, el síntoma; el verdadero trabajo consiste en identificar la causa.
Desde WordPress 5.2 existe además una función integrada, el Recovery Mode, diseñada precisamente para ayudar al administrador cuando un plugin, un tema o código personalizado provoca un error fatal. Antes de desactivar todo al azar, conviene averiguar qué sabe ya WordPress del problema.
Qué significa realmente «error crítico» en WordPress
WordPress está escrito principalmente en PHP y, para generar una página, ejecuta el núcleo junto con el tema activo, los plugins y cualquier código personalizado. Si uno de estos componentes genera un error fatal, la ejecución puede interrumpirse.
WordPress detecta determinados errores fatales y, en lugar de mostrar al visitante detalles técnicos potencialmente incomprensibles o sensibles, puede presentar el mensaje que indica un error crítico. La documentación oficial sobre Recovery Mode explica que esta función se introdujo con WordPress 5.2 precisamente para gestionar situaciones en las que un error PHP fatal impide el funcionamiento normal del sitio.
Este detalle cambia la forma de abordar el problema. El mensaje no te dice qué componente está averiado. Te dice que WordPress no ha podido completar correctamente la ejecución. El diagnóstico viene después.
Error crítico de WordPress: las causas más comunes
La documentación de WordPress sobre errores comunes señala entre las posibles causas los conflictos entre plugins, las incompatibilidades con el tema, una versión de PHP incompatible, el agotamiento del límite de memoria y los archivos de WordPress dañados. A estas situaciones se suma, naturalmente, el código personalizado: una modificación incorrecta de un plugin propio, un fragmento de código o un archivo PHP puede bastar para detener la ejecución.
Esto no significa que todos los errores críticos pertenezcan a una de estas categorías, pero son puntos de partida razonables. Más importante aún es el contexto temporal.
Si el sitio funcionaba hace cinco minutos y el error apareció inmediatamente después de actualizar un plugin, ese plugin merece atención antes que cualquier teoría extravagante. Si acabas de modificar functions.php y el sitio dejó de funcionar al guardar, el primer sospechoso no es la base de datos. Parece obvio, pero un diagnóstico ordenado empieza por lo que ha cambiado.
Lo primero: revisa el correo electrónico del administrador
Cuando WordPress activa Recovery Mode tras un error fatal durante la carga normal de una página, puede enviar un correo electrónico a la dirección del administrador del sitio. El mensaje contiene información sobre el problema y un enlace especial para acceder al sitio en modo de recuperación.
Ese correo es valioso porque puede indicar el plugin o el tema implicado. En lugar de empezar desactivando veinte plugins, quizá ya tengas una pista concreta.
Revisa, por tanto, el buzón asociado al administrador de WordPress, incluida la carpeta de spam. La ausencia del mensaje no demuestra que Recovery Mode no haya intentado intervenir: la documentación oficial advierte que, en algunas configuraciones, el correo podría no entregarse correctamente.
Cómo funciona Recovery Mode de WordPress
Recovery Mode no es una segunda instalación de WordPress ni «repara» automáticamente el componente defectuoso. Crea una sesión especial para el administrador en la que el plugin o tema que ha provocado el error puede quedar en pausa durante esa sesión, permitiendo acceder al panel de administración.
Una vez que entras mediante el enlace recibido por correo, WordPress muestra avisos que ayudan a identificar la extensión problemática. Puedes desactivarla, corregir el código o intervenir en la configuración y, al terminar, salir de Recovery Mode.
Es un mecanismo inteligente porque evita una solución drástica: apagar todo el sitio solo para poder acceder a la administración.
Pero no lo confundas con la modo de mantenimiento de WordPress. El modo de mantenimiento se utiliza normalmente durante las actualizaciones para impedir el acceso mientras se sustituyen los archivos; Recovery Mode interviene, en cambio, ante determinados errores fatales. Dos pantallas desagradables, dos problemas completamente distintos.
Si no llega el correo de recuperación
Si no has recibido el enlace o el error sigue impidiendo el acceso, debes pasar a un diagnóstico manual. La regla sigue siendo la misma: recopilar información antes de modificar el sitio a ciegas.
La primera herramienta útil es el registro de errores. WordPress dispone de las constantes WP_DEBUG, WP_DEBUG_LOG e WP_DEBUG_DISPLAY. La documentación oficial sobre depuración explica cómo utilizarlas y recomienda comprobar, antes de cualquier modificación, que dispones de un entorno de staging o de una copia de seguridad adecuada.
Una configuración habitual para registrar los errores sin mostrárselos a los visitantes es:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Con WP_DEBUG_LOG configurado como true, el registro suele escribirse en wp-content/debug.log. Aquí puedes buscar el error fatal y, sobre todo, la ruta del archivo implicado. Si la ruta apunta claramente a una carpeta dentro de wp-content/plugins/nome-plugin/, tienes una pista mucho más concreta que «quizá sea un plugin».
No conviene dejar la depuración activada por costumbre en el sitio en producción
Activar la depuración para diagnosticar un problema es una cosa; convertirla en una configuración permanente en un sitio público es otra. La documentación de WordPress especifica que las herramientas de depuración están pensadas principalmente para entornos locales y de staging y desaconseja su uso continuo en sitios en producción.
También hay una cuestión de seguridad. Los registros pueden contener rutas del servidor, detalles técnicos y otra información que no conviene hacer pública. WordPress advierte expresamente del riesgo de guardar archivos de registro en ubicaciones accesibles desde la web.
Por tanto: activa lo necesario, recopila la información, resuelve el problema y restablece una configuración adecuada para producción. La depuración es un estetoscopio, no un accesorio que debas dejar colgado del sitio.
Si el problema es un plugin y no puedes acceder a WordPress
Si el registro o el correo señalan un plugin concreto, pero el panel sigue inaccesible, puedes desactivarlo desde los archivos. WordPress documenta un procedimiento sencillo: mediante FTP/SFTP o el administrador de archivos del hosting, cambia temporalmente el nombre de la carpeta del plugin afectado dentro de wp-content/plugins.
Por ejemplo, si el componente problemático estuviera en la carpeta mio-plugin, cambiarle temporalmente el nombre impediría que WordPress lo cargara normalmente. Después puedes comprobar si el sitio vuelve a estar accesible.
Si no sabes qué plugin es responsable, también puedes desactivar todos los plugins cambiando el nombre del directorio plugins, una técnica recogida en la documentación sobre errores comunes. Sin embargo, es una medida mucho más invasiva y no debería ser el primer paso cuando ya tienes información para aislar al responsable.
En una tienda online o un sitio con funciones críticas, desactivar todo indiscriminadamente puede tener consecuencias evidentes. Mejor un bisturí cuando ya has localizado el punto, no una motosierra.
¿Y si el responsable es el tema?
Un tema también puede provocar un error fatal, especialmente después de modificar código, actualizarlo o cambiar la versión de PHP. Si el problema comenzó justo después de activar o modificar un tema, la relación temporal vuelve a ser importante.
La documentación de WordPress sobre errores comunes sugiere, cuando sea posible, cambiar a un tema predeterminado. Si no tienes acceso al panel, puede ser necesaria una intervención en el sistema de archivos.
Sin embargo, antes de cambiar nombres de carpetas o intervenir manualmente, asegúrate de que el sitio tenga instalado un tema alternativo funcional y de que sepas qué resultado esperar. Hacer cambios al azar mientras el sitio ya presenta errores dificulta descubrir qué ha solucionado realmente el problema.
Versión de PHP, memoria y compatibilidad
No todos los errores críticos se deben a un componente simplemente «roto». Un plugin puede funcionar durante meses y empezar a generar un error fatal tras un cambio de entorno. Una actualización de PHP, por ejemplo, puede dejar al descubierto código incompatible. Del mismo modo, agotar la memoria disponible puede interrumpir la ejecución.
El registro sirve precisamente para distinguir estos casos. Un mensaje sobre una función inexistente, un error de tipo, un problema de sintaxis y un aviso de memoria agotada cuentan historias distintas. Limitarse a leer «critical error» en la parte pública del sitio elimina justo la información necesaria para elegir la solución.
Si el problema aparece después de cambiar la versión de PHP desde el panel del hosting, comprueba los requisitos de los componentes utilizados y las indicaciones del proveedor. No cambies repetidamente de versión esperando que alguna funcione: identifica primero la incompatibilidad.
Una actualización ha provocado el error crítico: ¿qué hacer?
Si el error aparece inmediatamente después de una actualización, no significa necesariamente que haya que volver a una versión anterior de WordPress. Debes averiguar qué componente ha fallado y por qué.
Revisa el correo de Recovery Mode, el registro y el estado del componente actualizado. Si la actualización se interrumpió, comprueba también que los archivos estén completos. Si, en cambio, la nueva versión introduce una incompatibilidad con otro plugin o con tu entorno, restaurar temporalmente una copia funcional puede ser más prudente que modificar el sitio en producción bajo presión.
Aquí resulta útil contar con una estrategia de copias de seguridad seria. Nuestra guía de copias de seguridad de WordPress explica por qué una copia solo es útil si contiene lo necesario y puede restaurarse de verdad.
Para las actualizaciones importantes, probar primero en staging reduce aún más el riesgo: un error crítico es mucho menos crítico cuando aparece en una copia que ningún cliente está utilizando.
No restaures una copia de seguridad como primera reacción
Tener una copia de seguridad no significa que sea el primer botón que debas pulsar. Si el problema es un único plugin recién actualizado y Recovery Mode permite identificarlo y desactivarlo en pocos minutos, una restauración completa podría ser desproporcionada.
Además, en sitios dinámicos, una restauración puede hacer retroceder también los datos modificados después de crear la copia: pedidos, usuarios, comentarios, contenidos u otra información, según lo que se restaure.
La copia de seguridad es una red de protección. Antes de utilizarla, debes saber desde qué altura estás cayendo.
Qué comprobar después de resolver el error
Que la página de inicio vuelva a mostrarse no significa que el trabajo haya terminado. Si has desactivado un plugin, comprueba qué funciones proporcionaba. Si has corregido un fragmento de código, revisa las páginas que lo utilizaban. Si has cambiado PHP, comprueba las áreas más importantes del sitio.
En una tienda online, esto implica comprobar al menos la navegación, la cuenta, el carrito y el pago. En un sitio con formularios, envía uno de prueba. En un sitio de membresía, verifica el acceso y los contenidos protegidos. Las comprobaciones deben centrarse en lo que se ha modificado.
Por último, desactiva los ajustes temporales de depuración que no deban permanecer activos y conserva la información sobre la causa. Saber que «el sitio vuelve a funcionar» es útil; saber por qué dejó de funcionar evita repetir la misma situación en la próxima actualización.
Un procedimiento sencillo para no empeorar la situación
Ante un error crítico de WordPress, el orden de las operaciones importa más que la velocidad a la que puedas hacer clic.
- Recuerda qué cambió inmediatamente antes del error.
- Revisa el correo del administrador para encontrar el mensaje de Recovery Mode.
- Si está disponible, entra mediante el enlace de recuperación e identifica el componente señalado.
- Si no es suficiente, consulta los registros o activa temporalmente el registro de errores siguiendo la documentación de WordPress.
- Intervén sobre el componente realmente afectado y evita desactivaciones al azar.
- Si es necesario, utiliza una copia de seguridad verificada para volver a un estado funcional.
- Después de restaurar el sitio, prueba las funciones relacionadas con el problema y elimina las configuraciones temporales de depuración.
Es una secuencia menos espectacular que «desactívalo todo y veamos», pero proporciona algo mucho más útil: un diagnóstico.
El error crítico es un mensaje genérico, no una sentencia
La pantalla de error crítico es deliberadamente genérica. Protege al visitante de los detalles técnicos y te avisa de que WordPress no ha podido completar la ejecución. Para resolver el problema debes pasar del mensaje visible a la información de diagnóstico.
Recovery Mode, el correo del administrador y los registros son las primeras herramientas que debes utilizar. Plugins, tema, código personalizado, compatibilidad con PHP, memoria y archivos dañados son causas posibles, no veredictos que debas elegir al azar.
La diferencia entre una intervención ordenada y media hora de pánico suele estar aquí: primero identifica qué ha fallado y después modifica lo necesario. WordPress ya te proporciona buena parte de las herramientas necesarias para hacerlo.
El equipo de The Waffle