E-Ticaret Kategori Mimarisi Nasıl Kurulur?

E-ticaret kategori mimarisi, ürün kataloğundaki ürünleri yalnızca ticari sınıflara ayırmak değil; kullanıcıların ürünleri nasıl aradığına, karşılaştırdığına ve keşfettiğine göre kategori, alt kategori ve filtre rollerini belirlemektir.

Bir tedarikçinin, ERP sisteminin veya PIM yapısının ürünleri belirli biçimde sınıflandırması, aynı yapının doğrudan web sitesine taşınması gerektiği anlamına gelmez. Ürün kataloğu operasyonel bir envanter modeli olabilir. Search architecture ise kullanıcı ihtiyacını, arama talebini, ürün ilişkilerini ve sayfa rollerini birlikte temsil etmek zorundadır.

PRODUCT CATALOG
        ≠
SEARCH ARCHITECTURE

Bu nedenle kategori mimarisi çalışması “menüde hangi kategoriler olsun?” sorusundan önce başlar. Asıl soru şudur:

Hangi ürün kümesi, hangi kullanıcı ihtiyacını karşılıyor ve bu ihtiyaç sitede hangi sayfa tarafından temsil edilmeli?

Kategori mimarisi, daha geniş e-ticaret SEO sisteminin bütünü içindeki page ownership ve architecture katmanını derinleştirir. Buradaki amaç kategori title’ı yazmak veya her ürün grubuna metin eklemek değil; hangi kategorilerin neden var olması gerektiğini belirlemektir.

E-ticaret kategori mimarisi nedir?

E-ticaret kategori mimarisi, ürünleri anlamlı kümelere ayıran taksonominin, bu kümeler arasındaki üst-alt ilişkilerin ve kullanıcıların bu sayfalara ulaşmasını sağlayan bağlantı yollarının birlikte tasarlanmasıdır.

Bu tanımın üç ayrı katmanı vardır:

• Product taxonomy: Ürünlerin hangi özellik veya sınıflara göre gruplandığını tanımlar.
• Hierarchy: Bu gruplar arasında parent-child ilişkisi kurar.
• Site architecture: Kategorilerin, ürünlerin ve diğer sayfaların birbirine hangi yollarla bağlandığını belirler.

Bunlar aynı şey değildir. Örneğin “Akülü Matkaplar” bir ürün tipi olabilir, “Bosch” marka boyutunu, “18V” teknik bir özelliği, “Profesyonel Kullanım” ise kullanım bağlamını ifade edebilir.

Bu sınıflandırmaların hepsini aynı kategori ağacına sokmak zorunda değiliz.

Genel taxonomy, hierarchy, URL ve internal linking ilişkisini site mimarisi yazısında daha geniş biçimde ele alıyorum. Burada yalnızca bu prensiplerin büyük ürün kataloglarına nasıl uygulanacağını inceleyeceğiz.

Ürün kataloğu neden doğrudan kategori ağacı değildir?

Çünkü ürün kataloğu çoğu zaman şirketin ürünleri nasıl yönettiğini, kategori mimarisi ise kullanıcının ürünleri nasıl bulduğunu temsil eder.

İki yapı bazen örtüşür. Fakat bunun otomatik olarak gerçekleşmesini beklemek doğru değildir.

Bir distribütörün operasyonel kataloğu örneğin şöyle olabilir:

Elektrikli Ürünler
└── Bosch
    └── Professional
        └── 18V

Bu sınıflandırma stok, tedarik veya ürün yönetimi açısından tamamen mantıklı olabilir.

Fakat kullanıcıların arama ve gezinme davranışı şu yapıya daha yakın olabilir:

Elektrikli El Aletleri
└── Matkaplar
    ├── Akülü Matkaplar
    ├── Darbeli Matkaplar
    └── Manyetik Matkaplar

Buradaki fark yalnız isimlendirme değildir. İki yapı farklı problemleri çözer.

Yapı	Temel soru
Ürün kataloğu	Bu ürün şirket içinde nasıl sınıflandırılıyor ve yönetiliyor?
Search architecture	Kullanıcı bu ürün grubunu hangi ihtiyaçla arıyor ve hangi sayfadan ulaşmalı?

Bu nedenle ERP’deki bütün departman, marka veya özellik alanlarını otomatik olarak indexable kategoriye çevirmek kategori mimarisi değildir. Bu yalnızca veri tabanı sınıflandırmasını URL üretim sistemine bağlamaktır.

Aynı ürün birden fazla sınıflandırma boyutuna sahip olabilir

Bir ürün aynı anda ürün tipi, marka, teknik özellik, kullanım alanı ve uyumluluk gibi farklı boyutlarda sınıflandırılabilir.

Örneğin bir akülü matkap şu özelliklere sahip olabilir:

Sınıflandırma boyutu	Örnek
Product type	Akülü Matkap
Brand	Bosch
Voltage	18V
Technology	Kömürsüz
Use case	Profesyonel Kullanım
Compatibility	Bosch Professional 18V sistem

Buradaki en yaygın mimari hata, bütün boyutları parent-child ilişkisine dönüştürmektir:

Akülü Matkaplar
└── Bosch
    └── 18V
        └── Kömürsüz
            └── Profesyonel

Bu yapı veri açısından düzenli görünebilir. Ancak her yeni özellik yeni bir kategori seviyesi oluşturursa ürün ağacı hızla büyür ve aynı ürün çok sayıda benzer sayfa tarafından temsil edilmeye başlar.

Daha doğru soru şudur:

Bu özellik gerçekten farklı bir ürün kategorisi mi oluşturuyor, yoksa mevcut ürün kümesini daraltan bir facet mi?

Bu ayrım kategori mimarisinin merkezindedir.

Kategori mimarisi hangi verilerle başlamalı?

Sağlıklı bir kategori mimarisi yalnız keyword research veya yalnız mevcut ürün ağacı üzerinden kurulmaz. Katalog verisi, search demand ve mevcut site davranışı birlikte değerlendirilmelidir.

CATALOG DATA
     +
SEARCH DEMAND
     +
CURRENT SITE DATA
     ↓
ARCHITECTURE DECISION

1. Ürün kataloğu

Önce elimizde gerçekten ne bulunduğunu bilmek gerekir:

• ürün tipleri,
• markalar,
• teknik özellikler,
• varyantlar,
• uyumluluk ilişkileri,
• stok durumu,
• ürün yaşam döngüsü,
• hangi özelliklerin katalog genelinde tutarlı biçimde doldurulduğu.

Örneğin “motor tipi” yalnız ürünlerin %10’unda tanımlıysa buna dayanan kategori veya facet mimarisinin sürdürülebilirliği ayrıca sorgulanmalıdır.

2. Search demand

Search demand yalnız tek tek keyword hacimleri değildir. Kullanıcıların ürün grubunu hangi dil ve ayrımlarla aradığını anlamaya çalışırız.

Kaynaklar arasında şunlar bulunabilir:

• keyword ve query araştırması,
• Google Search Console sorguları,
• site içi arama verileri,
• ücretli arama sorguları,
• müşteri ve satış ekibi dili,
• SERP’te hangi page type’ların görünür olduğu.

Örneğin “akülü matkap”, “kömürsüz akülü matkap” ve “18v akülü matkap” farklı sorgu kümeleri oluşturabilir. Fakat üç ayrı ifade görmemiz üç ayrı kategori açmamız gerektiğini kanıtlamaz.

3. Mevcut site verisi

Yeni bir ağaç çizmeden önce mevcut yapının nasıl çalıştığı da görülmelidir:

• hangi kategori URL’leri organik görünürlük alıyor,
• hangi kategoriler birbirleriyle aynı sorgularda yarışıyor,
• hangi kategori sayfaları hiç ürün taşımıyor,
• hangi ürünler gereksiz derecede derinde kalıyor,
• hangi sayfalar yalnız site içi aramayla bulunabiliyor,
• hangi filtreler zaten organik talep toplamaya başlamış.

Yeni mimari, yalnız teorik olarak daha temiz görünmek için çalışan URL’leri bozacak şekilde tasarlanmamalıdır.

Search demand hangi sayfanın owner’ı olmalı?

Kategori mimarisi yalnız sorguları kategorilere eşlemek değil, sorgunun arkasındaki ihtiyacı doğru page role ile eşleştirmektir.

Kullanılabilecek basit model:

INFORMATION NEED
        ↓
QUERY FAMILY
        ↓
PRODUCT SET
        ↓
EXPECTED PAGE TYPE
        ↓
PAGE ROLE

Örneğin:

Sorgu	Muhtemel ihtiyaç	Muhtemel page role
akülü matkap	Ürünleri incelemek ve karşılaştırmak	Kategori
bosch akülü matkap	Belirli markadaki ürünleri incelemek	Kategori veya seçilmiş facet adayı
bosch gsb 18v-50	Belirli ürünü incelemek	Ürün sayfası
akülü matkap nasıl seçilir	Seçim kriterlerini öğrenmek	Rehber
m8 civata ölçüleri	Teknik bilgi edinmek	Teknik rehber

Aynı ürün evreni hakkında konuşuyor olmaları bu sorguların aynı sayfaya ait olduğu anlamına gelmez.

Kategori mimarisindeki owner kavramını Google’a gönderilen bir teknik direktif olarak düşünmemek gerekir. Buradaki owner, belirli bir kullanıcı ihtiyacının sitedeki ana karşılığı olarak seçilen sayfadır.

Bir ürün grubu ne zaman ayrı kategori olmalı?

Bir ürün grubunun kategori olması için tek bir metrik yeterli değildir. Ayrı kullanıcı ihtiyacı, anlamlı ürün kümesi ve uzun vadede sürdürülebilir bir sayfa rolü birlikte değerlendirilmelidir.

Kategori adayı için şu karar akışı kullanılabilir:

ÜRÜN KÜMESİ VAR MI?
        ↓
AYRI INFORMATION NEED VAR MI?
        ↓
SEARCH DEMAND BUNU DESTEKLİYOR MU?
        ↓
SERP AYRI LISTING PAGE BEKLİYOR MU?
        ↓
ÜRÜN KÜMESİ GERÇEKTEN FARKLI MI?
        ↓
ENVANTER SÜRDÜRÜLEBİLİR Mİ?
        ↓
MEVCUT OWNER İLE ÇAKIŞIYOR MU?
        ↓
KULLANICI BU SINIFLANDIRMAYLA GEZİNİR Mİ?
        ↓
CATEGORY / SUBCATEGORY / FACET / NO NEW URL

Ayrı information need var mı?

“Kömürsüz akülü matkap” arayan kullanıcı gerçekten daha spesifik bir ürün grubu mu arıyor, yoksa “akülü matkap” ihtiyacının yalnız bir filtre kriterini mi ifade ediyor?

Bu ayrım sektör ve ürün tipine göre değişebilir.

Ürün kümesi gerçekten farklı mı?

Yeni sayfa, mevcut kategorinin ürünlerini neredeyse birebir tekrar ediyorsa ayrı bir owner oluşturmak zorlaşır.

Örneğin katalogdaki akülü matkapların %95’i zaten 18V ise “18V Akülü Matkaplar” kategorisi kullanıcıya pratikte yeni bir ürün seti sunmayabilir.

Tersine, 12V ve 18V ürün grupları farklı kullanım senaryoları, fiyat seviyeleri ve ürün seçenekleri taşıyorsa ayrım daha anlamlı olabilir.

Ürün derinliği yeterli mi?

Burada evrensel bir “en az 20 ürün” kuralı yoktur.

Beş ürün bazı niş kategorilerde yeterli bir seçim kümesi olabilir. Elli ürün başka bir kategoride birbirinden neredeyse ayırt edilemeyen varyantlardan oluşabilir.

Ürün sayısını tek başına eşik olarak kullanmak yerine şunlara bakmak daha anlamlıdır:

• kullanıcıya gerçek seçim sunuyor mu,
• ürünler uzun süre katalogda kalacak mı,
• kategori sık sık sıfır ürüne düşecek mi,
• ürün grubu zaman içinde genişleyebilir mi,
• sayfa mevcut başka bir kategoriyle büyük ölçüde örtüşüyor mu?

SERP ne söylüyor?

SERP tek başına kategori açma talimatı değildir. Fakat Google’ın ilgili sorgu için ağırlıklı olarak kategori/listing sayfaları mı, ürün sayfaları mı yoksa rehberler mi gösterdiğini görmek expected page type hakkında yararlı veri sağlayabilir.

Örneğin ticari bir sorguda sonuçların büyük bölümü ürün listeleme sayfalarından oluşuyorsa, tamamen informational bir rehberle aynı ihtiyeti karşılamaya çalışmak sayfa rolü açısından sorunlu olabilir.

Parent kategori ve alt kategori nasıl ayrılmalı?

Parent kategori geniş bir ürün sınıfını temsil eder; alt kategori ise bu sınıf içinde kullanıcı açısından anlamlı ve yeterince kalıcı bir ürün grubunu ayırmalıdır.

Örneğin:

Hırdavat
└── Elektrikli El Aletleri
    └── Matkaplar
        ├── Akülü Matkaplar
        ├── Darbeli Matkaplar
        └── Manyetik Matkaplar

Bu yapı ürün tipleri arasında gerçek bir hiyerarşi kuruyor.

Ancak şu yapı aynı mantıkla çalışmayabilir:

Akülü Matkaplar
└── Bosch
    └── 18V
        └── Kömürsüz
            └── Profesyonel Kullanım

Çünkü Bosch bir marka, 18V bir teknik nitelik, kömürsüz bir motor teknolojisi ve profesyonel kullanım bir kullanım bağlamıdır. Bunların hepsi aynı taxonomy dimension değildir.

Bir ürünün beş özelliğe sahip olması, onu kategori ağacında beş seviye aşağı indirmemizi gerektirmez.

Parent-child ilişkisi şu soruyu cevaplamalıdır:

Bu alt grup gerçekten üst grubun daha spesifik ve doğal bir ürün sınıfı mı?

Cevap yalnız “ürün datasında bu alan mevcut” ise kategori üretmek için yeterli değildir.

Kategori mi, alt kategori mi, facet mi?

Her sınıflandırma boyutu kategori değildir. Bazı ayrımlar kalıcı landing page, bazıları alt kategori, bazıları yalnız facet olarak çalışmalıdır.

Durum	Muhtemel rol
Geniş, bağımsız ürün tipi	Kategori
Parent ürün tipinin doğal ve kalıcı alt sınıfı	Alt kategori
Anlamlı talebi bulunan marka × ürün tipi kombinasyonu	Kategori veya organik owner facet adayı
Geçici stok durumu	UX facet
Fiyata göre sıralama	Sıralama durumu, ayrı owner değil
Çok düşük değerli filtre kombinasyonu	Yeni organik URL gerekmeyebilir

Örneğin:

Akülü Matkaplar
↓
Bosch
↓
18V
↓
Kömürsüz

Kullanıcının arayüzde bu dört seçimi yapabilmesi gerekir diye dört farklı seviyede indexable sayfa üretmek zorunda değiliz.

Facet kombinasyonlarının URL üretimi, crawling, canonical, robots ve index yönetimi ayrı bir teknik problemdir. Bu katmanı faceted navigation ve filtre URL’lerinin teknik yönetimi yazısında ayrıntılı ele alıyorum.

Google da faceted navigation sistemlerinin parametre kombinasyonları üzerinden çok büyük URL alanları oluşturabileceğini ve gereksiz crawling’in yeni veya yararlı URL’lerin keşfini yavaşlatabileceğini belirtiyor.^[2]

Bu nedenle kategori mimarisi ile faceted navigation birbirine bağlıdır fakat aynı problem değildir:

CATEGORY ARCHITECTURE
= hangi ürün kümesi hangi page role tarafından temsil edilmeli?

FACETED NAVIGATION
= kullanıcı bu ürün kümesini nasıl daraltmalı ve oluşan URL'ler nasıl yönetilmeli?

Marka sayfaları kategori olmalı mı?

Marka adı tek başına kategori açmak için yeterli değildir. Markanın katalogdaki kapsamı, kullanıcı talebi ve hangi ürün kümesinin temsil edileceği birlikte değerlendirilmelidir.

Örneğin Bosch için birkaç farklı sayfa rolü düşünülebilir:

• tüm Bosch ürünlerini gösteren global marka sayfası,
• Bosch Akülü Matkaplar gibi marka × ürün tipi landing page’i,
• kategori içinde yalnız UX amaçlı marka facet’i,
• hiçbir ayrı indexable marka URL’si oluşturmamak.

Hangisinin doğru olduğu katalogdan kataloğa değişir.

“Bosch” sorgusunun bulunması doğrudan global bir kategori gerektiği anlamına gelmez. Kullanıcı markanın sitesini, belirli bir ürününü, teknik desteği veya belirli ürün grubunu arıyor olabilir.

Benzer biçimde “Bosch akülü matkap” sorgu ailesi güçlü ve belirgin bir ürün kümesi oluşturuyorsa, marka × ürün tipi kombinasyonu ayrı landing page adayı olabilir.

Ancak bunu bütün markalara programatik biçimde uygulamak:

50 marka
×
100 kategori
=
5.000 marka-kategori URL adayı

üretebilir.

Mimari karar tekrar query, product set ve page role seviyesinde verilmelidir.

Kullanım alanı ve teknik özellikler kategoriye dönüşmeli mi?

Bazı teknik özellikler kullanıcı için temel ürün sınıflandırmasıdır; bazıları yalnız seçim filtresidir. Özelliğin veri tabanında bulunması, organik kategori olmasını gerektirmez.

Örnek adaylar:

• 18V,
• SDS Plus,
• kömürsüz,
• paslanmaz,
• dış mekan,
• profesyonel,
• ahşap için,
• beton için.

Bunların aynı türde sınıflandırmalar olmadığını görmek önemlidir.

“SDS Plus kırıcı delici” gibi bir özellik ürün tipinin pazarda anlaşılma biçiminin doğal parçası olabilir. “Stokta bulunan SDS Plus kırıcı deliciler” ise ürün sınıfından ziyade geçici envanter durumunu ifade eder.

Kategori mimarisinin görevi bu ayrımları aynı URL üretim kuralına sıkıştırmak değil, hangi sınıflandırma boyutunun hangi rolü üstleneceğini belirlemektir.

Query varyasyonu yeni kategori anlamına gelir mi?

Hayır. Farklı sorgular aynı information need ve aynı ürün kümesini temsil edebilir.

Örneğin:

akülü matkap
şarjlı matkap
kablosuz matkap

Bu üç ifadenin bulunması otomatik olarak üç ayrı kategori oluşturmak gerektiğini göstermez.

Eğer kullanıcıların beklentisi, SERP yapısı ve gösterilecek ürün seti büyük ölçüde aynıysa tek owner daha doğru olabilir.

Aksi durumda şu tür bir yapı oluşabilir:

/akulu-matkaplar/
/sarjli-matkaplar/
/kablosuz-matkaplar/

ve üç sayfa aynı ürünleri, aynı ihtiyacı ve aynı sorgu ailesini hedeflemeye başlayabilir.

Buna karşılık:

Akülü Matkaplar
Kömürsüz Akülü Matkaplar

gerçekten farklı ürün kümelerine ve seçim ihtiyaçlarına karşılık gelebilir.

Karar yalnız kelime benzerliğinden değil, ihtiyaç ve ürün kümesi ilişkisinden çıkar.

Kategori overlap nasıl tespit edilir?

İki kategori aynı sorgu ailesini hedefliyor, büyük ölçüde aynı ürünleri gösteriyor ve kullanıcıya farklı bir seçim değeri sunmuyorsa ownership problemi oluşabilir.

Audit sırasında şu karşılaştırmalar yapılabilir:

• kategori isimleri,
• ranking query kümeleri,
• ürün setlerinin örtüşme oranı,
• internal link anchor’ları,
• title ve heading kapsamları,
• SERP’te hangi URL’nin görünür olduğu,
• hangi kategoriye navigasyondan daha güçlü erişildiği.

Örneğin iki kategori aynı 80 üründen 75’ini gösteriyorsa ve aynı sorgular için dönüşümlü olarak görünüyorsa yalnız metinleri farklılaştırmak temel problemi çözmeyebilir.

Asıl soru iki ayrı sayfa rolüne gerçekten ihtiyaç olup olmadığıdır.

Stok değişimleri kategori mimarisini nasıl etkiler?

Kategori mimarisi yalnız bugünkü stok görüntüsüne göre kurulursa katalog değiştikçe bozulur. Kategori sayfasının temsil ettiği ürün grubunun uzun vadeli sürdürülebilirliği de değerlendirilmelidir.

E-ticaret katalogları sabit değildir:

• ürünler stoktan çıkar,
• yeni markalar eklenir,
• ürün aileleri kapanır,
• sezonluk ürünler geri gelir,
• yeni teknik özellikler yaygınlaşır,
• eski ürün serileri tamamen kaldırılır.

Bu nedenle bir kategori bugün on beş ürün taşıyor diye kalıcı bir owner olmak zorunda değildir. Aynı şekilde geçici olarak üç ürüne düşmesi kategorinin otomatik olarak silinmesini gerektirmez.

Şu ayrımları yapmak gerekir:

Geçici stok azalması

Kategori uzun vadede devam eden gerçek bir ürün grubunu temsil ediyorsa kısa süreli stok problemi mimariyi değiştirmek için yeterli neden olmayabilir.

Kalıcı ürün ailesi kapanışı

Ürün grubunun ticari olarak tamamen ortadan kalkması durumunda kategori URL’sinin geleceği ayrıca değerlendirilmelidir. Mevcut talep, trafik, backlink, alternatif ürün grupları ve kullanıcı ihtiyacı dikkate alınabilir.

Sürekli sıfır ürün üreten programatik kategoriler

Bu durum çoğu zaman taxonomy ile URL üretim kurallarının katalog gerçekliğinden koptuğunu gösterir.

Özellikle marka × özellik × kullanım alanı kombinasyonlarından otomatik kategori üreten yapılarda binlerce boş veya çok zayıf ürün kümesi oluşabilir.

Internal linking kategori ağacını nasıl hayata geçirir?

Kategori ağacının bir Excel dosyasında tanımlanması yeterli değildir. Mimari, kullanıcıların ve crawler’ların izleyebildiği gerçek bağlantılarla uygulanmalıdır.

Google, e-ticaret sitelerinde crawler’ın menüden kategori sayfalarına, kategorilerden alt kategorilere ve alt kategorilerden ürünlere bağlantılar üzerinden ulaşabilmesini öneriyor.^[1]

Basitleştirilmiş keşif yolu:

ANA SAYFA
    ↓
ANA KATEGORİ
    ↓
ALT KATEGORİ
    ↓
ÜRÜN

Fakat gerçek e-ticaret yapısı yalnız dikey ağaçtan oluşmaz.

Ek bağlantılar bulunabilir:

• parent kategoriden önemli child kategorilere,
• child kategoriden ürünlere,
• rehberden ilgili kategoriye,
• kategoriden seçim rehberine,
• üründen doğrulanmış aksesuar veya tamamlayıcı ürüne,
• üründen ilgili kategoriye.

Google ayrıca site yapısını anlamada URL klasörlerinden ziyade sayfalar arasındaki bağlantı ilişkilerini analiz ettiğini açıkça belirtiyor.^[1]

Dolayısıyla:

/elektrikli-el-aletleri/matkaplar/akulu-matkaplar/

gibi düzenli bir URL tek başına iyi mimariyi kanıtlamaz.

Sayfanın gerçekten kategoriden bağlantı alıp almadığı, ürünlere geçiş sağlayıp sağlamadığı ve diğer ilgili sayfalarla anlamlı biçimde bağlanıp bağlanmadığı ayrıca kontrol edilmelidir.

Bütün ürünlere kategori sayfalarından ulaşılmalı mı?

İndekslenmesi istenen ürünlerin yalnız site içi arama kutusuna bağımlı kalmaması önemlidir.

Google, kategori sayfalarının ürünlere doğrudan bağlantı vermemesi durumunda crawler’ın yalnız tarama yoluyla bütün ürünleri bulamayabileceğini ve Googlebot’un genellikle site içi arama kutularına sorgu göndermediğini belirtiyor.^[1]

Bu durum büyük kataloglarda özellikle önemlidir.

Örneğin kullanıcı yalnız:

Arama kutusu
→ "M8 civata"
→ ürün

yoluyla bir ürüne ulaşabiliyor, fakat kategori, alt kategori veya başka taranabilir bağlantı yolundan erişemiyorsa ürün keşfi site içi aramaya bağımlı hale gelir.

Pagination, load more ve infinite scroll kullanılan kategorilerde de ürün bağlantılarının crawler tarafından erişilebilir olup olmadığı ayrıca test edilmelidir. Google crawler’larının genellikle kullanıcı gibi butonlara tıklamadığını ve taranabilir bağlantılar için gerçek `` yapılarının önemli olduğunu belirtiyor.[3]

11 bin ürünlü bir hırdavat kataloğunda kategori mimarisi nasıl düşünülür?

Büyük kataloglarda kategori mimarisi keyword listesinden URL üretme işi olmaktan çıkar; binlerce ürünün hangi ticari ve informational ihtiyaçlara göre gruplanacağını belirleyen bir ownership problemine dönüşür.

Yaklaşık 11 bin ürünlü anonim bir hırdavat e-ticaret projesinde kategori yapısı üzerinde çalışırken problem yalnız ürün sayısının fazla olması değildi. Kullanıcıların farklı arama ihtiyaçlarını karşılayan kategori ve içerik owner’larının daha sistematik hale getirilmesi gerekiyordu.

Bu tip bir katalog başlangıçta kabaca şöyle görünebilir:

HIRDAVAT
├── Bağlantı Elemanları
│   ├── Civatalar
│   ├── Vidalar
│   └── Dübeller
│
├── El Aletleri
│
└── Elektrikli El Aletleri
    └── Matkaplar
        └── Akülü Matkaplar

Ancak architecture çalışması burada bitmez.

Örneğin “M8 civata” query family ticari bir ürün kümesini işaret edebilir:

M8 civata
↓
ürünleri listeleme / karşılaştırma ihtiyacı
↓
commercial product set
↓
kategori veya ürün ailesi owner'ı

Aynı ürün evrenindeki başka bir sorgu:

M8 civata ölçüleri
↓
teknik ölçü bilgisini öğrenme
↓
informational need
↓
teknik rehber

İki query içinde de “M8 civata” geçmesi iki ihtiyacın aynı URL tarafından karşılanmasını gerektirmez.

Bu yaklaşımın gerçek bir projedeki daha geniş uygulamasını 11 bin ürünlü e-ticaret SEO vaka analizinde inceleyebilirsiniz.

E-ticaret kategori mimarisi nasıl audit edilir?

Kategori audit’i yalnız mevcut menüyü incelemek değildir. Ürün envanteri, URL envanteri, search demand, page ownership ve gerçek internal link graph birlikte değerlendirilmelidir.

1. Ürün envanterini çıkarın

Ürün tipi, marka, teknik nitelik, kullanım alanı ve varyant gibi classification dimension’ları belirleyin.

2. Mevcut kategori ve facet URL’lerini çıkarın

CMS’de tanımlı kategoriler ile crawler’ın gerçekten bulduğu URL’leri karşılaştırın.

Şunları ayırın:

• ana kategori,
• alt kategori,
• marka landing page,
• facet,
• site search URL’si,
• sıralama URL’si,
• pagination URL’si.

3. Query ownership haritası oluşturun

Hangi query family’nin hangi mevcut URL tarafından karşılandığını inceleyin.

Aynı query family’yi hedefleyen birden fazla kategori varsa overlap adayı olarak işaretleyin.

4. Ürün setlerini karşılaştırın

İki kategori farklı isimlere sahip olabilir fakat büyük ölçüde aynı ürünleri gösterebilir.

İsim farkını ürün kümesi farkıyla karıştırmayın.

5. Orphan ve derin kategorileri bulun

XML sitemap’te bulunup gerçek site navigasyonundan veya başka anlamlı sayfalardan bağlantı almayan kategori URL’lerini kontrol edin.

Sitemap discovery’yi destekleyebilir; internal linking’in yerine geçmez.

6. Boş ve sürekli zayıf kategorileri inceleyin

Sıfır veya çok düşük ürün sayısı tek başına otomatik silme kararı değildir. Ancak özellikle programatik olarak üretilen yüzlerce benzer kategori taxonomy probleminin göstergesi olabilir.

7. Kategori-facet çakışmalarını bulun

Örneğin hem:

/akulu-matkaplar/bosch/

hem de:

/akulu-matkaplar/?marka=bosch

aynı ürün grubunu ayrı indexable URL’lerle temsil ediyorsa hangi URL’nin owner olacağı belirlenmelidir.

8. Internal linking yollarını crawl ile doğrulayın

Mimari şemada var görünen ilişkinin HTML’de gerçek bir bağlantıyla uygulanıp uygulanmadığını kontrol edin.

9. Search Console verisiyle doğrulayın

Yeni kategori mimarisinin performansını yalnız toplam organik trafik üzerinden ölçmeyin.

Örneğin:

• kategori URL grubunun tıklama ve gösterimleri,
• commercial query görünürlüğü,
• hangi kategori URL’lerinin aynı sorgularda göründüğü,
• yeni kategorilerin indeks ve görünürlük gelişimi,
• bilgi içeriklerinden kategori sayfalarına geçişler

ayrı takip edilebilir.

Yaygın e-ticaret kategori mimarisi hataları

• Tedarikçi veya ERP kategori ağacını doğrudan web sitesine taşımak.
• Her keyword varyasyonu için ayrı kategori açmak.
• Marka, ürün tipi, özellik ve kullanım alanını tek parent-child hiyerarşisine sıkıştırmak.
• Her filtreyi indexable kategori haline getirmek.
• Kategori oluşturmak için bütün sektörlere aynı minimum ürün sayısını uygulamak.
• Yalnız search volume’a bakıp ürün setinin farklı olup olmadığını kontrol etmemek.
• Bugünkü stok durumuna göre uzun vadeli kategori oluşturmak.
• Aynı ürünleri gösteren birden fazla kategori owner üretmek.
• URL klasör yapısını site mimarisinin kendisi sanmak.
• Kategori ağacını çizip gerçek internal linking ile uygulamamak.
• Ürünleri yalnız site içi arama üzerinden erişilebilir bırakmak.
• Kategori mimarisi problemini kategori açıklamalarını uzatarak çözmeye çalışmak.

E-ticaret kategori mimarisi için karar modeli

İyi kategori mimarisi, ürün kataloğunu mümkün olduğunca fazla URL’ye dönüştüren değil; her anlamlı kullanıcı ihtiyacını doğru page role ile temsil eden yapıdır.

Çalışma sırası şu şekilde özetlenebilir:

PRODUCT CATALOG
        ↓
CLASSIFICATION DIMENSIONS
        ↓
SEARCH DEMAND
        ↓
INFORMATION NEED
        ↓
QUERY FAMILY
        ↓
PRODUCT SET
        ↓
PAGE ROLE
        ↓
┌────────────┬─────────────┬─────────┬────────┐
│ CATEGORY   │ SUBCATEGORY │ FACET   │ NO URL │
└────────────┴─────────────┴─────────┴────────┘
        ↓
INTERNAL LINKING
        ↓
CRAWLING
        ↓
INDEXING
        ↓
MEASUREMENT

Buradaki temel ayrım değişmez:

Ürün kataloğu, search architecture değildir. Kategori mimarisi katalogdaki sınıfları kopyalamaz; hangi ürün kümelerinin kullanıcı açısından ayrı bir sayfa rolünü hak ettiğini belirler.

Bu nedenle kategori mimarisinde ilk soru “URL nasıl olmalı?” değil, “bu URL neden var olmalı?” olmalıdır.

Kaynaklar ve teknik referanslar

1. Google Search Central — Help Google understand your ecommerce website structure
2. Google Crawling Infrastructure — Managing crawling of faceted navigation URLs
3. Google Search Central — Pagination, incremental page loading, and their impact on Google Search
4. Google Search Central — Link best practices for Google