Hosting Kesintisinde SEO: 5xx Hataları ve Tarama Etkisi

Sunucu kesintisi tek başına sitenizi aramadan silmez, ama kesinti sürerse Google tarama hızını düşürür, kesinti çok uzarsa daha önce dizine alınmış sayfalar eninde sonunda dizinden düşebilir. Kısa bir hata dalgası için yapılacak iş sunucuyu ayağa kaldırmak, sonra Search Console'da toparlanmayı izlemektir. Bir derneğin aylık yayın sitesini, üye bültenini ya da PDF arşivini yönetiyorsanız ve yeni sayının yayın gününde site çöktüyse, doğru sıra şudur: önce Google'ın 5xx ve 429 kodlarına ne yaptığını bilin, sonra kesintinin ne kadar sürdüğüne göre karar verin, en sonda toparlanmayı ölçün.

Kesinti sırasında Google sitenizde ne görür

Googlebot sayfanızı istediğinde sunucu bir HTTP durum kodu döndürür. Sağlıklı yanıt 2xx ailesidir. Sunucu yanıt veremiyorsa 500, 502 ya da 503 gibi 5xx kodları, aşırı yük sinyali verdiğinde ise 429 görülür. Google'ın HTTP durum kodları belgesi (yeni sekmede açılır) bu iki grubu birlikte ele alır: 5xx ve 429 sunucu hataları, Google tarayıcılarının taramayı geçici olarak yavaşlatmasına yol açar. Belge ayrıca 429'un aşırı yüklenmiş sunucu işareti sayıldığını ve bu yüzden diğer 4xx kodlarından ayrı, sunucu hatası gibi işlendiğini anlatır.

Kesinti sırasında üç ayrı sorun birbirine karışabilir. Sunucu sayfayı vermiyor olabilir (5xx), sunucu aşırı yük nedeniyle sizi sınırlıyor olabilir (429) ya da Googlebot sunucuya hiç ulaşamıyor olabilir. Search Console'un Tarama İstatistikleri raporu bu son durumu ayrı bir bölümde, “Host status” altında gösterir: robots.txt getirme, DNS çözümleme ve sunucu bağlantısı. Arayüzü Türkçe kullanıyorsanız etiket adları farklı görünebilir.

Tablo: Kesintide karşılaşılan durum ve Google belgesindeki karşılığı.

Son satırın önemi büyüktür. "Şu kadar saat dayanır" ya da "şu kadar gün sonra düşer" gibi bir süre bu belgede yer almaz, bu nedenle süre vaat etmek doğru olmaz.

429 ve 5xx kodları tarama hızını nasıl etkiler

Google belgesine göre 500, 502 ve 503 hataları için tarama hızı, hata veren tekil URL sayısı oranında düşürülür. Yani sitenin yalnız küçük bir bölümü hata veriyorsa etki küçük, büyük bölümü hata veriyorsa büyük olur. Bu, kısmi kesintilerde de önemlidir: veritabanı yavaşladığında yalnız arşiv sayfaları 500 veriyor olabilir ve bu bile tarama hızını etkiler.

Belge arama dizini için şunu söyler: dizinde zaten olan URL'ler korunur, fakat eninde sonunda düşürülür. Dizinleme sistemi, kalıcı olarak sunucu hatası (500, 502, 503) döndüren URL'leri kaldırır. 5xx ile dönen içerik de yok sayılır. Bunun anlamı şudur: kesinti sırasında Google sayfanızın bozuk ya da boş halini kaydetmez, ama o sırada o sayfadan yeni bir şey öğrenmez.

Durum kodlarının genel resmi için HTTP durum kodları ve SEO rehberi yazısına bakabilirsiniz.

Tarama hızı düştü, peki ne zaman geri gelir

Belge toparlanma için tek bir cümle verir: sunucu yeniden 2xx durum koduyla yanıt verdiğinde Google siteye yönelik tarama hızını kademeli olarak artırır. Kademeli ifadesi önemlidir, çünkü sunucu düzelir düzelmez tarama hızının eski haline dönmesi garanti edilmez. Belgede toparlanma süresi için bir sayı ya da aralık yoktur.

Tarama kapasitesi sınırı ve yanıt süresi

Google'ın tarama bütçesi belgesi (yeni sekmede açılır) bunun arkasındaki mantığı anlatır. Her site aynı varsayılan ve temkinli bir tarama kapasitesi sınırıyla başlar. Talep varsa ve site sağlıklı kalıyorsa sınır artar. Yanıt süreleri (gecikme ve ilk bayta kadar geçen süre dahil) sabit kalırsa ya da iyileşirse sınır yükselir. Site sunucu hatalarıyla (5xx) ya da hız sınırlama sinyalleriyle (429 gibi) yanıt verirse sınır düşer ve Google daha az tarar.

Aynı belge bir uyarı da içerir: tarama bütçesi rehberi esas olarak büyük siteler içindir. Belgenin kendi ifadesiyle haftada bir kez değişen bir milyon ve üzeri benzersiz sayfa ya da günlük değişen on bin ve üzeri benzersiz sayfa için bir tahmindir, kesin eşik değildir. Hızla değişen çok sayıda sayfanız yoksa belgenin bütün önerilerini okumanız gerekmez. Küçük bir dernek yayınında bu belge, kesintinin neden tarama hızını düşürebileceğini açıklayan bir arka plan olarak yararlıdır, ama günlük "tarama bütçesi" tutmanız gerekmez. Ayrıntı için tarama bütçesi optimizasyonu yazısına bakın.

Yanıt süresinin sınırı yükseltmesi, kesinti öncesi uyarı işaretlerini de açıklar: sunucu yavaşlıyorsa bu, tam çöküşten önce tarama kapasitesini etkileyebilir. İlk bayt süresi ve önbellek için TTFB, önbellek ve CDN yazısına bakın.

Kısa kesinti mi uzun kesinti mi: ne zaman endişelenmeli

Google belgeleri süre eşiği vermediği için karar kuralını gözleme dayandırmak gerekir. Karar tablosu bir uygulama önerisidir, Google'ın sınıflandırması değildir.

Karar tablosu: Kesintiyi nasıl değerlendirmeli.

Endişeyi belirleyen üç soru

• Kesinti sırasında hangi URL'ler hata verdi: tüm site mi, bir bölüm mü?
• Hatalar tek seferlik miydi, yoksa günlerdir tekrarlıyor mu?
• Düzeldikten sonra Tarama İstatistikleri'nde 200 oranı ve ortalama yanıt süresi normale dönüyor mu?

Bu üç sorunun yanıtları kesintinin tek seferlik bir olay mı yoksa hosting yapısı sorunu mu olduğunu ortaya koyar. Tekrarlıyorsa asıl iş, tarama etkisini ölçmek değil, barındırma çözümünü değiştirmektir.

robots.txt dosyasının kesintideki özel yeri

Search Console yardımına göre Google bu dosyayı düzenli olarak ister, bu yüzden dosyanın getirilememesi taramayı yavaşlatabilir ya da durdurabilir. Aynı yardım sayfasındaki kontrol listesi şunu söyler: robots.txt ya geçerli bir dosya ya da 404 ya da 410 döndürmelidir, 5xx ya da 429 döndürmemelidir. Sunucunuz kesintide tüm yolları 5xx ile yanıtlıyorsa robots.txt de buna dahildir.

Bu yüzden toparlanmayı izlerken robots.txt getirme durumuna ayrı bakın. Belgelerde bu konuda "kaç gün sonra ne olur" gibi bir ifade yoktur. Yardım sayfası ayrıca, rapordaki toplamlar sunucu günlüklerinizden çok daha yüksek görünüyorsa robots.txt'nin uzun süre ulaşılamaz olup olmadığını kontrol etmenizi söyler.

Kesintiyi doğuran nedenler ve ilk ayrım

Aynı 5xx dalgası çok farklı kökenlerden gelebilir ve düzeltme yolu köken ile belirlenir. Uygulama önerisi olarak nedenleri ayırın.

Üçüncü ve beşinci satırlar özellikle dikkat ister. Bir sertifika ya da DNS sorunu Search Console'da “Host status” altında DNS çözümleme ya da sunucu bağlantısı hatası olarak görünebilir, bu yüzden raporun “Host status” içindeki üç kategoriye ayrı ayrı bakmak nedeni ayırmaya yardım eder. Koruma katmanı kaynaklı 429 ise Google'ın tarayıcısını yavaşlatan bir yanlış alarm olabilir. Böyle bir durumda sorun hosting değil kural ayarıdır; ayrıntı için Googlebot erişimini doğrulama yazısındaki yöntemi izleyin.

Kısmi kesinti: yalnız bir bölüm çöktüğünde

Dernek sitesinde sayı arşivi ve arama sayfaları ağır sorgular çalıştırıyorsa, ana sayfa açılırken bu bölümler 500 verebilir. Google belgesi tarama hızının hata veren URL sayısıyla orantılı düştüğünü söylediği için, bölümün büyüklüğü etkiyi belirler. Pratik çıkarım: ağır bölümleri tespit edin, bu sayfalar için önbellek kullanın ve gerekirse arama sonuç sayfalarını tarama dışında bırakmayı ayrıca değerlendirin. Robots.txt'yi tarama bütçesini geçici olarak yeniden dağıtmak için kullanmayın; Google tarama bütçesi belgesi bu konuda açık bir uyarı yapar. Robots.txt, hiç taranmasını istemediğiniz sayfaları engellemek içindir.

Plansız kesintide ilk saatin sırası

Planlı bakımda 503 sayfası ve Retry-After başlığı için bakım modu ve 503 yazısındaki yöntemi kullanın. Plansız kesintide durum farklıdır, çünkü sunucu sizin istediğiniz yanıtı vermeye hazır değildir. Uygulama önerisi olarak sıra şudur.

1. Kesintinin kapsamını belirleyin: tüm site mi, yalnız yönetim paneli mi, yalnız belirli sayfalar mı?
2. Hosting sağlayıcınızın durum sayfasına ve destek kanalına bakın, sorunun sizden mi sağlayıcıdan mı geldiğini ayırın.
3. Mümkünse hatalı sayfa yerine geçici bir yanıtı sunucunuzun ya da CDN'inizin önünden verin. Hata sayfasının 200 koduyla dönmesi, bozuk içeriği normal sayfa gibi gösterir. Geçici sayfanın doğru durum koduyla (503) dönmesini hedefleyin; bu bir uygulama önerisidir.
4. Robots.txt dosyasının geçerli bir yanıt verdiğini doğrulayın.
5. Kesintiyi, saatleri ve alınan adımları bir olay kaydına yazın.
6. Düzeldikten sonra ilk kontrol: ana sayfa, bir makale, bir PDF, robots.txt ve sitemap dosyası beklenen yanıt kodunu veriyor mu?

Akla gelen soru şudur: geçici sayfanın bakım modu yazısındaki yöntemle mi hazırlanacağıdır. Cevap: sunucu hâlâ çalışıyorsa evet, yöntem aynıdır. Sunucu hiç yanıt veremiyorsa elinizde hiçbir sayfa sunma imkânı olmayabilir, bu durumda önleme bölümündeki hazırlıklar işe yarar.

Toparlanmayı Search Console'da izlemek

Tarama İstatistikleri raporu bu iş için doğru yerdir. Search Console yardımına göre rapor şu bölümlerden oluşur: toplam tarama isteği (başarılı ya da başarısız her istek), toplam indirme boyutu, ortalama yanıt süresi, “Host status”, tarama yanıtları (durum kodlarının yüzdesi), dosya türü, tarama amacı (keşif ya da yenileme) ve Googlebot türü. “Host status” son 90 günü gösterir ve yeşil ise önemli bir sorun olmadığını belirtir. Raporun ayrıntı sayfası için Search Console yardımına (yeni sekmede açılır), kullanımı için Tarama İstatistikleri raporu rehberine bakın.

Tablo: Toparlanma sırasında bakılacak göstergeler.

Yardım sayfasının sunduğu kontrol listesi bu izlemeyi özetler: “Host status” bölümünün yeşil olduğunu doğrulayın, yeşil değilse yanıt tablosuna ve “Host status” içindeki üç kategoriye bakın. 5XX hatalarını, zaman aşımlarını ve beklenmedik 4XX kodlarını arayın ve sunucu sorunlarını düzeltin.

Tekil sayfalar için kontrol

Bir makalenin kesintiden sonra Google'da nasıl göründüğünü Search Console URL Denetimi ile sınayabilirsiniz. Sitemap'e yeni eklenen sayıların tek tek kontrol edilmesi, yeni sayı gününde yaşanan bir kesintiden sonra özellikle yararlıdır. Erişim sorunlarının güvenlik duvarı ya da CDN kurallarından da gelebileceğini unutmayın, ayrıntı için Googlebot erişimini doğrulama yazısına bakın.

Sunucu günlükleriyle karşılaştırmak

Tarama İstatistikleri Google'ın bakış açısını gösterir, sunucu günlükleri ise sizinkini. İki kaynağı yan yana koymak kesinti analizini sağlamlaştırır. Search Console yardım sayfası, rapordaki toplamlar sunucu günlüklerinizden çok daha yüksekse robots.txt'nin uzun süre ulaşılamaz olup olmadığına bakmanızı söyler; bunun tersi de bir ipucu verir: günlüğünüzde kesinti saatlerinde hiç Googlebot isteği görünmüyorsa istek sunucunuza ulaşmamış olabilir, bu da ağ, DNS ya da koruma katmanı sorununa işaret eder.

Uygulama önerisi olarak günlükten şu soruların yanıtını çıkarın: kesinti başladığında istekler hangi kodlarla yanıtlandı, hangi URL grupları hata verdi, yanıt süreleri kesintiden önce yükseliyor muydu ve Googlebot'un istek sayısı kesinti sonrasında nasıl bir eğilim izledi? Günlüğü kendi sunucunuzda tutuyorsanız kişisel veri içerebileceğini (IP adresleri gibi) unutmayın ve saklama sürenizi buna göre belirleyin. Sahte Googlebot istekleri olabileceği için kullanıcı aracısı adına tek başına güvenmeyin.

Örnek senaryo: yayın günü çöken dernek sitesi

Örnek senaryo: bir meslek derneği her ayın ilk iş gününde dergisinin yeni sayısını sitesinde yayınlıyor ve üyelere e-posta gönderiyor. Yayın sabahı e-posta gidiyor, aynı anda binlerce üye siteye giriyor ve paylaşılan hosting yanıt veremez hale geliyor. Birkaç saat boyunca sayfalar 503 ve 500 veriyor.

Ne olduğunu sırayla düşünelim. Sunucu hataları sırasında Google hem tarama hızını düşürür hem de o hata veren sayfalardan yeni bir şey öğrenmez. Kesinti kısa sürerse ve sunucu 2xx ile yanıt vermeye başlarsa, belgeye göre tarama hızı kademeli olarak artar. Derneğin yapması gerekenler şunlardır: sağlayıcıyla kesintinin nedenini netleştirmek, Tarama İstatistikleri'nde hata oranının düştüğünü doğrulamak, yeni sayının sayfasını URL Denetimi ile sınamak ve bir sonraki yayın gününe önlem almak.

Önlem seçenekleri: e-posta gönderimini saatlere yaymak, sayının PDF dosyasını ayrı bir dosya sunucusuna ya da CDN'e koymak, sayı sayfasını önbelleğe almak ve yük artışını önceden hosting sağlayıcısıyla konuşmak. Bunların hangisinin yeterli olduğunu sitenizin gerçek trafiği belirler. Belgelerde bir "güvenli eşik" yoktur.

Aynı senaryoda karar noktaları

Burada dikkat edilecek bir nokta, kesinti süresince yayınlanan e-postadaki bağlantının kendisidir. Üyelerin tıkladığı adres tam da hata veren sayı sayfasıdır, dolayısıyla kesinti hem tarama hem kullanıcı deneyimi tarafında aynı sayfayı vurur. Bu yüzden sayı sayfasının ve PDF dosyasının önbelleğe alınması en yüksek getirili önlemdir. Bunun nedeni Google belgesinden değil, olayın yapısından gelir. Dernek ayrıca aynı sayfanın canonical adresinin hata sırasında değişmediğini, yönlendirmelerin bozulmadığını ve sitemap'in 200 döndüğünü kontrol etmelidir.

Kesinti sonrası denetim planı: gün gün

Bu sıra Google belgelerindeki bir takvim değildir, kendi çalışma planınız için bir iskelettir. Süreleri sitenizin boyutuna göre ayarlayın.

Sağlayıcıya sorulacak sorular

• Kesintinin teknik nedeni neydi ve tekrar edebilir mi?
• Planımın kaynak sınırları nelerdir ve bu olay sırasında hangisi aşıldı?
• İzleme ve uyarı hizmetiniz kesintiyi ne kadar sürede fark etti?
• Yük artışı öncesinde plan yükseltmek ya da önbelleği genişletmek mümkün mü?
• Yedekten geri yükleme süreniz ve son yedeğin zamanı nedir?

Bu soruların yanıtları, sağlayıcıyı değiştirip değiştirmeme kararınızın temelidir. Taşıma kararında DNS geçişi ve eski sunucuyu açık tutma konusunda hosting değişiminde SEO yazısına bakın.

Önleme listesi: kesinti olmadan önce

Kesintiyi tamamen önlemek mümkün olmayabilir, ama etkisini küçültmek ve hızla fark etmek mümkündür.

• Dışarıdan çalışan bir çalışma süresi izleme servisi kurun ve uyarıyı bir kişiye değil iki kişiye gönderin.
• Önemli sayfa türleri için (ana sayfa, sayı sayfası, PDF arşivi) ayrı kontrol adresleri tanımlayın.
• Yük kaynaklarını bilin: e-posta bülteni, sosyal medya paylaşımı, basın yazısı gibi anlık trafik yaratacak etkinlikleri takvime işleyin.
• Önbellek ve CDN kullanın, sayfa üretimini hafifletin.
• Hosting planınızın sınırlarını (eşzamanlı bağlantı, kaynak limiti) sağlayıcı belgelerinden okuyun.
• Sağlayıcı değiştirme senaryosunu önceden planlayın, kesinti tekrarlıyorsa taşımayı hosting kontrol listesi ile değerlendirin.
• Tarama İstatistikleri raporunu ayda bir gözden geçirin, “Host status” bölümünde sorun varsa erken fark edin.
• robots.txt'nin hataya düşmemesi için statik bir dosya olarak sunulmasını sağlayın. Bu bir uygulama önerisidir.

Yük artışı yaratan etkinlikleri takvime yazın

Kesintiyi iletmek: üyeler, ziyaretçiler ve ekip

Teknik düzeltme kadar iletişim de önemlidir. Bir derneğin üyeleri e-postayla gelen bağlantının açılmadığını fark ettiğinde kuşku duyabilir. Uygulama önerisi: kısa bir durum duyurusu hazırlayın, sosyal medya hesabında ve e-postada tek cümleyle sorunun bilindiğini yazın ve düzeldiğinde bir kapanış mesajı gönderin. Duyuruda teknik ayrıntıyı kısa tutun, gerçek nedeni bilmeden tahmin yazmayın.

İç iletişim için kesinti kaydı tutun: başlangıç saati, fark edilme saati, düzelme saati, etkilenen bölümler ve alınan adımlar. Bu kayıt hem sağlayıcıyla yazışmada hem bir sonraki planlamada kanıt olur. Sağlayıcıdan kesinti raporu isteyin.

Duyuru metninin iskeleti

Uygulama önerisi: duyuru üç cümleyi geçmesin. Ne oldu (siteye erişimde sorun yaşandı), şimdiki durum (sorun giderildi ya da üzerinde çalışılıyor) ve üyenin yapması gereken (bir şey yapmasına gerek yok ya da bağlantıyı yeniden deneyin). Nedeni bilmiyorsanız tahmin yazmayın, "inceliyoruz" demek yeterlidir. Saldırı, veri kaybı gibi iddialar kanıtlanmadan duyuruya girmemelidir. Düzelme sonrası ayrı bir kapanış mesajı üyelere sorunun bittiğini bildirir.

Kesinti sonrası değerlendirme soruları

Kesinti kapandıktan sonra kısa bir değerlendirme yapmak, aynı sorunun ikinci kez yaşanmasını önlemenin en ucuz yoludur. Uygulama önerisi: soruları suçlu aramak için değil, boşluğu bulmak için sorun.

Karar kuralı: aynı neden iki kez yaşandıysa çözümü ayarlarda değil mimaride arayın. Tek seferlik bir nedense önleme listesine madde olarak ekleyip konuyu kapatın.

Karıştırılan noktalar

İlk karışıklık, kesintinin otomatik olarak sıralama kaybı demek olduğunu varsaymaktır. Google belgesi tarama hızı, içeriğin yok sayılması ve kalıcı hatalarda dizinden düşme gibi sonuçlardan söz eder. Sıralama kaybı garantisinden ya da "şu kadar süre sonra" ifadesinden söz etmez. İkinci karışıklık, 503'ün tarama hızını korumak için sihirli bir çözüm olduğunu sanmaktır. Belge 503'ü de, 500 ve 502 ile birlikte, tarama hızını düşürebilecek sunucu hataları arasında sayar. Üçüncüsü, kesinti sonrası hemen "yeniden dizine ekle" isteği yağdırmaktır. Belgede bunun gerekli olduğuna dair bir ifade yoktur, toparlanmayı önce raporlarda izleyin. Dördüncüsü, tarama bütçesi belgesinin her siteye aynı biçimde uygulandığını sanmaktır: belge büyük siteler içindir.

Altıncı bir yanlış anlama, kesintinin yalnızca teknik bir olay sayılmasıdır. Dernek için aynı olay üyelere verilen bir sözdür; bu yüzden olay kaydına teknik nedenin yanında üyelere ne söylendiğini ve ne zaman söylendiğini de yazın. Böylece bir sonraki kesintide sunucu ve iletişim tarafı aynı kayıttan toparlanır.

Sık Sorulan Sorular

Hosting kesintisi sıralamamı düşürür mü?

Google belgesi 5xx ve 429 hatalarının tarama hızını düşürdüğünü, 5xx ile dönen içeriğin yok sayıldığını ve kalıcı sunucu hatası veren URL'lerin eninde sonunda dizinden düşebileceğini söyler. Belgede sıralama kaybı vaadi ya da kesin bir süre yoktur.

Kesinti ne kadar sürerse dizinden düşerim?

Belgede kesin bir süre verilmez. Yalnız dizindeki URL'lerin korunduğu ama eninde sonunda düşürüldüğü yazar. Kesinti uzuyorsa Tarama İstatistikleri'ni izleyin.

Sunucu düzeldi, tarama ne zaman normale döner?

Google belgesine göre sunucu yeniden 2xx ile yanıt verince tarama hızı kademeli olarak artar. Bu sürenin uzunluğu için belgede ifade yoktur.

429 kodu 5xx gibi mi sayılır?

Evet. Belge 429'u aşırı yük işareti olarak ele alır ve diğer 4xx kodlarından ayırıp sunucu hatası gibi işler.

Küçük bir site tarama bütçesi için endişelenmeli mi?

Google'ın tarama bütçesi belgesi esas olarak büyük siteler içindir ve hızla değişen çok sayıda sayfanız yoksa tüm rehberi okumanız gerekmediğini söyler. Kesintinin tarama hızına etkisi ise her site için geçerlidir.

Kesintiden sonra Search Console'da nereye bakmalıyım?

Tarama İstatistikleri raporunda “Host status” bölümüne, tarama yanıtlarına, ortalama yanıt süresine ve robots.txt getirme durumuna bakın. Yardım sayfası 5XX hataları, zaman aşımları ve robots.txt'nin 5XX ya da 429 dönmemesini kontrol etmenizi söyler.

Sonuç

Hosting kesintisi bir sıralama cezası değil, bir erişim sorunudur ve Google belgesi sonuçlarını açıkça sayar: tarama yavaşlar, hata veren içerik yok sayılır, kalıcı hatalar eninde sonunda dizinden düşmeye yol açabilir ve sunucu düzelince tarama kademeli olarak toparlanır. Belgeler süre vermez, bu yüzden karar gözleme dayanmalıdır. Kapsamı belirleyin, robots.txt'yi doğrulayın, Tarama İstatistikleri'ni izleyin ve tekrarlayan kesintiyi bir barındırma sorunu olarak ele alın. Önleme listesi bir sonraki yayın gününü rahatlatır.

Siteniz sağlıklı çalıştıktan sonra görünürlüğünüzü büyütmek istiyorsanız backlink paketlerimize göz atabilirsiniz.