Tarama Bütçesi (Crawl Budget) ve Site Hızı

Tarama bütçesi (crawl budget), arama motorunun belirli bir sürede sitenden çekmeye razı olduğu sayfa sayısıdır. Küçük bir tanıtım sitesi için bu kavram gerçekten önemsizdir; birkaç yüz sayfan varsa Google zaten hepsini rahatça tarar. Ama sitenin sayfa sayısı on binleri bulduğunda ya da filtreli adreslerle milyonlarca kombinasyon üretiyorsa, tarama bütçesi doğrudan şu soruya dönüşür: yeni yayımladığın ürün sayfası indekse ne zaman girecek, iki gün sonra mı iki ay sonra mı?

İşin performansla kesişen tarafı çoğu SEO içeriğinde yüzeysel geçilir: tarama bütçesinin en belirleyici girdisi sunucunun yanıt süresidir. Google, sitenin sağlığını bozmamak için tarama hızını senin sunucunun tepkisine göre kendisi ayarlar. Yani yavaş bir sunucu yalnızca kullanıcıyı kaçırmaz, aynı zamanda içeriğinin keşfedilme hızını da düşürür. Bu yazıda o mekanizmayı, bütçeyi boşa harcayan kalıpları ve günlük analiziyle gerçek tarama davranışını görmeyi anlatacağım.

Tarama Bütçesi Neyden Oluşur#

Tarama bütçesini tek bir sayı gibi düşünmek yanıltıcıdır; iki bağımsız bileşenin kesişimidir.

Tarama hızı sınırı (crawl rate limit), arama motorunun sunucuna zarar vermemek için kendine koyduğu tavandır. Bu tavan doğrudan senin sunucunun davranışına göre ayarlanır: hızlı ve hatasız cevap veriyorsan yükselir, yavaşlıyor ya da hata dönüyorsan düşer.

Tarama talebi (crawl demand), arama motorunun sitenden ne kadar sayfa istediğidir. Bunu içeriğin popülerliği, güncellenme sıklığı ve genel site otoritesi belirler. Kimsenin aramadığı, hiç güncellenmeyen bir arşiv sayfası için talep düşüktür.

Üçüncü satır kritiktir ve genelde atlanır. Bütçeni artırmanın iki yolu vardır: pastayı büyütmek (sunucuyu hızlandırmak) ya da pastayı daha az dilime bölmek (gereksiz adresleri taranabilir olmaktan çıkarmak). İkincisi hemen her zaman daha hızlı sonuç verir çünkü tamamen senin kontrolündedir.

Sunucu Hızı Tarama Hacmini Nasıl Belirler#

Mekanizma şöyle çalışır: arama motoru tarayıcısı sitene istek gönderirken yanıt sürelerini ve hata oranlarını sürekli izler. Yanıtlar hızlı ve 200 dönüyorsa eşzamanlı bağlantı sayısını ve istek hızını kademeli olarak artırır. Yanıt süresi uzamaya başlarsa ya da 5xx hataları görürse geri çekilir; bunu bir nezaket kuralı olarak değil, sitenin sağlığını koruma refleksi olarak yapar.

Bu geri çekilme asimetriktir ve bilinmesi gereken kısım da budur: sunucu yavaşladığında tarama hızı hızla düşer, sunucu düzeldiğinde ise eski seviyeye çıkması günler sürer. Yani bir hafta süren bir performans sorunu, düzeldikten sonra bile tarama hacminde bir süre iz bırakır.

Pratik karşılığı şu tabloda:

Buradan çıkan tek cümlelik kural şudur: tarama bütçesini iyileştirmenin en etkili yolu, sunucu yanıt süresini düşürmek ve hata oranını sıfıra yaklaştırmaktır. Bu iki metriği ölçmüyorsan tarama sorunlarını da açıklayamazsın; ölçüm düzenini kurmak için sunucu yanıt süresi izleme yazısındaki günlük ve prob kurulumunu uygula.

Dikkat edilecek bir nokta daha var: tarayıcı için önemli olan onun gördüğü yanıt süresidir. Sen ana sayfayı ölçüp 200 ms görüyor olabilirsin ama tarayıcı asıl derin, önbelleğe girmeyen sayfaları geziyordur ve orada süre 3 saniyedir. Bu yüzden ölçümü mutlaka tarayıcının gerçekten gezdiği adres kümesi üzerinden yap.

Bütçeyi Boşa Harcayan Kalıplar#

Çoğu sitede sorun bütçenin küçüklüğü değil, israfıdır. Aşağıdaki kalıplar tarayıcının zamanını hiçbir arama değeri olmayan adreslerde harcatır.

1. Faceted navigation (filtreli gezinme). Renk, beden, marka, fiyat aralığı ve sıralama parametrelerinin kombinasyonu üstel biçimde adres üretir. Beş filtrenin her biri beş değer alıyorsa teorik adres sayısı binlerle ifade edilir ve bunların neredeyse hiçbiri aranmaz.
2. Sıralama ve görünüm parametreleri. ?siralama=fiyat, ?gorunum=liste, ?sayfa_basina=48 gibi parametreler aynı içeriği farklı adreslerde sunar; tarayıcı için bunlar ayrı sayfalardır.
3. Oturum kimliği ve izleme parametreleri. Adrese eklenen kampanya ve oturum parametreleri, aynı sayfanın sonsuz kopyasını üretir.
4. Sonsuz takvim ve arşiv sayfaları. Bir sonraki aya sonsuza kadar gidebilen takvim bileşenleri, tarayıcıyı bitmeyen bir tünele sokar.
5. Site içi arama sonuç sayfaları. Her sorgu yeni bir adres üretir ve bunlar hem değersiz hem de sunucu için pahalıdır.
6. Yönlendirme zincirleri. Üç adımlı bir yönlendirme, tek sayfa için üç istek harcatır.
7. Yumuşak 404'ler. İçeriği olmayan bir sayfanın 200 dönmesi, tarayıcının o adresi geçerli sanıp tekrar tekrar ziyaret etmesine yol açar.

Bu kalıpların hepsinin ortak özelliği, aynı zamanda sunucu yükünü de artırmalarıdır; çünkü ürettikleri adresler önbelleğe girmez ve her biri tam bir uygulama çalıştırması gerektirir. Yani bunları düzeltmek hem SEO hem performans tarafında kazandırır. Bot yükünün nasıl ölçüleceğini ve bu adreslerin günlükte nasıl görüneceğini bot trafiği sunucu yükünü nasıl artırır yazısında ele aldım.

Günlük Analiziyle Gerçek Tarama Davranışını Görmek#

Arama konsolundaki tarama istatistikleri özet verir; ayrıntı web sunucusu günlüğündedir. Tarayıcının gerçekte nereye gittiğini görmek, bütçe israfını bulmanın en doğrudan yoludur.

LOG=/var/log/nginx/firmaniz-access.log

# 1) Googlebot'un en çok gezdiği yollar (parametresiz)
awk '/Googlebot/ {print $7}' "$LOG" | sed 's/?.*//' | sort | uniq -c | sort -rn | head -25

# 2) Parametreli adreslerin tarama içindeki payı - israfın ana göstergesi
awk '/Googlebot/ {print $7}' "$LOG" | awk '
  { if ($0 ~ /\?/) p++; else t++ }
  END { printf "parametreli=%d parametresiz=%d israf_orani=%%%.1f\n", p, t, 100*p/(p+t) }'

# 3) Googlebot'a dönen durum kodu dağılımı - 5xx ve 404 payı
awk '/Googlebot/ {print $9}' "$LOG" | sort | uniq -c | sort -rn

# 4) Googlebot'un gördüğü yanıt süreleri (rt= alanı günlükte varsa)
awk '/Googlebot/ {
  for (i=1; i<=NF; i++) if ($i ~ /^rt=/) { sub("rt=","",$i); s+=$i; n++ }
} END { if (n) printf "googlebot ortalama yanit=%.3f sn  istek=%d\n", s/n, n }' "$LOG"

İkinci komut çoğu e-ticaret sitesinde yüzde 60'ın üzerinde bir israf oranı gösterir; yani tarama bütçesinin üçte ikisi filtreli adreslerde harcanıyordur. Üçüncü komutta 5xx sayısı sıfırdan belirgin biçimde büyükse, tarama hızının neden düştüğünün cevabı oradadır. Dördüncü komut ise en değerli olanıdır: tarayıcının gördüğü ortalama süre, senin ana sayfada ölçtüğün süreden genellikle çok daha yüksektir.

Bu analizi düzenli çalıştır ve sonucu bir dosyaya yaz. Tarama davranışındaki değişimi haftalar sonra fark etmek yerine, deploy sonrası ertesi gün görürsün.

Bütçeyi Verimli Kullanmak İçin Yapılacaklar#

Sıralamayı etki büyüklüğüne göre yaptım; yukarıdan aşağı uygula.

1. Yanıt süresini düşür ve 5xx'i sıfırla. Sıralamada birincidir çünkü tavanı belirler. Önbellek katmanını doğru kur; tarayıcının gezdiği derin sayfalar da önbellekten dönsün. Uygulama düzeyinde bir sayfa önbelleği yoksa nginx FastCGI cache yapılandırması ya da LiteSpeed Cache ile başla.

2. Gereksiz adresleri taranabilir olmaktan çıkar. Filtre ve sıralama parametrelerini robots.txt ile kapat, kanonik etiketleri doğru kur ve iç bağlantılarda parametreli adreslere link verme. Tarayıcı bir adrese ancak bir yerden bağlantı bulursa gider.

User-agent: *
Disallow: /*?siralama=
Disallow: /*?gorunum=
Disallow: /*?sayfa_basina=
Disallow: /*&filtre=
Disallow: /arama
Allow: /*?sayfa=

Sitemap: https://firmaniz.com/sitemap.xml

3. Site haritasını temiz ve güncel tut. Site haritası tarayıcıya öncelik listesi verir. İçinde yalnızca indekslenmesini istediğin, 200 dönen, kanonik adresler olsun. Yönlendirilen, 404 dönen ya da noindex işaretli adresleri site haritasında bırakmak, tarayıcının güvenini ve bütçeni birlikte harcar.

4. Koşullu istekleri destekle. Sunucun Last-Modified ve ETag başlıklarını doğru üretiyorsa, değişmemiş sayfalar için tarayıcı 304 Not Modified alır ve gövdeyi hiç indirmez. Bu, hem senin bant genişliğini hem tarayıcının bütçesini korur.

# 304 desteğini test et: önce ETag'i al, sonra koşullu istek gönder
ETAG=$(curl -sI https://firmaniz.com/urun/ornek | awk '/[Ee][Tt]ag:/ {print $2}' | tr -d '\r')
curl -sI -H "If-None-Match: $ETAG" https://firmaniz.com/urun/ornek | head -1
# Beklenen çıktı: HTTP/2 304

5. Yönlendirme zincirlerini kısalt. Her ara adım bir istek maliyetidir. İç bağlantılarını doğrudan nihai adrese güncelle; yönlendirme kuralları yalnızca dışarıdan gelen eski bağlantılar için kalsın.

6. Sayfa ağırlığını düşür. Tarayıcı da sayfayı indirir ve büyük sayfalar hem daha uzun sürer hem daha fazla kaynak tüketir. Makul hedefler için ideal sayfa ağırlığı yazısındaki bütçe tablosuna bak.

Sık Yapılan Hatalar#

Küçük sitede tarama bütçesiyle uğraşmak. Birkaç yüz sayfalık bir sitede tarama bütçesi bir sorun değildir ve buraya harcadığın zaman içerik üretmeye harcansa daha çok kazandırır. Bu konu on binlerce adres üreten siteler içindir.

Gereksiz adresleri noindex ile çözdüğünü sanmak. noindex etiketi indekslemeyi engeller ama taramayı engellemez; tarayıcı o sayfayı yine de indirmek zorundadır, çünkü etiketi görmesi için sayfayı çekmesi gerekir. Bütçe zaten harcanmıştır. Taramayı kesmek istiyorsan robots.txt kullanmalısın.

robots.txt ile engelleyip kanonik beklemek. İkisi birlikte kullanılmaz. robots.txt ile kapatılan bir sayfayı tarayıcı çekemez, dolayısıyla içindeki kanonik etiketi de göremez. Kanonik kullanacaksan sayfa taranabilir kalmalıdır; bütçeyi korumak öncelikliyse robots.txt kullan ve kanonikten vazgeç.

Tarama düşüşünü otomatik olarak ceza sanmak. Taranan sayfa sayısındaki düşüş çoğu zaman bir yaptırım değil, sunucunun yavaşladığının ya da hata döndüğünün göstergesidir. Panik yapmadan önce yanıt süresi ve 5xx oranı grafiğine bak.

Site haritasını bir kez üretip unutmak. Eskimiş bir site haritası, tarayıcıyı silinmiş ve yönlendirilmiş adreslere yollar. Üretimi otomatikleştir ve içeriğindeki adreslerin durum kodlarını ara ara doğrula.

Sıkça Sorulan Sorular#

Tarama bütçesi küçük siteler için önemli mi#

Hayır. Birkaç yüz, hatta birkaç bin sayfalık siteler için arama motoru zaten tüm içeriği rahatça tarar ve bu konuya ayıracağın zaman başka yerde daha çok kazandırır. Tarama bütçesi, on binlerce adres üreten e-ticaret siteleri, büyük haber arşivleri ve filtreli listeleme sayfaları olan platformlar için gerçek bir kısıt hâline gelir.

Sunucumu hızlandırırsam tarama hemen artar mı#

Anında değil, kademeli olarak artar. Arama motoru tarama hızını yavaş yavaş yükseltir ve sunucunun yeni seviyede istikrarlı davrandığını görmek ister; bu süreç genellikle günler alır. Bu asimetri önemlidir: yavaşlamada hızlı düşer, düzelmede yavaş çıkar. Bu yüzden performans sorunlarını uzun süre taşımanın maliyeti yalnızca o günlerle sınırlı kalmaz.

Tarama bütçemi nasıl kontrol ederim#

İki kaynağı birlikte kullan. Arama konsolundaki tarama istatistikleri raporu günlük tarama isteği sayısını, indirilen veri miktarını ve ortalama yanıt süresini gösterir; genel gidişat için idealdir. Ayrıntı içinse web sunucusu erişim günlüğünü kullan: tarayıcının hangi yolları gezdiğini, kaç tanesinin parametreli olduğunu ve hangi durum kodlarını aldığını yalnızca orada görebilirsin.

robots.txt ile engellenen sayfa yine de indekse girer mi#

Girebilir. robots.txt taramayı engeller, indekslemeyi doğrudan engellemez; başka sitelerden çok sayıda bağlantı alan bir adres, içeriği hiç çekilmeden yalnızca bağlantı metniyle indekse girebilir. Bir sayfanın kesinlikle indekste olmamasını istiyorsan sayfayı taranabilir bırakıp noindex kullanmalısın. Amacın bütçe tasarrufuysa robots.txt, amacın indeks temizliğiyse noindex doğru araçtır.

304 Not Modified döndürmek gerçekten fark yaratır mı#

Büyük ve sık taranan sitelerde belirgin fark yaratır. Değişmemiş bir sayfaya 304 dönmek, sunucunun gövdeyi hiç üretmemesi ve göndermemesi demektir; hem işlem gücü hem bant genişliği tasarrufudur. Tarayıcı tarafında da aynı bütçeyle daha fazla adres kontrol edilebilir. Statik varlıklarda bu davranış genellikle hazır gelir, dinamik sayfalarda ise uygulama katmanında bilinçli olarak eklemen gerekir.

Tarama sıklığını doğrudan ayarlayabilir miyim#

Google tarafında robots.txt üzerinden bir hız direktifi tanımlayamazsın; Crawl-delay desteklenmez. Google tarama hızını sunucunun tepkisine bakarak kendisi belirler, yani hız ayarını dolaylı olarak performansınla yaparsın. Bing ve bazı diğer tarayıcılar Crawl-delay direktifini dikkate alır. Sunucun aşırı yükleniyorsa geçici olarak 429 dönmek de tarayıcılara yavaşlama sinyali verir.

Kapanış#

Tarama bütçesi, SEO ile altyapının en net kesiştiği yerdir: içeriğin ne kadar hızlı keşfedildiği, sunucunun ne kadar hızlı cevap verdiğine bağlıdır. Aklında kalması gereken dört alışkanlık şu: yanıt süresini ve 5xx oranını sürekli izle çünkü tarama tavanını onlar belirler, filtreli ve parametreli adresleri taranabilir olmaktan çıkararak bütçeyi israftan kurtar, site haritasını yalnızca kanonik ve 200 dönen adreslerle temiz tut ve tarayıcının gerçekte nereye gittiğini arama konsolu özetiyle yetinmeden günlükten doğrula.

Tarama hacmin sunucu kapasitesine takılıyorsa çözüm içerik tarafında değil altyapıdadır: daha yüksek ve öngörülebilir kaynak için VDS ve bulut sunucu paketlerimizi, yoğun katalog barındıran projeler için e-ticaret hosting çözümümüzü inceleyebilirsin. Önbellek katmanı, günlük analizi ve robots yapılandırmasını birlikte ele alan bir düzen kurmak istersen sunucu yönetimi ve SEO hizmetlerimiz bu işi üstlenir.