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
Aislar la petición fallida
Compara inicio, otra página, acceso y acción exacta: guardar, subir o enviar. Antes de repetir un formulario o pedido, verifica si el proceso ya se completó.
02
Consultar el registro correcto
El código 500 no explica la causa. Facilita URL, hora, zona e identificador de petición si existe. Archivo PHP, memoria y directivas inválidas orientan de forma distinta. Sin entradas, comprueba registro y servicios intermedios.
03
Revisar plugins, tema y PHP
Relaciona el inicio con actualizaciones, código propio y cambios PHP. Prueba el componente sospechoso sobre una copia. Subir memoria no explica su consumo creciente; revisa causa y límites permitidos.
04
Conservar reglas del servidor
Una directiva .htaccess inválida puede afectar Apache; Nginx por sí solo no lee ese archivo. Sustituirlo a ciegas puede eliminar protección y redirecciones. Revisa con el host la regla concreta.
05
Examinar permisos y recursos
Propietarios, permisos, espacio y gestión PHP deben encajar con el alojamiento. Aplicar 777 indiscriminadamente no es una reparación. Tras corregir, repite la petición y verifica las demás funciones.
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.