Error 502 Bad Gateway

TL;DR — Un 502 Bad Gateway significa que un servidor le estaba pidiendo su página a otro servidor y recibió una mala respuesta. Normalmente, ese servidor «frontal» es un CDN o un proxy, y el servidor «posterior» es su sitio web real (el origin). El error está en su hosting o en su infraestructura, no en Google Search Console, y en la práctica un 502 de corta duración suele implicar un riesgo limitado para el SEO, aunque Google no publica una duración «segura» exacta. Cuanto más se prolongue, mayor será el problema.

Qué es un 502 Bad Gateway

Cuando se carga una página, la solicitud a menudo no llega directamente a su sitio web. Pasa por un intermediario: un CDN (como Cloudflare), un load balancer o un reverse proxy (como Nginx). Ese intermediario reenvía la solicitud a su servidor real, espera una respuesta y la devuelve al visitante.

Un 502 Bad Gateway es lo que muestra el intermediario cuando le pidió la página a su servidor y recibió algo inválido, o nada en absoluto. En términos sencillos: el servidor frontal no pudo obtener una buena respuesta del servidor posterior. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Ese es el matiz importante. Un 502 no significa automáticamente que su sitio web esté caído. Su servidor puede estar perfectamente sano y responder bien a una solicitud directa, pero si el proxy que está delante no consigue alcanzarlo (un timeout, una configuración incorrecta o un mal día del propio CDN), los visitantes siguen viendo un 502.

En qué se diferencia de sus códigos hermanos

Verá varios errores 5xx que parecen similares:

• 500 — el propio código de su sitio web falló al construir la página.
• 502 — un proxy situado delante de su sitio recibió una mala respuesta de este.
• 503 — su sitio está deliberadamente no disponible (mantenimiento planificado, sobrecarga).
• 504 — un proxy esperó a su servidor, pero este agotó el tiempo de espera sin dar ninguna respuesta.

Están relacionados, pero le señalan lugares distintos donde buscar.

¿Un 502 perjudica su SEO?

Normalmente no mucho, siempre que no se prolongue. El rastreador de Google (Googlebot) trata un 502 igual que el resto de los errores 5xx: reduce el rastreo de forma proporcional a cuántas de sus URL están fallando y después vuelve a incrementarlo cuando su sitio empieza a responder de nuevo con 2xx. Google no publica una duración «segura» exacta, pero un 502 breve —de minutos a un par de horas— implica mucho menos riesgo práctico que uno que se repite. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

El riesgo real aparece cuando un 502 se repite o se mantiene durante un periodo prolongado. La formulación de Google es que elimina las URL que devuelven un error de servidor de forma “persistently” (traducción: «persistentemente»), sin definirlo como un número concreto de días. (John Mueller, de Google, ha mencionado informalmente “multiple days” (traducción: «varios días») como el momento aproximado en que las páginas empiezan a caerse, y que tienden a volver una vez que el sitio se recupera, pero trátelo como la lectura aproximada de una persona sobre un incidente concreto, no como una regla oficial.)

Qué hacer al respecto

• No intente «arreglarlo» en Search Console. Search Console solo informa de un 502 a posteriori. La corrección se hace en su CDN, en su proxy o en su servidor.
• Compruebe si le pasa solo a usted o a todo el mundo. Si el resto de internet funciona bien pero su sitio está caído, es su configuración. Si un gran CDN sufre una interrupción, puede que no sea culpa suya en absoluto, y no habrá nada que corregir por su parte más que esperar.
• Mire la página de estado de su hosting o de su CDN y los logs de su servidor. Ahí está la respuesta real.

¿Quiere el diagnóstico capa por capa (CDN vs. proxy vs. origin), lo que dice exactamente la documentación de Google y lo que declaró John Mueller durante la interrupción de Cloudflare de noviembre de 2025? Cambie a la pestaña Avanzado.

TL;DR — Un 502 es un fallo de la capa de proxy/gateway: el RFC 9110 §15.6.3 lo define como un gateway o proxy que recibe una respuesta inválida de un servidor entrante. Se distingue de un 500 (la aplicación de origin falló) y de un 503 (el origin está deliberadamente no disponible). La documentación de Google agrupa el 500, el 502 y el 503 bajo un mismo tratamiento 5xx: la frecuencia de rastreo baja de forma proporcional al número de URL que fallan, el contenido 5xx se ignora y los errores persistentes hacen que las páginas caigan del índice. La recuperación es gradual una vez que se reanudan los 2xx, aunque Google no publica ningún plazo fijo. La duración importa, pero no hay un umbral oficial: los picos breves implican mucho menos riesgo práctico, mientras que los errores que se repiten son los que ponen las páginas en riesgo real; los comentarios de Mueller de noviembre de 2025 lo sitúan informalmente en torno a varios días, no como un SLA documentado. Diagnostíquelo por capas —CDN, reverse proxy u origin— y correlacione las evidencias entre saltos en lugar de confiar únicamente en una página de error con la marca del proveedor.

Qué señala realmente un 502

El RFC 9110 §15.6.3 define el 502 de forma específica: un gateway o proxy que recibe una respuesta inválida de un servidor entrante al que accedió mientras intentaba atender la solicitud. Ese límite que marca la especificación importa: identifica dónde observó el gateway el fallo, no necesariamente qué salto lo causó. El código de estado 502 es evidencia de un fallo en el límite, no prueba de que la aplicación de origin esté rota. Esa única distinción es la que difuminan la mayoría de los artículos de la competencia del tipo «13 formas de arreglarlo», y es la razón por la que el diagnóstico que sigue está organizado por capas en lugar de ser una lista plana. Evidence for this claim A 502 response means a gateway or proxy received an invalid response from an upstream server. Scope: RFC 9110 defines the gateway response semantics; it does not identify which infrastructure layer caused a specific failure. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.3 — 502 Bad Gateway

Compare los códigos 5xx que se confunden con facilidad:

• 500 Internal Server Error — la propia aplicación de origin falló (un error de código, una excepción no controlada, agotamiento de recursos). El origin respondió, y la respuesta fue «me he roto».
• 502 Bad Gateway — el proxy recibió una respuesta mal formada o inválida del upstream (RFC 9110 §15.6.3).
• 503 Service Unavailable — el origin está deliberadamente no disponible; este es el código intencionado y avalado por Google que significa «vuelva más tarde» y que se usa para el mantenimiento planificado, idealmente con una cabecera Retry-After.
• 504 Gateway Timeout — el proxy esperó al upstream y no obtuvo nada antes de que expirara su tiempo de espera (RFC 9110 §15.6.5). (502 = mala respuesta; 504 = ninguna respuesta a tiempo.)

La conclusión práctica: el 503 es el código que usted elige a propósito; el 502 es el código que le ocurre cuando falla la infraestructura.

Cómo gestiona Googlebot un 502

Esta es la parte que conviene fundamentar en la documentación real de Google en lugar de en el vago «puede perjudicar tu posicionamiento» que leerá en otros sitios. El documento HTTP and network errors de Google incluye 502 (bad gateway) como código 5xx y da a todos los códigos 5xx el mismo tratamiento:

• La frecuencia de rastreo baja, de forma proporcional. Google reduce la frecuencia de rastreo del sitio, y la reducción es proporcional a cuántas URL individuales devuelven un error de servidor. Un puñado de 502 es algo menor; un 502 en todo el sitio es un «reduzca la marcha» contundente.
• El contenido 5xx se ignora. Todo lo que Google recibe de una URL que devuelve un 5xx se ignora: no indexará una página de error 502 como si fuera su contenido.
• La conservación en el índice es temporal. Las URL ya indexadas permanecen en el índice al principio, pero el sistema de indexación de Google elimina las URL que devuelven persistentemente un error de servidor.
• La recuperación es automática y gradual. Una vez que el servidor vuelve a responder con 2xx, Google incrementa gradualmente la frecuencia de rastreo. Para una recuperación normal no hace falta reenviar nada, ni pedir una reconsideración, ni hacer heroicidades con “validate fix”: ese botón solo le dice a Google que vuelva a comprobarlo antes.

La conclusión más importante: el 502 se trata igual que el 500 y el 503. No es «menos grave» por originarse en la capa de proxy/CDN en lugar de en la aplicación de origin. El 502 tampoco cuenta con una excepción documentada. Evidence for this claim Google handles 502 with its general 5xx behavior: reduced crawling, ignored response content, and eventual removal of persistently failing URLs. Scope: Google explicitly lists 502 among 5xx server errors; it does not guarantee that a particular short outage has no ranking effect. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La duración lo es todo

Que un 502 le perjudique realmente depende de cuánto dure, pero Google no publica una duración segura fija ni un umbral fijo de caída del índice, así que trate lo siguiente como matiz práctico, no como un SLA:

• Un pico breve (de minutos a unas pocas horas) → la reducción de la frecuencia de rastreo de Google escala con cuántas URL están fallando, de modo que un pico corto y de poco alcance tiene un impacto práctico limitado y, en general, no merece la pena perseguirlo en Search Console. Nada en la documentación de Google exime formalmente a los errores cortos: es una cuestión de grado, no un corte tajante.
• Un error que se repite o se mantiene → esta es la franja en la que se aplica la formulación de Google “persistently return a server error” (traducción: «devuelven persistentemente un error de servidor»), y las páginas pueden empezar a caerse del índice. Google no define “persistently” como un número concreto de días. El comentario público de Mueller (más abajo) lo situó informalmente en torno a varios días, con una recuperación bastante rápida una vez que el sitio está sano, pero esa es la lectura de un profesional sobre un incidente concreto, no una regla documentada en la que pueda confiar para cualquier sitio o CDN.

Esto encaja de forma aproximada con la interrupción de Cloudflare de noviembre de 2025, cuando una oleada de sitios devolvió errores 5xx sin tener culpa alguna. La respuesta pública de Mueller en Bluesky fue que con un 5xx el rastreo se ralentiza, pero “ramps back up” (traducción: «vuelve a incrementarse»); consulte la pestaña Citas para ver la formulación exacta y las advertencias sobre las fuentes, incluido un comentario aparte sobre “multiple days” transmitido a través del resumen de un tercero en lugar de verificado contra el hilo original. Una interrupción breve y confirmada por el proveedor se acerca al mejor de los casos: es visible, normalmente se resuelve por sí sola y, una vez que el proveedor confirma la recuperación y sus propias respuestas 2xx se han reanudado, la reacción razonable suele ser abstenerse de hacer cambios de infraestructura en lugar de hacerlos de forma reactiva.

Diagnosticar un 502 por capas

Como un 502 es un fallo de comunicación entre servidores, la forma más rápida de localizarlo es bajar por la pila —CDN, después reverse proxy y después origin— en lugar de recorrer una lista de comprobación plana. (La pestaña Árboles de decisión incluye esto como un recorrido guiado.)

Una advertencia antes de empezar: una página de error con la marca del proveedor, el nombre de un proveedor en una cabecera o el «aspecto» de una interrupción es una señal de evidencia, no la prueba de qué salto falló. Correlaciónela con las cabeceras de respuesta, los identificadores de solicitud o de traza y los logs con marca de tiempo a ambos lados del salto antes de concluir «es el CDN» o «es mi origin».

Capa de CDN / edge

• Timeout del upstream: el nodo de edge no pudo obtener a tiempo una respuesta del origin.
• El edge no puede alcanzar el origin en absoluto: fallo de resolución DNS, fallo del handshake SSL/TLS, o el firewall o la seguridad del origin bloqueando los rangos de IP del CDN.
• Las causas documentadas varían según el proveedor: la documentación de resolución de problemas de Cloudflare describe escenarios de conectividad con el origin y de timeout específicos de su red de edge, mientras que AWS CloudFront documenta su propio conjunto de causas de TLS, DNS, puertos y funciones de origin; consulte la documentación de su CDN concreto en lugar de asumir que la lista de causas de un proveedor se aplica a otro.
• La interrupción del propio proveedor de CDN (Cloudflare, Fastly, AWS, etc.): un evento de 502 masivo en sitios sin relación entre sí que no tiene nada que ver con la salud de su servidor; confírmelo con la página de estado del proveedor, no solo con la marca que aparece en la página de error.

Capa de reverse proxy / load balancer (Nginx, mod_proxy de Apache, HAProxy)

• Timeout del backend o conexión rechazada.
• Un bloque proxy_pass / upstream mal configurado que apunta al lugar equivocado.
• Agotamiento del pool del backend: todos los workers del upstream están ocupados.
• Incompatibilidad de SSL/TLS entre el proxy y el backend.

Capa del servidor origin

• Caída o reinicio de la aplicación o de PHP-FPM, o un OOM kill (límite de memoria superado).
• Agotamiento de las conexiones a la base de datos.
• Un despliegue o reinicio que provoca una breve indisponibilidad.
• Un WAF o un plugin de seguridad que bloquea IP legítimas de proxies o rastreadores como si fueran atacantes; este es el caso traicionero, porque los navegadores normales funcionan bien mientras el proxy (o Googlebot) recibe 502s.

Ese último patrón merece mencionarse: si solo Googlebot o solo las solicitudes que pasan por el CDN reciben 502s mientras los navegadores normales no, se trata de un bloqueo específico de bots o de un problema de respuestas variables, no de una interrupción real. Pruebe el acceso directo al origin frente al acceso a través del CDN, y verifique qué ve realmente Googlebot con la prueba en vivo de URL Inspection (Inspección de URLs) de Search Console, en lugar de dar por supuesto un impacto continuado a partir de un informe Server error (5xx) que puede estar ya desactualizado.

Corregir y prevenir los 502s

Las correcciones son específicas de cada capa, y quién debe aplicarlas varía según el rol:

• Visitante — nada que corregir. Recargue una vez, pruebe con otra red si sospecha que hay un problema local y, por lo demás, espere; los cambios en el navegador no pueden reparar un fallo entre servidores.
• Propietario del sitio sin acceso a la infraestructura — confirme el alcance y revise primero las páginas de estado y los logs (vea la lista de comprobación más abajo), y después escale a su hosting, al soporte del CDN o a su equipo de desarrollo en lugar de adivinar una solución.
• Responsable del hosting, del CDN o de la aplicación — corrija la configuración del proxy y del upstream, aumente los timeouts y la capacidad del backend allí donde el origin sea el cuello de botella real, y escalone los despliegues para que los reinicios no afecten a todo el pool. Trate la inclusión en la lista de permitidos del WAF, los cambios en el firewall y las modificaciones de la configuración del proxy o del upstream como cambios que requieren aprobación: aplíquelos solo después de que los logs y las evidencias del proveedor muestren realmente un fallo del firewall o del control de acceso, no como una primera reacción a ciegas; permitir un CDN o un rastreador no es una solución genérica para un 502.

Para la prevención, gana lo aburrido: monitorización de disponibilidad con alertas, monitorización de los logs de error del servidor y del proxy, vigilar Host status y la tendencia de Server error (5xx) en las estadísticas de rastreo de Search Console, y correlacionar los picos con las páginas de estado de sus proveedores de CDN y DNS para poder distinguir «mi problema» de «su interrupción» en segundos.

Los códigos relacionados que conviene tener claros están justo al lado en este clúster: el de origin 500, el intencionado 503 y el de timeout 504.

Resumen con IA

Una versión condensada de la variante del nivel Avanzado:

• 502 = fallo de la capa de proxy/gateway. El RFC 9110 §15.6.3 lo define como un gateway o proxy que recibe una respuesta inválida de un servidor entrante: eso es evidencia de un fallo en el límite, no prueba de qué salto (CDN, proxy u origin) lo causó. El origin puede estar sano mientras los visitantes siguen viendo un 502.
• Causas distintas, misma familia documentada. 500 (falló la aplicación de origin), 502 (el proxy recibió una mala respuesta, RFC §15.6.3), 503 (el origin está deliberadamente no disponible), 504 (el proxy no recibió una respuesta a tiempo, RFC §15.6.5). La documentación de Google agrupa el 500, el 502 y el 503 bajo un mismo tratamiento 5xx; no documenta una paridad específica por código más allá de esa regla de familia.
• La respuesta de Googlebot: la frecuencia de rastreo baja de forma proporcional al número de URL que fallan, el contenido 5xx se ignora, las URL indexadas se conservan a corto plazo pero se eliminan si los errores persisten, y el rastreo vuelve a incrementarse gradualmente una vez que se reanudan los 2xx; Google no publica ninguna duración segura exacta ni ningún plazo de recuperación garantizado.
• La duración importa, pero no hay un umbral oficial. Los picos breves implican mucho menos riesgo práctico; los errores que se repiten son el riesgo real. El comentario informal de Mueller de noviembre de 2025 situó las caídas del índice en torno a “multiple days” (traducción: «varios días»), con una recuperación bastante rápida; trátelo como la lectura de un profesional sobre un incidente, no como un SLA documentado.
• Diagnostique correlacionando evidencias entre capas, no confiando solo en la marca del proveedor: CDN (timeout, fallo de DNS/SSL, interrupción del proveedor; Cloudflare y AWS CloudFront documentan cada uno causas distintas específicas de su plataforma) → reverse proxy (proxy_pass incorrecto, agotamiento del pool, conexión rechazada) → origin (caída de la aplicación o de PHP-FPM, OOM, agotamiento de la base de datos, WAF bloqueando IP de proxies o rastreadores). Compare las cabeceras, los identificadores de traza y los logs con marca de tiempo a ambos lados de un salto antes de concluir qué capa falló.
• No hay una solución única para todos los casos. GSC solo informa del 502 a posteriori y no puede corregirlo. Los visitantes tampoco pueden corregirlo; los propietarios de sitios sin acceso a la infraestructura deberían escalar en lugar de editar la configuración; y los cambios destructivos —inclusión en la lista de permitidos del WAF, modificaciones del firewall o del proxy— deberían seguir las evidencias de los logs y del proveedor, no ser una primera reacción a ciegas. Si solo Googlebot o solo las solicitudes que pasan por el CDN reciben 502, sospeche de un bloqueo específico de bots, no de una interrupción global.

Documentación oficial

Documentación de fuentes primarias sobre cómo gestionan los motores de búsqueda los errores 5xx, incluido el 502.

Google

• Cómo afectan los códigos de estado HTTP a los rastreadores de Google — el documento canónico; incluye 502 (bad gateway) junto al 500 y al 503 y describe el tratamiento compartido de frecuencia de rastreo e indexación.
• Cómo gestionar el tiempo de inactividad planificado — por qué el 503 (y no el 502, el 404 o el 200) es el código correcto para una caída intencionada, con una cabecera Retry-After. Útil para la distinción entre 502 y 503.
• Especificación de robots.txt: gestión de errores del servidor — cómo trata Google un 5xx en el propio archivo robots.txt.

Especificación

• RFC 9110 §15.6.3 — 502 (Bad Gateway) — la definición a nivel de especificación: un gateway o proxy que recibe una respuesta inválida de un servidor entrante al que accedió mientras intentaba atender la solicitud. Identifica el límite donde se observó el fallo, no qué salto lo causó.

Bing / Microsoft

• Bing Webmaster Tools — Help Center — Bing muestra en sus informes de errores de rastreo los problemas del lado del servidor (de clase 5xx), incluidos los fallos de conectividad.

Citas de la fuente

Declaraciones oficiales de Google. Cada enlace lleva directamente al pasaje citado.

Google — cómo se gestiona un 5xx (incluido el 502)

• “5xx and 429 server errors prompt Google’s crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped.” (traducción) «Los errores de servidor 5xx y 429 hacen que los rastreadores de Google reduzcan temporalmente el rastreo. En el caso de la Búsqueda de Google, las URL ya indexadas se conservan en el índice, pero finalmente se eliminan.» — Google Search Central, How HTTP status codes affect Google’s crawlers. Ir a la cita
• “Google decreases the crawl rate for the site. The decrease in crawl rate is proportionate to the number of individual URLs that are returning a server error. For Google Search, Google’s indexing pipeline removes from the index URLs that persistently return a server error.” (traducción) «Google reduce la frecuencia de rastreo del sitio. La reducción de la frecuencia de rastreo es proporcional al número de URL individuales que devuelven un error de servidor. En el caso de la Búsqueda de Google, el sistema de indexación de Google elimina del índice las URL que devuelven persistentemente un error de servidor.» — el mismo documento, la fila de la tabla que cubre 500, 502 y 503. Ir a la cita
• “Once the server starts responding with a 2xx status code, Google gradually increases the crawl rate for the site.” (traducción) «Una vez que el servidor empieza a responder con un código de estado 2xx, Google incrementa gradualmente la frecuencia de rastreo del sitio.» — el mismo documento. Ir a la cita

John Mueller, Google (Bluesky, 18 de noviembre de 2025 — respondiendo en un hilo sobre el pico de errores 5xx de la interrupción de Cloudflare)

• “Yeah. 5xx = Google crawling slows down, but it’ll ramp back up.” (traducción) «Sí. 5xx = el rastreo de Google se ralentiza, pero volverá a incrementarse.» Ver la publicación
• “If it stays at 5xx for multiple days, then things may start to drop out, but even then, those will pop back in fairly quickly.” (traducción) «Si se mantiene en 5xx durante varios días, entonces las cosas pueden empezar a caerse, pero incluso entonces volverán a aparecer bastante rápido.» Transmitido a través del artículo de Matt G. Southern en Search Engine Journal sobre el mismo intercambio; confírmelo contra el hilo original antes de considerarlo definitivo. Leer la cobertura

Lista de comprobación para responder a un 502 Bad Gateway

Cuando aparece un 502 —en un navegador, en la monitorización o en el informe Server error (5xx) de Search Console— trabaje con esta lista. Etiquetas de rol: [Cualquiera] funciona tenga o no acceso a la infraestructura; [Responsable de hosting/CDN/aplicación] lo requiere.

• [Cualquiera] Confirme que es real y actual: reproduzca la URL ahora; un informe Server error (5xx) puede ir por detrás de un fallo puntual que ya está resuelto.
• [Cualquiera] Compruebe el alcance: ¿es una URL, una sección o todo el sitio? (El impacto en el rastreo escala con cuántas URL fallan.)
• [Cualquiera] Consulte la página de estado de su proveedor de CDN o de DNS por si hay una interrupción general del proveedor antes de tocar su propia configuración.
• [Responsable de hosting/CDN/aplicación] Pruebe el acceso directo al origin frente al acceso a través del CDN: si el origin responde 2xx directamente pero el CDN devuelve 502, el problema está en el edge o en algún punto intermedio.
• [Responsable de hosting/CDN/aplicación] Compruebe si solo los bots o las IP del CDN reciben 502 mientras los navegadores funcionan bien: apunta a un posible bloqueo del WAF o del firewall, no a una interrupción. Confírmelo en los logs del firewall o del WAF antes de permitir nada; permitir no es una solución genérica y debe seguir a las evidencias, no precederlas.
• [Responsable de hosting/CDN/aplicación] Lea los logs de error del proxy (Nginx/Apache/HAProxy) buscando timeouts del upstream o entradas de conexión rechazada.
• [Responsable de hosting/CDN/aplicación] Lea los logs del origin buscando caídas de la aplicación, OOM kills o agotamiento de las conexiones a la base de datos en torno a esas marcas de tiempo.
• [Cualquiera] Verifique qué ve Googlebot con la prueba en vivo de URL Inspection (Inspección de URLs) de GSC.
• [Responsable de hosting/CDN/aplicación] Aplique la corrección específica de la capa solo cuando los logs o las evidencias del proveedor apunten a ella: los cambios en el WAF, en el firewall, en los timeouts y en la configuración del proxy son cambios de infraestructura, no primeras reacciones a ciegas.
• [Cualquiera] Una vez corregido, deje que la recuperación ocurra: las respuestas 2xx hacen que el rastreo vuelva a incrementarse gradualmente; Google no publica un plazo de recuperación exacto. Use “Validate Fix” solo para provocar una nueva comprobación más rápida, no como una «corrección».
• [Responsable de hosting/CDN/aplicación] Confirme que está usando el 503 (y no el 502) para cualquier caída planificada en el futuro.

¿Mi 502 es un problema del CDN, del proxy o del origin?

Un 502 es un fallo entre servidores, así que diagnostíquelo bajando por la pila en lugar de adivinar. Empiece en el edge y avance hacia dentro.

P1. ¿Su proveedor de CDN o de DNS está informando de una interrupción en este momento?

• Sí → lo más probable es que sea una interrupción general del proveedor (el evento de Cloudflare de noviembre de 2025 es el caso de manual). Normalmente no hay nada que corregir por su parte. Confirme que su origin está sano y después espere a la recuperación: la frecuencia de rastreo de Google vuelve a incrementarse gradualmente una vez que se reanudan las respuestas 2xx, aunque no se publica ningún plazo exacto. Pare aquí.
• No → continúe.

P2. ¿Responde el origin con 2xx a una solicitud directa (evitando el CDN/proxy)?

• No, el origin también falla → el problema está en la capa del origin. Revise en los logs las caídas de la aplicación o de PHP-FPM, los OOM kills, el agotamiento de las conexiones a la base de datos o un despliegue defectuoso. Tenga en cuenta que esto a menudo se manifiesta también como un 500 o un 504, según cómo lo vea el proxy. Pare aquí.
• Sí, el origin está sano directamente, pero el CDN/proxy devuelve 502 → continúe. El origin está bien; algo que está delante de él no consigue una respuesta limpia.

P3. ¿Funcionan los navegadores normales mientras solo Googlebot o las IP del CDN reciben 502?

• Sí → sospeche de un bloqueo del WAF o del firewall que trata los rangos de IP del proxy o del rastreador como atacantes. Confírmelo primero en los logs del firewall o del WAF y después permita los rangos de IP legítimos del CDN y de los rastreadores verificados; no los permita sin esa confirmación. Pare aquí.
• No, todos los que pasan por el proxy reciben 502 → continúe.

P4. ¿Qué muestran los logs del reverse proxy sobre el upstream?

• Timeout / conexión rechazada → el proxy puede alcanzar el backend pero no obtiene una respuesta válida a tiempo → problema de capacidad del backend o de timeouts (pool agotado, timeouts demasiado ajustados). Aumente la capacidad o los timeouts, o corrija el backend lento.
• Host incorrecto / DNS / fallo del handshake SSL hacia el upstream → error de configuración del proxy → corrija el bloque proxy_pass / upstream o la configuración TLS entre el proxy y el backend.

Sea cual sea la capa: la limpieza desde el punto de vista del SEO es la misma y en su mayor parte no requiere intervención. Una vez que las URL devuelven 2xx, Google reanuda el rastreo automáticamente, sin necesidad de reenviar nada.

Mitos y errores sobre el 502 que conviene evitar

• Mito: «el 502 es un problema de Google o de SEO que soluciono en Search Console». No. Un 502 es un fallo de hosting o de infraestructura; Search Console solo lo informa a posteriori. La corrección está en el CDN, en el proxy o en el origin. “Validar corrección” solo le pide a Google que vuelva a comprobarlo: no repara nada.
• Mito: “A 502 always means my server is down.” (traducción) «Un 502 siempre significa que mi servidor está caído». No. El origin puede devolver 2xx a una solicitud directa mientras los visitantes ven un 502 a través del CDN: un timeout, una mala configuración del upstream o la propia interrupción del CDN. Pruebe el acceso directo al origin antes de dar por supuesto que su servidor se ha caído.
• Mito: «el 502 es menos grave que el 500 para el SEO». No. La documentación de Google da al 500, al 502 y al 503 la misma reducción de la frecuencia de rastreo y la misma eliminación eventual del índice para los errores persistentes. No existe ninguna indulgencia documentada para el 502.
• Mito: «un 502 aislado desindexará mi página». No. El rastreo se ralentiza y después vuelve a incrementarse. Las caídas del índice requieren que el error persista: la documentación de Google usa esa palabra sin definir un número exacto de días. El comentario informal de Mueller de noviembre de 2025 lo situó en torno a varios días, y añadió que las páginas caídas “pop back in fairly quickly” (traducción: «vuelven a aparecer bastante rápido»); trátelo como la lectura de un profesional sobre un incidente, no como un umbral oficial.
• Mito: «el 502 y el 503 significan lo mismo». No. El 503 es el código intencionado de «servicio no disponible» que debería usar para el mantenimiento planificado (con un Retry-After); el 502 es un fallo no intencionado del proxy. Confundirlos en la monitorización oculta incidentes reales detrás de ventanas de mantenimiento previstas.
• Mito: «vaciar la caché de mi navegador soluciona un 502 en todo el sitio». Eso es un consejo para un visitante que diagnostica su propia vista. Si el CDN, el proxy o el origin están fallando de verdad, ninguna acción en el navegador cambia nada para nadie más.
• Antipatrón: pulsar “Validate Fix” por reflejo y refrescar GSC. Durante un pico transitorio (o una interrupción del CDN), lo más rápido y correcto suele ser no hacer nada más que confirmar la recuperación. Google gestiona automáticamente la vuelta a la normalidad.

Manual de incidentes: el sitio está devolviendo 502

1. Confirme el alcance. Compruebe una URL afectada con el Website Down Checker y después pruebe varias URL con el Bulk HTTP Status Code Checker. Si solo falla su navegador, resuelva el problema local de red o de DNS antes de escalar un incidente que afecte a todo el sitio. Si muchas URL públicas devuelven 502, continúe.
2. Registre la respuesta fallida. Guarde la hora, la URL, el código de estado, las cabeceras de respuesta y cualquier identificador de solicitud del CDN. Si el error es intermitente, repita la solicitud en lugar de tratar un único reintento correcto como una recuperación.
3. Identifique el gateway; trate la marca del proveedor como una señal, no como una prueba. Lea las cabeceras y la página de error con marca buscando la huella de un CDN, un reverse proxy o un load balancer, pero confírmela con la propia página de estado del proveedor y con sus logs antes de concluir qué salto falló; las páginas y las cabeceras con marca son específicas de cada proveedor y no prueban la causa de forma universal. Si el proveedor informa de una interrupción, siga su vía de incidencias; si no, continúe hacia el origin.
4. Compare el edge y el origin. Solicite el nombre de host público con normalidad y después envíe el mismo nombre de host directamente a la IP conocida del origin con curl --resolve. Si el origin responde correctamente mientras el edge devuelve 502, inspeccione la conectividad del CDN con el origin, el TLS y la configuración del proxy. Si fallan ambas rutas, pase a los logs de la aplicación y del origin.
5. Correlacione los logs por marca de tiempo. Un rechazo de conexión o un fallo de TLS apunta al límite entre el gateway y el origin; una respuesta del upstream mal formada o cerrada de forma abrupta apunta al servicio de origin. Corrija la capa que falla, no Search Console.
6. Verifique la recuperación. Vuelva a ejecutar las comprobaciones públicas y las directas al origin en URL representativas. Si las respuestas 2xx son estables, monitorice los logs y Search Console mientras Googlebot reanuda el rastreo automáticamente. Si los 502 vuelven a aparecer, regrese al paso 4 con las nuevas marcas de tiempo en lugar de aumentar los reintentos a ciegas.

Prompt: clasificar un lote de fallos 502 por capa

Pegue un CSV que contenga la URL, la marca de tiempo, el código de estado, las cabeceras de respuesta, el resultado en el edge público, el resultado directo al origin y cualquier extracto de log coincidente. Elimine primero los secretos, las cookies, las cabeceras de autorización y las direcciones privadas del origin.

You are triaging HTTP 502 Bad Gateway failures. A 502 means a gateway or proxy
received an invalid response from an upstream server. Classify each row as one of:
CDN/edge, reverse proxy or load balancer, origin application/server, local-only,
provider-wide outage, or insufficient evidence.

For every row:
1. Cite the exact supplied evidence that supports the classification.
2. State the next check that would distinguish the leading cause from the runner-up.
3. Do not infer a cause from the 502 code alone.
4. Flag cases where the public edge fails but a same-host direct-origin test succeeds.
5. Group failures that share a timestamp, header fingerprint, or upstream log error.

Return a table with URL, likely layer, confidence (high/medium/low), evidence, next
check, and incident group. End with the three highest-value checks for the batch.

DATA:
[PASTE SANITIZED CSV HERE]

Espere una cola de triaje, no un informe definitivo de causa raíz. Valide cada comprobación sugerida contra las cabeceras y los logs en vivo.

Reproducir el 502 público

Ejecute esto en un shell de macOS/Linux. Imprime las cabeceras de respuesta sin descargar el cuerpo y no sigue redirecciones, de modo que usted ve la primera respuesta.

curl -sS -D - -o /dev/null https://www.example.com/affected-path

Equivalente en PowerShell:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -Method Head -SkipHttpErrorCheck

Si la aplicación trata HEAD de forma distinta, use un GET normal y descarte el cuerpo:

Invoke-WebRequest -Uri 'https://www.example.com/affected-path' -SkipHttpErrorCheck | Select-Object StatusCode, Headers

Comparar la ruta del CDN con el origin conocido

Sustituya 203.0.113.10 por una IP de origin que usted controle. --resolve mantiene el nombre de host público para la cabecera HTTP Host y para el nombre TLS mientras conecta con esa IP.

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/affected-path

No exponga un origin protegido ni debilite su firewall solo para ejecutar esta prueba. Ejecútela desde una red ya autorizada. Un 502 público junto con un acceso directo al origin correcto reduce el fallo a la ruta del CDN o del proxy; un fallo en ambas rutas le orienta hacia el origin o la aplicación.

Herramientas para acotar un 502

• Website Down Checker — confirme si la URL es accesible desde un punto de observación externo de Cloudflare y capture datos de tiempos, redirecciones y evidencias acotadas de DNS. Responde a «¿esto solo me pasa a mí?» antes de que empiece a cambiar la infraestructura.
• Bulk HTTP Status Code Checker — pruebe un conjunto representativo de URL, vea las rutas de redirección completas y la latencia, y exporte los resultados. Úselo para separar el fallo de una única ruta de un incidente de 502 más amplio.
• El panel de su CDN o de su load balancer — haga coincidir los identificadores de solicitud y las marcas de tiempo de la respuesta fallida con los logs del edge y con el estado del proveedor.
• Los logs de la aplicación y del servidor origin — confirme si el upstream aceptó la solicitud y si devolvió, reinició o malformó la respuesta. Esto es lo que convierte una hipótesis de capa en una causa raíz.

Ninguna herramienta puede identificar la capa que falla solo a partir de un 502. Compare las evidencias del edge público con una solicitud directa al origin autorizada y con logs con marca de tiempo.

Compruébelo usted mismo: 502 Bad Gateway

Cinco preguntas rápidas sobre qué es un 502 y cómo afecta al SEO. Elija una respuesta para cada una y después compruébelas.

Recursos que merecen su tiempo

Mis artículos relacionados

• Guía completa de códigos de estado HTTP para SEO — dónde encajan el 502 y el resto de la familia 5xx, y qué señala cada código a los motores de búsqueda.
• Guía para principiantes de SEO técnico — cómo se conectan la salud del servidor y el rastreo con el panorama general.
• Robots.txt y SEO: todo lo que debes saber — relevante porque un 5xx en su archivo robots.txt se gestiona de forma especial.

Del sector

• Cómo afectan los códigos de estado HTTP a los rastreadores de Google (Centro de la Búsqueda de Google) — la fuente primaria: 502 (bad gateway) agrupado con el 500 y el 503, y la formulación exacta sobre frecuencia de rastreo e indexación.
• Cómo gestionar el tiempo de inactividad planificado (Centro de la Búsqueda de Google) — la distinción entre 503 y 502 y por qué el 503 es el código para una caída intencionada.
• Interrupción de Cloudflare: picos de 5xx y lo que significan para SEO (Matt G. Southern, Search Engine Journal) — la interrupción de noviembre de 2025 como caso práctico real, con los comentarios de Mueller.
• 502 Bad Gateway: referencia de MDN (MDN Web Docs) — la definición neutral del código de estado a nivel de especificación.
• RFC 9110 §15.6.3 — 502 (Bad Gateway) (IETF) — la especificación subyacente de la semántica de HTTP.
• Cómo corregir un error 502 Bad Gateway (Kinsta) — un recorrido exhaustivo de resolución de problemas desde la óptica de un hosting, para las correcciones del navegador y del propietario del sitio.
• 502 bad gateway: qué significa y cómo pueden corregirlo los desarrolladores web (Webflow) — una visión general de causas y soluciones orientada a desarrolladores.

Registro de cambios