¿Qué significa "ha habido un error crítico en esta web"?

Significa que PHP sufrió un error fatal mientras construía la página y WordPress lo interceptó antes de que apareciera la pantalla en blanco. El mensaje es deliberadamente vago para que los visitantes no vean rutas de archivos ni código. El error real, con archivo y número de línea, se escribe en un registro dentro del servidor.

¿Dónde está el registro del error crítico de WordPress?

Si defines WP_DEBUG y WP_DEBUG_LOG como true en wp-config.php, WordPress escribe en wp-content/debug.log. Si están desactivados, el error igualmente va al registro de errores PHP de tu hosting, normalmente accesible desde el panel de control en la sección de registros o error logs. Revisa los dos antes de dar por hecho que no se guardó nada.

¿Por qué no me llegó el correo del modo de recuperación de WordPress?

El correo se envía a la dirección de administración del sitio configurada en Ajustes, no a la dirección con la que accedes, y lo manda el mismo PHP averiado que acaba de caerse, así que el envío falla a menudo. Muchos alojamientos compartidos además bloquean el correo saliente si no hay SMTP. Mira en spam y, si no aparece, olvídate del correo y desactiva los plugins por SFTP.

¿Cómo soluciono un error crítico si no puedo entrar en wp-admin?

Conéctate por SFTP o con el administrador de archivos de tu hosting y renombra la carpeta wp-content/plugins a plugins-off. Eso desactiva todos los plugins de golpe y casi siempre devuelve el acceso al escritorio. Después vuelve a ponerle su nombre original y reactiva los plugins de uno en uno hasta que reaparezca el error: ese es el culpable.

¿Puede una actualización de la versión de PHP provocar un error crítico en WordPress?

Sí, y es una de las causas más frecuentes. Los alojamientos actualizan PHP de forma automática, y el código antiguo de un plugin o un tema que usa sintaxis eliminada revienta al instante. La entrada del registro suele nombrar un archivo concreto dentro de wp-content. Volver a la versión anterior de PHP desde el panel de tu hosting confirma el diagnóstico, aunque es una solución temporal.

¿El mensaje de error crítico significa que me han hackeado la web?

Casi nunca. La inmensa mayoría de las veces se trata de una actualización de un plugin o un tema incompatible con tu versión de PHP, o de memoria agotada. El malware también puede provocar errores fatales, pero entonces la entrada del registro apunta a un archivo desconocido o a código ofuscado. Lee el registro antes de dar por sentado que hay una intrusión.

Ha habido un error crítico en esta web: qué significa y cómo solucionarlo

Ese mensaje significa que PHP sufrió un error fatal mientras construía tu página y que WordPress lo interceptó antes de que se convirtiera en una pantalla en blanco. El error es real, concreto y queda registrado: WordPress simplemente se niega a imprimirlo en el navegador, porque una traza de error en una página pública deja rutas de archivos y código a la vista de cualquiera.

Por eso la solución nunca pasa por adivinar. Consiste en leer el error real y actuar sobre lo que dice.

Qué está pasando en realidad

Desde WordPress 5.2 el núcleo incorpora un gestor de errores fatales. Cuando PHP muere a mitad de una petición, ese gestor interviene, sustituye la salida del fallo por la frase genérica y educada y, si consigue deducir qué plugin o tema lo causó, intenta enviar al administrador del sitio un correo con un enlace al modo de recuperación.

Por eso ves esto en lugar de la vieja pantalla blanca de la muerte. Es una mejora, pero también implica que la información de diagnóstico queda oculta por defecto. El mensaje tiene dos variantes:

Lo que ves	Dónde	Qué te dice
”Ha habido un error crítico en esta web.”	Portada, sin sesión iniciada	Se produjo un error fatal, sin más detalle expuesto
La misma frase más “Aprende más sobre la resolución de problemas en WordPress”	Portada o wp-admin	El mismo error; WordPress te ofrece la página del manual
”…Por favor, revisa la bandeja de entrada del correo del administrador del sitio para más instrucciones.”	Portada	El gestor cree que envió un correo de recuperación

Esa tercera variante es la útil. Significa que WordPress atribuyó el fallo a un plugin o un tema concreto e intentó darte una vía de entrada.

Paso 1: revisa el correo del modo de recuperación

WordPress envía el enlace de recuperación a la dirección de correo del administrador del sitio, la que está en Ajustes, Generales, que muchas veces no es la dirección con la que inicias sesión. Revisa esa bandeja de entrada, y revisa el spam.

El correo contiene un enlace largo que termina en algo parecido a ?action=enter_recovery_mode. Al abrirlo entras en wp-admin en modo de recuperación, con el plugin o el tema problemático pausado y señalado en un aviso rojo en la parte superior. Desde ahí ya puedes desactivarlo con normalidad.

Dos matices honestos. Primero: el correo lo genera el mismo proceso PHP que acaba de caerse, en un servidor que puede no tener ningún transporte de correo funcional, así que la falta de entrega es habitual y su ausencia no dice nada sobre el error. Segundo: el enlace de recuperación caduca (aproximadamente un día por defecto), de modo que un correo viejo en tu bandeja puede haber dejado de servir; provoca un fallo nuevo recargando la web y espera a que llegue otro correo.

Si quieres que ese correo llegue a una dirección que de verdad leas, defínela de forma explícita en wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Paso 2: lee el error real

Este es el paso que convierte una web rota en un arreglo de cinco minutos. Añade estas líneas a wp-config.php, por encima de la línea que indica que dejes de editar:

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

Que WP_DEBUG_DISPLAY esté en false importa: mantiene el error fuera del navegador mientras lo sigue escribiendo en disco, así que no expones rutas a los visitantes mientras depuras.

Recarga una vez la página rota y abre wp-content/debug.log. La última entrada tendrá más o menos este aspecto:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

La ruta del archivo es la respuesta. Si apunta a wp-content/plugins/, la causa es ese plugin. Si apunta a wp-content/themes/, es el tema, muy a menudo algo que se pegó hace poco en functions.php.

Si debug.log no aparece, puede que el directorio no tenga permisos de escritura o que un plugin de seguridad haya movido el registro a otro sitio. Recurre entonces al registro de errores PHP de tu hosting: casi todos los paneles de control tienen una sección “Error Log” o “Registros”, y ahí estará el mismo error fatal con su marca de tiempo.

Pega la entrada en el descodificador de registros de error de WordPress para traducir la redacción de PHP a lo que significa en la práctica y saber qué archivo mirar primero.

Borra estas líneas de depuración cuando termines. Dejar WP_DEBUG activo en producción llena el disco y, si WP_DEBUG_DISPLAY vuelve a activarse en algún momento, imprime rutas del servidor de forma pública.

Paso 3: recupera el acceso a wp-admin

Si wp-admin también está caído y no llegó ningún correo de recuperación, desactiva todos los plugins a nivel de archivos. Conéctate por SFTP (o con el administrador de archivos de tu hosting) y renombra una carpeta:

mv wp-content/plugins wp-content/plugins-off

WordPress no encuentra los plugins, así que los desactiva todos y el acceso al escritorio casi siempre vuelve. Después:

Devuelve a la carpeta su nombre plugins. Todo sigue desactivado: WordPress los registró como inactivos.
Reactiva los plugins de uno en uno y carga la portada después de cada activación.
El que hace reaparecer el error es tu culpable.

Si la web sigue rota con todos los plugins desactivados, el sospechoso es el tema. Renombra la carpeta del tema activo dentro de wp-content/themes/ y WordPress recurrirá a un tema por defecto si tienes alguno instalado.

Las tres causas que conviene conocer

Una actualización de plugin o tema que provoca un error fatal. Con diferencia, la más habitual. El registro nombra el archivo directamente. Vuelve a la versión anterior de ese plugin, o déjalo desactivado y escribe al desarrollador adjuntando la línea del registro.

Un desajuste con la versión de PHP. Los alojamientos actualizan PHP según su propio calendario, a veces sin demasiado aviso. Código escrito para versiones antiguas puede dejar de interpretarse por completo en una versión nueva. La señal es que no tocaste nada y todo se rompió a la vez. Bajar PHP una versión menor desde el panel de tu hosting es un diagnóstico válido, pero tómatelo como ganar tiempo, no como una solución: las versiones antiguas de PHP dejan de recibir parches de seguridad.

Memoria agotada. El registro dice “Allowed memory size of X bytes exhausted”. Subir el límite en wp-config.php es razonable:

define( 'WP_MEMORY_LIMIT', '256M' );

Sé sincero sobre lo que hace eso: quita el techo, no arregla aquello que consumía 256 MB para renderizar una sola página. Si el límite necesita subir una y otra vez, hay algo detrás (normalmente una importación, un maquetador visual o una consulta mal escrita) que es el problema de verdad.

Consejos que puedes ignorar tranquilamente

“Sube el límite de memoria y ya.” Solo tiene sentido si el registro dice literalmente que la memoria se agotó. En cualquier otro caso no cambia nada y tapa el hecho de que nunca llegaste a leer el error.

“Reinstala el núcleo de WordPress.” Los archivos del núcleo casi nunca son la causa, y reemplazarlos te quita tiempo que podrías dedicar a leer una línea del registro.

“Desactiva el gestor de errores fatales.” Existe una constante para desactivarlo, y el resultado es que el error crudo se imprime en tu web pública en lugar de quedar interceptado. Eso expone rutas de archivos a los visitantes. Usa WP_DEBUG_LOG con WP_DEBUG_DISPLAY desactivado: la misma información, sin exponer nada.

“Vacía la caché.” Un error fatal ocurre en PHP antes de que un plugin de caché pueda servir nada. Si se está sirviendo una copia cacheada de la página de error, vaciar la caché ayuda después de arreglar la causa, nunca en su lugar.

¿Sigues atascado?

Si el registro apunta a un archivo del núcleo y no a algo dentro de wp-content, la explicación más probable es que un plugin cargado antes rompió el estado del que depende el núcleo, no que el núcleo esté corrupto. Desactívalo todo renombrando la carpeta, comprueba que la web carga limpia y ve reintroduciendo plugins uno a uno: el último que actives antes de que el error vuelva es el que debes reportar, con la línea del registro adjunta.