Siteyi Geçici Kapatınca SEO için doğru 503 kodu

Siteyi geçici süreyle kapatmanız (bakım, DDoS temizliği, ödeme sistemi yenileme, taşınma vb.) SEO’yu doğrudan etkileyebilir. Google botları geçici kapalı sayfaları doğru okuyabilirse, içerik “kalıcı kayıp” gibi algılanmaz ve geri dönüş sürecinde toparlanma hızlanır. Bu rehberde, 503 Service Unavailable kodunu doğru kullanmak için gerekli HTTP başlıklarını, yaygın hataları ve pratik senaryoları net biçimde ele alıyoruz.

503 ne zaman doğru seçimdir?

503 (Service Unavailable) kodu, sunucunun belirli bir süre boyunca isteği karşılayamayacağını belirtir. Bu “kalıcı silme” mesajı değildir; amaç tarayıcıların ve arama motorlarının durumu bakım/ara verme olarak anlamasıdır.

503 yerine hangileri tercih edilir?

Aşağıdaki seçim, doğru sinyali verdiğinizden emin olur: - 503: Bakım var, trafik/kapasite anlık yetersiz, güncelleme sırasında geçici erişim kısıtı. - 429: Rate limit devrede (çok fazla istek). SEO amaçlı “site kapalı” anlatımı için genellikle uygun değildir. - 403: Yetkisiz erişim (abonelik/rol). İçerik “var ama yasak” algısı oluşur. - 404/410: İçerik kalıcı olarak yok. Geçici kapatma için kesinlikle doğru değildir.

SEO için 503 hangi sinyalleri taşımalı?

SEO etkisini belirleyen iki kritik unsur vardır: HTTP durum kodu ve doğru header.

Gerekli HTTP durum kodu

• Durum kodu: 503
• Yanıt gövdesi: Kullanıcıya kısa ve net bilgi (bakım zamanı aralığı, geri dönüş tarihi tahmini)

Mutlaka kullanılması gereken header: Retry-After

Retry-After başlığı, arama motorlarına ve botlara “ne zaman tekrar denemeli?” bilgisini verir. - Önerilen biçim: saniye cinsinden (ör: Retry-After: 3600) ya da HTTP tarihi (ör: Retry-After: Wed, 21 Oct 2026 07:28:00 GMT). - Hedef: Çok agresif deneme ile sunucunuzu gereksiz yere yormamak; çok uzun süre vermemek.

Net bir kural: Bakım 30 dakika sürecekse Retry-After: 1800, 4 saat sürecekse Retry-After: 14400 gibi plan yapın.

İsteğe bağlı ama faydalı: Cache-Control

Bakım sayfasının cachesiz kalması önemlidir. Aksi halde bazı CDN veya ara katmanlar, bakım ekranını “gerçek durum sanıp” uzun süre tutabilir.

• Yaygın ve güvenli yaklaşım:
• Cache-Control: no-store, max-age=0
• Pragma: no-cache

Doğru 503 sayfa stratejisi: HTTP ile metin uyumu

SEO açısından en sık yapılan hata, bakım ekranında kullanıcıya “bakım” yazıp HTTP yanıtında farklı kod göndermektir. Örneğin bakım sayfası gösterilirken içerik aslında 200 ile dönüyorsa arama motoru “erişilebilir” kabul edebilir.

Kullanıcı mesajı nasıl olmalı?

Bakım/kapalı sayfası şu bilgileri içermelidir: - “Bakım nedeniyle geçici olarak kullanılamıyor” mesajı - Tahmini dönüş zamanı (bilmiyorsanız bile “yakında” yerine net bir aralık) - Durum ilerledikçe iletişim kanalı (ör. destek e-posta)

Teknik sayfa içeriği için pratik kontrol

• Aynı sayfayı her istek için tutarlı sunun (tek URL üzerinden bakım sayfası gibi düşünün).
• Dil/etiketleme: sayfanız kendi normal tasarımınıza çok benzer olabilir, ancak HTML tarafında “kalıcı gitti” mesajları kullanmayın.

Örnek konfigürasyonlar (Nginx)

Aşağıdaki örnekler, tüm istekleri bakım sayfasına yönlendirirken HTTP 503 kodunu ve gerekli header’ları doğru verir.

Nginx: Tüm site için 503 (maintenance sayfası)

server {
    listen 80;

    location / {
        # Bakım modunda tüm trafiği yakala
        return 503;
    }
}

Bu tek satır örnek çalışır; ancak çoğu senaryoda bakım sayfası metnini de göstermek istenir. Daha gerçekçi kullanım şöyle olur:

server {
    listen 80;

    set $maintenance 1;

    location / {
        if ($maintenance = 1) {
            add_header Retry-After "3600" always;
            add_header Cache-Control "no-store, max-age=0" always;
            return 503;
        }

        proxy_pass http://app_upstream;
    }
}

Not: if kullanımını Nginx tarafında her yerde değil, bu tarz koşullarda kontrollü kullanın. Üretimde bakım modunu yönetmek için ayrı “maintenance server” veya farklı include yapısı daha temkinli olabilir.

Nginx: Maintenance sayfası göster (503 ile)

server {
    listen 80;

    root /var/www/html;

    location / {
        add_header Retry-After "3600" always;
        add_header Cache-Control "no-store, max-age=0" always;

        return 503;
    }

    location = /maintenance.html {
        try_files /maintenance.html =404;
        # maintenance.html gösterilirken 503 statusu return ile zaten gelir.
    }
}

Bu yaklaşımda maintenance HTML’inizi ayrıca servis ederken statusu korumanız gerekir. En temiz yöntem, istek geldiğinde bakım HTML’iyle birlikte 503 dönen bir return/try_files kombinasyonunu doğru kurmaktır.

Örnek konfigürasyonlar (Apache)

Apache tarafında da 503 ile birlikte header’ları ayarlamak gerekir.

Apache: Tüm siteye bakım ekranı ver

<VirtualHost *:80>
    DocumentRoot /var/www/html

    <Location />
        Header always set Retry-After "3600"
        Header always set Cache-Control "no-store, max-age=0"
        RewriteEngine On
        RewriteRule ^$ /maintenance.html [R=503,L]
        RewriteRule . /maintenance.html [R=503,L]
    </Location>
</VirtualHost>

Bu örnekte maintenance.html gösterilirken 503 dönüşü sağlanır. Konfigürasyonunuzda Rewrite modülü ve Header direktifi aktif olmalıdır.

Yanlış uygulamalar (SEO’yu gereksiz yere zedeleyenler)

Aşağıdaki hatalar, arama motorlarının davranışını bozabilir: - Bakım ekranı gösterip HTTP 200 dönmek. - Retry-After vermemek veya rastgele çok kısa süre (ör. 5 saniye) vermek. - Bakım modunu uzun süre tutup “geçici” mesajını yıllar süren bir şablona çevirmek. - CDN/Proxy katmanında bakım ekranının uzun cachelenmesine izin vermek. - Tüm sayfalara farklı davranıp bazılarını 200, bazılarını 503 döndürmek (tutarlılık bozulur).

Tek sayfa yerine tüm site mi? SEO kararı

Geçici kapatma her zaman “tüm site” değildir. En doğru yaklaşım, bakımın kapsamına göre değişir.

Tüm site bakımında

• Tüm URL’ler 503 dönmeli
• Retry-After tek bir mantığa bağlanmalı
• Cache-Control no-store yaklaşımı sürdürülmeli

Sadece belirli sayfalarda bakım

• Sadece ilgili URL gruplarına 503 verin
• Diğer sayfalar normal çalışıyorsa 503’e zorlamayın
• Aksi halde tarama bütçesi yanlış dağıtılır

HTTPS ve WAF/CDN ile birlikte 503 davranışı

Birçok kullanıcı Cloudflare/CDN, WAF veya load balancer kullanır. Bu katmanlar, uygulamanızdan gelen statik 503 davranışını etkileyebilir.

Pratik kontrol: Gerçek yanıtı her katmanda doğrulayın

• Tarayıcıda “developer tools” → Network sekmesinde:
• Durum kodu gerçekten 503 mi?
• Header’da Retry-After var mı?
• Cache-Control doğru mu?
• Komut satırı ile de kontrol edin:
• curl -I https://example.com/
• Çıktıda HTTP/1.1 503 ve Retry-After görünmeli.

Yaygın sorun: CDN bakım sayfasını 200 ile önbelleklemesi

Eğer CDN tarafında bakım sayfası “origin’dan 200 geldi” gibi yanlış bir varsayım oluştuysa, bakım döneminde bile kullanıcılar ve botlar kararsız sonuç görebilir. Bu yüzden header’ları ve cache politika ayarlarını bakım moduyla birlikte test edin.

Bakım bittiğinde ne yapmalısınız?

SEO açısından bakımın bittiği an, “sinyal sıfırlama” demektir. Yapmanız gerekenler net:

1. Bakım modu konfigürasyonunu kapatın.
2. Sunucu normal içeriğe döndüğünde tarafa 200/normal status akışı geri gelsin.
3. CDN varsa bakım önbelleği temizlensin.
4. 5-15 dakika içinde birkaç kritik URL’yi yeniden kontrol edin: - Durum kodu: 200 mi? - Sayfa içeriği doğru mu? - Büyük değişiklik varsa sitemap veya iç linkler etkileniyor mu?

Net karar tablosu: Kod + header eşleşmesi

Aşağıdaki tablo, bakım senaryolarında “ne yapmalıyım?” sorusuna doğrudan cevap verir.

Aksiyon: Bakım modunu güvenli test etme planı

Bakım kararını uygulamadan önce 15 dakikalık test, ilerideki SEO sorunlarını ciddi biçimde azaltır.

1) Bir URL seçin, header’ları ölçün

• Ana sayfa (/) veya en kritik bir landing sayfanızı seçin.
• Bakım modunu açın.
• curl -I ile kontrol edin:
• 503 geliyor mu?
• Retry-After var mı?
• Cache-Control no-store mu?

2) CDN/WAF varsa “origin” ve “edge” kontrolü yapın

• CDN arkasında kontrol:
• curl -I https://domain.com/ (uç katman)
• Origin kontrol:
• mümkünse doğrudan origin IP/host ile

3) Bakım ekranını aç-kapat testi

• 503 açıkken botlar “geçici” anlasın.
• 503 kapatınca 200/normal akış geri gelsin.
• Önbellek temizliği gerek mi görün.

Sonuç olarak: Siteyi geçici kapattığınızda SEO’yu korumanın ana yolu, 503 durum kodunu doğru uygulayıp Retry-After (ve no-store cache politikası) ile sinyali netleştirmektir. Bakım modunu açmadan önce tek bir URL üzerinden curl -I ile header doğrulaması yapın; bakım biter bitmez de aynı URL’lerde durumu tekrar kontrol edin. Böylece arama motorlarının “kalıcı kayıp” yerine “geçici erişim sorunu” okumasını sistematik biçimde garanti edersiniz.