504 Ağ Geçidi Zaman Aşımı

TL;DR — 504 Ağ Geçidi Zaman Aşımı, web sitenizin önündeki bir şeyin — CDN’nin, yük dengeleyicinin veya proxy’nin — sunucunuzun yanıt vermesini bekleyip yanıt çok uzun sürdüğü için vazgeçtiği anlamına gelir. Bu, bozuk bir yanıt değil, bir zaman aşımıdır. Arada bir görülen tekil bir 504 sorun değildir; sorun, bunlar tekrarladığında arama motorlarının sitenizi daha az taraması ve sonunda sayfaları düşürmesidir.

504 gerçekte ne anlama gelir

Bir sayfayı yüklediğinizde istek çoğu zaman doğrudan web sunucunuza ulaşmaz. Genellikle önce bir ağ geçidinden — CDN, yük dengeleyici veya ters proxy — geçer. Bu ağ geçidi isteği arkasındaki sunucuya (upstream veya origin) iletir, bir yanıt bekler ve yanıtı size geri gönderir.

Bir 504 Gateway Timeout, ağ geçidinin upstream yanıtını bekleyip zamanında alamadığında döndürdüğü yanıttır. Origin bir veritabanı sorgusunu yavaşça işliyor, üçüncü taraf bir API’yi bekliyor veya yalnızca aşırı yüklenmiş olabilir; ancak ağ geçidi açısından saat dolmuştur. 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

Buradaki anahtar kelime zaman aşımıdır. Bir şey mutlaka “bozulmuş” değildir. Yanıt yalnızca yeterince hızlı gelmemiştir.

5xx kardeşlerinden farkı

İnsanlar bunları sürekli birbirine karıştırır:

• 502 Bad Gateway — ağ geçidi origin’den bir yanıt aldı, ancak yanıt geçersiz veya bozuktu.
• 503 Service Unavailable — sunucu açıkça “Şu anda kullanılamıyorum” dedi (çoğu zaman bakım penceresi gibi kasıtlı olarak).
• 504 Gateway Timeout — ağ geçidi upstream’den zamanında bir yanıt alamadı. Bu, “hiçbir şey dönmedi” iddiasından daha dar bir iddiadır — upstream hâlâ çalışıyor olabilir; yalnızca bekleme penceresi içinde yanıt vermemiştir.

Bu nedenle 504 neredeyse her zaman bir performans belirtisidir: upstream’deki bir şey fazla yavaştır.

504 SEO’ma zarar verir mi?

Doğrudan vermez ve bu bir ceza değildir. Google içeriğinizi değerlendirmiyor; sayfayı kelimenin tam anlamıyla alamıyor. Ancak gerçek ve dolaylı bir maliyet vardır:

• Googlebot yavaş yanıtlarla ve zaman aşımlarıyla karşılaşmayı sürdürürse, yükü daha da artırmamak için geri çekilir ve sitenizi daha az tarar.
• Trafik artışı sırasında oluşan tek bir 504 yeniden denenir ve çoğunlukla göz ardı edilir.
• Günler boyunca tekrarlayan 504’ler, Google sayfaları güvenilir biçimde alamadığı için sayfaların dizinden çıkarılmasına yol açabilecek olanlardır. 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

Ne yapmalı?

• Bir veya iki kez yeniden yükleyin — tek seferlik bir 504 yalnızca kısa bir aksaklık olabilir.
• Neyin yavaş olduğunu (veritabanı sorgusu, harici API veya aşırı yüklenmiş uygulama süreci) görmek için sunucu ve hata günlüklerinizi kontrol edin.
• Zaman aşımı değerini artırıp işi bitmiş saymayın — bu, yavaş yanıtı düzeltmek yerine gizler (nedenini Advanced sekmesinde açıklıyoruz).
• Sunucunuzu hızlı tutun: önbellekleme, daha hızlı sorgular ve yeterli kapasite gerçek önlemlerdir.

İstek zincirinde bir 504’ün nereden kaynaklandığını, Googlebot’un tarama kısıtlamasının nasıl çalıştığını ve neden izlenecek metriğin TTFB olduğunu anlatan tam teknik sürümü mü istiyorsunuz? Advanced sekmesine geçin.

TL;DR — 504, upstream sunucunun zaman aşımı penceresi içinde yanıt vermediğini bildiren bir ağ geçidi/proxy yanıtıdır — 502’den (bozuk yanıt) veya 503’ten (açıkça kullanılamazlık) farklı bir zaman aşımıdır. Bu bir ceza değil, erişilebilirlik sorunudur. Zaman aşımları 429/500/503 ile aynı gruptadır: Googlebot bunları gördüğünde geri çekilir ve sürekli 504’ler dizinden çıkarılma riski yaratır. Kalıcı çözüm daha uzun bir zaman aşımı değeri değil, sunucu yanıt süresidir (TTFB); zaman aşımını artırmak genellikle yavaş upstream’i maskeler ve yük altında durumu kötüleştirebilir.

İstek zincirinde 504 nereden kaynaklanır?

Modern bir istek yolu kabaca şöyledir: tarayıcı → CDN/edge → yük dengeleyici → ters proxy (ör. Nginx) → uygulama sunucusu (PHP-FPM, Node vb.) → veritabanı / üçüncü taraf API’ler. Bir 504, zaman aşımı dolduğunda arkasındaki bileşeni beklemekte olan bileşen tarafından üretilir. İlk teşhis sorusu budur: 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

• Origin’de zaman aşımına uğrayan CDN/edge → çözüm origin performansını iyileştirmek veya CDN’nin upstream zaman aşımını dikkatle artırmaktır (aşağıya bakın).
• Uygulama sunucusunda zaman aşımına uğrayan yük dengeleyici → uygulama sunucusunun sağlığını ve otomatik ölçeklendirmeyi kontrol edin.
• Uygulama sürecinde zaman aşımına uğrayan ters proxy → Nginx’in proxy_read_timeout / fastcgi_read_timeout değerlerine ve bunların arkasındaki yavaş sorguya veya sürece bakın.

Doğru katmanı bulmak önemlidir; çünkü “uçta zaman aşımını düzeltmek” ile “origindeki yavaş veritabanı sorgusunu düzeltmek” tamamen farklı işlerdir.

504’lere ne sebep olur?

Durum kodunun kendisi bir nedeni kanıtlamaz — yalnızca bir ağ geçidinin upstream’i beklerken zaman aşımına uğradığını söyler. Bunlar kontrol etmeye değer olağan şüphelilerdir; 504 bunlardan birini zaten kanıtlamış değildir. Harekete geçmeden önce günlükler ve izlerle doğrulayın:

• Yavaş veritabanı sorguları veya upstream API çağrıları. Dizine eklenmemiş tek bir sorgu ya da geciken üçüncü taraf bağımlılığı yanıt süresini zaman aşımının ötesine itebilir.
• Sunucu/uygulama aşırı yükü ve kaynak tükenmesi. Yeterli eşzamanlı yük altında istekler kuyruğa girer, çalışan süreçleri dolar ve yanıtlar zamanında gelmemeye başlar.
• Nginx, Apache, yük dengeleyici veya CDN genelinde yanlış yapılandırılmış zaman aşımı değerleri — çoğu zaman katmanlar arasında uyumsuzdur ve biri diğerinden önce vazgeçer.
• Trafik artışları, bot akınları veya kapasiteyi geçici olarak aşan DDoS saldırıları.

504’ler çoğu zaman aralıklı ve yüke bağlıdır

Bunları kötü yapan şey budur. Kesin bir kesintinin aksine 504 çoğunlukla yalnızca yük altında görünür — bu da sessiz bir pencerede ping atan çalışma süresi izleyicisinin %100 yeşil gösterebilmesine karşın Googlebot’un daha yoğun tarama dalgalarında sessizce zaman aşımları toplaması anlamına gelir. Google Search Console’un URL Denetimi’nde bu durum temiz ve sürekli bir hata yerine “Hostload exceeded” koşulu olarak görünebilir. İzleme sisteminiz her şeyin yolunda olduğunu, ancak Tarama İstatistikleri aksini söylüyorsa, yük bağımlı 504’ler başlıca şüphelidir.

Googlebot (ve Bingbot) zaman aşımlarını nasıl ele alır?

Google 504’ü içerik kalitesine ilişkin bir yargı olarak görmez; bu bir erişilebilirlik sinyalidir ve yanıt otomatik kısıtlamadır. Tarama belgeleri açıkça şunu söyler: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (Türkçe çeviri) “Googlebot, sunucuların tarama isteklerine yanıt vermekte zorlandığını algılarsa taramayı azaltır.” Büyük site tarama bütçesi kılavuzu da bütçe açısından aynı şeyi söyler: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Türkçe çeviri) “Site yavaşlar veya sunucu hatalarıyla yanıt verirse sınır düşer ve Google daha az tarar.” 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

Yavaşlama ve zaman aşımlarıyla doğrudan bağlantı kuran en güncel çerçeve, Gary Illyes’in Mart 2026 tarihli Inside Googlebot açıklamasında aktarılan şu sözlerdir: “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.” (Türkçe çeviri) “Sunucu baytları sunmakta zorlanıyorsa tarayıcılarımız altyapınızı aşırı yüklememek için otomatik olarak geri çekilir; bu da tarama sıklığınızı düşürür.” (Search Engine Land’in haberinde aktarıldığı üzere — başka yerde alıntılayacaksanız özgün kayıt veya dökümle doğrulamanız gerekir.) 504, bu zorlanmayı görünür hâle getirir.

Anlaşılması gereken bir ayrıntı şudur: Google, tarayıcınızın gördüğü gibi her zaman kelimesi kelimesine bir “504” görmez. Zaman aşımı, Googlebot herhangi bir durum satırı almadan önce gerçekleşirse Tarama İstatistikleri’nde temiz bir 5XX yerine zaman aşımı/ağ hatası olarak kaydedilir. Ancak aradaki proxy veya CDN zaman aşımına uğrayıp kendi 504 yanıtını üretirse Googlebot standart bir 5XX sunucu hatası alır. Her iki durumda da etki aynıdır: kısıtlanan tarama hızı ve sürerse dizinden çıkarılma.

Bing, zaman aşımlarını sunucu hatalarından ayrı bir tarama hatası kategorisi olarak belgeler — yanıtlar çok yavaş olduğunda Bingbot sayfalara erişmeyi bırakır — ve sürekli önerisi sunucu yanıt süresini kontrol etmek, sunucu yazılımını güncel tutmak, yavaş kaynakları optimize etmek ve tek seferlik aksaklıklar yerine sistemik kalıpları görmek için sunucu günlüklerini okumaktır. Bing, Google’ın yayımladığı aynı ayrıntı düzeyinde kısıtlama ve toparlanma açıklaması yayımlamamıştır; bu nedenle ikisini niyet bakımından genel olarak karşılaştırılabilir, ancak aynı şekilde davrandığı doğrulanmış değil olarak ele alın.

Kısıtlama ve toparlanma geri bildirim döngüsü

Güven verici kısım şudur: Bu döngü otomatik ve kendi kendini düzeltir. Google hataları ve zaman aşımlarını gördüğünde kısıtlamayı azaltır, yanıtlar yeniden sağlıklı hâle geldiğinde taramayı kademeli olarak artırır. Altta yatan sorun düzeltildikten sonra basmanız gereken manuel bir “kısıtlamayı kaldır” düğmesi yoktur — John Mueller’in belirttiği gibi, “Once things settle down on the server, the crawl rate will return to normal automatically.” (Türkçe çeviri) “Sunucudaki durum sakinleştiğinde tarama hızı kendiliğinden normale döner.” Ayrıca asimetriye dikkat çekmiştir: acil bir sorunu çözmek için aşağı yönlü kısıtlama hızlı olur; yukarı yönlü artış temkinli yapılır.

Süre, kısa aksaklığı dizine ekleme sorununa dönüştürür

Kısa süreli, arada bir görülen ve hızlıca çözülen birkaç 504 yeniden denenir ve büyük ölçüde tolere edilir. Dizinden çıkarılma riski yaratan şey, uzun bir pencere boyunca sürdürülen zaman aşımı örüntüsüdür. Google’ın aşırı yük sırasında kasıtlı olarak 503 veya 429 döndürdüğünüz “daha sonra geri gel” mekanikleri, URL’lerin düşmeye başlamasından önce kabaca iki günlük bir ufuk tarif eder; ancak bu özel sayı 504 için değil, adıyla 503/429 için belgelenmiştir. Google’ın daha geniş 5xx kılavuzu, belirli bir 504 ufku adlandırmadan, tarama hızının hata veren URL sayısıyla orantılı düştüğünü ve yanıtlar sağlıklı hâle geldiğinde kademeli olarak toparlandığını söyler. İki günlük rakamı 504’e genişletmek makul bir çıkarımdır, belgelenmiş bir gerçek değildir — bunu şöyle ele alın: kısa 504’ler atlatılabilir; günler süren örüntü endişelenmeniz gereken aralıktır ve kesin bir tetiklenme tarihi değildir.

Büyük ve e-ticaret sitelerinde bu neden daha önemlidir?

Sayfaları yayımlandıkları gün taranan küçük bir siteniz varsa bunu neredeyse hiç fark etmezsiniz. Ancak büyük veya hızlı değişen sitelerde — büyük e-ticaret katalogları, haber siteleri, pazar yerleri — tarama bütçesi zaten kısıttır ve yoğun yük sırasında oluşan 504 dalgası, gerçekten yeniden taranması gereken sayfaların taramasını aç bırakabilir. Büyük ölçekte zaman aşımları ve tarama bütçesi aynı konuşmanın parçasıdır.

Sunucu yanıt süresi ve TTFB, origin kaynaklı nedenler için güçlü bir önleme aracıdır

Çoğu 504 makalesinin atladığı nokta şudur: Hatalar görünene kadar bekleyip sonra günlüklerde arama yapmak tepkiseldir. Sunucu yanıt süresini sürekli izlemek ve zaman aşımına dönüşmeden önceki kaymayı görmek proaktiftir. Bugün yavaş ama henüz zaman aşımına uğramayan bir sunucu, yarın biraz daha fazla yük veya biraz daha yavaş bir bağımlılık altında 504 üreten bir sunucuya dönüşür. TTFB’yi (ilk bayta kadar geçen süreyi) yalnızca sonradan incelenen bir metrik olarak değil, sürekli bir erken uyarı sinyali olarak izlemek bu kaymayı yakalamanın yoludur.

Uyarı: TTFB izleme origin tarafındaki yavaşlığı ele alır. Sağlıklı bir origin’de zaman aşımına uğrayan CDN’yi, çok erken vazgeçmek üzere yanlış yapılandırılmış yük dengeleyiciyi veya atlamalar arasındaki ağ yolu sorununu yakalamaz — bunlar önce yanıtı üreten atlamanın belirlenmesini gerektirir (yukarıdaki “504 nereden kaynaklanır” bölümü veya aşağıdaki karar ağacı). TTFB, gerçekten yavaş bir upstream için gerçek ve kalıcı bir çözümdür; evrensel değildir. Origin’in darboğaz olduğunu doğruladıktan sonra önbellekleme (sayfa, nesne ve CDN), daha hızlı veritabanı sorguları ve doğru dizinleme, yük için otomatik ölçeklendirme ve makul CDN upstream ayarlarıyla optimize edin.

“Zaman aşımını artır” neden yanlış içgüdüdür?

proxy_read_timeout veya CDN’nin upstream zaman aşımını artırmak 504’ün görünmesini durdurabilir — ancak upstream yanıtını daha hızlı hâle getirmez. Daha da kötüsü, yük altında daha uzun bir zaman aşımı penceresi isteklerin birikmesi ve çalışan süreçleri ve bağlantıları daha uzun süre meşgul etmesi anlamına gelir; bu, aşırı yük sarmalını iyileştirmek yerine kötüleştirebilir. Zaman aşımını artırmak, gerçekten uzun süren ve iyi anlaşılan bir işlem için ara sıra doğru karar olabilir; ancak refleks olarak yapmak gerçek sorunu maskeler.

Kesinti planlanmışsa veya kasıtlı olarak yük azaltıyorsanız doğru araç sayfaların 504 vermesine izin vermek değildir — arama motorlarına karmaşık bir zaman aşımı yerine temiz ve kasıtlı bir “daha sonra gel” sinyali göndermek için 503 (Retry-After başlığıyla) döndürmektir.

Uygulamada 504 teşhisi

Bir nedeni tahmin etmeden önce yanıtı üreten atlamayı belirleyin — asıl sorunu düzeltmekle bir belirtiyi düzeltmek arasındaki fark budur:

• Yeniden üretin ve hangi atlamanın yanıt verdiğini belirleyin. Sayfayı tarayıcıda yükleyin; TTFB için time_starttransfer süresini izleyerek curl ile istekte bulunun; sitenin geneline mi yoksa tek bir yere mi özgü olduğunu görmek için Ahrefs Site Audit veya Screaming Frog gibi bir tarayıcıyla çalıştırın. Mümkünse origin’in kendisinin tamamlayıp tamamlamadığını görmek için doğrudan origin’i (CDN/proxy’yi atlayarak) test edin.
• Günlükleri okuyun. Sunucu ve proxy günlükleri hangi katmanın zaman aşımına uğradığını ve ideal olarak neyin yavaş olduğunu — yavaş sorgu, takılmış upstream, tükenmiş çalışan havuzu — söyler. Varsaymak yerine katmanlar arasında zaman damgası ve istek kimliğiyle ilişkilendirin.
• Search Console’u kontrol edin. Tarama İstatistikleri yanıt kodu artışlarını ve ortalama yanıt süresini gösterir; Sayfa Dizine Eklenme raporu ve URL Denetimi Google’ın zaman aşımlarıyla (“Hostload exceeded” dahil) karşılaşıp karşılaşmadığını gösterir.

Araçları uzlaştırmak önemlidir: tarayıcıdaki bir 504, Ahrefs Site Audit’teki bir 5xx ve GSC’deki bir zaman aşımı, farklı bakış noktalarından görülen aynı temel yavaş origin’i anlatabilir. Üç aracın üç sorun anlamına geldiğini varsaymayın.

İlgili kodlar

504 küçük bir ailenin parçasıdır. 500, daha özel bir kodu olmayan genel bir sunucu hatasıdır; 502, bozuk veya geçersiz bir upstream yanıtıdır; 503, açıkça ve çoğu zaman kasıtlı olarak “kullanılamıyor” demektir. Aslında hangisini döndürdüğünüzü bilmek — ve planlı kesinti sırasında kasıtlı olarak doğru olanı döndürmek — mücadelenin yarısıdır.

AI özeti

Advanced sürümünün özeti:

• 504 = bozuk yanıt değil, zaman aşımıdır. Bir ağ geçidi/proxy (CDN, yük dengeleyici, ters proxy) upstream sunucuyu bekledi ve zamanında yanıt alamadı — bu, “hiç yanıt gelmediği” anlamına gelmez. 502 (bozuk yanıt) ve 503’ten (açıkça kullanılamazlık) farklıdır. Durum kodu tek başına hangi atlamanın veya nedenin söz konusu olduğunu kanıtlamaz; herhangi bir şeyi düzeltmeden önce yanıtı üreten atlamayı belirleyin.
• Bu bir ceza değildir. Bu bir erişilebilirlik sorunudur — Google sayfayı alamaz; sıralama/dizine ekleme kaybı cezalandırmanın değil, bunun sonraki sonucudur.
• Zaman aşımları tarama kısıtlamasını tetikler. Google şöyle der: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding.” (Türkçe çeviri) “Googlebot, sunucuların yanıt vermekte zorlandığını algıladığında tarama yoğunluğunu düşürür.” Gary Illyes, Search Engine Land’in Mart 2026 haberinde aktarıldığı üzere, zorlanan sunucuların getiricilerin “automatically back off … which will drop your crawl frequency” (Türkçe çeviri) “otomatik olarak geri çekilir; bunun sonucu tarama sıklığınız azalır” yapmasına neden olduğunu belirtir.
• Süre önemlidir, ancak “2 gün” rakamı Google’ın 504 için belgelenmiş sayısı değildir. Bu ufuk, aşırı yük sırasında kasıtlı olarak döndürülen 503/429 için belgelenmiştir. Google’ın daha geniş 5xx kılavuzu tarama hızının orantılı biçimde düştüğünü ve kademeli olarak toparlandığını söyler; 504 için sabit bir süre vermez — tekil 504’ler yeniden denenip tolere edilir, uzun pencere boyunca sürdürülen örüntü dizinden çıkarılma riski taşır.
• Döngü kendi kendini düzeltir. Yanıtlar düzeldiğinde tarama hızı otomatik olarak geri gelir — manuel hız açma gerekmez.
• Çoğu zaman aralıklı/yüke bağlıdır — sessiz pencerelerde ping atan çalışma süresi izleyicilerinden kaçabilir; URL Denetimi’nde “Hostload exceeded” olarak görünebilir.
• Sunucu yanıt süresi (TTFB), origin kaynaklı nedenler için güçlü bir önleme aracıdır; erken uyarı sinyali olarak izleyin — ancak evrensel değildir: 504 CDN, yük dengeleyici veya proxy katmanında da kaynaklanabilir, bu nedenle önce hangi atlamanın zaman aşımına uğradığını doğrulayın. Zaman aşımı değerini artırmak her durumda çözüm değildir; yavaş upstream’i maskeler ve aşırı yükü kötüleştirebilir.
• Kesinti planlıysa 504 yerine Retry-After ile 503 döndürün.

Resmi belgeler

Zaman aşımları, sunucu hataları ve tarayıcıların bunlara verdiği yanıtlar hakkında birincil kaynak belgeleri.

Tanım

• MDN — 504 Gateway Timeout — yetkili tanım ve 502’den farkı.

Google

• Tarama hatalarını giderme — Googlebot’un sunucu sorunlarında nasıl geri çekildiği ve aşırı yük için ne zaman 503/429 döndürülmesi gerektiği.
• Tarama bütçenizi optimize edin — yavaş yanıtların ve sunucu hatalarının tarama sınırını nasıl düşürdüğü.
• Tarama İstatistikleri raporu — “Sunucu hatası (5XX)” ve “Sayfa zaman aşımı” kategorileri ve Googlebot’un aşırı yükü önlemek için nasıl kısıtladığı.

Bing / Microsoft

• Bing Webmaster Tools — tarama hatası uyarıları — Bing’in sunucu hatalarıyla zaman aşımlarını ayrı tarama hatası kategorileri olarak işaretlemesi.

Kaynaktan alıntılar

Kayda geçmiş ifadeler. Her bağlantı, kaynak sayfasındaki alıntı bölümüne giden derin bağlantıdır.

MDN — tanım

• “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.” (Türkçe çeviri) “HTTP 504 yanıtı, ağ geçidi veya proxy olarak çalışan sunucunun isteği tamamlamak için upstream sunucudan zamanında yanıt alamadığını belirtir; 502’den farkı, origin’den belirli süre içinde hiçbir HTTP yanıtı alınmamasıdır.” Jump to quote

Google — tarama ve zaman aşımları

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (Türkçe çeviri) “Googlebot, sunucuların tarama isteklerine yanıt vermekte zorlandığını algılarsa taramasını azaltır.” — Google Search Central, Tarama hatalarını giderme. Jump to quote
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (Türkçe çeviri) “Site yavaşlar veya sunucu hataları döndürürse sınır düşer ve Google daha az tarar.” — Google Search Central, Tarama bütçenizi optimize edin. Jump to quote

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.” (Türkçe çeviri) “Sunucu baytları sunmakta zorlanırsa tarayıcılarımız altyapıyı aşırı yüklememek için otomatik olarak geri çekilir ve tarama sıklığı düşer.” Jump to quote

John Mueller, Google (Reddit’te; Search Engine Journal’ın Ağustos 2025 haberinde aktarıldı)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (Türkçe çeviri) “Tarama hızının bu kadar hızlı tepki vermesini ancak 429, 500, 503 veya zaman aşımı yanıtları döndürülüyorsa beklerdim.” Alıntıya git Search Engine Journal, Mueller’in Reddit yanıtını ve çevresindeki bağlamı aktarıyor.

Sunucu yanıt süresi / TTFB kontrol listesi

Amaç yanıtları 504’ün hiç tetiklenmeyeceği kadar hızlı tutmak ve kaymayı tetiklenmeden önce yakalamaktır. Yukarıdan aşağıya çalışın:

• TTFB için temel değer belirleyin: curl -w "%{time_starttransfer}" (veya sentetik bir izleyici) kullanın ve her şablon için “normal” değerin ne olduğunu kaydedin.
• TTFB’yi sürekli izleyin, yalnızca olaydan sonra değil — sadece kesin arızalarda değil, yukarı yönlü kaymada uyarı verin.
• Gerçekçi ve tepe eşzamanlılıkta yük testi yapın — 504’ler genellikle yüke bağlıdır; sessiz pencere kontrolü bunları ortaya çıkarmaz.
• En yavaş upstream işini profilleyin — dizine eklenmemiş veritabanı sorguları, N+1 sorguları ve engelleyici üçüncü taraf API çağrıları olağan suçlulardır.
• Agresif önbellekleme kullanın — sayfa önbelleği, nesne önbelleği ve CDN edge önbelleği — böylece isteklerin çoğu yavaş yola hiç girmez.
• Zaman aşımı değerlerinin katmanlar arasında tutarlı olduğunu kontrol edin (CDN, yük dengeleyici, Nginx proxy_read_timeout / fastcgi_read_timeout, uygulama); bir katmanın diğerinden önce vazgeçmediğinden emin olun.
• Trafik ve tarama artışları için otomatik ölçeklendirmeyi / kapasite payını doğrulayın.
• GSC Tarama İstatistikleri’ni zaman aşımı ve 5XX artışları ile yükselen ortalama yanıt süresi için inceleyin.
• Hangi katmanın ve neyin zaman aşımına uğradığını belirlemek için sunucu + proxy günlüklerini kontrol edin.
• Çalışma süresi izlemesinin yalnızca mesai dışı pingleri değil, tepe yükü kapsadığını doğrulayın.
• Planlı kesinti için sayfaların 504 vermesine izin vermek yerine Retry-After ile 503 kullanın.

Kaçınılması gereken 504 mitleri ve hataları

En sık ortaya çıkan tuzaklar — bunların birçoğu düzeltilmesi gereken, yaygın biçimde tekrarlanan mitlerdir:

• “504 bir Google cezasıdır.” Hayır. Bu, algoritmik bir işlem değil, erişilebilirlik/taranabilirlik sorunudur. Google içeriğinizi değerlendirmiyor; sayfayı alamıyor. Her türlü sıralama kaybı cezalandırmanın değil, erişilemezliğin sonraki sonucudur.
• “Her 504 sayfamı hemen dizinden çıkarır.” Hayır. Kısa ve arada bir görülen 504’ler yeniden denenir ve tolere edilir. Risk yaratan, uzun bir pencere boyunca sürdürülen ve sık tekrarlanan 504’lerdir.
• “504 ve 503 temelde aynıdır — birbirinin yerine kullanın.” Hayır. 503 kasıtlı ve kontrollü bir sinyal olabilir (Google planlı kesinti için 503’ü açıkça destekler); 504 ise neredeyse her zaman plansızdır ve yavaş bir upstream’in belirtisi olan bir zaman aşımıdır. Planlı kesinti sırasında Retry-After ile 503 döndürün — sayfaların 504 vermesine izin vermeyin.
• “Sorun Googlebot’un fazla agresif olması.” Genellikle tam tersi doğrudur. Googlebot’un tarama hızında güvenilir biçimde 504 veren bir sunucu, benzer yük altında gerçek kullanıcılar için de kötüleşir. Zaman aşımı gerçek bir kapasite/performans sorununu açığa çıkarır (“Hostload exceeded” senaryoları vardır, ancak kural değil istisnadır).
• “Düzeltmek yalnızca zaman aşımı değerini artırmak demektir.” proxy_read_timeout değerini artırmak yavaş upstream’i düzeltmek yerine maskeler — yük altında daha uzun zaman aşımı çalışan süreçleri daha uzun süre meşgul eder ve aşırı yükü kötüleştirebilir. Yavaş yanıtı düzeltin; sabrınızı artırmayın.
• “Çalışma süresi izleme sistemi yeşil gösteriyor, demek ki 504 sorunumuz yok.” 504’ler çoğu kez yüke bağlıdır. Sessiz bir pencerede ping atan izleyici, Googlebot’un daha yoğun tarama dalgalarında topladığı zaman aşımlarını kaçırabilir. Mesai dışı pinglerden çok Tarama İstatistiklerine ve günlüklerine güvenin.

Hangi katmanın zaman aşımına uğradığını bulun

İstem: bir 504 olayları grubunu sınıflandırın

URL, zaman damgası, yanıt başlıkları, TTFB veya toplam süre, herkese açık edge sonucu, doğrudan origin sonucu, uygulama izi, veritabanı zamanlaması ve kaynak sinyallerini içeren temizlenmiş satırları yapıştırın. Kimlik bilgilerini, çerezleri, özel adresleri veya kullanıcı verilerini yapıştırmayın.

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]

Sonucu bir hipotez kuyruğu olarak ele alın. Gateway, uygulama, veritabanı ve altyapı telemetrisiyle doğrulayın.

Durumu ve ilk bayta kadar geçen süreyi ölçün

Bunu bir macOS/Linux kabuğunda çalıştırın. Gövdeyi yazdırmadan tek bir istek için son yanıt kodunu ve TTFB’yi raporlar.

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

Tutarlı mı yoksa yüke mi bağlı olduğunu görmek için birkaç kez tekrarlayın:

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

PowerShell eşdeğeri:

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 }
  }
}

PowerShell sürümü TTFB’yi değil, toplam istek süresini ölçer. İlk bayt ayrımına ihtiyaç duyduğunuzda kabuk komutunu veya uygulama telemetrinizi kullanın.

504’leri yeniden üretmek ve kapsamını belirlemek için araçlar

• Website Down Checker — harici bir bakış noktasından erişilebilirliği test edin; yanıt zamanlamasını, yönlendirmeyi ve sınırlı DNS kanıtını yakalayın. Olayın genel kullanıma açık biçimde yeniden üretilebilir olup olmadığını belirlemek için kullanın.
• Bulk HTTP Status Code Checker — temsili bir rota kümesini kontrol edin, gecikmeyi karşılaştırın ve başarısız alt kümeyi dışa aktarın. Bu, yavaş tek bir uç nokta ile site genelindeki upstream sorununu ayırmaya yardımcı olur.
• CDN/yük dengeleyici günlükleri — 504’ü hangi ağ geçidinin ürettiğini bulun ve istek kimliği ile zaman aşımını upstream denemesiyle ilişkilendirin.
• Uygulama izleme ve veritabanı yavaş sorgu günlükleri — istek origini gördükten sonra zamanını nerede harcadığını gösterir.
• Altyapı izleme — olay penceresini CPU, bellek, çalışan havuzu, bağlantı ve bağımlılık doygunluğuyla karşılaştırın; durum kodundan tahmin etmeyin.

Rotaya ve yüzdelik dilime göre TTFB

Metrik: Yararlı yüzdelik dilimlere ayrılmış temsili rotalar için ilk bayta kadar geçen süre; yalnızca ortalama değil.

Ne anlatır: Kuyruk gecikmesinin yükselmesi, isteklerin 504 döndürmeye başlamasından önce bir ağ geçidi zaman aşımına yaklaştığına dair erken uyarıdır.

Nasıl alınır: Gerçek kullanıcı/sunucu izleme veya ağ geçidi günlüklerini kullanın; üretim telemetrisi yerine değil, noktasal kontroller için Scripts sekmesindeki curl betiğini kullanın.

Karşılaştırma / gerçekçi aralık: Rota ve altyapı yolu başına bir temel değer oluşturun. Anlamlı uyarı, evrensel bir SEO sayısı değil, bu temelden sürekli sapma veya gerçek yapılandırılmış ağ geçidi zaman aşımınıza yaklaşmadır.

Sıklık: Sürekli izleyin; rota düzeyindeki eğilimleri haftalık olarak ve her 504 olayında inceleyin.

504 yanıt oranı

Metrik: Kullanılabildiğinde rota, ağ geçidi, origin ve tarayıcı/kullanıcı aracısı sınıfına göre ayrılmış, tüm isteklere bölünen 504 döndüren istekler.

Ne anlatır: Zaman aşımlarının tekil mi, tek bir yolda yoğunlaşmış mı, yoksa taramayı ve kullanıcıları etkileyecek kadar geniş mi olduğunu gösterir.

Nasıl alınır: CDN, yük dengeleyici veya sunucu erişim günlüklerini durum kodu ve istek boyutlarına göre toplulaştırın.

Karşılaştırma / gerçekçi aralık: Sağlıklı hedef açıklanamayan hiçbir 504’ün olmamasıdır. Uyarı duyarlılığı için trafik karışımı ve yeniden deneme davranışı yığına göre değiştiğinden kendi normal, olaysız temel değerinizi kullanın.

Sıklık: Sürekli uyarı verin; toparlanma sırasında günlük, olağan haftalık güvenilirlik raporunda haftalık inceleyin.

Upstream tamamlanması ve ağ geçidi zaman aşımı

Metrik: Upstream tamamlanma sürelerinin dağılımını her atlama için yapılandırılmış zaman aşımıyla karşılaştırmak.

Ne anlatır: Yavaş işin gerçekten sınıra yaklaşıp yaklaşmadığını veya daha kısa bir ağ geçidi zaman aşımının aksi hâlde sağlıklı upstream yanıtlarını kesip kesmediğini gösterir.

Nasıl alınır: Ağ geçidi zamanlama alanlarını bir istek veya iz kimliği kullanarak uygulama izleriyle birleştirin.

Karşılaştırma / gerçekçi aralık: Beklenen değişkenlik için pay bırakarak normal tamamlanmayı yapılandırılmış sınırın rahatça içinde tutun. Bu payı gözlemlenen üretim dağılımlarından tanımlayın; genel bir yüzde uydurmayın.

Sıklık: Yapılandırma veya bağımlılık değişikliklerinden sonra ve kuyruk gecikmesi ya da 504 oranı yükseldiğinde inceleyin.

Kendinizi test edin: 504 Gateway Timeout

504’ün ne anlama geldiği ve taramayı nasıl etkilediği hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Teknik SEO için başlangıç rehberi — sunucu sağlığı ve taranabilirliğin daha büyük resimdeki yeri.
• Yeni web tarayıcılarıyla tanışın: Yapay zekâ botları arama motoru botlarına yaklaşıyor — sunucunuza gerçekte kimlerin eriştiği ve yükün neden önemli olduğu.

Konuşmalarım

• Arama nasıl çalışır? (SlideShare) — tarama, oluşturma, dizine ekleme ve sıralama; sunucu yanıtlarının tarama hızını nasıl yönettiğini anlatan yürüyüşüm. (Sabit uyarım geçerlidir: “Bu, sistemlere dair anlayışım… %100 eksiksiz veya doğru olmayabilir.”)

Sektörden

• MDN — 504 Gateway Timeout — yetkili tanım ve 502 ayrımı.
• Google — Tarama hatalarını giderme — Googlebot’un sunucu sorunlarında nasıl geri çekildiği.
• Google — Büyük siteler için tarama bütçesini yönetme — yavaş yanıtların tarama sınırını nasıl düşürdüğü.
• Google, 2026’da taramanın nasıl çalıştığını açıklıyor (Search Engine Land) — zorlanan sunucuları azalan tarama sıklığıyla ilişkilendiren Illyes alıntısı.
• Googlebot taraması düştü mü? Mueller sunucu hatalarına işaret ediyor (Search Engine Journal) — Mueller’in 429/500/503 ve zaman aşımlarını tarama hızını hızlı düşüren hatalarla aynı grupta ele alması.
• 504 Gateway Timeout hatası nasıl düzeltilir (Kinsta) — istek zinciri ve günlük teşhisi hakkında sağlam, sunucu odaklı teknik açıklama.

Videolar

• Google Search Central (YouTube) — How Google Search Works serisi ve Martin Splitt’in tarama açıklamaları; sunucu yanıtlarıyla tarama hızının nasıl etkileştiğini görmek için yararlıdır. Kanal

Değişiklik günlüğü