Respuesta breve: un error 500 significa que el servidor web o PHP falló mientras generaba la página y se detuvo. El mensaje visible es genérico a propósito; la causa concreta está en el registro de errores del servidor o de PHP. Las listas genéricas de “solución del 500” adivinan lo que tu registro ya nombra.
Delimita el alcance y la hora primero
¿Falla toda la web o solo una URL? ¿Sigue cargando /wp-admin/? Anota cuándo empezó y qué cambió justo antes: una actualización, un despliegue, un cambio de versión de PHP o una regla nueva del servidor. Después haz un snapshot antes de cambiar nada, incluido el estado roto.
Lee el registro
Activa WP_DEBUG_LOG en wp-config.php (WP_DEBUG activo, WP_DEBUG_DISPLAY desactivado) y lee /wp-content/debug.log, además del registro de errores de tu hosting. Un 500 suele reducirse a uno de estos casos: un error fatal de PHP que nombra un archivo, memoria agotada, un tiempo de ejecución superado o una directiva rechazada de .htaccess.
La prueba del .htaccess
En Apache, un archivo de reescritura dañado es una causa clásica. Renombra .htaccess a .htaccess_old por SFTP y recarga. Si el 500 desaparece, el archivo era el problema, pero no dejes la web sin reglas: regenera unas limpias en Ajustes › Enlaces permanentes pulsando Guardar, lo que escribe un .htaccess por defecto nuevo.
Luego aísla plugins y tema
Si no es el .htaccess, renombra /wp-content/plugins a plugins_off; si la web vuelve, reactiva los plugins uno a uno para encontrar al culpable. Si los plugins están descartados, renombra la carpeta del tema activo para forzar un tema por defecto. Es la misma secuencia de aislamiento que resuelve la mayoría de los 500 a nivel de aplicación.
Memoria, tiempos y permisos
Si el registro apunta a la memoria, sube WP_MEMORY_LIMIT. Si es un timeout en una operación pesada —una importación o una copia—, esa tarea pertenece a la línea de comandos, no a una petición de navegador. Tras una migración, un 500 también puede ser por permisos incorrectos: los directorios suelen ir a 755 y los archivos a 644, nunca a 777.
Verifica y descarta un compromiso
Vuelve a pedir la URL que devolvía el 500 y comprueba el administrador, un formulario y cualquier tarea programada. Si el registro apunta a archivos del núcleo que no reconoces, o el 500 llega con redirecciones inesperadas, trátalo como un posible hackeo y no como un fallo de configuración.
CRITERIO DE INCIDENTE WP REPAIR
Cómo acotar el fallo sin adivinar
Un 500 es una respuesta genérica deliberada del servidor. La evidencia decisiva es el error emitido a la misma hora por el servidor web, PHP o la aplicación.
Anota URL exacta, método HTTP y hora.
Lee los logs del servidor web y PHP antes de cambiar .htaccess o plugins.
Separa fallos de una ruta de fallos globales y comportamiento con sesión de sin sesión.
Trata archivos del núcleo modificados o redirecciones extrañas como posible compromiso, no como simple configuración.
Qué debe quedar verificado
- La petición original devuelve el estado y contenido esperados.
- Los logs permanecen limpios al repetir la acción que lo provocaba.
- Funcionan los recorridos críticos y las tareas programadas.
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 →