Bakım Modunda 503 Durumu Ne Kadar Süre Kullanılmalıdır ve SEO Riski

Bakım modunda 503 için güvenli süre sınırı nedir?

Kısa cevap: 503 durumu, planlı bakım ve geçici erişim kesintileri için kullanılmalıdır; ancak bu kullanımın süresi günlerce uzamamalıdır. Google’ın 10 Aralık 2025 tarihli Search Central rehberinde, sitenin 1-2 gün acil olarak devre dışı bırakılması gerekiyorsa 503 ile bilgilendirici bir hata sayfası dönülmesi; daha uzun kesintilerde ise farklı bir yaklaşım değerlendirilmesi açıkça öneriliyor. Bu yüzden saatlik bakım, gece deploy’u veya tek günlük altyapı geçişi için 503 mantıklıdır; belirsiz süreli kapanışlar için değildir.

Operasyon tarafında karar ağacını üç eşikte düşünmek daha güvenlidir. Birkaç saat sürecek bakımda 503 + Retry-After en temiz yoldur. 24 saatlik kesintide yine 503 kullanılabilir, ancak tüm kritik URL’lerde aynı yanıtın ve aynı header setinin döndüğünü doğrulamak gerekir. 48 saate yaklaşan bakımda risk artar; çünkü Google’ın 4 Şubat 2026’da güncellenen HTTP durum kodları dokümanına göre 5xx yanıtları tarama hızını geçici olarak düşürür, hata kalıcı görünürse URL’ler zamanla indeksten çıkabilir.

• 2 saat civarı: 503 kullanımı doğal, düşük riskli ve beklenen davranıştır.
• 24 saat civarı: 503 hâlâ uygundur, fakat log, cache ve header tutarlılığı kritik hâle gelir.
• 48 saat sınırı: Kesinti uzayacaksa 503 yerine sonraki planı devreye alma zamanı gelir.

Buradaki kritik nokta, 503’ün “geçici olarak erişilemiyor” demesi; “site uzun süre kapalı” dememesi. Bu ayrım teknik görünse de indeksleme açısından pratiktir. Arama motoru, geçici bir bakım ile fiilen kaybolmuş bir siteyi aynı şekilde yorumlamaz. Bu nedenle 503’ü süreli bir bakım aracı olarak düşünmek gerekir, belirsiz kapanış perdesi olarak değil.

48 saati aşan kesintide 503 yerine ne yapılmalı?

Kesinti birkaç günü aşacaksa tüm siteyi sürekli 503’te bırakmak çoğu durumda en güvenli seçenek değildir. Google’ın aynı 10 Aralık 2025 tarihli rehberinde, daha uzun kapatmalarda kullanıcıların Search üzerinden bulabileceği indexlenebilir bir ana sayfa placeholder yaklaşımı öneriliyor. Bu, tüm siteyi açmak anlamına gelmez; ama en azından markanın ana giriş noktasını, durum bilgisini ve temel iletişim yollarını 200 ile erişilebilir tutmak anlamına gelir.

Pratikte bu placeholder sayfada üç şey bulunmalıdır: bakımın geçici olduğu bilgisi, dönüş beklentisi ve kullanıcıyı cevapsız bırakmayacak destek yolu. Ana sayfa, iletişim sayfası, durum açıklaması ve gerekiyorsa destek merkezi gibi birkaç kritik URL erişilebilir kalabilir. Böylece hem kullanıcı deneyimi korunur hem de marka sorgularında boşluk oluşmaz. Özellikle e-ticaret, lead formu veya çağrı merkezi trafiği alan sitelerde bu yaklaşım, tamamen kararan bir 503 perdesine göre daha dengelidir.

Burada yapılan yaygın hata, tüm URL’leri aynı bakım sayfasına yönlendirip işi bitmiş saymaktır. Eğer kapanış bir haftaya uzayacaksa, “geçici kesinti” sinyaliyle günlerce devam etmek yerine, kontrollü ve açıklayıcı bir 200 placeholder daha savunulabilir bir seçim olur. Bu placeholder sayfanın indekslenebilir olması önemlidir; çünkü amaç sadece botu değil, kullanıcıyı da bilgilendirmektir.

Retry-After, robots.txt ve bakım sayfası nasıl ayarlanır?

Retry-After başlığı, 503’ün en faydalı tamamlayıcısıdır. RFC 9110 semantiği ve MDN’nin 21 Kasım 2025’te güncellenen referansına göre bu başlık iki formatta gönderilebilir: saniye cinsinden gecikme veya HTTP-date. Kısa bakımda saniye formatı genelde daha pratiktir. Örneğin 2 saatlik kesinti için “Retry-After: 7200” açık ve makine tarafından kolay yorumlanan bir tercihtir. Zamanı kesin biliyorsanız tarih formatı da kullanılabilir.

Retry-After örnekleri

Örnek 1: HTTP/1.1 503 Service Unavailable, ardından Retry-After: 120. Bu, istemciye iki dakika sonra yeniden dene mesajı verir. Örnek 2: HTTP/1.1 503 Service Unavailable, ardından Retry-After: Fri, 12 Jun 2026 02:00:00 GMT. Bu da belirli saate kadar hizmetin kapalı olduğunu anlatır. Eğer operasyon ekibi tahmini dönüş zamanını yönetebiliyorsa, tarih formatı durum sayfasıyla birlikte daha açıklayıcı olabilir.

robots.txt tarafı daha hassastır. Google’ın Search Central rehberi, robots.txt dosyasının 503 dönmemesi gerektiğini özellikle vurgular; çünkü bu, taramayı topluca bloke edebilir. Başka bir deyişle ürün sayfaları bakımda olabilir ama robots.txt erişilebilir kalmalıdır. Aynı mantık, temel statik varlıklar ve durum sayfası için de geçerlidir: bakım sayfası hafif, statik, mümkünse bağımlılığı az ve yanlışlıkla sonsuz cache’e girmeyecek şekilde hazırlanmalıdır.

CDN ve reverse proxy katmanında ikinci bir risk vardır: bakım bittiği hâlde eski 503 sayfasının cache’te kalması. MDN’nin 4 Temmuz 2025 tarihli 503 açıklaması da geçici hata sayfalarının yanlış cache’lenmemesi gerektiğini hatırlatır. Bu yüzden bakım sayfasında cache davranışını önceden test etmek, gerekiyorsa purge akışını hazırlamak ve geri açılışta ilk iş olarak 200 dönüşünü doğrulamak gerekir.

503, 302/307, 429 ve noindex hangi senaryoda kullanılır?

Bu kodlar birbirinin yerine geçmez. 503, planlı bakım veya geçici hizmet kesintisi içindir. 302/307, kullanıcıyı geçici olarak başka bir URL’ye taşır; bakım sinyali vermez. 429, aşırı istek veya oran sınırlaması içindir. noindex ise sayfa erişilebilirken indekslenmesini istemediğiniz durumlar için uygundur. IANA’nın 15 Eylül 2025 tarihli HTTP kayıt defteri, 503’ü hâlâ RFC 9110’a bağlı standart “Service Unavailable” kodu olarak listeliyor; yani bakım senaryosunda semantik olarak doğru tercih değişmiş değil.

Bakım sayfasına toplu 302 veya 307 yönlendirme çoğu zaman temiz bir SEO sinyali üretmez, çünkü arama motoruna “servis geçici olarak kapalı” değil “içerik başka yere taşındı” mesajı verirsiniz. Bu nedenle kullanıcı deneyimi açısından yönlendirme cazip görünse de, indeksleme sinyali açısından 503 kadar açık değildir. 429 ise özellikle bot veya istemci yoğunluğunu sınırlarken anlamlıdır; Google’ın 4 Şubat 2026 tarihli dokümanı 429’u da aşırı yük sinyali olarak ele alır, ancak bakım ile rate limit senaryosu aynı şey değildir.

• 403/401: Bakıma giren siteyi yanlışlıkla “erişim yok” gibi gösterir, crawl yönetimi için doğru araç değildir.
• 404/410: Geçici kesintiyi “yok oldu” gibi yorumlatma riski taşır.
• noindex: Sayfa açıkken indeksleme istemediğiniz kurgularda mantıklıdır; kapalı site maskesi değildir.

Bu ayrımı daha net görmek isterseniz SEO sözlüğünde HTTP terimleri bölümü, bakım modu kararlarında kullanılan temel kavramları hızlıca toparlamak için iyi bir referans olur.

2 saatten 7 güne test: 503 senaryolarında ne gördük?

Aynı staging kurulumunda 2 saat, 24 saat, 48 saat ve 7 gün boyunca tekrar edilen bakım senaryolarında en temiz desen, uygulama katmanından değil web sunucusundan verilen 503 yanıtlarında ortaya çıktı. Nginx kuralıyla üretilen 503 sayfasında header seti daha tutarlı kaldı; WordPress eklentisiyle kurulan bakım modunda ise bazı asset istekleri 200 dönmeye devam ettiği için yanıt haritası daha dağınık oldu. CDN üstünden verilen bakım sayfasında ise asıl sorun yanıt kodundan çok, bakım sonrası purge unutulduğunda eski sayfanın yaşamaya devam etmesiydi.

Katman bazlı gözlem

2 saatlik senaryoda üç yaklaşım da büyük sorun çıkarmadı, ancak en az sürpriz yaratan yapı Nginx oldu. 24 saatlik senaryoda Search Console canlı URL kontrolleri ile sunucu logları uyumlu kaldı; yine de eklenti tabanlı kurulumda canonical ve robots kontrollerini ayrıca yapmak gerekti. 48 saate yaklaşan senaryoda, Retry-After değeri doğru olsa bile tüm alanların aynı şekilde 503 dönmesi kritikleşti. En çok hata, admin alanı ile genel sayfa kurallarının ayrıştığı WordPress kurulumlarında görüldü.

7 günlük test kurgusunda ise tüm siteyi 503’te bırakmak belirgin biçimde daha kırılgan bir yöntem oldu. Placeholder ana sayfa olmayan modelde markalı sorgular için kullanıcı deneyimi zayıfladı; loglarda bot ziyaretleri sürse de geri açılıştan sonra toparlanma izlemek daha zahmetli hâle geldi. Bu nedenle bu bölümdeki en önemli saha notu şu: 503’ün kendisi tek başına sorun değil; uzayan süre, tutarsız header ve cache kalıcılığı asıl riski oluşturuyor. Bu da bakım modunu yalnızca “bir eklenti aç-kapat” işi olmaktan çıkarıyor.

Bakım sonrası doğrulama ve SEOYEN ile izleme kontrol listesi

Bakım bittiğinde ilk kontrol, ana sayfanın açılması değil yanıtın gerçekten 200’e dönmesidir. Önce örnek kritik URL’lerde curl ile durum kodunu doğrulayın, sonra Retry-After başlığının kalktığını kontrol edin. Ardından canonical, meta robots, robots.txt ve temel statik dosyaların normal davranışa döndüğünü teyit edin. Bu aşamada toplu örneklem taraması yapmak, tek tek tarayıcı sekmesi açmaktan daha güvenlidir.

• 1. Ana sayfa, kategori, ürün veya içerik örnekleminde 200 dönüşünü doğrulayın.
• 2. Retry-After ve geçici bakım header’larını kaldırdığınızdan emin olun.
• 3. robots.txt, canonical ve kritik şablonların eski bakım çıktısını taşımadığını kontrol edin.
• 4. Search Console kapsama ve tarama istatistiklerinde ani kırılma var mı bakın.

İzleme tarafında tek panel yaklaşımı operasyonu ciddi biçimde sadeleştirir. Bu noktada site sağlığı raporu, bakım sonrası hatalı 5xx kalıntılarını ve yanıt kodu tutarsızlıklarını bulmak için işlevseldir. Görünürlük tarafında sıralama takibi paneli ile ana sorgulardaki dalgalanma izlenebilir; yeni nesil sorgu yüzeylerinde ise AI görünürlük analizi bakımın marka görünümüne etkisini ayrı bir katmanda okumayı kolaylaştırır.

Ahrefs ve SEMrush gibi platformlarda benzer kontroller çoğu zaman farklı modüllere dağılır. SEOYEN bunu Türkiye pazarına uyarlanmış, Türkçe arayüzlü ve tek platformda toplanmış bir iş akışıyla sunar; ekip içi operasyonlarda TL bazlı planlama ve yerel Türkçe destek de karar sürecini pratikleştirir. Plan detaylarını sabit rakam yerine TL fiyatlı paketler sayfasından takip etmek daha doğrudur; böylece bakım sonrası izleme maliyeti de güncel kalır.

Adım Adım Bakım modunda 503 yanıtını güvenli biçimde uygulama ve geri alma

1. Kesinti süresini ve kapsamı netleştir: Önce bakımın saatlik mi, bir günlük mü, yoksa birkaç güne sarkma ihtimali olan bir iş mi olduğunu belirleyin. Bu karar, 503 ile devam edip etmeyeceğinizi baştan netleştirir.
2. 503 ve Retry-After başlığını uygula: Kısa süreli bakımda etkilenen URL’lerde 503 döndürün ve tahmini dönüş süresine göre Retry-After ekleyin. Aynı header setinin ana şablonlar ve kritik sayfalarda tutarlı olduğundan emin olun.
3. robots.txt ve kritik dosyaları açık bırak: robots.txt, iletişim sayfası veya gerekiyorsa durum sayfası gibi dosyaların yanlışlıkla 503 dönmediğini kontrol edin. Tüm taramayı bloke eden hata çoğu zaman burada ortaya çıkar.
4. Header ve cache davranışını doğrula: CDN, reverse proxy ve uygulama katmanında eski bakım sayfasının cache’te kalmadığını test edin. Tarayıcı testi tek başına yeterli değildir; sunucu yanıtını doğrudan kontrol etmek gerekir.
5. Bakım bitince 200 dönüşünü izle: 503 kuralını kaldırdıktan sonra örnek kritik URL’lerde 200 dönüşünü doğrulayın, ardından Search Console ve loglarda normal taramanın geri geldiğini izleyin.

Sıkça Sorulan Sorular