E-Ticaret Sitelerinde Crawl Budget Nasıl Yönetilir?

Binlerce ürün, kategori, filtre, marka, varyasyon ve sayfalama URL’si bulunan bir e-ticaret sitesinde teknik SEO problemi her zaman Google’ın siteyi yeterince taramaması değildir. Asıl sorun çoğu zaman Googlebot’un hangi URL’leri taramak için kaynak harcadığıdır.

10.000 gerçek ürün URL’si bulunan bir mağaza; filtreler, sıralama parametreleri, varyasyonlar, site içi aramalar ve kombinasyon URL’leri nedeniyle taranabilir durumda yüz binlerce hatta milyonlarca adres üretebilir. Googlebot bu URL alanının önemli bölümünü düşük değerli veya birbirine çok benzeyen sayfalarda tüketiyorsa yeni ürünlerin, güncellenen kategorilerin ve ticari değeri yüksek sayfaların keşfi yavaşlayabilir.

Crawl budget yönetiminin amacı bu nedenle “Googlebot’u mümkün olduğunca fazla taramaya zorlamak” değildir.

Amaç, Google’ın tarama kaynaklarının mümkün olduğunca doğru URL envanterine yönelmesini sağlamaktır.

Bu süreç yalnızca robots.txt düzenlemekten ibaret değildir. Sağlıklı bir crawl budget yönetimi; URL üretim kuralları, filtre mimarisi, canonical yapısı, pagination, XML sitemap, HTTP durum kodları, iç linkleme, sunucu performansı ve gerektiğinde sunucu loglarının birlikte değerlendirilmesini gerektirir.

Kısa Cevap: E-Ticaret Sitesinde Crawl Budget Nasıl Yönetilir?

E-ticaret sitesinde crawl budget yönetimi için önce Google’ın taramasını istediğiniz URL envanteri belirlenmeli, ardından gereksiz URL üretimi kontrol altına alınmalıdır. Filtre ve sıralama parametreleri, yinelenen varyasyonlar, site içi aramalar, boş sonuç sayfaları, soft 404’ler ve yönlendirme zincirleri tarama kaynaklarını gereksiz yere tüketmemelidir.

Bununla birlikte önemli ürün ve kategori URL’leri gerçek HTML bağlantılarıyla erişilebilir olmalı, XML sitemap yalnızca stratejik URL’leri içermeli ve sunucu Googlebot isteklerine istikrarlı biçimde cevap verebilmelidir.

En kritik nokta şudur:

Crawl budget optimizasyonu, mümkün olan en az URL’yi taratmak değil; Google’ın doğru URL’leri doğru sıklıkta tarayabilmesini sağlamaktır.

Crawl Budget Nedir?

Crawl budget, yaygın biçimde “Google’ın bir günde sitenizde tarayabileceği maksimum sayfa sayısı” şeklinde açıklanır. Bu tanım fazla basitleştirilmiştir.

Google’ın 5 Ağustos 2026’da güncellediği resmi dokümantasyona göre crawl budget iki temel bileşenden oluşur:

Bu iki bileşen birlikte değerlendirildiğinde crawl budget, Google’ın tarayabileceği ve taramak istediği URL kümesini ifade eder.

Dolayısıyla yüksek sunucu kapasitesi tek başına daha fazla crawl anlamına gelmez. Tarama talebi düşükse Google, teknik kapasite bulunmasına rağmen siteyi daha az tarayabilir.

Aynı şekilde çok değerli ve sık güncellenen bir site bile yavaş yanıt veriyor, sık sık 5xx üretiyor veya 429 Too Many Requests gönderiyorsa tarama kapasitesi sınırı düşebilir. Google; gecikme, Time to First Byte ve sunucu cevaplarının istikrarını crawl capacity hesaplamasında dikkate aldığını açıkça belirtmektedir.

Crawl Budget ile Index Budget Aynı Şey Değildir

Tarama ve dizine ekleme birbirinden farklı süreçlerdir.

Googlebot bir URL’yi taramış olabilir ancak bu durum sayfanın Google dizinine gireceği anlamına gelmez. Google, taramadan sonra sayfanın içeriğini, benzer URL’lerle ilişkisini, canonical sinyallerini ve indekslenmeye uygunluğunu ayrıca değerlendirir.

Bu nedenle:

Tarandı → Mutlaka indexlenir

şeklinde bir ilişki yoktur.

Aynı şekilde:

Daha fazla crawl → Daha fazla organik trafik

sonucu da otomatik değildir.

Bir e-ticaret sitesinde yüz binlerce gereksiz URL’nin Googlebot tarafından başarılı şekilde taranıyor olması teknik başarı değil, aksine crawl verimsizliğinin göstergesi olabilir.

Örneğin:

/erkek-ayakkabi/
/erkek-ayakkabi/?sort=price_asc
/erkek-ayakkabi/?sort=price_desc
/erkek-ayakkabi/?view=grid
/erkek-ayakkabi/?view=list
/erkek-ayakkabi/?color=black
/erkek-ayakkabi/?color=black&size=42
/erkek-ayakkabi/?color=black&size=42&sort=price_asc

URL’lerinin tamamı aynı ürün grubunun farklı sunumlarını gösteriyorsa Googlebot’un bunların tümünü tekrar tekrar taraması çoğu site için anlamlı değildir.

Asıl soru şudur:

Bu URL gerçekten Google Arama’da bağımsız bir sonuç olarak bulunmalı mı?

Crawl politikası bu soruya verilen cevaba göre oluşturulmalıdır.

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

Hayır.

Crawl budget özellikle büyük ve sık güncellenen sitelerde önem kazanır. Google kendi ileri seviye crawl budget dokümantasyonunu özellikle haftalık değişen 1 milyondan fazla benzersiz sayfası bulunan büyük siteler, günlük değişen 10.000’den fazla benzersiz sayfası bulunan orta ve büyük siteler veya URL’lerinin önemli bölümü Search Console’da “Keşfedildi - şu anda dizine eklenmiş değil” durumunda bulunan siteler için konumlandırmaktadır.

Google bu rakamların kesin sınırlar olmadığını da özellikle belirtir.

Bu nedenle 1.500 ürünlü bir mağazada hemen “crawl budget problemi var” sonucuna varmak doğru değildir.

Ancak ürün sayısı küçük olsa bile teknik altyapı milyonlarca filtre kombinasyonu üretiyorsa incelenmesi gereken bir crawl waste problemi oluşabilir.

Crawl Budget Sorunundan Şüphelenilmesi Gereken Durumlar

Bu sinyallerden birinin görülmesi tek başına kesin teşhis değildir. Crawl budget analizi Search Console, site taraması ve gerekiyorsa sunucu logları birlikte değerlendirilerek yapılmalıdır.

E-Ticaret Sitelerinde Crawl Budget En Çok Nerede Harcanır?

E-ticaret altyapılarında crawl waste çoğu zaman ürün sayısından değil, ürünlere ulaşmak için oluşturulan alternatif URL yollarından kaynaklanır.

Örneğin 20.000 ürün bulunan bir mağazada aşağıdaki filtreler olduğunu düşünelim:

renk = 12 seçenek
beden = 15 seçenek
marka = 50 seçenek
fiyat = 10 aralık
sıralama = 5 seçenek

Bu değerlerin teorik olarak oluşturabileceği kombinasyon sayısı gerçek ürün sayısından çok daha yüksek olabilir.

Google’ın faceted navigation dokümantasyonunda da filtre parametrelerinin çok büyük, hatta pratikte sonsuza yaklaşan URL alanları oluşturabileceği ve bunun yeni, faydalı URL’lerin keşfini yavaşlatabileceği açıkça belirtilmektedir.

Crawl waste oluşturan temel URL sınıflarını şu şekilde değerlendirebiliriz:

Burada bütün parametre URL’lerini otomatik olarak zararlı kabul etmek de hatadır.

Örneğin:

/kadin-ayakkabi/siyah/
/iphone-kilif/seffaf/
/erkek-mont/sisme/

gibi filtrelerden türetilmiş ancak gerçek arama talebi bulunan sayfalar bağımsız SEO landing page olarak tasarlanabilir.

Filtrelerin teknik olarak nasıl ayrıştırılması gerektiğini E-Ticaret Sitelerinde Filtre URL’leri Nasıl Yönetilir? ve Faceted Navigation SEO Sorunları ve Çözümleri rehberlerimizde daha detaylı ele aldığımız için burada aynı konuyu tekrar etmiyoruz.

Crawl budget açısından kritik soru yalnızca şudur:

SEO değeri olmayan filtre kombinasyonları Googlebot’a sınırsız URL alanı açıyor mu?

Önce URL Envanteri Çıkarılmalıdır

Crawl budget çalışmasına robots.txt dosyasını değiştirerek başlamak çoğu zaman yanlıştır.

İlk yapılması gereken sitenin URL envanterini sınıflandırmaktır.

Örneğin 50.000 ürünlü bir mağazada teknik tarama sonucunda şu tablo ortaya çıkabilir:

Gerçek organik hedef URL sayısı yaklaşık 52.000 iken crawler 769.000’den fazla URL keşfediyorsa analiz yalnızca “kaç sayfa indexleniyor?” sorusuyla sınırlandırılamaz.

Her URL sınıfı için ayrı politika gerekir.

Crawlable, Indexable ve Canonical URL Arasındaki Fark

Teknik SEO denetimlerinde bu üç kavram sıklıkla birbirine karıştırılır.

Crawlable URL

Googlebot’un erişmesine izin verilen URL’dir.

Indexable URL

Google’ın dizine eklemesini teknik olarak engelleyen bir direktif bulunmayan URL’dir.

Canonical URL

Aynı veya çok benzer içerik grubunda tercih edilen ana URL’dir.

Örneğin:

/ayakkabi/?sort=price

crawlable olabilir ancak:

<link rel="canonical" href="https://www.ornek.com/ayakkabi/">

ile ana kategoriye canonical verebilir.

Bu durumda URL taranabilir ancak Google’a tercih edilen sürümün /ayakkabi/ olduğu sinyali gönderilir.

Canonical kullanımı, robots.txt ile aynı şey değildir.

Google canonical sinyalini bir tercih sinyali olarak değerlendirir; her durumda belirtilen URL’yi seçmek zorunda değildir. Google ayrıca duplicate URL’leri canonical URL’den genellikle daha seyrek taradığını belirtmektedir.

Bu nedenle canonical crawl yönetimine dolaylı katkı sağlayabilir ancak anlık ve kesin bir crawl engelleme mekanizması değildir.

robots.txt, noindex ve Canonical Aynı Amaçla Kullanılmaz

Crawl budget çalışmalarındaki en önemli teknik ayrımlardan biri budur.

noindex Neden Crawl Budget Çözümü Değildir?

Örneğin:

<meta name="robots" content="noindex,follow">

kullandığınızda Google’ın bu etiketi görebilmesi için URL’yi önce istemesi gerekir.

Yani süreç:

Googlebot
   ↓
URL'yi ister
   ↓
Sunucu yanıt verir
   ↓
HTML indirilir
   ↓
noindex görülür

şeklindedir.

Tarama isteği zaten gerçekleşmiştir.

Google crawl budget dokümantasyonunda yalnız crawl kaynaklarını koruma amacıyla noindex kullanılmasını önermediğini açıkça belirtmektedir. Googlebot yine URL’yi taramak zorundadır.

robots.txt Ne Zaman Kullanılabilir?

Örneğin SEO değeri bulunmayan sıralama URL’leri:

/kadin-ayakkabi/?sort=price_asc
/kadin-ayakkabi/?sort=price_desc

sitenin tamamında aynı parametre mantığıyla çalışıyorsa robots.txt seviyesinde kontrol düşünülebilir.

Basitleştirilmiş örnek:

User-agent: Googlebot
Disallow: /*?sort=

Ancak gerçek bir e-ticaret sitesinde robots.txt kuralı yalnız örneğe bakılarak eklenmemelidir.

Çünkü aynı parametre başka bir URL’de SEO açısından gerekli olabilir veya yanlış wildcard kuralı değerli URL’leri de kapatabilir.

Önemli Bir İstisna: Zaten Indexlenmiş URL

Bir URL Google dizinindeyse ve robots.txt ile hemen engellenirse Google artık sayfadaki noindex direktifini göremeyebilir.

Bu nedenle:

crawl engelleme ile index kaldırma aynı işlem değildir.

Zaten indexlenmiş binlerce parametre URL’sinin temizlenmesi gerekiyorsa önce mevcut index durumunun ve URL sınıfının değerlendirilmesi gerekir.

URL Governance Matrix Nasıl Oluşturulur?

Büyük e-ticaret projelerinde her URL için tek tek karar vermek yerine URL sınıflarına politika atanmalıdır.

Örnek bir yönetim matrisi:

Bu tablo bütün sitelere kopyalanacak evrensel bir robots politikası değildir. İş modeline, URL yapısına ve organik arama talebine göre özelleştirilmelidir.

Sonuç Üretmeyen Filtre URL’leri 200 Döndürmemeli

Filtre sistemlerindeki önemli hatalardan biri, sonuç bulunamadığında HTTP 200 OK döndürülmesidir.

Örneğin:

/ayakkabi/?renk=mor&beden=67&marka=olmayanmarka

hiç ürün üretmiyor fakat sunucu:

HTTP/1.1 200 OK

döndürüyorsa Googlebot teorik olarak benzer kombinasyonları taramaya devam edebilir.

Google’ın faceted navigation rehberi, sonuç üretmeyen veya anlamsız filtre kombinasyonlarında 404 yanıtı verilmesini açıkça önermektedir.

Doğru yaklaşım:

HTTP/1.1 404 Not Found

olabilir.

Burada amaç kullanıcıyı kötü bir hata ekranına göndermek değildir. Kullanıcı dostu bir “sonuç bulunamadı” sayfası gösterilebilir ancak HTTP cevabı gerçek durumu yansıtmalıdır.

Soft 404’ler Crawl Budget’ı Nasıl Etkiler?

Soft 404, gerçekte bulunmayan veya anlamlı içerik sunmayan bir URL’nin teknik olarak 200 OK döndürmesidir.

Örneğin kaldırılan bir ürün:

/urun/eski-model-123

açıldığında:

Bu ürün artık satılmamaktadır.

yazıyor ancak sunucu:

200 OK

döndürüyorsa Google bu URL’yi tekrar tekrar değerlendirebilir.

Google, soft 404 sayfalarının taranmaya devam ederek crawl kaynaklarını gereksiz tüketebileceğini crawl budget rehberinde özellikle belirtmektedir.

Kalıcı olarak kaldırılmış ve uygun alternatif bulunmayan URL’lerde gerçek 404 veya gerektiğinde 410 cevabı daha doğru olabilir.

Ürünün tekrar stoklanması, alternatif ürüne yönlendirme ve SEO değerinin korunması ise farklı bir karar sürecidir. Bu konuyu Stokta Olmayan Ürün Sayfaları Silinmeli mi? rehberimizde ayrıntılı olarak ele alıyoruz.

Pagination Crawl Budget Açısından Nasıl Yönetilmeli?

Pagination e-ticaret sitelerinde yanlışlıkla engellenen URL sınıflarından biridir.

Örneğin:

/kadin-ayakkabi/
/kadin-ayakkabi/?page=2
/kadin-ayakkabi/?page=3
/kadin-ayakkabi/?page=4

Google’ın daha derindeki ürünleri keşfedebilmesi için bu sayfalar önem taşıyabilir.

Google pagination dokümantasyonunda her pagination sayfasının benzersiz URL taşımasını ve her sayfanın kendi URL’sine canonical vermesini önermektedir.

Yani şu yapı önerilmez:

?page=2 canonical → /kadin-ayakkabi/
?page=3 canonical → /kadin-ayakkabi/
?page=4 canonical → /kadin-ayakkabi/

Bunun yerine:

?page=2 canonical → ?page=2
?page=3 canonical → ?page=3
?page=4 canonical → ?page=4

şeklinde self-canonical yaklaşımı kullanılabilir.

Aynı zamanda sayfalar arasında gerçek <a href> bağlantıları bulunmalıdır.

Örneğin:

<a href="/kadin-ayakkabi/?page=2">2</a>
<a href="/kadin-ayakkabi/?page=3">3</a>
<a href="/kadin-ayakkabi/?page=4">4</a>

Google tarayıcıları çoğunlukla <a> elementinin href özelliğinde bulunan URL’leri keşfeder. Yalnız JavaScript ile çalışan “daha fazla yükle” veya infinite scroll sistemlerinde Googlebot kullanıcı gibi butona basmayabilir.

Infinite Scroll Kullanılıyorsa Ne Yapılmalı?

Kullanıcı deneyimi için infinite scroll kullanılabilir.

Ancak:

Sayfa ilk açılır
↓
20 ürün gelir
↓
Kullanıcı scroll yapar
↓
JavaScript sonraki 20 ürünü getirir

şeklindeki yapı, sonraki ürünlere başka bir taranabilir yol yoksa keşif problemi oluşturabilir.

Arka planda şu tür URL’ler bulunabilir:

/kategori?page=1
/kategori?page=2
/kategori?page=3

ve bunlara crawlable bağlantılar sağlanabilir.

Kullanıcı infinite scroll görürken arama motoru sağlıklı bir pagination mimarisi üzerinden ürünleri keşfedebilir.

Site İçi Arama URL’leri Kontrol Edilmeli

Site içi arama sistemleri crawl budget açısından tehlikeli olabilir.

Örneğin:

/arama?q=ayakkabi
/arama?q=siyah+ayakkabi
/arama?q=siyah+ayakkabi+42
/arama?q=abc
/arama?q=abc123

şeklinde teorik olarak sınırsız URL oluşturulabilir.

Üstelik botlar veya kullanıcılar rastgele sorgular üretmeye başladığında bu URL’ler internal link, referer veya başka kaynaklar üzerinden keşfedilebilir.

Site içi arama URL’lerinin normal kategori mimarisinin alternatifi olmaması gerekir.

Google da e-ticaret site mimarisi rehberinde Googlebot’un genellikle arama kutularına sorgu göndererek ürün keşfetmediğini ve indexlenmesi istenen ürünlere navigasyon üzerinden gerçek bağlantılar verilmesini önermektedir.

Ürün Varyasyonları Crawl Budget’ı Nasıl Etkiler?

Bir ürünün:

/urun/model-x

ana URL’si bulunurken renk ve beden seçenekleri:

/urun/model-x?color=black
/urun/model-x?color=white
/urun/model-x?color=black&size=38
/urun/model-x?color=black&size=39
/urun/model-x?color=black&size=40

şeklinde URL üretiyorsa tek ürün onlarca taranabilir URL’ye dönüşebilir.

Ancak bütün varyasyon URL’lerinin kapatılması da doğru değildir.

Örneğin farklı renk veya model gerçekten farklı arama talebine, farklı ürün verisine ve bağımsız landing page değerine sahipse ayrı URL stratejisi kurulabilir.

Bu nedenle varyasyon yönetimi crawl budget kararından önce ürün mimarisi kararıdır.

Renk, beden ve model URL’lerinin ne zaman ayrı sayfa olması gerektiğini Ürün Varyasyonları SEO: Renk, Beden ve Model URL’leri Nasıl Yönetilmeli? rehberimizde detaylandırıyoruz.

XML Sitemap Crawl Budget Yönetiminde Nasıl Kullanılır?

XML sitemap’in görevi Google’a sitenin bütün teknik URL’lerini göstermek değildir.

Sitemap mümkün olduğunca Google tarafından keşfedilmesini ve değerlendirilmesini istediğiniz URL envanterini temsil etmelidir.

Örneğin aşağıdaki URL sitemap’e eklenmemelidir:

/kadin-ayakkabi/?sort=price

eğer bu URL’nin bağımsız olarak indexlenmesini istemiyorsanız.

Buna karşılık:

/kadin-ayakkabi/
/erkek-ayakkabi/
/urun/model-x
/urun/model-y

gibi ana SEO URL’leri sitemap içerisinde bulunabilir.

Büyük projelerde sitemap’ler URL sınıfına göre ayrılabilir:

/sitemap-products-1.xml
/sitemap-products-2.xml
/sitemap-categories.xml
/sitemap-brands.xml
/sitemap-blog.xml

Bu yapı yalnız dosyaları düzenli tutmaz; Search Console üzerinden hangi URL grubunda indeksleme veya keşif problemi olduğunu analiz etmeyi de kolaylaştırır.

Google ayrıca değişen içeriklerde doğru <lastmod> bilgisinin kullanılmasını önermektedir.

Ancak <lastmod> değerinin her crawl sırasında otomatik olarak bugünün tarihine çevrilmesi doğru değildir. Gerçek içerik değişimini temsil etmelidir.

Sitemap İçinde Olmak İç Linkleme Yerine Geçmez

XML sitemap önemli bir keşif kaynağıdır ancak site mimarisinin alternatifi değildir.

Google’ın e-ticaret dokümantasyonunda önerilen yapı temelde şöyledir:

Ana Sayfa
   ↓
Kategori
   ↓
Alt Kategori
   ↓
Ürün

Google bir sayfanın site içindeki önemini değerlendirirken URL klasöründen çok sayfalar arasındaki gerçek bağlantıları analiz eder. Kategori sayfalarının ürünlere bağlantı vermemesi durumunda Googlebot bütün ürünleri yalnız tarama yoluyla bulamayabilir.

Bu konu crawl budget ile doğrudan ilişkilidir.

Googlebot’un:

Ana sayfa → kategori → alt kategori → ürün

şeklinde net bir yol üzerinden değerli URL’lere erişmesi, rastgele filtre URL’leri arasında ürün keşfetmeye çalışmasından daha sağlıklıdır.

Detaylı site bağlantı mimarisini E-Ticaret Sitesinde İç Linkleme Nasıl Yapılır? rehberimizde ayrıca ele alıyoruz.

Orphan Ürünler Crawl Budget Problemi midir?

Doğrudan her orphan ürün crawl budget problemi değildir.

Ancak şu durum önemlidir:

Ürün sitemap'te var
↓
Site içerisinde hiçbir gerçek link almıyor
↓
Google ürünü sitemap'ten keşfediyor
↓
Ürünün site mimarisindeki önemi zayıf

Bu yapı binlerce üründe tekrar ediyorsa sorun yalnız crawl budget değil, site mimarisi problemidir.

Sitemap’e daha fazla URL eklemek yerine ürünlerin doğru kategori ve alt kategorilere bağlanması gerekir.

Redirect Chain’ler Temizlenmeli

Örneğin eski ürün URL’si:

/urun/model-a

şuraya yönleniyor:

/urun/model-a-yeni

o da:

/urun/model-a-2026

adresine gidiyorsa:

A → 301 → B → 301 → C

şeklinde redirect chain oluşur.

Eski URL hâlâ iç linklerde ve sitemap’te bulunuyorsa Googlebot gereksiz yönlendirme adımlarından geçmek zorunda kalır.

Doğru yapı mümkün olduğunda:

A → 301 → C

olmalıdır.

Ayrıca site içindeki bağlantılar doğrudan:

C

URL’sine güncellenmelidir.

Google crawl budget rehberinde uzun redirect chain’lerinden kaçınılmasını açıkça önermektedir.

Sunucu Performansı Crawl Budget’ı Etkiler mi?

Evet.

Crawl budget yalnız SEO etiketlerinden oluşan bir konu değildir. Sunucunun Googlebot isteklerine nasıl cevap verdiği de önemlidir.

Google, crawl capacity limit hesaplanırken özellikle cevap sürelerini ve sunucu sağlığını değerlendirir.

Örneğin sunucu:

200 OK → 180 ms
200 OK → 220 ms
200 OK → 190 ms

gibi istikrarlı cevap verirken başka bir sistemde:

200 OK → 2.8 sn
503 → hata
200 OK → 4.1 sn
429 → rate limit
500 → hata

şeklinde davranıyorsa Google’ın tarama kapasitesi aynı olmayabilir.

Google; gecikme ve TTFB yükseldiğinde, 5xx cevapları oluştuğunda veya 429 gibi rate limiting sinyalleri geldiğinde crawl capacity limit’in düşebileceğini belirtmektedir.

Bu nedenle büyük e-ticaret sitelerinde crawl budget optimizasyonu bazen SEO ekibinden önce backend ve DevOps ekibini ilgilendirir.

304 Not Modified Kullanımı Neden Önemlidir?

Değişmeyen içeriklerde HTTP caching kullanılabilir.

Google’ın son ziyaretinden beri içerik değişmediyse uygun koşullarda:

HTTP/1.1 304 Not Modified

cevabı sunucunun sayfanın tamamını yeniden göndermesine gerek olmadığını belirtebilir.

Google crawl budget dokümantasyonu 304 Not Modified desteğinin sunucu bant genişliği ve kaynak tüketimini azaltabileceğini belirtmektedir.

Bu özellikle yüz binlerce URL’nin düzenli olarak yeniden kontrol edildiği büyük mağazalarda önem kazanır.

JavaScript E-Ticaret Sitelerinde Crawl Problemi Oluşturabilir mi?

JavaScript kullanılması tek başına SEO problemi değildir.

Problem, kritik bağlantıların yalnız kullanıcı etkileşimiyle oluşmasıdır.

Örneğin:

<div onclick="loadProduct(123)">Ürünü Gör</div>

yerine taranabilir bağlantı:

<a href="/urun/model-123">Ürünü Gör</a>

daha açıktır.

Google’ın e-ticaret ve pagination dokümanları, ürün keşfi için <a href> tabanlı gerçek bağlantıların kullanılmasını özellikle önermektedir.

Next.js, React, Vue veya özel SPA altyapılarında bu ayrım özellikle kontrol edilmelidir.

Crawl Waste Nasıl Ölçülür?

Search Console Crawl Stats genel tabloyu gösterir ancak büyük sitelerde tek başına yeterli olmayabilir.

Gerçek Googlebot davranışını görmek için sunucu access logları analiz edilebilir.

Basitleştirilmiş log satırı şöyle görünebilir:

66.249.xx.xx - - [24/Aug/2026:09:43:12 +0300]
"GET /kadin-ayakkabi/?sort=price HTTP/1.1" 200 28431
"Googlebot/2.1"

Log analizinde URL’ler sınıflara ayrılabilir:

Bu tabloda Googlebot isteklerinin %50’sine yakını SEO açısından düşük değerli filtre, sort ve arama URL’lerine gidiyorsa crawl politikası incelenmelidir.

Crawl Waste Ratio

Denetim sırasında yardımcı bir iç metrik olarak şu oran kullanılabilir:

Crawl Waste Ratio =
Gereksiz URL'lere yapılan Googlebot istekleri
───────────────────────────────────────────── × 100
Toplam Googlebot istekleri

Örneğin:

Toplam Googlebot isteği: 200.000
Gereksiz URL isteği:      80.000

Crawl Waste Ratio = %40

Buradaki Crawl Waste Ratio Google’ın resmi metriği değildir. Teknik SEO denetiminde URL sınıfları arasında kaynak dağılımını karşılaştırmak için kullanılabilecek operasyonel bir göstergedir.

Asıl değer, zaman içerisindeki değişimi ölçmektir.

Örneğin:

Mart   %42
Nisan  %31
Mayıs  %18

şeklinde düşüş görülürken ürün ve kategori crawl frekansı artıyorsa uygulanan URL politikalarının etkisi daha net değerlendirilebilir.

Googlebot Olduğunu Nasıl Doğrularız?

Log dosyasında User-Agent alanında “Googlebot” yazması isteğin gerçekten Google’dan geldiğini garanti etmez.

Kötü niyetli botlar User-Agent bilgisini taklit edebilir.

Bu nedenle ciddi log analizlerinde Google crawler doğrulaması DNS veya Google’ın önerdiği diğer doğrulama yöntemleriyle yapılmalıdır.

Aksi takdirde sahte bot trafiği crawl analizini bozabilir.

Crawl Budget Denetiminde Search Console Nasıl Kullanılır?

Search Console üç farklı açıdan yardımcı olur.

Crawl Stats, Googlebot’un siteye yaptığı istek hacmi, cevap kodları ve host durumları hakkında genel sinyal verir.

Page Indexing, hangi URL’lerin neden indekslenmediğini gösterir.

URL Inspection ise tekil URL seviyesinde Google’ın URL’yi nasıl değerlendirdiğini anlamaya yardımcı olur.

Ancak Search Console’daki toplam crawl sayısı tek başına “iyi” veya “kötü” değildir.

Örneğin:

100.000 crawl / gün

çok iyi görünebilir.

Fakat bunun:

80.000'i filtre
10.000'i sort
5.000'i arama
5.000'i gerçek ürün/kategori

olduğu ortaya çıkarsa problem vardır.

Bu nedenle sayıdan önce crawl dağılımı incelenmelidir.

Platformlara Göre Crawl Budget Problemleri

Crawl budget problemi platformdan çok uygulamanın nasıl yapılandırıldığıyla ilgilidir. Bununla birlikte farklı e-ticaret altyapılarında karakteristik riskler görülebilir.

Özel yazılım altyapılarında en büyük avantaj URL üretim kurallarına doğrudan müdahale edilebilmesidir.

En büyük risk ise kontrolsüz geliştirilen filtre sisteminin SEO ekibi fark etmeden sınırsız URL oluşturabilmesidir.

Crawl Budget Karar Ağacı

Bir URL sınıfıyla karşılaşıldığında karar şu mantıkla verilmelidir:

URL gerçek bir arama niyetini karşılıyor mu?
│
├── Evet
│ ↓
│ Benzersiz ve yeterli içerik var mı?
│ │
│ ├── Evet → Crawl + Index değerlendir
│ │ ↓
│ │ Self canonical
│ │ ↓
│ │ İç link + gerekirse sitemap
│ │
│ └── Hayır → Ana URL ile birleştirme /
│ canonical stratejisini değerlendir
│
└── Hayır
↓
Google'ın URL'yi taraması gerekiyor mu?
│
├── Evet → Crawl açık, index politikası belirle
│
└── Hayır → URL üretimini veya crawl erişimini sınırla

Burada karar verirken “SEO eklentisi ne öneriyor?” yerine URL’nin gerçek fonksiyonu değerlendirilmelidir.

Crawl Budget Yönetiminde Sık Yapılan Hatalar

En tehlikeli hata bütün problemli URL’leri tek robots.txt kuralıyla kapatmaya çalışmaktır.

Örneğin:

Disallow: /*?

gibi agresif bir kural parametre kullanan değerli pagination veya SEO landing page URL’lerini de etkileyebilir.

Bir diğer hata bütün filtre URL’lerine ana kategori canonical’ı vermek ve sorunun çözüldüğünü düşünmektir.

Canonical zaman içinde duplicate crawl’ı azaltmaya yardımcı olabilir ancak URL’nin taranmasını anında engellemez.

Aynı şekilde yalnız sitemap’i temizlemek de URL’nin ortadan kalkmasını sağlamaz. URL iç bağlantılarda veya faceted navigation sisteminde üretilmeye devam ediyorsa Google yeniden keşfedebilir.

Crawl budget çalışmasının temel prensibi bu nedenle şudur:

Sinyalleri değil, mümkün olduğunca URL üretim kaynağını düzeltin.

E-Ticaret Crawl Budget Audit Kontrol Listesi

• Gerçek ürün, kategori, marka ve landing page URL sayıları çıkarıldı.
• Crawler tarafından keşfedilen toplam URL sayısı gerçek SEO URL envanteriyle karşılaştırıldı.
• Filtre parametreleri sınıflandırıldı.
• SEO değeri olan ve olmayan filtre URL’leri ayrıldı.
• Sort ve görünüm parametreleri kontrol edildi.
• Site içi arama URL’lerinin taranabilirliği incelendi.
• Ürün varyasyonlarının URL üretim modeli analiz edildi.
• Pagination URL’leri crawlable durumda kontrol edildi.
• Pagination sayfalarında self-canonical doğrulandı.
• Infinite scroll arkasında crawlable URL yapısı kontrol edildi.
• robots.txt kuralları değerli URL’leri yanlışlıkla kapatıyor mu incelendi.
• noindex yalnız crawl budget kazanmak amacıyla kullanılıyor mu kontrol edildi.
• Canonical hedeflerinin tutarlı olduğu doğrulandı.
• XML sitemap yalnız stratejik URL’ler açısından incelendi.
• <lastmod> değerlerinin gerçek değişiklikleri temsil ettiği kontrol edildi.
• Soft 404 URL’leri temizlendi.
• Kalıcı kaldırılmış sayfalarda doğru HTTP durum kodları doğrulandı.
• Redirect chain ve loop’lar tarandı.
• İç linklerin doğrudan canonical URL’lere gittiği kontrol edildi.
• Orphan ürün ve kategoriler tespit edildi.
• 5xx ve 429 cevap oranları kontrol edildi.
• TTFB ve sunucu cevap süreleri analiz edildi.
• Gerekliyse Googlebot access log analizi yapıldı.
• Googlebot hitleri URL sınıflarına ayrıldı.
• Optimizasyon sonrasında crawl dağılımı tekrar ölçüldü.

Crawl Budget Optimizasyonundan Sonra Ne Ölçülmeli?

Başarılı bir çalışma yalnız toplam crawl sayısını düşürmek veya artırmakla ölçülmemelidir.

Asıl bakılması gereken değişim şudur:

Önce:
Googlebot → filtre → filtre → sort → arama → ürün

Sonra:
Googlebot → kategori → ürün → yeni ürün → önemli kategori

Yani kaynakların dağılımı değişmelidir.

Optimizasyon sonrasında yeni ürünlerin keşif süresi, önemli kategorilerin yeniden taranma sıklığı, Googlebot’un düşük değerli URL’lerde harcadığı hit oranı, soft 404/redirect miktarı, server error oranları ve “Keşfedildi - şu anda dizine eklenmiş değil” URL trendi birlikte takip edilmelidir.

Crawl Budget Yönetimi Ne Zaman Profesyonel Teknik SEO Gerektirir?

Birkaç yüz sayfalık standart bir mağazada çoğu crawl problemi temel teknik kontrollerle çözülebilir.

Ancak URL envanteri yüz binlere ulaştığında konu yalnız SEO ayarı olmaktan çıkar.

Özellikle:

Ürün veritabanı
       ↓
URL router
       ↓
Faceted navigation
       ↓
Canonical sistemi
       ↓
robots.txt
       ↓
Sitemap generator
       ↓
Internal linking
       ↓
Cache / CDN / Server
       ↓
Googlebot

zincirinin tamamı birlikte değerlendirilmelidir.

Bir katmanda yapılan yanlış değişiklik diğer bütün sistemi etkileyebilir.

Örneğin yalnız SEO ekibi robots.txt değiştirirken yazılım tarafı aynı anda yeni filtre URL’leri üretmeye devam ediyorsa problem kalıcı olarak çözülmez.

Optimia’da e-ticaret projelerini yalnız içerik veya anahtar kelime tarafından değerlendirmiyoruz. Yazılım altyapısı, URL üretim mekanizması, filtre sistemi, sunucu cevapları, tarama davranışı ve organik ticari hedefleri aynı teknik mimari içerisinde ele alıyoruz.

Çok sayıda ürün, kategori veya dinamik URL bulunan bir mağazada Google’ın değerli sayfalara geç ulaştığını düşünüyorsanız E-Ticaret SEO hizmetimizi inceleyebilir; URL mimarisi ve crawl problemlerinin teknik olarak analiz edilmesini talep edebilirsiniz.

Crawl Budget Bir Robots.txt Problemi Değil, URL Mimarisi Problemidir

E-ticaret sitelerinde crawl budget yönetimini yalnızca Googlebot’un günlük tarama sayısıyla değerlendirmek eksik kalır.

Asıl mesele sitenin Google’a nasıl bir URL evreni sunduğudur.

50.000 ürün bulunan bir mağaza Google’a 50.000–100.000 anlamlı URL sunabileceği gibi yanlış filtre, parametre ve varyasyon mimarisi nedeniyle milyonlarca gereksiz URL de sunabilir.

İyi tasarlanmış bir sistemde:

Gerçek ürünler
+ gerçek kategoriler
+ değerli landing page'ler
+ kontrollü pagination
+ doğru varyasyonlar
= anlaşılır URL envanteri

oluşturulur.

Kötü tasarlanmış sistemde ise:

ürün
× filtre
× beden
× renk
× marka
× sort
× view
× pagination
× arama
= kontrolsüz URL alanı

ortaya çıkar.

Crawl budget optimizasyonunun gerçek görevi bu iki yapı arasındaki farkı yönetmektir.

Googlebot’a yalnızca “burayı tarama” demek yerine; neden gereksiz URL üretildiğini, hangi URL’nin organik arama değeri taşıdığını ve e-ticaret altyapısının Google’a nasıl daha temiz bir site mimarisi sunabileceğini çözmek gerekir. Teknik SEO ile yazılım bilgisinin kesiştiği nokta tam olarak burasıdır.