E-Ticaret SEO’da Ürün Veri Modeli: Google Ürünleri Nasıl Anlıyor?

E-ticaret SEO’da bir ürün yalnızca başlık, açıklama, fiyat ve görselden oluşan bir web sayfası değildir. Aynı ürün; marka, ürün kimliği, teknik özellikler, varyantlar, ilişkili ürünler, stok, fiyat ve başka ticari bilgilerden oluşan bir veri nesnesidir.

Bu ayrım önemlidir. Çünkü ürün bilgisinin metinde bulunmasıyla, sistem tarafından ayrı veri alanları halinde modellenmesi aynı şey değildir.

Örneğin ürün açıklamasında “Bosch marka, kırmızı, 18V darbeli matkap” yazabiliriz. Fakat e-ticaret sisteminde aynı bilgi şu şekilde tutulabilir:

brand = Bosch color = Kırmızı voltage = 18V product_type = Darbeli Matkap

İki yapı kullanıcıya benzer bilgi verebilir. Fakat ikinci model; filtreleme, varyant yönetimi, structured data, Merchant Center, site içi arama, PIM, feed ve başka sistemler tarafından ayrı ayrı kullanılabilecek alanlar üretir.

E-ticaret SEO’da ürün verisinin bulunması ile ürün bilgisinin modellenmiş olması aynı şey değildir.

Bu nedenle ürün optimizasyonunu yalnız ürün açıklaması yazımı olarak ele almak eksik kalır. Ürünün e-ticaret altyapısında nasıl temsil edildiği de search altyapısının bir parçasıdır.

Ürün veri modeli nedir?

Ürün veri modeli, bir ürünün sistem içinde hangi alanlar, kimlikler, özellikler ve ilişkiler üzerinden temsil edildiğini tanımlar.

Basitleştirilmiş bir ürün modeli şöyle düşünülebilir:

PRODUCT ├── Identity │ ├── Name │ ├── SKU │ ├── Brand │ ├── GTIN │ └── MPN │ ├── Classification │ ├── Product Type │ ├── Category │ └── Taxonomy │ ├── Attributes │ ├── Color │ ├── Material │ ├── Size │ └── Technical Specifications │ ├── Relationships │ ├── Variants │ ├── Accessories │ ├── Required Parts │ └── Alternatives │ ├── Knowledge │ ├── Description │ ├── Highlights │ ├── Questions & Answers │ └── Documents │ └── Commerce ├── Price ├── Availability ├── Shipping └── Returns

Her e-ticaret sitesi bu alanların tamamına ihtiyaç duymaz. Bir moda mağazasının ürün modeli ile endüstriyel ekipman satan bir B2B kataloğun veri modeli doğal olarak farklıdır.

Asıl mesele, ürün grubunun gerçek özelliklerinin sürekli olarak description içine gömülmesi yerine gerektiğinde ayrı ve yeniden kullanılabilir veri alanlarıyla temsil edilmesidir.

Ürün açıklaması neden tek başına yeterli değildir?

Bir ürünün bütün özelliklerini açıklama alanında yazmak mümkündür:

M8 x 50 mm DIN 933 standardında, paslanmaz çelik, tam diş cıvata.

Bu metin kullanıcı açısından son derece yararlı olabilir. Sorun metnin varlığı değildir.

Sorun, sistem açısından bütün bilgilerin tek bir metin alanında kaybolmasıdır.

Aynı ürün şu şekilde modellenebilir:

product_type = Altı Köşe Başlı Cıvata diameter = M8 length = 50 mm standard = DIN 933 material = Paslanmaz Çelik thread = Tam Diş

İkinci yapı sayesinde aynı alanlar:

• ürün detay tablosunda gösterilebilir,
• site içi filtrelerde kullanılabilir,
• ürün karşılaştırmalarına taşınabilir,
• structured data üretiminde kullanılabilir,
• Merchant feed veya API alanlarına eşlenebilir,
• site içi arama tarafından sorgulanabilir,
• başka sistemlere API üzerinden aktarılabilir.

Burada description ortadan kalkmaz. Description’ın görevi değişir.

Ürün açıklaması kullanım bağlamını, faydayı, seçim bilgisini ve doğal dili taşıyabilir. Teknik gerçekler ise uygun olduğunda kendi veri alanlarında tutulur.

Ürün verisinin dört farklı katmanı

E-ticaret ürün bilgisini değerlendirirken dört katmanı birbirinden ayırmak gerekir.

Katman	Temel görev	Örnek
Product Data Model	Ürünün altyapıda nasıl tutulacağını belirler.	brand, gtin, material, voltage, variant, price
Page Content	Ürün bilgisini kullanıcıya görünür biçimde sunar.	Başlık, açıklama, teknik tablo, fiyat, stok
Structured Data	Sayfadaki varlık ve özellikleri makine tarafından okunabilir biçimde açıklar.	Product, Offer, ProductGroup
Merchant Product Data	Ticari ürün bilgisini Google’ın Merchant sistemlerine doğrudan aktarır.	title, brand, gtin, price, availability, item_group_id

Google, ürün bilgisini paylaşmak isteyen e-ticaret sitelerine ürün sayfalarında structured data kullanmalarını ve Merchant Center üzerinden doğrudan ürün verisi sağlamalarını öneriyor.^[1]

Structured data arama sonuçlarında görünmek için mutlak bir zorunluluk değildir; ancak Google’ın sayfadaki ürün bilgisini anlamasına ve uygun olduğunda daha zengin ürün deneyimleri oluşturmasına yardımcı olabilir.^[1]

Bu yapı şöyle özetlenebilir:

PRODUCT DATA MODEL ↓ ┌──────┼──────────┐ ↓ ↓ ↓ PAGE SCHEMA MERCHANT DATA ↓ ↓ ↓ └──────┴─────┬────┘ ↓ SEARCH SYSTEMS

Asıl kritik nokta alttaki üç katmanın çoğu zaman en üstteki product data model’dan beslenmesidir.

Product structured data ile Merchant verisi aynı şey değildir

Product structured data ve Merchant Center sık sık tek bir “ürün schema” konusu gibi anlatılıyor. Aslında farklı veri kanallarıdır.

Google’ın Product structured data dokümantasyonu, ürün sayfalarında fiyat, stok, değerlendirme, kargo ve benzeri bilgilerin açık biçimde işaretlenebilmesini sağlar. Satın alma yapılabilen ürün sayfaları için merchant listing işaretlemesi daha ayrıntılı ticari özellikleri destekler.^[2]

Merchant Center veya Merchant API ise ürün bilgisini Google’ın ticari ürün sistemine doğrudan aktaran ayrı bir kanaldır.

Dolayısıyla:

STRUCTURED DATA ≠ MERCHANT PRODUCT DATA

Ancak ikisi aynı ürünü temsil ettiği için fiyat, stok, kimlik ve varyant gibi alanlarda birbirleriyle ve kullanıcının gördüğü sayfayla çelişmemelidir.

Bu ayrımın daha geniş e-ticaret sistemi içindeki yerini e-ticaret SEO’nun site mimarisi, ürün verisi ve arama yüzeyleriyle nasıl birlikte çalıştığını anlattığım rehberde ele alıyorum.

Google Merchant API’deki ProductAttributes bize ne gösteriyor?

Google Merchant API’nin güncel ProductAttributes modeli; title, description, link, brand, GTIN, MPN, color, material, product type, availability ve benzeri klasik ürün alanlarının yanında oldukça geniş bir özellik kümesi taşıyor.^[3]

Burada özellikle dikkat çekici gelişme Mayıs 2026’da geldi.

Google, Products API’ye yeni “conversational attributes” alanları ekledi:^[4]

• questionsAndAnswers,
• popularityRank,
• itemGroupTitle,
• documentLinks,
• variantOptions,
• relatedProducts.

Bu değişiklikten “bu alanları doldurmak organik sıralamayı artırır” sonucu çıkarılamaz. Google böyle bir sıralama garantisi vermiyor.

Daha savunulabilir çıkarım şu:

Ürün veri sistemleri artık yalnız fiyat, stok ve başlık taşımıyor; ürün hakkındaki ilişkileri, varyantları, dokümanları ve soru-cevap bilgisini de yapılandırılmış veri olarak temsil edebiliyor.

Ürün SSS’si yalnız içerik alanı değildir

questionsAndAnswers, ürün hakkındaki kullanıcı, satıcı veya üretici kaynaklı soru-cevap çiftlerinin ürün verisine bağlanabilmesini sağlar.^[3]

Örneğin bir darbeli matkap için:

Soru: Bu model beton delmek için kullanılabilir mi? Cevap: Uygun uç ve darbeli çalışma modu ile belirtilen uygulamalarda kullanılabilir.

Buradaki ilginç nokta, soru-cevap bilgisinin yalnız PDP’nin altında duran bir SEO metni veya CRO öğesi olmaktan çıkarak ürün knowledge katmanının parçası olarak modellenebilmesidir.

Bu, her ürün sayfasına zorla SSS eklemek gerektiği anlamına gelmez. Gerçek kullanıcı sorusu olmayan ürünlerde yapay soru-cevap üretmek ürün modelini zenginleştirmek değil, yalnızca veri kalabalığı oluşturmaktır.

Varyantlar neden bir içerik problemi değil, veri modeli problemidir?

Bir ürünün renk, beden, depolama kapasitesi veya teknik seçenekleri değiştiğinde yalnız URL ve canonical kararı vermek yeterli değildir.

Önce şu sorunun cevabı gerekir:

Hangi kayıtlar aynı ürün ailesinin varyantıdır ve hangi alan onları birbirinden ayırır?

Merchant ürün verisinde item_group_id, aynı ürünün varyantlarını ortak bir grup altında birleştirmek için kullanılır. Google ayrıca item_group_title ve variant_option alanlarıyla grubun ve varyantı belirleyen özelliklerin tanımlanmasını destekliyor.^[5]

Structured data tarafında ise Google, varyantları aynı ana ürün altında anlamlandırmak için Schema.org ProductGroup, hasVariant, variesBy ve productGroupID özelliklerini destekliyor.^[6]

Örneğin:

TELEFON ├── 128 GB ├── 256 GB └── 512 GB

veya:

TİŞÖRT ├── Siyah / S ├── Siyah / M ├── Beyaz / S └── Beyaz / M

Burada veri modeli; ürün kimliğini ve varyant ilişkisini belirler. URL ve canonical stratejisi ise bu modelin web üzerindeki temsilini yönetir.

Bu yüzden canonical URL seçimi ile ürün varyant modelini aynı problem gibi ele almamak gerekir.

Aynı şekilde kullanıcıların kategori listesini daraltmasını sağlayan faceted navigation ve filtre URL’leri de ürün varyantlarından farklı bir mimari problemdir.

RelatedProducts: “İlgili ürünler”den daha fazla bilgi

Merchant API’deki relatedProducts alanı, başka bir ürünün yalnız ilişkili olduğunu değil, ilişkinin türünü de tanımlayabiliyor.^[3]

Desteklenen ilişki türleri arasında şunlar bulunuyor:

• PART_OF_SET,
• REQUIRED_PART,
• OFTEN_BOUGHT_WITH,
• SUBSTITUTE,
• DIFFERENT_BRAND,
• ACCESSORY.

Bir akülü matkap örneğinde bunu şöyle düşünebiliriz:

AKÜLÜ MATKAP │ ├── REQUIRED_PART │ └── Akü │ ├── ACCESSORY │ └── Matkap Ucu │ ├── OFTEN_BOUGHT_WITH │ └── Uç Seti │ └── SUBSTITUTE └── Alternatif Matkap Modeli

Bu ilişki modelini editoryal olarak bir product relationship graph şeklinde düşünmek yararlı olabilir.

Ancak “Product Graph” burada Google’ın bu özelliğe verdiği resmî ürün adı değildir. Kullanılan terim, ürünler arasındaki tiplenmiş ilişkilerin mantığını açıklamak için kullanılan bir modeldir.

Bu ayrım önemli. Çünkü klasik bir “ilgili ürünler” widget’ı çoğu zaman yalnız birkaç ürün kartı gösterirken, veri modeli şu soruya cevap verebilir:

Bu iki ürün neden birbiriyle ilişkili?

Teknik dokümanlar da ürün bilgisinin parçası olabilir

Merchant API’deki documentLinks alanı ürünle ilişkili PDF dokümanlarının bağlanmasını destekliyor. Google’ın verdiği örnekler arasında eğitim dokümanları, kullanıcı kılavuzları, montaj talimatları ve paket içi belgeler bulunuyor.^[3]

Bu özellikle şu kataloglarda anlamlıdır:

• endüstriyel makineler,
• HVAC ve iklimlendirme,
• hırdavat,
• elektronik,
• yedek parça,
• B2B teknik ürünler.

Örneğin bir endüstriyel pompanın ürün bilgisi yalnız şu alanlardan oluşmayabilir:

PRODUCT ├── Description ├── Technical Specifications ├── Dimensions ├── Compatibility ├── Variants ├── Accessories ├── Q&A └── Technical Documents ├── Data Sheet ├── Installation Manual └── User Guide

Bu noktada ürün sayfası yalnız satış metni taşıyan bir landing page olmaktan çıkar ve ürün hakkındaki farklı bilgi kaynaklarının birleştiği bir knowledge node işlevi görmeye başlar.

Product information architecture neden e-ticaret altyapısıyla başlar?

Bu yapının büyük bölümü içerik editörünün yazacağı metinden önce belirlenir.

Çünkü ürün alanlarını çoğu zaman şu sistemlerden biri veya birkaçı yönetir:

• e-ticaret platformu,
• CMS,
• PIM,
• ERP,
• ürün veritabanı,
• feed yönetim sistemi,
• Merchant entegrasyonu.

Altyapı yalnız:

title description price image

alanlarını tutuyorsa, ürün bilgisini farklı sistemlerde yeniden kullanmak zorlaşabilir.

Buna karşılık ürün grubuna uygun biçimde:

brand gtin mpn material diameter length standard voltage compatible_products variant technical_document

gibi alanlar tutulabiliyorsa daha zengin bir katalog modeli oluşturulabilir.

Bu noktada “product information architecture” yalnız Google için yapılan bir SEO düzenlemesi değildir.

Aynı veri:

• site navigasyonunu,
• filtreleri,
• site içi aramayı,
• ürün karşılaştırmalarını,
• öneri sistemlerini,
• structured data’yı,
• Merchant feed’i,
• marketplace entegrasyonlarını

besleyebilir.

WooCommerce gibi sistemlerde attribute kullanmak neden farklıdır?

Bir ürün açıklamasına:

Marka: Bosch Renk: Kırmızı Malzeme: Çelik

yazmakla, bu bilgileri e-ticaret altyapısında gerçekten ürün attribute’ları olarak tanımlamak aynı şey değildir.

Altyapının yeteneklerine ve entegrasyonun nasıl kurulduğuna bağlı olarak yapılandırılmış attribute’lar:

• filtrelerde,
• varyantlarda,
• ürün tablolarında,
• feed mapping işlemlerinde,
• structured data üretiminde,
• site içi aramada,
• API entegrasyonlarında

yeniden kullanılabilir.

Burada önemli olan “WooCommerce kullanırsanız SEO iyi olur” gibi anlamsız bir sonuç değildir. Aynı platform çok iyi veya çok kötü bir veri modeliyle kurulabilir.

SEO açısından değerlendirilmesi gereken soru şudur:

E-ticaret altyapısı, ürün grubunun gerçek özelliklerini tutarlı ve yeniden kullanılabilir alanlarla modellememize izin veriyor mu?

Ürün veri modeli kategori mimarisini de etkiler

Ürün attribute’larının bulunması, bu alanların tamamının kategori veya indexable filtre olması gerektiği anlamına gelmez.

Örneğin ürün veritabanında:

brand = Bosch voltage = 18V motor_type = Brushless color = Blue

alanlarının bulunması dört farklı organik landing page açılması gerektiğini göstermez.

Ürün veri modeli “ürün hakkında hangi gerçekleri biliyoruz?” sorusuna cevap verir.

E-ticaret kategori mimarisi ise bu ürün özelliklerinden hangilerinin kullanıcıların ürünleri keşfetmesi ve arama ihtiyaçlarının temsil edilmesi için kategori, alt kategori veya başka bir page role haline gelmesi gerektiğini belirler.

PRODUCT DATA = Ürün hangi özelliklere sahip? SEARCH ARCHITECTURE = Kullanıcı hangi ürün kümelerini ayrı bir ihtiyaç olarak arıyor?

İyi product data, iyi kategori mimarisini mümkün kılabilir. Fakat kategori mimarisi ürün veritabanının otomatik kopyası değildir.

E-ticaret altyapısını SEO açısından değerlendirirken neye bakılmalı?

E-ticaret platformları genellikle SEO açısından şu başlıklarla karşılaştırılır:

• URL kontrolü,
• canonical yönetimi,
• robots direktifleri,
• XML sitemap,
• rendering,
• performans,
• pagination.

Bunlar hâlâ önemlidir. Fakat ürün yoğun sitelerde değerlendirmeye veri modeli yeteneklerini de eklemek gerekir.

Kontrol	Sorulması gereken soru
Product attributes	Ürün grubuna özgü teknik alanlar ayrı tutulabiliyor mu?
Identifiers	SKU, GTIN, MPN ve marka bilgileri tutarlı yönetilebiliyor mu?
Variants	Parent-child ve varyant özellikleri açık biçimde modellenebiliyor mu?
Relationships	Aksesuar, yedek parça, alternatif veya uyumlu ürün ilişkileri tutulabiliyor mu?
Documents	Teknik föy, kılavuz veya montaj dokümanı ürünle ilişkilendirilebiliyor mu?
Structured data mapping	Veri alanları Product ve ProductGroup markup’ına güvenilir biçimde aktarılabiliyor mu?
Merchant mapping	Ürün alanları feed veya Merchant API alanlarına eşlenebiliyor mu?
Data consistency	Sayfa, structured data ve Merchant verisi aynı ürün gerçeklerini gösteriyor mu?

AI Search ve alışveriş sistemleri açısından ürün verisi

Ürün veri modelinin AI Search tarafını “attribute doldurun, yapay zekâ sizi önerir” seviyesine indirmek doğru değil.

Bir sistem kullanıcının:

M8, 50 mm uzunluğunda, paslanmaz, tam diş DIN 933 cıvata arıyorum.

gibi bir ihtiyacını çözmeye çalışıyorsa ürün kataloğunda:

diameter = M8 length = 50 mm material = Paslanmaz Çelik thread = Tam Diş standard = DIN 933

alanlarının açık ve tutarlı biçimde bulunması, aynı gerçeklerin yalnız uzun description metninin içinde gömülü olmasına göre makine tarafından yeniden kullanılmaya daha uygun bir veri yapısı sağlar.

Bu, belirli bir AI sisteminde görünürlük veya citation garantisi değildir.

Daha güvenli çıkarım şudur:

Zengin, doğru ve tutarlı yapılandırılmış ürün verisi; arama, alışveriş ve ürün keşif sistemlerinin ürünler hakkında kullanabileceği daha açık bir bilgi katmanı oluşturur.

Temel yine aynıdır: gerçek ürün bilgisi, iyi teknik altyapı ve katmanlar arası tutarlılık.

Ürün veri modeli nasıl audit edilir?

Product data audit’i yalnız Merchant Center’daki hata listesini açmak değildir. Veri kaynağından kullanıcıya ve arama sistemine kadar bütün akışı izlemek gerekir.

1. Ürün gruplarını çıkarın: Hangi katalogların hangi teknik özelliklere ihtiyaç duyduğunu belirleyin.
2. Kaynak sistemi bulun: Her alanın CMS, ERP, PIM veya başka hangi sistemden geldiğini belirleyin.
3. Kimlikleri kontrol edin: SKU, GTIN, MPN, marka ve parent ID alanlarının tutarlılığını inceleyin.
4. Serbest metne gömülen özellikleri bulun: Düzenli olarak kullanılan fakat yalnız description içinde tutulan teknik alanları çıkarın.
5. Varyant modelini kontrol edin: Gerçek varyantlarla ayrı ürünleri birbirine karıştırmayın.
6. Sayfa çıktısını karşılaştırın: Ürünün görünür başlık, fiyat, stok ve teknik özelliklerinin veri kaynağıyla uyuştuğunu doğrulayın.
7. Structured data mapping’i test edin: Product ve gerekiyorsa ProductGroup alanlarının doğru kaynaktan üretildiğini kontrol edin.
8. Merchant mapping’i test edin: Feed veya API alanlarının doğru ürün gerçeklerini taşıdığını doğrulayın.
9. İlişkileri değerlendirin: Uyumlu ürün, yedek parça, aksesuar veya alternatif ilişkilerinin gerçekten veri olarak tutulup tutulmadığını inceleyin.
10. Gereksiz alanları temizleyin: Veri modelini sırf alan sayısını artırmak için yüzlerce kullanılmayan attribute ile şişirmeyin.

Product data kalitesi ne değildir?

Ürün veri modeli konusunda birkaç yanlış çıkarım özellikle tehlikelidir:

• Her ürün özelliği yeni kategori değildir.
• Her attribute indexable facet değildir.
• Structured data sıralama garantisi değildir.
• Merchant feed site mimarisinin yerine geçmez.
• Ürün açıklamasının yapılandırılmış olması iyi metin ihtiyacını ortadan kaldırmaz.
• Çok fazla alan doldurmak otomatik olarak daha kaliteli katalog anlamına gelmez.
• Merchant API’de bir alanın bulunması, her mağazanın o alanı kullanmak zorunda olduğu anlamına gelmez.
• Yeni conversational attributes alanları organik ranking faktörü olarak ilan edilemez.

Product data kalitesi alan sayısından çok doğru modelleme ve tutarlılık problemidir.

E-ticaret SEO’da ürün optimizasyonunu yeniden tanımlamak

Ürün optimizasyonu yalnız:

Title yaz Description yaz Görsel ekle Schema ekle

şeklinde düşünülmemeli.

Daha doğru zincir şudur:

PRODUCT REALITY ↓ PRODUCT DATA MODEL ↓ PAGE CONTENT ↓ STRUCTURED DATA ↓ MERCHANT PRODUCT DATA ↓ SEARCH & SHOPPING SYSTEMS

Bir ürünün marka, kimlik, teknik özellik, varyant, ilişki, dokümantasyon ve ticari bilgilerinin e-ticaret altyapısında ayrı ve tutarlı veri alanları olarak modellenmesi; aynı gerçeklerin ürün sayfasına, structured data’ya, Merchant sistemlerine ve başka ürün deneyimlerine daha güvenilir biçimde aktarılmasını sağlar.

Bu yüzden ürün veri modeli yalnız operasyon ekibinin veya yazılım ekibinin konusu değildir.

E-ticaret sitesinin ürünleri arama sistemlerine nasıl temsil edebileceğini belirleyen teknik altyapının da bir parçasıdır.

Kaynaklar ve teknik referanslar

1. Google Search Central — Share Your Product Data With Google
2. Google Search Central — Introduction to Product Structured Data
3. Google for Developers — Merchant API ProductAttributes
4. Google for Developers — Merchant API Latest Updates
5. Google Merchant Center Help — Item Group ID
6. Google Search Central — Product Variant Structured Data