E-Ticaret Teknik SEO: URL Space ve Product Entity Modeling

E-ticaret Technical SEO’yu yalnız canonical, robots.txt, sitemap ve response code kontrolü olarak düşünmek büyük kataloglarda problemin önemli bir kısmını kaçırır.

Özellikle ürün sayısı, filtre sistemi ve varyant yapısı büyüdükçe iki farklı problem aynı anda ortaya çıkar:

• Site teknik olarak gereğinden fazla URL üretir.
• Gerçekten farklı ürün ve varyant ilişkileri yeterince açık modellenmeyebilir.

Bu yüzden e-ticaret Technical SEO’yu anlamak için yararlı bulduğum mental model şu:

E-COMMERCE TECHNICAL SEO

        ┌───────────────┐
        │   URL SPACE   │
        └───────┬───────┘
                │
       Gereksiz URL üretimini
             kontrol et
                │
                ↓
         CRAWL / INDEX


        ┌───────────────┐
        │ ENTITY SPACE  │
        └───────┬───────┘
                │
       Gerçek ürün ilişkilerini
             açıkla
                │
                ↓
       PRODUCT UNDERSTANDING


                +
                
        DATA CONSISTENCY

Başka bir ifadeyle:

E-ticaret Technical SEO’nun önemli bir bölümü URL’leri optimize etmekten çok, URL’lerin neyi temsil ettiğini yönetmektir.

Bu model Technical SEO’nun bütününü açıklamaz. Rendering, performance, HTTP durumları, indexability ve başka teknik katmanlar hâlâ geçerlidir. Ancak büyük kataloglarda URL üretimi ile ürün modelleme sorunlarını aynı çerçevede düşünmek birçok problemi daha anlaşılır hale getirir.

Bu çerçevenin daha geniş sistem içindeki yerini e-ticaret SEO’nun site mimarisi, ürün verisi ve arama yüzeyleriyle nasıl birlikte çalıştığı yazısında ele alıyorum.

1. URL Space: E-ticaret sitesi kaç farklı URL üretebilir?

E-ticaret sistemleri kullanıcıya aynı ürün kataloğunu onlarca farklı şekilde görüntüleme imkânı verir.

Örneğin bir kategori:

/ayakkabi/

üzerinden kullanıcı:

• marka,
• renk,
• beden,
• fiyat,
• stok,
• malzeme,
• sıralama

seçebilir.

Her seçim URL’de temsil ediliyorsa kombinasyonlar hızla büyür:

/ayakkabi/
↓
?brand=nike
↓
?brand=nike&color=black
↓
?brand=nike&color=black&size=42
↓
?brand=nike&color=black&size=42&sort=price
↓
...

Google’ın faceted navigation dokümantasyonu tam olarak bu problemi tanımlar. URL parametreleriyle çalışan filtre sistemlerinin çok büyük, hatta pratikte sonsuza yaklaşan URL alanları oluşturabileceğini; bunun overcrawling ve önemli yeni sayfaların daha yavaş keşfedilmesi gibi sonuçlara yol açabileceğini belirtir.^[1]

Buradaki temel problem içerik değildir.

İlk soru şudur:

Bu URL’lerin kaç tanesinin crawler tarafından gerçekten keşfedilmesi ve taranması gerekiyor?

Faceted navigation aslında URL üretim problemi midir?

Büyük ölçüde evet.

Filtrenin kullanıcı açısından yararlı olması, oluşturduğu her URL’nin Search açısından bağımsız sayfa olması gerektiği anlamına gelmez.

Örneğin:

/matkaplar/?brand=bosch

gerçek ve sürdürülebilir bir kullanıcı ihtiyacını temsil edebilir.

Ama:

/matkaplar/
?brand=bosch
&color=blue
&stock=true
&sort=price-desc
&view=grid

aynı derecede anlamlı bir Search landing page olmayabilir.

Dolayısıyla:

TECHNICALLY POSSIBLE URL
≠
SEARCH OWNER URL

Bu ayrımı faceted navigation ve filtre URL’lerini yönetme yazısında detaylandırıyorum.

Her facet URL’sini crawl ettirmek neden sorun olabilir?

Crawler URL’nin değerli olup olmadığını çoğu zaman URL’yi görmeden bilemez.

Bu nedenle sistem şu şekilde büyüyebilir:

1 CATEGORY

× 20 BRAND

× 10 COLOR

× 15 SIZE

× 8 PRICE RANGE

× 4 SORTING

=

96.000 POSSIBLE STATES

Bu matematik örneği yalnız kombinasyon etkisini göstermek içindir; gerçek sitelerde filtrelerin bağımlılıklarına göre sonuç farklı olabilir.

Problem şudur:

Kullanıcı için birkaç anlamlı filtre kombinasyonu faydalıyken crawler aynı sistemden binlerce gereksiz URL keşfedebilir.

Google bu nedenle faceted URL’lerin Search’te görünmesine ihtiyaç yoksa crawling’in önlenmesini; gerekiyorsa da URL’lerin belirli teknik kurallarla optimize edilmesini önerir.^[1]

Bu neden yalnız “crawl budget” konusu değildir?

Her küçük e-ticaret sitesinde dramatik bir crawl budget krizi bulunduğunu söylemek doğru olmaz.

Ama URL proliferation başka problemler de yaratır:

• gereksiz crawler request’leri,
• önemli URL’lerin keşfinin yavaşlaması,
• duplicate veya near-duplicate sayfalar,
• canonical karmaşası,
• internal linking sinyallerinin dağılması,
• Search Console raporlarının gürültülü hale gelmesi,
• index durumlarının anlaşılmasının zorlaşması.

Bu yüzden büyük kataloglarda:

URL EXISTS
≠
URL SHOULD BE CRAWLED
≠
URL SHOULD BE INDEXABLE
≠
URL SHOULD BE SEARCH OWNER

ayrımını kurmak gerekir.

Crawlability ile indexability arasındaki fark burada doğrudan devreye girer. Crawler’ın URL’ye erişebilmesi ile o URL’nin bağımsız Search sonucu olarak indekslenmesini istemek aynı karar değildir.

Kategori mimarisi URL Space probleminin neresindedir?

Her filtreyi engellemek de çözüm değildir.

Çünkü bazı facet’ler gerçekten ayrı search demand’i temsil edebilir.

Örneğin:

akülü matkaplar

bosch akülü matkaplar

18v akülü matkaplar

aynı ürün evreninin farklı fakat ticari açıdan anlamlı product set’lerini temsil edebilir.

Bu noktada teknik karar search architecture kararına bağlanır.

PRODUCT ATTRIBUTE
↓
SEARCH DEMAND VAR MI?
↓
AYRI USER NEED VAR MI?
↓
SÜRDÜRÜLEBİLİR PRODUCT SET VAR MI?
↓
PAGE ROLE GEREKİYOR MU?

Bu yüzden e-ticaret kategori mimarisi ile faceted navigation tamamen ayrı projeler değildir.

Kategori mimarisi hangi product set’in bağımsız sayfa rolü taşıyacağını belirler.

Technical SEO ise bu kararın URL, crawling, canonical ve indexability katmanlarında düzgün uygulanmasını sağlar.

2. Entity Space: Product variants neden farklı bir problem?

Faceted navigation tarafında problem çoğu zaman gereğinden fazla URL bulunmasıdır.

Product variants tarafında ise ters bir problem oluşabilir:

Gerçekten farklı ürün durumlarını yeterince açık biçimde temsil edememek.

Örneğin bir ayakkabının:

• siyah 42,
• siyah 43,
• beyaz 42,
• beyaz 43

varyantları olabilir.

Bunlar dört tamamen bağımsız ürün ailesi değildir.

Ama aynı zamanda anlamsız URL parametrelerinden de ibaret değildir.

Her varyantın:

• SKU’su,
• GTIN’i,
• rengi,
• bedeni,
• stok durumu,
• görseli,
• fiyatı

farklı olabilir.

Google product variants’ı nasıl modelleyebiliyor?

Google Search, aynı parent product’a ait varyantları açıklamak için Schema.org ProductGroup yapısını destekler.^[2]

Temel model:

ProductGroup
│
├── productGroupID
│
├── variesBy
│   ├── color
│   └── size
│
├── Product Variant A
│   ├── sku
│   ├── gtin
│   ├── color
│   ├── size
│   └── Offer
│
└── Product Variant B
    ├── sku
    ├── gtin
    ├── color
    ├── size
    └── Offer

Google özellikle:

• ProductGroup,
• hasVariant,
• variesBy,
• productGroupID

özelliklerini aynı ürün ailesinin varyasyonlarını açıklamak için destekler.^[2]

Buradaki asıl mesele JSON-LD syntax’ı değildir.

Sitedeki gerçek ürün mimarisinin makine tarafından anlaşılabilir biçimde temsil edilmesidir.

Variant URL’leri neden önemlidir?

Google’ın product variant dokümantasyonu her varyantın doğrudan seçilebildiği tanımlanabilir bir URL bulunmasını ister. Bu URL path veya query parameter kullanabilir.^[2]

Örneğin:

/winter-coat?color=green&size=small

açıldığında sayfanın gerçekten:

• yeşil,
• small,
• doğru görsel,
• doğru fiyat,
• doğru availability

durumuyla açılması gerekir.

Google’ın e-ticaret URL rehberi de her product variant’ın ayrı URL ile tanımlanabilmesini önerir.^[3]

Dolayısıyla:

VARIANT STATE
↓
IDENTIFIABLE URL
↓
PRODUCT ID
↓
VARIANT ATTRIBUTES
↓
OFFER

ilişkisi kurulabilir.

Faceted URL ile variant URL aynı şey değildir

Burası mental modelin en kritik ayrımlarından biridir.

Facet URL:

Bir ürün kümesini filtreler.

Variant URL:

Belirli bir ürün ailesindeki belirli ürün durumunu temsil eder.

Örneğin:

FACET

/ayakkabi/?color=black

=
Siyah ürünlerden oluşan bir PLP

ile:

VARIANT

/nike-air-max/?color=black&size=42

=
Nike Air Max ürün ailesinin
belirli varyantı

aynı değildir.

Alan	Facet URL	Variant URL
Temsil ettiği şey	Ürün kümesi	Belirli ürün durumu
Temel problem	URL proliferation	Product relationship
Ana soru	Bu URL crawl/index edilmeli mi?	Bu variant hangi parent ürüne ait?
Tipik veri	Brand, color, price filter	SKU, GTIN, size, color, availability

Canonical product variants’ı tek URL altında ezmek için mi kullanılmalı?

Hayır. Her product variant senaryosunda bütün URL’leri tek bir canonical’a göndermek mekanik bir kural değildir.

Google’ın product variants dokümantasyonu single-page ve multi-page variant uygulamalarını ayrı ele alır.^[2]

Tek sayfalı bir modelde ürün ailesinin base URL’si genel canonical olarak kullanılabilir.

Ancak varyantlar birden fazla eşit önemde sayfaya dağıtılıyorsa ProductGroup için tek bir canonical URL bulunduğu varsayılmaz; her sayfanın kendi üzerinde tanımladığı entity’ler için yeterli markup taşıması gerekir.^[2]

Bu yüzden canonical kararını:

"Varyant var → parent'a canonical ver"

şeklinde otomatikleştirmek doğru değildir.

Önce:

• varyant gerçekten ayrı kullanıcı durumu mu,
• URL nasıl çalışıyor,
• sayfa içeriği ne kadar farklı,
• variant Search açısından nasıl temsil edilmek isteniyor,
• single-page mi multi-page mi

anlaşılmalıdır.

Canonicalization’ın kendisini canonical URL ve duplicate URL ilişkileri yazısında detaylandırıyorum.

Faceted navigation ile product variants aslında zıt problemlerdir

İki problem arasındaki karşıtlık şu:

FACETED NAVIGATION

1 CATEGORY
↓
100.000 POSSIBLE URL

AMA

Çoğu ayrı Search entity değil.

↓

URL SPACE'İ DARALT


PRODUCT VARIANTS

1 PRODUCT FAMILY
↓
12 REAL VARIANT

VE

Bunlar rastgele duplicate state değil.

↓

ENTITY İLİŞKİLERİNİ KORU

Technical SEO’nun görevi bu yüzden yalnız URL sayısını azaltmak değildir.

Yanlış URL’leri azaltırken doğru ayrımları da korumak gerekir.

Gereksiz farklılıkları konsolide et; gerçek farklılıkları kaybetme.

3. Data Consistency: URL ve entity modeli aynı hikâyeyi anlatıyor mu?

Üçüncü katman data consistency’dir.

Google ürün bilgisini yalnız HTML içeriğinden değerlendirmez.

E-ticaret ürün bilgisi farklı kanallardan aktarılabilir:

PRODUCT DATABASE / PIM
          ↓
    ┌─────┼─────┐
    ↓     ↓     ↓
  HTML  SCHEMA MERCHANT
    │     │     │
    └─────┼─────┘
          ↓
       GOOGLE

Google, structured data’nın sayfadaki fiyat, stok ve kargo gibi ürün bilgilerinin anlaşılmasını destekleyebildiğini; Merchant Center verisinin de ürünler hakkında doğrudan veri sağladığını belirtir.^[4]

Bu kaynaklar arasında tutarsızlık oluşabilir.

Örneğin:

HTML
IN STOCK

SCHEMA
OUT OF STOCK

MERCHANT
IN STOCK

veya:

HTML PRICE
1.999 TL

STRUCTURED DATA
1.899 TL

MERCHANT FEED
2.099 TL

Google’ın Merchant dokümantasyonu özellikle web sitesi ile feed arasında fiyat veya availability güncelleme gecikmeleri nedeniyle tutarsızlık oluşabileceğini belirtir.^[4]

Bu yüzden product data kalitesini yalnız feed validation sonucu olarak değerlendirmek eksiktir.

Product data kalitesi, ürün hakkındaki farklı veri katmanlarının aynı gerçekliği ne kadar tutarlı anlattığıdır.

Data consistency yalnız fiyat ve stok mudur?

Hayır.

Şunlar da tutarlı olmalıdır:

• product URL,
• canonical URL,
• internal links,
• sitemap URL,
• SKU,
• GTIN,
• brand,
• variant group ID,
• price,
• availability,
• image,
• variant attributes.

Google’ın e-ticaret URL dokümantasyonu da ürün URL’leri konusunda internal links, sitemap ve canonical gibi sinyallerin aynı URL’yi kullanmasını önerir.^[3]

Yani:

INTERNAL LINK
↓
CANONICAL
↓
SITEMAP
↓
PRODUCT DATA
↓
MERCHANT URL

Mümkün olduğunca
aynı ürün gerçekliğini anlatmalı.

Internal linking bu modelin neresinde?

URL’nin var olması onun crawler tarafından bulunacağı anlamına gelmez.

Google e-ticaret site yapısını değerlendirirken URL klasörlerinden çok sayfalar arasındaki link ilişkilerini kullandığını açıkça belirtir.^[5]

Bu nedenle:

HOME
↓
CATEGORY
↓
SUBCATEGORY
↓
PRODUCT

gibi crawl path’leri önemli olmaya devam eder.

Ürün varyantları veya facet’ler doğru modellenmiş olsa bile yanlış internal linking:

• gereksiz URL’leri crawler’a sürekli açabilir,
• önemli ürünleri derinde bırakabilir,
• canonical tercihine karşı farklı URL’leri güçlendirebilir.

Technical SEO burada yalnız directive yazmaz; gerçek link graph’ın hangi URL’leri öne çıkardığını da kontrol eder.

URL Space ve Entity Space birlikte nasıl audit edilir?

Ben audit’i iki ayrı envanterle başlatmayı daha yararlı buluyorum.

URL inventory

CATEGORY
SUBCATEGORY
FACET
SORT
PAGINATION
INTERNAL SEARCH
PRODUCT
VARIANT
PARAMETER
LEGACY URL

Her URL sınıfında:

• kaç URL üretiliyor,
• nasıl keşfediliyor,
• crawl ediliyor mu,
• indexable mı,
• canonical pattern ne,
• sitemap içinde mi,
• internal link alıyor mu

kontrol edilir.

Entity inventory

PRODUCT TYPE
↓
PRODUCT GROUP
↓
PRODUCT
↓
VARIANT
↓
SKU / GTIN
↓
OFFER

Burada ise:

• parent-child ilişkileri,
• variant ID’leri,
• varyasyonu belirleyen attribute’lar,
• price,
• availability,
• product URLs

incelenir.

Pratik audit tablosu

Katman	Soru
URL Generation	Site hangi template ve parametrelerden URL üretiyor?
Discovery	Crawler bu URL’leri hangi bağlantılardan buluyor?
Crawling	Gerçekten crawl edilmesi gereken URL seti hangisi?
Indexability	Hangi URL’ler bağımsız Search owner olmalı?
Canonical	Duplicate veya similar states nasıl konsolide ediliyor?
Product Group	Hangi ürünler aynı parent product’a bağlı?
Variant	Her gerçek varyant benzersiz biçimde tanımlanabiliyor mu?
Identifiers	SKU, GTIN ve productGroupID tutarlı mı?
Structured Data	Sayfadaki gerçek product/variant yapısını doğru temsil ediyor mu?
Merchant Data	Feed/API aynı fiyat, stok ve product URL’lerini taşıyor mu?

En sık yapılan hata: bütün parametre URL’lerini duplicate sanmak

URL’de query parameter bulunması onun otomatik olarak gereksiz olduğu anlamına gelmez.

Aynı teknik mekanizma:

?color=black

bir yerde yalnız UX filtresi olabilir.

Başka yerde gerçek product variant’ı doğrudan seçebilir.

Bu yüzden parametrenin syntax’ından önce semantic role değerlendirilmelidir.

URL’nin nasıl yazıldığı değil, hangi state veya entity’yi temsil ettiği daha önemlidir.

İkinci hata: bütün product variants’ı duplicate kabul etmek

Renk veya beden varyantlarının aynı ana ürünün parçaları olması, bunların anlamsız kopyalar olduğu anlamına gelmez.

Google product variants dokümantasyonu tam tersine her variant’ın benzersiz ID ile tanımlanmasını ve doğrudan seçilebilir URL üzerinden erişilebilir olmasını ister.^[2]

Yani:

SAME PRODUCT FAMILY
≠
SAME PRODUCT STATE

Üçüncü hata: canonical ile crawl control’ü aynı şey sanmak

Canonicalization duplicate veya çok benzer URL’ler arasından temsilci URL seçimiyle ilgilidir.

Google canonical’ı tercih sinyali olarak kullanır; aynı zamanda duplicate URL’lerin daha seyrek crawl edilmesine zaman içinde katkı sağlayabilir. Fakat faceted navigation dokümantasyonu canonical’ın crawl kontrolü için daha dolaylı ve yavaş bir yöntem olduğunu açıkça belirtir.^[1]

Bu nedenle:

CANONICAL
≠
ROBOTS.TXT
≠
NOINDEX
≠
REDIRECT

Bu mekanizmaların görevlerini birbirine karıştırmamak gerekir.

Dördüncü hata: structured data’yı gerçek ürün modelinin yerine koymak

JSON-LD içine güzel bir ProductGroup yazmak kötü product database’i sihirli biçimde düzeltmez.

Eğer sistemde:

• varyant ilişkileri yanlışsa,
• SKU’lar duplicate ise,
• GTIN mapping bozuksa,
• stok farklı sistemlerde farklıysa,
• variant URL doğru ürünü seçmiyorsa

structured data yalnız bu problemin başka bir temsilini üretir.

Daha doğru sıra:

REAL PRODUCT MODEL
↓
DATABASE / PIM
↓
PAGE STATE
↓
PRODUCT URL
↓
STRUCTURED DATA
↓
MERCHANT DATA

E-ticaret Technical SEO’yu üç soru üzerinden düşünmek

Bu mental modeli üç soruya indirebiliriz.

1. Bu URL gerçekten gerekli mi?

URL Space problemi.

Özellikle:

• facets,
• sorting,
• parameters,
• internal search,
• pagination

için sorulur.

2. Bu URL tam olarak neyi temsil ediyor?

Entity Space problemi.

Özellikle:

• category,
• product family,
• product variant,
• SKU,
• Offer

ilişkilerinde sorulur.

3. Bütün sistemler aynı şeyi mi söylüyor?

Data Consistency problemi.

Kontrol edilen katmanlar:

• visible HTML,
• URL,
• canonical,
• internal links,
• sitemap,
• structured data,
• Merchant data.

Üst seviye mental model

                    E-COMMERCE SITE
                         │
            ┌────────────┴────────────┐
            │                         │
            ↓                         ↓
       URL SPACE                 ENTITY SPACE
            │                         │
      Facets                     ProductGroup
      Sorting                    Product
      Parameters                 Variant
      Pagination                 SKU
      Search URLs                GTIN
            │                         │
            ↓                         ↓
     CRAWL CONTROL             ENTITY MODELING
            │                         │
            └────────────┬────────────┘
                         ↓
                  DATA CONSISTENCY
                         ↓
          HTML + URL + CANONICAL
             + STRUCTURED DATA
             + MERCHANT DATA
                         ↓
                  SEARCH SYSTEMS

Neden bu model kullanışlı?

Çünkü teknik problemi yalnız crawler açısından görmeyi bırakıyoruz.

Örneğin:

“Bu URL crawl ediliyor mu?”

hala önemli bir soru.

Ama önceki ve sonraki sorular da ekleniyor:

BU URL NEDEN VAR?
↓
NEYİ TEMSİL EDİYOR?
↓
CRAWL EDİLMELİ Mİ?
↓
INDEX OWNER OLMALI MI?
↓
CANONICAL İLİŞKİSİ NE?
↓
HANGİ PRODUCT ENTITY'YE BAĞLI?
↓
MERCHANT AYNI URL/ÜRÜNÜ MÜ GÖSTERİYOR?

Bu bakış Technical SEO’yu yalnız hata düzeltme pratiğinden çıkarıp sistem modelleme problemine yaklaştırır.

Arama motorunun URL’yi keşfetmesinden crawling, indexing ve retrieval’a uzanan genel pipeline’ı arama motorlarının nasıl çalıştığını anlattığım yazıda daha geniş ele alıyorum.

Tek cümlelik sonuç

E-ticaret Technical SEO’da iki zıt problemi aynı anda yönetiyoruz:

TOO MANY MEANINGLESS URLS
↓
CONTROL URL SPACE


REAL PRODUCT DIFFERENCES
↓
PRESERVE ENTITY RELATIONSHIPS


THEN

MAKE EVERY DATA LAYER
TELL THE SAME STORY

E-ticaret Technical SEO, Google’ın siteyi gereksiz URL’lerle taramasını sınırlarken gerçek kategori, ürün ailesi ve ürün varyantı ilişkilerini mümkün olduğunca açık ve tutarlı biçimde temsil etme işidir.

Kaynaklar ve teknik referanslar

1. Google Crawling Infrastructure — Managing Crawling of Faceted Navigation URLs
2. Google Search Central — Product Variant Structured Data
3. Google Search Central — Ecommerce URL Structure Best Practices
4. Google Search Central — Share Your Product Data With Google
5. Google Search Central — Help Google Understand Your Ecommerce Site Structure
6. Google Search Central — What Is URL Canonicalization?