Crawl Budget Nedir: Tarama Bütçesi Optimizasyonu

Google her siteye sınırsız tarama kaynağı ayırmaz. Her domain için belirli bir tarama bütçesi vardır ve bu bütçe verimsiz alanlarda tükenirse yeni yayınladığınız sayfalar indekse günler, hatta haftalar sonra girer. Birkaç yüz sayfalık bir blog için bu durum genelde sorun yaratmaz. On binlerce sayfalı bir e-ticaret sitesinde ise crawl budget yönetimi doğrudan satışlara yansıyan bir SEO meselesine dönüşür.

Crawl budget tam olarak nedir

Crawl budget, Googlebot'un belirli bir sitede belirli bir zaman diliminde tarayacağı URL sayısını ifade eder. Google Search Central dokümantasyonu bu kavramı iki bileşene ayırır: crawl rate limit ve crawl demand.

Crawl rate limit, Googlebot'un sunucunuzu zorlamadan açabileceği eşzamanlı bağlantı sayısının teknik sınırıdır. Sunucu yavaş yanıt veriyorsa ya da sık 5xx hatası dönüyorsa Google bu limiti otomatik düşürür. Crawl demand ise Google'ın siteyi ne kadar taramaya değer bulduğudur; popüler, sık güncellenen ve otoriter sayfalar daha yüksek talep görür.

Bu iki bileşen birlikte çalışır. Sunucu hızlı olsa bile içerik değersizse Google az tarar; içerik değerli olsa bile sunucu yavaşsa yine az tarar. İkisi birlikte iyi olduğunda tarama sıklığı artar.

Bunu somut bir örnekle açmak gerekirse: Googlebot teknik olarak dakikada yüzlerce istek atabilecek kapasiteye sahip olsa bile, site içeriği durgunsa ya da düşük kaliteliyse bu kapasiteyi kullanmaz. Tersine, çok değerli bir site de yavaş bir sunucu yüzünden potansiyel tarama hacmine hiç ulaşamayabilir.

JavaScript render maliyeti bu denklemin genelde göz ardı edilen bir parçasıdır. Googlebot bir sayfayı önce ham HTML olarak alır; içerik JavaScript ile üretiliyorsa sayfayı ikinci bir aşamada render kuyruğuna koyar. Bu iki aşamalı süreç, statik HTML sayfalara göre daha fazla sunucu ve işlem kaynağı tüketir. React veya Vue tabanlı, client-side render'a dayanan siteler bu yüzden aynı sayfa sayısına sahip statik bir siteden daha yavaş taranır. Kritik içeriği sunucu tarafında render etmek (SSR) ya da statik HTML olarak önceden üretmek bu ek maliyeti ortadan kaldırır.

Crawl budget hangi sitelerde gerçekten önemli

Birkaç yüz sayfalık bir blog ya da kurumsal site için crawl budget nadiren pratik bir sorundur; Google küçük siteleri genelde birkaç gün içinde eksiksiz tarar. Google'ın kendi dokümantasyonu da bunu açıkça belirtir: birkaç bin sayfanın altındaki siteler crawl budget konusunda endişelenmemelidir.

Sorun büyüklüğünü kabaca üç kademede değerlendirmek mümkün. Birkaç bin sayfalık bir kurumsal site ya da orta ölçekli blog ağı genelde güvenli bölgededir; burada asıl mesele crawl budget değil, içerik kalitesi ve iç link yapısıdır. On binlerce sayfaya çıkan siteler (çok kategorili e-ticaret mağazaları, ilan siteleri, geniş içerik arşivleri) artık parametre kirliliğine ve yinelenen içeriğe karşı dikkatli olmalıdır.

Yüz binlerce, hatta milyonlarca URL'ye ulaşan siteler (büyük pazaryerleri, iş ilanı platformları, çok dilli kurumsal siteler) crawl budget'ı aktif olarak yönetmek zorundadır. Bu ölçekte robots.txt kuralları, sitemap segmentasyonu ve log analizi seçenek değil, düzenli operasyonel rutindir. Sitenizin hangi kademede olduğunu anlamak için Search Console'daki toplam indekslenmiş sayfa sayısını, yayında olan gerçek sayfa sayınızla karşılaştırmak iyi bir başlangıç noktasıdır.

Bu sorun genelde sayfa sayısı on binleri, yüz binleri geçtiğinde büyür. Büyük e-ticaret siteleri, geniş forumlar ve çok sayıda filtre kombinasyonu üreten kategori sayfaları bu gruba girer. Bu tür sitelerde Googlebot bütçesinin büyük kısmını değersiz URL'lerde tüketirse, yeni ürün sayfaları ya da güncellenmiş içerik günlerce taranmadan kalabilir.

Tarama bütçesini boşa harcayan yaygın hatalar

Crawl budget'ı israf eden sorunlar genelde site mimarisinden kaynaklanır ve çoğu zaman fark edilmeden birikir.

• Yinelenen içerik: Aynı ürünün ?renk=mavi ve ?renk=kirmizi gibi parametrelerle onlarca varyasyonu, Googlebot'a aynı içeriği tekrar tekrar taratır.
• Düşük değerli ince sayfalar: Otomatik oluşturulmuş, neredeyse boş kategori ya da etiket sayfaları bütçeyi tüketir.
• Yönlendirme zincirleri: A'dan B'ye, B'den C'ye giden 301 zincirleri, tek bir sayfa için birden fazla tarama isteği harcatır.
• Kırık bağlantılar ve 404'ler: Site içinde hâlâ bağlantı verilen ölü URL'ler Googlebot'u boşuna gezdirir.
• Gereksiz URL parametreleri: Sıralama, filtreleme ve oturum kimliği gibi parametreler binlerce yeni URL varyasyonu üretebilir.
• Sonsuz kaydırma (infinite scroll): JavaScript ile yüklenen ve ayrı URL'si olmayan sayfalama, Googlebot'un ilk birkaç üründen sonrasını hiç görmemesine yol açabilir.

Bu listedeki her madde tek başına küçük bir kayıp gibi görünse de, büyük bir sitede kümülatif etkisi ciddi boyutlara ulaşır. Yüz bin sayfalık bir katalogda parametre kombinasyonları birkaç milyon URL'ye kolayca çıkabilir.

Bir e-ticaret sitesinde bu israf genelde filtre kombinasyonlarından gelir: beden, renk, fiyat aralığı ve sıralama seçeneklerinin çarpımı teorik olarak binlerce benzersiz URL üretebilir. Bu URL'lerin neredeyse hepsi aynı ürünleri farklı sırada gösterir ve arama motoru için ek bir değer taşımaz.

Aşağıdaki tablo, sık görülen israf kalıplarını ve hangi çözümün ne zaman uygun olduğunu özetliyor:

robots.txt ve XML sitemap ile tarama yönlendirme

robots.txt, Googlebot'a hangi yolların taranmaması gerektiğini bildirmenin en direkt yoludur. Filtre ve sıralama parametrelerini burada engellemek bütçeyi gerçek içeriğe yönlendirir:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?sessionid=
Disallow: /search/
Disallow: /*/print/

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

robots.txt bir sayfayı taramadan engeller ama zaten indekslenmiş bir sayfayı indeksten çıkarmaz; bunun için noindex meta etiketi ya da Search Console'daki kaldırma aracı gerekir. XML sitemap ise tam tersi bir görev görür: Google'a hangi URL'lerin önemli olduğunu proaktif olarak bildirir.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/urun/ornek-urun</loc>
    <lastmod>2026-06-15</lastmod>
    <changefreq>weekly</changefreq>
  </url>
</urlset>

Sitemap'i yalnızca kanonik, indekslenmesini istediğiniz URL'lerle sınırlı tutmak önemlidir. Yönlendirilen, noindex olan ya da 404 dönen URL'leri sitemap'e eklemek Google'ın güvenini azaltır ve zamanla sitemap'inizin ciddiye alınma oranını düşürür.

Canonical etiketleri ve iç link mimarisi

Yinelenen içerik sorununun bir diğer çözümü canonical etiketleridir. Aynı ürünün farklı parametrelerle erişilen versiyonlarında hangi URL'nin asıl olduğunu belirtmek Google'a net bir sinyal verir:

<link rel="canonical" href="https://example.com/urun/ornek-urun" />

İç link mimarisi crawl demand'i doğrudan etkiler. Google, bir sayfaya kaç iç link geldiğini ve bu linklerin hangi derinlikten geldiğini önemli bir sinyal olarak kullanır. Ana sayfadan üç tıklamadan uzak sayfalar genelde daha seyrek taranır; bu yüzden önemli kategori ve ürün sayfalarının ana menüden ya da öne çıkan bağlantılardan ulaşılabilir olması gerekir.

Yetim sayfa (orphan page) sorunu burada özellikle zarar verir. Hiçbir sayfadan link almayan, yalnızca sitemap'te bulunan bir URL'yi Google bulsa bile düşük öncelikli sayar. Yeni yayınlanan her sayfayı en az bir kategori sayfasından ya da ilgili içerikten linklemek bu sorunu baştan önler.

Sayfalanmış kategori listeleri de ayrı bir dikkat ister. Google, rel=next ve rel=prev etiketlerini artık sinyal olarak kullanmadığını açıkladığından, sayfalamanın etkili çalışması artık her sayfanın kendi başına indekslenebilir ve linklenebilir olmasına bağlıdır. Her sayfalama adımının benzersiz bir URL'si olmalı, bu URL'ler iç linklerle birbirine bağlanmalı ve mümkünse ilk sayfadan çok uzaklaşmadan tüm ürünlere erişim sağlanmalıdır. Sonsuz kaydırma kullanan sitelerde, arka planda klasik sayfalanmış URL'lerin de bulunması (progressive enhancement) Googlebot'un içeriğe erişimini garanti eder.

Sunucu hızı tarama sıklığını nasıl etkiler

Sunucu yanıt süresi crawl rate limit'i doğrudan belirleyen faktörlerden biridir. Googlebot bir sitenin yanıt sürelerini sürekli izler; yanıtlar yavaşladığında ya da 500 hatası oranı arttığında, sunucuyu zorlamamak için tarama hızını otomatik düşürür.

Bu yüzden performans optimizasyonu, yalnızca kullanıcı deneyimi meselesi değil, aynı zamanda bir crawl budget stratejisidir. Sunucu taraflı önbellekleme, veritabanı sorgu optimizasyonu ve CDN kullanımı, Googlebot'un aynı sürede daha fazla sayfa taramasına imkân tanır.

Search Console'daki Tarama İstatistikleri raporu, ortalama yanıt süresini ve günlük tarama isteği sayısını gösterir. Sunucu değişikliği ya da CMS güncellemesi sonrası tarama davranışının nasıl değiştiğini görmek için bu raporu düzenli kontrol etmek gerekir.

Sunucu loglarıyla gerçek tarama davranışını izleme

Search Console verisi örneklenmiş ve gecikmelidir; gerçek tarama davranışını görmek için ham sunucu loglarına bakmak gerekir. Access log'da Googlebot'un user-agent'ını filtrelemek, hangi URL'lerin ne sıklıkla tarandığını gösterir:

grep "Googlebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Bu komutun çıktısı genelde şaşırtıcıdır: çoğu sitede en çok taranan URL'lerin önemli bir kısmı, aslında SEO açısından değersiz parametre kombinasyonlarıdır. İkinci adımda, Googlebot'un hangi HTTP durum koduyla karşılaştığına bakmak gerekir; 404 ve 500 gibi hatalı yanıtlara giden tarama isteklerinin oranı, bütçenin ne kadarının boşa gittiğini gösterir.

grep "Googlebot" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Bu iki komutun çıktısını yan yana koyduğunuzda genelde net bir tablo ortaya çıkar. En sık taranan URL'ler değersizse ve bunların içinde 404/500 oranı yüksekse, robots.txt ve mimari düzeltmeler öncelikli hale gelir. Log analizini aylık bir rutine dönüştürmek, robots.txt ve canonical stratejinizin gerçekten işe yarayıp yaramadığını sayısal olarak doğrulamanın tek yoludur.

Büyük sitelerde log analizini otomatikleştirmek için Screaming Frog Log File Analyser ya da özel BigQuery sorguları kullanılabilir. Amaç her zaman aynıdır: Googlebot'un zamanını değerli sayfalara mı, yoksa gürültüye mi harcadığını görmek.

Crawl budget optimizasyonu tek seferlik bir düzeltme değildir; site büyüdükçe tekrar gözden geçirilmesi gereken bir disiplindir. Yeni bir filtre özelliği, yeni bir URL parametresi ya da yeni bir kategori yapısı eklendiğinde, bu değişikliğin tarama davranışına etkisini loglardan kontrol etmek sorunun büyümeden fark edilmesini sağlar. En pratik alışkanlık, her yeni özellik yayına çıkmadan önce bu değişikliğin kaç yeni URL üreteceğini sormak ve cevap binleri geçiyorsa robots.txt kuralını kod ile aynı anda devreye almaktır.

Yazan Celil Uyanikoglu

Bilgisayar mühendisiyim; 25 yılı aşkın süredir bilgi işlem sektörünün içindeyim. Bu blogu 2020'de, işimde her gün karşılaştığım sorunların çözümlerini bir yere yazmak için açtım: Linux, güvenlik, tarayıcılar, yapay zeka araçları. Yazdığım her rehberi önce kendi bilgisayarımda ya da sunucumda deniyorum; çalıştığını görmediğim adımı yayınlamam. Hatalı ya da eskimiş bir şey görürsen iletişim sayfasından yaz — düzeltirim.