Antes de empezar
- El mensaje de error describe un fallo, pero no identifica por sí solo su causa.
- Recuperar el acceso de administrador no demuestra que la web funcione para los visitantes.
- Antes de restaurar hay que proteger pedidos, reservas y cambios posteriores a la copia.
Tu página muestra un error crítico y no sabes si debes actualizar, desactivar plugins o recuperar una copia. La prioridad es evitar que la primera intervención añada un segundo problema. Una tienda puede seguir recibiendo avisos de pago mientras parte de la web falla; una página corporativa puede cargar la portada y tener bloqueado el formulario.
Esta guía está dirigida a quien necesita coordinar la recuperación con su proveedor. No es una receta para editar archivos del servidor sin diagnóstico ni una garantía de resolución inmediata.
Delimita qué ha dejado de funcionar
Anota la primera hora conocida del fallo, la URL afectada y la acción que lo provoca. Comprueba si ocurre en la portada, al entrar al administrador o solo al realizar una tarea. No repitas compras, reservas o envíos para «ver si ahora funciona»: podrías generar operaciones duplicadas.
Si otra persona mantiene la web, acuerda un único responsable de los cambios. Mientras investiga, evita instalar herramientas de reparación o lanzar actualizaciones en cadena. Cada modificación dificulta reconstruir qué pasó y qué intervención produjo una mejora.
Ejemplo hipotético: la portada abre, pero al seleccionar una variante de producto aparece el error. Informar de esa secuencia permite investigar el proceso afectado; decir únicamente «la web está caída» puede llevar a comprobar una página que sí funciona.
El modo de recuperación ayuda, pero no es la reparación
Según la documentación de WordPress, ciertos errores fatales de PHP pueden activar el modo de recuperación y generar un correo al administrador. Este acceso especial permite investigar componentes problemáticos; su pausa se aplica a esa sesión de administración. Poder entrar al panel no prueba que los clientes ya puedan usar la web.
Revisa el buzón administrativo y el correo no deseado. Si llega un aviso, verifica el remitente y el dominio de destino antes de introducir credenciales. No publiques el enlace de recuperación ni lo pegues en un formulario abierto. Si no llega, tampoco concluyas que no existe un error: la entrega del correo puede fallar. El alojamiento o el responsable técnico pueden revisar los registros por otra vía.
Prepara un parte que permita actuar
Envía por el canal acordado un resumen breve:
- URL y mensaje visible, con una captura sin datos personales;
- hora aproximada de inicio y última vez que funcionó;
- cambios recientes conocidos: plugin, tema, código o configuración del alojamiento;
- funciones afectadas y las que todavía funcionan;
- existencia y fecha de la última copia disponible;
- si hay pedidos, reservas o solicitudes posteriores que deban conservarse.
No envíes contraseñas, claves API, listados de compradores ni archivos de configuración completos. Si se necesitan accesos, acuerda su entrega segura y el alcance de la intervención. Puedes usar nuestra guía para organizar accesos de mantenimiento sin mezclar el parte del fallo con las credenciales.
Qué debe investigar el técnico antes de cambiar cosas
La coincidencia con una actualización es una pista, no una prueba definitiva. Interesa relacionar el momento del fallo con los registros y reproducir la acción afectada en condiciones controladas. Un aviso antiguo no tiene por qué explicar el error actual.
La guía oficial de diagnóstico describe herramientas para registrar errores y recomienda usarlas en entornos de pruebas, con una copia adecuada antes de modificar la web. No actives la visualización pública de errores para enviarnos una captura: puede revelar información interna. Pide al técnico que gestione el registro de forma privada y retire la instrumentación temporal al terminar.
La intervención puede requerir corregir una incompatibilidad, sustituir un componente o ajustar código. Desactivar un plugin puede servir para aislar el fallo, pero también retirar una función del negocio; hay que valorar esa consecuencia antes de hacerlo.
Restaurar no debe borrar lo que ocurrió después
La documentación de copias de WordPress distingue archivos y base de datos. Una copia de una sola parte no garantiza una recuperación completa y coherente.
Antes de autorizar la restauración, pide una respuesta concreta: ¿qué fecha se recuperará, qué elementos se reemplazarán y cómo se conservarán los cambios posteriores? En WooCommerce, revisa especialmente los pedidos recientes y su relación con pagos y stock. En una web de reservas, las citas nuevas también importan. No reemplaces toda la base de datos solo porque existe un respaldo disponible.
Conviene conservar además el estado previo a la intervención y acordar cómo volver atrás si el intento no resuelve el problema. La decisión entre restaurar y corregir debe responder al diagnóstico, no a cuál parece más rápida desde fuera.
Cuándo dar la incidencia por cerrada
Solicita comprobaciones sobre las funciones afectadas, no únicamente una captura de la portada:
- La acción que provocaba el error vuelve a funcionar fuera de la sesión de recuperación.
- Las páginas y funciones dependientes del componente intervenido se han revisado.
- No se han perdido pedidos, reservas o cambios que debían conservarse.
- Los registros revisados no reproducen el mismo fallo al ejecutar la prueba acordada.
- Quedan documentados la actuación, las limitaciones y cualquier tarea pendiente.
Las pruebas con efectos reales deben acordarse antes: no hacer cobros ni enviar comunicaciones a clientes sin autorización. Que desaparezca el mensaje no demuestra por sí solo que todo el recorrido comercial esté recuperado.
Si necesitas ayuda con el error de tu web
En nuestro servicio de reparación WordPress valoramos el problema y la intervención necesaria. Cuéntanos qué ocurre, desde cuándo y qué parte del negocio está afectada. Si ya tienes mantenimiento contratado, revisaremos el alcance y las horas disponibles; cualquier trabajo adicional se valora antes de realizarlo.
No hace falta conocer la causa para pedir ayuda. Una descripción precisa y conservar el estado de la web aportan más al diagnóstico que probar varias soluciones a la vez.
Fuentes y documentación
Referencias para ampliar los aspectos técnicos. El alcance de cada servicio debe concretarse en su propuesta.
- WordPress: modo de recuperación · consultada el 19 de octubre de 2026
- WordPress: diagnóstico y registro de errores · consultada el 19 de octubre de 2026
- WordPress: copias de archivos y base de datos · consultada el 19 de octubre de 2026