Bir e-ticaret mağazasında 200 ürünü yönetmek ile 20.000 SKU'yu yönetmek aynı problem değildir.
Ürün sayısı arttıkça asıl sorun “ürünleri sisteme yüklemek” olmaktan çıkar. Kategori mimarisi, filtre kombinasyonları, URL üretimi, pagination, internal linking, crawl budget, arama ve veri modeli birlikte çözülmesi gereken bir storefront problemine dönüşür.
SKU sayısı neden mimariyi değiştirir?
Bir ayakkabı mağazasında marka, kategori, cinsiyet, renk, beden, fiyat ve materyal filtreleri varsa kombinasyon sayısı hızla büyür.
Her filtre kombinasyonunu indexlenebilir hale getirmek katalog büyüdükçe ciddi teknik SEO problemi yaratabilir.
Kategori ile filtre aynı şey değildir
Kategori, mağazanın kalıcı bilgi mimarisinin parçasıdır.
Filtre, mevcut ürün kümesini daraltan kullanıcı aracıdır.
SEO değeri bulunan kombinasyon landing page olabilir; yalnız kullanıcıya yardımcı olan operasyonel filtre ise filtre state'i olarak kalabilir.
Faceted navigation neden tehlikelidir?
Her seçim yeni crawlable URL oluşturuyorsa aynı ürün kümesinin yüzlerce varyasyonu ortaya çıkabilir.
Bu durum:
- duplicate veya near-duplicate sayfalar,
- gereksiz crawl,
- canonical karmaşası,
- index bloat,
- zayıf internal linking
oluşturabilir.
Pagination mı infinite scroll mu?
Üç temel model vardır:
- Pagination
- Load more
- Infinite scroll
UX açısından infinite scroll çekici olabilir ancak yalnızca JavaScript etkileşimine bağlı ürünler crawler tarafından keşfedilemeyebilir.
İyi storefront mimarisi kullanıcı için kesintisiz ürün keşfini, crawler için gerçek crawlable URL'lerle birlikte çözmelidir.
Search ile category birbirine karıştırılmamalı
Site içi /search?q=siyah+ayakkabi sayfası SEO landing page gibi kullanılmamalıdır.
Arama sistemi kullanıcının intent'ine cevap verir; kategori sistemi mağazanın bilgi mimarisini temsil eder.
Büyük kataloglarda veri modeli nasıl olmalı?
Daha sağlıklı yapı:
Product → Product Group → Variant → Attributes → Collections/Categories → Inventory → Pricing
şeklinde düşünülebilir.
Internal linking neden kritik?
Google yalnızca sitemap üzerinden ürün keşfetmemelidir.
Önemli ürünler storefront içindeki gerçek navigasyon yapısından ulaşılabilir olmalıdır.
Sitemap bütün problemi çözmez
Sitemap Google'a URL'leri bildirir ancak kötü bilgi mimarisini düzeltmez.
Cache stratejisi katalog büyüdükçe değişir
Kategori metadata, ürün açıklaması, stok, fiyat ve filtre aggregation gibi veri tipleri farklı cache politikalarına sahip olabilir.
Büyük katalog için teknik checklist
- Kategori ağacı iş ihtiyacına göre tasarlanmış mı?
- SEO landing page ile operasyonel filtre ayrılmış mı?
- Filtre kombinasyonları sınırsız URL üretmiş mi?
- Canonical davranışı test edilmiş mi?
- Pagination crawler tarafından erişilebilir mi?
- Orphan product var mı?
- Varyant ile product ayrımı doğru mu?
- Search URL'leri indexleniyor mu?
- Stokta olmayan ürün politikası belirlenmiş mi?
- Sitemap yalnız canonical URL'leri içeriyor mu?
- Filtre API'si katalog büyüdükçe ölçeklenebiliyor mu?
- Cache invalidation fiyat/stok yapısına uygun mu?
5.000 ürün sihirli sınır mı?
Hayır.
Asıl belirleyici:
SKU sayısı × attribute sayısı × filtre kombinasyonları × trafik × güncelleme sıklığı
kombinasyonudur.
Katalog büyüklüğünü ürün sayısı değil kombinasyon sayısı belirler
20.000 ürün, 12 marka, 20 renk, 15 beden ve onlarca filtre olduğunda URL state uzayı milyonlara çıkabilir.
Bu yüzden önce indexable taxonomy ile interactive facet state ayrılmalıdır.
SEO landing page hangi filtre kombinasyonundan üretilmeli?
Bir filtre kombinasyonu ancak şu koşulların çoğunu karşılıyorsa kalıcı landing page olmaya adaydır:
- gerçek arama talebi,
- anlamlı ürün sayısı,
- uzun süre stabil assortment,
- benzersiz intent,
- editoryal metadata üretme imkânı,
- güçlü internal linking.
URL cardinality budget
canonical category URLs
+ approved SEO facet URLs
+ product URLs
+ variant URLs
Bunun dışındaki ephemeral state kontrollü tutulmalıdır.
Category API nasıl ölçeklenmeli?
Büyük katalogda filtre aggregation pahalıdır.
Daha ölçekli yapı:
- search index,
- denormalized facet data,
- precomputed aggregation,
- cache
kullanabilir. Kritik nokta UI filtre sisteminin transactional database'e sınırsız aggregation yüklememesidir.
Orphan product detection
product URL
← category
← parent category
← navigation
zincirinin mevcut olup olmadığı periyodik test edilebilir.
Stokta olmayan ürün politikası
Geçici stok yok
URL kalır, availability güncellenir.
Kalıcı discontinued ama SEO değeri var
İçerik korunabilir, alternatif ürünlere yönlendirme yapılabilir.
Değersiz/yanlış URL
410/404 veya uygun redirect değerlendirilebilir.
Her out-of-stock ürünü ana kategoriye 301 etmek kötü pratiktir.
Pagination contract
Crawler için:
- benzersiz URL,
- erişilebilir link,
- server-rendered product links
önemlidir.
Infinite scroll UX katmanı olabilir; altında gerçek pagination contract bulunabilir.
Katalog health dashboard
- canonical URL count
- indexed URL count
- filter URL crawl share
- orphan products
- empty categories
- zero-result SEO pages
- search latency p95
- category API error rate
Veri sahipliği
PIM, commerce, feed ve storefront aynı attribute için farklı değer taşıyorsa katalog kalitesi bozulur. Canonical product schema belirlenmeli ve diğer kanallar bundan türetilmelidir.
Katalog büyüdükçe operasyon ekibi de değişir
SEO ekibi yeni landing page isterken merchandising ekibi filtre ekleyebilir, engineering URL üretir, PIM yeni attribute açar. Governance yoksa her ekip ayrı karar verir.
Minimum ownership:
- taxonomy owner,
- SEO index policy owner,
- product data owner,
- search/filter owner.
Yeni facet üretimi change request olarak değerlendirilmelidir.
Capacity testi
Black Friday öncesi katalog API'si yalnız ortalama trafikle değil:
- p95/p99 latency,
- concurrent filter requests,
- cache miss,
- search index refresh
senaryolarında yük testine girmelidir.
Sonuç
Büyük katalog yönetimi bir “ürün yükleme” problemi değildir.
Doğru çözüm:
ürün modeli + kategori mimarisi + filtreleme + URL stratejisi + crawlability + performans
birlikte tasarlandığında ortaya çıkar.
Reliefers olarak yüksek SKU'lu e-ticaret projelerinde storefront'u yalnızca görsel tema olarak ele almıyoruz. Kategori ve varyant modeli, filtreleme, arama, cache, teknik SEO ve frontend performansını aynı mimari içinde değerlendiriyoruz.