Crawl bütçesi nedir, hangi iki bileşenden oluşur?
Crawl bütçesi, bir arama motorunun belirli bir zaman aralığında bir alan adına göndermeyi kabul ettiği toplam istek sayısıdır. Google bu kavramı iki alt bileşene ayırır. Birincisi crawl rate limit: sunucunuzun bozulmadan taşıyabildiği eşzamanlı istek sayısı ve istekler arası bekleme süresidir. Googlebot yanıt sürelerinin uzadığını veya 5xx oranının arttığını gördüğünde bu limiti kendiliğinden aşağı çeker. İkincisi crawl demand: içeriğin popülerliği, güncellenme sıklığı ve arama motorunun elindeki kopyanın bayatlama derecesidir. Rate limit arzı, demand ise talebi temsil eder; gerçek tarama hacmi bu ikisinin kesişiminde oluşur.
Bu ayrım pratikte kritik bir sonuç doğurur: sunucunuzu hızlandırmak tek başına daha fazla taranmayı garanti etmez, çünkü talep tarafı içerik kalitesi ve link sinyalleriyle belirlenir. Aynı şekilde harika içerik üretmek de yavaş bir sunucuda tarama hacmini büyütmez. Teknik SEO tarafında hedef, arzı yükseltirken talebi doğru URL'lere yönlendirmektir. Berpel'in teknik SEO hizmeti kapsamında yürütülen çalışmalarda bu iki eksen ayrı ayrı ölçülür ve ayrı ayrı raporlanır.
Tarama yüzeyi: sorun sayfa sayısında değil, kombinatorikte
Tarama yüzeyi, arama motorunun sitede takip edebileceği benzersiz URL'lerin toplamıdır. Bir kurumsal sitede bu sayı yayınlanan sayfa sayısına yakınken, e-ticarette kombinatorik patlama nedeniyle yüzlerce kat büyür. Beş filtre boyutu (marka, renk, beden, fiyat aralığı, stok durumu) ve her boyutta ortalama altı seçenek bulunan bir kategori sayfası, sıralama ve sayfalama parametreleriyle birlikte tek başına on binlerce taranabilir kombinasyon üretebilir.
Kombinatorik patlamanın klasik kaynakları şunlardır:
- Faceted navigation: filtre bağlantılarının
<a href>olarak sunulması ve her kombinasyonun kendi URL'sini üretmesi. - Oturum ve izleme parametreleri:
?utm_source,?ref,?sessionidgibi içeriği değiştirmeyen sorgu dizeleri. - Sonsuz takvim ve sayfalama: gelecek tarihlere doğru sınırsız üretilen etkinlik veya rezervasyon URL'leri.
- Büyük/küçük harf ve eğik çizgi varyantları: aynı içeriği dört farklı URL ile sunan sunucu yapılandırmaları.
- Dahili arama sonuç sayfaları: kullanıcı sorgularının indekslenebilir URL'lere dönüşmesi.
- Karşılaştırma, yazdırma ve AMP benzeri ikincil çıktılar: aynı içeriğin paralel kopyaları.
Bu yüzeyi ölçmeden yapılan her optimizasyon tahmine dayanır. Ölçüm için üç veri kaynağı birlikte okunur: tam site taraması (crawler), XML site haritası envanteri ve sunucu erişim log'ları. Crawler size teorik yüzeyi, site haritası niyetinizi, log'lar ise gerçeği gösterir. Üçü arasındaki fark kümesi çalışmanın gerçek gündemidir.
Log dosyası analizi: yöntem
1. Ham veriyi toplama ve doğrulama
Analiz için en az 30 günlük erişim log'u gerekir; mevsimsel etkisi olan sektörlerde 90 gün tercih edilir. Nginx ve Apache'nin combined formatı yeterli alanı içerir. İlk adım sahte botların ayıklanmasıdır: kendini Googlebot ilan eden isteklerin kaynak IP'si ters DNS ile googlebot.com veya google.com alanına, ardından ileri DNS ile aynı IP'ye çözümlenmelidir. Doğrulanmamış istekler ayrı bir kümede tutulur; bunlar çoğu zaman scraper trafiğidir ve sunucu yükünün önemli bir kısmını açıklar.
2. İstekleri anlamlı gruplara indirgeme
Ham URL listesi doğrudan yorumlanamaz. URL'ler şablon (template) düzeyine indirgenir: ürün detay, kategori, filtreli kategori, blog yazısı, etiket, hizmet sayfası, statik varlık. Ardından her grup için dört metrik hesaplanır: toplam Googlebot isteği, benzersiz URL sayısı, ortalama yanıt süresi ve durum kodu dağılımı. Bu tablo tek başına vakaların çoğunda sorunu görünür kılar.
3. Fark kümelerini çıkarma
Dört fark kümesi kritik değer taşır:
- Taranıyor ama site haritasında yok: genellikle parametreli veya filtreli URL'lerdir; tarama bütçesinin sızdığı yerdir.
- Site haritasında var ama taranmıyor: iç link derinliği yüksek, otoritesi zayıf veya yavaş yanıt veren sayfalardır.
- Taranıyor ama dönüşüm/trafik üretmiyor: düşük değerli şablonların bütçedeki payı.
- Trafik üretiyor ama seyrek taranıyor: güncelleme sonrası indeks tazeliği riski taşıyan sayfalar.
4. Zaman serisi okuması
Tarama hacmi ile 5xx oranı ve ortalama yanıt süresi aynı grafikte üst üste bindirildiğinde nedensellik netleşir. Yanıt süresinin 800 ms üzerine çıktığı günlerde Googlebot isteklerinin düşmesi, sorunun içerik değil altyapı kaynaklı olduğunu kanıtlar. Tersine, yanıt süresi sabitken tarama hacminin düşmesi talep tarafında bir sorun olduğunu, yani içeriğin bayatladığını veya link sinyallerinin zayıfladığını gösterir.
Vaka analizi: 42.000 ürünlü tekstil e-ticareti
Aşağıdaki veriler, Berpel'in yürüttüğü bir e-ticaret teknik SEO projesinin 30 günlük log analizi özetidir. Rakamlar proje sözleşmesi gereği oransal olarak paylaşılmıştır.
| URL şablonu | Googlebot isteği (öncesi) | Organik oturum payı | Googlebot isteği (12 hafta sonra) |
|---|---|---|---|
| Filtreli kategori (parametreli) | %54 | %2 | %7 |
| Dahili arama sonuçları | %11 | %0 | %0 |
| Ürün detay | %18 | %61 | %49 |
| Kategori (temiz URL) | %9 | %28 | %31 |
| Blog ve rehber | %4 | %9 | %11 |
| Yönlendirme ve hata (3xx/4xx/5xx) | %4 | — | %2 |
Başlangıç tablosu tek cümlede özetlenebilir: tarama bütçesinin üçte ikisi, organik oturumların yüzde ikisini üreten URL'lere harcanıyordu. Uygulanan müdahaleler sırasıyla şunlardı: dahili arama sonuçlarının Disallow ile tarama dışına alınması; filtre bağlantılarının tek boyutlu kombinasyonlar dışında <button> + pushState yapısına taşınması; kalan filtreli URL'lerde canonical'ın üst kategoriye işaret etmesi; 1.240 yönlendirme zincirinin tek adıma indirilmesi; ürün detay şablonunda TTFB'nin 940 ms'den 210 ms'ye düşürülmesi.
Sonuç: yeni ürünlerin yayından indekse geçiş medyanı 6,4 günden 19 saate indi; indeks kapsamı raporundaki "Taranmadı - şu anda dizine eklenmedi" kümesi %71 küçüldü; ürün detay şablonunun organik oturumları on iki hafta içinde %38 arttı. Aynı dönemde içerik ekibi yeni metin üretmedi; kazanım tamamen tarama ekonomisinin yeniden dağıtılmasından geldi.
Tarama yüzeyini daraltma kararları ve doğru araç seçimi
Her sorun için farklı bir direktif doğrudur. En sık yapılan hata, tüm vakalarda robots.txt'e başvurmaktır.
| Durum | Doğru müdahale | Neden |
|---|---|---|
| Dahili arama sonuçları | robots.txt Disallow | Hiçbir koşulda indeks değeri yok; tarama hiç harcanmamalı. |
| Tek boyutlu filtre (ör. marka) | Taranabilir + self canonical | Gerçek arama talebi olan uzun kuyruk sayfalar. |
| Çok boyutlu filtre kombinasyonu | Link'i kaldır, canonical üst kategoriye | Talep yok, kombinatorik patlama var. |
| Kalıcı olarak kaldırılan ürün | 410 Gone | 404'e göre daha hızlı indeksten düşer. |
| Geçici stok yokluğu | 200 + yapılandırılmış veri güncellemesi | URL'nin otoritesi korunur. |
| İndeksten çıkarılacak zayıf içerik | Taranabilir + noindex | robots.txt ile engellenirse noindex hiç görülmez. |
| İzleme parametreleri | Self canonical + iç linklerde parametresiz URL | Kopya URL üretimi kaynağında kesilir. |
Sayfalamada rel="next" ve rel="prev" artık Google tarafından tarama sinyali olarak kullanılmıyor; bunun yerine her sayfalama adımının kendine self canonical vermesi ve ürünlere doğrudan iç link sağlaması tercih edilir. "Tümünü göster" sayfası ancak yanıt süresi kabul edilebilir seviyedeyse canonical hedefi yapılmalıdır.
Sunucu tarafı: arzı yükseltmek
Tarama arzını belirleyen en somut değişken sunucu yanıt süresidir. Deneyimimiz, medyan TTFB'nin 200 ms altına indirildiği projelerde günlük Googlebot isteğinin birkaç hafta içinde belirgin şekilde yükseldiğini gösteriyor. Uygulanan başlıca kaldıraçlar:
- Nesne önbelleği: tekrarlayan sorguların sonuçlarının 6–12 saatlik anahtarlarla saklanması ve içerik güncellemesinde geçersizleştirilmesi.
- Tam sayfa önbelleği: oturumsuz ziyaretçiler için HTML'in kenar (edge) katmanında sunulması; sepet ve hesap sayfalarının önbellek dışında bırakılması.
- Veritabanı indeksleri: listeleme sorgularında sıralama ve filtre alanlarına bileşik indeks eklenmesi; toplam satır sayımı gerekmeyen sorgularda sayım maliyetinin kaldırılması.
- Koşullu istekler:
Last-ModifiedveETagbaşlıklarıyla değişmemiş kaynaklara 304 dönülmesi; bu, aynı bütçeyle daha fazla URL taranmasını sağlar. - Sıkıştırma ve HTTP/2: Brotli ile HTML boyutunun düşürülmesi, bağlantı başına istek maliyetinin azaltılması.
Yanıt süresi çalışması aynı zamanda kullanıcı tarafında Core Web Vitals metriklerini de doğrudan iyileştirir; bu iki başlık aynı mühendislik bütçesinden beslenir. Ayrıntılı yöntem için Core Web Vitals ve INP optimizasyonu rehberine bakabilirsiniz.
İç link mimarisi: talebi yönlendirmek
Tarama talebi büyük ölçüde iç link grafiğinden beslenir. Ana sayfadan üç tıklamadan uzak kalan sayfaların taranma sıklığı belirgin biçimde düşer. Uygulanan yapısal düzenlemeler:
- Kategori sayfalarında ürün başına en az bir kalıcı iç link; sonsuz kaydırma kullanılıyorsa sunucu tarafında da render edilen sayfalama.
- Hub-spoke modelinde hizmet sayfasından rehberlere, rehberden hizmet sayfasına çift yönlü bağlantı; bu sitede uygulanan model Rehber Merkezi üzerinden izlenebilir.
- Anchor metinlerinin varlık (entity) adıyla eşleşmesi: "buraya tıklayın" yerine "crawl bütçesi analizi".
- Yetim sayfaların (orphan page) periyodik tespiti: crawler'ın bulduğu URL kümesinden site haritası kümesinin çıkarılması.
- Gezinme dışı bağlam linkleri: içerik gövdesinden verilen linkler, menü linklerine göre daha güçlü tematik sinyal taşır.
Ölçümleme ve raporlama çerçevesi
Crawl bütçesi çalışmasının başarısı üç metrik ailesiyle raporlanır. Birinci aile verimlilik: değerli URL'lere düşen Googlebot isteği oranı, hata ve yönlendirme isteklerinin payı, benzersiz taranan URL sayısı. İkinci aile hız: yayından ilk taramaya, ilk taramadan indekse geçiş süreleri. Üçüncü aile sonuç: indekslenen değerli URL sayısı, bu URL'lerin organik oturum ve gelir katkısı.
Raporlama ritmi haftalık log özeti ve aylık karşılaştırmalı analizdir. Search Console'un Tarama İstatistikleri raporu doğrulama amacıyla kullanılır; ancak örneklenmiş veri sunduğu için tek başına karar kaynağı yapılmaz. Kararlar log'dan, doğrulama Search Console'dan gelir.
Son olarak, crawl bütçesi çalışması bir kerelik proje değil süreklilik gerektiren bir bakım disiplinidir. Yeni bir filtre boyutu, yeni bir dil sürümü veya yeni bir kampanya parametresi, aylar süren kazanımı birkaç haftada geri alabilir. Bu nedenle yayın öncesi kontrol listesine "yeni URL üretiyor mu, üretiyorsa taranabilir mi" sorusu eklenir ve her sürümde işletilir. Kapsamlı bir denetim için teknik SEO hizmeti sayfamızdan başlayabilir, çok lokasyonlu yapılarda tarama yüzeyinin şehir sayfalarıyla nasıl kesiştiğini çoklu lokasyon Local SEO mimarisi rehberinde inceleyebilirsiniz.
Sahada en sık karşılaşılan on hata
Yüzlerce teknik denetimde tekrar eden hataları, düzeltme maliyeti ve etkisiyle birlikte sıralıyoruz. Listenin değeri, hangi işin önce yapılacağına dair önceliklendirme sağlamasıdır.
- robots.txt ile noindex'in birlikte kullanılması. Tarama engellendiği için noindex direktifi hiçbir zaman okunmaz; sayfa indekste kalmaya devam eder. Doğru sıra önce noindex ile indeksten düşürmek, düşüş doğrulandıktan sonra gerekirse taramayı kapatmaktır.
- Yönlendirme zincirleri. Üç ve daha fazla adımlı zincirlerde hem tarama bütçesi hem de link değeri erir. Tüm iç linkler nihai hedefe güncellenmeli, sunucu tarafında tek adımlı 301 kuralı bırakılmalıdır.
- Soft 404. Boş kategori veya tükenmiş ürün sayfalarının 200 dönmesi, Google'ın şablonu bütünüyle düşük değerli görmesine yol açar. Boş sonuç durumunda ya anlamlı alternatif içerik sunulmalı ya da doğru durum kodu döndürülmelidir.
- Site haritasına hatalı URL yazmak. Yönlendirilen, noindex olan veya 404 dönen URL'lerin haritada bulunması, haritanın güven değerini düşürür. Harita yalnızca 200 dönen ve indekslenmesi istenen URL'leri içermelidir.
- Canonical'ın yönlendirmeyle çelişmesi. A sayfası B'ye canonical veriyorken B'nin A'ya 301 dönmesi, çelişkili sinyal üretir ve Google kendi kararını verir.
- Tek bir dev site haritası. 50.000 URL veya 50 MB sınırına dayanan haritalar hem geç işlenir hem de hata teşhisini imkânsızlaştırır. Şablon bazlı bölünmüş haritalar (ürün, kategori, blog) kapsam raporunu okunabilir kılar.
- lastmod alanının her gece güncellenmesi. İçerik değişmediği hâlde tazelik iddiasında bulunmak, alanın tümüyle yok sayılmasına neden olur.
- JavaScript ile üretilen iç linkler. Tıklama olayına bağlı gezinme, bağlantı grafiğinde hiç var olmaz. Kritik gezinme her zaman HTML
<a href>ile sunulmalıdır. - Sunucu tarafı hataların örneklenmemesi. Ayda birkaç saat süren 5xx dalgaları, Googlebot'un tarama hızını haftalarca düşük tutabilir. İzleme yalnızca uptime değil, durum kodu dağılımı üzerinden yapılmalıdır.
- Test ortamının indekslenmesi. Kimlik doğrulaması olmayan staging alan adları, kopya içerik ve tarama israfının en pahalı kaynağıdır.
Doksan günlük uygulama planı
Tarama ekonomisi çalışması, etkiyi ölçülebilir kılmak için aşamalı yürütülür. Aşağıdaki takvim, orta ölçekli bir e-ticaret veya çok hizmetli kurumsal site için sahada test edilmiş bir sıralamadır.
0–2. hafta: teşhis
Log toplama altyapısı kurulur, 30 günlük geçmiş veri normalize edilir, tam site taraması alınır, site haritası envanteri çıkarılır. Bu aşamanın çıktısı tek bir tablodur: şablon bazında tarama payı, trafik payı ve gelir payı. Hiçbir değişiklik yapılmaz; ölçüm temeli (baseline) dondurulur.
3–5. hafta: hızlı kazanımlar
Dahili arama ve oturum parametrelerinin tarama dışına alınması, yönlendirme zincirlerinin tekilleştirilmesi, site haritalarının şablon bazında bölünmesi, staging erişiminin kapatılması. Bu kalemler düşük riskli ve geri alınabilir olduğu için önce uygulanır; log'da etkisi genellikle on gün içinde görülür.
6–9. hafta: mimari müdahaleler
Faceted navigation'ın yeniden tasarlanması, canonical politikasının şablon bazında yazılması, sayfalama stratejisinin güncellenmesi, iç link enjeksiyon kurallarının devreye alınması. Bu aşama geliştirme kaynağı gerektirir ve sürüm planına bağlanır.
10–12. hafta: performans ve doğrulama
Önbellek katmanlarının kurulması, veritabanı indekslerinin eklenmesi, koşullu istek başlıklarının açılması. Ardından ilk ölçüm temeliyle karşılaştırmalı rapor hazırlanır: tarama payı kayması, indeksleme gecikmesi, kapsam hatalarındaki değişim ve organik oturum etkisi.
Araç yığını ve maliyet dengesi
Analiz için pahalı bir kurumsal paket zorunlu değildir. Pratikte üç katman yeterlidir. Birinci katman toplama: sunucu log'ları veya CDN log push'u; Cloudflare, Fastly ve benzeri sağlayıcılar bu veriyi nesne depolamaya aktarabilir. İkinci katman işleme: log satırlarını şablonlara indirgeyen, bot doğrulaması yapan ve günlük özet üreten bir betik; Python ile birkaç yüz satırda yazılabilir, milyonlarca satırı dakikalar içinde işler. Üçüncü katman görselleştirme: zaman serisi grafikleri ve şablon bazlı tablolar; elektronik tablo düzeyinde bile karar almaya yeter.
Ticari log analiz ürünleri esas olarak kurulum süresini kısaltır ve ekip içi paylaşımı kolaylaştırır; teşhis kalitesini belirleyen ise veriyi doğru gruplara indirgemektir. Bu nedenle araç seçimini metodolojiden sonra yapmanızı öneririz. Ölçüm kültürü kurulmadan alınan araç, çoğu zaman kimsenin açmadığı bir panele dönüşür.
Yayın öncesi kontrol listesi
Kazanımı korumak için her sürüm öncesinde işletilecek kısa liste:
- Bu sürüm yeni URL deseni üretiyor mu? Üretiyorsa taranabilir olması isteniyor mu?
- Yeni şablon self canonical veriyor mu, yoksa hedefi doğru mu?
- Kaldırılan URL'ler için 301 hedefi tematik olarak en yakın sayfa mı, yoksa ana sayfaya toplu yönlendirme mi yapılıyor?
- Yeni gezinme bileşeni HTML link üretiyor mu?
- Site haritası otomatik olarak güncelleniyor mu, yalnızca 200 dönen URL'leri mi içeriyor?
- Sürüm sonrası ilk 72 saatte 5xx oranı ve medyan yanıt süresi izleniyor mu?
Bu altı soru, aylar süren teknik çalışmanın tek bir dikkatsiz sürümle geri alınmasını engeller. Tarama ekonomisi, kurulduktan sonra korunması gereken bir varlıktır; teknik SEO'nun kalıcı değeri de tam olarak bu sürekliliktedir.