E-Ticaret Crawl Budget ve Log Analizi: Googlebot Katalogda Nerede Zaman Harcıyor?

Büyük bir e-ticaret sitesinde “Google gereksiz URL’leri tarıyor” demek kolaydır. Bunu kanıtlamak ise ayrı iştir. Crawl budget problemi, yalnız URL sayısına bakarak veya crawler çıktısındaki parametre sayfalarını görerek teşhis edilmemelidir.

Önce Googlebot’un gerçekten hangi URL’lere istek gönderdiğini, bu isteklerin hangi template’lerde yoğunlaştığını, sunucunun nasıl yanıt verdiğini ve organik olarak önemli kategori ve ürün URL’lerinin yeterince keşfedilip yeniden taranıp taranmadığını ölçmek gerekir.

Bu nedenle ileri seviye e-ticaret crawl analizinde iki veri kaynağını birlikte kullanmak daha sağlıklıdır: Search Console Crawl Stats ve server access logları.

Crawl Budget Nedir?

Google crawl budget kavramını temel olarak crawl capacity ve crawl demand bileşenleri üzerinden açıklar.

• Crawl capacity, Googlebot’un siteyi sunucu sağlığını zorlamadan ne kadar tarayabileceğiyle ilgilidir.
• Crawl demand, Google’ın belirli URL’leri ne kadar taramak istediğini etkileyen talep tarafıdır.

Bu nedenle crawl budget yalnız “Google günde kaç URL tarıyor?” sorusuna indirgenmemelidir. Sunucu yanıtları, URL envanteri, duplicate veya düşük değerli URL’ler, yeniden tarama ihtiyacı ve site değişim hızı birlikte değerlendirilmelidir.

Her E-Ticaret Sitesinde Crawl Budget Problemi Var mı?

Hayır. Crawl budget çoğu küçük ve orta ölçekli sitenin ilk SEO problemi değildir.

Bu konu özellikle şu yapılarda daha anlamlı hale gelir:

• çok büyük URL envanterine sahip e-ticaret siteleri,
• ürün ve stok yapısı sık değişen mağazalar,
• facet, parametre, arama veya pagination nedeniyle çok büyük URL uzayı üreten sistemler,
• Search Console’da yüksek miktarda Discovered – currently not indexed problemi görülen yapılar,
• Googlebot isteklerinde yoğun 5xx, timeout veya yavaş yanıt problemi bulunan siteler.

Binlerce URL’li bir mağazada yalnız “crawl budget optimizasyonu yapalım” diye projeye başlamak yerine önce gerçek teknik darboğazı doğrulamak gerekir.

Search Console Crawl Stats Ne Gösterir?

Search Console Crawl Stats raporu Googlebot’un siteye yaptığı istekler hakkında ilk teşhis için yararlı bir görünüm sağlar.

Raporda proje durumuna göre şu sinyaller incelenebilir:

• toplam crawl request sayısı,
• toplam indirilen veri,
• ortalama response time,
• HTTP response code dağılımı,
• dosya türleri,
• crawl purpose,
• Googlebot türleri.

Ancak Crawl Stats URL seviyesinde eksiksiz bir server log değildir. Gösterilen URL örnekleri bütün istek envanterini temsil etmeyebilir. Bu nedenle “Googlebot hangi URL template’inde ne kadar zaman harcıyor?” sorusunu ayrıntılı cevaplamak için access log analizi daha güçlüdür.

Server Log Analizi Neden Ayrı Değer Taşır?

Server access logları sunucuya gelen gerçek HTTP isteklerini kaydeder. Doğru biçimde tutuluyorsa Googlebot’un hangi URL’ye, ne zaman, hangi status code ile ve hangi istemci bilgisiyle eriştiğini doğrudan inceleyebilirsiniz.

E-ticaret SEO açısından log analizi şu soruları cevaplamaya yardımcı olur:

• Googlebot en çok hangi URL tiplerini tarıyor?
• Kategori ve ürün sayfaları ne sıklıkta crawl ediliyor?
• Facet ve parametre URL’leri crawl talebinin büyük bölümünü alıyor mu?
• Pagination URL’leri nasıl taranıyor?
• 404, 410, 301, 302 ve 5xx URL’lerine ne kadar istek gidiyor?
• Googlebot yavaş endpoint’lerde yoğunlaşıyor mu?
• Yeni ürünler Googlebot tarafından ne kadar sürede görülüyor?
• Önemli ürün URL’leri orphan veya düşük keşfedilebilirlik nedeniyle az mı taranıyor?

Googlebot’u User-Agent ile Tek Başına Doğrulamayın

Log dosyasında user-agent alanında “Googlebot” yazması isteğin gerçekten Google’dan geldiğini kanıtlamaz. User-agent kolayca taklit edilebilir.

Googlebot analizi yapılacaksa isteklerin Google’a ait olduğunun reverse DNS veya Google’ın yayınladığı IP aralıkları gibi doğrulama yöntemleriyle kontrol edilmesi gerekir.

Bu adım özellikle güvenlik araçları, bot filtreleri veya üçüncü taraf crawler trafiğinin yoğun olduğu sitelerde önemlidir. Sahte Googlebot isteklerini gerçek crawl davranışı sanmak bütün analizi bozar.

Log Dosyasında Hangi Alanlar Gerekir?

Log formatı altyapıya göre değişir ancak teknik SEO analizi için mümkün olduğunca şu alanların tutulması yararlıdır:

• timestamp,
• client IP,
• HTTP method,
• request path veya tam URL,
• HTTP status code,
• user-agent,
• response size,
• response time veya upstream response time,
• host bilgisi.

CDN kullanılan yapılarda gerçek istemci IP’sinin hangi header üzerinden geçtiği ayrıca doğrulanmalıdır. Aksi halde bütün bot trafiği CDN IP’lerinden geliyormuş gibi görünebilir.

İlk İş: URL’leri Template’lere Ayırın

Ham log dosyasını URL listesi olarak okumak çoğu e-ticaret sitesinde işe yaramaz. Önce istekleri anlamlı URL gruplarına ayırmak gerekir.

Örnek segmentasyon:

Template	Örnek
Ana kategori	/hirdavat/
Alt kategori	/hirdavat/civata/
Ürün	/urun/m8-paslanmaz-civata/
Facet	?marka=x&olcu=m8
Pagination	?page=3
Site içi arama	/arama?q=m8+civata
Takip parametresi	?utm_source=...
404 / kaldırılmış ürün	Eski ürün URL’leri
Redirect	301 / 302 veren URL’ler

Bu ayrım yapıldığında “Googlebot çok crawl ediyor” cümlesi yerine hangi sistemin ne kadar crawl talebi ürettiği görülebilir.

Hangi Metrikleri Çıkarmalısınız?

Tek bir “crawl efficiency score” uydurmak yerine birkaç ölçümü birlikte kullanmak daha doğrudur.

1. Crawl Request Dağılımı

Toplam doğrulanmış Googlebot isteğinin URL template’lerine göre dağılımını hesaplayın.

Örneğin:

• kategori,
• ürün,
• facet,
• pagination,
• arama,
• redirect,
• 404,
• diğer parametre URL’leri.

Burada evrensel “facet yüzde 20’yi geçerse kötü” gibi eşikler yoktur. Sonuç sitenin büyüklüğü, URL mimarisi ve gerçek ürün yapısıyla yorumlanmalıdır.

2. HTTP Status Code Dağılımı

Googlebot isteklerini 200, 3xx, 4xx ve 5xx gruplarında inceleyin.

Özellikle:

• yoğun 5xx ve timeout,
• uzun redirect zincirleri,
• sürekli crawl edilen eski 404 URL’leri,
• gereksiz 302 kullanımı

teknik borcun nerede yoğunlaştığını gösterebilir.

3. Response Time

Googlebot’un eriştiği endpoint’lerde response time dağılımını URL tipine göre inceleyin.

Örneğin facet kombinasyonları dinamik sorgular nedeniyle kategori sayfalarından ciddi biçimde yavaşsa sunucu tarafındaki bu maliyet crawl kapasitesini etkileyebilir.

Yalnız ortalamaya bakmak yerine median ve yüksek gecikmeli uç değerleri de değerlendirmek daha sağlıklıdır.

4. Crawl Frequency

Aynı URL’nin belirli zaman aralığında kaç kez tarandığını hesaplayın.

Bu veri özellikle:

• sık değişen kategori sayfaları,
• stok durumu değişen ürünler,
• eski ürün URL’leri,
• parametre kombinasyonları

arasında karşılaştırma yaparken yararlıdır.

Crawl sıklığını ranking sinyali gibi yorumlamayın. Daha sık crawl edilmek otomatik olarak daha yüksek sıralama anlamına gelmez.

5. Yeni URL Discovery Süresi

Yeni ürün veya kategori URL’sinin yayın tarihi biliniyorsa ilk doğrulanmış Googlebot isteğine kadar geçen süre ölçülebilir.

Bu süre özellikle büyük kataloglarda internal linking, sitemap güncelleme hızı ve keşfedilebilirlik problemlerini araştırmak için yararlıdır.

Facet URL’lerinde Ne Aramalısınız?

Faceted navigation büyük e-ticaret sitelerinde crawl analizinin en önemli segmentlerinden biridir.

Loglarda şu pattern’leri kontrol edin:

• çok dar ürün kümeleri oluşturan filtre kombinasyonları,
• sıralama parametreleri,
• stok veya geçici kampanya filtreleri,
• aynı ürün setine ulaşan farklı parametre sıraları,
• takip parametreli facet URL’leri,
• boş sonuç döndüren kombinasyonlar.

Facet URL’lerinin gerçekten yoğun crawl edildiği doğrulanıyorsa problem artık varsayım olmaktan çıkar. Sonraki adım URL üretimi, internal linking, canonical, noindex ve gerekirse crawling kontrolünü birlikte değerlendirmektir.

Facet politikasının kendisini Faceted Navigation SEO rehberinde ayrı olarak ele alıyoruz.

Pagination Loglarda Nasıl Değerlendirilir?

Pagination URL’lerinin crawl edilmesi tek başına hata değildir. Özellikle ürünlerin yalnız ilk kategori sayfasından linklenmediği kataloglarda pagination önemli discovery yollarından biri olabilir.

Analizde şu sorular sorulmalıdır:

• Googlebot derin pagination sayfalarına erişiyor mu?
• Ürünler yalnız pagination üzerinden mi keşfediliyor?
• Pagination URL’leri yanlış canonical veya noindex nedeniyle ürün discovery’sini zayıflatıyor mu?

anlamaktır.

Sonsuz scroll ile crawl edilebilir URL yapısı arasında kopukluk var mı?

Burada amaç pagination’ı körlemesine engellemek değil, ürün keşfi içindeki gerçek rolünü

Ürün URL’lerinde Hangi Sinyaller Önemlidir?

Ürün sayfalarını aktif, stok dışı, kaldırılmış ve redirect edilen gruplara ayırmak analizi anlamlı hale getirir.

Kontrol edilebilecek noktalar:

• aktif ve gelir açısından önemli ürünler düzenli crawl alıyor mu?
• yeni ürünler uzun süre hiç taranmıyor mu?
• kalıcı olarak kaldırılmış ürünlere aylarca yoğun istek geliyor mu?
• stok dışı fakat geri gelecek ürünlerde crawl davranışı nasıl?
• varyant URL’leri ana ürün URL’sinden daha fazla crawl talebi alıyor mu?

Bu veriler ürün lifecycle ve variant SEO kararlarını gerçek Googlebot davranışıyla destekler.

Redirect ve Hata URL’lerini Ayrı Segmentleyin

Log analizinde redirect ve hata URL’lerini ürün veya kategori trafiğinin içinde bırakmak teşhisi zorlaştırır.

Özellikle:

• uzun redirect chain’leri,
• redirect loop’ları,
• eski migration URL’leri,
• kaldırılmış ürünlerin sonsuz 404 envanteri,
• 5xx üreten dinamik filtre endpoint’leri

ayrı raporlanmalıdır.

Google crawl budget rehberi de gereksiz redirect zincirlerini azaltmayı ve sunucu sağlığını korumayı önemli teknik konular arasında ele alır.

“Değersiz Crawl” Nasıl Tanımlanır?

Bir URL’nin SEO açısından değersiz olduğunu yalnız indexlenmiyor diye söylemek doğru değildir.

Örneğin bazı noindex URL’ler kullanıcı deneyimi için gerekli olabilir. Bazı pagination URL’leri ürün keşfi sağlar. Bazı redirect’lerin geçiş döneminde taranması normaldir.

Bu nedenle her template için önce görev tanımlayın:

• Organik landing page mi?
• Discovery yolu mu?
• Kullanıcı deneyimi URL’si mi?
• Geçici teknik URL mi?
• Artık hiçbir görevi olmayan legacy URL mi?

Ancak bundan sonra crawl davranışını “yararlı”, “beklenen”, “gereksiz” veya “araştırılmalı” gibi sınıflara ayırmak anlamlı hale gelir.

Log Analizi ile Search Console Verisini Nasıl Birleştirirsiniz?

En değerli analizlerden biri crawl verisini Search Console performansıyla aynı URL veya template seviyesinde karşılaştırmaktır.

Örneğin şu matris kullanılabilir:

Durum	Olası yorum
Yüksek crawl + yüksek organik değer	Beklenen davranış olabilir
Yüksek crawl + organik görevi olmayan URL	URL üretimi ve crawl yolu incelenmeli
Düşük crawl + önemli aktif ürün	Discovery, internal linking ve sitemap kontrol edilmeli
Yüksek 5xx + yüksek crawl	Sunucu veya endpoint problemi önceliklendirilmeli
Yeni URL + uzun discovery süresi	Site mimarisi ve yayın akışı incelenmeli

Örnek Teknik Teşhis Akışı

1. Search Console Crawl Stats ile genel trendi kontrol edin.
2. Analiz dönemi için server access loglarını alın.
3. Gerçek Googlebot isteklerini doğrulayın.
4. URL’leri kategori, ürün, facet, pagination, search, redirect ve hata template’lerine ayırın.
5. Request, status code ve response time dağılımlarını çıkarın.
6. Organik görev taşımayan fakat yoğun crawl alan template’leri işaretleyin.
7. Önemli fakat az crawl alan kategori ve ürün gruplarını bulun.
8. Internal linking, sitemap, canonical, robots ve URL üretim kurallarını bu bulgulara göre inceleyin.
9. Düzeltme sonrasında aynı segmentleri yeniden ölçün.

Hangi Aksiyon Hangi Bulgudan Sonra Gelir?

Bulgu	Muhtemel aksiyon alanı
Facet kombinasyonlarında yoğun crawl	Facet URL üretimi, internal linking, indexation ve crawl politikası
Search URL’lerinde yoğun crawl	Site içi arama URL politikası
Takip parametrelerinde yoğun crawl	Internal link ve URL temizliği
Uzun redirect zincirleri	Redirect haritasını sadeleştirme
Yoğun 5xx / yüksek response time	Sunucu ve uygulama performansı
Önemli ürünlerde düşük discovery	Internal linking, sitemap ve kategori mimarisi
Eski ürün 404’lerinde sürekli crawl	Lifecycle, internal link ve legacy URL temizliği

Robots.txt Kullanırken Neye Dikkat Edilmeli?

Robots.txt crawling kontrol eder; indeksleme komutu değildir. Bu nedenle bir URL grubunu bloklamadan önce Google’ın o URL’leri neden taradığını ve URL’lerin mevcut index durumunu anlamak gerekir.

Özellikle indeks dışı bırakmak istediğiniz bir URL’de yalnız noindex kullanacaksanız Googlebot’un bu etiketi görebilmesi için URL’yi crawl edebilmesi gerekir.

Bu yüzden robots.txt, noindex ve canonical aynı aracın üç farklı versiyonu gibi kullanılmamalıdır.

Log Analizinde Yapılan Yaygın Hatalar

• User-agent içinde Googlebot yazan bütün istekleri gerçek Googlebot kabul etmek.
• Bir günlük logdan büyük katalog hakkında kesin sonuç çıkarmak.
• URL’leri template’e ayırmadan yalnız toplam request sayısını yorumlamak.
• Facet crawl oranı için evrensel yüzde eşikleri uydurmak.
• Crawl sıklığını ranking sinyali sanmak.
• Yalnız robots.txt ile bütün index problemlerinin çözüleceğini düşünmek.
• Crawl Stats URL örneklerini tam access log gibi değerlendirmek.
• Ürün lifecycle ve stok durumunu hesaba katmamak.
• Sunucu response time ve 5xx hatalarını yalnız SEO ekibinin problemi sanmak.

Crawl Budget Analizini Teknik SEO Kararına Dönüştürün

İyi bir crawl budget analizi “Googlebot gereksiz sayfalarda zaman harcıyor” cümlesiyle bitmez. Hangi URL sisteminin gereksiz talep ürettiğini, hangi önemli URL’lerin yeterince keşfedilmediğini ve sunucunun Googlebot’a nasıl yanıt verdiğini kanıtlarla gösterir.

Büyük kataloglarda kategori, ürün, facet, pagination ve site içi arama URL’lerini birlikte yönetmek için E-Ticaret SEO yaklaşımını; crawling, indexation, server log, canonical ve teknik hata teşhisi için Teknik SEO kapsamını inceleyebilirsiniz.