0 Comentarios
El mensaje “Ha habido un error crítico en esta web” suele aparecer cuando WordPress detecta un error fatal de PHP y no puede completar la carga de una página. La causa puede estar en un plugin, el tema, un fragmento de código, una incompatibilidad con PHP o la falta de memoria del servidor. El aviso no identifica por sí solo al responsable: hace falta seguir un diagnóstico ordenado.
La vía más rápida es revisar el correo del administrador y entrar mediante el modo de recuperación. Si el mensaje no ha llegado, se puede recuperar el acceso por FTP o desde el administrador de archivos del hosting, desactivar el componente sospechoso y consultar los registros de errores. Antes de modificar archivos o restaurar una copia, guarda el estado actual de la web.
| Situación | Primera acción recomendada | Qué evita |
|---|---|---|
| WordPress ha enviado un correo | Entrar con el enlace del modo de recuperación | Desactivar componentes a ciegas |
| El fallo apareció tras actualizar un plugin | Renombrar solo la carpeta de ese plugin | Interrumpir funciones que sí están operativas |
| No sabes qué cambió | Activar el registro de depuración sin mostrar errores al público | Probar soluciones sin conocer la causa |
El log indica Allowed memory size exhausted |
Revisar el consumo y el límite de memoria PHP | Aumentar recursos sin corregir el origen |
| La web vende, recibe leads o no admite una caída prolongada | Restaurar una copia verificada o pedir soporte técnico | Alargar la incidencia y perder datos nuevos |
Desde WordPress 5.2, el núcleo incorpora un gestor de errores fatales. Cuando detecta determinados fallos de PHP, sustituye la antigua pantalla blanca por un aviso más comprensible y, normalmente, devuelve un error HTTP 500. El mensaje protege al visitante de detalles técnicos sensibles, pero no explica si el problema está en un plugin, el tema o el servidor.
El error puede afectar a toda la web, solo al escritorio, a una URL concreta o a una acción determinada. Por ejemplo, una tienda puede cargar con normalidad y fallar únicamente al tramitar un pedido si el código defectuoso se ejecuta durante el checkout. Por eso no basta con comprobar la portada: después de cada cambio hay que repetir la acción exacta que provocaba el fallo.
Las causas habituales son:
Una actualización incompleta o incompatible de un plugin o tema.
Código añadido recientemente a functions.php, un plugin de snippets o un desarrollo a medida.
Una versión de PHP incompatible con alguno de los componentes instalados.
Archivos dañados, ausentes o con permisos incorrectos.
Agotamiento de la memoria disponible para PHP.
Conflictos entre plugins, temas, mu-plugins o sistemas de caché.
Para avisos distintos, la guía general de problemas en WordPress ayuda a distinguir este fallo de errores de base de datos, bucles de redirección, respuestas 404 y otras incidencias.
Una solución rápida deja de serlo si elimina pedidos recientes o dificulta averiguar qué ocurrió. Antes de empezar, anota la hora aproximada del primer error y cualquier cambio inmediatamente anterior: actualizaciones, instalación de plugins, edición de código, cambio de versión de PHP, migración o actuación del hosting.
Haz una copia de los archivos y de la base de datos, aunque el sitio ya esté caído. Esa copia no tiene por qué servir para restaurar, pero conserva el estado necesario para analizar el incidente. Si existe un entorno de staging, reproduce allí las pruebas invasivas. WordPress también recomienda disponer de una copia o un entorno de pruebas antes de modificar la instalación.
Evita tres movimientos impulsivos: actualizar todo a la vez, borrar directamente la carpeta de un plugin y restaurar una copia sin saber de qué fecha es. Cada uno cambia varias variables y puede complicar el diagnóstico o provocar pérdida de información.
El orden importa. Empieza por el método que aporta más información con menos cambios y avanza solo si el error continúa.
WordPress envía el aviso a la dirección configurada en Ajustes > Generales > Dirección de correo electrónico de administración. Comprueba la bandeja de entrada, spam y correo no deseado. El asunto suele indicar que el sitio tiene un problema técnico.
El mensaje puede incluir:
El plugin o tema en el que se produjo el error.
La URL afectada.
El tipo de error, el archivo y la línea implicados.
Un enlace temporal para iniciar sesión en modo de recuperación.
Abre ese enlace y accede con una cuenta administradora. Durante esa sesión, WordPress pausa el plugin o tema defectuoso para que puedas entrar en el escritorio. Ve a Plugins o Apariencia > Temas, localiza el aviso y desactiva el componente señalado. Si el fallo nació tras editar código, corrige o retira ese cambio antes de salir del modo de recuperación.
Después, abre la portada, varias páginas interiores y la función que fallaba. Sal del modo de recuperación únicamente cuando el error haya desaparecido. La documentación oficial del modo de recuperación explica su funcionamiento y sus límites.
¿No ha llegado el email? Puede que la dirección administrativa esté desactualizada o que el servidor no haya podido entregar el mensaje. No esperes indefinidamente: continúa por FTP o con el administrador de archivos.
Una incidencia que aparece justo después de una acción concreta permite empezar por esa variable antes de intervenir en el resto de la instalación. Una actualización de plugin apunta primero a ese plugin; un cambio de PHP, a la compatibilidad del entorno; y un error tras pegar un snippet, al archivo o herramienta donde se añadió.
No hagas una nueva actualización “por si acaso” sobre una web inestable. Recupera la versión anterior del componente desde una copia fiable o desactívalo de forma temporal. Cuando el sitio vuelva a responder, prueba la combinación de versiones en staging y revisa el registro de cambios del proveedor.
Cuando wp-admin no carga, accede a los archivos mediante SFTP/FTP o el administrador de archivos del alojamiento. En la raíz de WordPress encontrarás wp-content/plugins.
Si el correo o el momento del fallo señalan a un plugin concreto:
Abre wp-content/plugins/.
Localiza su carpeta, por ejemplo plugin-ejemplo.
Renómbrala como plugin-ejemplo-desactivado.
Recarga la web y repite la acción que provocaba el error.
WordPress dejará de cargar ese plugin, pero sus archivos y ajustes permanecerán en el servidor. Si la web se recupera, ya has aislado al sospechoso. Mantenlo inactivo hasta comprobar compatibilidad, sustituirlo o instalar una versión corregida.
Cuando no haya ninguna pista, renombra la carpeta completa plugins como plugins-desactivados. Intenta acceder a /wp-admin/plugins.php y, si funciona, devuelve a la carpeta su nombre original. Los plugins normales quedarán desactivados y podrás activarlos uno a uno, probando la web después de cada activación.
Este método no desactiva necesariamente los mu-plugins ni archivos de caché cargados desde wp-content, como object-cache.php o advanced-cache.php. Si el error persiste con los plugins normales desactivados, los logs indicarán si alguno de esos componentes interviene.
Un tema puede provocar el mismo error por una actualización fallida, código personalizado o incompatibilidad con PHP. Antes de forzar el cambio, confirma que wp-content/themes/ contiene un tema predeterminado de WordPress que pueda activarse como alternativa.
Renombra únicamente la carpeta del tema activo, por ejemplo de mi-tema a mi-tema-desactivado. WordPress intentará utilizar otro tema disponible. Si no hay ninguno válido instalado, el sitio seguirá sin poder mostrarse; en ese caso, sube un tema predeterminado limpio o realiza el cambio con ayuda técnica.
Que el sitio arranque con el tema alternativo confirma una relación, pero no da por cerrada la incidencia. Revisa el tema hijo, functions.php, las personalizaciones recientes y la compatibilidad entre el tema padre, los plugins y la versión de PHP.
Cuando no hay una causa evidente, el registro de depuración permite pasar de la sospecha a una pista concreta. Edita wp-config.php, situado en la raíz de WordPress, y añade o ajusta estas líneas antes del comentario 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 );
Con esta configuración, WordPress registra avisos y errores en wp-content/debug.log sin mostrarlos a los visitantes. Reproduce una sola vez la acción problemática y revisa las últimas entradas del archivo, fijándote en la fecha y hora.
No confundas el último aviso con la causa. Busca expresiones como Fatal error, Uncaught Error, Parse error o Allowed memory size exhausted, seguidas de una ruta y un número de línea. La ruta suele revelar el componente implicado: /plugins/nombre-del-plugin/, /themes/nombre-del-tema/ o un archivo del núcleo.
La guía oficial de depuración de WordPress recomienda estas herramientas para desarrollo y pruebas, no dejarlas activadas de forma permanente en producción. Cuando termines, vuelve a establecer WP_DEBUG como false, desactiva el log y elimina o protege el archivo generado, ya que puede contener rutas u otra información técnica sensible.
debug.log puede no crearse si WordPress falla antes de inicializar el sistema de depuración, si la carpeta no tiene permisos de escritura o si el alojamiento dirige los errores a otro registro. En el panel del hosting busca apartados como Errores, Registros, PHP error log o Logs del servidor.
Lee primero la entrada que coincide con la hora y la petición afectada. La última línea no siempre es la causa: un error anterior puede desencadenar varios avisos posteriores.
| Mensaje del log | Qué suele indicar | Siguiente comprobación |
|---|---|---|
Uncaught Error o función/clase inexistente |
Código incompatible o dependencia ausente | Ruta del archivo, versión del plugin, tema y PHP |
Parse error o syntax error |
Error de sintaxis en código editado o archivo incompleto | Línea indicada y último cambio realizado |
Allowed memory size exhausted |
El proceso ha alcanzado el límite de memoria | Componente que consume memoria y límite efectivo |
Maximum execution time exceeded |
Proceso bloqueado o demasiado costoso | Importaciones, copias, consultas, cron y plugins implicados |
Cannot redeclare |
Dos componentes declaran la misma función o clase | Conflicto entre plugins, tema o código personalizado |
La ruta y el contexto pesan más que el texto aislado. Que el error aparezca dentro de un archivo del núcleo no demuestra que WordPress sea el origen; ese archivo puede ser el punto donde termina manifestándose un dato incorrecto enviado por otro componente.
Si el log contiene Allowed memory size ... exhausted, comprueba el límite efectivo en el panel del hosting o en Herramientas > Salud del sitio > Información > Servidor, si todavía puedes entrar. En wp-config.php se puede solicitar un límite mayor para WordPress:
define( 'WP_MEMORY_LIMIT', '256M' );
El valor adecuado depende del alojamiento y de la carga real. El servidor puede imponer un máximo inferior y no aceptar el cambio. Tampoco conviene usar una cifra cada vez mayor como solución permanente: si un plugin entra en un bucle o ejecuta una tarea desproporcionada, ampliar memoria solo retrasará el siguiente fallo.
Tras recuperar el acceso, identifica qué proceso agotó los recursos. Si el consumo creció después de una actualización, una importación, un constructor visual o una tarea programada, reproduce el caso en pruebas y corrige esa causa.
Un cambio de versión de PHP puede dejar obsoleto un plugin antiguo; mantener PHP desactualizado también puede impedir que funcione código moderno. Compara los requisitos de WordPress, el tema y cada extensión implicada antes de subir o bajar de versión.
Cuando el error comienza justo después de modificar PHP, volver temporalmente a la versión anterior puede recuperar el servicio, pero no sustituye la corrección. El objetivo es actualizar o reemplazar el componente incompatible y utilizar una versión de PHP mantenida por el proveedor.
Cuando el log apunta a archivos ausentes o dañados del núcleo, reinstala la misma versión de WordPress o reemplaza los archivos con una copia oficial, preservando wp-content y wp-config.php. Esta operación exige copia previa y atención a instalaciones personalizadas; no borres carpetas sin confirmar qué contienen.
Restaurar tiene sentido cuando conoces una copia funcional, el diagnóstico se alarga y el coste de la caída supera el de volver atrás. La copia debe incluir archivos y base de datos compatibles entre sí.
Antes de restaurar, responde a cuatro preguntas:
¿De qué fecha y hora es el backup?
¿Se ha probado alguna vez su restauración?
¿Qué pedidos, formularios, usuarios o contenidos se perderían?
¿Puedes conservar primero una copia del estado averiado para analizarlo después?
En una tienda o plataforma con actividad continua, restaurar una base de datos antigua puede eliminar transacciones válidas. En esos casos suele ser preferible recuperar solo los archivos afectados, poner el sitio temporalmente en mantenimiento o coordinar una restauración selectiva.
Que la portada cargue no garantiza que el problema esté resuelto. Haz una comprobación breve pero representativa:
Abre la home y varias plantillas distintas: entrada, página, categoría y ficha de producto si existe.
Entra en wp-admin y revisa Plugins, Temas y Salud del sitio.
Ejecuta la acción que originó el error: guardar, enviar un formulario, comprar, importar o actualizar.
Comprueba tareas programadas, envío de correos y procesos en segundo plano relacionados.
Revisa de nuevo los logs para confirmar que no se siguen generando errores fatales.
Vacía la caché de página, servidor y CDN solo después de corregir la causa.
Documenta el componente, la versión y la solución aplicada. Esa información permitirá reaccionar mucho más rápido si el fallo se repite.
Detén las pruebas en producción si no puedes hacer una copia fiable, el error afecta a ventas o captación, hay datos recientes que no deben perderse, aparecen indicios de una intrusión o no tienes claro cómo volver al estado anterior. También merece intervención técnica un fallo que reaparece al activar el componente necesario: desactivarlo recupera la web, pero no resuelve la función de negocio que dependía de él.
El servicio de mantenimiento WordPress de Webtec incluye actualizaciones, copias de seguridad, monitorización y actuación ante caídas. Contar de antemano con un procedimiento de backup, un entorno de pruebas y registros accesibles reduce tanto el tiempo de diagnóstico como el riesgo de improvisar cuando la web deja de responder.
¿Qué te ha parecido este artículo?