“There has been a critical error on this website” significa que WordPress se detuvo por un error fatal de PHP, normalmente provocado por un plugin, un tema o una versión de PHP incompatible. Para solucionarlo, abre el correo que WordPress envió a la dirección del administrador, sigue el enlace al modo de recuperación y desactiva el plugin defectuoso. Si no llegó ningún correo, activa WP_DEBUG_LOG en wp-config.php, busca la ruta del archivo en wp-content/debug.log y renombra la carpeta de ese plugin o tema desde el gestor de archivos o por FTP.
Qué significa “There has been a critical error on this website”
Desde WordPress 5.2, el núcleo captura los errores fatales de PHP: en lugar de una página en blanco, los visitantes ven un mensaje breve, el servidor devuelve HTTP 500 y el administrador recibe un correo con un enlace al modo de recuperación. Antes de la 5.2, el mismo problema se veía como la “pantalla blanca de la muerte”. Todavía puedes encontrarte una pantalla blanca si el gestor de errores está desactivado, si la memoria se agotó antes de que pudiera ejecutarse o si una caché sirve una página vacía.
Si tu WordPress está en español, el mensaje y el correo aparecen traducidos. Aquí citamos el texto original en inglés, que es igual en todas las instalaciones.
| Qué ves | Dónde | Qué significa |
|---|---|---|
| “There has been a critical error on this website.” y un enlace de ayuda | Parte pública | Error fatal de PHP; el correo al administrador ya se envió o está a punto de enviarse |
| El mismo texto y además “Please check your site admin email inbox for instructions.” | Escritorio o página de acceso | El modo de recuperación está listo; el enlace está en el buzón |
| “There has been a critical error on this website, putting it in recovery mode.” | Escritorio tras usar el enlace | El plugin o tema defectuoso está en pausa para tu sesión |
| Página en blanco | En cualquier parte | El error no se capturó o la caché sirve una respuesta vacía |
| Solo 500 Internal Server Error | En cualquier parte | Fallo antes de que cargue WordPress: .htaccess, permisos, configuración de PHP |
Paso 1. Usa el correo de WordPress y el modo de recuperación
Cuando salta el gestor, WordPress envía un correo a la dirección de Ajustes > Generales (admin_email), que en inglés lleva el asunto “[Site name] Your Site is Experiencing a Technical Issue”. El correo nombra el plugin o el tema, muestra el error con el archivo y la línea, indica las versiones de WordPress y PHP e incluye el enlace al modo de recuperación.
- Sigue el enlace e inicia sesión como administrador.
- En la pantalla de plugins, el plugin defectuoso aparece en pausa. Desactívalo o actualízalo si ya existe una versión corregida.
- Si el culpable es el tema, activa un tema por defecto en Apariencia > Temas.
- Sal del modo de recuperación con el botón de la barra de administración (“Exit Recovery Mode” en inglés) y comprueba la web en una ventana privada del navegador.
El modo de recuperación solo funciona para tu sesión: los visitantes siguen viendo el error hasta que desactives al culpable. El enlace es válido durante aproximadamente un día y WordPress no envía más de un correo nuevo al día (el filtro recovery_mode_email_rate_limit tiene por defecto DAY_IN_SECONDS).
Si el correo nunca llegó
- Revisa la carpeta de spam y comprueba que el correo del administrador en Ajustes es correcto.
- Comprueba que la web puede enviar correos: si mail() no funciona en el servidor, el mensaje no saldrá.
- Envía los correos de recuperación a otra dirección:
define( 'RECOVERY_MODE_EMAIL', 'admin@example.com' ); - No esperes un día a que llegue otro correo: pasa al paso 2, que no lo necesita.
Paso 2. Activa WP_DEBUG y lee debug.log
Abre wp-config.php en la raíz del sitio desde el gestor de archivos del panel de control, por FTP o por SSH. Sustituye define( 'WP_DEBUG', false ); por el bloque siguiente, encima de la línea “That’s all, stop editing!”.
define( 'WP_DEBUG', true ); // enable debug mode
define( 'WP_DEBUG_LOG', true ); // write errors to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // do not show errors to visitors
@ini_set( 'display_errors', 0 );Recarga la página que falla y revisa el final del registro:
tail -n 30 wp-content/debug.log
# fatal errors only
grep "PHP Fatal" wp-content/debug.log | tail -n 5Una entrada típica tiene este aspecto:
[21-Oct-2026 11:02:17 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /home/user/web/example.com/public_html/wp-content/plugins/my-shop-addon/includes/class-cart.php:48Lo importante es la ruta: /wp-content/plugins/my-shop-addon/ apunta a un plugin, /wp-content/themes/theme-name/ a un tema, y /wp-includes/ o /wp-admin/ a archivos del núcleo dañados. El texto que sigue a “PHP Fatal error” explica la causa; la tabla de más abajo descifra los mensajes más comunes.
El registro dentro de wp-content es accesible por URL, así que vuelve a poner WP_DEBUG en false y borra debug.log cuando termines. Otra opción: desde WordPress 5.1, WP_DEBUG_LOG admite una ruta de archivo fuera de la raíz web:
define( 'WP_DEBUG_LOG', '/home/user/logs/wp-errors.log' );Si debug.log sigue vacío, revisa el registro de errores del dominio. Se abre desde el panel de control (en el servidor suele estar en /var/log/apache2/ o /var/log/nginx/), y los errores de PHP-FPM aparecen en él como “PHP message: PHP Fatal error”.
Paso 3. Desactiva el plugin o el tema sin el escritorio
Gestor de archivos o FTP
Renombra la carpeta del plugin, por ejemplo wp-content/plugins/my-shop-addon a my-shop-addon.off. WordPress no encontrará el archivo del plugin y lo desactivará en la siguiente carga. Si el registro no dio ninguna pista, renombra toda la carpeta plugins a plugins.off, confirma que la web abre, devuélvele su nombre y vuelve a activar los plugins uno a uno hasta que reaparezca el error. Haz lo mismo con wp-content/themes/theme-name si se trata de un tema: WordPress recurre a un tema por defecto si hay alguno instalado.
Renombrar plugins no afecta a wp-content/mu-plugins (plugins imprescindibles, must-use) ni a los drop-ins advanced-cache.php y object-cache.php que los plugins de caché añaden en wp-content. Revísalos también.
WP-CLI por SSH
cd /home/user/web/example.com/public_html
wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate my-shop-addon --skip-plugins --skip-themes
# deactivate all plugins at once
wp plugin deactivate --all --skip-plugins --skip-themes
# switch to a default theme
wp theme activate twentytwentyfive --skip-plugins --skip-themes
# verify core and WordPress.org plugin files
wp core verify-checksums
wp plugin verify-checksums --allLos parámetros --skip-plugins y --skip-themes evitan que WP-CLI cargue el mismo código roto y se caiga junto con la web.
Base de datos
Si no tienes SSH ni FTP pero sí phpMyAdmin, desactiva todos los plugins con una sola consulta. Exporta antes la tabla de opciones y sustituye el prefijo wp_ por el tuyo, que aparece en wp-config.php:
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
Causas habituales del error crítico y soluciones
| Texto en debug.log | Causa | Solución |
|---|---|---|
| Allowed memory size of … bytes exhausted | El script superó memory_limit | Sube WP_MEMORY_LIMIT o memory_limit de PHP y averigua qué consume la memoria |
| Call to undefined function | Falta un plugin necesario, una extensión de PHP o una función eliminada | Instala la dependencia o la extensión, actualiza o sustituye el plugin |
| Uncaught TypeError, ArgumentCountError | Código antiguo en una versión de PHP más nueva | Actualiza el plugin o el tema, o vuelve temporalmente a la versión de PHP anterior |
| Cannot redeclare function | La misma función declarada dos veces: plugin duplicado o fragmento en functions.php | Elimina el duplicado o el fragmento |
| syntax error, unexpected | Un error en un archivo que acabas de editar | Restaura la versión anterior del archivo |
| Class … not found, Failed opening required | Una actualización se interrumpió y faltan archivos | Reinstala el plugin o el núcleo |
| Maximum execution time of … seconds exceeded | El script tardó más que max_execution_time | Localiza la tarea lenta; ejecuta los procesos pesados con WP-CLI o cron |
Si la memoria se agota con frecuencia, subir el límite solo aplaza el problema. Fíjalo en wp-config.php y busca después el plugin que consume la memoria; en nuestra guía para solucionar Allowed memory size exhausted encontrarás el método completo. Esos mismos plugins suelen explicar también por qué tu WordPress va lento.
define( 'WP_MEMORY_LIMIT', '256M' );
Error crítico tras actualizar PHP o WordPress
La mayoría de los errores críticos aparecen justo después de una actualización. WordPress 7.0, publicado el 20 de mayo de 2026, exige como mínimo PHP 7.4 y recomienda 8.4 u 8.5, mientras que algunos plugins y temas antiguos fallan en PHP 8.x por sus comprobaciones de tipos más estrictas.
- Si el error empezó tras cambiar la versión de PHP, vuelve a poner el dominio en la versión anterior, actualiza plugins y temas y luego cambia de nuevo.
- Si una actualización de un plugin rompió la web, instala la versión anterior desde la página del plugin en WordPress.org (Advanced View, versiones anteriores) o desde una copia de seguridad.
- Si una actualización interrumpida dañó archivos del núcleo, descárgalos de nuevo sin tocar wp-content:
wp core download --skip-content --force. Descarga la última versión; para conservar la tuya, añade--versioncon el número que muestrawp core version.
Desde WordPress 6.6, el núcleo revierte las actualizaciones automáticas de plugins: tras una actualización automática comprueba la web y restaura la versión anterior si detecta un error fatal. Las actualizaciones manuales desde el escritorio no están cubiertas, así que mantén copias de seguridad recientes.
Pantalla blanca sin mensaje: qué revisar
Primero comprueba el código de estado HTTP:
curl -sI https://example.com/ | head -n 1- 200 y una página vacía: normalmente una caché guardó una respuesta vacía. Vacía la caché del plugin, del servidor y de Cloudflare y prueba con ?nocache=1.
- 500: un error fatal que el gestor no capturó. Asegúrate de que wp-config.php no contiene
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );y lee debug.log y el registro del dominio. - 403: el servidor no puede leer los archivos. Los permisos estándar son 644 para archivos y 755 para carpetas.
- 502 o 504: PHP-FPM se cayó o no responde; busca en los registros del servidor, no en WordPress. Nuestra guía sobre el error 504 Gateway Timeout explica cómo hacerlo.
Cómo lo comprobamos: el 30.10.2026 contrastamos los datos de esta guía con fuentes oficiales: la referencia de código en developer.wordpress.org (WP_Fatal_Error_Handler, WP_Recovery_Mode_Email_Service, filtro recovery_mode_email_rate_limit), la guía “Debugging in WordPress”, la referencia de WP-CLI para wp core download, la página de compatibilidad de WordPress 7.0 en el Hosting Handbook de make.wordpress.org, la propuesta “Rollback Auto-Update” para WordPress 6.6 y Google Search Central (errores HTTP y de red). Las líneas de registro, rutas y comandos son ejemplos con example.com y un plugin ficticio (my-shop-addon).
Preguntas frecuentes
¿Puedo simplemente ocultar el mensaje de error crítico?
Puedes desactivar el gestor con WP_DISABLE_FATAL_ERROR_HANDLER, pero entonces los visitantes verán una pantalla blanca y perderás el correo del modo de recuperación. Corrige el error en lugar de esconderlo.
¿Es seguro dejar WP_DEBUG activado?
No. El registro puede exponer rutas de archivos y fragmentos de datos, y wp-content/debug.log es accesible por URL. Desactívalo al terminar y borra el registro, o escríbelo fuera de la raíz web.
El error solo aparece en el escritorio. ¿Por qué?
Normalmente la culpa es de un plugin que solo se carga en wp-admin, o de una caché que sigue sirviendo páginas guardadas a los visitantes. El diagnóstico es el mismo: debug.log y después desactivar los plugins uno a uno.
¿Un error crítico perjudica al SEO?
Las páginas rotas devuelven HTTP 500. Google trata las caídas 5xx cortas como temporales, pero si la web sigue caída durante días, las páginas pueden salir del índice, así que corrígelo rápido.
¿Cómo evito que vuelva a pasar?
Haz una copia de seguridad antes de actualizar, actualiza los plugins de uno en uno, elimina los plugins abandonados, comprueba la compatibilidad con PHP antes de cambiar de versión y configura la monitorización del hosting para enterarte de los errores antes que tus visitantes.
Conclusión
“There has been a critical error on this website” indica un error fatal de PHP, no un hackeo ni una pérdida de datos. Usa el correo del administrador y el modo de recuperación; si no hay correo, activa WP_DEBUG_LOG, busca en debug.log la ruta del plugin o tema defectuoso y desactívalo renombrando la carpeta o con WP-CLI. Con gestor de archivos, SSH y acceso a los registros es cuestión de cinco minutos, y por eso la plataforma importa a la hora de elegir hosting para WordPress. Los planes de hosting de RichHost incluyen el panel de control propio con asistente de IA, discos NVMe y SSL gratuito.
