Tarama İstatistiklerinde Ani Düşüş: Hangi Sinyaller İncelenmeli?

Düşüş Gerçek mi, Anomali mi? Raporu Doğru Yorumlamak

Google Search Console’un Tarama İstatistikleri raporu, Googlebot’un sitenizi ne sıklıkta ziyaret ettiğini, aldığı yanıt kodlarını ve ortalama sunucu yanıt sürelerini günlük granülerlikte gösterir. Ancak rapordaki ani bir düşüş her zaman gerçek bir teknik soruna işaret etmez; veri gecikmesi ve örnekleme farklılıkları tek günlük sapmalara neden olabilir.

Düşüşün gerçek bir sorun olduğundan emin olmak için şu eşiği kullanın: düşüş 3 günü aşıyor ve hem keşif hem yenileme segmentlerinde eş zamanlı görünüyorsa teknik teşhise geçin. Yalnızca tek günde gözlemlenen ve sonraki günlerde toparlamış bir çukur büyük olasılıkla veri gecikmesidir.

Google’ın 2020’de sunup 2024-2025 döneminde keşif/yenileme ayrımıyla güncellediği Tarama İstatistikleri raporu, düşüşün nereden kaynaklandığını çok daha hızlı belirlemenizi sağlamaktadır. Zaman aralığını son 90 güne ayarlayarak bir önceki yılın aynı dönemiyle karşılaştırın; mevsimsel örüntüler zaman zaman tarama hacmini gerçekten etkiler. Düşüş yalnızca keşif segmentinde ise iç link ve site mimarisi sorununa, yalnızca yenileme segmentinde ise içerik kalitesi veya noindex/canonical hatasına odaklanın.

İlk Kontrol Noktası: robots.txt Engellemeleri ve Erişim Kısıtlamaları

Tarama düşüşü tanısında her zaman ilk bakılacak yer robots.txt dosyasıdır. Search Console’daki robots.txt Test aracını çalıştırın ve dosyanın en son değiştirilme tarihini kontrol edin. Bu tarihin tarama düşüşünün başlangıcıyla örtüşmesi kural değişikliğine işaret eder ve doğrulamayı hızlandırır.

Aşırı geniş kapsamlı Disallow kuralları — örneğin Disallow: / veya tüm kritik bir dizini kapatan bir kural — Googlebot’u saatler içinde durdurabilir ve bu durum günler içinde indeksleme kaybına dönüşür. Daha ince ama bir o kadar tehlikeli hata ise CSS ve JavaScript varlıklarına erişim kısıtlamasıdır. Googlebot sayfaları doğru biçimde değerlendirmek için bu kaynaklara erişmek zorundadır; erişim engellendiğinde rendering kalitesi düşer ve etkilenen sayfalar zamanla sıralamadan çekilebilir — ancak bu sorun doğrudan 5XX hatası olarak görünmez.

• robots.txt son değişiklik tarihini tarama düşüşü başlangıcıyla karşılaştırın.
• Search Console robots.txt Test aracında kritik URL’leri ve CSS/JS varlıklarını Googlebot user-agent’ıyla test edin.
• Staging ortamına ait bir robots.txt’in yanlışlıkla production’a kopyalanmadığını doğrulayın.
• Değişiklik geçmişini dağıtım kayıtları veya git commit loglarıyla çapraz doğrulayın.

Sunucu Sinyalleri: 5XX Hataları ve TTFB Eşik Değerleri

Google’ın resmi Crawl Budget Management dokümantasyonuna göre, 5XX hata oranı yükseldiğinde Googlebot sunucunun aşırı yüklendiğini varsayarak tarama hızını otomatik biçimde kısıtlar. Bu mekanizma sunucuyu koruma altına almak için tasarlanmıştır; hata oranı normale döndüğünde tarama kademeli olarak yeniden artar, ancak tam iyileşme birkaç günü bulabilir.

Yanıt süresi için kritik eşik 500 ms TTFB değeridir. Googlebot birim zamanda sabit sayıda eş zamanlı bağlantı açar; TTFB 500 ms’yi aştığında her istek daha uzun sürer ve Googlebot aynı sürede daha az URL tarayabilir. Bu durum, efektif tarama bütçesi kullanımını doğrudan olumsuz etkiler. Tarama İstatistikleri raporunun Yanıt Süresi sekmesinde grafiğin belirgin biçimde yükseldiği noktayı tespit edin ve bunu altyapı değişiklikleriyle ilişkilendirin.

2026 itibarıyla HTTP/3 ve QUIC protokolünün yaygınlaşmasıyla sunucu yanıt süresi optimizasyonu crawl budget tartışmalarında daha merkezi bir yer almaktadır. QUIC, bağlantı kurulum gecikmesini azaltarak özellikle yüksek gecikme süreli ağlarda TTFB’yi kayda değer ölçüde iyileştirmektedir. CDN sağlayıcınızın HTTP/3 desteğini etkinleştirip etkinleştirmediğini kontrol etmek, tarama verimliliğine doğrudan katkı sağlayacak düşük maliyetli bir iyileştirme adımıdır.

Tarama İstatistikleri raporunun Yanıt Kodu sekmesini açın; 5XX oranı %2’yi aşıyor ya da grafikte belirgin bir artış görülüyorsa sunucu sorununu derhal önceliklendirin. Ortalama TTFB eğrisi de düşüş dönemine denk gelen bir sıçrama gösteriyorsa bu iki veriyi birlikte sunucu ekibine iletmek teşhis sürecini önemli ölçüde hızlandırır.

Log Dosyası + Search Console Verisi: Gerçek Bir Vakadan Adım Adım Tanı Süreci

Teorik çerçeveyi gerçek bir örnekle pekiştirmek, iki veri kaynağının birlikte nasıl kullanılacağını netleştirir. Bir müşterimizin e-ticaret sitesi, hosting sağlayıcı geçişinin tamamlanmasından yaklaşık dört gün sonra Search Console Tarama İstatistikleri raporunda belirgin bir düşüş gösterdi; iki haftalık pencerede günlük tarama sayısı yaklaşık %40 geriledi.

İlk şüphe robots.txt’e yöneldi. Disallow kuralları tek tek test edildi, Search Console robots.txt Test aracı çalıştırıldı; tüm sonuçlar temizdi. İkinci adımda log dosyalarına geçildi. Sunucu erişim loglarında Googlebot user-agent (Googlebot/2.1) filtresi uygulandı; istek frekansının düştüğü, hata dağılımının büyük ölçüde normal göründüğü ancak TTFB değerlerinin ortalama 1,4 saniyeye yükseldiği tespit edildi. Yeni hosting sağlayıcısının varsayılan yapılandırması dinamik içerik için optimize edilmemiş, yanıt süresi önceki değerin yaklaşık üç katına çıkmıştı.

Log verisiyle Search Console verisi çakıştırıldığında şu tablo ortaya çıktı:

• Log dosyası: Googlebot’un gerçekte hangi URL’leri ziyaret ettiğini, TTFB dağılımını ve hata kodlarını URL bazında gösterir.
• Search Console: Yanıt kodlarını özetler, segment bazında tarama sayısını raporlar; ancak Googlebot’un tüm isteklerini yansıtmaz.
• Örtüşmezlik noktaları: Log’da görünen bazı Googlebot istekleri Search Console’a başarılı yanıt olarak kaydedilmeyebilir; bu noktalar render sorunlarını veya bağlantı kopmalarını işaret eder.

Sorun, PHP-FPM havuz boyutunun artırılması ve object cache etkinleştirilmesiyle çözüldü; TTFB 280 ms’ye geriledi ve üç hafta içinde tarama sayısı eski seviyesine döndü. Bu vaka, yalnızca Search Console verisiyle yetinilseydi sorunun kök nedeninin —sunucu yanıt süresi— uzun süre gözden kaçacağını açıkça göstermektedir.

Adım Adım Tarama Düşüşü Tanı Süreci

Tarama istatistikleri raporunda ani düşüş gördüğünüzde şu yedi adımı sırayla uygulayın:

1. Tarama İstatistikleri raporunu açın: Google Search Console > Ayarlar > Tarama İstatistikleri; zaman aralığını düşüşü kapsayacak biçimde ayarlayın.
2. Anomali mi, gerçek düşüş mü belirleyin: Düşüş 3 günü aşıyorsa ve keşif ile yenileme segmentleri birlikte düşüyorsa teknik sorun olarak değerlendirin.
3. robots.txt’i kontrol edin: Search Console robots.txt Test aracını çalıştırın; CSS/JS varlıklarını da kapsayan Disallow kurallarına özellikle dikkat edin.
4. 5XX oranı ve TTFB grafiğini inceleyin: 5XX oranı %2’yi aşıyor veya ortalama TTFB 500 ms’nin üzerindeyse sunucu sorununu önceliklendirin.
5. Keşif ve yenileme segmentlerini ayrı değerlendirin: Yalnızca keşif düşüşü iç link sorununa, yalnızca yenileme düşüşü içerik kalitesi sorununa, her ikisi birlikte yapısal bir soruna işaret eder.
6. Log dosyalarını analiz edin: Googlebot user-agent’ını filtreleyin; istek frekansı ve TTFB değerlerini Search Console verileriyle karşılaştırın.
7. Sorunu giderin ve yeniden tarama isteği gönderin: URL Denetimi aracıyla kritik sayfalar için yeniden tarama isteyin; iyileşmeyi 48-72 saat izleyin.

Keşif ve Yenileme Taraması Segmentleri: Hangi Düşüş Neye İşaret Eder?

Search Console’un 2024-2025 döneminde sunduğu keşif/yenileme ayrımı, tarama düşüşlerini doğru kategorize etmek açısından son derece değerlidir. Keşif (discovery) taraması, Googlebot’un daha önce görmediği URL’leri bulmaya çalıştığı taramadır; bu segmentin düşmesi iç link yapısında kopukluklar, XML site haritasındaki eksiklikler veya yeni içeriklerin hiçbir bağlantıyla desteklenmemesi anlamına gelir.

Yenileme (refresh) taraması ise dizinde zaten yer alan sayfaların güncellenip güncellenmediğini kontrol eder. Bu segmentte düşüş gözlemlendiğinde noindex veya canonical etiketlerinin hatalı uygulanması, içeriğin uzun süre güncellenmemesi ya da zayıflayan PageRank sinyalleri öncelikli inceleme konularıdır.

JavaScript ağırlıklı mimarilerde (SPA, Next.js, Nuxt) her iki segment de baskı altına girer. Googlebot, client-side rendered içerikleri işlemek için ek kaynak harcamak zorundadır; bu render maliyeti tarama bütçesini daha hızlı tüketir. Server-side rendering (SSR) veya statik site üretimi (SSG), JavaScript-heavy sitelerde tarama verimliliğini artıran en etkili teknik çözümdür.

Pratik öncelik sıralaması: yalnızca keşif segmenti düşüyorsa iç bağlantı denetimi ve site haritası güncellemesini, yalnızca yenileme segmenti düşüyorsa içerik kalitesi denetimi ve etiket revizyonunu, her iki segment birlikte düşüyorsa sunucu sinyallerini ve robots.txt kontrolünü önce alın.

Tarama Düşüşünden Sonra: Zaman Çizelgesi, Crawl Budget Optimizasyonu ve SEOYEN ile Proaktif İzleme

Google’ın site trafik düşüşü teşhis rehberine göre tarama düşüşünün trafiğe yansıma süreci doğrusal değildir: önce indeksleme yavaşlar, ardından mevcut sayfalar güncelliğini yitirir, sıralamalar geriler ve son olarak organik trafik düşer. Bu nedensellik zinciri tipik olarak 2-8 hafta içinde trafiğe yansır; erken teşhis bu gecikmeyi kısmen telafi edebilir.

Sorun giderildikten sonra crawl budget optimizasyonu için öncelik sırası şu şekilde olmalıdır:

1. Yanıt süresini iyileştirin: TTFB hedefini 500 ms altına çekin; CDN, object cache ve sunucu yapılandırmasını gözden geçirin.
2. Kırık bağlantıları temizleyin: 404 dönen iç linkler tarama bütçesini boşa harcar; düzenli denetimle giderin.
3. Düşük kaliteli sayfaları ele alın: İnce içerikli ve yinelenen sayfaları noindex ile işaretleyin ya da geliştirin.
4. İç link yapısını güçlendirin: Yetim sayfaları bağlantıyla destekleyin, keşif taramasını besleyin.
5. XML site haritasını güncel tutun: Yalnızca indekslenebilir ve kanonik URL’leri ekleyin.

SEOYEN’in site sağlığı aracı, tarama hatalarını, kırık iç linkleri ve yavaş yanıt veren sayfaları Türkçe arayüzde otomatik olarak listeler. Ahrefs veya SEMrush bu tür analizleri sunar; SEOYEN ise bu özellikleri Türkiye pazarına yönelik Türkçe arayüz ve TL bazlı fiyatlandırmayla tek platformda bir araya getirir. Sıralama takibi aracıyla tarama düşüşü ile organik görünürlük değişimini paralel izleyerek nedensellik zincirini erken aşamada yakalayabilirsiniz. Güncel planlar için fiyatlandırma sayfasını inceleyebilirsiniz.

Sıkça Sorulan Sorular