Organization yeterli değil: ürün ve marka ayrı varlıklardır

Organization şeması "bu kuruluş nedir" sorusunu cevaplar. Ürün satan bir işletme için bu yeterli değildir — çünkü model, kuruluş ile o kuruluşun sattığı ürünler arasındaki ilişkiyi de ayrı ayrı bilmek ister.

Üç ayrı varlık, üç ayrı şema

Küçük bir işletmede kuruluş ve marka genellikle aynı addır ve Brand alanı Organization içinde kısaca tekrarlanabilir. Holding yapılarında (bir şirketin birden çok marka taşıması) bu ayrım zorunlu hâle gelir — aksi halde model, hangi ürünün hangi şirkete ait olduğunu karıştırır.

Asgari Product şeması

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ürün adı",
  "brand": { "@type": "Brand", "name": "Marka adı" },
  "description": "Kısa, olgusal ürün açıklaması",
  "sku": "ABC-123",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}

brand alanı Product'ı Organization'a bağlar. aggregateRating olmadan bir ürün, hiçbir sosyal kanıt taşımadan tanımlanmış olur — model için "var olan ama doğrulanmamış" bir varlıktır.

Review ve AggregateRating farkı

Bir Review, tek bir kişinin tek bir değerlendirmesidir. AggregateRating birden çok değerlendirmenin toplamıdır. Model için ikincisi daha güçlü bir sinyaldir çünkü tek bir öznel görüşe değil, bir örüntüye dayanır.

Uyarı: Şemadaki puan ve yorum sayısı, sayfada görünen puan ve yorum sayısıyla birebir uyuşmalı. Bu, structured data'daki en sık hatalardan biri olan "şemada olup sayfada olmayan bilgi" kuralının doğrudan bir uygulaması — sahte veya şişirilmiş puan şeması, fark edildiğinde güveni tamamen sıfırlar.

Ne zaman ayrı Brand şeması gerekir

• Bir şirket birden fazla, birbirinden farklı isimli marka satıyorsa
• Bir marka, üretici şirketten farklı bir adla pazarlanıyorsa
• Bayilik/lisans yapısında marka sahibi ile satıcı ayrı kuruluşlarsa

Bu durumların hiçbiri geçerli değilse (küçük, tek markalı işletme), Organization'ın name alanı marka adıyla örtüşür ve ayrı bir Brand bloğu şart değildir — gereksiz karmaşıklık eklemenin bir faydası olmaz.

Varyant ürünlerde sık yapılan hata

Aynı ürünün farklı renk/beden/paket varyantları olduğunda, tek bir Product bloğuna tüm varyantları sıkıştırmak ya da her varyant için tamamen ayrı, birbirinden habersiz Product blokları açmak iki ayrı hataya yol açar.

Doğru desen ProductGroup ve hasVariant:

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Pamuklu Tişört",
  "productGroupID": "TSHIRT-001",
  "variesBy": ["color", "size"],
  "hasVariant": [
    { "@type": "Product", "sku": "TSHIRT-001-S-MAVI", "color": "Mavi", "size": "S" },
    { "@type": "Product", "sku": "TSHIRT-001-M-MAVI", "color": "Mavi", "size": "M" }
  ]
}

Bu yapı olmadan model, "mavi tişört" ile "M beden tişört"ün aynı ürünün iki yüzü mü, yoksa iki ayrı ürün mü olduğunu şemadan çıkaramaz — sayfadaki görsel seçim arayüzüne bakarak tahmin etmek zorunda kalır.

Fiyat geçmişi ve priceValidUntil

Şemadaki fiyat statik bir sayı değil, bir ana ait bir beyandır. priceValidUntil alanı olmadan bir model, önbelleğe alınmış eski bir fiyatı hâlâ geçerli sanabilir — özellikle indirim dönemlerinde bu, structured data'nın en sık yapılan hatalarından biriyle aynı aileden bir sorun: şemanın sayfayla değil, geçmişle uyumlu kalması.

Kontrol listesi

• Şirket ve marka farklı adlar taşıyorsa Brand ayrı tanımlı mı
• Her ürün kendi Product şemasına sahip mi, hepsi Organization'a mı yığılmış
• AggregateRating sayısı sayfada görünen yorum sayısıyla uyuşuyor mu
• Ürün ile marka arasındaki brand bağlantısı doğru kurulmuş mu