Error 500 en WordPress: solución paso a paso

El error 500 en WordPress es uno de los problemas más frustrantes que puede encontrar un administrador de sitio web: el sitio muestra una pantalla en blanco o el mensaje "Ha habido un error crítico en este sitio web" sin ninguna indicación de qué ha fallado ni dónde. A diferencia del error 500 genérico, en WordPress las causas son casi siempre identificables y corregibles sin conocimientos avanzados de servidores: un plugin incompatible, el archivo .htaccess corrupto, el límite de memoria PHP insuficiente o un error en el tema activo son los culpables en más del 95% de los casos. El contenido de la base de datos nunca se pierde con un error 500: todo está intacto, el problema está en el código o la configuración.

Por qué el error 500 en WordPress es especialmente difícil de diagnosticar

En WordPress, el error 500 tiene una particularidad que lo hace más difícil de diagnosticar que en otras aplicaciones web: WordPress tiene múltiples capas de código que se ejecutan en cada solicitud (el núcleo, los plugins activos, el tema, los hooks y filtros, las consultas a la base de datos), y cualquiera de ellas puede fallar de forma silenciosa y mostrar la misma pantalla en blanco sin ningún mensaje de error al usuario.

Por seguridad, WordPress en modo producción tiene desactivada la visualización de errores PHP al público. Esto significa que aunque PHP detecte el error con toda precisión (archivo, línea y tipo de error), no lo muestra en el navegador: simplemente muestra la pantalla en blanco o el mensaje genérico de error crítico.

La solución a este problema tiene siempre el mismo primer paso: activar el modo debug de WordPress para ver el error real. Sin esa información, cualquier diagnóstico es puro ensayo y error.

El error 500 en WordPress y la "Pantalla Blanca de la Muerte" (WSOD)

La comunidad WordPress llama coloquialmente White Screen of Death (WSOD, Pantalla Blanca de la Muerte) al error 500 que se manifiesta como una pantalla completamente en blanco, sin ningún mensaje, sin ningún elemento visual. Es la forma más común en que aparece el error 500 en WordPress porque:

• WordPress captura los errores PHP fatales antes de que lleguen al navegador.
• En modo producción (configuración por defecto), no muestra esos errores al público.
• Si el error ocurre antes de que WordPress pueda cargar su propio sistema de manejo de errores, el resultado es simplemente una respuesta vacía.

Desde WordPress 5.2, el sistema de recuperación de errores fatales (también llamado "modo de recuperación") intenta detectar los errores fatales y mostrar un mensaje más informativo, ofreciendo también un enlace de recuperación enviado al email del administrador. Sin embargo, si el error ocurre demasiado pronto en el proceso de arranque de WordPress (antes de que el sistema de correo esté disponible), puede seguir apareciendo la pantalla en blanco.

Diagnóstico rápido: dónde aparece el error 500

Antes de empezar a buscar la causa, determina exactamente dónde aparece el error 500. La ubicación del error orienta directamente hacia la causa más probable:

Paso 1: Activa el modo debug de WordPress

Es el primer paso obligatorio en cualquier diagnóstico de error 500 en WordPress. Sin el modo debug activado, estás trabajando completamente a ciegas.

Accede al archivo wp-config.php en la raíz de tu instalación de WordPress mediante FTP, SFTP o el administrador de archivos de Plesk. Busca la línea define( 'WP_DEBUG', false ); y reemplázala con estas tres líneas:

// Activar el modo debug de WordPress — añadir ANTES de "/* That's all, stop editing! */"

define( 'WP_DEBUG', true );           // Activa la detección de errores PHP
define( 'WP_DEBUG_LOG', true );       // Guarda los errores en wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // NO muestra los errores al público en el navegador

Con esta configuración, WordPress guardará todos los errores PHP en el archivo wp-content/debug.log sin mostrarlos al público. Accede a ese archivo y busca los mensajes de error más recientes:

# Si tienes acceso SSH al servidor:
tail -50 /var/www/html/tudominio/wp-content/debug.log

# Buscar solo los errores fatales (los que causan el error 500):
grep -i "Fatal error\|Parse error\|Uncaught" /var/www/html/tudominio/wp-content/debug.log | tail -20

El debug.log te dirá exactamente qué archivo y qué línea causa el error. Un ejemplo típico:

[03-Jun-2026 10:45:23 UTC] PHP Fatal error: Uncaught Error: Call to undefined function mi_funcion_personalizada()
in /var/www/html/wp-content/plugins/mi-plugin/includes/clase-principal.php on line 247

[03-Jun-2026 10:45:31 UTC] PHP Parse error: syntax error, unexpected token "return"
in /var/www/html/wp-content/themes/mi-tema/functions.php on line 89

Con esta información, ya sabes exactamente qué archivo y qué línea está causando el error. El diagnóstico pasa de "algo falla en algún sitio" a "el plugin mi-plugin falla en la línea 247 de clase-principal.php".

En Plesk: si no tienes acceso SSH, ve a Websites y Dominios > [tu dominio] > Archivos de registro (Logs). Los errores PHP aparecen en el log de error del dominio con el mensaje exacto y el archivo donde ocurrió el fallo.

Paso 2: Desactiva todos los plugins

Los plugins incompatibles son la causa número uno del error 500 en WordPress, especialmente después de actualizaciones. Si el debug.log señala un plugin específico, desactívalo directamente. Si el log no está disponible o no es concluyente, desactiva todos los plugins de una vez:

Opción A: Desde el panel de administración (si puedes acceder)

1. Ve a Plugins > Plugins instalados.
2. Selecciona todos los plugins marcando la casilla del encabezado de la tabla.
3. En el menú desplegable "Acciones en lote" selecciona "Desactivar".
4. Haz clic en "Aplicar".
5. Recarga el frontend del sitio. Si el error desaparece, reactiva los plugins de uno en uno hasta que el error vuelva a aparecer: ese es el plugin culpable.

Opción B: Por FTP/SFTP o administrador de archivos (si no puedes acceder al panel)

# Renombra la carpeta completa de plugins para desactivarlos todos a la vez:
# En el administrador de archivos de Plesk o por FTP:
# Renombra /wp-content/plugins/ a /wp-content/plugins_bak/

# Por SSH:
mv /var/www/html/tudominio/wp-content/plugins \
   /var/www/html/tudominio/wp-content/plugins_bak

# Si el error desaparece: el problema está en un plugin.
# Restaura la carpeta original:
mv /var/www/html/tudominio/wp-content/plugins_bak \
   /var/www/html/tudominio/wp-content/plugins

# Luego activa los plugins de uno en uno desde el panel de administración
# hasta que el error vuelva a reproducirse

Opción C: Con WP-CLI (la más rápida si tienes acceso SSH)

# Listar todos los plugins activos:
wp plugin list --status=active

# Desactivar todos los plugins de una vez:
wp plugin deactivate --all

# Recargar el sitio. Si funciona, activar de uno en uno:
wp plugin activate nombre-del-plugin

# Cuando el error reaparezca, ese es el plugin culpable:
wp plugin list --status=active  # Ver cuál fue el último en activarse

Paso 3: Cambia al tema por defecto de WordPress

Si desactivar todos los plugins no resolvió el error, el problema puede estar en el tema activo. El tema de WordPress puede tener errores de sintaxis en su functions.php, incompatibilidades con la versión actual de PHP o conflictos con el núcleo de WordPress.

Opción A: Desde el panel de administración

1. Ve a Apariencia > Temas.
2. Activa cualquier tema por defecto de WordPress: Twenty Twenty-Four, Twenty Twenty-Three o Twenty Twenty-Two.
3. Recarga el frontend. Si el error desaparece, el tema activo era el culpable.

Opción B: Por FTP/SFTP o SSH (si no puedes acceder al panel)

# Renombra el directorio del tema activo para que WordPress use el tema por defecto:
mv /var/www/html/tudominio/wp-content/themes/mi-tema \
   /var/www/html/tudominio/wp-content/themes/mi-tema_bak

# Por WP-CLI:
wp theme activate twentytwentyfour

# Si el error desaparece: el problema está en el functions.php del tema
# o en algún archivo de plantilla del tema

Opción C: Cambiar el tema directamente en la base de datos

# Si no puedes acceder ni al panel ni al SSH, puedes cambiar el tema
# directamente desde phpMyAdmin:
# 1. Abre phpMyAdmin desde el panel de Plesk
# 2. Selecciona la base de datos de WordPress
# 3. Busca la tabla wp_options
# 4. Busca las filas con option_name = 'template' y 'stylesheet'
# 5. Cambia su valor a 'twentytwentyfour'

# Por WP-CLI con MySQL:
wp db query "UPDATE wp_options SET option_value='twentytwentyfour'
WHERE option_name IN ('template','stylesheet');"

Paso 4: Revisa y regenera el archivo .htaccess

Un archivo .htaccess corrupto o con errores de sintaxis es una de las causas más frecuentes de error 500 en WordPress, especialmente después de migraciones, cambios de servidor o ediciones manuales del archivo.

# Renombra el .htaccess actual para desactivarlo:
mv /var/www/html/tudominio/.htaccess \
   /var/www/html/tudominio/.htaccess_bak

# Crea un .htaccess mínimo para WordPress:
cat > /var/www/html/tudominio/.htaccess << 'EOF'
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
EOF

# Si el error desaparece: el .htaccess original tenía un problema.
# Desde el panel de WordPress, ve a:
# Ajustes > Enlaces permanentes > Guardar cambios
# Esto regenera automáticamente el .htaccess con las reglas correctas.

Si el .htaccess tenía reglas personalizadas (redirecciones, cabeceras de seguridad, reglas de caché), añádelas de nuevo de una en una, verificando después de cada añadido que el sitio sigue funcionando, para identificar cuál de las reglas causaba el error.

Paso 5: Aumenta los límites de memoria PHP

WordPress y sus plugins, especialmente en instalaciones con muchos plugins activos, pueden necesitar más memoria PHP de la configurada por defecto. El error "Allowed memory size exhausted" en los logs es el indicador inequívoco, pero también puede producirse el error 500 sin ese mensaje si el límite se supera en un momento muy específico del proceso de carga.

# Opción 1: En wp-config.php (método más directo y compatible):
define( 'WP_MEMORY_LIMIT', '256M' );       // Memoria para el frontend
define( 'WP_MAX_MEMORY_LIMIT', '512M' );   // Memoria para el panel de administración

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

# Opción 3: En un archivo .user.ini en la raíz (funciona con PHP-FPM):
memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

# Verificar el límite actual desde WordPress:
# Añadir temporalmente en functions.php del tema:
add_action('init', function() {
    if (current_user_can('administrator')) {
        echo 'Memory limit: ' . WP_MEMORY_LIMIT;
        echo ' | PHP limit: ' . ini_get('memory_limit');
    }
});

En Plesk: ve a Websites y Dominios > [tu dominio] > PHP > Configuración de PHP. Aquí puedes cambiar memory_limit, max_execution_time, upload_max_filesize y post_max_size desde la interfaz gráfica sin editar ningún archivo.

Paso 6: Verifica la compatibilidad con la versión de PHP

Una de las causas más frecuentes de error 500 en WordPress es la incompatibilidad entre la versión de PHP del servidor y alguno de los plugins o el tema activo. PHP 8.0, 8.1, 8.2 y 8.3 introdujeron cambios importantes que rompieron la compatibilidad con plugins y temas desarrollados para PHP 7.x.

# Verificar la versión de PHP activa en el servidor:
php --version

# Verificar la versión de PHP que usa el sitio específico en Plesk:
# Websites y Dominios > [tu dominio] > PHP > ver la versión activa

# Verificar las extensiones de PHP disponibles (algunas son requeridas por WordPress):
php -m | grep -E "curl|gd|imagick|mbstring|mysqli|openssl|zip"

# Si una extensión requerida no está disponible, instalarla:
sudo apt install php8.2-curl php8.2-gd php8.2-mbstring php8.2-zip
sudo systemctl restart php8.2-fpm

Si el error 500 apareció después de actualizar la versión de PHP del servidor, la solución más rápida es cambiar temporalmente el sitio a una versión anterior de PHP (por ejemplo, de PHP 8.2 a PHP 8.1) mientras identificas qué plugin o tema no es compatible con la nueva versión. En Plesk, el cambio de versión de PHP se hace desde Websites y Dominios > [tu dominio] > PHP.

Paso 7: Reinstala el núcleo de WordPress

Si ninguno de los pasos anteriores resuelve el error, puede que algunos archivos del núcleo de WordPress estén corruptos o modificados. La reinstalación del núcleo sobreescribe solo los archivos del núcleo (wp-admin/ y wp-includes/) con versiones limpias de la versión actual, sin tocar wp-content/ ni wp-config.php, lo que significa que todos tus contenidos, configuraciones y personalizaciones están completamente seguros.

# Con WP-CLI (método recomendado):
# Verificar la integridad de los archivos del núcleo:
wp core verify-checksums

# Ver qué archivos han sido modificados respecto a la versión oficial:
wp core verify-checksums 2>&1 | grep -v "Success"

# Reinstalar el núcleo de WordPress (sin tocar wp-content ni wp-config.php):
wp core download --skip-content --force

# Verificar la versión instalada:
wp core version

# Sin WP-CLI — método manual:
# 1. Descarga la versión exacta de WordPress que tienes instalada desde wordpress.org
# 2. Descomprime el archivo descargado
# 3. Sube por FTP los directorios wp-admin/ y wp-includes/ sobreescribiendo los existentes
# 4. Sube también todos los archivos PHP de la raíz (wp-login.php, wp-cron.php, etc.)
#    EXCEPTO wp-config.php — ese no lo toques nunca
# 5. NO subas ni sobreescribas wp-content/ bajo ningún concepto

Paso 8: Verifica la base de datos

Aunque el error 500 raramente viene de la base de datos directamente (los problemas de base de datos suelen mostrar mensajes específicos como "Error al establecer conexión con la base de datos"), en algunos casos tablas corruptas pueden causar errores fatales en PHP que se manifiestan como error 500.

# Verificar y reparar las tablas de WordPress con WP-CLI:
wp db check
wp db repair

# Optimizar las tablas (libera espacio y mejora el rendimiento):
wp db optimize

# Verificar las credenciales de base de datos en wp-config.php:
wp config get DB_NAME
wp config get DB_USER
wp config get DB_HOST

# Probar la conexión a la base de datos:
wp db cli -- --execute="SELECT 1;"

# Ver el tamaño de cada tabla (útil para detectar tablas anómalamente grandes):
wp db query "SELECT table_name, ROUND((data_length+index_length)/1024/1024,2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC;"

Casos especiales: error 500 en contextos específicos de WordPress

Error 500 al actualizar WordPress o plugins

Si el error 500 aparece exactamente durante o inmediatamente después de una actualización, el proceso de actualización modificó archivos que causaron un conflicto. Las opciones son:

1. Restaurar desde la copia de seguridad previa a la actualización (siempre debes tener un backup antes de actualizar).
2. Revertir el plugin o tema a la versión anterior: descarga la versión anterior desde el repositorio de WordPress (wordpress.org/plugins/nombre-plugin/developers/) y sobreescribe los archivos del plugin problemático.
3. Desactivar el plugin o tema que falló (como se describió en el Paso 2 y 3) hasta que el desarrollador publique una versión compatible.

Error 500 solo en el panel de administración de WordPress

Si el frontend funciona correctamente pero el panel de administración (/wp-admin/) da error 500, la causa más frecuente es el límite de memoria PHP. El panel de administración de WordPress carga muchos más recursos que el frontend, especialmente si hay plugins activos con pantallas de configuración complejas.

# Aumentar específicamente el límite de memoria para el área de administración:
# En wp-config.php:
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

# Verificar cuánta memoria usa el panel actualmente:
# Añadir temporalmente al principio de wp-admin/admin.php:
ini_set('display_errors', 1);
error_reporting(E_ALL);
# (Recuerda eliminar estas líneas después del diagnóstico)

Error 500 solo al procesar pagos en WooCommerce

Este error específico casi siempre está relacionado con el timeout de PHP durante el proceso de pago, que puede ser más lento de lo habitual si el gateway de pago tiene latencia o si hay validaciones complejas. También puede ser causado por conflictos entre el plugin del gateway de pago y otros plugins activos.

# Aumentar el timeout específicamente para WooCommerce:
# En wp-config.php:
define( 'WC_GATEWAY_TIMEOUT', 300 );  // Timeout específico de WooCommerce

# Aumentar el timeout general de PHP:
define( 'WP_MEMORY_LIMIT', '512M' );

# En el .htaccess:
php_value max_execution_time 300
php_value max_input_time 300

Error 500 en la API REST de WordPress

Si el error 500 afecta solo a las llamadas a la API REST de WordPress (URLs del tipo /wp-json/), la causa puede ser un plugin que modifica la API REST de forma incorrecta, o la API REST está desactivada por alguna regla en el .htaccess o en la configuración del servidor.

# Verificar si la API REST de WordPress funciona:
curl https://tudominio.com/wp-json/wp/v2/posts

# Si devuelve 500, verificar en el debug.log qué error ocurre al llamar a la API

# Si la API REST está bloqueada por el .htaccess, verifica si hay reglas
# que bloqueen las URLs /wp-json/:
grep -i "wp-json\|rest_api" /var/www/html/tudominio/.htaccess

Lista de verificación completa para resolver el error 500 en WordPress

Cómo prevenir el error 500 en WordPress

La mayoría de los errores 500 en WordPress son evitables con unas buenas prácticas de mantenimiento:

• Haz siempre una copia de seguridad antes de actualizar cualquier componente: WordPress, plugins o temas. Si algo sale mal, puedes restaurar en minutos.
• Prueba las actualizaciones en un entorno de staging antes de aplicarlas en producción. Plesk permite crear entornos de staging con un clic.
• Mantén un entorno PHP actualizado pero compatible: revisa la compatibilidad de todos tus plugins activos con la versión de PHP antes de actualizar el servidor.
• Limita el número de plugins activos: cada plugin añade código que se ejecuta en cada solicitud. Los sitios con muchos plugins son más propensos a conflictos y errores de memoria.
• Configura alertas de monitorización: herramientas como UptimeRobot o Pingdom alertan inmediatamente cuando el sitio devuelve un error 500, permitiendo una respuesta rápida.
• Mantén el debug.log activado (con WP_DEBUG_DISPLAY = false) para tener un registro histórico de advertencias y errores antes de que se conviertan en errores fatales.

Preguntas frecuentes sobre el error 500 en WordPress

¿El error 500 en WordPress puede hacer que pierda todo el contenido del sitio?

No. El error 500 en WordPress nunca borra ni modifica el contenido de la base de datos. Todo tu contenido (entradas, páginas, comentarios, usuarios, configuraciones, pedidos de WooCommerce) está almacenado en MySQL y está completamente intacto. El error 500 es un problema de código o configuración que impide a WordPress renderizar y mostrar ese contenido, pero los datos en sí nunca se ven afectados. Incluso en el peor caso (necesitas reinstalar WordPress desde cero), tus datos siguen ahí y se pueden recuperar fácilmente reconectando WordPress a la misma base de datos.

¿Por qué el error 500 apareció después de actualizar un plugin si ese plugin funcionaba bien antes?

Las actualizaciones de plugins pueden introducir nuevas dependencias de PHP, usar funciones disponibles solo en versiones más recientes de PHP o WordPress, o modificar la forma en que interactúan con otros plugins. Si el plugin actualizó su código para usar funciones de PHP 8.x y tu servidor corre PHP 7.4, el resultado es un error 500. También puede ocurrir que la nueva versión del plugin entre en conflicto con otro plugin que ya tenías activo, aunque ambos funcionaran correctamente por separado.

¿Cómo puedo acceder al panel de WordPress si el error 500 me impide entrar?

Si el error 500 afecta también al panel de administración (/wp-admin/), tienes tres alternativas: acceder por FTP o SFTP para modificar los archivos directamente (renombrar la carpeta de plugins, editar wp-config.php), usar WP-CLI desde la línea de comandos SSH si tu servidor lo tiene instalado, o usar el administrador de archivos de Plesk que te da acceso a todos los archivos del sitio desde el navegador sin necesidad de FTP ni SSH.

¿El error 500 en WordPress puede ser causado por el servidor de hosting y no por WordPress?

Sí, aunque es menos frecuente que las causas internas de WordPress. El servidor puede causar un error 500 en WordPress por: agotamiento de los recursos del servidor (CPU, RAM, conexiones MySQL) en momentos de alta carga, cambios en la configuración del servidor que afectan al comportamiento de PHP, actualizaciones del servidor que cambian la versión de PHP activa sin aviso, o problemas con PHP-FPM en configuraciones LEMP. Para distinguir si el error viene del servidor o de WordPress, activa WP_DEBUG: si el debug.log muestra un error PHP específico, es un problema de WordPress; si el debug.log está vacío y el servidor devuelve 500, el problema puede estar en una capa inferior.

¿Cuánto tiempo tarda en resolverse un error 500 en WordPress?

Con el proceso de diagnóstico correcto, la mayoría de los errores 500 en WordPress se resuelven en menos de 30 minutos. El tiempo mayor lo consume el primer paso: encontrar la causa exacta. Si activas WP_DEBUG y el debug.log identifica el plugin o archivo culpable de forma directa, el error puede resolverse en 5 minutos desactivando ese plugin o corrigiendo el código. Sin el debug.log, el proceso de ensayo y error (desactivar plugins uno a uno, cambiar el tema) puede llevar entre 15 y 60 minutos dependiendo del número de plugins activos.

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

Si el error 500 aparece solo en páginas específicas (por ejemplo, solo en la categoría "Noticias" o solo en las páginas con el shortcode [mi_shortcode]), la causa es el código o los datos que se cargan específicamente en esas páginas. Los escenarios más frecuentes son: un shortcode que tiene un bug que se activa con ciertos datos (por ejemplo, si el shortcode espera un ID de imagen y esa imagen fue eliminada), un widget en el sidebar que falla con ciertos tipos de página, o una consulta SQL personalizada que funciona en la mayoría de páginas pero falla con los datos de páginas específicas. El debug.log mostrará el error exactamente en el momento en que accedas a esa página específica.