Site Geçici Kapanınca SEO İçin Doğru 503 Kodu Nasıl Kullanılır?

Siteinizi bakım, yoğun trafik, ödeme/iletim hatası veya planlı güncelleme nedeniyle geçici süreliğine kapatmanız gerektiğinde, SEO açısından tek bir nokta kritiktir: Arama motorlarına doğru sinyali vermek. Yanlış kod (ör. 200 dönmek) dizinlemeyi yanıltabilir; sürekli 302/301 ise kalıcı taşıma gibi algılanabilir. Bu rehberde, geçici kapama senaryosunda 503 Service Unavailable yanıtını ne zaman ve nasıl vereceğinizi, hangi ek başlıklarla (özellikle Retry-After) davranmanız gerektiğini, ayrıca en yaygın hataları net örneklerle açıklıyoruz.

503 ne zaman doğru seçimdir?

Geçici kapama; sitenin bir süre sonra geri geleceğini düşündüğünüz durumdur. Arama motorlarına “şu an geçici bir problem var, sayfa kalıcı olarak taşınmadı” sinyali vermek istersiniz.

Aşağıdaki durumlar 503 için tipik örneklerdir: - Bakım/iyileştirme: kod deploy, veritabanı migrasyonu, cache yeniden üretimi - Kapasite sınırı: beklenmeyen yük artışında geçici koruma - Dış servis kesintisi: ödeme sağlayıcı, e-posta sağlayıcı, SMS/2FA sağlayıcı - Hizmetin kısa süreli durdurulması: ör. 30 dakika–48 saat arası

Buna karşılık şu kodlar genellikle yanlış sinyaldir: - 200 dönmek: Arama motoru sayfanın normal çalıştığını sanır. - 404/410: Sayfanın kalıcı olarak olmadığını ifade eder. - 301/308 ile yönlendirmek: Kalıcı taşıma gibi algılanabilir. - 302 ile geçici yönlendirme (tek başına): Arama motoru sinyalleri karışabilir; doğru kod yine 503 olmalıdır.

503 ile 200 arasındaki SEO etkisi

• 200: İçerik gerçekten yoksa “varmış gibi” davranılır; kullanıcı da hata görür.
• 503: “Şu an kapalı ama geri gelecek” mesajı verilir. Bu, tarama sıklığı ve indeksleme süreçlerini daha kontrollü hale getirir.

503 için doğru HTTP yanıt seti

Doğru uygulama sadece status code ile bitmez. SEO ve tarama davranışı için özellikle iki şeye dikkat edin: 1) Doğru status code: 503 2) Doğru süre sinyali: Retry-After (varsa)

Minimum doğru yapı

Sunucu bakım sayfanız görünse bile arama motoruna 503 gitmelidir.

Örnek mantık: - Kullanıcı tarayıcıya düşen bakım sayfasını görür. - Arama motoru bakım sayfasını görür ama HTTP status 503 olduğunu anlar.

Retry-After başlığı nasıl yazılır?

Retry-After başlığı, arama motorlarının ve istemcilerin ne zaman yeniden denemesi gerektiğini belirtir.

Tercih edilen format seçenekleri: - Saniye cinsinden: Retry-After: 3600 - Tarih-saat cinsinden (HTTP-date): Retry-After: Wed, 04 Oct 2026 12:00:00 GMT

Net kural: - Bakım sürenizi biliyorsanız süreyi yazın. - Belirsizse bile 0 yerine “makul bir aralık” verin; ör. 1800 (30 dk) veya 14400 (4 saat) gibi.

Örnek senaryolar: Ne yapmalı, ne yapmamalı?

Aşağıdaki tabloda en sık yapılan hatalar ve doğru karşılıkları net şekilde görebilirsiniz.

Hangi katmanda 503 dönmeli: Origin mi CDN mi?

Birçok sitede istek önce bir CDN’e (ör. edge katmanı) gider. Bu noktada kritik soru şudur: 503 gerçekten yanıt olarak nereden üretiliyor?

Kontrol kontrol listesi

• Tarayıcıdan değil, gerçek HTTP yanıtını doğrulayın.
• CDN katmanı varsa, CDN’in bakım modunda döndürdüğü statü koduna bakın.
• Reverse proxy (Nginx/Apache) varsa, 503’ün proxy’den geldiğini doğrulayın.

Net doğrulama yöntemi

Her bakım durumunda şu yaklaşımı uygulayın: - curl -I ile başlıkları inceleyin. - HTTP/1.1 503 satırı görünüyor mu bakın.

Örnek komut (yerine göre URL’nizi değiştirin): - curl -I https://ornek-domain.com

Çıktıda beklenenler: - HTTP/1.1 503 Service Unavailable - Retry-After: ... (varsa) - Cache-Control (aşağıda anlatıyoruz)

Cache ve indeksleme: 503 sayfası nasıl önbelleğe alınmalı?

Bakım sayfası 503 döndürür ama cache politikası doğru olmalıdır. Aksi halde yanlışlıkla bakım sayfası uzun süre önbelleğe girip “geri döndükten sonra” bile kullanıcıya bakım sayfası servis edilebilir.

Pratik cache ayarı

Genel hedef: - Bakım sırasında yanıt önbelleğe alınmamalı veya kısa süreyle saklanmalı.

Bu hedefe uygun başlıklar örnekleri: - Cache-Control: no-store, max-age=0 - Alternatif: Cache-Control: max-age=60 (çok kısa)

Net tavsiye: - Bakım modu acilse no-store yaklaşımı güvenlidir. - Her şeyi uzun cache’e bırakmak hatalı olur.

Nginx’te 503 bakım modu (örnek)

Aşağıdaki örnek, tüm trafiğe geçici bakım sayfası verirken 503 status dönmeyi hedefler. Yapı; site dosya yolunuza ve bakım durumuna göre ayarlanmalıdır.

Basit yaklaşım (bakım bayrağı)

• Nginx tarafında bir bakım dosyası/flag kontrolü yapın.
• Bu flag aktifse bakım sayfasını servis edin ve status 503 verin.

Örnek mantık (konsept): - error_page 503 /maintenance.html; - return 503; veya bakım sayfasına yönlendirme ama status korunacak şekilde.

Not: Nginx yapılandırması dağıtımınıza göre farklılık gösterir. Önemli nokta: İstek sonuç olarak 503 status almalı; bakım sayfası 200 gibi görünmemeli.

Apache’te 503 bakım modu (örnek)

Apache tarafında da hedef aynıdır: bakım sayfası görünsün ama HTTP status 503 olarak kalsın.

Yaygın desen

• Bakım sırasında 503 üreten bir kural tanımlayın.
• ErrorDocument 503 ile bakım sayfasını servis edin.

Net hedef: - 503 üretildiğinde bakım sayfası görüntülenmeli. - Son kullanıcı 200 görmemeli (yanıt başlığında 503 olmalı).

Uygulama katmanında (ör. Node.js/PHP) 503 üretme

Statü kodunu uygulama seviyesinde döndürmek de mümkündür. Bu yöntem özellikle tek sayfa uygulamalarında veya dinamik routing yapan sistemlerde kullanışlıdır.

Temel kural

• Bakım koşulu aktif olduğunda endpoint’ler her zaman 503 döndürmeli.
• Aynı zamanda Retry-After ve cache başlıkları ile davranışı kontrol etmelisiniz.

Örnek mantık: - Bakım modu flag’i aktifse response: 503 - Header: Retry-After, Cache-Control gibi - Body: bakım metni, beklenen dönüş zamanı

Arama motoru tarafında beklenen davranış

Doğru 503 uygulandığında arama motorları: - Sayfanın kalıcı taşınmadığını anlar. - Bakım süresi boyunca daha kontrollü tarama yapabilir. - Süre bittiğinde tekrar tarar ve normal içeriği görür.

Ancak şunu unutmayın: 503’ün SEO etkisi bakım süresine ve kullanım sıklığına bağlıdır. Çok uzun süre (ör. haftalar/aylar) 503 döndürmek, kalıcılığa yaklaşan bir sinyale dönüşebilir.

Sık yapılan 7 hata (ve hızlı düzeltme)

1) Bakım sayfası 200 dönüyor: HTTP status’ı kontrol edin. 2) CDN bakım modunda 200 basıyor: CDN’de status korunduğundan emin olun. 3) Retry-After kullanılmıyor: En azından beklenen yeniden deneme aralığını ekleyin. 4) Yanlış cache başlığı: Bakım sayfası uzun süre önbelleğe alınmasın. 5) 301/308 kullanımı: Geçici bakım için yönlendirmeyi 503 ile sınırlayın. 6) Tek endpoint yerine tüm siteyi kapsamama: Ana sayfa değil, tüm giriş/önbellekli sayfalar 503 almalı. 7) Geri dönüşte bakım flag’inin kapanmaması: Otomatik kapanma/izleme kuralı kurun.

Operasyon önerisi: Bakım modunu güvenli kapatma

503 bakım modu sadece “açmak” değil “kapatmak” kadar önemlidir. Net bir operasyon akışı şunları içermeli:

1) Bakım banner’ında süre verin

Kullanıcı deneyimi için bakım ekranında net bilgi gösterin: - Başlangıç zamanı - Tahmini bitiş (veya “X saat içinde”) - İletişim varsa yöntem

2) İzleme ile doğrulayın

Bakım aktifken şu metrikleri kontrol edin: - HTTP 503 oranı: tüm istekler 503 mü? - Retry-After var mı? - CDN edge’te status değişiyor mu?

3) Otomatik kapanış

Bakımın elle unutulması sık görülür. Süreli bir bakım için: - Flag’i otomatik kapatan bir mekanizma kurun. - Ya da bakım modunu başlatırken “bitirme saatini” sistemde zorunlu kılın.

Sonuç: SEO’yu korumak için 503’ü doğru ve tutarlı kullanın

Siteyi geçici kapattığınızda SEO’yu koruyan yaklaşım bellidir: Tüm isteklerde 503 Service Unavailable dönün, mümkünse Retry-After başlığını gerçekçi bir süreyle ekleyin ve bakım sayfasının cache’e takılmasını engelleyin. Hemen şimdi bakım senaryosu için bir test yapın: Tarayıcıdan değil, curl -I ile yanıt başlığında 503’ün ve Retry-After/cache başlıklarının doğru geldiğini doğrulayın. Bu doğrulama doğru yapılınca, bakım sonrası normal içeriğe geçişte hem kullanıcı hem arama motoru için süreç kontrol altında olur.