Crawl budget ile sunucu yanıt süresi ilişkisi: NetKıyas rehberi

Crawl budget (tarama bütçesi), arama motorlarının bir siteyi ne kadar ve ne kadar sıklıkta tarayacağını belirleyen pratik bir sınırdır. Bu sınır; içerik kalitesi ve yapılandırma kadar sunucu yanıt süresi, 5xx oranı ve kaynak tüketimiyle de doğrudan etkilenir. Bu rehberde; crawl bütçenin neden daraldığını anlamak için hangi metrikleri izleyeceğinizi, sunucu tarafında hangi sorunların taramayı kestiğini ve nasıl adım adım iyileştireceğinizi öğreneceksiniz.

Crawl budget tam olarak neyi ölçer?

Crawl budget tek bir sayıdan ibaret değildir. Arama motorları bir siteyi tararken hem “ne kadar sayfa” hem de “ne kadar hızla” gibi kısıtları birlikte değerlendirir. Uygulamada şunlar belirleyicidir:

Sayfaların yanıt süreleri (özellikle ilk yanıt ve yoğun anlarda gecikme)
Sunucunun kararlılığı (5xx/timeout oranı)
Trafiğin tarama trafiğine verdiği tepki (rate limit, WAF/anti-bot, queue birikmesi)
İçeriklerin linklenme durumu ve taranabilirlik (robots, canonical, yönlendirmeler)

Önemli nokta: Sunucu yavaşladığında veya zaman aşımına girdikçe, tarayıcılar “beklemek” yerine daha az sayfaya yönelir. Bu da crawl bütçenin pratikte azalması demektir.

Crawl budget düşüşünün en sık sunucu kaynaklı belirtileri

Aşağıdaki belirtiler, crawl budget kısılmasının sunucu performansından kaynaklandığını güçlü biçimde düşündürür:

Google Search Console’da tarama istatistiklerinde toplam istek/indirme sayısında düşüş
Aynı dönemde sunucu loglarında timeout (ör. read timeout, upstream timed out) veya 504/502 artışı
TTFB (Time To First Byte) belirgin şekilde yükselmesi
CPU/RAM/IO doygunluğu nedeniyle gecikmelerin zirve saatlerinde katlanması
Aynı URL’lerin tekrar tekrar denenip sonunda başarısız dönmesi (özellikle 429/403 dalgaları)

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

Tarayıcı bir sayfayı alırken “bekleme” maliyetini hesaba katar. Sunucu geciktikçe, tarayıcı daha az sayfayı daha kısa sürede tamamlar. Bu, crawl budget kullanımını aşağı çeker.

TTFB yükselince ne olur?

TTFB; uygulamanızın ilk veriyi ne kadar sürede döndürdüğünü temsil eder. Yüksek TTFB genellikle şu kök nedenleri işaret eder:

Uygulama katmanında yavaş sorgular (özellikle veritabanı)
Cache kaçırma (CDN/uygulama cache devre dışı)
Thread/connection havuzlarının yetersizliği (queue birikmesi)
DNS çözümleme gecikmeleri veya upstream döngüleri

Tarayıcılar aynı sayfayı tekrar denediğinde, gecikme bir “tarama maliyeti” olarak kabul edilir. Sonuç: belirli süreler içinde taranan URL sayısı düşer.

5xx ve timeout oranı artınca bütçe daralır

500/502/503/504 yanıtlar: Tarayıcının sayfayı tamamlamasını engeller.
Timeout: Tarayıcı belirli bir eşiğin üstünde bekleyince denemeyi keser.

Arama motorları, başarısızlık oranı yüksek sitelerde tarama hızını azaltır. Bu, crawl budget’ı azaltmanın doğrudan yoludur.

429/403 dalgaları taramayı kısar

WAF, rate limiting veya anti-bot kuralları tarayıcı IPlerini yanlış yorumladığında 429 (Too Many Requests) ya da 403 üretebilir. Burada kritik ayrım şudur:

“gerçek kullanıcı” ile “arama motoru botu” aynı davranışı göstermeyebilir
Yanlış eşleştirme crawl bütçeyi saniyeler içinde kırar

Bu yüzden crawl budget performansı için sadece sunucu hızını değil, güvenlik katmanının botlara verdiği cevabı da izlemek gerekir.

Crawl budget etkisini ölçmek için net veri seti

Sadece “site yavaş” demek yerine, sunucu yanıt süresi ile tarama davranışı arasında eşleşme kurmanız gerekir.

Kontrol panelinde değil, loglarda zaman çizelgesi kurun

Şu zaman pencerelerini aynı grafikte düşünün:

Son 7/30 gün: TTFB ve p95 gecikme
Son 7/30 gün: 4xx/5xx/timeout dağılımı
Son 7/30 gün: veri tabanı yavaş sorgu oranı
Search Console: tarama istekleri ve “tarama istatistikleri” eğrisi

Hedef: “TTFB yükseldiğinde tarama istekleri azalıyor” gibi bir eşleşme bulmak.

Önerilen metrikler (öncelik sırasıyla)

Aşağıdaki tabloyu kendi verilerinizle doldurun:

Metrik	Hangi gösterge	Neden crawl budget’ı etkiler?	Hedef/izleme notu
p95 TTFB	Zirve gecikmesi	Tarayıcıların bekleme maliyeti	p95’i düşürün; ortalama tek başına yeterli değildir
5xx oranı	Başarısız tarama denemeleri	Tarayıcı tamamlayamaz	503/504 özellikle kritik
Timeout sayısı	Denemelerin kesilmesi	Tarayıcı denemeyi bırakır	Uygulama + upstream zaman aşımı ayrı ölçün
429/403 oranı	Bot bloklama	Tarama azalır	WAF/Rate limit istisna planı yapın
Queue/worker saturation	Thread/connection tıkanması	TTFB katlanır	pencereli izleme: CPU/RAM + istek bekleme

Uygulama tarafında doğru ölçüm nerede başlar?

Sunucu yanıt süresi deyince sadece web server değil; şu katmanlar birlikte ele alınmalıdır:

Load balancer varsa: upstream gecikmesi
Reverse proxy (Nginx/HAProxy): proxy_read_timeout, upstream failover
Uygulama runtime (PHP-FPM, Node.js, JVM): worker sayısı, event loop tıkanması
Veritabanı: slow query, connection limit

Bu katmanlardan birinin bile gecikmesi TTFB’yi yükseltir ve crawl bütçeyi daraltır.

Crawl bütçeyi artırmak için sunucu tarafında yapılacaklar

Aşağıdaki aksiyonlar, crawl budget ile sunucu yanıt süresi ilişkisinin pratikte kırıldığı yerleri düzeltir.

1) TTFB’yi düşürün: Cache ve upstream zamanlaması

Hedef: Tarayıcı beklemeden yanıt alsın.

CDN cache oranını artırın (özellikle statik + içerik sayfaları için)
Uygulama cache (cache katmanı) kullanın; “her istekte aynı sorguyu” kırın
Veritabanında slow query eşiğini düşürün ve indeksleri düzeltin
Upstream gecikmesini izleyin: Nginx proxy_pass arkasında upstream response time

Kontrol listesi (kısa)

Cache header’ları doğrulayın (yanlış no-store crawl verimini düşürür)
Eşleşmeyen canonical/redirect zinciri var mı (TTFB artar)
Basit bir “health endpoint” (ör. GET /healthz) hızlı mı dönüyor?

2) 5xx/timeout’ı sıfıra yakın hedefleyin

Crawl bütçeyi kısan en hızlı tetikleyiciler 5xx ve timeout’tur.

Uygulama zaman aşımı (request timeout) ile reverse proxy zaman aşımını uyumlu yapın
504/502 artıyorsa upstream tarafında (app container, DB, harici API) kök nedeni bulun
Error bütçesi koyun: belirli URL gruplarında hata oranını izleyin

3) WAF ve rate limit bot davranışını botla ayırın

Rate limiting ve WAF kurallarında hedef “trafik kontrolü”dür; crawl budget düşürmek değildir.

Googlebot gibi botların doğrulanmış trafiğine uygun istisna/allow kuralı oluşturun
Aşırı kısa limit pencereleri (ör. saniyeler düzeyi) taramayı kırar
Challenge (JS/HTTP challenge) uyguluyorsanız, botların bununla takılıp takılmadığını test edin

Uygulama önerisi

Arama motoru trafiği için ayrı bir “policy” yaklaşımı kullanın. Aynı kuralı hem kullanıcı hem bot için kör şekilde uygulamak çoğu zaman crawl performansını bozar.

4) Kaynak tıkanmasını (queue) düzeltin

TTFB sadece uygulamanın kodu değildir; aynı zamanda kapasite planlamasıdır.

Web worker sayısı yetersizse istekler kuyrukta bekler
Veritabanı bağlantı havuzu dolarsa uygulama yeni bağlantı için bekler
Disk IO doygunluğu (log, swap, temp dosyaları) gecikmeyi artırır

Bu noktada sunucu türü (VDS/VPS/dedicated) tek başına çözmez; kapasite ayarları ve ölçüm belirleyicidir.

Crawl bütçeyi artırma için senaryo bazlı net yaklaşım

Aşağıdaki senaryolar, hangi adımın önce gelmesi gerektiğini belirler.

Senaryo A: p95 TTFB yüksek, 5xx düşük

Bu durumda tarayıcılar tamamlıyor ama yavaş tamamlıyor. Öncelik:

Cache kaçaklarını giderin
Veritabanı sorgularını optimize edin
Upstream/harici API çağrılarını kısaltın

Senaryo B: 5xx ve timeout yüksek

Öncelik hata kök nedenleri:

Reverse proxy timeout ayarlarını doğrulayın
Uygulama worker saturation kontrol edin
Veritabanı bağlantı limitleri ve slow query’i ele alın

Senaryo C: 429/403 yüksek, TTFB normal

Bu durumda hız sorun değil; erişim politikası sorun.

WAF/Rate limit kuralını bot doğrulamasıyla ayırın
Yanlış pozitif denetleyin
İlgili URL gruplarında (ör. site haritası ile gelen sayfalar) güvenli allow kuralı uygulayın

VDS/VPS/dedicated seçiminde crawl budget etkisi nasıl ele alınır?

Sunucu yanıt süresi ile crawl budget ilişkisi, altyapı seçimi sırasında da göz ardı edilmemelidir.

Ne zaman VDS veya VPS yeter, ne zaman dedicated gerekir?

Trafik dalgalanması ve kaynak tıkanması yaşıyorsanız: VDS/VPS üzerinde kapasiteyi artırmak kısa vadede çözüm olabilir.
Ancak uzun süreli stabilite ve yüksek eşzamanlılık istiyorsanız: dedicated üzerinde worker/DB kapasitesi daha kontrollü büyütülebilir.

Önemli ölçüt: “Sadece CPU/RAM yetiyor mu?” değil, “p95 TTFB ve timeout oranı düşüyor mu?”

Aynı uygulama, farklı sunucuda neden farklı crawl sonucu verir?

Aynı kod farklı IO performansı ile daha farklı TTFB üretebilir.
Network gecikmesi ve packet loss upstream zamanını etkiler.
Container/VM kaynak paylaşımlıysa yoğun saatlerde dalgalanma artar.

Bu nedenle crawl bütçeyi iyileştirme yaklaşımı, altyapıyı “göz kararı” değil, metrikle seçmelidir.

Son kontrol: İyileştirmeyi nasıl doğrularsınız?

Yapılan değişikliklerin crawl bütçeye etkisini doğrulamak için tek seferlik test değil, ölçümlü döngü kurun.

Değişiklikten sonra izlemeniz gereken 3 şey

p95 TTFB: düşüş başladı mı?
5xx/timeout: azaldı mı?
Search Console tarama istatistikleri: tarama hacmi kademeli artıyor mu?

Aksiyon sonrası beklenen zamanlama

Cache/konfig değişikliklerinde yanıt süreleri kısa sürede düşer.
Crawl davranışında ise tarayıcıların yeniden deneme paterni kademeli değişir.

Bu yüzden “24 saat” yerine en az 7 günlük pencerede trend görmek daha doğru sonuç verir.

Sonuç: Crawl budget için tek hedef “hız” değil, “istikrarlı yanıt”

Crawl budget düşüşünün en sık görülen tetikleyicisi sunucu gecikmesi ve başarısız yanıtlar (5xx/timeout) olduğundan, öncelik sırası bellidir: önce p95 TTFB’yi düşürün, sonra 5xx/timeout’u ortadan kaldırın, ardından WAF/rate limit bot trafiğini gereksiz yere engellemeyecek şekilde ayarlayın. İlk 1 haftada metriklerde net düşüş görmeden “SEO/robots tarafı” aramaya geçmeyin.

NetKıyas’ta karşılaştıracağınız barındırma türü ne olursa olsun, değişiklik yapmadan önce p95 TTFB ve hata oranlarını referans alın; değişiklikten sonra trendi doğrulayın. Bu yaklaşım, crawl budget ile sunucu yanıt süresi ilişkisini somut verilerle yönetmenizi sağlar.