Ürün Sayfalarında Yapılandırılmış Veri Nasıl Kurgulanmalı?

Çoğu e-ticaret sitesinde ürün şeması teknik olarak “çalışıyor”: Rich Results Test yeşil yanıyor, Search Console hata vermiyor, kimse şikâyetçi değil. Ama aynı sitede kargo süresi, iade koşulu ve varyant yapısı şemada hiç yok — yani Google ürünü listeliyor, listede öne çıkarmıyor.

Bu yazı, o boşluğu kapatmak için yazıldı. Alan alan ne yazılacağını, hangi değerin geçerli olduğunu ve en çok nerede hata yapıldığını anlatıyor. Tüm kod örnekleri Google Search Central dokümantasyonundan doğrulandı; ilgili sayfalar en son 8 Eylül 2026’da güncellendi.

Önemli Noktalar

• Ürün zengin sonucu için zorunlu olan yalnızca beş alan var: name, image, offers ile price ve priceCurrency.
• shippingDetails ve hasMerchantReturnPolicy zorunlu değil, önerilen. “2026’da zorunlu oldu” diyen kaynaklar yanlış — Google dokümanı bunları hâlâ önerilen alanlar altında listeliyor.
• Merchant Center’da tanımlı kargo ve iade ayarları, sayfadaki şemayı geçersiz kılar. Google’ın yayınladığı net bir öncelik sırası var ve çoğu ajans bunu bilmiyor.
• İade politikası için Google Organization seviyesini tercih ediyor; ürün seviyesi yalnızca istisna içindir ve daha az alan destekler.
• returnPolicyCategory için yalnızca üç geçerli değer, availability için on değer var. Yanlış enum, sessiz bir hata kaynağı.
• JavaScript ile üretilen şema, tarama sıklığını düşürebilir. Google ilk HTML’de bulunmasını öneriyor.

İki Farklı Zengin Sonuç: Hangisini Hedefliyorsunuz?

Başlamadan önce ayırmanız gereken bir şey var, çünkü gereksinimler farklı.

	Satıcı ürün listelemesi	Ürün snippet’i
Hangi sayfa	Kullanıcının satın alabildiği sayfa	İnceleme, karşılaştırma, editoryal
Fiyat	Her zaman içerir	Zorunlu değil
Offer	Zorunlu (AggregateOffer kabul edilmez)	Offer veya AggregateOffer olabilir
Search Console	Satıcı ürün listeleme raporu	Ürün snippet’i raporu

Bir e-ticaret sitesiyseniz hedefiniz satıcı ürün listelemesi. Google bunu net söylüyor: yalnızca alışverişçinin ürünü satın alabildiği sayfalar bu deneyime uygun. Editoryal veya karşılaştırma içeriği yayınlıyorsanız hedefiniz ürün snippet’i olur.

Bir sınır daha var: ürün zengin sonuçları şu an yalnızca tek bir ürüne odaklanan sayfaları destekliyor (veya aynı ürünün varyantlarını). Kategori sayfasına otuz ürünün şemasını basmak işe yaramaz.

Zorunlu Alanlar: Minimum Geçerli İşaretleme

Şemanızın geçerli sayılması için gereken tam liste bu kadar:

Product seviyesinde:

• name
• image
• offers

Offer seviyesinde:

• price (veya priceSpecification.price)
• priceCurrency (ISO 4217 — Türkiye için TRY)

Minimum geçerli hali şöyle görünür:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "925 Ayar Gümüş Minimal Kolye",
  "image": [
    "https://ornek.com/kolye-1x1.jpg",
    "https://ornek.com/kolye-4x3.jpg",
    "https://ornek.com/kolye-16x9.jpg"
  ],
  "offers": {
    "@type": "Offer",
    "price": 2499.0,
    "priceCurrency": "TRY"
  }
}

Görsel için üç en boy oranı (1:1, 4:3, 16:9) vermek Google’ın önerisi — farklı yüzeyler farklı oran kullanıyor.

Bu şema geçerlidir ama eksiktir. Search Console’da hata vermez, uyarı verir. Aradaki fark önemli:

• Hata (Error): Zorunlu alan yok veya geçersiz → öğe zengin sonuç için tamamen uygunsuz.
• Uyarı (Warning): Önerilen alan yok → öğe hâlâ uygun, ama daha az zengin görünür.

Çoğu e-ticaret sitesinin sorunu hata değil, uyarı yığını. Yani görünüyorsunuz, ama rakibinizin listesinde kargo süresi ve iade rozeti varken sizinkinde yok.

Önerilen Alanlar: Asıl Farkı Yaratanlar

Zorunluların ötesinde Google’ın önerdiği alanlar, listede öne çıkmanızı sağlayan kısım.

Product seviyesinde: brand.name, description, sku, gtin (veya gtin8/gtin12/gtin13/gtin14/isbn), mpn, category, color, material, pattern, size, audience, aggregateRating, review, hasCertification (en fazla 10), inProductGroupWithID, isVariantOf

Offer seviyesinde: availability, itemCondition, url, priceValidUntil, validFrom, validThrough, shippingDetails, hasMerchantReturnPolicy

Son iki alanın altını çizelim, çünkü sektörde yanlış biliniyor.

Yaygın yanlış bilgi

2026’da birçok kaynak “shippingDetails ve hasMerchantReturnPolicy artık zorunlu” yazdı. Bu doğru değil. Google’ın dokümantasyonu — hem İngilizce hem Türkçe — bu iki alanı hâlâ önerilen özellikler başlığı altında listeliyor. Eksik olmaları zengin sonuç uygunluğunuzu bitirmez; yalnızca kargo ve iade zenginleştirmelerini kaybedersiniz.

Ama “zorunlu değil” ile “önemsiz” aynı şey değil. 2027 e-ticaret trendleri yazımızda anlattığımız saha vakasında, 450 SKU’lu bir mağazada tam olarak bu alanları eklemek üç ayda ücretsiz listelemelerde %80 görünürlük artışı getirdi. Zorunlu olmayan alanlar, rekabetin olduğu yer.

Kargo Bilgisi: shippingDetails

OfferShippingDetails üç parçadan oluşuyor: ücret, hedef bölge ve süre.

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "shippingRate": {
    "@type": "MonetaryAmount",
    "value": 49.90,
    "currency": "TRY"
  },
  "shippingDestination": {
    "@type": "DefinedRegion",
    "addressCountry": "TR"
  },
  "deliveryTime": {
    "@type": "ShippingDeliveryTime",
    "handlingTime": {
      "@type": "QuantitativeValue",
      "minValue": 0,
      "maxValue": 1,
      "unitCode": "DAY"
    },
    "transitTime": {
      "@type": "QuantitativeValue",
      "minValue": 1,
      "maxValue": 3,
      "unitCode": "DAY"
    }
  }
}

Buradaki ayrım çoğu uygulamada karıştırılıyor:

• handlingTime — siparişin hazırlanma süresi. Sizin depo sürecinizdir.
• transitTime — kargonun yolda geçirdiği süre. Kargo firmasının süresidir.

Toplam teslimat süresi ikisinin toplamıdır. Yalnızca birini vermek, kullanıcıya yanlış beklenti kurdurur. unitCode değeri "DAY" olarak yazılır.

Ücretsiz kargo veriyorsanız value alanına 0 yazarsınız — alanı boş bırakmak yerine sıfır yazmak, bilginin var olduğunu söyler.

İade Politikası: hasMerchantReturnPolicy

Burada Google’ın net bir tercihi var ve çoğu uygulama bunu tersine yapıyor.

Organization seviyesi mi, ürün seviyesi mi?

Google, site geneli standart iade politikanızı Organization seviyesinde tanımlamanızı istiyor. Temmuz 2025’teki güncellemeyle bunu daha da netleştirdi: satıcı düzeyindeki iade politikaları Organization işaretlemesi altında tanımlanmalı.

Ürün seviyesindeki Offer.hasMerchantReturnPolicy ise istisna içindir — belirli bir ürünün farklı bir iade koşulu varsa. Üstelik ürün seviyesi, Organization seviyesinin yalnızca bir alt kümesini destekliyor.

Pratik kural: politikanız tüm ürünlerde aynıysa Organization seviyesinde bir kez tanımlayın, her ürün sayfasında tekrarlamayın.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Örnek Mağaza",
  "url": "https://ornek.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "applicableCountry": "TR",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 14,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

Geçerli değerler — üç kategori, o kadar

returnPolicyCategory için yalnızca üç geçerli değer var. Başka bir şey yazmak sessiz bir hatadır:

Değer	Anlamı
MerchantReturnFiniteReturnWindow	Belirli gün sayısı — merchantReturnDays zorunlu
MerchantReturnUnlimitedWindow	Süresiz iade
MerchantReturnNotPermitted	İade kabul edilmiyor

returnMethod için: ReturnByMail, ReturnInStore, ReturnAtKiosk.

returnFees için: FreeReturn, ReturnFeesCustomerResponsibility, ReturnShippingFees. Son değeri kullanıyorsanız returnShippingFeesAmount alanını da doldurmanız gerekir.

Türkiye için not: 14 gün yasal minimum

Mesafeli satış sözleşmelerinde tüketicinin 14 günlük cayma hakkı yasal bir zorunluluk. Yani merchantReturnDays değeriniz en az 14 olmalı.

Ama burada kaçırılan bir fırsat var: birçok Türk e-ticaret sitesi 30 gün iade veriyor ve bunu şemada belirtmiyor. Yasal minimumun üstündeki her gün, öneri motorlarının ve kullanıcının gördüğü bir avantaj. Politikanız 30 günse şemaya 30 yazın.

Merchant Center Öncelik Kuralı

Bu bölüm, bu yazının en önemli kısmı olabilir — çünkü Türkçe kaynaklarda neredeyse hiç geçmiyor ve yanlış anlaşıldığında saatlerce boşa uğraşılıyor.

Google, kargo ve iade verisi için açık bir öncelik sırası yayınlıyor. En güçlüden en zayıfa:

1. Content API for Shopping (hesap düzeyinde kargo ayarları)
2. Merchant Center veya Search Console’daki ayarlar
3. Ürün düzeyinde satıcı ürün listeleme işaretlemesi (sayfadaki JSON-LD)
4. Kuruluş düzeyinde işaretleme (Organization)

Bunun pratik anlamı şu: Merchant Center’da kargo ayarı tanımlıysa, sayfanızdaki shippingDetails değerleri geçersiz kılınır.

Yani Merchant Center’da “3-5 gün” yazıyorsa ve şemanızda “1-3 gün” yazıyorsa, Google 3-5 günü kullanır. Şemayı düzeltmek sorunu çözmez; Merchant Center’ı düzeltmeniz gerekir.

Sahada en sık gördüğümüz kafa karışıklığı bu. Ajans şemayı mükemmel kuruyor, sonuç değişmiyor, çünkü üst katmanda çelişen bir ayar duruyor. Önce Merchant Center’a bakın, sonra şemaya.

Search Console’daki Kargo ve İade ayarlarını kullanabilmek için Merchant Center hesabınızın Search Console mülkünüzle ilişkilendirilmiş olması gerekiyor. Merchant Center tarafındaki çalışmaları Merchant Center ve ürün feed optimizasyonu kapsamında yürütüyoruz.

Fiyat ve Stok

price ve priceSpecification birlikte kullanılmaz

Google’ın kuralı net: ikisini birden aktif fiyat için kullanırsanız, offers.price kullanılır ve priceSpecification yok sayılır.

Aktif fiyat için basitçe price yazın. priceSpecification, yalnızca ek fiyat tipleri içindir — üstü çizili fiyat veya üye fiyatı gibi.

İndirimli ürün, üstü çizili eski fiyatla birlikte:

"offers": {
  "@type": "Offer",
  "price": 1999.00,
  "priceCurrency": "TRY",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 2499.00,
    "priceCurrency": "TRY"
  }
}

availability: on geçerli değer

https://schema.org/ öneki ile: InStock, OutOfStock, PreOrder, PreSale, BackOrder, SoldOut, LimitedAvailability, InStoreOnly, OnlineOnly, Discontinued.

Bu listenin dışında bir şey yazmak — "Stokta" gibi Türkçe bir değer veya "available" gibi uydurma bir enum — geçersiz değer hatası üretir.

priceValidUntil tuzağı

Bu alan zorunlu değil, ama geçmiş bir tarih içeriyorsa listelemeniz görünmeyebilir.

Tema varsayılanlarında sabit bir tarih bırakılması çok yaygın bir hata. Sitenin şemasında "priceValidUntil": "2024-11-20" yazıyorsa, o tarih geçtiği için zengin sonuç sessizce kaybolur ve kimse fark etmez. Bu alanı ya dinamik üretin ya da hiç kullanmayın.

Puan ve Yorumlar

AggregateRating için zorunlu alanlar: ratingValue ve ratingCount veya reviewCount (en az biri). İkisini birden vermek en güvenlisi.

Review için: author, reviewRating ve reviewRating.ratingValue.

Kendi kendine puan verme kuralı — doğru anlaşılmalı

Google’ın “self-serving review” yasağı sıkça yanlış yorumlanıyor. Kural şu: bir varlık kendisi hakkındaki yorumları kontrol ediyorsa, LocalBusiness veya Organization yapılandırılmış verisi kullanan sayfaları yıldız özelliği için uygun değildir.

Dikkat: bu yasak Organization ve LocalBusiness tipleri içindir. Product için geçerli değildir.

Yani bir e-ticaret sitesi kendi ürün sayfasında müşteri yorumlarını işaretleyebilir. Yasak olan, işletmenin kendi hakkındaki puanını Organization şemasıyla işaretlemesidir. Bu ayrımı bilmeyen birçok site, ürün yorumlarını gereksiz yere şemadan çıkarıyor.

Varyantlar: ProductGroup Ne Zaman Kullanılır?

Renk ve beden gibi varyantları olan ürünlerde ProductGroup devreye girer.

Karar şeması basit:

Durum	Yaklaşım
Tüm varyantlar tek canonical URL’de	ProductGroup + hasVariant (Google’ın önerdiği)
Her varyantın ayrı sayfası var	Her sayfada ProductGroup tekrarlanır, diğerleri url ile linklenir
CMS şemayı bağımsız üretiyor	isVariantOf ile referanslama

Nested yapı — Google’ın en kompakt ve doğal dediği hali:

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Yün Kışlık Mont",
  "url": "https://ornek.com/yun-mont",
  "brand": { "@type": "Brand", "name": "Örnek Marka" },
  "productGroupID": "44E01",
  "material": "yün",
  "variesBy": ["https://schema.org/size", "https://schema.org/color"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "44E01-M11000",
      "name": "Yün Kışlık Mont - Yeşil, S",
      "color": "Yeşil",
      "size": "S",
      "image": "https://ornek.com/mont-yesil-s.jpg",
      "offers": {
        "@type": "Offer",
        "url": "https://ornek.com/yun-mont?beden=s&renk=yesil",
        "price": 3499.0,
        "priceCurrency": "TRY",
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}

Dikkat edilecekler:

• variesBy değerleri tam schema.org URL’i olmalı — "color" değil, https://schema.org/color.
• Her varyantın benzersiz bir kimliği olmalı (sku veya gtin).
• Tek sayfalı yapıda varyantlar sorgu parametresiyle önseçilebilmeli.
• productGroupID, üst grup kimliğidir ve grup seviyesinde bir kez yazılır.

Yaygın Hatalar

Sahada en sık gördüklerimiz:

Sayfada olmayan veriyi işaretlemek. Google’ın politikası net: okuyucuya görünmeyen içeriği işaretlemeyin. Ürün sayfasında yazmayan bir iade süresini şemaya yazmak ihlaldir.

Fiyatı metin olarak yazmak. "price": "2.499,00 ₺" geçersizdir. Sayı olarak, nokta ondalık ayırıcıyla: "price": 2499.00. Para birimi ayrı alanda.

Geçersiz enum değeri. Türkçe veya uydurma değerler ("Stokta", "iade var") sessizce geçersiz sayılır.

Statik priceValidUntil. Yukarıda anlatıldı — en sinsi hatalardan biri, çünkü bir gün çalışıp ertesi gün çalışmayı bırakır.

İade politikasını her ürüne kopyalamak. Organization seviyesinde bir kez tanımlanması gerekirken her ürün sayfasında tekrarlanıyor. Çalışır ama gereksiz ve bakımı zordur.

Merchant Center ile çelişen değerler. Öncelik kuralı nedeniyle şemadaki doğru değer bile görünmeyebilir.

Bir de rahatlatıcı bir nokta: yapılandırılmış veri ihlalleri manuel işlem ile zengin sonuç uygunluğunuzu kaldırabilir, ancak normal arama sıralamanızı etkilemez. “Schema hatası sıralamamı düşürür” yaygın bir mittir.

Doğrulama: Üç Adımlı İş Akışı

Sıra önemli:

1. validator.schema.org — Sözdizimi ve yapı kontrolü. Schema.org spesifikasyonuna uygun mu?
2. Rich Results Test — Google uygunluğu. Hangi zengin sonuca uygunsunuz, hangi uyarılar var?
3. Search Console — Yayın sonrası izleme. Satıcı ürün listeleme raporu ve ürün snippet’i raporu ayrı ayrı izlenir.

Üçüncü adımı atlamayın: şablon veya sunucu kaynaklı sorunlar çoğu zaman yayından sonra ortaya çıkar. Google’ın kendi ifadesiyle, dağıtımdan sonra sayfalar bozulabilir.

Eski Structured Data Testing Tool emekliye ayrıldı; hâlâ onu öneren içerikler güncel değil.

Platform Tarafı: Şema Nerede Üretilmeli?

Burada kaynaklandırabileceğimiz en güçlü kural şu: şema ilk HTML’de bulunmalı.

Google’ın ifadesi net — en iyi sonuç için Product işaretlemesi başlangıç HTML’inde yer almalı; JavaScript ile üretilen işaretleme tarama sıklığını düşürebilir.

Bunun pratik sonucu: şemayı istemci tarafında enjekte eden uygulamalar yerine tema veya şablon seviyesinde, sunucu tarafında üretmek daha güvenli.

Platform temalarının ürettiği varsayılan şemada tipik olarak eksik kalanlar: shippingDetails, hasMerchantReturnPolicy, gtin/sku, aggregateRating ve varyant yapısı. Bunlar Search Console’da hata değil uyarı olarak görünür — yani kayıp sessizdir. Bu gözlem kendi müşteri projelerimize dayanıyor; platformlar tema ve sürüme göre farklılık gösterir, kendi mağazanızda Rich Results Test ile doğrulamanız gerekir.

Platforma özel çalışmayı Shopify, İdeaSoft, ikas ve T-Soft mağazaları için e-ticaret SEO hizmetimiz kapsamında yürütüyoruz.

Bir Not: Sadakat Programı Türkiye’de Yok

Google 2025’te üyelik programları için şema desteği ekledi — MemberProgram ve üye fiyatlandırması. Faydalı bir özellik, ama şu an yalnızca Avustralya, Brezilya, Kanada, Fransa, Almanya, Meksika, Birleşik Krallık ve ABD’de kullanılabiliyor.

Türkiye bu listede yok. Üyelik indirimi veren bir siteyseniz bu işaretlemeyi eklemek şu an sonuç üretmez. Takip listenize alın, uygulama listenize değil.

Küçük bir teknik not: priceType ve validForMemberTier aynı UnitPriceSpecification içinde birlikte kullanılırsa, fiyat spesifikasyonu tamamen yok sayılır.

Uygulama Sırası

Sıfırdan kuruyorsanız veya mevcut şemayı düzeltiyorsanız:

1. Merchant Center ayarlarını kontrol edin. Öncelik kuralı nedeniyle ilk bakılacak yer burası. Kargo ve iade ayarları tanımlıysa şemayla tutarlı olmalı.
2. Zorunlu beş alanı doğrulayın. Rich Results Test’te hata yoksa bu adım tamam.
3. Organization seviyesinde iade politikasını tanımlayın. Bir kez, site geneli.
4. shippingDetails ekleyin. handlingTime ve transitTime ayrı ayrı.
5. availability, sku, gtin, brand alanlarını tamamlayın.
6. Varyantlı ürünlerde ProductGroup yapısını kurun.
7. priceValidUntil varsa dinamik olduğundan emin olun veya kaldırın.
8. Search Console’da iki raporu da izlemeye alın.

İlk üç madde bir günlük iş. Dördüncü ve beşinci madde ürün sayısına göre değişir — 2027 trendleri yazımızdaki vakada 450 ürün için toplam süreç üç ay sürdü, ama ajan arayüzü kullanarak veri girişi kısmını saatlere indirdik.

Sonuç

Ürün şeması, “hata almıyorum” ile “listede öne çıkıyorum” arasında büyük bir fark barındırıyor. Zorunlu beş alan sizi listeye sokar; kargo, iade, varyant ve stok bilgisi sizi listede görünür kılar.

En sık atlanan iki nokta şunlar: Merchant Center’ın şemayı geçersiz kılabildiği ve iade politikasının Organization seviyesine ait olduğu. İkisi de Google dokümantasyonunda açıkça yazıyor ama sahada nadiren uygulanıyor.

Bir de kalıcı bir alışkanlık önerisi: şemayı bir kez kurup unutmayın. Tema güncellemeleri, fiyat yapısı değişiklikleri ve sabit tarihler sessizce bozar. Search Console’daki iki raporu aylık kontrol listenize alın.

Ürün şemanızın mevcut durumunu ve hangi alanların eksik olduğunu görmek isterseniz, e-ticaret SEO hizmetimiz kapsamında yapılandırılmış veri ve feed denetimi yapıyoruz. Teknik altyapı tarafındaki çalışmalar için teknik SEO sayfamıza bakabilirsiniz. Mağazanızın tamamını tek elden büyütmemizi isterseniz e-ticaret ajansı sayfamızda nasıl çalıştığımızı anlatıyoruz.

Nereden başlayacağınızı konuşmak isterseniz ücretsiz büyüme analizi için bize yazabilirsiniz.

---

Bu yazı Emir Bengiserp tarafından yazıldı. Benji’s Digital kurucusu; 15+ yıldır e-ticaret markalarında SEO, performans pazarlaması ve ürün verisi tarafında çalışıyor.

Son güncelleme: 19 Eylül 2026. Kaynak olarak kullanılan Google Search Central dokümantasyon sayfaları 8 Eylül 2026’da güncellendi; bu alan sık değiştiği için gereksinimleri düzenli olarak yeniden kontrol ediyoruz.

← Blog ana sayfasına dön