Error 500: qué es, cómo solucionarlo y qué hace Google

El error 500 (500 Internal Server Error, o error interno del servidor) es la respuesta que entrega un servidor cuando algo falló por dentro y no sabe explicar qué. Me lo imagino así: falta un mes para Black Friday, alguien sube un cambio un jueves a las seis de la tarde, el sitio web carga perfecto desde la oficina y todos se van a la casa. Lo que nadie vio es que las páginas de categoría con dos filtros activos responden error 500 desde ese momento, y que Googlebot lleva toda la noche pidiéndolas.

Las guías que hoy aparecen en Google explican bien qué es el internal server error y cómo arreglarlo en WordPress. Mi lectura, después de revisar sitios grandes, es que el error 500 que más cuesta es el que nadie ve desde la oficina: el que aparece en una sola plantilla, con ciertos parámetros o solo para los bots. Ese se encuentra cruzando Search Console con los logs del servidor, y se prioriza según las URLs que venden. Acá va qué significa, qué lo causa, cómo solucionarlo y qué hace Google cuando lo encuentra.

¿Qué es el error 500?

El error 500 es un código de estado HTTP de la familia 5xx, la de los errores del servidor. Dice algo bastante vago: el servidor recibió tu solicitud, intentó procesarla, se encontró con una situación que no sabe manejar y no puede ser más específico. Por eso se le dice "genérico": es el cajón donde caen los fallos que no tienen un código propio.

La analogía que más me sirve es llamar a un restaurante para reservar y que te contesten "tuvimos un problema en la cocina" antes de cortar. El restaurante existe y tu llamada llegó. Algo se quemó adentro y nadie te va a contar qué.

El mensaje cambia según el servidor web y la configuración del sitio web. Los más comunes:

• 500 Internal Server Error
• HTTP 500
• HTTP Error 500
• Error interno del servidor
• Una pantalla con el logo de la marca que dice "algo salió mal"

Si el servidor es Microsoft IIS, a veces aparece con decimales (500.19, 500.13) que apuntan a una causa más concreta, como una configuración inválida o un servidor sobrecargado. Para Google ese diseño da lo mismo: lee el código de estado que devuelve la URL y decide con eso qué hacer.

¿Qué causa un error 500?

Las causas se repiten bastante de un sitio a otro:

• Errores en el código. Una excepción no controlada, un error de sintaxis o un cambio recién desplegado que rompe una función. En sitios grandes es la causa más frecuente, y casi siempre coincide con un deploy.

• Archivo .htaccess mal configurado. En servidores Apache, una línea con sintaxis incorrecta en el archivo .htaccess basta para que todo el sitio responda 500.

• Permisos de archivos y carpetas. Si el servidor no puede leer o ejecutar un archivo porque los permisos están mal asignados, responde con un error.

• Límite de memoria de PHP. Un proceso que necesita más de lo asignado se cae. Subir el límite de memoria resuelve el problema por un rato, aunque normalmente esconde un script que está consumiendo de más.

• Tiempo de espera agotado (timeout). Un script que llama a un servicio externo y no recibe respuesta a tiempo puede terminar en 500.

• Plugins y temas. En WordPress, un plugin incompatible, una actualización a medias o un tema mal programado son la causa clásica. Es lo que más se repite en sitios web chicos y medianos.

• Base de datos. Una conexión que falla, credenciales que cambiaron o una consulta demasiado lenta dejan a la página sin los datos que necesita para armarse.

• Recursos del servidor. CPU o RAM al tope por un peak de tráfico, un proceso pesado o un bot pidiendo URLs sin parar. Si pasa cada vez que hay campaña, los recursos del plan de hosting se quedaron cortos.

Hay una causa que las guías mencionan poco y que en sitios enterprise me toca ver seguido: URLs que solo fallan con ciertos parámetros. La ficha de producto funciona, pero la misma ficha con un parámetro de tracking, una combinación de filtros que nadie probó o una paginación que no existe revienta con un error 500. Desde la oficina el sitio web se ve impecable, porque ningún usuario navega esas URLs a mano. Googlebot sí.

¿Qué hacer si ves un error 500 en otro sitio?

Si el error aparece en una página web que no es tuya, el problema está del lado del servidor y como usuario no puedes solucionarlo. Tu margen es corto:

1. Recarga la página web después de unos segundos. Muchas veces el fallo fue momentáneo.

2. Borra la caché y las cookies de ese sitio en tu navegador. Rara vez es la causa, pero se descarta rápido.

3. Si estabas pagando, no recargues. Revisa tu correo o tu banco antes, porque el pedido puede haberse registrado aunque la confirmación no cargó, y recargar puede duplicar la compra.

4. Avisa al sitio web si el error sigue después de un rato. Puede que su equipo no se haya enterado, sobre todo si el problema afecta solo a algunos usuarios.

Algunas guías todavía recomiendan ver la versión guardada en la caché de Google. Esa opción ya no existe: Google retiró su caché en 2024. Si necesitas el contenido de esa web sí o sí, la alternativa es buscar la URL en la Wayback Machine, que guarda copias archivadas de muchos sitios.

¿Cómo solucionar el error 500 en tu sitio?

Si el sitio es tuyo, antes de tocar nada contesta dos preguntas: desde cuándo pasa y en qué URLs (todo el sitio, una plantilla o solo ciertas combinaciones de parámetros). Con eso claro, este es el orden que seguiría para solucionar el error:

1. Revisa qué cambió. Un deploy, una actualización de plugin, una regla nueva en el .htaccess, un cambio en la configuración del servidor. Si el error 500 empezó justo después, revertir ese cambio es la forma más rápida de corregir mientras se investiga.

2. Lee los logs de errores. El archivo de errores de Apache o de NGINX, y el debug.log si usas WordPress, suelen decir qué script falló, en qué línea y a qué hora. Recarga la URL con error mientras miras el archivo y vas a ver aparecer la línea nueva.

3. Revisa el archivo .htaccess. Renómbralo y carga el sitio. Si el error desaparece, el problema está ahí: restaura una versión anterior o corrige la regla que agregaste.

4. Revisa los permisos. Lo habitual es 755 para carpetas y 644 para archivos. Nunca dejes 777 como solución, porque es un problema de seguridad.

5. Mira la memoria y PHP. Si los logs hablan de "memory exhausted", sube el límite de memoria como parche temporal y busca después qué proceso la está consumiendo. Confirma también que la versión de PHP sea compatible con tu CMS y tus plugins.

6. Prueba la conexión con la base de datos. Credenciales, espacio disponible, consultas lentas y la configuración del archivo que guarda los datos de acceso.

7. Revisa los servicios externos. Si la página depende de una API o de un servicio de terceros, confirma que esté respondiendo y que el código maneje bien el timeout.

8. Escala al proveedor de hosting. Si nada de lo anterior funciona o no tienes acceso a los logs, escríbele al soporte con la hora exacta, las URLs afectadas y lo que ya probaste. Un buen proveedor de hosting puede revisar recursos, procesos y configuración que tú no ves.

¿Cuánto dura un error 500? Depende de la causa: un plugin conflictivo se arregla en minutos y un problema de base de datos o de infraestructura puede tomar horas, y muchas veces solucionarlo depende más del hosting que de ti.

¿Cómo solucionar el error 500 en WordPress?

En WordPress el sospechoso habitual es un plugin. El proceso que sigo para solucionar el problema:

1. Desactiva todos los plugins desde el panel. Si no puedes entrar, renombra la carpeta wp-content/plugins por FTP o desde el administrador de archivos del hosting.

2. Reactívalos de a uno hasta que vuelva el error. El último que activaste es el culpable: actualízalo, reemplázalo o elimínalo.

3. Cambia temporalmente a un tema por defecto si el problema sigue con todos los plugins apagados.

4. Aumenta el límite en el archivo wp-config.php si los logs muestran que la memoria se agotó.

5. Regenera el archivo .htaccess guardando de nuevo los enlaces permanentes en los ajustes de WordPress.

6. Restaura una copia de seguridad si nada funciona y tienes una reciente.

¿En qué se diferencia el error 500 de un 503, un 502 o un 404?

En pantalla se parecen, pero le dicen cosas distintas al navegador y a Google:

Para Google, el 500, el 502 y el 503 caen en el mismo cajón de los 5xx. La diferencia está en la intención: si vas a bajar el sitio web a propósito, el error 503 es el que corresponde porque es temporal y dice "vuelve después" de forma explícita. John Mueller, de Google, validó este mes un orden de preferencia para una caída: 503, después 500, después 403, después 404 y, al final de todo, un 200 con una página de error. Lo explicamos completo en el artículo sobre el 503.

Un error 404, en cambio, dice que el contenido no existe, y la mayoría de las veces no hay que arreglarlo (lo conté en una guía sobre el error 404 para Ahrefs en Español). Un error 500 casi siempre sí, porque esa URL debería funcionar y algo la está rompiendo.

¿El error 500 afecta al SEO?

Depende de cuánto dure y de cuántas URLs toque. Un error 500 de unos minutos en un sitio web no pesa. El riesgo aparece cuando se estira por días o cuando se instala en una plantilla completa. Esto documenta Google sobre los errores 5xx en su guía de códigos de estado HTTP:

• Googlebot baja temporalmente el ritmo de rastreo, y la baja es proporcional a la cantidad de URLs que responden con error.

• El contenido que llega con un 5xx se ignora: Google no actualiza nada de esa URL mientras falle.

• Las URLs que ya están en el índice se preservan por un tiempo, pero si siguen fallando terminan saliendo. Google no da un plazo exacto.

• Cuando el servidor vuelve a responder 200, el rastreo sube de nuevo de a poco.

O sea, la pregunta para tu equipo es cuántas horas y en qué URLs. Un 500 de diez minutos en el blog es invisible para el posicionamiento. Un 500 de dos semanas en las fichas de producto que más venden es otro problema.

Hay un caso que me preocupa más que el 500 honesto: la página web rota que responde 200. Pasa mucho en sitios hechos con JavaScript, donde la API que trae los productos falla, el navegador le muestra al usuario "algo salió mal" y el servidor igual entrega un 200. Para Google eso es una URL válida y vacía. Google la marca como soft 404 cuando ve un 200 con cara de error, y en el peor caso la indexa con el mensaje adentro. Un error 500 por lo menos le avisa que algo anda mal. Si tu equipo trabaja con generadores de código o frameworks de JavaScript, en el artículo sobre vibe coding hay más de estos riesgos.

¿Cómo saber si Google está viendo errores 500?

Acá está la diferencia entre el error que tú ves y el que ve Google. Para el segundo hay tres informes en Search Console y una fuente fuera de ella:

1. Informe de páginas. En Indexación > Páginas, el motivo "Error del servidor (5xx)" lista las URLs que Google no pudo indexar por ese problema. Mira cuándo empezó a subir y las URLs de ejemplo: si comparten un patrón (filtros, paginación, una carpeta), ya tienes una pista.

2. Estadísticas de rastreo. En Configuración > Estadísticas de rastreo, el desglose por respuesta muestra qué porcentaje de las solicitudes de Googlebot terminó en error del servidor. Un salto de error 500 ahí, sin un mantenimiento anunciado, vale una investigación para solucionar la causa antes de que crezca.

3. Inspección de URL. La prueba en vivo te muestra qué código recibe Google hoy en una URL puntual. Sirve para confirmar que el arreglo funcionó.

4. Logs del servidor web. Es el método que usamos en las auditorías de sitios enterprise: tomamos el archivo de logs de 30 días, filtramos las visitas reales de Googlebot (verificadas, no cualquiera que diga llamarse así) y agrupamos los errores por plantilla: fichas, categorías, filtros, búsqueda interna. Un error 500 repartido al azar suele ser carga. Uno concentrado en una plantilla suele ser un bug de programación.

Un ejemplo ilustrativo: un sitio con 300.000 solicitudes de Googlebot al mes donde el 4% termina en error 500, y el 90% de esos errores cae en URLs de categoría con dos o más filtros. El arreglo pasa por corregir la programación de los filtros y, de paso, decidir si esas combinaciones deberían ser rastreables (para eso está el robots.txt y la conversación sobre crawl budget).

Ojo con el error 500 que solo ven los bots. A veces un CDN o un firewall con una configuración distinta para ciertos user agents le sirve a Googlebot una respuesta que los usuarios nunca reciben, y al revés: el CDN puede esconder un 500 del origen detrás de una copia guardada. Por eso no basta con abrir el sitio web en el navegador para declarar que todo está bien. Cuando las URLs vuelvan a responder 200, revisa su estado en cómo indexar una página en Google.

¿Cómo evitar que vuelva a aparecer un error 500?

La prevención es menos entretenida, pero ahorra noches:

• Monitoreo de disponibilidad del sitio web con alertas, para enterarte antes que tus clientes. Mejor si mide la tasa de errores por plantilla o por tipo de página (ficha, carrito, checkout), porque un "hay errores en algún lado" no sirve para priorizar.

• Alertas de tiempo de respuesta. Un servidor que se pone lento suele avisar antes de caerse por falta de recursos.

• Staging antes de producción. Cada actualización de WordPress, plugins, tema o código se prueba primero en un ambiente de pruebas, incluidas las URLs raras: filtros combinados, parámetros, paginación profunda.

• Copias de seguridad recientes y un plan de reversión del deploy que cualquiera del equipo pueda ejecutar.

• Un rastreo de prueba antes de los peaks. Si se viene Black Friday, rastrea el sitio con una herramienta de auditoría una semana antes y filtra los 5xx. En SEO para Black Friday están los datos de cuándo llegan los clics.

• Revisión técnica en cada migración o rediseño de la página web. Es donde más errores aparecen, porque se juntan apuro, servidor nuevo y reglas copiadas a mano. El checklist para rediseñar tu web tiene el resto.

Qué revisaría esta semana

Abre Search Console y mira dos cosas: el motivo "Error del servidor (5xx)" en el informe de páginas y el desglose por respuesta en las Estadísticas de rastreo de los últimos 90 días. Si hay URLs con error 500, ordénalas por plantilla y cruza esa lista con las páginas que más venden. Para solucionar primero lo que importa, empieza por ahí, aunque sean pocas. Son veinte minutos y es bastante más barato que descubrirlo en el reporte de diciembre.