Error 504 Gateway Timeout

TL;DR — Un 504 Gateway Timeout significa que algo situado delante de su sitio web —un CDN, un load balancer o un proxy— esperó a que su servidor respondiera y se rindió porque la respuesta tardó demasiado. Es un timeout, no una respuesta defectuosa. Un 504 aislado de vez en cuando no es grave; el problema aparece cuando se repiten, porque los motores de búsqueda le rastrearán menos y, con el tiempo, retirarán páginas del índice.

Qué significa realmente un 504

Cuando se carga una página, la solicitud a menudo no llega directamente a su servidor web. Lo habitual es que pase primero por un gateway: un CDN, un load balancer o un reverse proxy. Ese gateway reenvía la solicitud al servidor que tiene detrás (el upstream o el origin), espera una respuesta y se la devuelve.

Un 504 Gateway Timeout es lo que devuelve el gateway cuando esperó esa respuesta del upstream y no la recibió a tiempo. El origin puede estar procesando lentamente una consulta a base de datos, esperando a una API de terceros o simplemente sobrecargado, pero desde el punto de vista del gateway se agotó el tiempo. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

La palabra clave es timeout. No necesariamente había nada «roto»: la respuesta simplemente no llegó lo bastante rápido.

En qué se diferencia de sus hermanos 5xx

Se confunden constantemente:

• 502 Bad Gateway: el gateway sí recibió una respuesta del origin, pero era inválida o estaba corrupta.
• 503 Service Unavailable: el servidor declaró explícitamente «no estoy disponible ahora mismo» (a menudo de forma intencionada, como en una ventana de mantenimiento).
• 504 Gateway Timeout: el gateway no recibió una respuesta a tiempo del upstream. Es una afirmación más restringida que «no llegó nada»: puede que el upstream siga trabajando en ello; simplemente no respondió dentro de la ventana de espera.

Así que un 504 es casi siempre un síntoma de rendimiento: algo en el upstream es demasiado lento.

¿Un 504 perjudica mi SEO?

No directamente, y no es una penalización. Google no está juzgando su contenido: literalmente no puede recuperar la página. Pero sí existe un costo indirecto real:

• Si Googlebot se topa continuamente con respuestas lentas y timeouts, reduce el ritmo y rastrea su sitio menos para no agravar la sobrecarga.
• Un 504 aislado durante un pico de tráfico se reintenta y en su mayor parte se ignora.
• Los 504 que se repiten durante días son los que provocan que se retiren páginas del índice, porque Google no puede recuperarlas de forma fiable. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Qué hacer al respecto

• Recargue una o dos veces: un 504 puntual puede ser solo un episodio aislado.
• Revise los logs de su servidor y de errores para ver qué iba lento (una consulta a base de datos, una API externa, un proceso de aplicación sobrecargado).
• No se limite a subir el valor del timeout y dar el trabajo por terminado: eso oculta la respuesta lenta en lugar de arreglarla (más sobre por qué, en la pestaña Avanzado).
• Mantenga su servidor rápido: caché, consultas más rápidas y capacidad suficiente son la verdadera prevención.

¿Quiere la versión técnica completa —dónde se origina un 504 en la cadena de solicitudes, cómo funciona la limitación del rastreo de Googlebot y por qué el TTFB es la métrica que hay que vigilar? Cambie a la pestaña Avanzado.

TL;DR — Un 504 es un gateway/proxy indicándole que el servidor upstream no respondió dentro de la ventana de timeout: un timeout, distinto de un 502 (respuesta defectuosa) o de un 503 (indisponibilidad explícita). Es un problema de accesibilidad, no una penalización. Los timeouts están en el mismo grupo que los 429/500/503: Googlebot reduce el ritmo cuando los detecta, y unos 504 sostenidos arriesgan la desindexación. La solución duradera es el tiempo de respuesta del servidor (TTFB), no un valor de timeout más alto: subir el timeout suele enmascarar un upstream lento y puede empeorar las cosas bajo carga.

Dónde se origina un 504 en la cadena de solicitudes

Una ruta de solicitud moderna se parece aproximadamente a esto: navegador → CDN/edge → load balancer → reverse proxy (por ejemplo, Nginx) → servidor de aplicación (PHP-FPM, Node, etc.) → base de datos / APIs de terceros. Un 504 lo genera el componente que estaba esperando al que tenía detrás cuando expiró su timeout. Esa es la primera pregunta diagnóstica: Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/edge agotando el tiempo con el origin → la solución es el rendimiento del origin, o subir el timeout de upstream del CDN (con cuidado; véase más abajo).
• Load balancer agotando el tiempo con el servidor de aplicación → revise el estado del servidor de aplicación y el autoescalado.
• Reverse proxy agotando el tiempo con el proceso de la aplicación → mire proxy_read_timeout / fastcgi_read_timeout de Nginx y la consulta o el proceso lento que en realidad está detrás.

Acertar con la capa importa, porque «arreglar el timeout en el edge» y «arreglar la consulta lenta a base de datos en el origin» son trabajos completamente distintos.

Diagnóstico del timeout 504

El código de estado por sí solo no demuestra una causa: solo indica que un gateway agotó el tiempo esperando a un upstream. Estos son los sospechosos habituales que conviene comprobar, no hechos que el 504 ya haya establecido; confírmelos con logs y trazas antes de actuar sobre alguno:

• Consultas lentas a base de datos o llamadas a APIs upstream. Una sola consulta sin índice o una dependencia de terceros con retardo puede llevar el tiempo de respuesta más allá del timeout.
• Sobrecarga del servidor o de la aplicación y agotamiento de recursos. Con suficiente carga concurrente, las solicitudes se encolan, los procesos de trabajo se llenan y las respuestas dejan de llegar a tiempo.
• Valores de timeout mal configurados en Nginx, Apache, el load balancer o el CDN, a menudo descoordinados entre capas, de forma que una se rinde antes que otra.
• Picos de tráfico, avalanchas de bots o DDoS que desbordan temporalmente la capacidad.

Diagnóstico del timeout 504

Esto es lo que los hace desagradables. A diferencia de una caída total, un 504 aparece con frecuencia solo bajo carga, lo que significa que un monitor de disponibilidad que hace ping durante una ventana tranquila puede mostrar el 100 % en verde mientras Googlebot, que rastrea en ráfagas más intensas, acumula timeouts en silencio. En URL Inspection (Herramienta de inspección de URLs) de Google Search Console esto puede aparecer como una condición “Hostload exceeded” en lugar de un error limpio y constante. Si su monitorización dice que todo va bien pero Crawl Stats (Informe “Estadísticas de rastreo”) no está de acuerdo, los 504 dependientes de la carga son un sospechoso principal.

Cómo gestionan los timeouts Googlebot (y Bingbot)

Google no trata un 504 como un juicio sobre la calidad del contenido: es una señal de disponibilidad, y la respuesta es una limitación automática del rastreo. Su documentación sobre rastreo es explícita: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traducción) «Googlebot reducirá su rastreo si detecta que sus servidores tienen problemas para responder a las solicitudes de rastreo.» La guía de presupuesto de rastreo para sitios grandes dice lo mismo en términos de presupuesto: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traducción) «Si el sitio se ralentiza o responde con errores de servidor, el límite baja y Google rastrea menos.» Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

El planteamiento más reciente que conecta esto directamente con respuestas lentas o con timeout procede del explicativo Inside Googlebot de Google de marzo de 2026, donde se cita a Gary Illyes diciendo: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traducción) «Si su servidor tiene dificultades para servir bytes, nuestros rastreadores se echarán atrás automáticamente para evitar sobrecargar su infraestructura, lo que reducirá su frecuencia de rastreo.» (Según la cobertura de Search Engine Land; conviene confirmarlo con la grabación o la transcripción original si lo cita en otro sitio.) Un 504 es esa dificultad hecha visible.

Un matiz que conviene entender: Google no siempre ve un «504» literal como lo ve su navegador. Si el timeout ocurre antes de que Googlebot reciba cualquier línea de estado, se registra como un error de timeout o de red en Crawl Stats (Informe “Estadísticas de rastreo”) en lugar de como un 5XX limpio. Pero cuando un proxy o CDN intermediario agota el tiempo y genera su propia respuesta 504, Googlebot recibe un error de servidor 5XX estándar. En cualquier caso el efecto es idéntico: frecuencia de rastreo limitada y, si se mantiene, retirada del índice.

Bing documenta los timeouts como una categoría propia de error de rastreo, separada de los errores de servidor —Bingbot deja de intentar acceder a las páginas cuando las respuestas son demasiado lentas— y su recomendación habitual es comprobar el tiempo de respuesta del servidor, mantener actualizado el software del servidor, optimizar los recursos lentos y leer los logs del servidor buscando patrones sistémicos en lugar de episodios aislados. Bing no ha publicado el mismo nivel de detalle sobre limitación y recuperación que Google, así que considere que ambos son ampliamente comparables en su intención, no que esté confirmado que se comporten de forma idéntica.

El bucle de retroalimentación de limitar y luego recuperar

La parte tranquilizadora: este bucle es automático y autocorrectivo. Google reduce el ritmo cuando ve errores y timeouts, y después vuelve a aumentar el rastreo de forma gradual en cuanto las respuestas vuelven a ser saludables. No hay ningún botón manual de «quitar la limitación» que haya que pulsar una vez corregido el problema de fondo: como señaló John Mueller, “Once things settle down on the server, the crawl rate will return to normal automatically.” (traducción) «Una vez que las cosas se calmen en el servidor, la frecuencia de rastreo volverá a la normalidad automáticamente.» También señaló la asimetría: la reducción del ritmo se produce rápido para resolver un problema inmediato; el aumento posterior se hace con cautela.

La duración es lo que convierte un episodio aislado en un problema de indexación

Los 504 breves y ocasionales —unos pocos durante un pico, resueltos rápidamente— se reintentan y en gran medida se toleran. Lo que arriesga la desindexación es un patrón sostenido de timeouts durante una ventana prolongada. La mecánica documentada de «vuelve más tarde» de Google —en la que se devuelve intencionadamente un 503 o un 429 durante una sobrecarga— describe un horizonte de aproximadamente dos días antes de que las URL empiecen a caer, pero esa cifra concreta está documentada para el 503/429 por su nombre, no para el 504. La guía más amplia de Google sobre 5xx dice que la frecuencia de rastreo baja de forma proporcional al número de URL que devuelven errores y se recupera gradualmente en cuanto las respuestas son saludables, sin nombrar un horizonte fijo para el 504 en concreto. Extender la cifra de dos días al 504 es una inferencia razonable, no un hecho documentado: interprételo así: los 504 breves son sobrellevables, y un patrón sostenido durante días es el rango en el que debería preocuparse, no una fecha de activación garantizada.

Por qué esto importa más en sitios grandes y de ecommerce

La solución debe ser medible: pruebe el origin, compare el TTFB y compruebe los códigos devueltos en condiciones reales (referencia de este apartado 39)..

El tiempo de respuesta del servidor y el TTFB son una palanca preventiva potente — para las causas del lado del origin

Este es un punto que la mayoría de los artículos sobre el 504 pasan por alto: esperar a que aparezcan los errores y luego rebuscar en los logs es reactivo. Monitorizar el tiempo de respuesta del servidor de forma continua, para ver la deriva antes de que se convierta en un timeout, es proactivo. Un servidor que hoy es lento pero todavía no agota el tiempo será mañana un servidor que genera 504 con algo más de carga o con una dependencia algo más lenta. Vigilar el TTFB (time to first byte, tiempo hasta el primer byte) como señal continua de alerta temprana —no solo como métrica post mortem— es la forma de detectar esa deriva.

La advertencia: la monitorización del TTFB aborda la lentitud del lado del origin. No detectará un CDN que agota el tiempo con un origin saludable, un load balancer mal configurado que se rinde demasiado pronto, ni un problema en la ruta de red entre saltos; para eso hace falta identificar primero el salto que emite el error (la sección «Dónde se origina un 504» de más arriba, o el árbol de decisión de más abajo). El TTFB es una solución real y duradera para el caso común de un upstream genuinamente lento; no es universal. Una vez que haya confirmado que el origin es el cuello de botella, optimice con caché (de página, de objetos y de CDN), consultas a base de datos más rápidas e indexación adecuada, autoescalado para la carga y un ajuste sensato del upstream del CDN.

Por qué «simplemente subir el timeout» es el instinto equivocado

Aumentar proxy_read_timeout o el timeout de upstream del CDN puede evitar que aparezca el 504, pero no hace que la respuesta del upstream sea más rápida. Peor aún: bajo carga, una ventana de timeout más larga significa que las solicitudes se acumulan y ocupan procesos de trabajo y conexiones durante más tiempo, lo que puede agravar una espiral de sobrecarga en lugar de mejorarla. Subir el timeout es de vez en cuando la decisión correcta (para una operación genuinamente larga y bien comprendida), pero como reflejo enmascara el problema real.

Cuando la caída es planificada o se está desechando carga deliberadamente, la herramienta correcta no es dejar que las páginas devuelvan 504, sino devolver un 503 (con una cabecera Retry-After) para enviar a los motores de búsqueda un «vuelve más tarde» limpio e intencionado en lugar de un timeout desordenado.

Diagnosticar un 504 en la práctica

Identifique el salto que emite el error antes de conjeturar una causa: esa es la diferencia entre arreglar el problema real y arreglar un síntoma:

• Reprodúzcalo e identifique qué salto respondió. Cárguelo en un navegador; llámelo con curl y observe time_starttransfer para el TTFB; páselo por un rastreador como Ahrefs Site Audit o Screaming Frog para ver si es un problema de todo el sitio o aislado. Si puede, pruebe directamente contra el origin (evitando el CDN/proxy) para ver si el propio origin completa la respuesta.
• Lea los logs. Los logs del servidor y del proxy le dicen qué capa agotó el tiempo y, en el mejor caso, esperando qué: la consulta lenta, el upstream atascado, el pool de procesos de trabajo agotado. Correlacione por marca de tiempo e ID de solicitud entre capas en lugar de suponerlo.
• Revise Search Console. Crawl Stats (Informe “Estadísticas de rastreo”) muestra los picos de códigos de respuesta y el tiempo medio de respuesta; el Page Indexing report (Informe “Indexación de páginas”) y URL Inspection (Herramienta de inspección de URLs) indican si Google se está topando con timeouts (incluido “Hostload exceeded”).

Reconciliar las herramientas importa: un 504 en el navegador, un 5xx en Ahrefs Site Audit y un timeout en GSC pueden describir todos el mismo origin lento subyacente visto desde puntos de observación distintos. No dé por hecho que tres herramientas significan tres problemas.

Códigos relacionados

Un 504 vive en una familia pequeña. Un 500 es un error de servidor genérico sin un código más específico; un 502 es una respuesta del upstream defectuosa o corrupta; un 503 es un «no disponible» explícito y a menudo intencionado. Saber cuál está devolviendo realmente —y devolver el correcto a propósito durante una caída planificada— es media batalla ganada.

Resumen con IA

Un resumen condensado de la versión Avanzado:

• Un 504 = un timeout, no una respuesta defectuosa. Un gateway/proxy (CDN, load balancer, reverse proxy) esperó al servidor upstream y no obtuvo una respuesta a tiempo, no necesariamente «ninguna respuesta nunca». Distinto de un 502 (respuesta defectuosa) y de un 503 (indisponibilidad explícita). El código de estado por sí solo no demuestra qué salto ni qué causa; identifique el salto que lo emite antes de arreglar nada.
• No es una penalización. Es un problema de accesibilidad: Google no puede recuperar la página, así que la pérdida de posiciones o de indexación es una consecuencia derivada, no un castigo.
• Los timeouts desencadenan la limitación del rastreo. Google: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding.” (traducción) «Googlebot reducirá su rastreo si detecta que sus servidores tienen problemas para responder.» Se cita a Gary Illyes (a través de la cobertura de Search Engine Land de marzo de 2026) describiendo que los servidores con dificultades hacen que los fetchers “automatically back off … which will drop your crawl frequency.” (traducción) «se echen atrás automáticamente… lo que reducirá su frecuencia de rastreo.»
• La duración importa, pero la cifra de «2 días» no es el número documentado de Google para el 504. Ese horizonte está documentado para el 503/429 devuelto intencionadamente durante una sobrecarga. La guía más amplia de Google sobre 5xx dice que la frecuencia de rastreo baja de forma proporcional y se recupera gradualmente, sin nombrar un plazo fijo para el 504 en concreto: los 504 aislados se reintentan y se toleran; un patrón sostenido durante una ventana prolongada es el rango que arriesga la desindexación.
• El bucle es autocorrectivo. Una vez que las respuestas se recuperan, la frecuencia de rastreo vuelve automáticamente; no hace falta quitar la limitación a mano.
• A menudo intermitente o dependiente de la carga: invisible para los monitores de disponibilidad que hacen ping en ventanas tranquilas; puede mostrarse como “Hostload exceeded” en URL Inspection (Herramienta de inspección de URLs).
• El tiempo de respuesta del servidor (TTFB) es una palanca preventiva potente para las causas del lado del origin, monitorizado como señal de alerta temprana, pero no es universal: un 504 también puede originarse en la capa del CDN, del load balancer o del proxy, así que confirme primero qué salto está agotando el tiempo. Subir el valor del timeout no es una solución en ningún caso: enmascara el upstream lento y puede empeorar la sobrecarga.
• Cuando la caída es planificada, devuelva un 503 con Retry-After, no un 504.

Documentación oficial

Documentación de fuentes primarias sobre timeouts, errores de servidor y cómo responden los rastreadores.

Definición

• MDN — 504 Gateway Timeout — la definición autorizada y en qué se diferencia de un 502.

Google

• Troubleshoot crawling errors — cómo Googlebot reduce el ritmo ante problemas del servidor, y cuándo devolver 503/429 en caso de sobrecarga.
• Optimize your crawl budget — cómo las respuestas lentas y los errores de servidor bajan el límite de rastreo.
• Crawl Stats report — las categorías “Server error (5XX)” y “Page timeout”, y cómo Googlebot limita el rastreo para evitar la sobrecarga.

Bing / Microsoft

• Bing Webmaster Tools — crawl error alerts — cómo Bing marca los errores de servidor y los timeouts como categorías de error de rastreo separadas.

Citas de la fuente

Declaraciones oficiales. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

MDN: la definición

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (traducción) «El código de estado de respuesta de error de servidor HTTP 504 Gateway Timeout indica que el servidor, actuando como gateway o proxy, no obtuvo a tiempo una respuesta del servidor upstream para completar la solicitud. Es similar a un 502 Bad Gateway, salvo que en un estado 504 el proxy o gateway no recibió ninguna respuesta HTTP del origin en un tiempo determinado.» Ir a la cita

Google: rastreo y timeouts

• La solución debe ser medible: pruebe el origin, compare el TTFB y compruebe los códigos devueltos en condiciones reales (referencia de este apartado 71).. Elementos conservados: https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors#:~:text=Googlebot%20will%20scale%20back%20its%20crawling%20if%20it%20detects%20that%20your%20servers%20are%20having%20trouble%20responding%20to%20crawl%20requests, https://developers.google.com/crawling/docs/crawl-budget#:~:text=If%20the%20site%20slows%20down%20or%20responds%20with%20server%20errors%2C%20the%20limit%20goes%20down%20and%20Google%20crawls%20less Fuente original Fuente original

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traducción) «Si su servidor tiene dificultades para servir bytes, nuestros rastreadores se echarán atrás automáticamente para evitar sobrecargar su infraestructura, lo que reducirá su frecuencia de rastreo.» Ir a la cita

John Mueller, Google (en Reddit, recogido por Search Engine Journal, agosto de 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (traducción) «Solo esperaría que la frecuencia de rastreo reaccionara tan rápido si estuvieran devolviendo 429 / 500 / 503 / timeouts.» Ir a la cita Search Engine Journal reproduce la respuesta de Mueller en Reddit y su contexto.

Lista de comprobación de tiempo de respuesta del servidor / TTFB

El objetivo es mantener las respuestas lo bastante rápidas para que nunca se dispare un 504, y detectar la deriva antes de que ocurra. Recórralo de arriba abajo:

• Establezca una línea base de TTFB con curl -w "%{time_starttransfer}" (o un monitor sintético) y registre qué aspecto tiene lo «normal» por plantilla.
• Monitorice el TTFB de forma continua, no solo después de un incidente: alerte sobre la deriva al alza, no solo sobre los fallos duros.
• Haga pruebas de carga con concurrencia realista (y de pico): los 504 suelen depender de la carga, así que una comprobación en una ventana tranquila no los revelará.
• Perfile el trabajo upstream más lento: consultas a base de datos sin índice, consultas N+1 y llamadas bloqueantes a APIs de terceros son los culpables habituales.
• Use caché de forma agresiva —caché de página, caché de objetos y caché en el edge del CDN— para que la mayoría de las solicitudes nunca toquen la ruta lenta.
• Compruebe que los valores de timeout son coherentes entre capas (CDN, load balancer, proxy_read_timeout / fastcgi_read_timeout de Nginx, aplicación) para que una capa no se rinda antes que otra.
• Confirme el autoescalado y el margen de capacidad para picos de tráfico y de rastreo.
• Revise Crawl Stats (Informe “Estadísticas de rastreo”) en GSC buscando picos de timeouts y de 5XX y un tiempo medio de respuesta al alza.
• Revise los logs del servidor y del proxy para identificar qué capa está agotando el tiempo y esperando qué.
• Verifique que la monitorización de disponibilidad cubre la carga máxima, no solo pings en horas de baja actividad.
• Use 503 + Retry-After para las caídas planificadas en lugar de dejar que las páginas devuelvan 504.

Mitos y errores sobre el 504 que conviene evitar

Las trampas más frecuentes; varias de ellas son mitos muy repetidos que conviene corregir:

• «Un 504 es una penalización de Google». No. Es un problema de accesibilidad y de rastreabilidad, no una acción algorítmica. Google no está juzgando su contenido: no puede recuperar la página. Cualquier pérdida de posiciones es una consecuencia derivada de la inaccesibilidad, no un castigo.
• «Cualquier 504 hará que mi página se desindexe de inmediato». No. Los 504 breves y ocasionales se reintentan y se toleran. Son los 504 sostenidos y frecuentes durante una ventana prolongada los que arriesgan la desindexación.
• «El 504 y el 503 son básicamente lo mismo: se pueden usar indistintamente». No. Un 503 puede ser una señal deliberada y controlada (Google admite explícitamente el 503 para caídas planificadas); un 504 es un timeout, casi siempre no planificado y sintomático de un upstream lento. Durante una caída planificada, devuelva un 503 con Retry-After; no deje que las páginas devuelvan 504.
• «Es Googlebot, que es demasiado agresivo». Normalmente es al revés. Un servidor que devuelve 504 de forma constante a la frecuencia de rastreo de Googlebot también se degradará para usuarios reales con una carga similar. El timeout está exponiendo un problema genuino de capacidad o de rendimiento (existen escenarios de “Hostload exceeded”, pero son la excepción, no la regla).
• «Arreglarlo consiste simplemente en subir el valor del timeout». Subir proxy_read_timeout enmascara un upstream lento en lugar de arreglarlo, y bajo carga un timeout más largo mantiene ocupados los procesos de trabajo durante más tiempo, lo que puede empeorar una sobrecarga. Arregle la respuesta lenta; no amplíe la paciencia con ella.
• «La monitorización de disponibilidad dice que estamos en verde, así que no tenemos un problema de 504». Los 504 dependen con frecuencia de la carga. Un monitor que hace ping durante una ventana tranquila puede pasar por alto los timeouts que Googlebot acumula durante ráfagas de rastreo más intensas. Fíese de Crawl Stats (Informe “Estadísticas de rastreo”) y de los logs antes que de pings en horas de baja actividad.

¿Qué capa está agotando el tiempo?

Prompt: clasificar un lote de incidentes de 504

Pegue filas saneadas con la URL, la marca de tiempo, las cabeceras de respuesta, el TTFB o el tiempo total, el resultado en el edge público, el resultado directo contra el origin, la traza de la aplicación, los tiempos de base de datos y las señales de recursos. No pegue credenciales, cookies, direcciones privadas ni datos de usuarios.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Trate el resultado como una cola de hipótesis. Confírmelo con la telemetría del gateway, de la aplicación, de la base de datos y de la infraestructura.

Medir el código de estado y el tiempo hasta el primer byte

Ejecute esto en un shell de macOS/Linux. Informa del código de respuesta final y del TTFB de una única solicitud sin imprimir el cuerpo.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Repítalo unas cuantas veces para ver si el timeout es constante o depende de la carga:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

Equivalente en PowerShell:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

La versión de PowerShell mide el tiempo total de la solicitud, no el TTFB. Use el comando de shell o la telemetría de su aplicación cuando necesite el desglose del primer byte.

Diagnóstico del timeout 504

• Website Down Checker — comprueba la accesibilidad desde un punto de observación externo y captura evidencia acotada de tiempos de respuesta, redirecciones y DNS. Úselo para determinar si el incidente es reproducible públicamente.
• Bulk HTTP Status Code Checker — comprueba un conjunto representativo de rutas, compara la latencia y exporta el subconjunto que falla. Ayuda a separar un endpoint lento de un problema de upstream en todo el sitio.
• Logs del CDN o del load balancer — localice el gateway que emitió el 504 y correlacione su ID de solicitud y su timeout con el intento contra el upstream.
• Trazado de la aplicación y logs de consultas lentas de la base de datos — muestran en qué gastó su tiempo la solicitud después de llegar al origin.
• Monitorización de la infraestructura — compare la ventana del incidente con la saturación de CPU, memoria, pool de procesos de trabajo, conexiones y dependencias, en lugar de conjeturar a partir del código de estado.

TTFB por ruta y percentil

Métrica: tiempo hasta el primer byte de rutas representativas, segmentado por percentiles útiles en lugar de solo por una media.

Qué le indica: una latencia de cola creciente es una alerta temprana de que las solicitudes se están acercando al timeout de un gateway incluso antes de que empiecen a devolver 504.

Cómo obtenerla: use monitorización de usuarios reales o del servidor, o los logs del gateway; use el script de curl de la pestaña Scripts para comprobaciones puntuales, no como sustituto de la telemetría de producción.

Referencia / rango realista: establezca una línea base por ruta y por ruta de infraestructura. La alerta significativa es un cambio sostenido respecto a esa línea base o un movimiento hacia el timeout de gateway que tenga realmente configurado, no una cifra universal de SEO.

Cadencia: monitorice de forma continua; revise las tendencias por ruta cada semana y en cada incidente de 504.

Tasa de respuestas 504

La solución debe ser medible: pruebe el origin, compare el TTFB y compruebe los códigos devueltos en condiciones reales (referencia de este apartado 119)..

Qué le indica: si los timeouts son aislados, están concentrados en una ruta o son lo bastante amplios como para afectar al rastreo y a los usuarios.

Cómo obtenerla: agregue los logs de acceso del CDN, del load balancer o del servidor por código de estado y por dimensiones de la solicitud.

Referencia / rango realista: el objetivo saludable es no tener 504 sin explicación. Para ajustar la sensibilidad de las alertas, usa tu propia línea base normal sin incidentes, porque la mezcla de tráfico y el comportamiento de los reintentos varían según la pila.

Cadencia: alerte de forma continua; revise a diario durante la recuperación y en el informe semanal habitual de fiabilidad.

Finalización del upstream frente al timeout del gateway

Métrica: la distribución de los tiempos de finalización del upstream comparada con el timeout configurado en cada salto.

Qué le indica: si el trabajo lento se está acercando realmente al límite o si un timeout de gateway más corto está cortando respuestas del upstream que por lo demás son saludables.

Cómo obtenerla: una los campos de tiempos del gateway con las trazas de la aplicación mediante un ID de solicitud o de traza.

Referencia / rango realista: mantenga la finalización normal cómodamente dentro del límite configurado, con margen para la variación esperada. Defina ese margen a partir de las distribuciones observadas en producción; no invente un porcentaje genérico.

Cadencia: revísela después de cambios de configuración o de dependencias y siempre que suban la latencia de cola o la tasa de 504.

Compruebe sus conocimientos: 504 Gateway Timeout

Cinco preguntas rápidas sobre qué significa un 504 y cómo afecta al rastreo. Elija una respuesta para cada una y luego compruébelas.

Recursos que merecen su tiempo

Mis artículos relacionados

• La guía para principiantes de SEO técnico: cómo encajan la salud del servidor y la rastreabilidad en el panorama general.
• Conoce a los nuevos rastreadores web: los bots de IA se acercan a los bots de los motores de búsqueda: quién está accediendo realmente a tu servidor y por qué importa la carga.

Mis ponencias

• How Search Works (SlideShare) — mi recorrido por el rastreo, el renderizado, la indexación y el ranking, incluido cómo las respuestas del servidor gobiernan la frecuencia de rastreo. (Se aplica mi advertencia habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni exacta».)

De todo el sector

• MDN — 504 Gateway Timeout — la definición canónica y la diferencia frente al 502.
• Google — Solucionar errores de rastreo — cómo Googlebot reduce el ritmo ante problemas del servidor.
• Google — Gestionar el presupuesto de rastreo para sitios grandes — cómo las respuestas lentas reducen el límite de rastreo.
• Google explica cómo funciona el rastreo en 2026 (Search Engine Land) — la cita de Illyes que relaciona los servidores con problemas con una menor frecuencia de rastreo.
• ¿Bajón del rastreo de Googlebot? Mueller señala errores del servidor (Search Engine Journal) — Mueller agrupa los timeouts con 429 / 500 / 503 como los errores que reducen rápidamente la frecuencia de rastreo.
• Cómo solucionar el error 504 Gateway Timeout (Kinsta) — una guía técnica sólida del lado del hosting sobre la cadena de la solicitud y el diagnóstico en los logs.

Vídeos

• Google Search Central (YouTube) — la serie How Google Search Works y las explicaciones de Martin Splitt sobre el rastreo, útiles para ver cómo interactúan las respuestas del servidor y la frecuencia de rastreo. Canal

Registro de cambios