Error 500 Internal Server Error: qué es, causas y cómo solucionarlo

El error 500 Internal Server Error es un código de estado HTTP que indica que el servidor encontró una condición inesperada que le impidió completar la solicitud del cliente. Es el código de error más genérico de la familia 5xx: el servidor detecta que algo ha fallado pero no puede o no quiere especificar qué. La causa casi siempre está en la capa de aplicación — un script PHP con errores, un archivo .htaccess mal configurado, permisos de archivo incorrectos o un plugin roto — y no en el hardware ni en la red.

Qué significa exactamente el error 500

El código 500 Internal Server Error está definido en el RFC 9110 (que reemplazó al RFC 7231 en junio de 2022) con esta descripción exacta: "The server encountered an unexpected condition that prevented it from fulfilling the request." (El servidor encontró una condición inesperada que le impidió cumplir la solicitud).

La palabra clave es "inesperada": el servidor no estaba preparado para lo que encontró durante el procesamiento de la solicitud. No es que el recurso no exista (eso sería un 404) ni que el cliente no tenga permiso (eso sería un 403). El servidor recibió una solicitud válida, empezó a procesarla y algo falló en el camino.

Lo que hace al 500 especialmente difícil de resolver sin información adicional es precisamente su genericidad: puede tener docenas de causas distintas. El servidor devuelve el mismo código 500 tanto si un plugin de WordPress tiene un error de sintaxis en PHP como si el límite de memoria está superado, o si los permisos del archivo son incorrectos. Los logs del servidor son imprescindibles para cualquier diagnóstico.

Error 500 vs otros errores de la familia 5xx

La distinción práctica más importante: si ves un 500, el error ocurre dentro del servidor que procesa la solicitud (PHP, la aplicación). Si ves un 502 o 504, hay un proxy o balanceador de carga delante del servidor de aplicación y el error ocurre en la comunicación entre ambos.

Causas más comunes del error 500

1. Errores en el archivo .htaccess

El .htaccess es un archivo de configuración de Apache que se aplica al directorio donde reside y a todos sus subdirectorios. Un error de sintaxis en cualquier línea de este archivo provoca un error 500 inmediato, antes de que Apache llegue siquiera a procesar el código PHP de la aplicación.

Las causas más frecuentes de errores en el .htaccess son:

• Directivas mal escritas o con errores tipográficos
• Reglas de reescritura (RewriteRule) con expresiones regulares inválidas
• Directivas que no están disponibles en la versión de Apache del servidor
• Archivos .htaccess de otros servidores copiados sin adaptar
• Caracteres invisibles o codificación incorrecta del archivo (especialmente si se editó en Windows)

Cómo confirmarlo: renombra el .htaccess a .htaccess_bak y recarga la página. Si el error 500 desaparece, el .htaccess es la causa. Si el sitio era WordPress y las páginas internas dan 404 después de renombrar el .htaccess, ve a Ajustes > Enlaces permanentes y guarda para regenerarlo automáticamente.

2. Permisos de archivos o directorios incorrectos

En servidores Linux, el usuario del servidor web (normalmente www-data en Ubuntu/Debian o apache en CentOS/AlmaLinux) necesita permisos específicos para leer y ejecutar los archivos de tu aplicación. Los permisos incorrectos pueden provocar un error 500 porque Apache o Nginx no puede leer el archivo que necesita servir.

Los permisos 777 (todos pueden leer, escribir y ejecutar) son especialmente peligrosos: algunos servidores y paneles de hosting (incluyendo ciertas configuraciones de Plesk) rechazan ejecutar archivos con permisos 777 como medida de seguridad, generando un error 500. Nunca uses 777 en producción.

Comandos para corregir permisos de forma masiva:

# Corregir todos los archivos de una instalación web:
find /ruta/a/tu/web -type f -exec chmod 644 {} \;
find /ruta/a/tu/web -type d -exec chmod 755 {} \;

# Corregir también el propietario:
sudo chown -R www-data:www-data /ruta/a/tu/web/

# Dar permisos especiales a wp-config.php:
chmod 640 /ruta/a/tu/web/wp-config.php

3. Errores de sintaxis en scripts PHP

Un error de sintaxis en cualquier archivo PHP que se incluye en la ejecución de una solicitud hace que PHP no pueda compilar el script y provoca un error 500. Las situaciones más frecuentes en las que ocurre esto son:

• Actualización de plugins o temas en WordPress que introduce incompatibilidades con la versión de PHP del servidor.
• Edición manual de archivos PHP a través del editor de código del panel de administración de WordPress o de un cliente FTP.
• Incompatibilidad de versión de PHP: un plugin desarrollado para PHP 7.x puede fallar con PHP 8.x si usa funciones obsoletas o sintaxis antigua.
• Truncación de archivos: si una subida FTP se interrumpió a mitad, el archivo PHP puede estar incompleto y generar un error de sintaxis.

Los errores de sintaxis PHP aparecen en los logs del servidor con mensajes como:

PHP Parse error: syntax error, unexpected token "echo" in /var/www/html/wp-content/plugins/mi-plugin/main.php on line 142
PHP Fatal error: Uncaught Error: Call to undefined function mi_funcion() in /var/www/html/wp-content/themes/mi-tema/functions.php on line 87

4. Límite de memoria PHP insuficiente

PHP tiene un límite de memoria por proceso configurado en el parámetro memory_limit de php.ini. Cuando un script necesita más memoria de la disponible, PHP lo interrumpe con un error fatal que el servidor convierte en un 500.

El mensaje en los logs es inequívoco:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20971520 bytes) in /var/www/html/wp-includes/class-wp-hook.php on line 307

El límite por defecto en la mayoría de instalaciones de PHP es de 128MB (134217728 bytes). Muchos sitios WordPress con múltiples plugins pesados necesitan 256MB o más. Formas de aumentar el memory_limit:

# Opción 1: En wp-config.php (solo para WordPress):
define('WP_MEMORY_LIMIT', '256M');

# Opción 2: En el .htaccess (en Apache con mod_php):
php_value memory_limit 256M

# Opción 3: En php.ini (requiere acceso al servidor o Plesk):
memory_limit = 256M

# Opción 4: En un archivo .user.ini en la raíz del sitio:
memory_limit = 256M

En Plesk, el memory_limit se configura desde Websites y Dominios > PHP > Configuración de PHP > memory_limit.

5. Timeout de ejecución PHP superado

El parámetro max_execution_time de PHP limita el tiempo máximo en segundos que puede ejecutarse un script. El valor por defecto es 30 segundos en la mayoría de instalaciones. Cuando un script supera ese límite, PHP lo interrumpe y el servidor devuelve un error 500.

Este error es especialmente frecuente en operaciones como importaciones masivas de datos, generación de thumbnails en WordPress al cambiar de tema, procesos de pago complejos en WooCommerce, y exportaciones o copias de seguridad dentro del panel de administración.

# En php.ini:
max_execution_time = 300

# En .htaccess (Apache con mod_php):
php_value max_execution_time 300

# En wp-config.php:
set_time_limit(300);

6. Problemas con la base de datos

Si la aplicación web no puede conectarse a la base de datos MySQL o hay un error en una consulta SQL, puede devolver un error 500 en lugar de un error más específico. En WordPress esto suele mostrarse como "Error al establecer conexión con la base de datos", pero dependiendo de la configuración del servidor, puede aparecer como un 500 genérico.

Causas frecuentes:

• Credenciales de base de datos incorrectas en wp-config.php o en el archivo de configuración de la aplicación.
• Servicio MySQL parado o con problemas: sudo systemctl status mysql
• Tabla de base de datos corrupta: necesita reparación con REPAIR TABLE nombre_tabla; en MySQL.
• Límite de conexiones simultáneas de MySQL superado bajo alta carga.

7. Configuración incorrecta del servidor virtual (VirtualHost)

En servidores con múltiples sitios web, un error en la configuración del VirtualHost de Apache o del bloque server de Nginx puede provocar un error 500 para ese sitio específico. Esto ocurre especialmente después de cambios en la configuración del servidor o de migraciones entre servidores con diferentes versiones de Apache/Nginx.

Cómo solucionar el error 500: proceso paso a paso

Paso 1: Consulta los logs del servidor

Es el primer paso obligatorio y el más importante. Los logs del servidor contienen el mensaje de error exacto, el archivo y la línea donde ocurrió el fallo. Sin los logs, cualquier intento de diagnóstico es ineficiente.

# Apache — ver los últimos 50 errores:
sudo tail -50 /var/log/apache2/error.log

# Nginx — ver los últimos 50 errores:
sudo tail -50 /var/log/nginx/error.log

# PHP-FPM — errores de PHP en Nginx+PHP-FPM:
sudo tail -50 /var/log/php8.2-fpm.log

# Buscar solo errores 500 en los logs de acceso de Apache:
sudo grep " 500 " /var/log/apache2/access.log | tail -20

# En tiempo real (útil para reproducir el error):
sudo tail -f /var/log/apache2/error.log

En Plesk: Websites y Dominios > [tu dominio] > Archivos de registro (Logs). Los errores PHP aparecerán con el mensaje exacto.

En WordPress: activa el modo debug añadiendo estas líneas en wp-config.php antes de /* That's all, stop editing! */:

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

Los errores se guardarán en wp-content/debug.log en lugar de mostrarse al público.

Paso 2: Revisa el archivo .htaccess

# Renombra el .htaccess para desactivarlo temporalmente:
mv .htaccess .htaccess_bak

# Recarga la página en el navegador.
# Si el error desaparece: el .htaccess era la causa.

# Para regenerar el .htaccess de WordPress:
# Ajustes > Enlaces permanentes > Guardar cambios

# Si el error persiste: restaura el .htaccess original:
mv .htaccess_bak .htaccess

Paso 3: Verifica y corrige los permisos de archivos

# Corregir permisos de toda la instalación web:
find /var/www/html/tu-sitio -type f -exec chmod 644 {} \;
find /var/www/html/tu-sitio -type d -exec chmod 755 {} \;
sudo chown -R www-data:www-data /var/www/html/tu-sitio/

# Verificar los permisos del archivo que aparece en los logs:
ls -la /var/www/html/tu-sitio/wp-config.php

# Verificar el usuario del servidor web:
ps aux | grep apache
ps aux | grep nginx

Paso 4: Aumenta el límite de memoria PHP

# En wp-config.php (WordPress):
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // Para el área de admin

# Verifica el memory_limit actual:
php -r "echo ini_get('memory_limit');"

# En el .htaccess:
php_value memory_limit 256M
php_value max_execution_time 300

Paso 5: Desactiva plugins y extensiones (WordPress)

Si no puedes acceder al panel de administración de WordPress y sospechas que un plugin es el culpable:

# Desactiva todos los plugins de una vez renombrando la carpeta:
mv wp-content/plugins wp-content/plugins_bak

# Recarga la página. Si el error desaparece:
# - Renombra la carpeta de vuelta:
mv wp-content/plugins_bak wp-content/plugins

# - Luego entra en el panel y activa los plugins de uno en uno
# - hasta que el error 500 vuelva a aparecer: ese es el plugin culpable.

Paso 6: Cambia al tema por defecto (WordPress)

Si el error 500 ocurre solo en el frontend pero puedes acceder al panel de administración, el problema puede estar en el tema activo:

# Desde el panel: Apariencia > Temas > activa Twenty Twenty-Four

# Si no puedes acceder al panel, cambia el tema por base de datos:
# En phpMyAdmin, tabla wp_options, busca la fila con option_name = 'template'
# y cambia su valor a 'twentytwentyfour'

Paso 7: Reinstala el núcleo de WordPress

Si ninguno de los pasos anteriores resuelve el error, reinstalar el núcleo de WordPress puede corregir archivos del sistema corruptos. Esta operación no elimina tus contenidos ni tu configuración: solo sobreescribe los archivos del núcleo (wp-admin/ y wp-includes/) con versiones limpias.

# Descarga WordPress manualmente y sobreescribe solo los archivos del núcleo:
# (NO sobreescribas wp-content/ ni wp-config.php)

# Con WP-CLI (si está disponible):
wp core download --skip-content --force

# Verificar la integridad de los archivos del núcleo:
wp core verify-checksums

Error 500 en entornos de producción: consideraciones adicionales

Ocultar la causa del error 500 al público

En un servidor de producción correctamente configurado, el error 500 que ve el usuario no debe mostrar ningún detalle técnico sobre la causa del fallo (como rutas de archivos, versiones de software o mensajes de error de PHP). Esos detalles solo deben aparecer en los logs del servidor, nunca en la respuesta pública.

En PHP, el parámetro display_errors debe estar en Off en producción:

# En php.ini (producción):
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log

# En desarrollo/staging:
display_errors = On

Configurar una página de error 500 personalizada

# En .htaccess (Apache):
ErrorDocument 500 /error-interno.html

# En Nginx (en el bloque server):
error_page 500 502 503 504 /error-interno.html;
location = /error-interno.html {
    root /var/www/html;
    internal;
}

Monitorización de errores 500

Un error 500 que aparece brevemente y se resuelve solo puede pasar desapercibido pero afectar a los usuarios. Las herramientas de monitorización externa (UptimeRobot, Pingdom, StatusCake) alertan inmediatamente cuando el sitio devuelve errores 5xx, permitiendo una respuesta rápida incluso si el error ocurre a las 3 de la mañana.

Error 500 en WordPress: resumen de causas y soluciones

WordPress merece una mención especial porque es el CMS más usado del mundo y también el más frecuente en los tickets de soporte relacionados con el error 500. Esta tabla resume los escenarios más habituales:

Preguntas frecuentes sobre el error 500

¿El error 500 es temporal o permanente?

Depende completamente de la causa. Si el error apareció de forma repentina después de un cambio (actualización, edición de archivo, cambio de configuración), es permanente hasta que corrijas la causa. Si es intermitente y aparece solo bajo alta carga, puede indicar un problema de recursos del servidor como memoria insuficiente o límite de conexiones de MySQL. El error 500 no desaparece solo salvo que la causa fuera un pico temporal de recursos que ya se disipó.

¿El error 500 afecta al SEO de mi web?

Sí, si dura más de unas horas. Google tolera errores transitorios (menos de 24 horas) porque entiende que los servidores pueden tener fallos puntuales. Pero si Googlebot encuentra errores 500 persistentes al intentar rastrear tu sitio, dejará de indexar el contenido afectado y puede reducir la frecuencia de rastreo de todo el sitio. Resuelve el error 500 lo antes posible para minimizar el impacto en el SEO.

¿Qué es lo primero que debo hacer cuando veo un error 500?

Lo primero es consultar los logs de error del servidor. Sin los logs, estás trabajando a ciegas y cualquier intento de solución es ensayo y error. Los logs contienen el mensaje exacto, el archivo y la línea donde ocurrió el fallo, lo que reduce el tiempo de diagnóstico de horas a minutos. En Plesk, accede desde Websites y Dominios > [tu dominio] > Logs. En acceso SSH directo: sudo tail -50 /var/log/apache2/error.log.

¿Puedo recuperar mi web sin perder el contenido?

Sí, siempre. El error 500 nunca borra el contenido de la base de datos. Todo tu contenido, usuarios, configuraciones y personalización están guardados en MySQL y están completamente seguros. El error 500 es un problema de código o configuración, no de datos. La reinstalación del núcleo de WordPress o la corrección del .htaccess no toca la base de datos.

¿Cómo diferencio si el error 500 viene de PHP, del .htaccess o de la base de datos?

Los logs del servidor son la respuesta definitiva. Los errores de PHP aparecen como "PHP Fatal error" o "PHP Parse error" con el nombre del archivo y la línea. Los errores de .htaccess aparecen como "AH00526: Syntax error on line X of /ruta/.htaccess" con la línea exacta del .htaccess que falló. Los errores de base de datos aparecen como mensajes de MySQL o como errores de conexión. Si los logs no muestran nada, habilita WP_DEBUG_LOG en WordPress.

¿Por qué el error 500 aparece solo en algunas páginas de WordPress?

Si el error 500 aparece solo en páginas específicas (por ejemplo, el carrito de WooCommerce, una categoría concreta o una página con un shortcode determinado), la causa es el código o los datos que se cargan específicamente en esas páginas. Lo más frecuente es un shortcode que genera un error, un widget con código PHP roto, o una consulta a la base de datos que falla con ciertos datos específicos. El debug.log con WP_DEBUG activado mostrará el archivo y la línea exactos del error.