Guía para decidir mejor
Error 500 en WordPress: diagnóstico paso a paso
Un 500 no identifica por sí solo la causa. Conserva el estado, consulta los logs y revierte el cambio responsable con seguridad.
Un error 500 en WordPress significa que una petición falló en el servidor, no que sepas ya qué componente es culpable. Puede venir de PHP, plugins, tema, reglas web, permisos o recursos. Confirma el código HTTP, conserva una copia y busca el primer error registrado a la hora exacta antes de cambiar archivos o restaurar la base de datos.
Delimita el fallo
- Prueba portada, una URL interior y /wp-admin/ desde otra conexión. Anota hora, URL, respuesta HTTP y si empezó tras una actualización o cambio de PHP.
- Consulta los logs del servidor web y PHP en el panel o con el administrador. Un 500 mostrado por proxy puede ocultar un fatal PHP u otra causa; el mensaje del navegador no basta.
- Haz copia actual de archivos y base de datos. Si sigue entrando contenido o pedidos, no restaures a ciegas una copia antigua: podrías perder cambios nuevos.
- Si el administrador aún funciona, revisa Salud del sitio y cambios recientes. En staging, reproduce con la misma versión de PHP, plugins y tema.
Pruebas según la evidencia
Si el log señala un plugin, prueba a desactivarlo o revertir su actualización en staging y comprueba la URL que fallaba. Si el problema coincide con una regla .htaccess, conserva una copia y prueba una configuración mínima adecuada al servidor; en NGINX esa ruta no funciona igual. Si faltan permisos o archivos, compara con el despliegue anterior, sin cambiar permisos de todo el sitio indiscriminadamente. La guía oficial de errores de WordPress enumera estas familias de causas.
Para obtener una traza más precisa, WordPress documenta WP_DEBUG_LOG. Prefiere staging y no muestres errores ni logs al público: pueden contener rutas o datos sensibles. Retira el acceso al log al terminar. Si el log indica memoria agotada, localiza la petición o plugin que consume recursos antes de aumentar el límite; un límite mayor puede ocultar el problema.
Ejemplo y cierre seguro
Una actualización de plugin introduce una función incompatible con la versión PHP. El log cita el archivo y la línea; revertir esa versión en staging devuelve HTTP 200. Ahora puedes planificar la versión compatible o consultar al proveedor del plugin. En cambio, si todas las URL fallan y el web server registra un error de configuración, cambiar plugins no servirá.
Después de corregir, prueba páginas públicas, administrador, formularios y checkout. Vigila que el error no reaparezca. Si el síntoma es mantenimiento o indisponibilidad temporal, compara con la guía de 503; si WordPress muestra su mensaje de base de datos, usa ese diagnóstico. Comparte con soporte la hora y el texto del error, nunca contraseñas.
Una pantalla blanca puede esconder este código u otro fallo; si la web pública sigue visible pero solo falla wp-admin, delimita primero esa ruta y su log.
Si la traza indica Allowed memory size exhausted, investiga la petición y el límite PHP efectivo antes de aumentar memoria de manera general.