Crawl Budget Optimizasyonu: Teknik SEO Öncelik Rehberi

Crawl budget optimizasyonu ne zaman gerçek sorun olur?

Google, crawl budget kavramını Googlebot’un bir site için tarayabildiği ve taramak istediği URL sayısı olarak açıklar; bu çerçeve crawl rate limit ile crawl demand birleşiminden oluşur (Google Search Central). Bu tanım önemli, çünkü birçok ekip her indeksleme gecikmesini otomatik olarak tarama bütçesi problemi sanıyor. Oysa pratikte çoğu orta ve küçük sitede asıl sorun içerik değeri, iç linkleme, yanlış canonical veya teknik kalite eksikleri oluyor.

Gerçek crawl budget problemi genelde üç durumda görünür: URL hacmi hızla büyümüştür, filtre ve parametre kombinasyonları neredeyse sonsuz alan üretir ya da sunucu yanıt kalitesi dalgalandığı için Googlebot temkinli davranır. Google’ın aynı kaynaktaki açıklamasına göre birkaç bin URL’nin altındaki sitelerde tarama çoğu zaman zaten verimli ilerler. Bu yüzden önce “bütçe mi, kalite mi?” ayrımını yapmak gerekir; aksi halde ekipler robots.txt düzenleyip asıl problemi yerinde bırakır.

Crawl rate limit sunucunun kaldırabildiği hızla ilgilidir; yanıtlar hızlıysa Googlebot daha rahat tarar, 5xx ve timeout artarsa yavaşlar. Crawl demand ise URL’nin popülerliği, tazeliği ve yeniden taranma ihtiyacıyla ilgilidir. Büyük e-ticaret, ilan, çok kategorili blog ve programatik sayfa yapılarında bu iki katman aynı anda baskı oluşturur. Tam da bu yüzden crawl budget optimizasyonu, tanım ezberinden çok öncelik yönetimi işidir.

Crawl budget optimizasyonu analizi: log, Crawl Stats ve URL örüntüleri

Doğru başlangıç noktası, server log verisini Search Console’daki Crawl Stats görünümüyle eşleştirmektir. Log tarafı size Googlebot hangi klasörleri, hangi parametreleri ve hangi durum kodlarını ne yoğunlukta taradığını söyler. Crawl Stats ise bu davranışın zamana yayılan özetini, yanıt boyutu ve yanıt süresi gibi sinyallerle birlikte verir. Tek başına Crawl Stats ekranı sorun sezdirir; ama hangi klasörün bütçeyi yediğini çoğu zaman ancak log satırları gösterir.

İlk bakmanız gereken yerler şunlardır:

• En çok hit alan klasörler ve URL desenleri
• 200 dışındaki durum kodlarının payı
• Parametreli URL, filtre URL ve oturum kimliği içeren istekler
• Googlebot Smartphone ile Desktop farkı varsa user-agent kırılımı
• Uzun redirect zincirleri ve tekrar taranan soft 404 kümeleri

Googlebot dokümanı, tarayıcının bugün mobil ve masaüstü tipleriyle çalıştığını ve robots.txt tarafında ayrı hedeflenemediğini açıkça belirtir (What Is Googlebot). Bu nedenle analiz sadece sayfa düzeyinde değil, host, klasör ve URL şablonu düzeyinde yapılmalıdır. Örneğin ürün sayfaları yavaş keşfediliyorsa ama bot hit’leri filtre URL’lerinde birikiyorsa sorun yeni içerik üretimi değil, boşa taranan alanlardır.

Karar verirken basit bir eşik mantığı iş görür: yeni önemli URL’ler geç keşfediliyor, Crawl Stats tarafında bot hareketi yüksek kalıyor ve loglarda düşük değerli örüntüler baskın görünüyorsa gerçek bir tarama verimsizliği vardır. Buna karşılık bot hareketi düşük, ama önemli sayfalar yeterince link almıyor ya da canonical sinyalleri karışıksa konu indeksleme/kalite tarafına kayar. Kısacası log ve Crawl Stats birlikte okunmadan yapılan crawl budget teşhisi eksik kalır.

Tarama bütçesini boşa harcayan URL kalıpları nasıl temizlenir?

Google’ın crawl budget açıklamasında düşük değerli URL’lerin başında faceted navigation, session identifier, site içi duplicate content, soft error sayfaları ve sonsuz URL alanları sayılır (What Crawl Budget Means for Googlebot). Google ayrıca 17 Aralık 2024 tarihli faceted navigation yazısında, filtre kombinasyonlarının sayısız URL üretip önemli içeriklerin keşfini yavaşlattığını ve bunun sahada en sık gördükleri overcrawl kaynağı olduğunu söylüyor (Crawling December: Faceted navigation).

Burada araçların rolünü karıştırmamak gerekir. robots.txt tarayıcı erişimini yönetir; indeks kaldırma aracı değildir. Google’ın robots.txt rehberi de bunu açık söyler ve noindex ya da erişim kısıtı gereken durumların ayrı ele alınması gerektiğini vurgular (Robots.txt Introduction and Guide). Buna karşılık canonical benzer URL kümelerinde sinyal birleştirir, noindex sonuçtan çıkmasını istediğiniz ama hâlâ taranabilen sayfalarda rol oynar, sitemap ise göstermek istediğiniz kanonik URL setini öne çıkarır.

Pratik karar matrisi genelde şöyle kurulur:

• İndekslenmesini istemediğiniz filtre URL’leri: robots.txt veya fragment tabanlı yaklaşım
• Benzer ürün liste varyasyonları: canonical ile tek ana versiyona toplama
• Session ID ve takip parametreleri: üretimi kaynakta kesme
• Redirect chain: nihai hedefe doğrudan yönlendirme
• Soft 404 ve eski boş kategori sayfaları: net 404/410 veya anlamlı içerik kararı

Yanlış inanışlardan biri de “robots.txt ile her şeyi çözerim” yaklaşımıdır. Google’ın 2017 açıklamasına göre disallow edilmiş URL’ler doğrudan crawl budget’tan düşmez; fakat bu, URL üretim problemini göz ardı edebileceğiniz anlamına gelmez. Eğer site içi linkler, facet mantığı ve yönlendirmeler aynı karmaşayı üretmeye devam ediyorsa bütçe yerine keşif kalitesini bozarsınız. Asıl kazanç, taramayı engellemekten çok gereksiz URL üretimini azaltmaktan gelir.

Site hızı, CDN ve JavaScript crawl budget optimizasyonu nasıl etkiler?

Site hızı crawl budget için dolaylı değil, doğrudan bir verimlilik sinyalidir. Google, hızlı ve sağlıklı sunucuların crawl rate’i artırabildiğini; 5xx hataları ve connection timeout’ların ise taramayı yavaşlattığını açıkça belirtir (Google Search Central). Bu yüzden TTFB yükseliyorsa, sunucu yanıt boyutu şişiyorsa veya bot çok sayıda başarısız istek dönüyorsa önce altyapı tarafını temizlemek gerekir.

2024 sonundaki Google yazıları bu resmi daha netleştirdi. 9 Aralık 2024 tarihli HTTP caching içeriğinde Google, özellikle büyük ve nadir değişen sayfalarda ETag ve Last-Modified ile yerel cache kullanımının tarama verimini artırabileceğini anlattı (Crawling December: HTTP caching). 24 Aralık 2024 tarihli CDN yazısı ise CDN arkasındaki host’larda ilk tarama dalgasının yine origin’i yükleyebileceğini, aşırı korumacı WAF kurallarınınsa tarayıcıyı yanlışlıkla engelleyebileceğini vurguladı (Crawling December: CDNs and crawling).

JavaScript tarafında 2026 güncellemesi daha kritik. Google’ın 31 Mart 2026 tarihli Inside Googlebot yazısı, HTML dosyasında ilk 2 MB’tan sonrasının alınmadığını; WRS’nin JavaScript, CSS ve XHR kaynaklarını ayrıca işlediğini; gereksiz büyük inline kodların kritik içeriği aşağı itebileceğini net biçimde anlattı (Inside Googlebot, 2026). Yani crawl budget optimizasyonu artık sadece URL sayısı değil, işlenen byte miktarı ve render yükü meselesi. Ağır SPA yapıları, gereksiz cache-busting parametreleri ve sürekli değişen asset URL’leri bu yüzden ayrıca denetlenmeli. Teknik ekibin ortak dili için Google Search Central’ın crawling odaklı resmi videoları da faydalı bir eğitim kaynağı olur.

Acil bir altyapı krizinde Google, kısa süreli olarak 500, 503 veya 429 yanıtlarıyla crawl back-off tetiklenebileceğini; ancak bunun kalıcı çözüm olmadığını ve uzun sürerse görünürlüğe zarar verebileceğini belirtir (Reduce Google Crawl Rate). Bu nedenle hedef, botu sürekli frenlemek değil; onun güvenle ve hızlı tarayabileceği bir yapı kurmaktır.

50 bin+ URL’li e-ticaret sitesinde crawl budget optimizasyonu vaka analizi

Anonimleştirilmiş bir 50 bin+ URL’li e-ticaret saha örneğinde 30 günlük server log verisini Search Console Crawl Stats ile eşleştirdiğimizde, ilk tablo klasik bir overcrawl vakasına benziyordu: kategori ve ürün detay sayfaları yerine filtre kombinasyonları, sıralama parametreleri ve eski yönlendirme kalıpları bot isteklerinin büyük bölümünü çekiyordu. Yeni ürünler yayına alınsa da keşif hızı tutarsızdı; ekip sorunu içerik üretim temposunda arıyordu, ama asıl yük URL mimarisindeydi.

Müdahale üç parçalı yapıldı. İlk olarak indeks değeri taşımayan filtre URL’leri için net URL politikası tanımlandı; bazı kombinasyonlar robots.txt ile sınırlandı, bazıları üretim katmanında kapatıldı, benzer liste varyasyonları canonical ile toplandı. İkinci olarak redirect chain’ler kısaltıldı ve soft 404 davranışı gösteren boş sonuç sayfaları temizlendi. Üçüncü olarak sitemap sadece kanonik kategori, ürün ve önemli landing page setiyle yeniden düzenlendi; Google’ın sitemap rehberindeki gibi tercih edilen kanonik URL’ler dosyada bırakıldı (Build and Submit a Sitemap).

Sonuç tarafında bakılan KPI’lar şunlardı: Crawl Stats yoğunluğu, önemli klasörlerde Googlebot hit dağılımı, keşif süresi, index coverage tutarlılığı, organik landing page kazanımı ve sunucu yanıt süresi. En değerli içgörü şu oldu: crawl budget optimizasyonu çoğu zaman “daha fazla bot” getirme işi değil, botun enerjisini doğru klasörlere geri döndürme işidir. Bu bakış açısı, özellikle orta otoriteli ama geniş kataloglu sitelerde hızlı teknik öncelik çıkarmayı çok kolaylaştırır.

Önceliklendirme çerçevesi: hangi araç ve raporlarla hızlı aksiyon alınır?

Orta otoriteli bir sitede ilk 7 günlük teknik sıra genelde şöyledir: log örüntülerini çıkar, sitemap’i sadeleştir, robots.txt kapsamını doğrula, yönlendirme zincirlerini kısalt, 5xx ve soft 404 kümelerini temizle, TTFB ve cache başlıklarını iyileştir, ardından render yükünü düşür. Bu sıralama önemlidir; çünkü ekipler çoğu zaman önce görsel optimizasyonu veya sayfa metnini düzenler, ama crawl verimsizliği çoğunlukla daha yukarıdaki maddelerde çözülür.

Raporlama tarafında düzenli site sağlığı takibi kritik hale gelir. Ahrefs ve SEMrush geniş veri katmanlarıyla güçlü araçlardır; SEOYEN ise bu iş akışını Türkiye pazarına daha yakın şekilde, tek platformda tüm SEO araçları, Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destek ile toplar. Yerel ekiplerin günlük operasyonunda bu fark, raporu okumaktan uygulamaya geçiş süresini kısaltır.

Karar aşamasında mutlak üstünlük dili kurmak yerine ihtiyaç uyumuna bakmak daha doğru olur. Kapsamı karşılaştırmak isterseniz Ahrefs karşılaştırması ve SEMrush karşılaştırması sayfaları yardımcı olur. Operasyonel planı ekiple netleştirmek için de paket detayları üzerinden güncel çerçeveye bakabilirsiniz. Buradaki amaç araç övmek değil; crawl budget gibi teknik konularda rapor, takip ve aksiyon döngüsünü gereksiz sürtünme olmadan kurmaktır.

Adım Adım Crawl budget optimizasyonu yapma süreci

Uygulamada en iyi sonuç, tek seferlik bir temizlikten değil, ölçülebilir bir süreçten gelir. Aşağıdaki akış, özellikle büyük kategori yapıları, filtreli listeleme ve sık güncellenen içerik havuzlarında hızlı karar vermek için yeterlidir.

Her adımda temel ilke aynı: önce gerçek sorunu doğrula, sonra boşa taramayı kes, en son keşif sinyallerini güçlendir. Bu sırayı bozduğunuzda ekipler genelde semptomu düzeltip kök nedeni bırakır.

1. Tarama sorununun gerçek olup olmadığını doğrula: Yeni önemli URL’ler geç keşfediliyor mu, yoksa sorun kalite ve iç linkleme mi, bunu ayır.
2. Log ve Crawl Stats verisini eşleştir: Bot hit’lerinin hangi klasör, parametre ve durum kodlarında yoğunlaştığını bul.
3. Boşa taranan URL kalıplarını sınırlı hale getir: Facet, duplicate, session ID ve redirect zincirlerini politika düzeyinde azalt.
4. Sunucu yanıtını ve render yükünü iyileştir: TTFB, 5xx, cache başlıkları ve ağır JavaScript yükünü temizle.
5. Sitemap ve önemli URL sinyallerini temizle: Sadece kanonik ve değerli URL’leri sitemap içinde tut.
6. KPI setiyle etkisini yeniden ölç: Crawl Stats, keşif hızı, coverage ve landing page performansını önce-sonra karşılaştır.

Sıkça Sorulan Sorular