Crawl budget ve sunucu yanıt süresi ilişkisi: SEO’da net etki ölçümü

Crawl budget (arama motoru tarama bütçesi) konusu çoğu zaman “robotlar daha çok gelsin” gibi yorumlarla geçiştiriliyor. Oysa crawl budgetın fiili davranışı; sitenin sunucu yanıt süreleri, hata oranları (HTTP 5xx/4xx), yönlendirme zinciri (redirect chain), dosya boyutları ve kaynak yükleme süreçleriyle doğrudan şekilleniyor. Bu rehberde, sunucu yanıt süresinin crawl budgetı nasıl düşürdüğünü/dengelediğini somut metriklerle anlatıyor; log (sunucu erişim kayıtları) ve Google Search Console verilerini birlikte kullanarak net bir teşhis çerçevesi veriyoruz.

Aşağıdaki başlıklar üzerinden ilerleyin: Önce “hangi gecikme crawl budgetı bozar?” sorusunun teknik cevabını kuracağız. Sonra ölçüm planı çıkaracağız. En sonunda ise yanıt süresini iyileştirmek için uygulanabilir adımlar ve “ölçmeden düzeltme olmaz” yaklaşımıyla net bir aksiyon listesi bırakacağız.

Crawl budget tam olarak neyi ifade eder?

Crawl budget, arama motorlarının bir siteyi taramak için ayırdığı kapasiteyi ifade eder. Bu kapasite iki bileşenden etkilenir:

• Tarama kapasitesi: Arama motorunun genel tarama altyapısı (siteye göre ayarlanır).
• Tarama verimliliği: Arama motorunun tarama denemeleri sırasında elde ettiği sonuçlar.

Tarama verimliliği şu sinyallerle düşer: - Sunucunun yanıt vermekte geç kalması (TTFB, bağlantı kurma gecikmesi, ilk bayt gecikmesi) - Zaman aşımı (timeout) - 5xx hataları - Çok yavaş yüklenen sayfalarda tarayıcının sayfayı tamamlamadan vazgeçmesi - Redirect zincirleri nedeniyle tek sayfa için birden fazla istek yapılması

Burada kritik nokta şudur: Tarayıcı “sizi daha çok tarayacak” diye bir garanti yoktur. Tarayıcı, her tarama denemesinde daha fazla kaynak harcayıp daha az sonuç döndürdüğünde, sitenize ayırdığı tarama kapasitesini zaman içinde azaltır.

Sunucu yanıt süresi crawl budgetı nasıl etkiler?

Sunucu yanıt süresi tek bir sayı gibi görünse de tarayıcı deneyiminde birden fazla aşamaya yayılır: - DNS + TCP + TLS kurulumu (özellikle HTTP/2, TLS ayarları ve sertifika/cihaz geçmişine göre) - İlk yanıt (server first byte) - Uygulamanın sayfayı üretmesi (PHP/WordPress sorguları, template render) - Statik dosya yükleme (CSS/JS/image)

Sunucu “ilk istek”te yavaşsa tarayıcı daha az sayfayı aynı zaman penceresinde tamamlar. Sonuç, daha düşük tarama verimliliği ve zaman içinde azalan crawl aktivitesidir. Bu davranış, özellikle şu senaryolarda belirginleşir: - CPU %100’e yaklaştığında (PHP worker/Node/Java süreçleri tıkanır) - Veritabanı sorguları uzadığında - Cache katmanı düzgün çalışmadığında - Çok büyük response body (ör. devasa sayfa HTML’si) nedeniyle tarayıcı tamamlayamaz

Crawl budget ile yanıt süresini birlikte ölçme: net metodoloji

Sadece “Site hızlı değil” demek, eyleme dönüşmeyen bir tespittir. Aşağıdaki metrikleri birlikte takip edin.

1) Google Search Console’da crawl verimliliği sinyalleri

Search Console (Önceki adıyla) şu raporlar üzerinden tarama trendini görmenizi sağlar: - İçerikler - sayfalar (dizinlenme/indekslenme durumları) - Tarama istatistikleri (hangi günlerde kaç istek, indirimler) - Tarama hataları (5xx/4xx ile ilgili göstergeler)

Hedef: Yanıt süresi artışının ardından tarama etkinliğinin azalıp azalmadığını zaman ekseninde görün. Bu ilişki her zaman birebir aynı gün olmaz; arama motoru davranışı dalgalıdır. Bu yüzden en az 2-4 haftalık pencerede bakın.

2) Sunucu loglarından (access log) tarayıcı isteklerini ayırın

Rehberin ana noktası: “Arama motoru tarıyor mu, hangi sayfada takılıyor?”

Erişim loglarınızdan aşağıdaki ayrımları yapın: - User-Agent: Googlebot, Bingbot gibi - HTTP status kodları: 200, 3xx, 4xx, 5xx - Response süresi (varsa request_time, upstream_response_time) - Response size

Örnek kontrol soruları: - Googlebot 200 dönen sayfalarda ortalama yanıt süresi kaç ms? - 5xx aldığınız sayfalarda tarayıcının oranı ne kadar? - Redirect zinciri olan URL’lerde bot başına istek sayısı artıyor mu?

3) Dağıtım ve uygulama katmanı için ayrı ölçün

Sunucu yanıt süresi tek yerde çözülmez. En azından şu katmanları ayırın: - Reverse proxy / web sunucusu (Nginx/Apache/LiteSpeed) upstream bekleme - Uygulama katmanı (PHP-FPM/Node) işleme süresi - Veritabanı sorgu süresi (örn. yavaş sorgular)

Bu ayrımı yapmadan, “hosting yavaş” teşhisi çoğu zaman yanlış yere gider.

Hangi yanıt süresi eşikleri crawl verimini bozar?

Net bir eşik vermek çoğu zaman zor; çünkü dosya boyutu, sayfa türü ve botun davranışı değişir. Yine de pratikte şu aralıklar karar vermeyi kolaylaştırır:

• TTFB / ilk yanıt gecikmesi 200-300 ms aralığının üzerine düzenli çıktığında: tarayıcı sayfa tamamlamadan önce daha fazla bekler.
• İlk yanıt 1-2 saniye bandına oturduğunda: özellikle yoğun günlerde tarama verimliliği belirgin düşer.
• 5xx hataları veya timeout oranı arttığında: crawl budgetın gerçekten azaldığını gözlemlersiniz.
• Tam sayfa üretimi (uygulama tarafı) 2-3 saniyenin üstüne sürekli çıkıyorsa: botun “tamamlanmış tarama” oranı düşer.

Bunu “tek bir test”le değil, zaman serisiyle doğrulayın. Örneğin 7 gün/14 gün boyunca aynı saat aralığında bot benzeri istekleri kıyaslayın.

Bot-benzeri test için doğru yaklaşım

• Statik dosya önbellek etkisini farklılaştırın (cache clear sonrası ölçmeyin)
• Aynı URL grubunu (en çok bot alan/indekslenen sayfalar) seçin
• Sadece homepage değil, iç sayfalarla ölçün
• Ölçümü lokasyondan bağımsız yapın: gecikmeyi ölçmek için CDN varsa CDN’in de dahil olduğunu bilin

İyileştirme planı: Yanıt süresi düşürmeden crawl bütçeyi “artırmaya” çalışmayın

Crawl budgetı doğrudan artıran bir düğme yoktur. Ama yanıt süresi ve hata oranlarını düşürerek, tarayıcının sitenizde “tamamlama oranını” artırırsınız. Sonuç genellikle daha stabil tarama ve daha iyi dizinlenme olur.

Aşağıdaki öncelik sırası pratikte en hızlı geri dönüşü verir.

1) 5xx ve timeoutları önce sıfıra yakınlayın

• Uygulama loglarını kontrol edin (PHP hata logları, upstream timeout)
• Nginx/Apache timeout ayarlarını körlemesine uzatmayın; kök nedeni giderin
• Veritabanı bağlantı hataları ve slow query yoklamalarını açın

Ölçüm hedefi: Bot isteklerinde 5xx oranı belirgin düşmeli. Örn. bot trafiği yüksek URL’lerde 200/304 oranı artmalı.

2) Redirect zincirlerini kesin

Redirect chain, tarayıcı için tek sayfada birden fazla istek demektir. Bu da yanıt süresi ve toplam tarama maliyetini yükseltir.

Kontrol listesi: - HTTP->HTTPS->www->non-www gibi çoklu geçişleri düzeltin - canonical ve gerçek yönlendirme ile çelişen URL’leri sadeleştirin - “Eski URL -> yeni URL” map’lerini güncel tutun

3) Cache katmanını tarayıcının ulaşabileceği şekilde yapılandırın

Özellikle WordPress tabanlı sitelerde şu durum crawl bütçeyi etkiler: - Dinamik üretilen sayfalar her bot isteğinde komple render edilir - Object cache/page cache etkin değildir

Yapılacaklar: - Sayfa önbelleği (page cache) düzgün çalışmalı - Tarayıcıdan gelen varyantlara (cache vary) dikkat edin (ör. query string) - İndeksleme gerektiren sayfalarda cache prevent header’ları olmadığını doğrulayın

4) Veritabanı gecikmesini tespit edip daraltın

Yavaş sorgular crawl verimini düşürür çünkü uygulama “ilk yanıtı” geç üretir.

H3: Veritabanında net teşhis nasıl yapılır?

• Slow query log’u açın
• En sık çalışan ama en yavaş sorguları belirleyin
• Index eksikleri ve gereksiz JOIN/ORDER BY maliyetlerini azaltın

Hedef: Uygulama işleme süresi düşmeli; loglarda upstream response time azalmaya başlamalı.

5) Sunucu kaynaklarını doğru ölçekleyin (CPU/IO tıkanması)

Crawl sırasında bot sayfa üretimini tetikler. Cache yoksa her bot isteği CPU ve disk/IO kullanımı demektir.

Kontrol: - CPU %100’e yaklaşan saatlerde tarama verimi düşüyor mu? - Disk IO wait artışı var mı? - PHP-FPM/worker sayısı (ve kuyruk) büyüyor mu?

Örnek iyileştirmeler: - Worker sayısını ve limitleri uygulama ihtiyacına göre ayarlayın - Storage performansını doğrulayın (özellikle düşük IOPS disk kullanan planlarda) - Yüksek eşzamanlı isteklerde process limitlerini düzeltin

Hosting türü değiştirirken dikkat: Yanıt süresi farkı sadece “ram” değildir

Sık yapılan hata: “Daha çok RAM alalım, hız gelir.” Crawl bütçede belirleyici olan şey çoğu zaman RAM’den çok cache davranışı, CPU tıkanması, disk/DB gecikmesi ve web sunucusu-upstream zamanlamasıdır.

Yine de plan türleri performansı etkiler. Kısa bir kıyas:

Not: Aynı CPU/RAM değerlerinde bile sağlayıcının disk türü ve ağ gecikmesi, bot deneyimini doğrudan değiştirebilir. Bu nedenle plan değiştirirken “tek seferlik hız testi” yerine 7-14 günlük ölçüm yapın.

Uygulanabilir kontrol listesi (hemen yarın başlayabileceğiniz türden)

Aşağıdaki listeyi, crawl bütçe düşüşü yaşadığınız haftada uygulayın.

H3: Hız ve tarama verimi kontrol listesi

• [ ] Search Console’da tarama istatistiklerini son 30-60 gün boyunca karşılaştır
• [ ] Googlebot/Bingbot isteklerinde 5xx ve timeout oranını loglardan çıkar
• [ ] En çok taranan 20 URL’de ortalama yanıt süresini hesapla
• [ ] Redirect chain olan URL’leri tespit et ve sadeleştir
• [ ] Cache header’larının doğru geldiğini doğrula (page cache açık mı?)
• [ ] Slow query raporunda ilk 10 sorguyu hedefle (index/plan optimizasyonu)
• [ ] CPU %100 olan saatlerde worker queue büyüyor mu bak
• [ ] Uygulama ve DB için ayrı metrik toplama başlat (en azından request time + slow query)

Sonuç: Crawl bütçeyi “tarama talebiyle” değil, yanıt süresiyle stabilize edin

Crawl budget, sitenizin tarayıcıya sağladığı “tamamlanmış içerik” deneyimiyle şekillenir. Sunucu yanıt süresi düzenli olarak uzadığında veya 5xx/timeout arttığında, tarama verimliliği düşer ve crawl aktivitesi zaman içinde azalır. Bu yüzden aksiyon sırası net olmalı: önce loglardan bot davranışını ve 5xx/timeout kaynaklarını bulun, sonra redirect ve cache hatalarını düzeltin, ardından DB ve CPU tıkanmalarını giderin. Bu yaklaşımı uygulayıp ölçümleri 2-4 haftalık pencereye yaydığınızda, hem tarama istatistikleri hem de dizinlenme davranışı daha öngörülebilir hale gelir.