Bir kullanıcı 503 döndüren bir sayfayla karşılaştığında genellikle birkaç saniye bekler ya da sayfayı yeniler; sunucu toplandığında sorun ortadan kalkmış olur. Googlebot aynı sayfayı taramaya geldiğinde ise deneyim farklı işler: bot ya isteği birkaç saniye içinde terk eder ya da kısa süre sonra bir kez daha dener, ama bu deneme döngüsü başarısız oldukça tarama kaynakları harcanmış, o sayfa bir süreliğine güncellenemez hale gelmiş olur. Kullanıcı için geçici bir rahatsızlık olan durum, Googlebot için tarama programını bozan, bütçeyi tüketen ve zamanla indeksleme sürekliliğini tehdit eden bir sinyal haline dönüşebilir.
5xx hataları, sunucunun isteği aldığını ancak tamamlayamadığını bildirdiği HTTP yanıt kodlarıdır. 500 İç Sunucu Hatası, 503 Hizmet Kullanılamıyor, 504 Ağ Geçidi Zaman Aşımı bunların en sık görülenleridir. Teknik açıdan birbirinden ayrışırlar; SEO perspektifinden bakıldığında ise etkileri çoğunlukla örtüşür ama bazı kritik farklılıklar taşırlar. Özellikle yoğun trafik dönemlerinde ortaya çıkan, büyük siteler için düşük sayıda kalabilen, küçük siteler için görece birkaç hatayla bile bütçeyi zorlayan bir sorun kategorisidir. Bunu değerlendirmek için önce hatanın Googlebot tarafından nasıl yorumlandığını anlamak gerekir.
Sorun yalnızca "hata var mı yok mu" sorusuna indirgenemez. Hataların hangi sayfalarda yoğunlaştığı, ne sıklıkla tekrarladığı, geçici mi yoksa yapısal mı olduğu ve log ile GSC verisinde nasıl göründüğü: bunların tamamı birlikte okunduğunda SEO üzerindeki gerçek etkinin boyutu netleşir. Bu yazı bu okuma çerçevesini kurmaya çalışır.
Kullanıcı için geçici olan hata, Googlebot için tarama döngüsü kırılması anlamına gelebilir
Googlebot belirli bir sayfayı tarama programına aldığında bu program birkaç faktöre göre şekillenir: sayfanın daha önce ne sıklıkla güncellendiği, sitedeki genel içerik hızı, sayfanın iç link ağındaki konumu. Tarama gerçekleştiğinde bot 5xx yanıtıyla karşılaşırsa isteği tamamlayamaz. Bu noktada iki şey olur: mevcut içerik güncellenmemiş olarak indekste kalır, bir sonraki tarama denemesi ise ertelenir.
Erteleme süresi sabit değildir. Google, başarısız isteklerden sonra tarama sıklığını dinamik olarak ayarlar. Pratikte bu şu anlama gelir: normalde haftada birkaç kez taranan bir sayfa 5xx döndürdükten sonra birkaç haftaya kadar uzayan bir bekleme süresine girebilir. Bu süre zarfında sayfada yapılan güncellemeler indekse yansımaz, yeni eklenen iç linkler taranmaz, sayfa son kullanıcıya eski bilgiyle sunar.
Kullanıcı sayfayı saniyeler içinde yenilediğinde sorunu görmez. Bot erteleme döngüsüne girdiğinde ise SEO etkisi sessizce birikmeye başlar. Bu asimetri 5xx sorunlarının kullanıcı şikayetleri üzerinden değil, log analizi ve crawl budget analizi üzerinden takip edilmesini gerektirir.
Bir başka boyut daha var: Googlebot'un erteleme mantığı sabit bir algoritma değil, siteye özgü dinamik bir uyumdur. Bot belirli bir sitede art arda başarısız isteklerle karşılaşırsa o siteye olan tarama baskısını genel olarak azaltır. Bu durum yalnızca hata alan sayfaları değil, aynı sunucu üzerinde çalışan sağlıklı sayfaları da etkileyebilir; tarama kapasitesi dar çerçevede tahsis edildiğinde bütün site havuzundan pay alınmış olur.
500, 503 ve 504 hataları Googlebot'un gözünde aynı değildir
5xx ailesi tek bir davranış kalıbı sergilemez. Google'ın bu hata kodlarını yorumlama biçimi farklılaşır ve bu fark SEO müdahalesinin nasıl şekillenmesi gerektiğini doğrudan etkiler.
503 Hizmet Kullanılamıyor, Google'ın geçici bir durum olarak kabul etmeye en yatkın olduğu koddur. Özellikle bakım dönemlerinde sunucunun kendisi 503 döndürüyorsa ve buna Retry-After başlığı eşlik ediyorsa Googlebot bu süreyi bekleyebilir. Kısa süreli ve tutarlı bir 503 mantığı planlı bakımlarda SEO açısından nispeten güvenli bir yaklaşımdır. Ancak 503'ün plansız biçimde, yoğun trafik dönemlerinde düzensiz aralıklarla tekrarlaması bu toleransı ortadan kaldırır; bot artık bunu geçici değil yapısal bir sorun olarak yorumlamaya başlar.
500 İç Sunucu Hatası bir uygulama katmanı sorununu işaret eder. Sunucu isteği aldı, ama işleyemedi. Bu kod için genellikle bir Retry-After sinyali bulunmaz; Googlebot geçici bir durum mu yoksa sayfanın kalıcı olarak bozulduğu mu olduğunu koddan çıkaramaz. Tekrarlayan 500 hataları indeks kaybına daha hızlı ilerleme eğilimi taşır.
504 Ağ Geçidi Zaman Aşımı ise sunucunun isteği aldığını ancak yukarı akış sunucusundan zamanında yanıt alamadığını bildirir. Genellikle altyapı katmanında (yük dengeleyici, veritabanı bağlantısı, üçüncü taraf API çağrıları) düğümlenir. Googlebot açısından sonuç 500'e benzer; sayfa yanıtsız kaldı ve tarama tamamlanamadı. 504 hatalarının yoğunlaşması çoğunlukla trafik zirvelerinde bağlantı havuzunu dolduran, sunucu kapasite sınırlarına takılan altyapı sorunlarına işaret eder.
Üç kod arasındaki ayrım yalnızca teknik sınıflandırma değildir. Hangi kodun ne zaman yoğunlaştığını bilmek, sorunun bakım planlamasından mı, uygulama katmanından mı yoksa altyapı kapasitesinden mi kaynaklandığını anlamaya yardımcı olur. Bu ayrım log dosyasında görünür, teknik SEO analizinde de bu ayrıma göre müdahale yolu değişir.
5xx hataları tarama bütçesini iki ayrı kanaldan tüketir
Crawl bütçesi üzerindeki etki tek boyutlu değildir. 5xx hataları bütçeyi iki farklı mekanizma üzerinden tüketir ve ikisi de ayrı sorunlar doğurur.
İlk mekanizma başarısız isteğin kendisidir. Googlebot bir URL'yi taramaya çalıştığında, ister başarılı ister başarısız olsun, bu istek tarama bütçesinden düşer. 5xx döndüren bir URL botu hiçbir kullanılabilir içerikle ödüllendirmeden bütçe tüketmiş olur. Sitede yüzlerce URL düzenli aralıklarla 5xx döndürüyorsa bu URL'ler için harcanan bütçe, değerli içerik sayfalarına gidebilecek tarama kapasitesini erimektedir.
İkinci mekanizma yeniden deneme döngüsüdür. Google başarısız bir tarama isteğini tamamen terk etmez; belirli aralıklarla aynı URL'yi yeniden dener. Bu yeniden denemeler de bütçeden harcanır. Sürekli 5xx döndüren bir URL, her yeniden deneme turunda ek bütçe tüketen bir drenaj noktasına dönüşür. Büyük sitelerde bu etki daha az belirgindir ama toplam URL havuzu sınırlı olan küçük ve orta ölçekli sitelerde birkaç sorunlu URL bile tarama verimliliğini ciddi biçimde düşürebilir.
Log analizi bu iki mekanizmayı ayrı ayrı görünür kılar. Başarısız ilk istekler hangi URL'lerde yoğunlaşıyor, yeniden denemeler hangi zaman aralıklarında gelişiyor, başarılı taramalar bütçenin ne kadarını alabiliyor: bunları görmek için log verisi dışında başka bir kaynak yoktur. GSC tarama raporları bu düzeyde çözünürlük sunmaz; yalnızca log satırları Googlebot'un sunucuya gönderdiği her isteği kayıt altına alır.
Geçici sunucu hatası yoğunlaşırsa Google site güvenilirliğini yeniden değerlendirmeye başlar
Tek bir 503, hatta aynı gün içinde birkaç düzine 503, büyük olasılıkla kalıcı bir SEO hasarına yol açmaz. Google'ın sistemleri geçici hataları tolere edecek biçimde tasarlanmıştır. Ancak bu toleransın bir eşiği vardır; bu eşik aşıldığında dinamik değişir.
Pratikte şöyle görünür: bir site haftalarca süren ve her gün belirli saatlerde (yoğun trafik dönemlerinde) yüzlerce 5xx üretiyorsa Googlebot bu saatlerde bu siteye gelen isteklerini giderek azaltmaya başlar. Bu azaltma bir ceza değil, bir uyum mekanizmasıdır; bot başarısız olacağını öğrendiği zaman dilimlerinde kaynağını harcamaz. Ama sonuç aynıdır: tarama frekansı düşer, içerik güncellemeleri geç yansır, yeni sayfalar taramaya daha geç girer.
Daha uzun vadede ve hata oranı yüksek kalıyorsa Google'ın site genelindeki tarama hızını kalıcı olarak düşürdüğü gözlemlenebilir. Bu noktada sorun tekil URL'lerin taranmamasının ötesine geçer; sitenin bütünü için ayrılan tarama kapasitesi daralır. Organik trafik düşüşleri çoğunlukla bu evreden haftalarca sonra yüzeye çıkar, çünkü indeks değişikliklerinin görünür hale gelmesi zaman alır.
Güvenilirlik değerlendirmesinin ne zaman devreye girdiğini kesin bir eşikle tanımlamak mümkün değildir; Google bu parametreyi kamuoyuyla paylaşmaz. Ama log verisinde tarama frekansının belirgin biçimde azaldığını ve ardından aynı dönemde GSC'de hata uyarılarının yoğunlaştığını görüyorsanız bu iki sinyal birlikte okunduğunda anlamlı bir uyarıdır.
Log analizi ve GSC, 5xx etkisini farklı çözünürlüklerde gösterir
5xx hatalarını hem log analizi hem de GSC üzerinden izlemek mümkündür, ama ikisi farklı sorulara yanıt verir ve bu fark denetim sürecinde önemlidir.
GSC Kapsam raporu 5xx hatalarını "Sunucu hatası (5xx)" kategorisinde listeler. Bu listede hangi URL'lerin hata aldığını, kaç URL'nin etkilendiğini ve sorunun dönemsel mi yoksa sürekli mi olduğunu görmek mümkündür. GSC bu verileri birkaç günlük gecikmeyle raporlar ve yalnızca Google'ın gördüğü URL'leri kapsar. Hatanın yoğunlaştığı dönemi ve etkilenen sayfa kategorisini anlamak için GSC yeterli bir başlangıç noktasıdır.
Log analizi ise daha yüksek çözünürlük sunar. Her Googlebot isteği, yanıt kodu, yanıt süresi, istek zamanı ve URL bilgisiyle log satırında görünür. Bu veriyle şu soruları yanıtlamak mümkündür: 5xx hataları günün hangi saatlerinde yoğunlaşıyor? Belirli URL kalıplarında mı kümeleniyor, yoksa site geneline mi dağılmış? Yeniden deneme istekleri ne sıklıkla geliyor ve başarı oranı nedir? Hata dönemleriyle tarama frekansındaki düşüş arasında zamansal bir korelasyon var mı?
GSC verileri sorunun var olduğunu doğrular; log verisi sorunun yapısını açıklar. İkisi birlikte olmadan müdahalenin nereden başlaması gerektiğini net biçimde belirlemek güçleşir. GSC'de 5xx uyarısı görüp log olmadan hareket etmek, etkiyi genişletilmiş biçimde görmeden önlem almaya çalışmak anlamına gelir.
Log verisi yoksa başlangıç noktası olarak GSC'deki URL listesini URL segmentlerine göre gruplamak ve hangi sayfa tipinin yoğunlaştığını tespit etmek yardımcı olur. Kategori URL'leri mi, içerik sayfaları mı, yoksa parametreli URL'ler mi: bu gruplama, altyapı sorununu kökten çözmek için teknik ekiple yapılacak görüşmenin de çerçevesini oluşturur.
Hata yoğunluğuna ve etkilenen sayfa tipine göre önceliklendirme
Her 5xx aynı aciliyetle müdahale gerektirmez. Önceliklendirme kararı iki eksende kurulur: hatanın yoğunluğu ve etkilenen sayfaların SEO değeri.
Yoğunluk değerlendirmesinde log verisine bakılır. Kaç farklı URL etkileniyor? Aynı URL'ler tekrar tekrar hata veriyor mu yoksa her seferinde farklı URL'ler mi? Hatalar günün belirli dilimlerinde mi yoğunlaşıyor, yoksa düzensiz mi dağılmış? Yüzlerce URL'yi etkileyen ve tekrarlayan bir hata, birkaç URL'yi arada sırada etkileyen bir hatadan çok farklı müdahale gerektirir.
Sayfa tipi boyutunda ise hangi URL'lerin hata aldığı kritiktir. Kategori sayfaları veya yüksek trafik alan içerik sayfaları mı etkileniyor? Yoksa filtre kombinasyonları, arşiv URL'leri ya da zaten düşük tarama önceliği olan sayfalar mı? Denetimde önceliklendirme mantığı burada da geçerlidir: yüksek SEO değeri taşıyan sayfaların hata alması aynı hatanın düşük öncelikli sayfalarda görülmesinden çok daha hızlı müdahale gerektirir.
Bakım penceresiyle çakışan planlı 5xx'ler ayrı bir kategori oluşturur. Bu durumda sorun teknik değil süreç tasarımıdır: bakım süresi minimize edilmeli, 503 kodu Retry-After başlığıyla doğru biçimde servis edilmeli, bakım saatleri mümkünse Googlebot'un tarama yoğunluğunun düşük olduğu dönemlerle örtüşmeli. Log verisi bu örtüşmeyi planlamak için de kullanılabilir; hangi saatlerde Googlebot'un az istek gönderdiği log satırlarından okunabilir.
5xx sorunlarını denetim sürecinde izole bir teknik sorun olarak değil, taranabilirlik ve indeksleme zincirinin bir halkası olarak değerlendirmek gerekir. Sunucu katmanındaki bir sorun kapasite, uygulama veya altyapı kökenli olabilir; ama SEO üzerindeki yansıması her zaman aynı kanaldan akar: Googlebot sayfaya ulaşamadı, bütçe harcandı, içerik güncellenmedi, güncelleme indekse gecikmeli yansıdı. Bu zinciri görmek için teknik takımla konuşmak ve log verisiyle GSC'yi birlikte okumak şarttır.
Sorunun ciddiyetini küçümsemek kadar abartmak da denetimi verimli yürütmez. Tek bir sunucu hatası paniği gerektirmez. Ama log satırlarında haftalarca süren, belirli URL gruplarını ya da belirli saat dilimlerini tutarlı biçimde vuran, GSC'de de uyarı olarak görünen bir hata örüntüsü: bu, teknik SEO gündeminin üst sıralarına taşınması gereken bir sinyaldir.
Son olarak şunu belirtmek gerekir: 5xx hataları çoğunlukla SEO ekibinin değil altyapı ya da geliştirme ekibinin sahiplendiği bir alandır. SEO tarafından bu sorunları görünür kılmak, hata yoğunluğunu URL tipi ve zaman dilimiyle ilişkilendirmek ve tarama kaybını somut veriyle ortaya koymak, müdahale önceliğini teknik gündemde doğru yere yerleştirmenin yolu haline gelir. SEO raporlarında sunucu hata eğilimlerini ayrı bir izleme kalemi olarak tutmak bu süreci daha sistematik kılar.