Product şeması ile fiyat stok ve yıldız puanı arama sonucunda nasıl görünür?

Aynı sorguda iki ürün sayfası alt alta çıktığında aradaki fark başlığı okumadan önce fark edilir. Birinin altında iki satır gri açıklama vardır. Diğerinin altında sarı yıldız sırası, kaç kişinin puan verdiği, güncel fiyat ve stok durumu görünür. İkinci sonuç henüz tıklanmadan üç soruya cevap vermiştir: ürün var mı, kaça satılıyor, alanlar memnun kalmış mı. Aynı listede duran düz mavi link ise bu soruların hiçbirine cevap vermez ve kullanıcı cevabı bulmak için tıklamak yerine bir alttaki sonuca bakar.

Bu görsel fark tesadüf değildir. Zengin görünen sonucun kaynak kodunda Product yapılandırılmış verisi vardır ve o veri Google'a fiyatın hangi sayı, stok durumunun hangi değer, puanın hangi ölçekte olduğunu ayrı ayrı söyler.

Yıldız ve fiyat arama sonucuna nereden geliyor?

Product şeması, schema.org sözlüğündeki Product türünü kullanarak bir sayfadaki ürünün adını, görselini, fiyatını, stok durumunu ve puanını makine tarafından okunabilir biçimde tanımlayan yapılandırılmış veri bloğudur. Google için önerilen biçim JSON-LD'dir, yani sayfanın görünen HTML'ini bozmadan bir script etiketi içine yerleştirilen veri paketidir.

Şema ailesinin birçok üyesi arama sonucunda doğrudan bir şey üretmez, yalnızca sayfanın ne hakkında olduğunu netleştirir. Product bu açıdan ayrışır: doğru kurulduğunda çıktısı görünür. Puan yıldızları, değerlendirme sayısı, fiyat ve stok durumu sonucun altında metin sonucu biçiminde belirebilir, ürün alışveriş bilgi panelinde ve popüler ürün sonuçlarında yer alabilir.

Buradaki fiil önemlidir. Google'ın kendi ifadesiyle yapılandırılmış veri bir özelliğin var olmasını sağlar, ileride var olacağını garanti etmez. İşaretleme sayfayı uygun hale getirir, gösterim kararı Google'a aittir ve doğru işaretlenmiş bir sayfa bile zengin sonuç almayabilir. Bu yüzden Product şemasını bir sıralama aracı gibi değil, sayfanın halihazırda taşıdığı ticari bilgiyi kaybolmadan iletme aracı gibi düşünmek doğru olur. Katalog ölçeğinde bu işin nereye oturduğunu görmek için e-ticaret SEO'nun klasik SEO'dan nerede ayrıldığını incelemek yararlıdır.

Ürün snippet'i mi satıcı ürün listelemesi mi?

Product işaretlemesine başlamadan önce cevaplanması gereken tek soru vardır: kullanıcı bu sayfadan ürünü satın alabiliyor mu?

Cevap evet ise sayfa satıcı ürün listelemesi deneyimine adaydır. Bu deneyim fiyat, stok durumu, kargo ve iade bilgisi gibi satışa dair spesifik verileri öne çıkarır ve alışveriş bilgi paneli, Google Görseller, popüler ürün sonuçları gibi yüzeylere uygunluk kapısıdır.

Cevap hayır ise, yani sayfa bir ürün incelemesi, editoryal yorum veya karşılaştırma içeriğiyse, sayfa ürün snippet'i deneyimine adaydır. Burada öne çıkan şey puan, yorum bilgisi ve fiyat aralığıdır.

Bu ayrım kozmetik değildir. İki deneyimin zorunlu alan listesi farklıdır, Search Console'da iki ayrı raporla izlenirler ve aynı sayfa için farklı uyarılar üretebilirler. Satıcı listelemeleri raporu tüketicinin ürünü satın alabileceği sayfalar içindir; ürün snippet'leri raporuna ise yalnızca satıcı harici listeleme sayfaları için bakılması gerekir. Kavramın kendisine yabancıysanız e-ticaretin temel işleyişi bu ayrımın neden bu kadar keskin olduğunu da açıklar.

Zorunlu alanlar iki deneyimde nasıl ayrışıyor?

Aşağıdaki tablo Google'ın iki deneyim için tanımladığı asgari alan setini karşılaştırır. Önerilen alanlar bu tabloya girmez, çünkü onlar uygunluğu değil kalite ve zenginliği belirler.

Tablodaki iki satır pratikte en çok hataya yol açan yerlerdir. Birincisi, satıcı listelemesinde AggregateOffer kabul edilmez, çünkü bu deneyime uygun olmak için satıcının ürünün gerçek satıcısı olması gerekir ve fiyat aralığı değil tek bir etkin fiyat beklenir. İkincisi, ürün snippet'inde offers alanını review veya aggregateRating olmadan tek başına verirseniz doğrulama aracı ürün snippet'leri bölümünde uyarı gösterebilir.

Offers bloğunda fiyatın doğru yazılması

Fiyat iki yerden verilebilir: doğrudan offers.price alanında veya offers.priceSpecification içine yerleştirilerek. İkisini birden yazarsanız Google offers.price değerini kullanır ve priceSpecification alanını yok sayar. Yani karmaşık fiyatlandırmayı priceSpecification ile anlatıp bir yandan eski bir price değerini blokta unutmak, sessizce yanlış fiyatın okunmasına yol açar.

Para birimi üç harfli ISO 4217 biçiminde yazılır, Türk lirası için TRY. Ondalık ayırıcı olarak virgül değil nokta kullanılır, çünkü işaretleme sayı biçimini yerel yazım kurallarına göre değil standart biçime göre okur.

priceValidUntil alanı bir tuzak barındırır. Geçmiş bir tarih yazılmışsa girişiniz gösterilmeyebilir. Kampanya bittiğinde bu tarihi güncellemeyen sistemler, kampanya sırasında kazandıkları zengin sonucu kampanyadan haftalar sonra sessizce kaybeder ve sebebini genelde başka yerde arar.

availability değerleri ve hangisini seçmeli

Stok durumu serbest metin değildir, tanımlı bir değer listesinden seçilir. URL ön eki olmadan kısa adlar da desteklenir, yani InStock ile https://schema.org/InStock aynı anlama gelir. Listeden durumu en iyi anlatan tek değeri seçmek gerekir.

• InStock: ürün stoktadır.
• OutOfStock: ürün şu anda stokta yoktur.
• SoldOut: ürün bitmiştir.
• LimitedAvailability: stok sınırlı sayıdadır.
• BackOrder: ürün geri dönen siparişte olan bir üründür, yani stok yoktur ama sipariş alınıp sonradan karşılanacaktır.
• PreOrder: ürün için ön sipariş verilebilir.
• PreSale: ürün genel satışa çıkmadan önce sipariş edilip teslim edilebilir.
• InStoreOnly: ürün yalnızca fiziksel mağazadan satın alınabilir.
• OnlineOnly: ürün yalnızca internette mevcuttur.
• Discontinued: ürün kullanımdan kaldırılmıştır.

Aradaki nüanslar operasyonel karşılık taşır. OutOfStock ile Discontinued arasındaki fark, ürünün geri geleceği ile bir daha satılmayacağı arasındaki farktır. BackOrder ile PreOrder arasındaki fark ise mevcut bir ürünün stoğunun tükenmesi ile henüz piyasaya çıkmamış bir ürünün sipariş edilmesi arasındaki farktır. Bu değerleri stok yönetim sistemine gerçekten bağlamak yerine hepsini InStock sabitine kilitlemek, kullanıcıyı stokta olmayan sayfaya göndermek anlamına gelir ve bu davranışın karşılığı yanıltıcı işaretleme kategorisidir.

aggregateRating ve review alanlarında kim ne puan verebilir?

Puan bloğunun asgari şartı sanıldığından basittir. ratingValue yanında ratingCount veya reviewCount alanlarından en az birinin bulunması gerekir. Puan başka bir türün içine aggregateRating olarak yerleştirildiğinde itemReviewed alanı çıkarılabilir, ancak değerlendirilen öğenin adı yine sağlanmalıdır.

Ölçek konusunda varsayılan davranış şudur: düz bir sayı verirseniz Google 5 puanlık ölçek varsayar, 1 en düşük 5 en yüksektir. Farklı bir ölçek kullanıyorsanız bestRating ve worstRating alanlarını eklemeniz gerekir, çünkü 88 değeri 5'lik ölçekte anlamsızdır ama bestRating: 100 ile birlikte anlamlıdır. Kesir ve yüzde biçimleri (örneğin 60% veya 6/10) ölçeği kendi içinde taşıdığı için ayrıca tanımlanmalarına gerek yoktur.

Asıl kritik kısım alan adları değil, puanın kaynağıdır. Google'ın yorum snippet'i yönergeleri dört sınır çizer:

• İşaretlenen puan sayfada kullanıcıya görünür olmalıdır. aggregateRating kullanıyorsanız kullanıcı o toplu puanı sayfada görebilmelidir.
• Puan belirli bir öğe hakkında olmalıdır, bir kategori veya öğe listesi hakkında değil.
• Sayfada birden fazla bireysel yorum işaretliyorsanız bu yorumların toplam puanını da eklemeniz gerekir.
• Başka web sitelerinden yorum veya puan toplanmaz ve puanlar doğrudan kullanıcılardan alınmalıdır.

Burada yaygın bir yanlış anlama vardır. "Kendi sitende kendi puanını gösteremezsin" kuralı, Google'ın yönergesinde LocalBusiness ve Organization yapılandırılmış verisi için yazılmıştır: yorumlanan kurum kendisi hakkındaki yorumları kontrol ediyorsa o sayfalarda yıldızlı yorum özelliği kullanılamaz. Ürün sayfaları bu kısıtın hedefi değildir, bir mağaza kendi sattığı ürün için topladığı müşteri puanlarını işaretleyebilir. Ürün tarafında bağlayıcı olan yukarıdaki dört maddedir. Yorumcu adı da ayrı bir detaydır: Person veya Team için geçerli bir ad olmalıdır, "Kara Cuma indirimi" gibi bir pazarlama ifadesi yorumcu adı olarak kullanılamaz.

Örnek bir satıcı listelemesi bloğu

Aşağıdaki blok satıcı ürün listelemesi için asgari zorunlu alanları ve en çok işe yarayan önerilen alanları içerir. Değerler örnektir, gerçek uygulamada bunların hepsi katalog ve stok sisteminden dinamik olarak üretilir.

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Bakır Tabanlı Çelik Tencere 24 cm",
  "image": [
    "https://ornek.com/gorsel/tencere-1x1.jpg",
    "https://ornek.com/gorsel/tencere-4x3.jpg",
    "https://ornek.com/gorsel/tencere-16x9.jpg"
  ],
  "description": "Üç katmanlı tabanı olan 24 cm çelik tencere.",
  "sku": "TNC-24-BK",
  "gtin13": "8691234567890",
  "brand": {
    "@type": "Brand",
    "name": "Örnek Mutfak"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "ratingCount": 128
  },
  "offers": {
    "@type": "Offer",
    "url": "https://ornek.com/urun/celik-tencere-24-cm",
    "price": 1249.90,
    "priceCurrency": "TRY",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceValidUntil": "2027-01-31"
  }
}
</script>

Bu blokta dikkat edilmesi gereken şey alanların varlığı değil, hepsinin sayfadaki görünen bilgiyle birebir aynı olmasıdır. Sayfada 1.199,90 yazıp işaretlemede 1249.90 göndermek, teknik olarak geçerli ama politika olarak yanlış bir kurulumdur.

Varyantlı ürünlerde doğru yaklaşım

Renk ve beden gibi seçenekleri olan ürünlerde her varyantı ayrı bir Product gibi işaretlemek de, hepsini tek bir Product içinde ezmek de eksik çözümdür. Doğru yapı ProductGroup türüdür.

ProductGroup ürün ailesini temsil eder ve zorunlu alanı yalnızca name değeridir, örneğin "Kışlık yün palto". Grubun altındaki her varyant kendi Product tanımına sahiptir ve adı daha spesifik olmalıdır, örneğin "Kışlık yün palto yeşil küçük beden". Grup ile varyantlar iki yönlü bağlanır: gruptan varyantlara hasVariant, varyanttan gruba isVariantOf. Grubun hangi özelliklere göre farklılaştığı variesBy alanında belirtilir (örneğin renk ve beden) ve grup productGroupID ile kimliklenir. Marka, açıklama ve toplu puan gibi tüm varyantlarda ortak olan bilgiler grup düzeyinde verilir, varyant düzeyinde tekrarlanması gerekmez.

Varyantlar ayrı URL'lerde yaşıyorsa ek bir detay devreye girer. ProductGroup tek bir sayfaya ait olmadığı için standart URL'si yoktur; grup tanımı her sayfada tekrarlanır ve her sayfa kendi varyantlarının tam tanımına ek olarak diğer sayfadaki varyanta yalnızca url alanıyla işaret eden bir varyant taşır. Böylece Google varyant ağını gezebilir. Aynı mantığın para birimi tarafındaki karşılığı da nettir: bir ürün birden fazla para biriminde satılıyorsa her para birimi için ayrı URL kullanılır.

Merchant Center ile işaretleme arasındaki iş bölümü

Ürün verisini Google'a iki kanaldan verebilirsiniz: sayfaya yapılandırılmış veri eklemek ve Merchant Center'a feed yüklemek. Bunlar birbirinin alternatifi değildir. İkisini birden sağlamak deneyimlere uygunluğu en üst düzeye çıkarır ve Google'ın veriyi doğru anlayıp doğrulamasına yardımcı olur. Bazı deneyimler iki kaynağı birleştirir; örneğin ürün snippet'leri, sayfadaki işaretlemede bulunmayan fiyatlandırma verisini satıcı feed'inizden alıp kullanabilir.

Kargo ve iade tarafında ise çakışma ihtimali olduğu için Google net bir öncelik sırası tanımlar. En güçlüden en zayıfa: Merchant Center'da gönderilen ürün düzeyindeki feed'ler, Content API ayarları, Merchant Center veya Search Console'daki ayarlar, ürün düzeyindeki satıcı listeleme işaretlemesi, kuruluş düzeyindeki işaretleme. Bu sıra pratikte şu anlama gelir: kargo politikanız sık değişiyorsa ve işaretlemeyi güncel tutmakta zorlanıyorsanız, bu bilgiyi işaretlemeye gömmek yerine Merchant Center veya Search Console tarafında yapılandırmak daha dayanıklı bir çözümdür.

Kategori sayfalarında Product şeması neden çalışmaz?

Ürün zengin sonuçları yalnızca tek bir ürüne veya aynı ürünün varyantlarına odaklanan sayfaları destekler. "Mağazamızdaki ayakkabılar" belirli bir ürün değildir. Google işaretlemenin ürün listeleme veya kategori sayfalarına değil, ürün sayfalarına eklenmesini önerir.

Bu, kategori sayfalarına 40 ürünün Product bloğunu basan eklenti kurulumlarının neden hiçbir zaman yıldız üretmediğini açıklar. Aynı mantık puan tarafında da tekrarlanır: yorum bilgisi belirli bir öğe hakkında olmalıdır, bir kategori veya öğe listesi hakkında değil. Kategori sayfasının SEO değeri yapılandırılmış veriden değil, kendi içerik ve iç bağlantı yapısından gelir.

Manuel işlem riski yaratan uygulamalar

Yapılandırılmış veri yönergeleri birkaç davranışı açıkça yasaklar ve ihlal halinde sayfaya manuel işlem uygulanabilir:

• Sayfanın okuyucularına görünmeyen içeriği işaretlemek. JSON-LD bir puanı, fiyatı veya stok durumunu tanımlıyorsa HTML gövdesi de aynı bilgiyi göstermelidir.
• Sahte yorumlar gibi alakasız veya yanıltıcı içeriği işaretlemek.
• Yapılandırılmış veriyi kullanıcıları aldatmak için kullanmak, başka bir kişi ya da kurumu taklit etmek, sahip olunmayan bir şeyi sahiplenmek veya asıl amacı yanlış tanıtmak.
• Başka sitelerden puan toplayıp kendi sayfasının toplu puanı gibi sunmak.

Yaptırımın kapsamını doğru bilmek gerekir. Yapılandırılmış veriyle ilgili manuel işlem, sayfanın zengin sonuç olarak görünmeye artık uygun olmadığı anlamına gelir; sayfanın Google Web Arama'daki sıralaması bu işlemden etkilenmez. Yani riskin karşılığı sıralama çöküşü değil, görünürlük kaybıdır. Bu kayıp yine de ciddidir, çünkü kaybedilen şey tam olarak yazının başındaki tıklama farkını yaratan görsel avantajdır. Manuel işlem olup olmadığı Search Console'daki Manuel İşlemler raporundan kontrol edilir.

Zengin sonuç kaybettiren sık hatalar

• Sabitlenmiş stok değeri. Tüm ürünlerde availability alanının InStock olarak kalması, stok bittiğinde işaretlemenin yanıltıcı hale gelmesi demektir.
• Fiyat uyuşmazlığı. Sayfada görünen fiyat ile işaretlemedeki fiyatın farklı olması, özellikle indirim uygulanan sayfalarda önbellek kaynaklı olarak sık görülür.
• Geçmiş tarihli priceValidUntil. Kampanya bittikten sonra güncellenmeyen tarih, girişin gösterilmemesine yol açabilir.
• Satıcı sayfasında AggregateOffer. Ürünü siz satıyorsanız tek etkin fiyatı olan Offer gerekir; fiyat aralığı bu deneyime uygun değildir.
• Sıfır fiyat. Satıcı listelemesi sıfırdan büyük bir fiyat bekler, "fiyat için arayın" kurgusunda bu deneyim çalışmaz.
• Puan sayısı olmayan puan. ratingValue yazılıp ratingCount ve reviewCount alanlarının ikisinin de boş bırakılması bloğu geçersiz kılar.
• Görünmeyen toplu puan. Sayfada hiçbir yerde gösterilmeyen bir ortalama puanın işaretlenmesi, doğrudan yönerge ihlalidir.
• Çift işaretleme. Tema ve eklenti aynı sayfaya iki ayrı Product bloğu basınca hangi verinin okunacağı belirsizleşir; bu WordPress ve WooCommerce kurulumlarında en sık karşılaşılan çakışmadır.
• Kategori sayfasına ürün işaretlemesi. Liste sayfalarına basılan Product blokları zengin sonuç üretmez.
• Ondalık virgülü. 1249,90 biçiminde yazılan fiyat, standart biçimde okunmadığı için sorun çıkarır.

Doğrulama ve düzenli izleme

Kurulum sonrası akış üç adımdır. Önce işaretleme test edilir ve kritik hatalar giderilir; kritik olmayan uyarıları düzeltmek uygunluk için şart değildir ama veri kalitesini yükseltir. Test aracının nasıl okunacağı ve hangi uyarının gerçekten aksiyon gerektirdiği zengin sonuç testi doğrulama rehberinde ayrıntılı olarak ele alınıyor.

İkinci adım Google'ın sayfayı sizin gördüğünüz gibi görüp görmediğini kontrol etmektir. URL denetleme aracı burada devreye girer, çünkü robots.txt engeli, noindex etiketi veya giriş gereksinimi varsa işaretlemenin doğruluğu bir işe yaramaz. Fiyat ve stok bilgisini JavaScript ile basan kurulumlarda bu adım isteğe bağlı değildir, zorunludur.

Üçüncü adım süreklilik kurmaktır. Search Console'da satıcı listelemeleri ve ürün snippet'leri raporları hata ve uyarıları sayfa bazında gösterir, arama sonuçları raporu ise zengin sonucun ne sıklıkta göründüğünü ve tıklandığını izlemeye yarar. Katalog büyüdükçe hatalar tek tek değil toplu olarak ortaya çıkar, çünkü aynı şablon binlerce sayfayı üretir. Bu yüzden Product şeması tek seferlik bir kurulum işi değil, stok ve fiyat sistemine bağlı yaşayan bir veri katmanıdır.

Sık sorulan sorular

Product şeması eklemek sıralamamı yükseltir mi?

Hayır. Yapılandırılmış veri sayfayı bir görünüm özelliğine uygun hale getirir, sıralama vaadi taşımaz. Bunun en açık kanıtı yaptırım tarafındadır: yapılandırılmış veriyle ilgili bir manuel işlem uygulandığında sayfa zengin sonuç uygunluğunu kaybeder ama Google Web Arama'daki sıralaması etkilenmez. Şemanın kazandırdığı şey sıra değil, aynı sırada daha fazla bilgi taşıyan bir sonuçtur.

Stok bittiğinde şemayı sayfadan kaldırmalı mıyım?

Kaldırmak yerine availability değerini gerçek duruma çevirmek daha doğrudur. Değer listesinde OutOfStock, SoldOut ve Discontinued gibi seçeneklerin bulunmasının sebebi tam olarak budur. İşaretlemeyi silmek sayfayı doğru hale getirmez, yalnızca sinyalsiz bırakır; yanlış olan stok bilgisinin eksikliği değil, olmayan stoğu var göstermektir.

Puanları başka bir platformdan çekip gösterebilir miyim?

Hayır. Yönergeler diğer web sitelerinden yorum veya puan toplanmasını açıkça dışarıda bırakır ve puanların doğrudan kullanıcılardan gelmesini şart koşar. Dış platformdaki puanı sayfada bilgi olarak göstermek ayrı bir şeydir, o puanı kendi aggregateRating bloğunuz gibi işaretlemek ise yönerge ihlalidir.