Bir tişörtün beş rengi ve altı bedeni varsa mağazada kaç ürün vardır?
Kullanıcı açısından cevap genellikle bir üründür.
Stok sistemi açısından ise 30 ayrı SKU olabilir.
SEO açısından doğru cevap ise ürünün ve varyantların nasıl arandığına, URL mimarisine ve storefront'un nasıl çalıştığına bağlıdır.
Product, Product Group ve SKU aynı şey değildir
Örnek:
Model: Runner X
Renk: Siyah
Beden: 43
Burada Runner X ürün grubu, Runner X Siyah ürün varyantı, Runner X Siyah 43 ise stok tutulan SKU olabilir.
Her beden için ayrı URL gerekli mi?
Çoğu durumda hayır.
Beden genellikle ürün sayfasındaki selectable state olarak tutulabilir.
Renk varyantları ayrı URL olabilir mi?
Evet.
Örneğin:
/runner-x-siyah
/runner-x-beyaz
URL'leri bulunabilir.
Bunun anlamlı olabilmesi için her URL'nin doğrudan açılabilmesi, doğru varyantı göstermesi, kendi görsellerine sahip olması ve tutarlı structured data üretmesi gerekir.
Canonical nasıl seçilmeli?
İki temel model vardır.
Model A — Tek ürün URL'si
/runner-x
Renk ve beden client-side seçimdir.
Model B — Varyant URL'leri
/runner-x?color=black
veya
/runner-x-black
gibi ayrı varyant adresleri bulunabilir.
Canonical stratejisi storefront veri modeliyle birlikte tasarlanmalıdır.
ProductGroup structured data ne işe yarar?
ProductGroup yapısı ürünlerin aynı ürün ailesinin varyantları olduğunu anlatmayı sağlar.
Örneğin Runner X altında Black, White ve Red varyantları tanımlanabilir.
Structured data frontend state'iyle uyuşmalı
Kullanıcı siyah ürünü görürken structured data beyaz ürün diyorsa veri tutarsızlığı oluşur.
Storefront'un görsel state'i ile structured data aynı commerce state'inden üretilmelidir.
Stokta olmayan varyant ne olacak?
Ürün ailesi hâlâ satılıyorsa tek bir bedenin tükenmesi ürün sayfasını 404 yapmayı gerektirmez.
Varyant değiştirilince URL değişmeli mi?
Varyant bağımsız olarak paylaşılabilir ve indexlenebilir olacaksa URL'nin state'i temsil etmesi faydalıdır.
Ancak shareable state ile indexable state farklı kavramlardır.
Analytics'te varyant nasıl izlenmeli?
Purchase event'te parent product yanında variant ve SKU ayrımı korunursa hangi renk ve bedenin sattığı analiz edilebilir.
Merchant feed ile storefront aynı ID'leri kullanmalı
Sistemler arasında farklı kimlik stratejileri reconciliation'ı zorlaştırır.
Varyant SEO checklist
- Parent product tanımlı mı?
- Her SKU benzersiz mi?
- GTIN doğru varyanta bağlı mı?
- Varyant URL stratejisi belirlenmiş mi?
- Canonical davranışı tutarlı mı?
- Structured data gerçek UI state'iyle eşleşiyor mu?
ProductGroupkullanımı uygun mu?- Stok varyant seviyesinde mi?
- Merchant feed ID'leri storefront ile eşleşiyor mu?
- Analytics varyant seviyesini koruyor mu?
- Paylaşılan varyant URL'si aynı state'i yeniden oluşturuyor mu?
Varyant URL kararı için arama niyetini ölçün
Her varyantın ayrı URL alması teknik bir tercih değil, discovery kararıdır.
Renk varyantı ayrı aranıyorsa bağımsız landing intent oluşturabilir. Beden ise çoğu üründe ayrı search intent üretmez.
Üç varyant modeli
Model 1 — Tek canonical ürün
/product/runner-x
Model 2 — Shareable varyant parameter
/product/runner-x?color=black
URL state'i yeniden üretir ama canonical parent'a gidebilir.
Model 3 — Indexable varyant URL
/product/runner-x-black
Her varyant self-canonical, doğru title/meta, görsel, availability ve structured data üretir.
ProductGroup veri kontratı
group_id: runner-x
varies_by: color, size
Variant:
variant_id: runner-x-black-43
color: black
size: 43
sku: RX-BLK-43
availability: in_stock
Storefront, feed ve analytics aynı identity graph'ı kullanırsa reconciliation kolaylaşır.
Varyant switch client-side olduğunda riskler
Kullanıcı beyaz renge geçiyor ama URL, title, structured data ve analytics item_id değişmiyorsa commerce state tutarsız olabilir.
Canonical anti-pattern
Bütün varyant URL'lerini parent'a canonical verip sitemap'a ayrı ayrı koymak çelişkili sinyal yaratabilir.
Sitemap mümkün olduğunca canonical/indexlenmesi istenen URL'leri içermelidir.
Analytics'te önerilen item dimensions
- item_id
- item_name
- item_variant
- item_category
- parent_product_id
gibi alanlarla parent ve SKU seviyeleri birlikte korunabilir.
QA senaryoları
- doğrudan varyant URL açılışı,
- crawler JS olmadan ne görüyor,
- renk switch sonrası URL/state,
- social share sonrası doğru varyant,
- structured data / visible price eşleşmesi,
- out-of-stock varyant,
- canonical ve sitemap uyumu,
- Merchant feed ID eşleşmesi.
Varyant modelinde en kritik hata: identity drift
Storefront SKU A-BLK-43, ERP 12345, feed A_BLACK_43, analytics runner-x-black kullanıyorsa aynı ürünü sistemler arasında eşlemek zorlaşır.
İdeal yaklaşım:
- internal canonical variant id,
- external channel mappings
ayrımıdır.
Varyant lifecycle
Yeni renk ekleme, SKU değişimi, discontinued varyant ve GTIN güncelleme süreçleri de modelin parçasıdır. SEO yalnız URL açıldığı gün değil, varyantın bütün yaşam döngüsünde korunmalıdır.
Sonuç
İyi bir varyant modeli Google'a ürün ilişkilerini daha doğru anlatırken aynı zamanda stok, analytics, Merchant Center ve kullanıcı deneyiminin aynı ürün kimliği üzerinden çalışmasını sağlar.
Reliefers olarak ürün ve varyant modelini frontend'in son aşamasında çözülmesi gereken bir detay olarak değil, e-ticaret mimarisinin temel kontratlarından biri olarak ele alıyoruz.