Respuesta breve: WordPress detectó un error fatal de PHP y sustituyó la página por una pantalla de seguridad. Desde la versión 5.2 suele enviar un correo al administrador con el plugin o tema culpable y un enlace de modo recuperación. Ese email es la vía más rápida para volver a entrar.
Revisa primero el correo y el modo recuperación
Busca en la bandeja del administrador (y en spam) “Tu sitio está experimentando un problema técnico”. Normalmente nombra el componente que falla e incluye un enlace de modo recuperación que te deja entrar con ese componente pausado, para que lo actualices o borres desde un administrador que funciona. Si el correo no llegó, la web no puede enviar emails: un hallazgo en sí mismo.
Lee el error fatal real
Activa el registro en wp-config.php (WP_DEBUG_LOG activo, WP_DEBUG_DISPLAY desactivado) y abre /wp-content/debug.log. La última línea nombra el archivo, la línea y la función: por ejemplo un plugin llamando a una función que ya no existe en tu versión de PHP. El componente señalado es donde aflora el error, no siempre donde se originó: un plugin puede fallar hoy porque anoche se actualizó PHP.
Aísla sin destruir la evidencia
Si no tienes acceso al administrador, desactiva el sospechoso a nivel de archivos: por SFTP, renombra su carpeta dentro de /wp-content/plugins. Para confirmar que son los plugins, renombra toda la carpeta plugins a plugins_off; si la web vuelve, reactiva uno a uno. Para un fallo del tema, renombra la carpeta del tema activo para recurrir a uno por defecto. Desactivar todo de golpe recupera la portada pero cambia el estado de la aplicación y puede ocultar la secuencia original de los hechos y puede romper pagos o formularios por el camino.
Memoria, versión de PHP y código propio
Si el registro muestra memoria agotada, sube WP_MEMORY_LIMIT. Si nombra una función indefinida o una sintaxis rechazada, estás en una versión de PHP que el componente ya no admite: prueba una compatible en lugar de quedarte en una sin soporte. Si lo causó código propio en functions.php o un plugin de snippets, restaura la versión anterior en lugar de parchear a ciegas.
Comprueba algo más que la portada
Cuando cargue, repite la acción exacta que provocó el error, entra en el administrador y prueba cualquier función crítica ligada al componente reparado: compra, reserva, acceso. Confirma que las tareas programadas vuelven a ejecutarse, porque un error fatal puede detener WP-Cron en silencio. No reactives y actualices sin más el componente sin saber por qué falló, o la misma actualización reproduce el mismo error.
CRITERIO DE INCIDENTE WP REPAIR
Secuencia de intervención segura
El modo recuperación de WordPress contiene un error fatal de PHP. El componente nombrado en el correo es donde aflora el error; la causa de fondo puede seguir siendo PHP, memoria u otra dependencia.
- Conserva el correo de recuperación y su hora.
- Abre la línea del error fatal y anota el primer archivo del proyecto en la traza.
- Compara las versiones PHP y WordPress soportadas por el componente con el entorno real.
- Reproduce la acción exacta en modo recuperación o staging antes de reactivar el componente.
Qué debe quedar verificado
- Ya no se necesita el modo recuperación.
- La función que lo provocaba opera con plugins y tema normales activos.
- Cron, formularios, checkout o la integración correspondiente terminan sin fatales.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →