«Ha habido un error crítico en esta web»: cómo arreglarlo en WordPress

Respuesta corta: «Ha habido un error crítico en esta web» es la forma que tiene WordPress de decirte que un error fatal de PHP ha parado la carga de la página. Casi siempre lo provoca un plugin, el tema o un cambio de versión de PHP. Busca el correo de «modo de recuperación» que WordPress envía al administrador o activa el registro de errores en wp-config.php para ver el fichero culpable, y desactívalo.

Qué significa «Ha habido un error crítico en esta web»

Desde WordPress 5.2 existe una protección contra errores fatales. Antes, cuando un plugin rompía PHP, la web se quedaba en blanco o enseñaba el error en bruto. Ahora WordPress captura ese error al final de la ejecución y muestra un mensaje genérico:

• En español: «Ha habido un error crítico en esta web. Por favor, revisa la bandeja de entrada del correo electrónico de administración de tu sitio para ver las instrucciones.»
• En inglés: «There has been a critical error on this website.»

El mensaje no dice qué ha fallado, y es a propósito: enseñar rutas de ficheros y nombres de funciones a cualquier visitante da pistas a un atacante. La información útil está en otros dos sitios: el correo de recuperación y el registro de errores.

Las causas más habituales, por orden de frecuencia en lo que vemos:

1. Una actualización de plugin que no es compatible con otro plugin, con el tema o con tu versión de PHP.
2. Un cambio de versión de PHP en el hosting (por ejemplo de 7.4 a 8.1 o superior): funciones obsoletas que ahora provocan error fatal.
3. Código pegado en el functions.php del tema o en un plugin de fragmentos.
4. Memoria de PHP agotada («Allowed memory size of … bytes exhausted»).
5. Una actualización a medias que dejó ficheros incompletos.

Cómo saber si te pasa

Parece obvio, pero hay matices:

• El mensaje puede salir solo en algunas páginas. Si el error está en el código de WooCommerce, quizá falle la ficha de producto y la portada siga bien.
• Puede salir solo en el escritorio (/wp-admin/) o solo en la parte pública.
• Si tienes caché de página o CDN, puede que tú veas la versión vieja y tus clientes el error, o al revés. Prueba en una ventana privada y añadiendo ?nocache=1 a la URL.

Comprueba también el código HTTP. Con el error crítico WordPress responde normalmente con un 500:

curl -sI https://tuweb.com/ | head -n 1

Paso 1: busca el correo de modo de recuperación

Cuando ocurre el error, WordPress manda un correo a la dirección de administración (Ajustes > Generales) con el asunto «Tu sitio está experimentando un problema técnico». Dentro vienen dos cosas valiosas:

• El plugin o tema donde falló y el fichero y la línea del error.
• Un enlace para entrar en el modo de recuperación. En ese modo, solo para ti, WordPress pausa el plugin o tema culpable y te deja entrar al escritorio.

Si el correo llega:

1. Abre el enlace. Caduca a las 24 horas, y WordPress no manda otro correo de recuperación hasta que pasa un día.
2. Entra con tu usuario.
3. En Plugins verás el culpable marcado como pausado. Desactívalo o actualízalo.
4. Sal del modo de recuperación con el botón de la barra superior y comprueba la web en una ventana privada.

Si el correo no llega (es muy común: el hosting no envía bien, la dirección de administración es de alguien que ya no está, acaba en spam), pasa al paso 2.

Paso 2: activa el registro de errores en wp-config.php

Conéctate por FTP/SFTP, por SSH o con el gestor de archivos del panel (cPanel, Plesk) y edita wp-config.php, en la raíz de WordPress (tienes todas las opciones en la documentación oficial de depuración de WordPress). Busca la línea de WP_DEBUG y sustitúyela por esto, siempre antes de la línea que dice «¡Eso es todo, deja de editar!»:

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

Con esto los errores se guardan en wp-content/debug.log y no se enseñan a los visitantes. Recarga la página que falla y abre el log:

tail -n 50 wp-content/debug.log

Verás algo así:

[29-Oct-2026 09:12:33 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /var/www/html/wp-content/plugins/plugin-antiguo/inc/widget.php:41

La ruta te dice el culpable: lo que va después de wp-content/plugins/ es la carpeta del plugin; si pone wp-content/themes/, es el tema. En la guía de «Fatal error» y «Parse error» de PHP explicamos cómo leer cada tipo de mensaje.

Si no aparece nada en debug.log, mira el registro de errores del servidor (en el panel suele llamarse «Error log» o «Registros»; por SSH, /var/log/apache2/error.log, /var/log/nginx/error.log o el log de PHP-FPM).

Paso 3: desactiva el plugin o tema culpable

Sin acceso al escritorio, tienes tres formas.

Con wp-cli (la más limpia)

wp plugin list --status=active
wp plugin deactivate nombre-del-plugin --skip-plugins --skip-themes

Las opciones --skip-plugins --skip-themes evitan que wp-cli cargue el código roto y falle él también. Si el culpable es el tema:

wp theme list
wp theme activate twentytwentyfour --skip-plugins --skip-themes

(Usa el tema por defecto que tengas instalado.)

Por FTP o gestor de archivos

Renombra la carpeta del plugin, por ejemplo wp-content/plugins/plugin-antiguo a plugin-antiguo.off. WordPress no lo encuentra y lo desactiva. Si no sabes cuál es, renombra la carpeta plugins entera a plugins.off, comprueba que la web vuelve, deja otra vez el nombre original y ve desactivando uno a uno desde el escritorio.

Desde el panel del hosting

Muchos paneles (Plesk con WordPress Toolkit, cPanel con Softaculous) permiten desactivar plugins o cambiar la versión de PHP sin entrar a WordPress.

Paso 4: arregla la causa, no solo el síntoma

Desactivar el plugin devuelve la web, pero quizá te deja sin formulario, sin pagos o sin el constructor de páginas. Según lo que diga el log:

• Función no definida o «deprecated» convertida en fatal tras subir PHP: actualiza el plugin. Si no hay versión compatible, vuelve temporalmente a la versión de PHP anterior desde el panel y busca un reemplazo.
• Memoria agotada: sube el límite en wp-config.php con define( 'WP_MEMORY_LIMIT', '256M' ); y, si el hosting lo limita más abajo, pídeselo. Si un plugin agota 256 MB, el problema es el plugin.
• Código propio en functions.php: deshaz el último cambio. Para comprobar la sintaxis de un fichero antes de subirlo: php -l functions.php.
• Actualización a medias: reinstala la misma versión del plugin con wp plugin install nombre --force.

Cuando acabes, deja WP_DEBUG en false y borra wp-content/debug.log. Ese fichero queda accesible por URL en muchos servidores y enseña rutas y datos internos.

Errores habituales

• Restaurar una copia sin mirar el log. Vuelve la web, pero la próxima actualización automática lo rompe otra vez.
• Dejar WP_DEBUG_DISPLAY en true en producción. Los visitantes ven rutas del servidor y Google puede indexarlas.
• Borrar el plugin en vez de desactivarlo. Algunos borran sus datos al desinstalarse. Renombrar la carpeta es reversible.
• Actualizar todo a la vez. Si actualizas veinte plugins y PHP el mismo día, no sabrás cuál falló. Hazlo por tandas y, si puedes, en un entorno de pruebas.
• Confiar en que el correo de recuperación llegará. Comprueba hoy que la dirección de administración es correcta y que el servidor envía correo.

Para agencias: que no te lo cuente el cliente

Este error es silencioso desde fuera: el servidor responde, la página carga rápido y un monitor que solo mire si hay respuesta puede darlo por bueno aunque tenga un código 500 en una sola página. Lo normal es enterarse cuando el cliente llama.

Jeffrey hace cada día una prueba con un navegador real, en móvil y en escritorio, sobre hasta cinco páginas de cada web: la portada, las que tú marques, las dos que más visitas reciben desde Google, la de contacto y una de producto. Si en pantalla aparece «Ha habido un error crítico en esta web» (o su versión en inglés), lo marca como error crítico de WordPress. Antes de avisar repite la prueba a los cinco minutos, para no despertarte por un fallo momentáneo, y si se confirma te llega un aviso urgente con la URL y el dispositivo. Con el plugin de Jeffrey instalado, además, la prueba se lanza un par de minutos después de cada actualización de plugins, tema o núcleo, y el aviso dice qué actualización lo provocó.

Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Más contexto en nuestra guía de errores de WordPress que tumban tu web y en la de pantalla blanca en WordPress, que es lo que veías antes de WordPress 5.2.

Preguntas frecuentes