Error 500 interno de WordPress: causas más comunes y plan rápido de solución

Qué significa realmente un 500 en WordPress (y qué no significa)

Un código de estado 500 significa que el servidor no pudo cumplir la solicitud debido a una condición inesperada. No significa que la solicitud estuviera mal formada (eso es 400/404),
y no significa que estés limitado por tasa (429) ni que tu upstream esté caído (502/504). Un 500 suele generarlo el servidor de origen o el runtime de la aplicación.

En el mundo WordPress, “500 Internal Server Error” frecuentemente corresponde a:

• Errores de configuración del servidor web (reglas de rewrite erróneas, directivas inválidas, módulos faltantes).
• Caídas o errores fatales del runtime PHP (excepciones no capturadas, funciones indefinidas, agotamiento de memoria).
• Problemas con el pool de PHP-FPM (max_children alcanzado, timeouts en slowlog, permisos de socket).
• Problemas de permisos/propiedad del sistema de ficheros (no puede leer plugins/temas, no puede escribir cache/temp).
• Limitaciones de recursos (CPU saturada, disco lleno, agotamiento de inodos).
• Reglas de seguridad/WAF que provocan que el upstream devuelva 500 genérico.

Además, no olvides que “WordPress 500” a veces no es WordPress. Puede ser la CDN devolviendo un 500 genérico porque el origen devolvió otra cosa,
o porque el edge no puede alcanzar el origen correctamente. Verifica siempre dónde se crea el código de estado.

Una frase útil para tu checklist mental de incidentes viene de Werner Vogels (CTO de Amazon): “Everything fails, all the time.” No es pesimismo; es planificación.

Playbook de diagnóstico rápido (primeras/segundas/terceras comprobaciones)

Paso 0: Deja de adivinar. Confirma la capa que falla.

Antes de tocar WordPress, determina si el 500 viene del edge (CDN/WAF), del servidor web (Nginx/Apache) o de PHP (PHP-FPM/mod_php).
Tu primer acierto es reducir el radio de impacto.

Primera comprobación (2 minutos): reproduce y captura las cabeceras de respuesta

• Si las cabeceras muestran server: cloudflare o similar, valida si es un 500 de origen o un error generado en el edge.
• Si ves X-Powered-By: PHP y un header de ID de petición de tu plataforma, tienes un hilo para tirar.

Segunda comprobación (5 minutos): lee los logs correctos, no todos

• Registro de errores del servidor web para la marca de tiempo y la ruta de la petición.
• Registro de errores de PHP-FPM (o php_errors en syslog/journald).
• Registro de depuración de WordPress solo si está activado—y preferiblemente activarlo temporalmente.

Tercera comprobación (10 minutos): aisla WordPress de la plataforma

• Solicita un fichero estático (como /favicon.ico) para ver si el servidor web puede servir algo.
• Solicita /wp-login.php y un endpoint simple de phpinfo si tienes uno (o créalo temporalmente y elimínalo después).
• Deshabilita plugins y cambia el tema (con seguridad) si los logs apuntan a fatales de PHP o problemas de orden de carga de plugins.

Si haces esas tres comprobaciones con disciplina, la mayoría de los incidentes 500 pasan de “misteriosos” a “accionables” rápido.
Si las saltas, harás lo que hacen los humanos bajo estrés: cambiar cinco cosas y no aprender nada.

Causas más comunes (por capa)

1) CDN/WAF y reverse proxies: errores de origen disfrazados

Una CDN puede reenviar fielmente un 500 del origen, o puede emitir su propio 500 si no puede alcanzar el origen, no puede negociar TLS, o recibe una respuesta inválida.
Algunos WAF gestionados también bloquean peticiones y devuelven una página de error con marca que parece “500-ish” a los usuarios.

Tu trabajo: comprueba si el origen devuelve 500 cuando se accede directamente (omitendo la CDN) y si la petición está siendo reescrita de forma sorprendente.

2) Nginx/Apache: reglas de rewrite, permisos y rutas erróneas

WordPress depende mucho de los rewrites. Una sola directiva mala puede convertirse en un 500. También puede hacerlo una línea inválida en .htaccess o una configuración de Nginx que referencia un fichero inexistente.
En Apache, 500 también es lo que recibes cuando el servidor encuentra una directiva que no entiende (a menudo tras un cambio de módulo).

3) Runtime PHP: errores fatales, memoria y versiones incompatibles

La mayoría de los 500 reales de WordPress son fatales de PHP. Una actualización de plugin llama a una función que no existe en tu versión de PHP. Un tema asume que una extensión está instalada.
Una fuga de memoria se convierte en “Allowed memory size exhausted” y el runtime se detiene a mitad de petición.

Otro culpable frecuente es el comportamiento extraño del opcode cache tras un despliegue. OPcache es genial—hasta que no lo es. Vaciarlo puede marcar la diferencia entre estable y embrujado.

4) PHP-FPM: pools bajo presión

Cuando PHP-FPM alcanza pm.max_children, las peticiones se encolan. Dependiendo de los timeouts del servidor web, eso suele verse como 502/504, pero también puede presentarse como 500
si el manejo del upstream está mal configurado o la app devuelve salida parcial. También: problemas de permisos de socket y restricciones chroot/open_basedir pueden convertirse en fallos que parecen errores de aplicación.

5) Sistema de archivos y almacenamiento: disco lleno, agotamiento de inodos y deriva de permisos

WordPress escribe. Escribe ficheros de cache, subidas, actualizaciones de plugins, archivos temporales, ficheros de sesión, a veces logs. Si el disco está lleno, puedes obtener errores sorprendentemente genéricos.
Si el recuento de inodos se agota, puedes tener gigabytes libres y aun así estar efectivamente “lleno”.

La deriva de permisos es más común de lo que la gente admite: una edición manual como root, un deploy que cambia la propiedad, un paso de endurecimiento que bloquea al usuario PHP de leer un fichero de plugin.
La pila web responde con—exacto—500.

6) Base de datos y dependencias externas: errores que se propagan mal

Los fallos puros de base de datos tienden a mostrar “Error establishing a database connection”, pero dependiendo del manejo de errores y las capas de object caching,
las excepciones de BD pueden tragarse y relanzarse como 500 genéricos. Redis/Memcached mal configurados pueden hacer lo mismo.

Broma #1: Un error 500 es la forma que tiene el servidor de decir “Yo también tengo sentimientos”, y ahora mismo están mayormente en pánico.

Tareas prácticas con comandos, salidas y decisiones

Estas son tareas de nivel productivo. Suponen Linux, Nginx o Apache, y PHP-FPM. Ajusta rutas según tu distro.
Cada tarea incluye (a) un comando, (b) qué significa una salida típica, y (c) la decisión que tomas a continuación.

Tarea 1: Captura la respuesta fallida y confirma dónde se genera el 500

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | sed -n '1,20p'
HTTP/2 500
date: Fri, 26 Dec 2025 18:42:10 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-request-id: 7f2c9a4e9b0f3c1a

Qué significa: La respuesta viene de nginx (no de una CDN). El ID de petición es oro si tus logs lo incluyen.
Decisión: Ve directamente a los logs de Nginx y PHP-FPM para esta marca de tiempo/ID de petición.

Tarea 2: Omitir la CDN y golpear el origen directamente (si es posible)

cr0x@server:~$ curl -sS -D- -o /dev/null -H "Host: example.com" http://203.0.113.10/ | sed -n '1,20p'
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Fri, 26 Dec 2025 18:42:13 GMT
Content-Type: text/html

Qué significa: El origen también devuelve 500. Esto no es “la CDN haciendo cosas raras.”
Decisión: Soluciona la pila del origen. Si el origen devuelve 200 pero la CDN devuelve 500, investiga reglas del edge, TLS, WAF o health checks del origen.

Tarea 3: Observa el log de errores del servidor web en vivo mientras reproduces

cr0x@server:~$ sudo tail -n 50 -f /var/log/nginx/error.log
2025/12/26 18:42:10 [error] 1129#1129: *928 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234" while reading response header from upstream, client: 198.51.100.23, server: example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "example.com"

Qué significa: Causa raíz clara: fatal de PHP por falta de la extensión mbstring.
Decisión: Instala/activa la extensión faltante, recarga PHP-FPM y vuelve a probar. No toques los plugins de WordPress todavía; la pila te está diciendo exactamente qué falla.

Tarea 4: Comprueba la salud del servicio PHP-FPM y errores recientes

cr0x@server:~$ sudo systemctl status php8.1-fpm --no-pager -l
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled)
     Active: active (running) since Fri 2025-12-26 17:01:22 UTC; 1h 40min ago
   Main PID: 901 (php-fpm8.1)
     Status: "Processes active: 12, idle: 4, Requests: 28291, slow: 7, Traffic: 0.0req/sec"
     ...

Qué significa: El servicio está en ejecución. “slow: 7” sugiere peticiones lentas pero no necesariamente la causa del 500.
Decisión: Si no hay errores obvios en los logs web, inspecciona los logs de PHP-FPM y considera habilitar slowlog brevemente.

Tarea 5: Inspecciona el log de errores de PHP-FPM para errores fatales o saturación de pools

cr0x@server:~$ sudo tail -n 80 /var/log/php8.1-fpm.log
[26-Dec-2025 18:42:10] WARNING: [pool www] child 2134 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234"
[26-Dec-2025 18:40:55] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it

Qué significa: Dos issues: extensión faltante (500 inmediato) y saturación del pool (riesgo de rendimiento).
Decisión: Arregla el fatal primero (restaurar servicio), luego aborda la capacidad: aumenta pm.max_children solo después de confirmar memoria disponible.

Tarea 6: Confirma que las extensiones y la versión de PHP coinciden con lo que espera WordPress

cr0x@server:~$ php -v
PHP 8.1.26 (cli) (built: Nov 21 2025 10:12:33) (NTS)

cr0x@server:~$ php -m | egrep -i 'mbstring|mysqli|curl|gd|imagick|zip|openssl' || true
curl
mysqli
openssl
zip

Qué significa: No hay mbstring. El core de WordPress y muchos plugins la esperan.
Decisión: Instala el paquete php-mbstring para tu distro, reinicia PHP-FPM y vuelve a probar. Si el CLI difiere del FPM, verifica la ruta de ini de FPM.

Tarea 7: Valida la sintaxis de la configuración del servidor web (barato, rápido, a menudo pasado por alto)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Qué significa: La configuración de Nginx se parsea correctamente.
Decisión: Si obtienes errores aquí, arréglalos antes que nada. Ninguna depuración de WordPress ayuda cuando el servidor web no carga las reglas correctamente.

Tarea 8: Para Apache, comprueba la config y el posible fallout de .htaccess

cr0x@server:~$ sudo apachectl configtest
Syntax OK

Qué significa: La configuración principal de Apache está OK. Eso no garantiza que .htaccess no esté rompiendo peticiones.
Decisión: Mueve temporalmente .htaccess si sospechas problemas de rewrite y vuelve a probar.

Tarea 9: Cuarentena de .htaccess para descartar directivas erróneas

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo mv .htaccess .htaccess.bak.$(date +%s)
cr0x@server:~$ sudo -u www-data php -l index.php
No syntax errors detected in index.php

Qué significa: Si el sitio se recupera después de mover .htaccess, tus reglas de rewrite o directivas eran inválidas.
Decisión: Recrea los permalinks desde el admin de WordPress una vez estable, o reconstruye las reglas mínimas estándar y reintroduce cambios incrementalmente.

Tarea 10: Deshabilitar plugins de forma segura sin wp-admin (renombrar directorio)

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ sudo mv plugins plugins.disabled.$(date +%s)
cr0x@server:~$ ls -1
mu-plugins
plugins.disabled.1766774712
themes
uploads

Qué significa: WordPress no cargará los plugins normales si el directorio falta/está renombrado. Aún cargará mu-plugins.
Decisión: Si el 500 desaparece, un plugin causó el fatal. Restaura el directorio y vuelve a habilitar plugins por bloques o uno a uno para identificar al culpable.

Tarea 11: Cambia a un tema por defecto (cuando sospeches del código del tema)

cr0x@server:~$ cd /var/www/html/wp-content/themes
cr0x@server:~$ sudo mv mytheme mytheme.disabled.$(date +%s)
cr0x@server:~$ ls -1
mytheme.disabled.1766774766
twentytwentyfour
twentytwentythree

Qué significa: Si falta el tema activo, WordPress recurrirá a un tema por defecto instalado.
Decisión: Si esto arregla el 500, el tema está roto o es incompatible. Revierte el despliegue del tema o parchea el error fatal.

Tarea 12: Activa el registro de depuración de WordPress (temporal y responsablemente)

cr0x@server:~$ sudo cp -a /var/www/html/wp-config.php /var/www/html/wp-config.php.bak.$(date +%s)
cr0x@server:~$ sudo grep -n "WP_DEBUG" /var/www/html/wp-config.php || true

cr0x@server:~$ sudo sed -i "s/\/\* That's all, stop editing! Happy publishing. \*\//define('WP_DEBUG', true);\ndefine('WP_DEBUG_LOG', true);\ndefine('WP_DEBUG_DISPLAY', false);\n\n\/\* That's all, stop editing! Happy publishing. \*\//" /var/www/html/wp-config.php

cr0x@server:~$ sudo -u www-data tail -n 30 /var/www/html/wp-content/debug.log
[26-Dec-2025 18:45:03 UTC] PHP Fatal error:  Uncaught Error: Class "WooCommerce" not found in /var/www/html/wp-content/themes/mytheme/functions.php:211

Qué significa: El tema espera WooCommerce, pero los plugins están deshabilitados o WooCommerce no cargó.
Decisión: Corrige las dependencias (proteger el código con class_exists), o restaura el plugin requerido una vez estable. Además: desactiva debug cuando termines; los logs pueden filtrar información interna.

Tarea 13: Comprueba uso de disco y agotamiento de inodos (los problemas de almacenamiento adoran los 500)

cr0x@server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  200M 100% /

cr0x@server:~$ df -i
Filesystem       Inodes   IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 2621401      39  100% /

Qué significa: Te quedaste sin espacio y sin inodos. Actualizaciones, escrituras de cache, archivos de sesión—todo puede fallar de forma impredecible.
Decisión: Libera espacio inmediatamente (logs, lanzamientos antiguos, cache), luego arregla la causa (rotación de logs, política de cache, crecimiento de uploads, dimensionamiento de particiones).

Tarea 14: Identifica rápidamente a los grandes responsables

cr0x@server:~$ sudo du -xhd1 /var | sort -h
120M	/var/cache
1.4G	/var/log
6.8G	/var/lib

cr0x@server:~$ sudo ls -lhS /var/log | head
-rw-r----- 1 syslog adm  920M Dec 26 18:40 syslog
-rw-r----- 1 root  adm  210M Dec 26 18:15 nginx-error.log

Qué significa: Los logs se están comiendo el disco. Eso suele correlacionar con un bucle de errores nuevo (por ejemplo un fatal de plugin que llena los logs).
Decisión: Rota/trunca logs para recuperar espacio, pero también arregla el bucle subyacente. Si no, volverás aquí en una hora.

Tarea 15: Comprueba la propiedad y permisos de ficheros en directorios de WordPress

cr0x@server:~$ sudo namei -l /var/www/html/wp-content
f: /var/www/html/wp-content
drwxr-xr-x root     root     /
drwxr-xr-x root     root     var
drwxr-xr-x root     root     www
drwxr-xr-x root     root     html
drwx------ root     root     wp-content

Qué significa: wp-content es 700 y propiedad de root. PHP corriendo como www-data no puede leer/escribir. Espera 500s y comportamiento admin raro.
Decisión: Corrige propiedad/permisos según tu modelo de despliegue (a menudo legible por www-data, con áreas limitadas grabables para uploads/cache).

Tarea 16: Valida permisos del socket de PHP-FPM y conectividad desde Nginx

cr0x@server:~$ ls -l /run/php/php8.1-fpm.sock
srw-rw---- 1 www-data www-data 0 Dec 26 17:01 /run/php/php8.1-fpm.sock

cr0x@server:~$ sudo grep -R "fastcgi_pass" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42: fastcgi_pass unix:/run/php/php8.1-fpm.sock;

Qué significa: El socket existe y coincide con la configuración. Si los permisos fuesen malos o la ruta no coincidiera, Nginx registraría errores de conexión al upstream.
Decisión: Si la ruta del socket difiere, alinea la config de Nginx o la directiva listen de PHP-FPM, luego recarga servicios.

Tarea 17: Comprueba la saturación del pool y la memoria disponible antes de “aumentar max_children”

cr0x@server:~$ ps -o pid,rss,cmd -C php-fpm8.1 | head
  PID   RSS CMD
  901  17800 php-fpm: master process (/etc/php/8.1/fpm/php-fpm.conf)
 2134 145200 php-fpm: pool www
 2135 152300 php-fpm: pool www

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:            2048        1530          85          40         432         260
Swap:           1024         950          74

Qué significa: Los workers usan ~150MB RSS cada uno. Tienes poca memoria disponible y estás usando swap intensamente.
Decisión: No aumentes pm.max_children todavía. Reduce uso de memoria (plugins, configuración de object cache), añade RAM o escala horizontalmente.

Tarea 18: Busca errores fatales de PHP en journald (común en distros con systemd)

cr0x@server:~$ sudo journalctl -u php8.1-fpm -S "10 minutes ago" --no-pager | tail -n 30
Dec 26 18:42:10 server php-fpm8.1[901]: PHP Fatal error:  Uncaught Error: Call to undefined function mb_strlen() in /var/www/html/wp-includes/formatting.php:1234

Qué significa: Confirma un fatal de runtime cercano en tiempo al incidente.
Decisión: Arregla la dependencia faltante; si el fatal cambia después de arreglarlo, sigue iterando—no asumas que solo hay un problema.

Tarea 19: Prueba un único archivo PHP a través de la ruta del servidor web

cr0x@server:~$ printf '%s\n' '/dev/null
cr0x@server:~$ curl -sS -D- http://127.0.0.1/health.php | sed -n '1,10p'
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8

OK

Qué significa: La ejecución de PHP a través de la pila funciona. Entonces la falla probablemente está en el path de código de WordPress (plugins/tema/core) más que en la conectividad de FPM.
Decisión: Concéntrate en WordPress y sus dependencias; mantén el endpoint de salud temporal y elimínalo tras el incidente.

Tarea 20: Elimina el endpoint de prueba temporal (porque tu yo futuro merece paz)

cr0x@server:~$ sudo rm -f /var/www/html/health.php
cr0x@server:~$ test ! -e /var/www/html/health.php && echo "removed"
removed

Qué significa: El endpoint ha sido eliminado.
Decisión: Si necesitas checks de salud continuos, impléméntalos correctamente (ruta restringida, autenticación y monitorización), no como un artefacto de incidente que queda por ahí.

Tres mini-historias del mundo corporativo (fallos realistas)

Mini-historia 1: El incidente causado por una suposición errónea

Un sitio de marketing ejecutaba WordPress detrás de una CDN y un WAF gestionado. El equipo vio un pico de “errores 500” en monitorización sintética y asumió, por reflejo, que WordPress se había caído.
Fueron directo a wp-content, renombraron plugins e incluso revirtieron un tema.

Nada cambió. El error persistió, obstinadamente. Mientras tanto, al editar el servidor de origen durante tráfico pico, introdujeron una deriva de permisos:
un rápido scp como root dejó archivos propiedad de root en el directorio de plugins. El sitio empeoró. Ahora tenían 500s intermitentes y fallos raros en el admin.

La causa raíz era upstream: el proveedor del WAF había desplegado un nuevo conjunto de reglas que trataba un parámetro de consulta común de su rastreo publicitario como sospechoso.
El WAF devolvía una página 500 genérica (no un 403), porque “seguridad por ambigüedad” aparentemente sigue siendo una característica de producto.

La solución fue aburrida: omitir CDN/WAF para confirmar la salud del origen, luego añadir una excepción para el parámetro de tracking y afinar la regla. Después deshacer los cambios innecesarios en el origen.
La lección: un 500 no es una confesión de WordPress. Es un síntoma. Confirma dónde se genera antes de abrir el kit de cirugía.

Mini-historia 2: La optimización que salió mal

Un equipo de plataforma quería páginas más rápidas y menor CPU. Habilitaron caching de página agresivo con un plugin, además de microcaching en Nginx.
En teoría: menos ejecuciones de PHP, DB feliz, menor coste. Y durante una semana, funcionó genial.

Luego llegó una campaña de venta. El tráfico subió, y también los intentos de login (legítimos y no). La configuración de cache accidentalmente almacenó respuestas que nunca debieron ser cacheadas:
fragmentos de páginas autenticadas y, peor, bucles de redirección para usuarios con cookies específicas. Las sesiones PHP se descontrolaron. Las keys de cache estaban mal.

Bajo estrés, los workers de PHP-FPM se bloquearon. Las peticiones se acumularon. El servidor web empezó a devolver una mezcla de 500s y 502s según qué timeout se disparara primero.
El plugin también escribió ficheros de cache enormes en un directorio del filesystem raíz. El disco llegó al 100% y todo se convirtió en “internal server error”, incluyendo servicios no relacionados.

La solución no fue “desactivar cache para siempre”. Fue: limitar el comportamiento del cache, establecer reglas de bypass correctas para usuarios autenticados, mover almacenamiento de cache a un volumen dimensionado,
aplicar cuotas de disco y establecer alertas de uso de inodos. La optimización no estaba mal; faltaban guardarraíles.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un sitio de contenido ejecutaba WordPress con un pipeline de despliegue estricto: releases inmutables, configs en control de versiones y un preflight que ejecutaba nginx -t,
una comprobación de sintaxis PHP en código personalizado y una prueba de humo que solicitaba /, /wp-login.php y un asset estático.

Un ingeniero fusionó un cambio a reglas de rewrite de Nginx para manejar una estructura de URLs legacy. La config pasó la sintaxis, pero la prueba de humo falló: la homepage devolvía 500.
El pipeline detuvo el despliegue automáticamente y mantuvo la config anterior en vivo. No hubo página de incidentes. No hubo reunión de emergencia. Solo un job fallido y un ingeniero algo molesto.

El error era sutil: una regla de rewrite referenciaba un grupo de captura nombrado que no existía en algunas rutas, provocando un bucle de redirección interna y un 500.
Como la prueba de humo incluía la homepage y un par de URLs representativas, lo detectó inmediatamente.

La moraleja es radicalmente poco sexy: las comprobaciones de preflight y las pruebas de humo son más baratas que las heroicas. No necesitas testing perfecto; necesitas unas pocas comprobaciones que fallen ruidosamente.

Errores comunes: síntoma → causa raíz → solución

La forma más rápida de depurar es reconocer patrones. La forma más lenta es tratar cada 500 como si fuera nuevo.
Aquí están los errores que sigo viendo en sistemas reales.

1) “500 solo en /wp-admin” → agotamiento de memoria o hooks de admin de plugins → aumentar memoria correctamente y arreglar el plugin

• Síntoma: La página principal carga; wp-admin devuelve 500.
• Causa raíz: Las páginas de admin cargan más código (plugins, editores, builders). Límite de memoria demasiado bajo o un fatal de plugin que se dispara en hooks solo de admin.
• Solución: Revisa los logs de PHP por “Allowed memory size exhausted”, establece la memoria en php.ini del PHP-FPM (no solo en wp-config) y actualiza/desactiva el plugin.

2) “500 después de activar permalinks” → mala configuración de rewrite → restaurar reglas base

• Síntoma: Funciona con ?p=123, falla con URLs bonitas.
• Causa raíz: Falta mod_rewrite (Apache), try_files mal en Nginx, o .htaccess roto.
• Solución: Valida la configuración de rewrites del servidor, regenera permalinks, mantén las reglas de rewrite mínimas.

3) “500 tras actualizar PHP” → incompatibilidad de extensiones o código obsoleto → alinear extensiones y actualizar código

• Síntoma: El sitio muere justo después de cambiar la versión de PHP.
• Causa raíz: Un plugin/tema usa funciones eliminadas/deprecadas; faltan extensiones para la nueva versión de PHP.
• Solución: Revisa los logs fatales, instala módulos faltantes, revierte PHP si es necesario y luego actualiza plugins/temas para compatibilidad.

4) “500 intermitente bajo carga” → saturación de pool PHP-FPM o DB lenta → escalar o afinar, no solo aumentar timeouts

• Síntoma: 500s aleatorios durante picos de tráfico.
• Causa raíz: Workers de FPM al máximo, o una consulta DB que se queda estancada y consume workers. Los timeouts se encadenan.
• Solución: Mide la RAM por worker, afina pm.max_children responsablemente, añade caching/object cache, optimiza consultas lentas, escala horizontalmente.

5) “500 tras un ‘pequeño cambio de configuración’” → reload de Nginx/Apache OK pero comportamiento roto → diff y revert rápido

• Síntoma: No hubo deploy, pero alguien tocó la config.
• Causa raíz: Socket upstream equivocado, path root erróneo, bloques location mal ordenados, bucles de redirect internos.
• Solución: Revierte el cambio de configuración primero, luego reaplica con pruebas. En incidentes, la reversibilidad vence a la creatividad.

6) “500 más ‘permission denied’ en logs” → deriva de propiedad → arreglar owner/group y umask

• Síntoma: Los errores mencionan “Permission denied” al leer ficheros PHP o escribir cache/upload.
• Causa raíz: Ficheros copiados como root; proceso de deploy inconsistente; hardening cambió modos de directorio.
• Solución: Restaura la propiedad correcta, aplica un usuario de deploy consistente y deja de editar producción como root a menos que te gusten los incidentes recurrentes.

Listas de verificación / plan paso a paso

Checklist de restauración rápida (objetivo: 15–30 minutos)

1. Confirma la fuente del 500: curl cabeceras; omite CDN si es posible.
2. Revisa el log de errores del servidor web: busca FastCGI/fatales de PHP, errores de permisos, bucles de rewrite.
3. Revisa logs de PHP-FPM: fatales, max_children alcanzado, segfaults, triggers de slowlog.
4. Verifica coherencia de configuración: nginx -t / apachectl configtest.
5. Comprueba disco + inodos: discos llenos crean fallos “misteriosos”.
6. Cuantena plugins: renombra wp-content/plugins si los logs apuntan a errores a nivel plugin.
7. Tema de fallback: renombra el directorio del tema activo si el tema está implicado.
8. Restaura conocido bueno: revierte el último deploy, restaura desde backup/snapshot si sospechas corrupción.
9. Elimina cambios de depuración temporales: desactiva WP_DEBUG y quita endpoints de prueba.

Checklist de causa raíz y endurecimiento (objetivo: mismo día)

1. Haz los logs consultables: centraliza Nginx/Apache + PHP-FPM con request IDs.
2. Añade pruebas de humo: homepage, wp-login, una entrada representativa y un asset estático.
3. Bloquea el despliegue: propiedad consistente, no ediciones root ad-hoc, directorios de release inmutables si es posible.
4. Monitorea lo correcto: % disco, % inodos, cola/children de PHP-FPM, tasa de 5xx, latencia DB.
5. Define rollback: un comando o un botón. Si el rollback necesita una reunión, no es rollback.
6. Audita plugins: elimina plugins abandonados, fija versiones, prueba actualizaciones en staging.

Broma #2: Lo único más permanente que una solución temporal es el ticket marcado “no volverá a pasar”.

Datos interesantes y contexto histórico (que realmente te ayudan a depurar)

• HTTP 500 existe desde los primeros días de HTTP/1.0, pero siempre fue pensado como un cajón de sastre—lo que significa que debes confiar en los logs, no en el código de estado.
• WordPress nació como fork de b2/cafelog; su ecosistema de plugins explotó temprano, y esa extensibilidad es una fuente frecuente de sorpresas en runtime.
• .htaccess existe en gran parte por el hosting compartido: las sobrescrituras por directorio permiten a usuarios cambiar rewrites sin root. También les permite romper cosas sin root.
• “White Screen of Death” suele ser un fatal de PHP con la visualización de errores desactivada. Los usuarios ven blanco; los logs ven la verdad.
• PHP-FPM se convirtió en el modelo de despliegue común porque gestiona procesos mejor que CGI clásico y es más flexible que mod_php para stacks modernos.
• OPcache reduce dramáticamente CPU cacheando bytecode compilado, pero casos de cache obsoleta pueden imitar 500s “aleatorios” tras despliegues.
• El agotamiento de inodos es anterior a la nube: los sistemas de ficheros ext pueden quedarse sin inodos antes que bytes, y las web apps con muchos ficheros pequeños de cache son candidatas naturales.
• Muchas CDNs históricamente devolvían páginas 5xx genéricas incluso cuando el origen devolvía un código específico, lo que entrenó a equipos a depurar la capa equivocada primero.
• El modelo de rewrites de WordPress depende del front controller (index.php manejando “pretty URLs”), por eso una mala configuración de rewrite se ve como una caída total del sitio.

Preguntas frecuentes

1) ¿Por qué WordPress muestra un 500 en vez de un error útil?

En producción, la visualización de errores de PHP suele estar apagada (correctamente), por lo que los fatales no muestran un stack trace bonito. El servidor web devuelve 500 porque el upstream falló.
Tu error útil está en los logs.

2) ¿Un error 500 siempre lo causan plugins?

No. Los plugins son comunes, pero las malas configuraciones, extensiones PHP faltantes, permisos, disco lleno y saturación del pool PHP-FPM son igual de frecuentes en entornos reales.
Empieza por los logs, no por supersticiones.

3) ¿Cuál es la forma más rápida y segura de desactivar todos los plugins?

Renombra wp-content/plugins a otra cosa. WordPress no cargará los plugins normales. Si el sitio se recupera, has confirmado la clase de problema.
Recuerda que mu-plugins siguen cargándose.

4) Si aumento memory_limit, ¿se arreglarán los 500?

A veces. Si el log dice que la memoria se agotó, sí—aumentarla puede restaurar el servicio. Pero también puede enmascarar una fuga de memoria o un plugin que consume demasiado.
Además asegúrate de cambiar el límite en el lugar correcto (pool PHP-FPM/php.ini), no solo en las constantes de WordPress.

5) ¿Por qué obtengo 500 solo algunas veces?

Los 500 intermitentes suelen venir de comportamientos dependientes de carga: saturación de PHP-FPM, DB lenta, condiciones de carrera en capas de cache, disco que se llena gradualmente o dependencias upstream inestables.
Busca correlaciones con tráfico y métricas de recursos.

6) ¿Y si los logs están vacíos?

Entonces estás mirando en el lugar equivocado o el logging está mal configurado. Confirma qué servidor web está activo, confirma rutas de logs y revisa journald.
También verifica que tu petición realmente llegue al origen (omite CDN/WAF y confirma).

7) Estoy en Apache. ¿Debo borrar .htaccess?

No borres; cuaréntalo. Renómbralo para poder restaurarlo rápido. Si quitarlo arregla el problema, reconstruye un .htaccess mínimo de WordPress y aplica cambios con cuidado.

8) ¿Un problema de base de datos podría aparecer como 500?

Sí. Aunque WordPress suele mostrar un mensaje de conexión a BD, algunas capas de object cache y código personalizado lanzan excepciones que acaban siendo 500s.
Revisa logs de PHP por excepciones de BD y logs web por timeouts de upstream.

9) ¿Cómo sé si es PHP-FPM vs código de WordPress?

Crea un endpoint PHP mínimo temporal (o usa un health check existente) y solicítalo por el mismo vhost.
Si eso funciona, PHP-FPM probablemente está bien y falla el path de código de WordPress. Elimina el endpoint después.

10) ¿Cuál es la prevención más efectiva para incidentes 500 recurrentes?

Un pipeline de despliegue con pruebas de humo y un rollback en un paso. Puedes sobrevivir a plugins rotos si puedes revertir en segundos en lugar de debatir en chat.

Conclusión: siguientes pasos que realmente reducen repeticiones

Los errores 500 de WordPress no son raros, ni místicos. Son tu sistema diciéndote “algo falló” mientras se niega a decir qué.
Tu trabajo es hacerlo hablar: confirma la capa, lee los logs, aísla el runtime y luego avanza con una solución—o revierte con confianza.

Si quieres una secuencia práctica para implementar después de apagar el incendio, haz esto:

1. Asegúrate de que los logs de error de Nginx/Apache y PHP-FPM se retengan, roten y sean consultables.
2. Añade un pequeño conjunto de pruebas de humo que se ejecuten en cada deploy y en cada cambio de configuración.
3. Pon guardarraíles en el almacenamiento: alertas de disco e inodos, además de ubicaciones y límites sensatos para caches.
4. Estandariza la propiedad de ficheros y la mecánica de despliegue para que la deriva de permisos deje de ser un personaje recurrente en tus informes de incidentes.
5. Prueba plugins/temas en staging y trata las actualizaciones de PHP como proyectos de compatibilidad, no como “mantenimiento menor”.

Haz eso, y la próxima vez que veas “500 Internal Server Error”, será una reparación de 15 minutos con un postmortem limpio—en lugar de una noche de depuración interpretativa.