Guía de códigos de error WordPress: 500, 502, 503, 504 y 404 explicados

Por qué los códigos de error importan

Toda emergencia de WordPress empieza con un número en la pantalla del navegador. 500. 502. 503. 504. 404. La mayoría de los dueños entran en pánico, googlean el número y aplican cinco arreglos diferentes leídos en foros aleatorios. Cuando recibimos la llamada, el sitio está peor que cuando se rompió.

Los cinco códigos HTTP cubiertos aquí representan aproximadamente el 85% de los tickets "mi WordPress está caído" que recibimos. Leerlos correctamente es la habilidad de mayor apalancamiento en operaciones de WordPress.

HTTP 500 — Internal Server Error

Un 500 es un cajón de sastre: el servidor intentó procesar la petición y algo fatal lo detuvo. En WordPress el fatal normalmente vive en PHP — un error de sintaxis, un agotamiento de memoria, una llamada a algo que ya no existe.

Causas más comunes en WordPress

.htaccess corrupto tras un plugin o migración
Error fatal de PHP en functions.php, un plugin o wp-config.php
Agotamiento de memoria (memory_limit PHP alcanzado durante una tarea pesada de admin)
Permisos de archivos equivocados (777 en archivos disparan muchas reglas de seguridad de hostings compartidos)
Fallo de conexión a la base de datos durante el bootstrap

Cómo leerlo

El navegador no muestra nada útil — por diseño (la info de debug filtraría datos). La historia real está en el log de errores del servidor. En cPanel: Errores → ver las últimas 300 entradas. En un VPS: tail -f /var/log/php-fpm.log y recarga la página rota.

Si ves "Allowed memory size of X bytes exhausted", sube WP_MEMORY_LIMIT en wp-config.php. Si ves "Parse error: syntax error", un archivo se editó y se rompió — revierte desde backup. Si ves "Call to undefined function", el problema es un plugin/tema esperando algo que WordPress ya no ofrece.

HTTP 502 — Bad Gateway

Un 502 es un fallo de enrutamiento. Tu visitante habla con un proxy (Nginx, Cloudflare, un balanceador). El proxy intenta hablar con el upstream WordPress (PHP-FPM, Apache). El upstream devolvió basura, no respondió, o cerró la conexión a mitad de respuesta.

Causas más comunes en WordPress

PHP-FPM sin workers disponibles (pm.max_children agotado)
Una sola petición PHP excediendo el tiempo (export pesado en admin, llamada lenta a API de plugin)
Segmentation fault de PHP (raro, usualmente una extensión PHP con bugs)
Ruta de socket fastcgi_pass equivocada en Nginx tras una actualización PHP
Fallo de handshake TLS entre Cloudflare y origen

Cómo leerlo

Comprueba si el 502 viene de Cloudflare (su página con marca) o de tu origen (texto plano). Para Cloudflare entra al dashboard y revisa el gráfico de "Reachability". Para origen, el log de errores de Nginx (/var/log/nginx/error.log) nombra explícitamente el fallo: "upstream prematurely closed connection", "no live upstreams" o "connect() failed (111: Connection refused)".

Si el culpable es PHP-FPM, incrementa pm.max_children después de medir el uso real de memoria por worker. El valor correcto es (RAM disponible ÷ RAM promedio por worker) × 0.8, nunca el mito de "más workers es mejor".

HTTP 503 — Service Unavailable

Un 503 es el estado educado de "estoy temporalmente fuera". WordPress lo devuelve cuando el archivo .maintenance existe (durante actualizaciones). Los hostings lo devuelven cuando tu cuenta excede cuotas. Los balanceadores lo devuelven cuando no tienen backends saludables.

Causas más comunes en WordPress

Modo mantenimiento atascado (archivo .maintenance nunca borrado tras una actualización fallida)
Throttling del hosting por superar cuota de CPU/IO
Rate-limit de Cloudflare disparado por un ataque de fuerza bruta
Origen detrás de un balanceador con todos los backends marcados como no saludables

Cómo leerlo

Mira el cuerpo de la respuesta. El texto literal "Briefly unavailable for scheduled maintenance" significa que WordPress está en modo mantenimiento — borra .maintenance de la raíz del sitio y vuelves en segundos.

Si ves una página con marca del hosting ("Resource limit reached"), el problema es de cuota. Identifica el cron, plugin o ataque de fuerza bruta consumiendo recursos y deténlo antes de añadir más capacidad.

Un 503 con header Retry-After es, de hecho, la forma correcta y SEO-segura de señalar mantenimiento a Google. No te preocupes por 503s breves — solo dañan el SEO si persisten horas.

HTTP 504 — Gateway Timeout

Un 504 es el primo lento del 502. El proxy esperó al upstream de WordPress, la respuesta nunca llegó a tiempo, el proxy se rindió. La diferencia importa: 502 significa respuesta rota, 504 significa sin respuesta dentro del presupuesto de tiempo.

Causas más comunes en WordPress

Una petición PHP que dura demasiado (import enorme, reporte pesado)
Una consulta MySQL lenta bloqueando la petición
Una llamada HTTP externa desde un plugin a una API tercera lenta
Timeout de 100 segundos de Cloudflare en peticiones al origen
Un lock bloqueante en la base de datos

Cómo leerlo

El 504 siempre viene de la capa proxy. Revisa timestamps y duraciones en el log del proxy para ver cuánto esperó. Después, en el upstream, identifica qué corría al mismo tiempo.

Arreglos comunes: subir fastcgi_read_timeout a 300s, mover operaciones lentas a trabajos en segundo plano (Action Scheduler, WP-CLI), y añadir optimización de queries MySQL para las páginas problemáticas.

HTTP 404 — Not Found

Un 404 dice que el servidor recibió la petición pero no encontró recurso que servir. En WordPress casi siempre es un problema de permalinks o reescritura — excepto cuando es intencional (alguien borró la página) o vengativo (un plugin de seguridad ocultando URLs de atacantes devolviendo 404 en lugar de 403).

Causas más comunes en WordPress

Estructura de permalinks rota tras migración o reactivación de plugin
Reglas de custom post type o taxonomía sin flush
.htaccess faltante o con reglas de reescritura equivocadas
Directiva try_files de Nginx equivocada
Definiciones de idioma de WPML/Polylang desincronizadas
Un plugin de seguridad enmascarando URLs legítimas

Cómo leerlo

Si la home funciona pero las páginas internas dan 404, casi seguro son permalinks. Ve a Ajustes → Enlaces permanentes → Guardar (no cambies nada) — esto regenera las reglas de reescritura.

Si los custom post types dan 404, el plugin que los registró se desactivó/reactivó sin hacer flush de reescrituras. Mismo arreglo.

Si las URLs traducidas de WPML dan 404, las definiciones de idioma en las tablas de WPML se desincronizaron de las opciones de WordPress. Resincroniza vía la página de troubleshooting de WPML.

Un árbol de decisión para los próximos 5 minutos

Cuando llegue la próxima emergencia, haz esto en orden:

Abre la URL rota con curl -I — ¿cuál es el código de estado real? Los navegadores pueden engañar por caché y CDN intermedios.
Si es 5xx, revisa primero el log de errores del origen. No toques archivos de WordPress hasta haber leído al menos 10 entradas recientes del log.
Si es 4xx, revisa .htaccess y la configuración de permalinks. Estos causan el 90% de los 404 de WordPress.
Si el problema empezó tras un deploy o actualización, tu primer movimiento es rollback, no diagnóstico. Diagnostica qué rompió desde una base estable.
Si el problema es intermitente, configura un monitor (UptimeRobot, BetterStack) antes de debuggear — los patrones importan más que muestras individuales.

Cuándo llamar a un especialista

Un patrón que vemos semanalmente: un dueño pasa 8 horas persiguiendo un 502, cambia de hosting, acaba en un proveedor "mejor", el 502 vuelve en una semana porque la causa raíz era un plugin lento que ningún host puede tapar.

Si ya probaste lo básico y el error vuelve, el problema es estructural. Diagnosticamos en cada capa — config Nginx, tuning PHP-FPM, slow log MySQL, profiling WordPress — y arreglamos la causa raíz una sola vez.

¿Necesitas un arreglo de emergencia? Respondemos en minutos para caídas activas. Para una auditoría profunda, ve recuperación de velocidad WordPress o eliminación de malware según el síntoma.