Esta guía es para sitios WordPress autoalojados. Los cambios requieren permisos adecuados y una vuelta atrás segura. Si no conoces archivos, bases de datos y hosting, coordina el diagnóstico con tu proveedor o equipo de mantenimiento.
Registrar lo observado
Anota URL, mensaje exacto, primer momento observado con zona horaria y último cambio. Compara inicio, otra página y acceso. Registra los intentos realizados: un único fallo no demuestra una caída completa.
Copia y vuelta atrás
Antes de intervenir conserva archivos y base de datos si es posible, además de copias anteriores. Comprueba fechas y restauración. Una copia dañada o infectada puede servir al análisis; protégela por separado y no la consideres limpia.
Cambia una sola cosa y repite la misma petición. Usa una copia de pruebas para conflictos de plugins, temas y configuración. Desactivar no es borrar: tienda, formularios y seguridad pueden verse afectados. Documenta estado inicial y reversión.
Diagnóstico dirigido
01
Comparar navegador y red
Prueba una ventana privada, otro dispositivo y otra conexión. Si solo falla una vista, revisa caché y extensiones del navegador. Los fallos de DNS, TLS y WordPress necesitan comprobaciones distintas.
02
Identificar el síntoma
HTTP 500 indica un fallo del procesamiento del servidor. 502, 503 y 504 pueden implicar servicios intermedios o recursos. Ante errores de base de datos, comprueba disponibilidad con el host sin cambiar credenciales por intuición.
03
Revisar cambios recientes
La proximidad temporal no es prueba. Si funciona la administración, prueba el plugin sospechoso de forma controlada. Evita nuevas actualizaciones masivas; usa una copia para conflictos amplios y comprueba cada paso.
04
Si tampoco funciona el acceso
Busca un enlace de recuperación en el correo del administrador y spam. Recovery Mode pausa componentes para tu sesión, sin reparar automáticamente la web pública. Solicita ayuda para cambios de archivos si no hay acceso seguro.
05
Comprobar hosting y caché
Pide registros PHP y del servidor a la hora exacta y revisión de espacio, dominio, DNS y certificado. Vaciar caché puede retirar una página de error antigua, pero no repara PHP ni la base de datos.
Valorar la restauración
Una copia no sustituye investigar la causa. Revísala primero aislada si es posible. Restaurar puede eliminar pedidos, consultas y contenido recientes. Acuerda el alcance; tras un ataque no reincorpores archivos actuales sin comprobarlos.
Comprobar la corrección
Verifica la URL inicial, inicio, otras páginas y acceso. Prueba formularios y tienda en un entorno adecuado sin pedidos reales involuntarios. Vacía solo los niveles de caché afectados después de corregir. Documenta causa y resultado.
Cuándo pedir ayuda
Detén los cambios si la causa sigue sin aclararse, la reversión no es fiable o hay funciones críticas afectadas. Los indicios de malware requieren análisis de seguridad. No publiques registros completos, contraseñas, claves ni enlaces de recuperación.
Acordar alcance y costes →Mantenimiento tras la reparación
El núcleo WordPress, los plugins y los temas se actualizan cada semana, sin que el trabajo diario retrase las tareas necesarias. Mensuales, diarias o cada hora: el intervalo depende del plan. Las copias se guardan en servidores de la UE.
Las reparaciones y la limpieza de webs ya hackeadas se ofrecen por separado. Las licencias de pago no están incluidas.