Estás trabajando con normalidad en tu web, actualizas un plugin, cambias una configuración o simplemente intentas entrar al día siguiente y WordPress muestra un mensaje inquietante:
«Ha habido un error crítico en esta web.»
A veces desaparece toda la web. Otras veces la parte pública continúa funcionando, pero no puedes entrar en wp-admin. Y en otros casos el problema aparece únicamente al visitar una página o realizar una acción determinada.
Lo primero que conviene saber es que el mensaje de error crítico no explica cuál es el problema. Es la consecuencia visible de un error que WordPress no ha podido gestionar con normalidad.
Puede estar relacionado con un plugin, un tema, código personalizado, PHP u otros componentes de la instalación. Por eso empezar a desactivar, borrar, restaurar o modificar cosas sin saber qué ha ocurrido puede complicar una incidencia que inicialmente era relativamente sencilla.
La prioridad debería ser otra: recopilar información, proteger lo que todavía funciona y localizar el origen del error antes de intentar solucionarlo.
WordPress dispone de un sistema para gestionar determinados errores fatales de PHP.
Cuando detecta uno durante la carga normal de una página, puede impedir que el fallo se muestre directamente al visitante y presentar en su lugar el mensaje genérico de error crítico.
Además, WordPress incorpora desde la versión 5.2 un modo de recuperación (Recovery Mode) diseñado para facilitar el acceso al administrador cuando un error fatal está relacionado, por ejemplo, con un plugin, un tema o código personalizado.
WordPress explica aquí cómo funciona Recovery Mode.
Esto introduce una distinción importante:
El error crítico es un síntoma. No es el diagnóstico.
Ver ese mensaje no permite afirmar automáticamente que:
Cualquiera de esas posibilidades necesita evidencias.
Antes de tocar nada, intenta reconstruir los últimos cambios realizados.
Por ejemplo:
El momento en el que apareció el problema puede aportar una pista muy valiosa.
Si acabas de actualizar un plugin y segundos después aparece un error fatal relacionado precisamente con los archivos de ese plugin, existe una línea de investigación bastante clara.
Pero evita convertir una coincidencia temporal en un diagnóstico.
Que el error aparezca después de una actualización no demuestra por sí solo que la actualización sea la causa.
Si vas a realizar cambios importantes en el futuro, precisamente por este tipo de situaciones merece la pena seguir un procedimiento para actualizar WordPress sin romper la web.
El siguiente paso no requiere conocimientos técnicos.
Comprueba qué continúa funcionando.
Es el escenario más evidente: los visitantes encuentran el error y tú tampoco puedes acceder al administrador.
En ese caso necesitarás una vía alternativa de diagnóstico: el modo de recuperación, los registros de errores, el panel del hosting o, si sabes trabajar con ellos, acceso a los archivos del servidor.
Es una situación diferente.
No des por hecho que, porque la portada cargue, la incidencia carece de importancia.
Comprueba también páginas importantes y, si se trata de una web empresarial, funciones críticas como:
Puede existir un error que afecte solo a una parte de WordPress.
También puede ocurrir que el error aparezca únicamente al editar una página, ejecutar una función determinada o acceder a una zona concreta.
Anota exactamente qué acción provoca el error.
Cuanto mejor puedas reproducir una incidencia, más fácil será investigarla.
Este paso se olvida con frecuencia.
Cuando WordPress detecta determinados errores fatales, puede enviar un mensaje a la dirección de correo electrónico del administrador con información sobre el problema y un enlace especial para acceder mediante Recovery Mode.
WordPress explica que, durante esa sesión de recuperación, el plugin o tema problemático puede quedar pausado para ese administrador, permitiendo acceder al panel e investigar el componente implicado.
Por tanto, comprueba:
No necesitas empezar borrando plugins si WordPress ya te está proporcionando información sobre el error.
Si no sabes qué dirección de correo está configurada como administrador o ya no tienes acceso a ella, eso introduce otro problema que habrá que resolver.
Entrar en modo de recuperación no significa que la web esté reparada.
Significa que WordPress ha conseguido proporcionarte un entorno desde el que investigar.
La documentación oficial recomienda revisar los avisos que identifican el componente problemático y, cuando corresponda, desactivar temporalmente el plugin o tema implicado o corregir el código que ha provocado el fallo.
Antes de realizar cambios, guarda la información disponible:
Esa información puede ser mucho más útil para solucionar el problema que una captura que muestre únicamente «Ha habido un error crítico».
Después de aplicar una corrección hay que salir del modo de recuperación y comprobar que la web funciona realmente con normalidad.
«Desactiva todos los plugins» es una recomendación habitual cuando WordPress falla.
Puede formar parte de un proceso de diagnóstico, pero no debería convertirse automáticamente en el primer paso en una web empresarial en producción.
Un plugin puede encargarse de:
Desactivar componentes indiscriminadamente puede cambiar el comportamiento de la web y añadir nuevos síntomas al problema original.
Si dispones de información que apunta a un componente concreto, empieza investigando esa evidencia.
Y si necesitas realizar pruebas extensas, un entorno de staging suele ser mucho más apropiado que experimentar sobre la web pública.
En nuestra guía sobre qué puedes tocar tú mismo en WordPress y qué conviene delegar explicamos precisamente dónde empieza a aumentar el riesgo de realizar cambios directamente en producción.
«Ha habido un error crítico» contiene muy poca información.
El error registrado en el servidor puede contener mucha más.
Dependiendo de cómo esté configurado el alojamiento, puedes disponer de registros de PHP o herramientas del propio hosting para consultar errores recientes.
WordPress también incorpora herramientas específicas de depuración. Entre ellas se encuentran WP_DEBUG, WP_DEBUG_LOG y WP_DEBUG_DISPLAY.
La documentación para desarrolladores de WordPress explica cómo funciona su sistema de debugging.
Pero hay una precaución importante.
No es recomendable activar indiscriminadamente herramientas de depuración en una web pública.
La propia documentación de WordPress señala que estas herramientas están pensadas principalmente para entornos de desarrollo y staging. Los registros pueden contener información sensible y no deberían quedar expuestos públicamente.
Si no sabes editar wp-config.php, trabajar con registros o proteger correctamente esa información, es preferible utilizar las herramientas proporcionadas por el hosting o pedir ayuda técnica.
El objetivo no es «activar debug».
El objetivo es averiguar qué error se está produciendo sin crear un problema adicional.
Sí.
Los plugins pueden provocar errores por incompatibilidades, código defectuoso, dependencias, cambios de PHP, conflictos con otros componentes o problemas surgidos después de una actualización.
Pero «seguro que es un plugin» sigue sin ser un diagnóstico.
Si el registro señala repetidamente un archivo perteneciente a un plugin y el error empezó después de modificarlo o actualizarlo, ya dispones de indicios mucho mejores.
En ese momento puede tener sentido:
Si la web acumula extensiones antiguas, abandonadas o cuya función nadie conoce, la incidencia puede revelar además un problema de mantenimiento más amplio.
En Mantenimiento WordPress en 2026: qué debería incluir realmente explicamos por qué mantener una instalación no consiste simplemente en pulsar «actualizar todo».
También.
Un tema puede contener código PHP que provoque un error fatal, especialmente después de cambios, actualizaciones, modificaciones personalizadas o incompatibilidades con otros componentes.
De nuevo, hay que buscar evidencias.
Si el error señala archivos pertenecientes al tema activo, el tema pasa a ser un sospechoso razonable.
Eso no significa que debas cambiar inmediatamente el tema de producción y esperar a ver qué ocurre.
En una web muy personalizada, cambiar de tema puede alterar radicalmente su apariencia y algunas funcionalidades.
Sí, pero conviene precisar qué significa.
PHP es el lenguaje sobre el que funciona buena parte de WordPress. Una incompatibilidad entre la versión de PHP utilizada por el servidor y determinado código de un plugin, tema o personalización puede provocar errores.
Esto puede aparecer, por ejemplo, después de que el alojamiento cambie la versión de PHP o al utilizar componentes antiguos que no funcionan correctamente con una versión más reciente.
Pero el mensaje genérico de WordPress tampoco demuestra por sí mismo que «PHP sea el problema».
Los registros vuelven a ser la pieza importante para identificar qué está fallando.
No necesariamente.
Un error crítico puede producirse en una instalación que no haya sufrido ningún ataque.
Por eso no deberías concluir que tienes malware únicamente porque WordPress muestra este mensaje.
La situación cambia si aparecen además otras señales:
En ese caso ya no estaríamos únicamente ante un problema de disponibilidad. Habría que investigar también un posible incidente de seguridad.
Y la solución no consiste simplemente en conseguir que desaparezca el mensaje de error.
Depende.
Una restauración puede ser una excelente herramienta de recuperación, pero no debería utilizarse automáticamente cada vez que aparece un error crítico.
Imagina una tienda online.
El último backup es de las 02:00 y restauras la web a las 17:00.
¿Qué ocurre con los pedidos, usuarios, cambios de stock y otros datos generados durante esas quince horas?
O imagina que la causa del problema ya estaba presente cuando se creó la copia.
Restaurarla podría devolver también el problema.
Antes de restaurar deberías saber, como mínimo:
En Copias de seguridad en WordPress: la diferencia entre creer que las tienes y saber que funcionan explicamos cómo evaluar precisamente estas cuestiones.
Una restauración sobrescribe información. Si tu web recibe pedidos, reservas, formularios o cambios frecuentes, no restaures producción a una fecha anterior sin evaluar primero qué datos perderías.
Cuando wp-admin tampoco funciona, el diagnóstico se vuelve más técnico, pero eso no significa que la web sea irrecuperable.
Las vías habituales pasan por:
La documentación de WordPress explica que un plugin también puede desactivarse temporalmente cambiando el nombre de su directorio mediante FTP o un administrador de archivos.
Eso puede ser útil cuando ya tienes motivos para sospechar de ese plugin.
Pero aquí conviene marcar una frontera.
Si nunca has trabajado con los archivos de WordPress, no sabes cuál es el directorio correcto o no tienes una copia recuperable, una web empresarial caída no es el mejor sitio para aprender mediante prueba y error.
Hay varias reacciones comprensibles que pueden dificultar posteriormente el diagnóstico.
Estás modificando muchas variables a la vez.
Aunque la web vuelva a funcionar, puede resultar difícil saber qué solucionó el problema.
Y también puedes introducir incompatibilidades adicionales.
Desactivar y borrar son acciones diferentes.
Eliminar un plugin puede afectar a archivos o configuraciones y dificulta volver exactamente al estado anterior.
Puede implicar pérdida de información posterior al backup.
Primero determina qué estás restaurando y qué datos desaparecerán.
Probar versiones de PHP al azar puede alterar el comportamiento de otros componentes de la instalación.
Los mensajes de depuración pueden revelar rutas del servidor y otra información que no necesitas enseñar a los visitantes.
Después será difícil determinar cuál era la causa y cuál de tus cambios produjo un síntoma nuevo.
Ante un error crítico, el orden importa.
¿Está caída toda la web, solo wp-admin o una función determinada?
Anota la hora, los últimos cambios realizados y las acciones que reproducen el fallo.
Busca el mensaje de WordPress relacionado con Recovery Mode.
Consulta los avisos del modo de recuperación o los registros disponibles.
Antes de empezar a modificar producción, comprueba qué copias existen y si puedes crear una copia adicional del estado actual.
Esto puede parecer extraño cuando la web ya está rota, pero conservar ese estado puede ser útil para diagnosticar y para recuperar información que una restauración antigua no contenga.
Plugin, tema, código personalizado, PHP u otra causa.
Pero intenta respaldarla con el mensaje de error y el contexto.
Si intervienes, modifica una variable y comprueba el resultado.
Que vuelva la portada no significa necesariamente que el problema esté resuelto.
Prueba las funciones importantes para el negocio.
Una web que vuelve a cargar no siempre es una incidencia terminada.
Conviene responder a tres preguntas.
No te quedes en «desactivamos el plugin y funcionó».
¿Por qué falló?
¿Estaba desactualizado? ¿Existía una incompatibilidad? ¿Hubo un cambio de PHP? ¿Había código personalizado? ¿El problema apareció tras una actualización?
Si simplemente has revertido un componente sin solucionar la causa, el problema puede reaparecer en la siguiente actualización.
Una incidencia suele revelar debilidades que permanecían ocultas:
Ahí es donde el error deja de ser un incidente aislado y se convierte en una señal sobre el estado general del mantenimiento.
No existe una forma realista de garantizar que una web nunca vaya a fallar.
Sí podemos conseguir que los fallos sean menos probables y, sobre todo, más fáciles de recuperar.
Para una web empresarial conviene disponer de:
Si las actualizaciones son precisamente lo que te preocupa, puedes revisar nuestra guía sobre actualizaciones de WordPress para empresas, donde explicamos cómo preparar una instalación para reducir el riesgo antes de introducir cambios.
No todos los errores críticos necesitan una intervención compleja.
Si Recovery Mode identifica claramente un plugin recién instalado, existe una copia reciente y sabes cómo volver al estado anterior, la solución puede ser relativamente sencilla.
En cambio, conviene evitar seguir experimentando cuando:
En esos casos, preservar los datos y diagnosticar correctamente suele ser más importante que intentar recuperar la web lo antes posible mediante cambios al azar.
Cuando WordPress dice que ha habido un error crítico, la reacción natural es intentar hacer desaparecer esa pantalla cuanto antes.
Pero esa pantalla es solamente la parte visible.
La pregunta útil es: ¿Qué error se ha producido y qué evidencia tenemos sobre su causa?
Empieza comprobando el alcance de la incidencia. Revisa el correo del administrador y Recovery Mode. Conserva los mensajes de error. Comprueba tus backups antes de modificar o restaurar nada. Y realiza cambios controlados que permitan saber qué está ocurriendo.
Si la web es importante para el negocio y no puedes identificar con claridad el origen del fallo, detener las pruebas también es una decisión técnica razonable.
Una reparación bien hecha no consiste únicamente en conseguir que WordPress vuelva a cargar.
Consiste en averiguar por qué dejó de hacerlo, recuperar el servicio sin perder información y reducir las posibilidades de que la misma incidencia vuelva a sorprenderte.
