1Primeros diez minutos

1. Confirma si el fallo afecta a todos o solo a tu dispositivo.
2. Anota hora, URL, mensaje y acción anterior.
3. Comprueba estado del hosting, dominio y certificado.
4. Evita actualizar, reinstalar o borrar sin copia.
5. Informa al responsable y pausa campañas si el destino no funciona.
6. Si hay indicios de ataque, cambia accesos desde un equipo seguro y conserva logs.

2Determina el alcance

Prueba home, una página interna, login, formulario y checkout. Abre navegación privada y otra conexión. Utiliza una comprobación externa para distinguir caché local de caída real. Revisa si falla el dominio, DNS, SSL, servidor, PHP, base de datos o aplicación.

3Web completamente caída

Comprueba panel del hosting, recursos, mantenimiento, DNS y renovación del dominio. Un límite de disco o procesos puede dejar la web inaccesible. Revisa logs y cambios recientes. Contacta con hosting aportando hora y error exacto.

No cambies DNS como primera medida: su propagación dificulta el diagnóstico.

4Error 500

Indica un fallo interno genérico. Revisa log de errores, versión de PHP, memoria, .htaccess, plugin o tema actualizado. Si el problema empezó tras un cambio, revierte solo ese cambio mediante staging, copia o acceso a archivos.

Renombrar temporalmente la carpeta de un plugin puede desactivarlo cuando no entra el panel, pero hazlo con copia y documenta. No borres la carpeta.

5Pantalla blanca o error crítico

WordPress puede enviar un correo de modo de recuperación. Comprueba spam y destinatario de administración. Activa depuración de forma controlada para registrar errores, no para mostrarlos públicamente. Identifica plugin, tema o código señalado.

Oculta datos sensibles de cualquier captura compartida.

6Conflicto de plugins

Si puedes trabajar en staging, desactiva plugins y actívalos uno a uno. En producción, empieza por el cambio reciente o el componente indicado en logs. Comprueba compatibilidad con WordPress, PHP y tema.

No mantengas dos plugins que hacen la misma caché, seguridad o redirección.

7Problema del tema o maquetador

Un tema o Elementor puede romper estilos, editor o frontend tras actualización. Limpia caché, regenera CSS si la herramienta lo permite y revisa consola. Cambiar a un tema por defecto es una prueba útil en staging, pero en producción puede alterar el sitio.

8Error de conexión con base de datos

Comprueba servicio, credenciales, host, espacio y corrupción. No publiques el contenido de wp-config.php. El hosting puede confirmar si MySQL está caído o si existen límites. Reparar tablas sin diagnóstico puede ocultar un problema mayor.

9Administrador bloqueado

Revisa URL, cookies, plugin de seguridad, firewall y usuario. Utiliza recuperación oficial o acceso de hosting. No crees cuentas administrativas permanentes sin control. Después revoca accesos temporales y activa doble factor.

10Formulario que no envía

Puede mostrar éxito sin entregar correo. Revisa registro de envíos, spam, dirección remitente, DNS del correo, SMTP y errores. Utiliza un proveedor transaccional cuando la entrega sea importante y configura autenticación del dominio.

Prueba el formulario completo y no solo el botón.

11Sospecha de hackeo

Indicadores: usuarios desconocidos, redirecciones, archivos modificados, spam, alertas de hosting o Search Console. Aísla si es necesario, conserva copia forense, cambia credenciales desde un equipo limpio y solicita revisión. Eliminar un archivo visible no garantiza limpieza.

Después actualiza, rota claves, revisa usuarios, plugins, tema, cron, base de datos, logs y puertas traseras. Notifica incidentes según obligaciones aplicables.

12Restaurar una copia

Confirma fecha, contenido y causa. Restaurar una copia vulnerable puede devolver el fallo; restaurar una muy antigua puede perder pedidos o formularios. Conserva la versión actual antes de reemplazar y separa archivos de base de datos.

Valida web, login, formularios, pedidos, analítica y copias después.

13Lo que no debes hacer

• Copiar un wp-config.php de internet.
• Compartir contraseñas por chat o email.
• Instalar varios plugins de reparación.
• Borrar carpetas para "probar".
• Actualizar todo durante el incidente sin copia.
• Ocultar la caída mientras siguen campañas activas.
• Restaurar sin comprobar la fecha de datos.
• Declarar resuelto sin revisar causa.

14Información que necesita soporte

• Dominio y URL afectada.
• Hora y zona horaria.
• Mensaje o código exacto.
• Cambios previos.
• Alcance y dispositivos.
• Logs relevantes sin secretos.
• Acceso seguro y temporal cuando sea necesario.
• Copias disponibles y última restauración probada.

15Prevención después de la emergencia

Configura copias externas automáticas, prueba restauración, monitoriza disponibilidad, actualiza con staging, reduce plugins, usa doble factor y limita administradores. Documenta hosting, DNS, dominio, correo y responsables. Revisa formularios y compra de forma periódica.

Un plan de mantenimiento no elimina incidentes, pero reduce tiempo de detección y recuperación.

Conclusión

En una emergencia WordPress, la calma es una herramienta técnica. Registra, protege, diagnostica por capas, cambia una cosa y valida. Resolver el síntoma sin encontrar la causa deja la web preparada para repetir el fallo. Después convierte lo aprendido en copias, monitorización y un procedimiento claro.