Tarama Bütçesi (Crawl Budget) Nedir? Googlebot'un Sitenizi Verimli Taraması

Tarama bütçesi (crawl budget), Googlebot'un belirli bir zaman diliminde sitenizde taramak istediği ve tarayabildiği URL sayısıdır. Bu sayı iki şeyin kesişiminden doğar: sunucunuzun yorulmadan kaldırabileceği tarama miktarı (tarama kapasitesi sınırı) ve Google'ın sayfalarınızı ne kadar taramaya değer bulduğu (tarama talebi). Bütçe sınırsız olmadığı için önemsiz URL'lere harcanan her istek, önemli sayfalarınızın daha geç keşfedilmesi ya da daha seyrek güncellenmesi anlamına gelir.

Bu rehberde tarama bütçesinin iki bileşenini, hangi sitelerin bu konuya gerçekten kafa yorması gerektiğini, Search Console'daki Tarama İstatistikleri raporunun nasıl okunacağını, bütçeyi sessizce tüketen URL türlerini ve robots.txt, canonical ile noindex arasındaki pratik farkı adım adım ele alıyoruz.

Tarama bütçesinin iki bileşeni

Google tarama bütçesini tek bir sayı olarak değil, birbirini dengeleyen iki kuvvet olarak tanımlar. İkisini ayrı ayrı anlamak, sorunun nerede olduğunu teşhis etmenin ilk adımıdır.

Tarama kapasitesi sınırı

Tarama kapasitesi sınırı, Googlebot'un sitenizi taramak için aynı anda açabileceği bağlantı sayısı ve istekler arasında bekleyeceği süredir. Amaç sunucunuzu aşırı yüklememektir. Bu sınır sabit değildir; sitenin o anki sağlığına göre yükselir ya da düşer:

• Sunucu bir süre boyunca hızlı ve hatasız yanıt veriyorsa sınır yükselir, Googlebot daha fazla bağlantı kullanır.
• Yanıtlar yavaşlıyor ya da 5xx sunucu hataları artıyorsa sınır düşer, tarama yavaşlar.
• Google'ın kendi tarama kaynakları da sınırlıdır; bu nedenle teknik olarak kaldırabilseniz bile sonsuz tarama beklenmez.

Search Console'da eskiden tarama hızını elle sınırlamaya yarayan bir ayar vardı; Google bu ayarı kaldırdı. Taramayı geçici olarak yavaşlatmak gerekiyorsa Google'ın önerdiği yol, kısa süreliğine 503 veya 429 durum kodu döndürmektir. Bunu günlerce sürdürmek ise sayfaların dizinden düşmesine yol açabilir, dolayısıyla kalıcı bir çözüm değildir.

Tarama talebi

Tarama talebi, Google'ın sitenizi ne kadar taramak istediğidir. Kapasite ne kadar yüksek olursa olsun, talep düşükse Googlebot o kapasiteyi kullanmaz. Talebi belirleyen başlıca etkenler şunlardır:

• Algılanan envanter: Google, sitenizde bildiği tüm URL'leri taramaya çalışır. Bu URL'lerin büyük kısmı kopya, gereksiz ya da kaldırılmış sayfalarsa tarama zamanı boşa gider.
• Popülerlik: İnternette daha çok bağlantı alan ve daha çok ziyaret edilen URL'ler daha sık taranma eğilimindedir.
• Güncellik: İçeriği sık değişen sayfalar, değişikliği yakalamak için daha sık ziyaret edilir.
• Site çapındaki olaylar: Alan adı değişikliği veya URL yapısının topluca değiştiği bir site taşıması, yeni adresleri işlemek için talebi geçici olarak artırır.

Kısacası tarama bütçesi = kapasite ile talebin izin verdiği tarama. Kapasite sunucu tarafında, talep ise içerik ve site yapısı tarafında iyileştirilir.

Tarama bütçesi hangi siteler için önemli?

Dürüst cevap şu: sitelerin çoğu için tarama bütçesi bir sorun değildir. Birkaç yüz ya da birkaç bin sayfalık, yeni sayfaları genellikle yayınlandığı gün ya da ertesi gün dizine giren bir kurumsal site veya blog için tarama bütçesi optimizasyonu öncelik listesinin üst sıralarında olmamalıdır. Google'ın kendi rehberi de bu konuyu ağırlıklı olarak çok büyük ya da çok sık değişen siteler için ele alır.

Aşağıdaki durumlardan biri sizin için geçerliyse konu ciddiye alınmalıdır:

Site tipi	Neden risk taşır?
Yüz binlerce veya milyonlarca URL'si olan siteler	Envanter büyüdükçe her URL'nin taranma sıklığı düşer.
E-ticaret siteleri	Ürün varyantları, sıralama seçenekleri ve stok değişimleri çok sayıda URL üretir.
Filtre ve parametre kullanan kategori sayfaları	Renk, beden, fiyat aralığı gibi filtrelerin kombinasyonları neredeyse sınırsız URL doğurur.
Haber ve ilan siteleri	İçerik günde birçok kez değişir, yeni sayfaların hızlı taranması gerekir.
Search Console'da "keşfedildi, şu anda dizine eklenmedi" durumunda çok sayıda URL görülen siteler	Google URL'yi biliyor ama taramaya sıra gelmemiş olabilir.

Filtreli kategori sayfalarının nasıl yapılandırılacağını, hangi filtre kombinasyonlarının dizine açılmaya değer olduğunu E-Ticaret SEO rehberinde ayrıntılı anlattık. Bu yazıda konunun tarama tarafına odaklanıyoruz.

Search Console Tarama İstatistikleri raporunu okuma

Tarama bütçesini tahminle değil veriyle yönetmek için başlangıç noktası Search Console'daki Tarama İstatistikleri raporudur. Rapor, Ayarlar bölümünün altında yer alır ve yalnızca alan adı düzeyindeki ya da kök dizindeki mülkler için görüntülenir.

Üst grafik: üç temel metrik

• Toplam tarama isteği: Seçilen dönemde Googlebot'un sitenize yaptığı istek sayısı. Tekrarlanan istekler de sayılır.
• Toplam indirme boyutu: Tarama sırasında indirilen toplam veri. Sayfalarınız ağırlaştıkça bu değer artar.
• Ortalama yanıt süresi: Sunucunun bir isteğe yanıt vermesi için geçen ortalama süre. Bu süre yalnızca HTML'yi değil, taranan tüm kaynakları kapsar.

Okuma kuralı basittir: ortalama yanıt süresi yükselirken toplam tarama isteği düşüyorsa, Google sunucunuzu yormamak için taramayı kısıyor demektir. İki çizginin birbirine ters hareket ettiği dönemler, sunucu tarafında bir şey değiştiğinin işaretidir.

Ana makine durumu

Bu bölüm son dönemde robots.txt dosyasının alınmasında, DNS çözümlemesinde ya da sunucu bağlantısında sorun yaşanıp yaşanmadığını gösterir. Burada kayda değer bir hata oranı varsa önce bunu çözün; ana makine sorunlu olduğunda Google taramayı bilinçli olarak yavaşlatır ve diğer optimizasyonların etkisi görünmez.

Kırılımlar: yanıt, dosya türü, amaç, Googlebot türü

1. Yanıta göre: 200 dışındaki yanıtların payına bakın. Yüksek oranda 301/302, 404 veya 5xx görüyorsanız bütçenin önemli bir kısmı faydasız isteklere gidiyordur.
2. Dosya türüne göre: HTML'nin payı çok düşük, görsel ya da betik payı çok yüksekse taranan kaynakların gerçekten gerekli olup olmadığını sorgulayın.
3. Amaca göre: Keşif, Google'ın daha önce hiç taramadığı URL'leri; yenileme ise bilinen URL'lerin tekrar taranmasını gösterir. Yeni içerik yayınladığınız halde keşif payı hiç kıpırdamıyorsa yeni sayfalarınız bulunamıyor olabilir.
4. Googlebot türüne göre: Akıllı telefon tarayıcısının baskın olması beklenen durumdur. Beklenmedik bir tarayıcı türünün yüksek payı incelenmeye değer.

Her kırılımın içine tıkladığınızda örnek URL listesi görürsünüz. Bu liste tüm URL'leri değil bir örneklemi gösterir, ama parametreli adreslerin ya da yönlendirme zincirlerinin bütçeyi yiyip yemediğini hızlıca anlamak için yeterlidir.

Tarama bütçesini israf eden şeyler

Bütçe sorunlarının büyük kısmı az sayıda tekrar eden kalıptan kaynaklanır. Aşağıdaki liste, kendi sitenizde aramanız gereken başlıca kalıpları gösterir.

Parametreli URL'ler

Sıralama, filtreleme, oturum kimliği ve takip parametreleri aynı içeriği farklı adreslerde sunar. Örneğin şu üç adres çoğu zaman aynı ürün listesini gösterir:

/ayakkabi?renk=siyah&sirala=fiyat
/ayakkabi?sirala=fiyat&renk=siyah
/ayakkabi?renk=siyah&sirala=fiyat&sessionid=8f2a

Parametre sırası değiştikçe ve ek parametreler eklendikçe URL sayısı katlanarak büyür. Çözüm, değeri olmayan parametreli adreslere site içinden bağlantı vermemek, gerekiyorsa bunları robots.txt ile taramaya kapatmak ve parametre sırasını sunucu tarafında sabitlemektir. Kampanya takibi için kullanılan parametreleri site içi bağlantılarda kullanmamak da aynı sorunu önler.

Sonsuz alanlar: takvimler ve sayfalama tuzakları

"Sonraki ay" bağlantısı olan bir etkinlik takvimi, teorik olarak sonsuz sayıda geleceğe ait boş sayfa üretir. Benzer şekilde hatalı göreli bağlantılar URL'nin kendi kendine uzamasına yol açabilir. Googlebot bu tür sonsuz alanlarda zaman harcarken asıl içerikler beklemede kalır. Takvim gibi yapılarda belirli bir tarih aralığının dışındaki sayfalara bağlantı vermeyin veya bu yolları taramaya kapatın.

Yönlendirme zincirleri

A adresi B'ye, B adresi C'ye, C de D'ye yönleniyorsa Googlebot tek bir sayfaya ulaşmak için birden fazla istek harcar. Google zincirin belli bir uzunluğundan sonra takibi bırakabilir. Site içi bağlantıları her zaman nihai adrese yönlendirin ve zincirleri tek adımlı yönlendirmeye indirin.

Soft 404 sayfalar

Soft 404, sayfanın aslında içeriği olmadığı halde sunucunun 200 durum kodu döndürmesidir. Stokta olmayan ürünler için "ürün bulunamadı" yazan ama 200 dönen sayfalar, sonuç vermeyen site içi arama sayfaları ve boş kategori sayfaları tipik örneklerdir. Google bu sayfaları taramaya devam eder, çünkü sunucu ona sayfanın var olduğunu söylemektedir. Kalıcı olarak kaldırılan içerik için 404 veya 410 döndürün; yerine geçen bir sayfa varsa 301 ile oraya yönlendirin.

Kopya ve neredeyse kopya sayfalar

Aynı içeriğin büyük-küçük harf farkıyla, sonda eğik çizgiyle ya da çizgisiz, www ile ve www olmadan, http ve https sürümleriyle erişilebilmesi; yazdırma sürümleri; aynı ürünün birden fazla kategori yolunda yer alması gibi durumlar envanteri şişirir. Bu kopyaları tek bir adrese indirgemek hem tarama bütçesini hem de sıralama sinyallerini toplar.

Kontrol listesi

• Site içi bağlantılarda parametreli adres kullanılıyor mu?
• Takvim, filtre veya arama sonuçları sonsuz URL üretiyor mu?
• İki ya da daha fazla adımlı yönlendirme var mı?
• İçeriği olmayan sayfalar 200 durum kodu döndürüyor mu?
• Aynı sayfaya birden fazla protokol, alt alan adı veya yol ile erişilebiliyor mu?
• Site haritasında yönlendirilen, 404 veren veya noindex taşıyan URL var mı?
• Sayfalar gereksiz yere ağır mı, kritik olmayan kaynaklar her sayfada yükleniyor mu?

Robots.txt, canonical ve noindex: hangisi neyi yapar?

Bu üç araç sıkça birbirinin yerine kullanılır, oysa tarama bütçesi üzerindeki etkileri tamamen farklıdır. Yanlış aracı seçmek sorunu çözmediği gibi bazen daha da büyütür.

Araç	Taramayı engeller mi?	Dizine eklemeyi engeller mi?	Tarama bütçesine etkisi
robots.txt Disallow	Evet	Kesin olarak hayır; URL başka yerden bağlantı alıyorsa içeriksiz olarak dizinde görünebilir	Doğrudan tasarruf sağlar
rel=canonical	Hayır	Hayır, ama sinyalleri tercih edilen adrese toplar	Uzun vadede kopyaların daha seyrek taranmasına yardımcı olur
noindex	Hayır; Google etiketi görmek için sayfayı taramak zorundadır	Evet	Kısa vadede tasarruf yok; zamanla bu sayfalar daha seyrek taranabilir

Buradan çıkan pratik kurallar şunlardır:

1. Taranmasını istemediğiniz ve değeri olmayan URL kalıpları (sonsuz filtre kombinasyonları, site içi arama sonuçları, sepet ve hesap sayfaları) için robots.txt kullanın.
2. Kullanıcılar için var olması gereken ama asıl sürümü başka bir adreste olan sayfalar için canonical kullanın. Canonical bir ipucudur, Google farklı bir adres seçebilir.
3. Taranabilmesi ama arama sonuçlarında görünmemesi gereken sayfalar için noindex kullanın.
4. Robots.txt ile engellenmiş bir sayfaya noindex eklemek işe yaramaz; Google sayfayı tarayamadığı için etiketi hiç görmez.

Robots.txt sözdizimini ve sık yapılan hataları Robots.txt rehberinde, kopya sayfalarda canonical'ın nasıl kurulacağını Canonical URL rehberinde ayrıntılı işledik. Site haritasının yalnızca dizine eklenmesini istediğiniz, 200 dönen ve canonical URL'leri içermesi de tarama talebini doğru yöne çevirmenin kolay bir yoludur; konunun ayrıntıları site haritası yazısında yer alıyor.

Sunucu yanıt süresi ve sayfa ağırlığı

Tarama kapasitesi sınırının en doğrudan kaldıracı sunucunun hızıdır. Sunucu ne kadar hızlı yanıt verirse Googlebot aynı sürede o kadar çok sayfa alabilir. Burada önemli olan, kullanıcının gördüğü toplam yüklenme süresinden çok sunucunun ilk baytı ne kadar sürede gönderdiğidir.

• Önbellekleme: Dinamik olarak üretilen ama sık değişmeyen sayfaları sunucu tarafında önbelleğe alın.
• Veritabanı sorguları: Kategori ve filtre sayfalarındaki yavaş sorgular, tarama sırasında yanıt süresini en çok bozan kalemlerdendir.
• Koşullu istekler: Sunucunuz Last-Modified veya ETag başlıklarını doğru gönderip değişmemiş sayfalar için 304 Not Modified dönebiliyorsa, Googlebot aynı içeriği tekrar indirmek zorunda kalmaz.
• Kaynak sayısı: Google sayfayı oluştururken gereken betik ve stil dosyalarını da çeker. Gereksiz kaynaklar her sayfa için ek istek demektir.
• Hata oranı: Yoğun saatlerde 5xx hatası veren bir sunucu, Google'ın kapasite sınırını aşağı çekmesine neden olur.

Tarama İstatistikleri raporundaki ortalama yanıt süresini, sunucu tarafında yaptığınız değişikliklerden önce ve sonra not edin. Bu basit karşılaştırma, yaptığınız iyileştirmenin taramaya yansıyıp yansımadığını gösteren en somut kanıttır.

Log analizi: Googlebot'un gerçekte ne yaptığını görmek

Search Console örneklenmiş ve özetlenmiş bir görünüm sunar. Googlebot'un sitenizde tam olarak hangi URL'leri, ne sıklıkla ziyaret ettiğini görmenin tek yolu sunucu erişim kayıtlarını (log dosyalarını) incelemektir. Log analizi ilk bakışta teknik görünse de temel mantığı basittir.

Adım adım temel log analizi

1. Kayıtları toplayın: Barındırma panelinizden veya sunucudan en az iki ila dört haftalık erişim kayıtlarını alın. Bir içerik dağıtım ağı kullanıyorsanız kayıtların bir kısmı orada tutuluyor olabilir.
2. Googlebot isteklerini ayıklayın: Kullanıcı aracısında Googlebot geçen satırları filtreleyin. Kullanıcı aracısı taklit edilebildiği için, şüpheli IP'leri ters DNS sorgusuyla doğrulayın; gerçek Googlebot adresleri googlebot.com veya google.com alan adına çözümlenir.
3. URL'leri gruplayın: İstekleri dizine göre (örneğin ürün, kategori, blog, filtre) ve parametreli/parametresiz olarak sınıflandırın.
4. Durum kodlarını sayın: Her grup için 200, 3xx, 404 ve 5xx oranlarını çıkarın.
5. Karşılaştırın: En çok taranan grupları, sizin için en değerli sayfa gruplarıyla yan yana koyun.

Basit bir log satırı şuna benzer:

66.249.66.1 - - [27/Oct/2026:10:14:02 +0300] "GET /ayakkabi?renk=siyah&sirala=fiyat HTTP/1.1" 200 48211 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Bu satırdan IP adresini, zamanı, istenen URL'yi, durum kodunu, yanıt boyutunu ve kullanıcı aracısını okuyabilirsiniz. Komut satırına alışkınsanız temel bir filtre şöyle olabilir:

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

Bu komut Googlebot'un en çok istediği 50 URL'yi sayılarıyla listeler. Listenin üst sıralarında parametreli adresler, eski yönlendirmeler ya da hiç önemsemediğiniz sayfalar varsa, bütçenin nereye aktığını bulmuşsunuz demektir.

Log analizinde aranacak sinyaller

• Önemli kategori veya ürün sayfalarının haftalarca hiç taranmaması.
• Tek bir parametre kalıbının toplam isteklerin büyük bölümünü oluşturması.
• Silinmiş ve 404 veren URL'lerin ısrarla taranması; bu durum genellikle bu adreslere hâlâ bir yerden bağlantı verildiğini gösterir.
• Site haritasında olan ama logda hiç görünmeyen URL'ler.

Tarama bütçesini iyileştirmek için uygulama planı

Yukarıdaki teşhisleri bir sıraya koymak, işi yönetilebilir kılar. Aşağıdaki sıra, etkisi en büyük ve riski en düşük adımlardan başlar:

1. Durumu ölçün: Tarama İstatistikleri raporundaki toplam istek, ortalama yanıt süresi ve yanıt kırılımını bir tabloya not edin. Sayfa dizine ekleme raporundaki "keşfedildi, şu anda dizine eklenmedi" ve "tarandı, şu anda dizine eklenmedi" sayılarını da ekleyin.
2. Ana makine sorunlarını giderin: DNS, sunucu bağlantısı ve robots.txt erişimi hatalarını önce kapatın.
3. Site içi bağlantıları temizleyin: Yönlendirilen, 404 veren ve parametreli adreslere verilen iç bağlantıları nihai, temiz URL'lerle değiştirin.
4. Sonsuz alanları kapatın: Filtre kombinasyonları, site içi arama ve takvim gibi yolları robots.txt ile taramaya kapatın; dizine açılmaya değer birkaç filtre sayfasını bilinçli olarak seçin.
5. Kopyaları birleştirin: Protokol, alt alan adı ve sondaki eğik çizgi varyantlarını tek adrese 301 ile yönlendirin, kalan kopyalarda canonical kullanın.
6. Soft 404'leri düzeltin: İçeriği olmayan sayfaların doğru durum kodunu döndürmesini sağlayın.
7. Site haritasını sadeleştirin: Yalnızca 200 dönen, canonical ve dizine eklenmesini istediğiniz URL'leri bırakın; içeriği gerçekten değişen sayfalarda son değişiklik tarihini doğru verin.
8. Sunucuyu hızlandırın: Önbellekleme ve sorgu iyileştirmeleriyle ortalama yanıt süresini düşürün.
9. Dört ila altı hafta sonra tekrar ölçün: İlk adımdaki tabloyu yeniden doldurun ve karşılaştırın.

Tarama verisi tek başına okunduğunda eksik kalır; asıl soru, taramadaki değişikliğin dizine ekleme ve organik görünürlüğe yansıyıp yansımadığıdır. Bu yüzden tarama düzeltmelerinden sonra ilgili sayfa gruplarının gösterim ve tıklama eğilimini de izleyin. SEO Analytics gibi Search Console verisini sayfa bazında takip eden bir panel, düzeltme yaptığınız sayfa grubunun haftalar içindeki seyrini tek ekranda görmeyi kolaylaştırır. Tarama bütçesi tek başına bir hedef değil, daha geniş bir teknik denetimin parçasıdır; resmin bütünü için teknik SEO kontrol listesine göz atabilirsiniz.

Sık sorulan sorular

Küçük bir site tarama bütçesi için endişelenmeli mi?

Genellikle hayır. Birkaç bin sayfadan küçük ve yeni sayfaları birkaç gün içinde dizine giren bir sitede tarama bütçesi nadiren darboğaz olur. Yeni sayfalar uzun süre dizine girmiyorsa sorun çoğunlukla içerik kalitesi, iç bağlantı eksikliği veya teknik bir engeldir.

Tarama bütçesini artırmanın bir yolu var mı?

Doğrudan bir ayar yoktur. Sunucuyu hızlandırmak ve hata oranını düşürmek tarama kapasitesini, daha değerli ve daha çok bağlantı alan içerik üretmek tarama talebini artırır. Çoğu durumda en hızlı kazanç, bütçeyi artırmaktan çok israf edilen kısmı geri kazanmaktan gelir.

Noindex eklemek tarama bütçesinden tasarruf ettirir mi?

Kısa vadede hayır. Google noindex etiketini görmek için sayfayı taramak zorundadır. Uzun vadede noindex sayfalar daha seyrek taranabilir, ancak taramayı doğrudan önlemek istiyorsanız doğru araç robots.txt'tir.

Tarama İstatistikleri raporundaki sayı birden düştü, ne yapmalıyım?

Önce aynı dönemde ortalama yanıt süresinin yükselip yükselmediğine ve ana makine durumunda hata olup olmadığına bakın. Sunucu tarafı temizse robots.txt dosyasında yanlışlıkla geniş bir engelleme yapılıp yapılmadığını ve yakın zamanda büyük bir URL değişikliği olup olmadığını kontrol edin. Sunucu sağlıklı ve içerik değişmemişken görülen dalgalanmalar çoğu zaman normal kabul edilebilir.