¿Qué es el Error 500 (Internal Server Error)?

El código 500 pertenece a la familia 5xx, reservada para fallos que ocurren dentro del servidor, no en la petición del cliente. Según RFC 9110, la especificación vigente, el servidor responde con 500 cuando encuentra "una condición inesperada que le impide completar la petición". Es, en la práctica, el cajón de sastre de los errores de servidor: se usa cuando algo falla y ningún código más concreto describe qué ocurrió.

Esa generalidad es la clave para entenderlo. Un error 404 señala que el recurso solicitado no existe. Un error 400 señala que la petición llegó mal formada. El 500 no dice nada de eso: confirma que el servidor recibió la petición, empezó a procesarla y algo se rompió por el camino, ya sea el código de la aplicación, la conexión a la base de datos o un recurso agotado.

En WordPress y gestores similares, el 500 suele aparecer tras activar un plugin o un tema incompatible, o después de una actualización de PHP que deja código antiguo sin soporte. En sitios con más tráfico, también puede ser el servidor quedándose sin memoria o sin conexiones disponibles en un pico de carga.

Los cuatro códigos son errores de servidor, pero cada uno señala un punto distinto del proceso. Confundirlos complica el diagnóstico porque la solución no es la misma en los cuatro casos.

La diferencia práctica es que 502 y 504 los genera por definición un proxy, una pasarela o un balanceador de por medio, mientras que 500 y 503 pueden darse en un servidor único. Y frente al error 404, los cuatro comparten algo: la petición llegó bien formada y el fallo está en el lado del servidor, no en el cliente.

Cuando el servidor recibe una petición correctamente formada, empieza a ejecutarla: consulta la base de datos, procesa la lógica de la aplicación, genera la respuesta. El 500 aparece cuando algo se rompe en ese proceso, después de que la petición ya pasó los filtros que generarían un error 400 y antes de que el servidor termine de generar el contenido.

HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:21:09 GMT

Las causas más comunes son pocas y bastante repetidas. Un plugin o un tema con código defectuoso, frecuente tras una actualización de WordPress. Un error de conexión a la base de datos, ya sea por credenciales incorrectas, un servicio caído o un límite de conexiones simultáneas superado. Una configuración incorrecta en el archivo .htaccess, sobre todo tras editarlo a mano. Recursos del servidor agotados, memoria o procesos, en picos de tráfico que el hosting no soporta. Y con menos frecuencia, un certificado SSL caducado o un conflicto de versión de PHP entre el código y el entorno donde corre.

A diferencia del error 404, que confirma que el servidor terminó de buscar y no encontró nada, el 500 deja el proceso a medias. Por eso revisar los logs del servidor es casi siempre el primer paso: ahí queda registrado qué proceso o qué línea de código provocó el fallo, información que la respuesta HTTP en sí misma no ofrece.

Un error 500 puntual, que dura segundos o minutos, apenas tiene efecto en el posicionamiento. Google trata los fallos aislados como ruido normal de cualquier servidor. El problema empieza cuando el error se repite o se mantiene: Google Search Central confirma que los errores 5xx, junto con el 429, hacen que sus rastreadores reduzcan la velocidad de rastreo de forma temporal, y si el servidor sigue devolviendo 500 el tiempo suficiente, las URL afectadas acaban saliendo del índice.

Search Console agrupa estos fallos bajo la categoría "Error de servidor (5XX)" en el informe de estadísticas de rastreo, separada de los errores 4xx que se explican en el error 400. Un aumento sostenido ahí es la señal más fiable de que el problema no es puntual, aunque la web parezca funcionar bien en una comprobación manual.

La buena noticia es que la recuperación también es rápida: en cuanto el servidor vuelve a responder con normalidad, Google restablece gradualmente el ritmo de rastreo anterior. A diferencia del error 404, que retira contenido del índice sin necesidad de que el fallo se repita, el 500 solo perjudica cuando se convierte en la norma, no en la excepción.

• Revisar los logs del servidor inmediatamente después de un 500 para identificar qué proceso, plugin o línea de código lo provocó, en vez de limitarse a recargar la página.
• Configurar una herramienta de monitorización de uptime que avise en cuanto el servidor empiece a devolver 500, no solo cuando el sitio quede completamente caído.
• Durante un mantenimiento programado, devolver un 503 con la cabecera Retry-After. Google lo recomendó en 2011 para estas caídas; su documentación actual trata el 500 y el 503 igual: frena el rastreo, conserva de momento las URL indexadas y acaba retirándolas si el error dura.
• Comprobar la compatibilidad de plugins y temas antes de actualizar WordPress, sobre todo en tiendas o sitios con integraciones personalizadas.
• Verificar la vigencia del certificado SSL y la versión de PHP tras cualquier migración de hosting, dos causas frecuentes y fáciles de pasar por alto.
• Aislar el componente que falla desactivando plugins o temas uno a uno cuando el error aparece tras un cambio reciente, en lugar de revertir toda la actualización a ciegas.

• Dejar un error de servidor, sea 500 o 503, activo durante días en una migración o un mantenimiento: Google acaba retirando del índice las URL que siguen fallando.
• Ignorar un 500 que solo aparece de forma intermitente, asumiendo que se ha resuelto solo porque la siguiente carga funciona.
• Revertir una actualización completa sin revisar antes los logs, perdiendo la oportunidad de identificar qué plugin o tema causó el fallo real.
• Confundir un 500 con un error 404 al leer los informes, tratando un fallo de servidor como si fuera contenido inexistente.
• No monitorizar el uptime del sitio, descubriendo el problema solo cuando un cliente o Search Console lo reporta días después.