Error 500 Internal Server Error: encontrar la causa en los logs y recuperar el sitio

Qué significa el error

Un error 500 es la respuesta de un servidor que recibió la petición, intentó ejecutarla y falló sin decir por qué. El servidor web funciona; la aplicación que tiene detrás (casi siempre PHP, con WordPress) arrancó y se detuvo por un error. El navegador muestra una página en blanco o « HTTP ERROR 500 »; WordPress, a veces, « Ha habido un error crítico en esta web » (o, según la variante de idioma, « Ha habido un error crítico en este sitio web »).

Diferencia con los códigos vecinos: un 502 Bad Gateway significa que el servidor web no pudo llegar a la aplicación (PHP-FPM detenido); un 503, que se niega a servir a propósito (sobrecarga, modo mantenimiento). Un 500 significa que la aplicación respondió, pero con un error. La causa casi siempre está en tus archivos o en tu configuración, y el motivo exacto está en un log.

Causas frecuentes

1. Un plugin o un tema tras una actualización. Un archivo incompatible con la versión de PHP, un conflicto entre dos plugins. La causa número uno en WordPress.
2. Un cambio de versión de PHP. Se pasa a una versión más reciente y una parte del sitio usa una sintaxis o un módulo retirado.
3. Un error de sintaxis en .htaccess. Una directiva mal escrita o un módulo de Apache que falta: Apache devuelve 500 antes incluso de arrancar PHP.
4. Permisos o propietario incorrectos. Tras una migración, hay carpetas que pertenecen a root, ilegibles para PHP, o demasiado abiertas.
5. Límite de memoria alcanzado. Una página necesita más que memory_limit.
6. Base de datos. Credenciales cambiadas, servidor MySQL o MariaDB detenido, disco lleno, tabla dañada.

Si eres visitante

No puedes reparar nada en un sitio que no es tuyo. Vuelve a cargarlo más tarde; si el error sigue, tiene que intervenir el propietario.

Si el sitio es tuyo: comprobar primero

Abre el Website down checker: muestra el código HTTP visto desde fuera. Después lee los logs del servidor:

# los últimos errores, los más recientes abajo
sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo journalctl -u php8.3-fpm -n 50

En un hosting compartido, el log suele llamarse error_log y está en la carpeta del sitio. Líneas típicas:

• PHP Fatal error: Uncaught Error: plugin o tema incompatible; la ruta del archivo dice cuál.
• PHP Parse error: un archivo modificado o una actualización incompleta.
• Allowed memory size of ... bytes exhausted: límite de memoria.
• .htaccess: Invalid command: error de sintaxis o módulo que falta.
• Permission denied: permisos o propietario.
• Error establishing a database connection: base de datos.

Soluciones en tu servidor o en tu hosting con SSH

1. Desactivar el plugin o el tema culpable

En WordPress, cambia el nombre de la carpeta del plugin: queda desactivado sin tocar la base de datos.

cd /var/www/example.com/wp-content/plugins
mv nombre-plugin nombre-plugin.off

Si no sabes cuál es, renombra toda la carpeta plugins: el sitio vuelve y reactivas los plugins uno por uno. Para el tema, cambia el nombre de su carpeta en wp-content/themes; WordPress pasa a un tema predeterminado. Con WP-CLI:

wp plugin list --status=active
wp plugin deactivate nombre-plugin

Para leer el error mientras buscas la causa, activa la depuración en wp-config.php (y quítala después); los errores van a wp-content/debug.log:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

2. Volver a la versión de PHP que funcionaba

php -v muestra la versión activa y ls /etc/php/ las instaladas; en un hosting compartido, la versión se elige en el panel del cliente. Vuelve a la versión anterior para recuperar el sitio y actualiza después el plugin culpable antes de volver a la nueva.

3. Reparar .htaccess

Cambia el nombre del archivo para probar: si el sitio vuelve (aunque sea con enlaces rotos), la causa está dentro.

mv .htaccess .htaccess.off
sudo apachectl -M | grep rewrite

Después vuelve a poner los bloques uno por uno. Un módulo que falta se activa con sudo a2enmod rewrite; luego recarga Apache.

4. Permisos y propietario

sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} +
sudo find /var/www/example.com -type f -exec chmod 644 {} +

Sustituye www-data por el usuario de tu pool de PHP-FPM.

5. Memoria

Sube memory_limit en el pool de PHP-FPM o en php.ini y recarga PHP-FPM. En WordPress, define('WP_MEMORY_LIMIT', '256M'); en wp-config.php hace lo mismo, dentro del límite del servidor. Comprueba con free -m que la memoria alcanza.

6. Base de datos

systemctl status mariadb
sudo systemctl start mariadb
df -h

Compara las credenciales de wp-config.php con las de la base de datos; wp db repair arregla una tabla dañada.

Si el problema está en tu proveedor de hosting

Si de tu lado no cambió nada y los logs están vacíos, envía esto:

Hola, mi sitio example.com devuelve « 500 Internal Server Error » desde aproximadamente las 9:30 (UTC). No he modificado nada por mi parte y el log de errores no muestra nada. ¿Hubo un cambio de versión de PHP o algún problema en el servidor de mi cuenta? ¿Pueden revisarlo e indicarme cuándo volverá a estar en línea el sitio?

Para que no vuelva a pasar

Un error 500 llega casi siempre justo después de una actualización, y una comprobación desde fuera lo ve en cuanto aparece, antes que tus visitantes. El monitoring de servidores vigila además el espacio en disco, la memoria y los servicios, y te avisa antes de que la base de datos se detenga por falta de espacio. Si el sitio es WordPress, las actualizaciones bajo demanda de WordPress, sin contrato, cubren el plugin incompatible antes de que rompa algo.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida corrige los pequeños errores de configuración, con copia de seguridad previa, a precio fijo; la intervención a fondo se encarga del plugin incompatible o de la versión de PHP, en bloques de 15 minutos, las 24 horas, todos los días.