Bakım Modu SEO'yu Etkiler mi? 503 ve Retry-After

Kısa cevap: bakım modu SEO'ya zarar vermek zorunda değildir, ama bakım sayfasının hangi HTTP durum koduyla sunulduğu önemlidir. Geçici bir bakımda doğru araç, aynı adreste 503 Service Unavailable döndürmek ve mümkünse Retry-After başlığı eklemektir. Bakım sayfasını 200 ile sunmak, arama motoruna bu metnin sayfanın gerçek içeriği olduğunu söyler; 404 ya da yönlendirme ise kalıcı bir değişiklik izlenimi yaratır. Bu rehber, 503'ün Google tarafından nasıl işlendiğini, kısa ve uzun kesintiler için ayrı yolları, test ve geri alma adımlarını ve bakım sonrası kontrolleri anlatır.

Genel durum kodu tablosunu burada tekrar etmiyoruz; 200, 301, 302, 404, 410 ve 5xx kodlarının SEO anlamı için HTTP durum kodları SEO rehberine bakabilirsiniz. Bu yazı yalnızca planlı ya da plansız kesinti senaryosuna odaklanır. Google belgelerindeki ayrıntılar değişebilir; uygulamadan önce güncel sayfaları kontrol edin.

Bakım Sayfası Neden 200 Dönmemeli

Birçok CMS eklentisi ve barındırma paneli bakım modunu "güzel görünen bir sayfa" olarak sunar. Ziyaretçi için yeterlidir; fakat durum kodu 200 ise tarayıcılar için bu sayfa sitenin yeni, normal içeriğidir.

200 yanıtı arama motoruna ne söyler?

Google'ın HTTP durum kodları belgesi (yeni sekmede açılır), 2xx dönen bir sayfada içeriğin dizinleme sürecinin sonraki adımına aktarıldığını söyler. Yani bakım metni, o adresin içeriği olarak değerlendirilmeye alınır. Aynı belge, 2xx dönen ama içeriği hata ya da boş sayfa gibi görünen yanıtlar için Search Console'un soft 404 bildirebileceğini ve dizinlemenin garanti olmadığını belirtir. Pratikte iki ihtimal vardır: bakım sayfası soft 404 olarak işaretlenir ya da kısa bir süre için sayfanın içeriği olarak okunur. İkisi de istenmeyen sonuçtur; birincisi gereksiz bir rapor kirliliği, ikincisi sayfanın gerçek metninin yerine "birazdan döneceğiz" yazısının değerlendirmeye girmesidir.

Kalıcı hata kodları da yanlıştır

404 ve 410, sayfanın yok olduğunu ya da kalıcı biçimde kaldırıldığını anlatan kodlardır. Bakım sürerken bunları dönmek, sayfaların geri geleceği bilgisini vermez. Yönlendirme de ayrı bir tuzaktır: tüm adresleri tek bir bakım sayfasına 301 ya da 302 ile yönlendirmek, sitenin adres yapısının değiştiği izlenimini yaratır ve bakım bitince yönlendirmeleri tamamen kaldırmak gerekir. Yönlendirme kullanmadan aynı adreste hata kodu dönmek daha temizdir. Alakasız sayfalara toplu yönlendirmenin soft 404 sayılabileceği, Google'ın site taşıma belgesinde de ayrıca uyarılan bir durumdur.

Eklentiler ve yönetim panelleri neden tuzaktır?

Hazır bakım modu eklentilerinin birçoğu varsayılan olarak güzel bir sayfa gösterir ve durum kodunu ayarlar menüsünde ayrı bir seçeneğe bırakır. Bazıları yalnızca giriş yapmamış ziyaretçilere bakım sayfası gösterir, yöneticiye normal siteyi açar; bu durumda kendi tarayıcınızdan test ettiğinizde sorunsuz görünür, tarayıcılar ise farklı bir yanıt alır. Eklentiyi etkinleştirdikten sonra mutlaka oturum açmamış bir pencereden ve komut satırından kontrol edin. Barındırıcının panelindeki "bakım modu" düğmeleri için de aynı kural geçerlidir: düğmenin hangi durum kodunu döndürdüğünü varsaymayın, ölçün.

503 neyi iletir?

503, sunucunun isteği şu anda karşılayamadığını bildiren bir sunucu hatasıdır. Google'ın belgesine göre 5xx ve 429 sunucu hataları, Google'ın tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açar. Belge ayrıca 500, 502 ve 503 gibi hatalarda tarama hızının, sunucu hatası dönen ayrı URL sayısıyla orantılı biçimde düşürüldüğünü söyler. Sunucu yeniden 2xx dönmeye başlayınca Google tarama hızını kademeli artırır; belge hız ya da süre için sayı vermez. Yani 503, tarama motorunun yaptığı iş açısından "şu an gelme, sonra tekrar dene" anlamına gelen, tasarlanmış bir sinyaldir.

Hızlı karşılaştırma

Gerçek bir hata mı, bilinçli bir bakım mı?

503 dönmenin iyi tarafı, planlı bakım ile plansız çöküşü aynı biçimde göstermesidir. Sunucu kendiliğinden yanıt veremediğinde de bu hata ortaya çıkar. Bu yüzden bakım penceresi bittikten sonra beklenmeyen 503'lerin sürmediğini doğrulamak, bakım kadar önemlidir. Kimin sorumlu olduğu, nasıl geri alındığı ve ne zaman kontrol edildiği önceden yazılmış olmalıdır.

503 ve Retry-After Uygulaması

Teknik olarak iş basittir: bakım sırasında istek alan her adres, 503 durum koduyla ve kısa bir HTML gövdesiyle yanıt verir. Zorluk, bunu tutarlı, her yol için ve önbelleği bozmadan yapmaktır.

Başlık, durum kodu ve gövde

Yanıt üç parçadan oluşur. Durum satırı 503 Service Unavailable olur. İsteğe bağlı Retry-After başlığı, ne zaman yeniden deneneceğini bildirir. Gövde ise ziyaretçiye gösterilen metindir. Gövdeye kısa bir açıklama, tahmini dönüş zamanı ve gerekirse bir iletişim yolu koyun. Metin, normal sayfa içeriği gibi okunmamalı; sade ve bilgilendirici olmalıdır.

Retry-After Google için ne ifade eder?

Google'ın HTTP durum kodları belgesi Retry-After başlığından söz etmez; dolayısıyla Google'ın bu başlığı nasıl kullandığına dair resmi bir ifade yoktur. MDN'nin Retry-After sayfası (yeni sekmede açılır) ise şunları söyler: başlık, kullanıcı aracısına sonraki isteği yapmadan önce ne kadar bekleyeceğini bildirir. İki biçimi vardır, saniye cinsinden negatif olmayan bir tam sayı ya da bir HTTP tarihi. 503 ile birlikte hizmetin ne kadar süre kullanılamaz olması beklendiğini gösterir; 429 ve yönlendirme yanıtlarında da kullanılır. Aynı sayfa, Googlebot gibi bazı tarayıcıların başlığı dikkate aldığını ve planlı kesintide 503 ile birlikte göndermeyi önerdiğini yazar, ancak istemci ve sunucu desteğinin tutarsız olduğunu da ekler. Sonuç olarak başlığı eklemek iyi bir uygulamadır; fakat Google'ın tarama sıklığını belirleyeceğini varsaymayın.

Hangi süreyi yazmalı?

Retry-After'a gerçekçi bir değer verin. Bakımın bir saat süreceğini düşünüyorsanız o süreyi saniye olarak yazın. Süreyi kısa tutup bakım uzarsa istek yine 503 alır; bu kabul edilebilir bir durumdur, çünkü başlık bir taahhüt değil, tahmindir. Bakım bitmeden başlıktaki süre geçtiyse değeri güncelleyin. Çok uzun ya da belirsiz bir süre yazmak ise tarayıcıya aslında "uzun süre gelmeyin" demek olur; planlanmış kısa bakım için gereksiz bir mesajdır.

Bütün URL'ler ve robots.txt dosyası

Kural şudur: bakım tüm siteyi etkiliyorsa tüm istekler 503 almalıdır. Kısmen 503, kısmen 200 dönen karışık bir durum, tarayıcı tarafında tutarsız sinyal üretir. Robots.txt dosyası da bu kapsama girer. Google'ın robots.txt belgesi (yeni sekmede açılır), dosyanın bulunduğu fakat getirilemediği 5xx durumunda şunu söyler: ilk 12 saat Google siteyi taramayı durdurur ama dosyayı getirmeyi denemeye devam eder; sonraki 30 gün son iyi sürüm kullanılır; 30 günden sonra hata sürerse ve site genel olarak erişilebilirse Google dosya yokmuş gibi davranır, site genel olarak erişilemiyorsa taramayı durdurup dosyayı arada bir ister. Bu kural bakım için yazılmış bir tarif değildir, ama kısa bir kesintide robots.txt'nin 503 dönmesinin tarama açısından bilinen bir davranışı olduğunu gösterir. Bakım sırasında robots.txt'yi 200 ve "Disallow: /" ile sunmak önerilmez, çünkü o durumda kesinti yerine "taramaya kapalı site" bildirmiş olursunuz ve bakım bitince dosyayı geri almayı unutmak ciddi bir tarama kaybına yol açar.

Bakım sayfası noindex taşımalı mı?

Google'ın robots.txt tanıtım sayfası (yeni sekmede açılır), robots.txt'nin bir sayfayı Google'dan uzak tutma mekanizması olmadığını söyler; engellenen bir URL başka sitelerin bağlantıları nedeniyle yine de dizinlenebilir. Sayfayı aramadan uzak tutmak için noindex ya da parola koruması önerilir. Sayfa bakım için bir süre erişilemeyecekse, durum kodu zaten geçici bir sunucu hatasıdır; ekstra noindex eklemek gereksizdir ve bakım sonrası unutulursa kalıcı sorun yaratır. Google belgeleri bakım sayfaları için doğrudan bir yönerge vermez; aşağıdaki öneri bir uygulama çıkarımıdır: durum kodu işi görüyorsa noindex'e gerek yoktur.

Önbellek ve CDN tuzağı

Bakım yanıtı bir CDN ya da ters vekil sunucu tarafından önbelleğe alınırsa, bakım bittikten sonra da kullanıcılar 503 görmeye devam edebilir. Bakım yanıtına önbelleğe alınmasını engelleyen başlıklar ekleyin, CDN'deki ilgili önbelleği bakımdan sonra temizleyin ve geri dönüşte hem kaynak sunucuyu hem CDN uç noktasını ayrı ayrı test edin. Bu, sunucu ayarlarına göre değişen genel bir uygulamadır.

Ziyaretçi için bakım metni nasıl yazılır?

Durum kodu arama motoruna, metin ise insana hitap eder. İyi bir bakım metni üç soruyu yanıtlar: ne oluyor, ne zaman biter, bu arada ne yapabilirim? "Sitemiz kısa süreliğine bakımda" cümlesi yeterli değildir; tahmini bitiş saatini, varsa durum bilgisi verilen bir kanalı ve acil işler için bir iletişim yolunu ekleyin. Sayfa hafif olmalı: harici yazı tipi, ağır görsel ya da üçüncü taraf betik yüklemek, zaten zorlanan bir altyapıda ek istek üretir. Metni ayrıca hem Türkçe hem İngilizce verin; çok dilli sitede bakım sayfası da iki dilde olmalıdır.

Tarayıcı dışındaki istemciler: API, mobil uygulama, geri çağrılar

Bakım yalnızca web sayfalarını değil, aynı sunucuyu kullanan API uçlarını da etkiler. Mobil uygulamalar ve dış servisler 503 yanıtını beklemiyorsa hata ekranı gösterebilir. API uçlarında bakım yanıtı JSON gibi makine okunur bir gövdeyle verilmeli, durum kodu yine 503 olmalıdır. Ödeme sağlayıcısı ya da başka bir dış sistem sizin adresinize geri çağrı gönderiyorsa, bakım sırasında bu çağrıların nasıl yeniden deneneceğini ilgili sağlayıcının belgesinden kontrol edin; sağlayıcıların davranışı farklıdır, bu yüzden varsayım yapmayın.

Uygulama kontrol listesi

• Bakım sayfası aynı adreste 503 döndürüyor, yönlendirme kullanılmıyor.
• Retry-After gerçekçi bir süreyle ekleniyor.
• Tüm yollar ve robots.txt aynı tutarlı davranışı gösteriyor.
• Gövdede kısa açıklama ve tahmini dönüş zamanı var.
• Bakım yanıtı önbelleğe alınmıyor.
• İzleme ve sağlık kontrolleri bakım sırasında yanlış alarm üretmeyecek biçimde ayarlandı.
• Bakım kapatma adımı yazılı ve sorumlusu belli.

Bakım Süresi: Kısa ve Uzun Kesinti

En çok sorulan soru "ne kadar sürerse sorun olur?" sorusudur. Dürüst cevap, Google'ın belgelerinde kesin bir eşik olmadığıdır.

Kesinti süresi için Google eşik vermiyor

HTTP durum kodları belgesine göre sunucu hataları taramayı geçici olarak yavaşlatır; ısrarlı sunucu hataları döndüren URL'ler ise dizinleme sürecinde eninde sonunda kaldırılır. Bu kaldırmanın kaç saat ya da gün sonra olacağı belgede yazmaz. Robots.txt belgesindeki 12 saat ve 30 gün rakamları yalnızca robots.txt dosyası için geçerlidir; sayfaların dizinden çıkma süresi olarak okunmamalıdır. Bu yüzden "iki gün güvenli" ya da "bir hafta tehlikeli" gibi kesin cümleler kurulamaz.

Süreye göre üç yaklaşım

Bölümleme: tüm site yerine yalnız etkilenen kısım

Bakım yalnızca ödeme akışını, bir üyelik alanını ya da bir arama modülünü etkiliyorsa tüm siteyi kapatmak gerekmez. Yalnızca etkilenen yollarda 503 döndürürseniz sitenin geri kalanı taranmaya ve ziyaret edilmeye devam eder. Bu, Google'ın "sunucu hatası dönen URL sayısıyla orantılı yavaşlama" tarifiyle de uyumludur: hata alan URL sayısı azaldıkça etki de küçülür. Kısmi bakımda dikkat edilecek nokta, gezinmenin ve iç linklerin bozuk sayfalara çok sayıda link vermemesidir.

Örnek senaryo: haftalık küçük güncelleme

Örnek senaryo: bir e-ticaret yöneticisi, gece trafiği düşük saatte veritabanı güncellemesi yapacak. Tüm site için bir saatlik bakım penceresi planlıyor, Retry-After değerini bir saat olarak ayarlıyor ve işlem bitince 503'ü kapatıyor. İlk gece ödeme ve sipariş kayıtlarının kuyruğa alındığını doğruluyor. Ertesi gün sunucu günlüklerinde Googlebot'un yeniden normal 200 yanıt aldığını görüyor. Böyle kısa ve planlı bir pencerede Google'ın belgesindeki davranış, tarama hızının geçici düşüp yeniden artmasından ibarettir; yine de ek bir sonuç garanti edilmez.

Uzayan bakım için karar kuralı

1. Kesinti öngörülen süreyi aştı mı? Retry-After değerini güncelleyin ve kullanıcıya dürüst bir tahmin verin.
2. Sorun tüm sitede mi, yalnız bir bölümde mi? Bölümlere ayırabiliyorsanız kalan kısmı açın.
3. Gün sayılan bir kesinti mi yaklaşıyor? Önce tarama ve dizin izlemesini sıklaştırın (günlükler, Search Console).
4. Bakımı uzatan işin bir bölümü ertelenebilir mi? Önce siteyi 200 yanıtlı normal durumuna döndürün, sonra işi yeniden planlayın.
5. Çözüm uzaktaysa kalıcı 404'e ya da yönlendirmeye geçmek yerine, 503 ile kaldığınız her günün riskini kayda alın.

Bakımı duyurmak ve zamanlamak

Planlı bakımı, trafiğin en düşük olduğu saatlere koyun; bu saati analitiğinizden gün ve saat kırılımıyla bulun. Kampanya, e-posta bülteni ya da reklam akışlarının başladığı saatlerden kaçının; ücretli trafik 503 sayfasına giderse hem bütçe hem de güven kaybı yaşarsınız. Reklam kampanyalarını bakım süresince duraklatmak, çoğu zaman en ucuz önlemdir. Önemli bir bakım için kullanıcılara önceden site içi uyarı ya da e-posta ile haber verin.

Plansız kesintide ne yapılmaz?

Sunucu çöktüğünde bazı barındırıcılar otomatik olarak yedek sayfa gösterir ve bunu 200 ile verebilir. Bu, bilmeden bakım sayfasını 200 ile yayınlamak demektir. Barındırıcınızın hata sayfalarının hangi kodu döndürdüğünü, kesinti yaşanmadan önce test edin. Aynı şekilde, kesintinin ilk saatlerinde robots.txt dosyasını silmek ya da boş bırakmak da bir çözüm değildir.

Test ve Geri Alma

Bakım modu açılış-kapanış testi yapılmadan canlıya alınan bir süreç, bakım dışı hata kaynağı olur. Yayın öncesinde temiz bir prova yapın.

Durum kodunu doğrulama

1. Tarayıcının geliştirici araçlarında ağ sekmesini açın ve ana sayfa ile iki ya da üç iç sayfanın 503 döndüğünü doğrulayın.
2. Komut satırı aracıyla (curl -I gibi) yalnızca başlıkları isteyip durum satırını ve Retry-After başlığını okuyun.
3. Robots.txt, site haritası ve bir görsel dosyasının da aynı davranışı gösterip göstermediğine bakın.
4. Giriş yapmış kullanıcı, yönetici ve API istemcisi için ayrı ayrı deneyin; bakım yalnızca belirli kullanıcıları dışarıda bırakıyorsa Googlebot'un kapsama girdiğinden emin olun.
5. Bakım modu canlıdaysa Search Console'daki URL denetim aracında canlı test çalıştırıp Google'ın aldığı yanıtı görün.

HEAD ve GET aynı yanıtı vermeli

Bazı bakım eklentileri GET isteğine 503, HEAD isteğine 200 dönebilir. İzleme araçları çoğunlukla HEAD ile kontrol ettiği için bakımın başlamadığını sanırsınız. İki yöntemi de deneyin.

Bakım kapatma ve geri alma planı

Bakım açıldığı anda kapatma adımını da yazın: hangi bayrak değişecek, hangi yapılandırma geri alınacak, hangi önbellek temizlenecek ve işlemi kim yapacak. Geri alma kararı için iki ölçüt belirleyin. Birincisi zaman: bakım planlanan süreyi belirli bir oranda aştıysa kesinti sorununu kökten ele alacak kişi devreye girer. İkincisi sonuç: bakım sonrası sitenin ana yolları 200 dönmüyorsa güncellemeyi geri çevirmek, kesintiyi uzatmaktan iyidir. Veri tabanı değişikliği içeren bakımlarda geri alınabilir yedek olmadan işlem başlatmayın.

Bakım sonrası "ilk beş dakika" listesi

• Ana sayfa, kategori ve bir ürün ya da makale sayfası 200 dönüyor.
• Robots.txt 200 dönüyor ve bakım öncesi içeriğiyle aynı.
• Site haritası erişilebilir.
• CDN ve önbellekte 503 kalıntısı yok.
• Retry-After başlığı artık gönderilmiyor.
• Sağlık kontrolü ve izleme araçları normale döndü.
• Giriş, arama ve ödeme gibi kritik akışlar çalışıyor.

Prova sonucunu yazıya dökün

Provada gördüğünüz durum kodlarını, başlıkları ve yanıt sürelerini kısa bir tabloya yazın. Canlı bakımda aynı tabloyu yeniden doldurup farkları karşılaştırırsanız, beklenmedik bir davranışı (örneğin yalnızca belirli bir yolda 200 dönmesi) dakikalar içinde fark edersiniz. Bakım ekibinin dışındaki biri de tabloyu okuyup işlemi doğrulayabilmelidir.

Hangi ortamda deneyin?

Prova mümkünse üretimle aynı önbellek ve CDN yapılandırmasına sahip bir ortamda yapılmalıdır. Aksi hâlde yerel makinede sorunsuz çalışan 503, üretimde CDN yüzünden farklı davranır. Test ortamını arama motorlarından uzak tutmak ayrı bir konudur; bu rehberde yalnızca bakım davranışı ele alınıyor.

Sonrasında Tarama ve İndeks Kontrolü

Bakım bittiğinde iş bitmez. Googlebot'un yeniden normal tarama düzenine dönmesini izlemek gerekir.

Tarama hızı ne zaman toparlanır?

Google'ın belgesine göre sunucu yeniden 2xx dönmeye başladığında tarama hızı kademeli olarak artırılır; ancak belge bunun için süre vermez. Toparlanmanın hızı sitenin büyüklüğüne ve kesintinin uzunluğuna göre değişebilir. Bu yüzden ilk günlerde tarama hızında düşüklük görmek beklenen bir durumdur; sorun, yavaşlamanın günlerce sürmesi ve yeni içeriğin bulunmamasıdır. Tarama kaynağının nasıl kullanıldığını daha geniş çerçevede anlamak için tarama bütçesi optimizasyonu yazısına bakabilirsiniz.

Sunucu günlüklerinde ne aranır?

Bakım penceresi sırasında Googlebot isteklerinin 503 aldığını ve bakım bittikten sonra 200'e döndüğünü günlüklerde doğrulayın. Beklenmeyen 5xx, sürekli 4xx ve bakım öncesinde taranan yolların artık taranmadığı yerler sorunu işaret eder. Günlük analizinin SEO için nasıl yapılacağı SEO sunucu log analizi yazısında anlatılıyor. Search Console'da ise sunucu hatalarına ve tarama istatistiklerine bakın; Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.

Soft 404 ve dizin raporu

Bakım sırasında yanlışlıkla 200 dönen sayfalar varsa Search Console soft 404 bildirebilir. Bu raporlar bakım bittikten sonra otomatik kapanmayabilir; sorunlu URL'leri tek tek denetleyip doğrulama başlatın. Soft 404 sorununun teşhisi ve düzeltilmesi için soft 404 hatası nedir ve nasıl düzeltilir yazısını kullanın.

Trafik ve görünürlük karşılaştırması

Bakım öncesi, sırası ve sonrası için Search Console performans verisini ve organik oturumları karşılaştırın. Kısa bir bakım, bakım gününde doğal olarak daha az ziyaret üretir; bunu kalıcı kayıp ile karıştırmayın. Beklenen: tarama toparlandıkça gösterimler bakım öncesi düzeye yaklaşır. Gösterimler birkaç hafta sonra hâlâ yerine gelmediyse, hangi sayfaların dizinden düştüğünü dizin raporundan çıkarın.

Bakım kaydı tutun

Her bakım için bir kayıt oluşturun: başlangıç ve bitiş saati, kullanılan Retry-After değeri, etkilenen bölümler, test sonuçları ve bakımdan sonraki ilk üç günde izlenen göstergeler. Bu kayıt, ileride trafikte beklenmedik bir dalgalanma görürseniz bakım ile ilişkisini hızla kurup ya da dışlamanıza yardım eder. Aynı kayıt, bir sonraki bakımın planlanmasında da hazır bir şablon işlevi görür.

Bakım sonrası karar tablosu

Sık Sorulan Sorular

Bakım modu SEO'yu etkiler mi?

Doğru yapılırsa kısa bir bakım genellikle büyük sorun çıkarmaz; yanlış yapılırsa etkileyebilir. Bakım sayfasının 200 dönmesi arama motoruna sayfanın normal olduğunu söyler. 503 ise geçici bir sunucu sorunu bildirir ve Google tarama hızını düşürür. Google belgeleri ısrarlı sunucu hatalarında URL'lerin eninde sonunda dizinden çıkarılabileceğini söyler, fakat bir gün sayısı vermez. Bu yüzden kesintiyi kısa tutmak gerekir.

Bakım sayfası için hangi durum kodu kullanılmalı?

Geçici bakım için 503 Service Unavailable uygundur. 404 ve 410 sayfanın kalıcı olarak yok olduğu izlenimini verir; 200 ise bakım metnini normal içerik gibi gösterir ve Search Console'da soft 404 raporuna yol açabilir. Yönlendirme ile bakım sayfasına göndermek de adresleri değiştiriyormuş gibi davranır, bu yüzden aynı adreste 503 dönmek daha temizdir.

Retry-After başlığını Google dikkate alır mı?

Google'ın HTTP durum kodları belgesi bu başlıktan söz etmez. MDN belgesi, Googlebot gibi bazı tarayıcıların başlığı dikkate aldığını ve planlı kesintide 503 ile birlikte göndermeyi önerdiğini yazar; aynı sayfa istemci ve sunucu desteğinin tutarsız olduğunu da belirtir. Başlığı zararsız ve iyi bir uygulama olarak ekleyin, ama etkisini garanti saymayın.

Bakım ne kadar sürerse tehlikeli olur?

Google'ın belgelerinde bu konuda gün ya da saat cinsinden bir eşik ifadesi yok. Yalnızca robots.txt dosyasında 5xx hata alındığında ilk 12 saat tarama durdurulur, sonraki 30 gün son iyi sürüm kullanılır. Kesinti uzadıkça riskin arttığı genel olarak doğrudur; bu yüzden bakımı mümkün olan en kısa pencerede planlayın ve süre uzuyorsa sayfa bazlı kısmi bakıma geçin.

Bakım sayfasını robots.txt ile engellemeli miyim?

Gerek yok. Google, robots.txt'nin bir sayfayı Google'dan uzak tutma mekanizması olmadığını söyler; engellenen URL başka sitelerden bağlantı alırsa yine de dizinlenebilir. Bakım için tüm siteye Disallow vermek, bakım bittikten sonra unutulursa tarama sorunu yaratır. 503 yanıtı bu iş için yeterli ve geri alması kolay bir yoldur.

Bakım bittikten sonra ne kontrol edilmeli?

Önemli sayfaların 200 döndüğünü, robots.txt dosyasının erişilebildiğini ve içeriğinin bakım öncesiyle aynı olduğunu, CDN ya da önbellekte 503 kalmadığını doğrulayın. Ardından Search Console'da tarama istatistiklerini, sayfa dizinleme raporunu ve sunucu günlüklerini birkaç gün izleyin. Google tarama hızını sunucu yeniden 2xx dönmeye başlayınca kademeli artırır.

Kesinti sırasında sipariş ve ödeme akışı için ne yapılmalı?

Bunun SEO tarafı 503'ün geçiciliğidir; iş tarafı ise ayrı planlanır. Süren ödemeler, bekleyen siparişler ve geri çağrılar bakım penceresinden önce tamamlanmalı ya da güvenli biçimde kuyruğa alınmalıdır. Ödeme sağlayıcısının geri çağrı adresleri 503 aldığında yeniden deneme yapıp yapmadığını sağlayıcının belgesinden kontrol edin.

İlgili rehberler: Web Sitesi Yenileme SEO Kontrol Listesi: Trafik Kaybetmeden Geçiş, Test Ortamı Google'da İndekslendi: Kaldırma ve Önleme, WordPress Etiket ve Arşiv Sayfaları: Noindex Kararı.

Sonuç

Bakım modunu SEO açısından güvenli yapan şey, süslü bir bakım sayfası değil, doğru durum kodudur. Aynı adreste 503 döndürün, Retry-After'ı gerçekçi bir süreyle ekleyin ama etkisini Google belgelerinde yer almayan bir garanti saymayın, robots.txt ve CDN davranışını aynı provada test edin ve süre uzadıkça kısmi bakıma geçmeyi düşünün. Google belgeleri bakım için açık bir gün eşiği vermez; bu yüzden kesintiyi kısa tutmak ve bitişini doğrulamak en güvenilir yoldur. Bakım sonrasında 200 yanıtlarını, robots.txt'yi, günlükleri ve Search Console raporlarını izleyin. Hiçbir adım belirli bir sıralama sonucunu garanti etmez; amaç, geçici bir teknik durumun kalıcı bir görünürlük kaybına dönüşmesini engellemektir.

Bakım dönemlerinde ve sonrasında sitenizi canlı tutacak rehber ve bilgi içeriklerini düzenli üretmek isterseniz Akua Adforce'ta makale yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.