WordPress muestra el mensaje genérico de error crítico cuando PHP se detiene por un error fatal no controlado. El texto visible no permite saber si la causa es un plugin, el tema, un fragmento de código propio, la versión de PHP, un archivo ausente o un recurso agotado.
Antes de desactivar componentes, conserva el primer error y el historial de cambios recientes. La reparación fiable más rápida empieza por el archivo y la ruta de ejecución que fallan, no por desactivar elementos al azar.
Delimita el fallo
Anota la URL exacta, la hora, la acción realizada y si falla la web pública, la administración, el acceso, las tareas programadas o una sola página. Haz una única prueba desde una ventana privada.
Comprueba si justo antes hubo una actualización, un despliegue, un cambio de PHP o una restauración. Registra versiones y operador sin buscar culpables.
No repitas una acción de escritura, como una importación o el envío de un formulario, hasta saber si llegó a completarse antes del error fatal.
Crea una copia recuperable
Haz copia de los archivos y la base de datos antes de editar. Si el espacio está casi lleno, descarga la copia o utiliza un destino externo en vez de generar otro archivo grande dentro de la misma cuenta.
Confirma que funcionan tus accesos a cPanel, Plesk, SFTP o SSH y que conoces la raíz activa de la web. Una copia que no puedes localizar ni restaurar no sirve como reversión.
No sobrescribas la única copia conocida con una restauración sin comprobar.
Lee el error fatal de PHP
Consulta el registro de errores PHP del alojamiento y busca la misma hora y petición. El error suele indicar un archivo y una línea, además de un mensaje como función inexistente, error de tipo o memoria agotada.
Datos que conviene guardar:
tipo y mensaje del error fatal
ruta del plugin, tema o archivo
línea y pila de llamadas
versión de PHP
petición y horaOculta nombres de cuentas del servidor, secretos y datos de clientes antes de compartir el registro.
Activa un registro privado de WordPress si hace falta
Si los registros del servidor no bastan, añade temporalmente estas líneas antes de «stop editing» en wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );No dupliques constantes ni muestres errores a los visitantes. Cuando hayas reunido las pruebas, desactiva la depuración y protege o elimina el registro según la política de conservación.
Aísla el componente señalado
Si el error apunta a un plugin, renombra únicamente su directorio desde el gestor de archivos o SFTP. Si apunta al tema activo, comprueba que existe un tema predeterminado compatible antes de cambiarlo.
En un plugin de fragmentos personalizados, desactiva solo el fragmento implicado mediante su modo seguro documentado o, después de una copia, desde la base de datos.
No renombres todo el directorio de plugins salvo que no haya pruebas y dispongas de un plan ordenado de reactivación.
Comprueba PHP y las dependencias ausentes
Una función inexistente puede significar que no se cargó un plugin del que depende otro o que una actualización dejó archivos incompletos. Un error de tipo puede revelar incompatibilidad con la versión actual de PHP.
Compara los requisitos de WordPress, plugin o tema y PHP. Si los checksums o el recuento de archivos muestran un despliegue incompleto, reinstala exactamente el paquete oficial correspondiente.
No descargues código sustitutivo de repositorios dudosos ni reviertas una corrección de seguridad sin un plan posterior.
Aplica la reparación mínima
Actualiza o revierte un único componente, corrige el código propio, restaura la dependencia ausente o elige una versión compatible de PHP según las pruebas. Mantén el cambio reversible y documéntalo.
Limpia OPcache y los recursos generados mediante los controles compatibles del alojamiento. Una caché de bytecode antigua puede mantener activo el error anterior.
No edites el núcleo de WordPress para ocultar el problema.
Comprueba más que la página afectada
Prueba páginas públicas, acceso, administración, editor, medios, tareas programadas y la acción original. Revisa si aparecen nuevos errores fatales y comprueba el correo o las integraciones externas relacionadas.
Un servicio recurrente debería vigilar los errores fatales de PHP y probar las actualizaciones antes de producción. La reparación urgente termina cuando se entiende la causa, funciona el recorrido afectado y se conserva una vía de reversión; no simplemente cuando desaparece el mensaje genérico.