Tüm Yazılımlarda Net %50 İndirim. Detayları İncele >

E-Ticaret Tarama Bütçesi Yönetimi Rehberi

E-Ticaret Tarama Bütçesi Yönetimi Rehberi

Binlerce ürün, varyant ve filtre kombinasyonu olan mağazalarda arama motoru her URL’yi aynı hızda ve aynı sıklıkta ziyaret etmez. E-ticaret tarama bütçesi, botun sitenizde harcayabileceği sınırlı tarama kapasitesinin hangi sayfalara gittiğini yönetmek demektir. Amaç garanti sıralama değil; stok, parametre ve düşük değerli adreslere giden payı kesip ürün ile kategori sayfalarını daha sık ve sağlıklı taranır hale getirmektir. Bu rehber sitemap veya filtre mimarisine girmeden log, robots ve parametre kararlarıyla uygulanabilir bir çerçeve sunar.

E-ticaret tarama bütçesi nedir, kimleri etkiler?

Tarama bütçesi, arama motorunun bir siteyi belirli bir sürede ne kadar tarayabileceğini ve hangi URL’lere öncelik vereceğini ifade eden pratik bir kavramdır. Resmi olarak her site için sabit bir “kota paneli” yoktur; sunucu yanıt kalitesi, site boyutu, URL keşfi ve içeriğin güncellenme sıklığı birlikte davranışı şekillendirir.

Küçük vitrinlerde (yüzlerce URL) bütçe genelde darboğaz olmaz. Asıl risk şuralarda büyür:

  • On binlerce SKU, renk-beden varyantı ve otomatik üretilen URL’ler
  • Filtre, sıralama ve oturum parametrelerinin indekse açık kalması
  • Stokta yok, arşivlenmiş veya neredeyse aynı içerikli sayfaların yoğun iç link alması
  • Yavaş yanıt, sık 5xx veya gereksiz yönlendirme zincirleri

KOBİ ölçeğinde bile katalog hızla büyüyorsa botun zamanını “keşfedilebilir ama satmayan” sayfalara harcaması, yeni ürün veya güncellenen kategori sayfalarının geç fark edilmesine yol açabilir. Kurumsal kataloglarda bu etki daha belirgindir.

Crawl israfı yaratan tipik kaynaklar

Israf, botun taramaya değer görmediğiniz veya indekslenmesini istemediğiniz URL’lere tekrar tekrar gelmesiyle oluşur. E-ticarette en sık görülen kaynaklar şunlardır.

Parametre ve oturum URL’leri

Sıralama (sort=price), sayfa boyutu, renk-beden filtre kombinasyonları, utm_ ve izleme parametreleri, sepet veya oturum kimlikleri aynı ürün listesini onlarca kopya URL olarak üretir. Bot bunları ayrı adres sanırsa tarama payı parçalanır.

Etiket, arama sonuçları ve “ince içerik” listeleri

Otomatik etiket sayfaları, site içi arama sonuçları ve “benzer ürün” üreten zayıf şablonlar genelde ince veya yinelenen içerik taşır. Keşfedilebilir olduklarında ürün sayfalarından tarama dikkatini çalarlar.

Stok ve yaşam döngüsü gürültüsü

Sürekli stokta yok kalan, kısa ömürlü kampanya veya kopya ürün kartları botu eski sinyallere bağlar. Burada amaç stok politikasını anlatmak değil; tarama açısından hangi URL’lerin hâlâ “canlı ve öncelikli” sayılacağını netleştirmektir.

Yönlendirme ve hata gürültüsü

301 zincirleri, 302 ile kalıcı gibi davranan geçici yönlendirmeler, 404/410 karışıklığı ve yavaş 5xx yanıtları botun işini zorlaştırır. Her başarısız istek fiilen bütçeden düşer.

Sunucu loglarıyla tarama davranışını okuma

Google Search Console faydalıdır ama “hangi bot, hangi URL’ye, hangi HTTP koduyla, ne sıklıkta geldi?” sorusunun en net cevabı sunucu erişim loglarındadır. Büyük kataloglarda e-ticaret tarama bütçesini yönetmek istiyorsanız log analizi varsayım değil, periyodik bir iş haline gelmelidir.

Ne toplamalısınız?

  • Zaman damgası, istek yolu (path + query), HTTP durum kodu, yanıt boyutu, yanıt süresi
  • User-Agent (Googlebot, diğer botlar, tarayıcı ayrımı)
  • Mümkünse referrer ve host (çok domain / alt domain senaryolarında)

Nasıl okursunuz?

  1. Yalnızca arama botu satırlarını filtreleyin; insan trafiğini karıştırmayın.
  2. En çok istek alan path ve query desenlerini gruplayın (ör. ?color=, ?sort=, /search?).
  3. 2xx / 3xx / 4xx / 5xx dağılımını çıkarın. Yüksek 3xx ve 5xx tarama verimsizliğidir.
  4. Ürün ve kategori path’lerinin toplam bot istekleri içindeki payını ölçün. Düşükse israf yüksektir.
  5. Yeni eklenen ürün URL’lerinin ilk bot ziyaretine kadar geçen süreyi örnekleyin (keşif gecikmesi göstergesi).

Haftalık veya iki haftalık bir log kesitiyle “botun vakit geçirdiği ilk 50 desen” listesi çıkarmak çoğu ekipten daha net öncelik üretir. HazırSoft tarafında teknik altyapı ve panel kararlarını bu verilere bağlamak, rastgele robots kuralı eklemekten daha sağlıklıdır.

Robots.txt, noindex ve URL parametre karar matrisi

Üç araç farklı iş yapar. Birini diğerinin yerine kullanmak sık görülen hatadır.

AraçNe yapar?Ne zaman tercih edilir?Dikkat
robots.txt DisallowBotun URL’ye istek atmasını engellemeye çalışırAçıkça değersiz, yüksek hacimli parametre/arama/admin yollarıZaten indekste olan URL’yi tek başına temizlemez; yanlış kural kritik sayfayı kapatabilir
noindex (meta veya header)Sayfanın indeksten çıkarılmasını ister; tarama genelde devam edebilirKeşfedilebilir ama indekslenmemesi gereken ince/etiket/arama sayfalarınoindex’in işe yaraması için sayfanın taranabilir olması gerekir; Disallow + noindex çakışması sık hatadır
Parametre / URL standardıGereksiz query’leri üretmemek, tek kanonik adrese toplamakFiltre-sıralama kopyaları, izleme parametreleri, oturum kimlikleriKök çözüm üretim tarafındadır; yalnızca meta ile “temizlenmiş gibi” görünmek yetmez

Karar adımları

  1. Önce üretimi kısın: Oturum ID’sini URL’ye yazmayın. Sıralama ve sayfalama için tek, tutarlı bir adres kuralı seçin. Gereksiz kombinasyonları oluşturmayın.
  2. İndeks istemediğiniz ama link alabilen sayfalar: noindex kullanın; tarama devam edebilir, indekse girmesini istemezsiniz.
  3. Botun hiç uğramasını istemediğiniz yüksek hacimli çöplük: robots.txt ile path/query desenini kapatmayı değerlendirin (ör. site içi arama sonuçları, belirli admin veya export yolları).
  4. Aynı içeriğin birden fazla adresi: Tercih edilen URL’yi netleştirin; yönlendirme ve kanonik sinyali tutarlı olsun. Bu rehber canonical makalesinin yerini tutmaz; parametre kararında “hangi adres yaşayacak?” sorusunu net bırakmanız yeterlidir.
  5. Test: Kural sonrası logda o desene bot isteği düşüyor mu, Search Console’da kapsama/hata davranışı değişiyor mu bakın. Körü körüne kural birikimi yeni israf üretir.

Örnek mantık (kod değil, politika): /search sonuçları noindex veya Disallow adayıdır; anlamlı bir kategori path’i açık kalır. ?utm_ izleme parametreleri kanonik/üretim tarafında temizlenir; ürün detay path’i engellenmez. Stokta yok ürün için site geneli “hepsini kapat” yerine log ve iş kuralına göre sayfa saklama, yönlendirme veya kaldırma seçilir—bu karar tarama payını da etkiler.

Öncelikli sayfaları güçlendirme

Bütçeyi kesmek tek başına yetmez; botun gideceği yerleri de netleştirmek gerekir. Öncelik genelde şunlardadır: para kazandıran ürün kartları, güçlü kategori hub’ları, sık güncellenen koleksiyonlar ve kritik bilgilendirme sayfaları.

  • İç link ağırlığı: Ana menü, footer, kategori ağacı ve ürün–ürün / kategori–ürün köprüleriyle taranabilirliği yüksek sayfalara bağ kurun. Dağınık ve rastgele linkler yerine hub mantığı işe yarar; detaylı mimari için iç linkleme stratejisi rehberine bakabilirsiniz.
  • Yanıt kalitesi: Öncelikli path’lerde hızlı 200, kısa yönlendirme zinciri ve düşük 5xx oranı hedefleyin. Yavaş sunucu tarama isteğini dolaylı cezalandırır.
  • Güncelleme sinyali: Gerçekten değişen stok, fiyat veya içerik güncellemelerini şişirmeden yansıtın. Sahte “her gün değişti” gürültüsü güven kırar.
  • Keşif yüzeyi: Yeni ürünlerin yalnızca parametreli listelerde değil, taranabilir kategori ve ilgili ürün bloklarında görünmesini sağlayın.

İçerik tarafında zayıf veya yinelenen şablonları ayıklamak da dolaylı bütçe yönetimine girer. Kapsamlı bir envanter için SEO içerik denetimi yaklaşımı ürün açıklamaları ve kategori metinlerini tarama önceliğiyle birlikte ele almanıza yardımcı olur.

Ölçüm metrikleri ve kontrol ritmi

Yönetmediğiniz şeyi iyileştiremezsiniz. Aşağıdaki metrikler “sıralama garantisi” değil; tarama sağlığı göstergesidir.

  • Bot istek payı: Ürün + kategori path’lerinin toplam Googlebot istekleri içindeki oranı (log)
  • Parametre/arama istek payı: Query ve search desenlerinin bot trafiğindeki yüzdesi (düşmesi genelde iyidir)
  • Durum kodu sağlığı: Bot isteklerinde 2xx oranı; 3xx zinciri ve 5xx frekansı
  • Keşif gecikmesi: Yeni ürün URL’sinin logda ilk bot isteğine kadar geçen süre (örneklem)
  • Kapsama dengesi: Search Console’da “taranan ama indekslenmeyen” ve hata kümelerinin trendi
  • Öncelikli URL taranma sıklığı: Seçilmiş 20–50 kritik ürün/kategori için periyodik bot ziyaret aralığı

Önerilen ritim: log özeti iki haftada bir; robots/parametre kural değişikliklerinden sonra bir hafta izleme; büyük katalog aktarımı veya filtre motoru değişikliğinde ekstra kesit. Tek seferlik “temizlik günü” yerine küçük, ölçülen iterasyonlar daha güvenlidir.

Uygulama kontrol listesi

  1. Son 7–14 gün logundan bot isteklerini süzün; en çok taranan 50 deseni listeleyin.
  2. Ürün/kategori dışındaki yüksek hacimli desenleri israf adayı işaretleyin.
  3. Her aday için karar verin: üretimi kes / noindex / robots Disallow / yönlendir / olduğu gibi bırak.
  4. Kuralı staging veya sınırlı path’te deneyin; sonra log ve Search Console ile doğrulayın.
  5. Öncelikli sayfalara iç link ve yanıt kalitesi yatırımı yapın.
  6. İki hafta sonra bot istek payı ve keşif gecikmesini yeniden ölçün; kuralı gevşetin veya sıkılaştırın.

Büyük kataloglarda e-ticaret tarama bütçesi, tek bir sihirli dosya değil; üretim kuralları, erişim kontrolü ve ölçüm disiplininin birleşimidir. Parametre ve düşük değerli sayfalara giden payı bilinçli kestiğinizde botun zamanı ürün ve kategori tarafında daha verimli harcanır. Altyapı, URL mimarisi veya panel tarafında tutarlı bir yapı kurmak isteyen ekipler HazırSoft’un e-ticaret ve web çözümleriyle teknik temeli sadeleştirip bu kararları uygulamaya dökebilir; sonraki adım olarak kendi log kesitinizden ilk israf listesini çıkarmak çoğu mağaza için en somut başlangıçtır.

Yorumlar (0)
Yorum bırakmak için giriş yapın veya hesap oluşturun

Deneyiminizi kişiselleştirmek için çerezler kullanıyoruz. Bu web sitesini ziyaret etmeye devam ederek çerez kullanımımızı kabul etmiş olursunuz

Daha Fazla