Respuesta breve: si la web falló justo tras una actualización, esa actualización es la primera hipótesis, todavía no el diagnóstico. La nueva versión puede haber revelado una incompatibilidad que ya existía con tu PHP, el tema u otro plugin.
Los primeros cinco minutos
- Anota qué se actualizó, a qué versión y a qué hora.
- Comprueba si el fallo afecta a toda la web o a una ruta, y si carga
/wp-admin/. - Busca el correo de recuperación de WordPress en la bandeja del administrador.
- Confirma que existe una copia anterior a la actualización; si no, haz un snapshot del estado roto ahora.
Vuelve a entrar y lee el registro
Si la web carga, desactiva el componente actualizado desde el administrador. Si no, renombra su carpeta en /wp-content/plugins (o la del tema) por SFTP. Después activa WP_DEBUG_LOG y lee /wp-content/debug.log: nombra el archivo y la línea, lo que te dice si la actualización en sí falló o solo reveló una incompatibilidad previa.
¿Desactivar o revertir?
Desactivar restablece el acceso rápido pero puede dejar sin pagos, formularios o membresías. Revertir exige saber la versión anterior y si la actualización ejecutó una migración de base de datos: un rollback tras una migración completada puede corromper datos. Haz snapshot antes de revertir, porque el rollback es en sí un cambio que quizá debas deshacer.
Antes de volver a actualizar
La reparación no termina cuando la web carga. Sabe qué versión funciona, qué condición provocó el fallo y prueba la función concreta que controla el componente, no solo la portada. Para plugins críticos, reproduce la actualización en staging con una vía de rollback verificada para que una mala versión no llegue nunca antes a producción.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
La coincidencia temporal convierte la actualización en primera hipótesis, no en prueba. La respuesta segura registra versiones, conserva el estado roto y determina si cambiaron archivos, dependencias o datos.
- 1
Anota componente, versión anterior/nueva y hora exacta.
- 2
Captura el fatal y si afecta a admin, front o una ruta.
- 3
Revisa notas de versión y si se ejecutó una migración de base.
- 4
Prueba la vuelta atrás en snapshot o staging antes de tocar datos de producción.
Qué debe quedar verificado
- La función concreta opera en la versión elegida.
- Esquema de base y código son compatibles.
- La próxima actualización tiene prueba, copia y vuelta atrás.
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 →