Tarama İstatistiklerinde 5xx Artışı: SEO Ekibi Ne Zaman Müdahale Etmeli?

Geçici mi, Kalıcı mı? 5xx Artışını Doğal Dalgalanmadan Ayıran 3 Kriter

Google Search Console tarama istatistikleri raporunda ani bir 5xx artışı görmek stres yaratır; ancak her spike eşit risk taşımaz. 5xx terimlerini SEO sözlüğünde inceleyin — bu kodlar sunucunun isteği işleyemediğini gösterir, ancak durumun kalıcılığı SEO açısından belirleyici faktördür. Üç temel kriter, doğal dalgalanmayı gerçek riskten ayırır.

Spike süresi, ilk sorudur. Birkaç dakika ile birkaç saat arasındaki kısa spike’lar; sunucu yeniden başlatmaları, geçici yük artışları veya kısa bakım pencereleri nedeniyle gerçekleşir. Hatanın başlangıç ve bitiş saatini kaydetmek, karar sürecinin temelidir. Spike kendiliğinden kapandıysa müdahale önceliği otomatik olarak düşer ve gözlem moduna geçmek yeterlidir.

Hata oranı, ikinci kriterdir. Google’ın resmi Search Console belgelerine göre tarama istatistikleri raporu, toplam tarama istekleri içinde 5xx kodlarının payını gösterir. Toplam 5xx hata sayısını günlük toplam tarama isteğine bölerek oranı hesaplayın. %5’in altındaki oran düşük risk, %10 ve üzeri ise müdahale eşiği olarak değerlendirilir.

Etkilenen URL kümesi ise üçüncü ve en kritik kriterdir. Hata tek bir dizini mi etkiliyor yoksa tüm siteyi mi? Ürün listeleme sayfaları veya ödeme akışı gibi gelir kritik sayfalar etkilendiyse, düşük hata oranına rağmen müdahale önceliği artar. Tek bir CDN edge node’unun veya sunucu örneğinin arızalanması genellikle bölümsel hata örüntüsü üretir; bu imzayı site genelindeki bir sorundan ayırt etmek, doğru müdahale katmanını belirlemenin ön koşuludur.

Googlebot 5xx ile Karşılaştığında Ne Yapar? Tarama Daraltma Mekanizması

Yaygın bir yanılgı, Googlebot’un 5xx hatasıyla karşılaştığında o sayfayı kalıcı olarak tarama listesinden çıkardığıdır. Google’ın resmi crawl istatistikleri belgesine göre Googlebot, hata aldığında taramayı durdurmaz; tarama hızını kademeli olarak düşürür ve site yeniden erişilebilir hale geldiğinde oranı adım adım artırır.

Bu kademeli daraltma mekanizması, kısa süreli spike’ların kalıcı SEO hasarı yaratmamasının temel nedenidir. Googlebot, aşırı sunucu yükü dönemlerinde robot trafiğini otomatik azaltır; site istikrara kavuştuktan sonra tarama hızını önce temkinli biçimde artırır. Bu toparlanma süreci birkaç saat ila birkaç gün arasında değişebilir ve herhangi bir manuel tetikleme gerektirmez.

503 + Retry-After başlığı, geçiciliği Googlebot’a resmi olarak bildirmenin en doğru yöntemidir. Google, bu kombinasyonu planlı kesinti sinyali olarak yorumlar ve tarama daraltmasını daha öngörülebilir biçimde yönetir. 2025 yılında güncellenen Google tarama bütçesi belgeleri, geçici hatalara yönelik tolerans penceresini daha net tanımladı. Planlı bakım dönemlerinde 503 + Retry-After kullanmak, SEO açısından en güvenli bakım modu seçeneğidir.

Robots.txt için Google’ın katı eşikleri ayrı bir risk tablosu çizer: robots.txt dosyasına 24 saat erişilemezlik taramayı durdurur; 30 gün boyunca erişilemeyen robots.txt dosyası Googlebot tarafından yokmuş gibi değerlendirilir. Bu eşikler, içerik sayfalarına kıyasla çok daha acil müdahale gerektiren kritik senaryolardır.

Ne Zaman Bekle, Ne Zaman Müdahale Et? Somut Eşik Değerleri ve Hata Tipi Karşılaştırması

Soyut tavsiyeler yerine somut eşik değerleri, karar sürecini hızlandırır. Süre, hata oranı ve etkilenen URL kümesi üç risk profilinde özetlenebilir:

• Düşük risk (bekle): Spike süresi 2 saat altında, hata oranı %5’in altında, spike kendiliğinden kapanmış. Googlebot’un otomatik daraltma mekanizması yeterlidir; manuel müdahale gerekmez.
• Orta risk (izle): 2-4 saat, %5-10 hata oranı, sınırlı URL kümesi etkilenmiş. Sunucu loglarını anlık izleyin; spike 4 saate ulaşırsa müdahale adımlarına geçin.
• Yüksek risk (müdahale et): 4+ saat, %10 ve üzeri hata oranı veya gelir kritik dizinler etkilenmiş. Gecikmeden sunucu ya da CDN müdahalesi başlatın.

Hata tipi de müdahale önceliğini doğrudan belirler. 503, Retry-After başlığıyla birleştiğinde geçicilik sinyali gönderir ve en güvenli hata kodudur; Retry-After yoksa kalıcı hata olarak yanlış yorumlanma riski doğar. 500 Internal Server Error, uygulama katmanı sorununa işaret eder ve kalıcı hata olarak algılanma ihtimali yüksek olduğundan müdahale önceliği yüksektir. 502 Bad Gateway, reverse proxy veya load balancer arızasını gösterir. 504 Gateway Timeout ise origin sunucunun yanıt vermediğine işaret eder; CDN kaynaklı mı origin kaynaklı mı olduğunu netleştirmeden müdahale planı oluşturmak yanıltıcı olabilir.

2025 yılı itibarıyla GSC Tarama İstatistikleri raporundaki uyarı mekanizmaları daha okunabilir hale getirildi; hata tipi dağılımını doğrudan rapor arayüzünden takip etmek kolaylaştı. Bununla birlikte GSC’nin yaklaşık 48 saatlik veri gecikmesini unutmamak gerekir — anlık karar için sunucu logları birincil kaynak olmaya devam eder.

Vaka Analizi: 3 Saatlik Hosting Outage’da GSC Tarama Logları ile Sunucu Loglarını Paralel İzlemek

Eşik değerlerinin pratikte ne anlama geldiğini bir e-ticaret sitesinde yaşanan outage vakasıyla somutlaştıralım. Gece 02:15’te hosting sağlayıcısının sunucu yeniden başlatması tetiklendi; 3 saat 10 dakika boyunca site yaklaşık %40 oranında 503 hatası döndürdü. Sabah 05:25’te sistem otomatik olarak toparlandı.

İlk tepki GSC’yi kontrol etmek yönünde oldu. Ancak GSC’nin yaklaşık 48 saatlik veri gecikmesi nedeniyle outage sırasında raporda herhangi bir spike görünmüyordu. Gerçek veri sunucu erişim loglarındaydı: her dakika ortalama 340 Googlebot isteği geliyordu, bunların yaklaşık 136’sı 503 döndürüyordu — hata oranı %40, yüksek risk eşiğinin belirgin biçimde üzerinde. Buna karşın süre 4 saatin altında kaldığından kalıcı indeks kaybı yaşanmadı.

Kritik öğrenme şu oldu: GSC tarama istatistikleri, outage bittikten 36-48 saat sonra spike’ı görünür hale getirdi. Bu gecikme farkındalığı olmadan iki farklı hataya düşülebilir: ya anlık kriz döneminde GSC’de her şey normal sanılır ya da 48 saat sonra spike’ı gören ekip gereksiz alarm durumuna girer. Anlık kriz kararı için sunucu access logu ve uptime monitörü tek güvenilir kaynak olarak öne çıktı.

CDN kaynaklı 5xx ile origin server kaynaklı 5xx’in log imzaları da bu vakada net biçimde ayrıştı. CDN kaynaklı hatalarda tüm edge node’lardan eş zamanlı hata akışı gözlemlendi; origin kaynaklı hatalarda ise hatalar belirli IP aralıklarından kaynaklandı. Search Engine Journal’ın Cloudflare kesintisi analizinde de vurgulandığı üzere, 2024-2025 döneminde büyük CDN kesintilerinin toplu spike’lara yol açmasıyla birlikte bu ayrım giderek daha kritik hale geldi — CDN kaynaklı 5xx’te origin sunucuya müdahale etmek sorunu çözmez.

Adım Adım Müdahale Protokolü: Spike’ı Gördüğünüzde İlk 30 Dakika

Bir 5xx spike’ı tespit ettiğinizde doğru sırayla hareket etmek hem gereksiz paniği önler hem de gerçek sorunların gözden kaçmasını engeller. Aşağıdaki adımlar ilk 30 dakikayı yapılandırır:

1. Sunucu erişim loglarını açın ve spike saatini tespit edin. GSC’yi değil sunucu loglarını kullanın — GSC yaklaşık 48 saat gecikmeyle güncellenir, anlık karar için güvenilir değildir. Hatanın tam olarak hangi saatten itibaren başladığını kaydedin.
2. Spike süresini ve hata oranını hesaplayın. Hatanın başladığı saatten itibaren kaç dakika veya saat geçtiğini belirleyin. 5xx sayısını toplam tarama isteğine bölün; %5 altındaysa düşük risk, %10 ve üzeriyse yüksek risk sınıfına girer.
3. Etkilenen URL kümesini segmentlere ayırın. Hata tüm siteyi mi yoksa belirli bir dizini mi etkiliyor? Ürün listeleme, sepet veya ödeme gibi kritik gelir sayfaları öncelikli değerlendirme kapsamındadır.
4. Kaynağın CDN mi yoksa origin server mı olduğunu netleştirin. CDN loglarını kontrol edin; kaynak belirsizken oluşturulan müdahale planı yanlış katmana odaklanır ve sorunu çözmez.
5. Bekle veya müdahale et kararını verin. 2 saat altı, düşük oran ve spike kapanmışsa bekleyin. Aksi halde sunucu veya CDN tarafında müdahaleyi derhal başlatın.
6. Sorun giderildikten sonra Validate Fix tetikleyin. Outage devam ederken Validate Fix kullanmayın — erken tetikleme GSC’de false positive oluşturur. Sunucu en az 30-60 dakika hatasız çalıştıktan sonra tetikleyin.

AIOSEO’nun teknik rehberine göre outage sırasında erken tetiklenen Validate Fix, GSC’nin yeni bir tarama turunu hata devam ederken başlatmasına yol açabilir; bu durum false positive raporlara ve güvenilirlik kaybına neden olur. Zamanlama bu adımın en kritik parametresidir.

SEOYEN Site Sağlığı ile 5xx Spike’larını Anlık İzleme ve Toparlanma Takibi

5xx spike’larını anlık izlemek için GSC’nin yaklaşık 48 saatlik veri gecikmesi göz önüne alındığında bağımsız bir izleme katmanı kritik önem taşır. Site sağlığı raporunda özelleştirilebilir alarm eşikleri ve otomatik izleme kurulumu bu ihtiyacı doğrudan karşılar. GSC verilerini Türkçe arayüzde yorumlamak ve hata tipine göre segmentlere ayırmak için harcanan zaman önemli ölçüde azalır.

Ahrefs veya SEMrush gibi uluslararası platformlar kapsamlı tarama analizi sunar; ancak tarama istatistiklerini Türkiye pazarına uyarlanmış Türkçe arayüzde yorumlamak, yerel Türkçe destek alabilmek ve TL bazlı fiyatlandırmayla döviz kuru belirsizliğini ortadan kaldırmak için SEOYEN tek platformda güçlü bir alternatif sunar.

Outage geride kaldıktan sonra toparlanmanın doğrulanması da kritik bir adımdır. Sıralama takibi ile toparlanma hareketlerini sıralama verileriyle doğrulamak, 5xx artışının gerçekten sıralama kaybı yaratıp yaratmadığını nesnel biçimde ortaya koyar. Kısa süreli spike’larda çoğunlukla sıralama değişimi gözlemlenmez; bu da bekleme kararının doğrulandığını kanıtlar. Güncel planlar ve fiyatlandırma için fiyatlandırma sayfamızı ziyaret edebilirsiniz.

Sıkça Sorulan Sorular