Yapısal Veri (Schema Markup) Nedir, Nasıl Eklenir?

Yapısal veri (structured data) ya da yaygın adıyla schema markup, bir web sayfasının içeriğini arama motorlarının ve yapay zekâ sistemlerinin makine düzeyinde anlayabileceği standart bir biçimde tarif eden, çoğunlukla schema.org sözlüğüyle yazılan ve sayfaya genellikle JSON-LD formatında eklenen koddur. Kısacası: insan gözüyle "bu bir ürün sayfası, fiyatı şu, stok durumu bu, yorum puanı şu" diye okuduğunuz şeyi, Google'a açık ve belirsizliğe yer bırakmayan bir dille söylersiniz. Sayfanız bu işaretleme olmadan da taranır, indekslenir ve sıralanabilir; ancak yapısal veri, içeriğin ne anlama geldiğini Google'ın tahmin etmesini beklemek yerine doğrudan beyan etmenizi sağlar. Bu beyan iki yerde işe yarar: bazı içerik tiplerinde arama sonuçlarında zengin sonuç (rich result) görünümleri açar; her durumda ise hem klasik arama motorlarının hem de AI Overviews gibi üretken sistemlerin içeriğinizi daha güvenle yorumlamasına yardımcı olur.

Bu yazı, Alis Dijital'in 10 parçalı SEO rehber kümesinin yapısal veri ayağıdır. Schema markup tek başına bir sihir değneği değildir; sağlam bir temel olan SEO'nun ne olduğu ve nasıl yapıldığı ile, sayfanın teknik altyapısını ele alan teknik SEO denetimi sürecinin üzerine oturur. İşaretleme, içeriğin kendisinin yerini tutmaz; iyi içeriği makinelere doğru tercüme eder. Müşterilerimizde gördüğümüz en yaygın yanılgı, schema'yı "sihirli yıldız üreteci" sanmak; oysa 2026 itibarıyla gerçek tablo çok daha incelikli ve aşağıda bunu olduğu gibi anlatıyoruz.

Yapısal veri nedir, ne işe yarar?

Yapısal veri, sayfanızdaki içeriği önceden tanımlanmış bir şema (kalıp) içine yerleştirerek arama motorlarına "bu sayfa neyle ilgili, içindeki her parça nedir" bilgisini açıkça veren işaretleme yöntemidir. Normal bir HTML sayfasında "1.299 TL" yazısı Google için sadece bir metindir; yapısal veriyle bunu bir Offer (teklif) nesnesinin price (fiyat) alanı olarak işaretlediğinizde, artık bunun bir fiyat olduğu, hangi ürüne ait olduğu ve hangi para biriminde olduğu makine tarafından net biçimde okunur.

Aradaki farkı somutlaştıralım. İşaretsiz bir sayfada Google, "Ahmet Yılmaz" ifadesinin yazar mı, müşteri yorumu sahibi mi, yoksa ürün adının bir parçası mı olduğunu bağlamdan tahmin etmek zorundadır; "12.03.2026" tarihinin yayın tarihi mi, güncelleme tarihi mi, etkinlik tarihi mi olduğunu çıkarsamaya çalışır. Yapısal veriyle bu belirsizlik ortadan kalkar: author alanı yazarı, datePublished alanı yayın tarihini, aggregateRating alanı ortalama puanı doğrudan beyan eder. Tahmin payını sıfıra indirmek, Google'ın içeriğinizi yanlış bağlamda değerlendirme riskini azaltır.

Schema.org, Google, Microsoft (Bing), Yahoo ve Yandex'in ortaklaşa geliştirdiği, yüzlerce nesne tipini (Article, Product, Organization, LocalBusiness, Event, Recipe ve daha fazlasını) ve bu tiplerin özelliklerini tanımlayan ortak bir kelime dağarcığıdır. Yapısal verinin "ne söyleyeceğini" schema.org belirler; "nasıl yazılacağını" ise format belirler. Google'ın bugün önerdiği format JSON-LD'dir (JavaScript Object Notation for Linked Data): işaretlemeyi sayfanın görünür HTML'sine karıştırmak yerine, ayrı bir script bloğunda, temiz ve bakımı kolay bir biçimde tutarsınız. Eski Microdata ve RDFa biçimleri hâlâ desteklense de, JSON-LD'nin yönetilebilirliği onu pratik standart yapmıştır.

Üç biçimin pratikteki farkını kısaca görelim. Microdata ve RDFa, işaretlemeyi doğrudan görünür HTML etiketlerinin içine, itemprop gibi özniteliklerle serpiştirir; içerik HTML'i değiştiğinde işaretleme de kırılmaya açık hâle gelir ve bakımı zorlaşır. JSON-LD ise tüm bilgiyi tek bir bağımsız blokta toplar; tasarım veya şablon değişikliklerinden etkilenmez, sunucu tarafında dinamik olarak üretilmesi kolaydır ve Google'ın açıkça önerdiği biçimdir. Bu yüzden 2026'da yeni bir kurulum yapıyorsanız varsayılan tercihiniz tartışmasız JSON-LD olmalıdır.

Yapısal verinin sağladığı somut faydaları üç başlıkta toplayabiliriz:

• Anlamlandırma (semantic understanding): Google sayfanızın bir makale mi, ürün mü, yerel işletme mi olduğunu, yazarın kim olduğunu, yayın tarihini, fiyatı, puanı tahmin etmek yerine kesin olarak öğrenir. Bu, içeriğin doğru bağlamda değerlendirilmesini kolaylaştırır.
• Zengin sonuç (rich result) uygunluğu: Belirli içerik tiplerinde arama sonucunuz düz mavi linkten daha zengin görünür; ürün için fiyat ve yıldız, makale için üst-hikâye görünümü, yerel işletme için adres ve çalışma saati gibi. Bunun hangi tiplerle hâlâ mümkün olduğunu aşağıda netleştiriyoruz.
• AI ve üretken arama desteği: AI Overviews ve büyük dil modelleri içeriği parçalayıp yorumlarken iyi yapılandırılmış schema, hangi bilginin ne olduğunu açık ettiği için içeriğinizin doğru alıntılanma ihtimalini destekler.

Burada kritik bir ayrımı baştan koymak gerekir: yapısal veri eklemek doğrudan bir sıralama faktörü değildir. Google, schema markup'ın tek başına sayfanızı üst sıralara taşıyan bir sinyal olduğunu söylemez. Onun işlevi içeriği daha anlaşılır kılmak ve uygun olduğunda zengin sonuç görünümleri açmaktır; bu da dolaylı olarak tıklama oranını (CTR) ve görünürlüğü iyileştirebilir. "Schema ekledim, sıralamam fırlayacak" beklentisi gerçekçi değildir; doğru beklenti, "içeriğimi makinelere net anlattım ve uygun yerlerde daha zengin görünüyorum" şeklindedir. Sıralamayı belirleyen asıl unsurlar içeriğin kalitesi, arama amacına uygunluğu ve E-E-A-T sinyalleridir; schema bu temelin üzerine eklenen bir tercüme katmanıdır, temelin kendisi değildir.

Zengin sonuç (rich result) nedir, schema ile ilişkisi nedir?

Zengin sonuç, arama sonuçlarında standart başlık-açıklama-URL üçlüsünün ötesine geçen, görsel olarak zenginleştirilmiş listeleme biçimidir; yıldız puanları, fiyat bilgisi, kırıntı navigasyonu (breadcrumb), ürün stok durumu ya da yayın tarihi gibi ek öğeler içerir. Bu görünümler, sayfanıza uygun ve geçerli yapısal veri eklediğinizde Google'ın uygun gördüğü durumlarda gösterdiği bir sunum biçimidir.

Burada iki noktayı sürekli vurgulamak gerekir. Birincisi: geçerli schema eklemek zengin sonucu hak etme önkoşuludur, ama garantisi değildir. Google işaretlemeyi okur, kalite ve uygunluk değerlendirir ve gösterip göstermeyeceğine kendi karar verir. Aynı işaretleme aynı sorguda bir gün gösterilip başka bir gün gösterilmeyebilir; bu, hata değil Google'ın sunum kararıdır. İkincisi: her schema tipi zengin sonuç üretmez. İşte 2026'da en çok kafa karıştıran ve internette hâlâ eski/yanlış bilgiyle dolaşan kısım tam olarak budur.

FAQ ve HowTo zengin sonuçları: 2026'da gerçek durum

Pek çok eski rehber hâlâ "sayfana FAQPage schema ekle, Google'da açılır SSS kutuları çıksın, sonuçta daha çok yer kapla" der. 2026 itibarıyla bu tavsiye geçerliliğini yitirmiştir ve okuyucuyu yanıltır. Olaylar şöyle gelişti:

• Ağustos 2023'te Google, FAQ zengin sonucunu yalnızca iyi bilinen, otoriter devlet ve sağlık siteleriyle sınırladı. Sıradan işletme, e-ticaret, SaaS veya ajans siteleri o tarihten itibaren FAQ zengin sonucu almayı fiilen bıraktı.
• 2026'da Google FAQ zengin sonucu desteğini tamamen kaldırma sürecini yürütüyor: FAQ arama görünümü, zengin sonuç raporu ve Rich Results Test desteğinin 2026 içinde, Search Console API tarafındaki FAQ desteğinin ise 2026 içinde kaldırılması planlandı.
• HowTo zengin sonucu da benzer kaderi paylaştı. Eylül 2023'te önce mobilde kısıtlandı, ardından masaüstü dahil tamamen kaldırıldı. Yani "HowTo schema eklersen adım adım zengin görünüm çıkar" iddiası da artık geçersizdir.

Bu bilgi önemli, çünkü yanlış beklenti yanlış öncelik doğurur. Bir müşteri "neden FAQ schema ekledik ama hiç açılır kutu çıkmıyor" diye sorduğunda, cevap bir hata ayıklama değil, gerçeği kabul etmektir: o görünüm artık çoğu site için yok. Buna karşılık iki teselli edici nokta var. Birincisi, FAQPage hâlâ geçerli bir schema.org tipidir ve Google bu işaretlemeyi içeriği anlamak için ayrıştırmaya devam eder; görsel zengin sonuç vermese de içerik anlaşılırlığına ve AEO/üretken arama tarafına katkısı sürer. İkincisi, mevcut FAQ/HowTo işaretlemenizi telaşla sökmeniz gerekmez; Google kullanılmayan yapısal verinin Search açısından sorun çıkarmadığını belirtti. Sadece bundan zengin sonuç beklemeyin.

Pratik bir öneri: Sıkça sorulan sorular bölümünü içeriğinizde tutmaya devam edin, çünkü kullanıcı için gerçek değer üretir ve soru-cevap formatı, üretken arama sistemlerinin içeriğinizi alıntılaması için elverişlidir. Yalnızca bu bölüme FAQPage schema eklemenin artık görsel bir SERP kazanımı getirmeyeceğini bilin ve enerjinizi aşağıda anlattığımız, hâlâ karşılığı olan tiplere yönlendirin. Soru biçimli başlıklar ve answer-first yazım, schema'dan bağımsız olarak hem klasik aramada hem de AI Overviews görünürlüğü tarafında işinize yarar.

2026'da hâlâ zengin sonuç veren önemli tipler

İyi haber: yapısal verinin değeri ölmedi, sadece doğru tiplere odaklanmak gerekiyor. 2026 itibarıyla pratikte zengin sonuç üretmeye devam eden başlıca tipler şunlardır:

Bir noktanın altını çizelim: Review ve AggregateRating yıldızları yalnızca Google'ın izin verdiği tiplerde (örneğin Product, Recipe, Course, Book, LocalBusiness) gösterilir; kendi kendine verilmiş, "self-serving" yıldızlar (kendi sitenizi kendiniz puanlayıp anasayfaya yıldız koymak gibi) gösterilmez. E-ticaret tarafında çalışıyorsanız Product işaretlemesinin doğru kurulması doğrudan görünürlük getirir; bu konuyu e-ticaret SEO rehberimizde ürün ve kategori sayfaları bağlamında daha derin ele alıyoruz.

Bu tiplerin pratik karşılığını birkaç örnekle netleştirelim. Bir e-ticaret ürün sayfasında doğru kurulmuş Product + Offer işaretlemesi, sonucunuzun yanında güncel fiyatı ve "stokta var" bilgisini gösterebilir; bu, fiyata duyarlı kullanıcı tıklamadan önce karar verdiği için niteliği yüksek tıklama getirir. Bir blog yazısında Article işaretlemesi yayın tarihini ve yazarı öne çıkararak güncellik algısını destekler. Çok katmanlı bir sitede BreadcrumbList, SERP'te uzun ve okunaksız URL yerine "Anasayfa > Kategori > Ürün" şeklinde anlaşılır bir yol gösterir; bu hem görünümü düzenler hem de kullanıcının sayfanın site içindeki konumunu anlamasını kolaylaştırır. Yerel bir hizmet işletmesinde LocalBusiness işaretlemesi, marka aramalarında adres, telefon ve çalışma saatlerini öne çıkarabilir.

Hangi schema tipinden başlamalı?

Yapısal veriyi ilk kez kuran bir site için tavsiye edilen temel set sade ve nettir: Organization (marka kimliğinizi tanımlar), BreadcrumbList (site içi gezinme yolunu işaretler) ve içeriğe uygun ana tip. Ana tip, sayfanın türüne göre değişir; bir blog yazısında Article/BlogPosting, bir ürün sayfasında Product, bir yerel işletme sayfasında LocalBusiness olur. Bu üçlü temeli kurduktan sonra, sayfanın spesifik zengin sonuç fırsatına göre genişletirsiniz.

Mantığı şudur: önce sitenin kimliğini ve iskeletini makinelere anlatın, sonra sayfa bazında derinleşin. Aşağıdaki tablo, sayfa türüne göre hangi tipten başlamanız gerektiğini özetler:

Bir e-ticaret sitesinde her ürün sayfasına Product + Offer, bir yerel hizmet işletmesinde anasayfaya LocalBusiness, bir haber/blog sitesinde her yazıya Article eklemek tipik bir sıralamadır. Alis Dijital olarak müşteri sitelerinde standart yaklaşımımız tam olarak budur; gereksiz, içerikle eşleşmeyen schema yığını yerine, sayfanın gerçekten temsil ettiği tipi doğru ve eksiksiz işaretlemeyi tercih ederiz. İçerikle uyuşmayan schema (örneğin ürün olmayan bir sayfaya Product koymak, ya da sayfada görünmeyen bir puanı AggregateRating olarak beyan etmek) yarar yerine zarar verir ve Google'ın yapısal veri politikalarını ihlal eder; bu tür uyumsuzluklar manuel işlem riskine kadar uzanabilir. Temel kural: işaretlediğiniz her bilgi, sayfada kullanıcının da görebildiği gerçek içerikle birebir örtüşmelidir.

Schema markup nasıl eklenir ve test edilir?

Yapısal veri eklemenin günümüzdeki standart yolu, sayfanın head ya da body bölümüne bir JSON-LD script bloğu yerleştirmektir. JSON-LD'yi tercih etmenizin nedeni, işaretlemeyi görünür içerikten ayrı tutması, bu sayede hem yazımının hem de bakımının kolay olmasıdır; içerik değiştiğinde işaretlemeyi tek bir blokta güncellersiniz. WordPress, Shopify veya ikas gibi platformlarda bu iş çoğu zaman bir eklenti ya da tema entegrasyonuyla otomatikleşir; ancak otomatik üretilen schema'nın da doğru tip ve eksiksiz alanlarla çıktığını mutlaka denetlemek gerekir.

Süreci pratik adımlara dökelim:

1. Doğru tipi belirleyin. Sayfanın gerçekten ne olduğuna karar verin (makale mi, ürün mü, yerel işletme mi) ve o tipin schema.org'daki zorunlu/önerilen alanlarına bakın.
2. JSON-LD bloğunu oluşturun. Elle yazabilir, bir kütüphaneyle dinamik üretebilir veya platformunuzun eklentisine bırakabilirsiniz. Alanları, sayfada görünen gerçek içerikle aynı değerlerle doldurun.
3. Sayfaya yerleştirin. Bloğu şablona ekleyin; dinamik sitelerde bunu sunucu tarafında üretmek, JavaScript ile sonradan eklemekten daha güvenlidir.
4. Test edin. Aşağıdaki araçlarla uygunluğu ve teknik doğruluğu doğrulayın.
5. Yayına alıp izleyin. Search Console raporlarıyla sahadaki durumu takip edin.

Eklemenin ardından doğrulama şart. Google'ın iki temel aracı vardır ve ikisini de kullanmanızı öneririz:

• Rich Results Test: İşaretlemenizin bir zengin sonuç için uygun olup olmadığını ve hangi görünüme aday olduğunu gösterir. (Unutmayın: FAQ desteği bu araçtan 2026 içinde kaldırılıyor.)
• Schema Markup Validator: İşaretlemenizin schema.org standardına teknik olarak uygun olup olmadığını, eksik veya hatalı alan olup olmadığını doğrular.

İki aracın işlevi farklıdır ve bu fark çoğu zaman karıştırılır: Rich Results Test, "bu işaretleme Google'da bir zengin sonuç görünümüne aday mı" sorusunu yanıtlar; Schema Markup Validator ise "bu işaretleme schema.org standardına teknik olarak uygun mu" sorusunu yanıtlar. Bir işaretleme teknik olarak geçerli olabilir ama herhangi bir Google zengin sonucuna aday olmayabilir (örneğin artık görünüm üretmeyen bir tip). Bu yüzden ikisini birlikte kullanmak, hem standart uyumunu hem de fiili SERP karşılığını görmenizi sağlar.

Yayına aldıktan sonra işiniz bitmez. Google Search Console içindeki "Geliştirmeler" raporları, desteklenen yapısal veri tipleri için sahadaki hataları ve uyarıları gösterir; örneğin bir grup ürün sayfasında zorunlu bir alanın eksik kaldığını burada yakalarsınız. Bu raporları düzenli izlemek, schema'nızın zamanla bozulmadan çalıştığından emin olmanın en sağlam yoludur; özellikle tema güncellemesi veya eklenti değişikliği sonrası işaretlemenin sessizce kırılması sık görülen bir durumdur ve ancak bu raporları takip ederek erken fark edilir. Yapısal verinin teknik sağlığını, sitenizin genel teknik durumuyla birlikte değerlendirmek isterseniz GEO denetim aracımızdan faydalanabilir; daha bütünsel bir kurulum için dijital pazarlama danışmanlığı tarafında ekibimizle çalışabilir ya da hızlı bir başlangıç için ücretsiz analiz talep edebilirsiniz.

Özetle yapısal veri, 2026'da hâlâ değerli ama beklentilerin doğru ayarlanması gereken bir araçtır: doğrudan sıralama yükseltmez, FAQ ve HowTo zengin sonuçları çoğu site için artık geçmişte kaldı; buna karşılık Product, Article, LocalBusiness, BreadcrumbList ve Organization gibi tipler hâlâ somut görünürlük getirir, ve her durumda iyi yapılandırılmış schema hem klasik aramada hem de AI destekli arama deneyiminde içeriğinizin doğru anlaşılmasına hizmet eder. Doğru tip, eksiksiz alanlar ve düzenli doğrulama; formül bundan ibarettir.

2026'da Hangi Schema Türleri Gerçekten Önemli?

Kısa cevap: 2026 itibarıyla yapısal verinin değeri görsel "zengin sonuç" (rich result) getirmesinden çok, Google'ın ve AI motorlarının içeriğinizi doğru anlamasına yardım etmesinde. Bazı schema türleri hâlâ SERP'te yıldız, fiyat, kırıntı navigasyonu gibi gözle görülür zenginleştirmeler sağlarken (Article, Product, BreadcrumbList, LocalBusiness, Organization), bir zamanlar popüler olan FAQPage ve HowTo türleri görsel rich result vermeyi bıraktı. Bu yüzden 2026'da schema seçimini "hangisi gerçekten çıktı veriyor" mantığıyla yapmak gerekiyor; gelişigüzel her türü eklemek değil. Aşağıda en önemli türleri tek tek, ne işe yaradıkları ve hangi içerikte kullanılacaklarıyla birlikte ele alıyoruz. Bu konuyu temelden kavramak isterseniz yapay zekâ aramalarında görünürlük rehberimiz ve genel çerçeve için SEO nedir, nasıl yapılır rehberimiz iyi bir başlangıç olur.

Türlere geçmeden önce: hangisi "rich result" verir, hangisi sadece "anlama" sağlar?

Yapısal veri türlerini 2026'da iki kovaya ayırmak işinizi kolaylaştırır. Birinci kova, Google'ın hâlâ görsel zengin sonuç ürettiği türler: Article/BlogPosting, Product + Offer + AggregateRating/Review, BreadcrumbList, LocalBusiness, Event, Recipe, VideoObject, Course, JobPosting. İkinci kova ise rich result vermeyen ama içeriğin anlaşılırlığına ve marka sinyaline katkı sağlayan türler: Organization (genelde bilgi paneli/marka sinyali için), ve artık görsel sonuç vermeyen FAQPage ile HowTo. Bu ayrım kritik çünkü müşterilerimizde sık gördüğümüz hata, "schema ekledik ama SERP'te hiçbir şey değişmedi" şikâyetinin altında çoğu zaman yanlış türe yanlış beklenti yatması. Bir başka deyişle, yapısal veri sıralamada size doğrudan bir "puan" kazandırmaz; içeriğinizi makineye doğru tanıtır ve uygun türde görsel zenginleştirme fırsatı açar. Aşağıdaki tablo bu durumu netleştiriyor.

Article / BlogPosting: içerik sayfalarının temel türü

Article (ve onun alt türleri BlogPosting, NewsArticle), blog ve rehber içeriğiniz için ana yapısal veri türüdür. Yazının başlığını, yayın ve güncelleme tarihini, yazarını ve yayıncı kuruluşu Google'a net biçimde bildirir. Google bu türü haber ve "üst hikâye" (top stories) görünümlerinde değerlendirebilir; ayrıca yazar ve tarih bilgisini netleştirmesi, içeriğin tazeliğini ve kim tarafından yazıldığını ortaya koyduğu için E-E-A-T sinyalleriyle doğal olarak örtüşür. Burada en kritik nokta yazar alanı (author): gerçek bir kişiye, mümkünse o kişinin kimlik/biyografi sayfasına bağlanan bir yazar tanımı, deneyim ve uzmanlığın makineyle okunabilir kanıtıdır. NewsArticle yalnızca gerçek haber içeriği için uygundur; sıradan blog yazılarında BlogPosting daha doğru bir seçimdir. Doğru başlık ve açıklama yazımı schema'yı tamamlar; bu konuda meta title ve description nasıl yazılır rehberimize ve hızlıca çıktı almak için meta etiket oluşturucu aracımıza göz atabilirsiniz.

Pratikte en sık karşılaştığımız iki hata şu: birincisi, datePublished ile dateModified alanlarının sayfada görünen tarihle uyuşmaması ya da hiç verilmemesi. İçeriği güncellediğinizde dateModified alanını da gerçekten güncellemeniz gerekir; sahte "güncellendi" tarihleri tazelik adına atılan bir kestirme değildir ve uzun vadede güven sinyalinize zarar verir. İkincisi, author alanına kişi yerine doğrudan markanın yazılması. Özellikle deneyim ve uzmanlık (E-E-A-T) çıtasının yüksek olduğu para/sağlık (YMYL) konularında yazarın gerçek bir kişi olması, o kişinin biyografi sayfasına sameAs ile bağlanması belirgin fark yaratır. Bir kontrol listesi olarak Article schema'sında şu alanların dolu ve doğru olduğundan emin olun: headline (sayfadaki H1 ile tutarlı), author (kişi + biyografi linki), datePublished/dateModified, publisher (logo dahil) ve mümkünse image. Bu beş alan, hem haber/üst görünüm uygunluğunu hem de AI motorlarının yazıyı kime, ne zaman ve hangi otoriteye atfedeceğini netleştirir.

Product + Offer + AggregateRating: e-ticaretin kritik türü

E-ticaret için 2026'da en yüksek getirisi olan yapısal veri türü Product'tır; çünkü hâlâ görsel rich result veren ve tıklama oranını doğrudan etkileyen türlerin başında gelir. Product schema tek başına yeterli değildir; gerçek değer Offer (fiyat, para birimi, stok durumu/availability) ve uygunsa AggregateRating veya Review (toplam yıldız ve değerlendirme sayısı) ile birleştiğinde ortaya çıkar. Arama sonucunda ürün fiyatının, stok durumunun ve yıldız puanının görünmesi, kullanıcı henüz tıklamadan ürünü değerlendirmesini sağlar ve nitelikli trafiği artırır. Bu nedenle ürün ve kategori sayfalarınızda Product schema'yı, doğru fiyat ve stok verisini gerçek zamanlı yansıtacak şekilde kurmak gerekir; sayfada görünmeyen ya da yanlış bir fiyatı schema'da göstermek politika ihlalidir ve zarar verir. Bir önemli sınır: AggregateRating/Review yıldızları yalnızca Google'ın izin verdiği ana tiplerde (örneğin Product, Recipe, Course, Book, LocalBusiness) gösterilir; bir işletmenin kendi sitesine kendisi hakkında koyduğu serbest "self-serving" yıldızlar görsel sonuç vermez. E-ticaret yapısal verisini bütünsel ele almak için e-ticaret SEO rehberimiz Product schema'yı ürün ve kategori sayfası bağlamında ayrıntılandırıyor.

Somut bir senaryo üzerinden gidelim. Diyelim ki bir ayakkabı ürün sayfanız var ve farklı numaralarda (varyantlarda) stoğu değişiyor. Doğru kurulumda her varyantın fiyatı ve availability değeri (örneğin InStock, OutOfStock, PreOrder) gerçek envanterle senkron olmalı; aksi halde Google "fiyat eşleşmiyor" ya da "stok dışı ürün satışta gösteriliyor" tipinde uyumsuzluk yakalar ve zenginleştirmeyi geri çekebilir. İndirimli ürünlerde price ile birlikte priceValidUntil alanını vermek, kampanyanın bittiği tarihte schema'nın güncel kalmasını sağlar. AggregateRating tarafında ise iki sayı kritiktir: ratingValue (ortalama puan) ve reviewCount ya da ratingCount (kaç değerlendirmeye dayandığı). Tek bir yorumla 5,0 göstermek hem zayıf bir sinyaldir hem de güveni zedeler; gerçek ve yeterli sayıda değerlendirme biriktiğinde işaretlemek daha sağlıklıdır. Aşağıdaki tablo, bir Product işaretlemesinde fayda getiren ve risk taşıyan uygulamaları karşılaştırıyor.

BreadcrumbList: SERP'te okunabilir gezinme yolu

BreadcrumbList (kırıntı navigasyonu), arama sonucunda sayfanızın ham URL'si yerine "Ana Sayfa › Kategori › Sayfa" biçiminde okunabilir bir yol göstermesini sağlar. Görsel olarak küçük bir fark gibi görünse de iki açıdan değerlidir: kullanıcıya sayfanın site içindeki yerini hemen aktarır, böylece tıklama olasılığını artırır; aynı zamanda Google'a sitenizin hiyerarşik yapısını net biçimde bildirerek taranabilirliği ve sayfalar arası ilişki sinyalini güçlendirir. BreadcrumbList'i kategori derinliği olan her sayfada (özellikle e-ticaret ve çok katmanlı blog/küme yapılarında) kullanmak iyi bir pratiktir. Site yapısı ve iç bağlantı mantığını bir bütün olarak kurmak isterseniz topical authority ve içerik kümesi rehberimiz kırıntı navigasyonunun pillar-cluster yapısıyla nasıl uyumlandığını anlatıyor; teknik kurulumun doğruluğunu denetlemek için ise teknik SEO denetimi rehberimizden yararlanabilirsiniz.

BreadcrumbList'in pratik gücü, görünür kırıntı çubuğuyla yapısal verinin birbirini doğrulamasında yatar: kullanıcının sayfada gördüğü gezinme yolu ile schema'da bildirilen itemListElement sırası aynı olmalı. Sıralamanın mantıksal olması (genelden özele: Ana Sayfa → Kategori → Alt Kategori → Ürün) ve her adımın gerçek, taranabilir bir URL'ye işaret etmesi gerekir. E-ticarette aynı ürüne birden çok yoldan ulaşılabildiği durumlarda (örneğin hem "kadın > ayakkabı" hem "indirim > ayakkabı" altından), kırıntıyı ürünün kanonik kategorisine göre tutarlı kurmak, Google'ın sayfayı tek bir mantıklı konuma yerleştirmesini kolaylaştırır. Bu, pillar-cluster modelinde de aynıdır: küme yazıları, pillar sayfaya giden tutarlı bir kırıntı yoluyla işaretlendiğinde konu otoritesi sinyali güçlenir.

Organization: marka kimliğinin makine tarafından okunması

Organization schema, ana sayfanızda kuruluşunuzun adını, logosunu, iletişim bilgilerini ve sosyal medya profillerini Google'a yapısal olarak bildirir. Tek başına gözle görülür bir rich result vermez; daha çok marka bilgi paneli (knowledge panel) ve genel marka kimliği sinyali için bir temel oluşturur. Doğru kurulduğunda Google logonuzu, resmî hesaplarınızı ve kuruluşunuza dair temel bilgileri tutarlı biçimde eşleştirir. Burada özellikle yerel işletmeler için kritik bir tutarlılık kuralı devreye girer: schema'da verdiğiniz isim, adres ve telefon (NAP) bilgisinin sitenizdeki, dizinlerdeki ve Google İşletme Profilinizdeki bilgilerle birebir aynı olması gerekir. Küçük tutarsızlıklar bile güven ve yerel sıralama açısından zarar verir. Alis Dijital olarak kendi sitemizde de bu tutarlılığı (Kayseri/Kocasinan merkezli kanonik adres) titizlikle yönetiyoruz; çünkü geçmişte yaşanan şehir tutarsızlıkları yerel görünürlüğü doğrudan etkiledi. Marka ve organizasyon sinyallerini stratejik bir bütün hâline getirmek için dijital pazarlama danışmanlığı hizmetimiz kapsamında yapısal veriyi, NAP tutarlılığını ve içerik stratejisini birlikte ele alıyoruz.

Organization işaretlemesinde değeri belirleyen iki alan öne çıkar. Birincisi logo: Google'ın markanızın görselini arama sonuçlarında ve bilgi panelinde tutarlı kullanabilmesi için net, yüksek çözünürlüklü bir logo URL'si vermek gerekir. İkincisi sameAs: resmî sosyal medya hesaplarınızı (LinkedIn, X, Instagram, YouTube vb.) ve varsa kuruluşunuzun Vikipedi/güvenilir referans sayfalarını listeleyerek, "bu kuruluş ile bu hesaplar aynı varlıktır" eşlemesini kurarsınız. Bu, entity (varlık) bazlı arama açısından markanızı tek bir kimlik altında toplar ve AI motorlarının markanızı doğru tanımasına yardım eder. Çok şubeli işletmeler için ipucu: Organization'ı kurumsal kimlik için ana sayfada bir kez kurun, her fiziksel şube içinse aşağıda anlattığımız LocalBusiness'ı ayrı ayrı kullanın. Bu konuyu marka görünürlüğü açısından derinleştirmek için yapay zekâ aramalarında görünürlük rehberimiz entity netliğinin AI motorlarındaki rolünü ele alıyor.

LocalBusiness: yerel işletmeler için adres, saat, telefon

LocalBusiness, fiziksel bir konumu olan işletmeler için adres, çalışma saatleri ve telefon gibi bilgileri Google'a yapısal olarak iletir ve yerel arama sonuçlarında bu bilgilerin zengin biçimde görünmesine zemin hazırlar. Restoran, klinik, ajans, mağaza gibi konuma bağlı işletmelerde Organization yerine (veya onunla birlikte, içeriğe göre) daha spesifik bir LocalBusiness alt türü kullanmak daha doğru sinyal verir. LocalBusiness'ın etkisi, doğru ve eksiksiz bir Google İşletme Profili ile birleştiğinde belirginleşir; schema ve profil birbirini tamamlar. Yine NAP tutarlılığı burada da belirleyicidir. Yerel SEO'yu uçtan uca kurmak için yerel SEO nasıl yapılır rehberimiz ile Google İşletme Profili rehberimiz bu türü saha pratiğiyle birlikte ele alıyor.

Doğru alt tür seçimi LocalBusiness'ta önemlidir: schema.org bir restoran için Restaurant, bir diş kliniği için Dentist, bir mağaza için Store gibi daha özel tipler sunar. Mümkün olan en spesifik alt türü kullanmak, Google'a işletmenizin türünü daha net anlatır. Bu türde sıkça eksik bırakılan ama yüksek değerli alanlar şunlar: openingHoursSpecification (gün ve saat bazında çalışma saatleri; özel tatil günleri dahil), geo (enlem-boylam koordinatları, harita eşlemesi için), telephone ve priceRange. Çalışma saatlerini schema'da gerçek saatlerle ve Google İşletme Profili'ndeki bilgiyle senkron tutmak gerekir; uyumsuz saatler hem kullanıcı güvenini hem de yerel sinyali zedeler. Çok şubeli yapıda her şube için ayrı bir LocalBusiness işaretlemesi ve her birinin kendi tutarlı NAP bilgisi olmalı. Alis Dijital'in kendi kanonik adresinde (Kayseri/Kocasinan) yaptığımız gibi, schema-site-dizin-profil dörtlüsünün adres ve telefonunun birebir aynı olması, geçmişte yaşanan şehir tutarsızlığı tipindeki sorunların önüne geçer.

Review / AggregateRating: yıldızlar ama kurallı

Review ve AggregateRating, ürün ya da hizmete dair toplu yıldız puanını arama sonucunda gösterebilen türlerdir ve doğru kullanıldığında tıklama oranına ciddi katkı sağlar. Ancak 2026'da bu türde dikkat edilmesi gereken net bir sınır var: Google yıldızlı görünümü yalnızca izin verdiği ana tiplerde (örneğin Product, Recipe, Course, Book, LocalBusiness) gösterir. Bir kuruluşun kendi sitesine kendi hakkında koyduğu, dış doğrulaması olmayan serbest yıldızlar (self-serving review) görsel sonuç vermez; bu tür işaretlemeler ya yok sayılır ya da politika ihlali riski taşır. Bu yüzden AggregateRating'i yalnızca gerçek müşteri değerlendirmelerine dayanan ve izin verilen bir ana tipe (genellikle Product veya LocalBusiness) bağlı olduğu durumlarda kullanın. Yıldız sayısını şişirmek veya sahte değerlendirme yansıtmak kısa vadede dahi risklidir ve E-E-A-T'nin merkezindeki Güven (Trust) bileşenine doğrudan zarar verir.

Pratik bir ayrımı netleştirelim: Review (tekil) tek bir değerlendirmeyi, AggregateRating ise birden çok değerlendirmenin ortalamasını ve sayısını temsil eder. E-ticarette genelde işinize yarayan AggregateRating'tir, çünkü "4,6 yıldız, 212 değerlendirme" gibi toplu bir görünüm hem daha güçlü hem de daha güvenilirdir. Yıldızların SERP'te gerçekten çıkması için işaretlemenin bir ürün ya da yerel işletme sayfasına gömülü, sayfada gerçekten görünen değerlendirmelere dayalı olması gerekir; "değerlendirme sayfada yok ama schema'da var" durumu Google için bir uyumsuzluk sinyalidir. Hizmet sitelerinde sık görülen "kendi hakkımızda 5 yıldız" işaretlemesi tam da bu nedenle çalışmaz: dış doğrulaması olmayan, kuruluşun kendi koyduğu serbest yıldızlar gösterilmez. Sürdürülebilir yol, gerçek müşteri değerlendirmelerini biriktirip izin verilen ana tipe bağlamak; manipülasyonun getirisi yokken Trust riski yüksektir.

Event, VideoObject ve JobPosting: niş ama hâlâ çıktı veren türler

Yukarıdaki ana türlerin yanında, içerik tipiniz uyuyorsa hâlâ gözle görülür zenginleştirme veren birkaç değerli tür daha var. Event, konser, webinar, eğitim, fuar gibi tarihli etkinlikler için tarih, yer ve bilet/katılım bilgisini SERP'te öne çıkarır; etkinlik bir yere bağlıysa fiziksel adresi, çevrim içiyse VirtualLocation bilgisini doğru vermek gerekir. VideoObject, sayfaya gömülü videolarınız için küçük resim (thumbnail), süre ve yükleme tarihi gibi bilgileri Google'a iletir; hasPart/Clip ile "önemli anlar" (key moments) işaretleyerek videonun belirli bölümlerine doğrudan atlanmasını sağlayabilirsiniz. JobPosting ise iş ilanlarınızı Google'ın iş arama deneyiminde görünür kılar; maaş aralığı, konum, çalışma türü ve son başvuru tarihi gibi alanların doğru ve güncel olması, ilanın listelenmeye uygun kalması için kritiktir. Bu türlerin ortak kuralı diğerleriyle aynı: schema'da bildirilen her bilgi sayfada gerçekten görünmeli ve güncel olmalı; geçmiş tarihli bir etkinliği ya da kapanmış bir ilanı işaretli bırakmak zenginleştirmeyi geri çekebilir.

FAQPage ve HowTo: artık rich result vermiyor

Burada içerik üreticilerinin en sık yanıldığı konuya geliyoruz. Geçmişte FAQPage schema'sı ekleyince Google sonuçlarında açılır soru-cevap blokları, HowTo schema'sı ekleyince adım adım görsel kılavuzlar çıkıyordu. Bu artık geçerli değil. Google, Ağustos 2023'te FAQ rich result'ını yalnızca iyi bilinen, otoriter devlet ve sağlık siteleriyle sınırladı; sıradan işletme, e-ticaret, SaaS ve ajans siteleri bu görünümü almayı bıraktı. Dahası, Google FAQ desteğini tamamen kaldırma sürecinde: FAQ arama görünümü ve Rich Results Test desteği 2026 içinde, Search Console API'deki FAQ desteği ise 2026 içinde sona eriyor. HowTo rich result'ı da Eylül 2023'te önce mobilde sınırlandı, ardından masaüstü dahil tamamen kaldırıldı. Dolayısıyla bir içerikte "FAQ schema eklersek Google'da açılır SSS çıkar" veya "HowTo schema rich result getirir" iddiasını kurmak 2026 itibarıyla yanlış olur.

Bu değişikliğin neden bu kadar yaygın bir yanlış anlama yarattığını da görmek faydalı: internette dolaşan rehberlerin çok büyük kısmı 2021-2022 dönemine ait ve hâlâ "FAQ ekle, açılır SSS kazan" diyor. Müşterilerimizle yaptığımız denetimlerde, eski bir eklenti ya da tema yüzünden sayfalara otomatik FAQPage basıldığını ama yıllardır hiçbir görsel sonuç gelmediğini sık görüyoruz. Bu yüzden 2026'da bir içerik stratejisini "FAQ schema yıldız/SSS getirir" varsayımı üzerine kurmak ölçülebilir bir hayal kırıklığıdır.

Peki bu türleri tamamen silmeli misiniz? Hayır. Google, kullanılmayan yapısal verinin Search açısından sorun çıkarmadığını belirtti; yani mevcut FAQPage/HowTo işaretlemenizi aceleyle kaldırmanız şart değil. Ancak bu türlerden artık görsel rich result beklemeyin. Bugün bu işaretlemelerin asıl değeri, içeriğinizin yapısını AI motorlarına ve arama sistemlerine daha net aktarmasında; iyi yapılandırılmış soru-cevap içeriği, AEO (Answer Engine Optimization) açısından AI Overviews ve sohbet tabanlı motorlar tarafından alıntılanabilirliği destekler. Burada esas kaldıracın schema değil içeriğin kendisi olduğunu vurgulamak gerekir: gerçek bir soruyu, kısa ve net bir doğrudan yanıtla (genelde 30-60 kelime) açan bölümler yazmak, AI motorlarının içeriğinizi alıntılaması için schema'dan daha belirleyicidir. Schema bu yapıyı yalnızca doğrular. Bu mantığı derinleştirmek için AI Overviews rehberimiz ve GEO (Generative Engine Optimization) rehberimiz doğru beklenti çerçevesini kuruyor; yapısal verinizin AI motorlarınca nasıl okunduğunu pratik olarak ölçmek isterseniz GEO denetim aracımız hızlı bir başlangıç sağlar.

Pratik özet: hangi siteye hangi temel set?

Bütün bu türleri birden eklemek yerine, içeriğinize uygun bir temel setle başlamak en sağlıklı yaklaşımdır. Tavsiye ettiğimiz çekirdek set şudur: her sitede Organization (ana sayfa) ve BreadcrumbList (hiyerarşik sayfalar), ardından içeriğe göre ana tip. Blog ve rehber sitelerinde bu ana tip Article/BlogPosting olur; e-ticarette Product + Offer + (varsa gerçek) AggregateRating; fiziksel konumu olan işletmelerde ise LocalBusiness. FAQPage ve HowTo'yu yalnızca içeriği gerçekten yapılandırmak ve AI motorları için anlaşılırlığı artırmak amacıyla, görsel rich result beklentisi olmadan ekleyin. Her işaretlemeyi yayına almadan önce Rich Results Test ve Schema Markup Validator ile doğrulayın; JSON-LD önerilen formattır ve sayfaya ek bir görsel yük getirmeden temiz biçimde eklenir. Yapısal verinin gerçekten çıktı verip vermediğini sürekli izlemek için Search Console'daki "Geliştirmeler" raporlarını takip edin (FAQ raporunun 2026 içinde kaldırıldığını unutmadan). Aşağıdaki tablo, site tipine göre önerdiğimiz çekirdek seti özetliyor.

Hangi türün sizin sayfa tipinize en yüksek getiriyi sağlayacağını ve teknik kurulumun doğruluğunu birlikte değerlendirmek isterseniz ücretsiz analiz ve teklif sihirbazımız üzerinden sitenizin yapısal veri durumunu çıkarıp önceliklendirebiliriz. Yapısal veriyi tek başına değil, doğru başlık-açıklama yazımı, sağlam iç bağlantı ve teknik temizlikle birlikte kurmak gerektiğini de hatırlatalım; bu bütünü sayfa içi (on-page) SEO rehberimiz ve genel çerçeve için SEO nedir, nasıl yapılır rehberimiz üzerinden tamamlayabilirsiniz.

Schema Nasıl Eklenir ve Test Edilir?

Yapısal veriyi eklemenin en güvenilir yolu, sayfanın <head> veya gövdesine bir JSON-LD bloğu yerleştirmektir. JSON-LD, schema bilgisini görünür içerikten ayrı, bağımsız bir <script type="application/ld+json"> etiketi içinde tutar; HTML'inizi kirletmez, sayfa tasarımını etkilemez ve hata yaptığınızda görsel bir bozulmaya yol açmaz. Google bu formatı resmî olarak önerir ve hem Article/Product gibi klasik zengin sonuç tipleri hem de AI motorlarının içeriği anlaması için en temiz yöntemdir. Ekleme yapıldıktan sonra doğrulama tek bir mantığa dayanır: önce Rich Results Test ile Google'ın o işaretlemeyi tanıyıp tanımadığını kontrol edin, sonra Search Console'un "Geliştirmeler" raporlarında canlı durumu izleyin. Aşağıda bu döngünün her adımını — biçim seçimi, kod yapısı, ekleme yöntemi, mobil tutarlılık, test ve canlı izleme — sırayla, müşteri projelerimizde uyguladığımız pratik disiplinle açıyoruz.

Neden JSON-LD? Microdata ve RDFa'ya göre farkı ne?

Yapısal veriyi siteye gömmenin üç tarihsel yöntemi var: JSON-LD, Microdata ve RDFa. Microdata ve RDFa, schema niteliklerini (itemprop, itemscope gibi) doğrudan görünür HTML etiketlerinin içine serpiştirir; yani başlık, fiyat, yazar gibi her veri parçasını ilgili HTML elemanına iliştirmeniz gerekir. Bu, işaretlemeyi içeriğe bağımlı kılar — tema değiştiğinde veya bir geliştirici HTML'i yeniden düzenlediğinde schema sessizce bozulabilir.

JSON-LD ise bütün yapısal veriyi tek bir kod bloğunda, sayfanın geri kalanından izole biçimde tutar. Pratik avantajları somut:

• Bakımı kolay: İşaretleme tek yerde toplanır; bir alanı güncellemek için onlarca HTML etiketini gezmek gerekmez.
• Şablonla uyumlu: Next.js, WordPress veya benzeri sistemlerde sunucu tarafında üretip <head>'e basmak kolaydır; CMS şablonlarına dinamik değerlerle yerleştirilir.
• Görünür içerikten bağımsız: Tasarım değişse de schema bozulmaz; ancak işaretlediğiniz veri sayfada gerçekten görünür olmalıdır — Google, kullanıcıya gösterilmeyen bilgiyi işaretlemeyi politika ihlali sayar.
• AI motorları için temiz: Yapay zekâ aramaları çağında iyi yapılandırılmış JSON-LD, içeriğin makinece anlaşılmasını kolaylaştırır; bu konuyu yapay zekâ aramalarında görünürlük rehberimizde ayrıntılı işliyoruz.

Üç biçimin farkını bir bakışta görmek için karşılaştırma faydalı olur:

2026 Haziran itibarıyla net tavsiyemiz şudur: yeni bir kurulumda JSON-LD kullanın. Microdata yanlış değildir ve mevcut sitelerde çalışmaya devam eder, ama Google'ın belgeleri ve örnekleri JSON-LD merkezlidir; biz de müşterilerimizde standart olarak JSON-LD üretiyoruz. Mevcut bir sitede Microdata varsa, yalnız biçim için aceleyle JSON-LD'ye geçmek şart değildir; ancak işaretlemeyi her elden geçirdiğinizde tek bloğa taşımak uzun vadede bakım yükünü belirgin düşürür.

JSON-LD nasıl görünür? Temel yapı

Bir JSON-LD bloğu üç zorunlu çerçeve unsuruyla başlar: bağlamı belirten @context (her zaman https://schema.org), işaretlediğiniz varlığın türünü söyleyen @type (ör. Article, Product, Organization) ve o türe ait özellikler. Örneğin bir blog yazısı için iskelet kavramsal olarak şöyle kurgulanır: @type "BlogPosting" olur; headline yazının başlığını, author bir Person nesnesiyle yazarın adını, datePublished yayın tarihini, publisher ise bir Organization nesnesiyle yayıncıyı taşır. Bir ürün sayfasında ise @type "Product" olur; içinde name, image, bir offers nesnesi (fiyat, para birimi, stok durumu) ve varsa aggregateRating bulunur.

Her ana tipin "olmazsa olmaz" alanları farklıdır; zengin sonuç almak için zorunlu alanları eksiksiz vermek gerekir. En sık kullandığımız tiplerde tipik çekirdek alanlar şöyledir:

Önemli bir disiplin: her sayfaya, içeriğine uygun ana tipi seçin. Bir blog yazısına Product schema, bir kategori sayfasına Article schema basmak yanlış sinyaldir. Doğru tip eşleşmesi ve hangi tiplerin 2026'da hâlâ görsel zengin sonuç verdiği konusunu bu rehberin önceki bölümlerinde ele aldık; özetle Article/BlogPosting, Product+Offer, BreadcrumbList, Organization ve LocalBusiness en değerli tiplerdir. Pratik bir başlangıç seti olarak her sayfada Organization + BreadcrumbList'i temel alıp üstüne sayfanın türüne uygun ana tipi (Article ya da Product) eklemenizi öneriyoruz; bu kombinasyon hem marka kimliğini hem navigasyonu hem de içerik tipini Google'a tek seferde net biçimde anlatır.

Schema sayfaya nasıl eklenir? Üç pratik yol

Yapısal veriyi siteye dahil etmenin teknik yolu, kullandığınız altyapıya bağlıdır. En sık karşılaştığımız üç senaryo:

• Doğrudan koda gömme (kod tabanlı siteler): Next.js, React veya saf HTML kullanıyorsanız, JSON-LD'yi sunucu tarafında bir nesneden üretip <script type="application/ld+json"> etiketiyle sayfaya basın. Bu en kontrollü yöntemdir; dinamik sayfalarda (her ürün, her blog yazısı) değerler veritabanından gelir. Önemli kural: işaretleme, sayfa ilk yüklendiğinde HTML kaynağında bulunsun. Tamamen istemci tarafında, geç çalışan JavaScript ile enjekte edilen schema, Googlebot render aşamasını beklediği için daha kırılgandır.
• Eklenti ile (WordPress, Shopify vb.): WordPress'te SEO eklentileri (Yoast, Rank Math) çoğu temel tipi otomatik üretir; Shopify temaları da Product/Organization işaretlemesini hazır sunar. Eklenti yolu hızlıdır ama denetim şarttır — çift schema (hem tema hem eklenti aynı tipi basabilir) ve eksik alan sık görülen sorunlardır.
• Google Etiket Yöneticisi (GTM) ile: Koda dokunamadığınız durumlarda GTM üzerinden özel HTML etiketi olarak JSON-LD enjekte edilebilir. İşe yarar bir geçici çözümdür; ancak GTM enjeksiyonu JavaScript'e bağlı olduğundan, mümkünse kalıcı çözümü sunucu tarafı render'da arayın.

Bu üç yolun hız, kontrol ve dayanıklılık dengesi farklıdır. Doğru seçimi yapmak için şu kıyas işinizi görür:

Eklenti yolunu seçtiyseniz en sık karşılaştığımız iki tuzağı baştan kapatın: birincisi çift schema — tema ve SEO eklentisi aynı tipi (çoğunlukla Organization veya Article) ayrı ayrı basınca sayfada iki kez tanımlanır; Rich Results Test bunu uyarı olarak gösterir ve tekilleştirmeniz gerekir. İkincisi otomatik üretilen ama eksik alanlı işaretleme — eklenti bir Product bloğu basar ama fiyat alanı temaya bağlı boş kalırsa zengin sonuç hiç çıkmaz. Hangi yolu seçerseniz seçin, ilke aynı kalır: schema'da beyan ettiğiniz her bilgi sayfada kullanıcıya görünür olmalı, doğru olmalı ve güncel kalmalıdır. Bu, yapısal verinin sayfa içi SEO çalışmanızın doğal bir uzantısı olarak ele alınmasını gerektirir; başlık, açıklama ve içerik hiyerarşisiyle tutarlı olmalıdır.

Mobil-öncelikli indekslemede schema'ya dikkat

Google 5 Temmuz 2024 itibarıyla mobil-öncelikli indekslemeyi tamamen tamamladı; artık tüm siteler için indeksleme ve sıralama sinyalleri akıllı telefon taramasından geliyor. Bunun yapısal veri açısından somut sonucu şudur: sayfanın mobil sürümü, masaüstüyle aynı yapısal veriyi içermelidir. Eğer responsive olmayan, ayrı bir mobil şablon kullanıyorsanız ve schema yalnızca masaüstü sürümde varsa, Google o işaretlemeyi görmez. Bu, müşteri denetimlerimizde rastladığımız sessiz hatalardan biridir — masaüstünde kusursuz görünen schema, mobilde hiç render edilmediği için zengin sonuç fırsatını kaçırır.

Aynı tuzak yalnız ayrı mobil şablonlarda değil, "mobilde daha hafif sayfa" mantığıyla bazı içerikleri (ör. yazar kutusu, fiyat tablosu, breadcrumb) mobilde gizleyen tasarımlarda da görülür: schema o veriyi beyan eder ama mobil DOM'da karşılığı yoktur. Google işaretlenen verinin sayfada görünür olmasını beklediği için bu durum hem politika açısından risklidir hem de zengin sonucu engeller. Pratik kural: mobil ve masaüstü aynı ana içeriği, başlıkları, iç linkleri ve yapısal veriyi taşısın. Aynı titizliği geri kalan teknik unsurlar için de göstermek gerekir; kapsamlı bir kontrol için teknik SEO denetimi rehberimize göz atabilirsiniz.

Schema nasıl test edilir? Rich Results Test ve doğrulayıcı

İşaretlemeyi ekledikten sonra körlemesine yayına almayın. İki resmî test aracı var ve ikisi farklı sorulara cevap verir:

• Rich Results Test (Zengin Sonuç Testi): "Bu işaretleme Google'da görsel bir zengin sonuca uygun mu?" sorusunu yanıtlar. URL girer veya kodu yapıştırırsınız; araç sayfayı render eder, hangi zengin sonuç tipinin algılandığını, varsa hataları (zorunlu alan eksikliği) ve uyarıları (önerilen alan eksikliği) listeler. Mobil ve masaüstü render'ı ayrı gösterir — mobil-öncelikli indeksleme gereği mobil görünümü mutlaka kontrol edin.
• Schema Markup Validator (schema.org doğrulayıcısı): "Bu kod schema.org standardına sözdizimsel olarak uygun mu?" sorusunu yanıtlar. Google'ın zengin sonuç desteklemediği tipleri de (ör. FAQPage) doğrular. Yani Rich Results Test'in "bu tip için zengin sonuç yok" dediği yerde, bu araç işaretlemenin teknik olarak geçerli olup olmadığını teyit etmenizi sağlar.

İki aracın işbölümünü netleştirmek için şu ayrım faydalıdır: Rich Results Test Google'a özgü bir bakıştır — yalnızca Google'ın aktif olarak desteklediği zengin sonuç tiplerini tanır ve "bu sayfa SERP'te şu görünümü kazanabilir" der. Schema Markup Validator ise standarda bakar — kodun schema.org sözdizimine uyup uymadığını söyler, ama o tipin Google'da bir zengin sonuç karşılığı olup olmadığıyla ilgilenmez. Pratikte ikisini birlikte kullanırız: önce doğrulayıcıyla sözdizimini temizler, sonra Rich Results Test'le Google'ın gerçekte ne tanıdığını görürüz.

Burada 2026 itibarıyla kritik bir gerçeği netleştirelim: her geçerli schema, Google'da görsel zengin sonuç anlamına gelmez. Örneğin FAQPage işaretlemesi schema.org açısından tamamen geçerlidir ve Schema Markup Validator onu sorunsuz doğrular; ancak Google, FAQ zengin sonucunu Ağustos 2023'ten beri yalnızca otoriter devlet ve sağlık siteleriyle sınırlamış, 2026'da ise FAQ zengin sonuç desteğini tamamen kaldırma sürecine girmiştir (Rich Results Test ve raporlardaki FAQ desteği 2026 içinde, Search Console API'deki FAQ desteği 2026 içinde çekiliyor). Aynı şekilde HowTo zengin sonucu da kaldırılmıştır. Bu tiplerin işaretlemesi zarar vermez — Google kullanılmayan yapısal verinin Search'e sorun çıkarmadığını belirtmiştir — ve içeriğin makinece anlaşılmasına katkı sunar; fakat "FAQ schema eklersem aramada açılır sorular çıkar" beklentisi artık gerçekçi değildir. Test aracında "uygun zengin sonuç bulunamadı" mesajı görmeniz, bu tipler için bir hata değil, beklenen durumdur. Bu yüzden FAQ/HowTo işaretlemesini bugün "zengin sonuç kazanma" aracı olarak değil, içeriğin AI motorlarınca ve arama altyapısınca anlaşılmasını destekleyen bir anlamsal sinyal olarak konumlandırmak doğrudur.

Pratik test akışımız şöyle işler: Rich Results Test'te kodu doğrulayın, kırmızı hataları (zorunlu alanlar) mutlaka giderin, sarı uyarıları (önerilen alanlar) içeriğe uygun olduğu ölçüde tamamlayın. Bir Product işaretlemesinde fiyatın eksik olması hatadır ve zengin sonucu tamamen engeller; bir incelemenin tarihinin eksik olması yalnızca uyarıdır. Hata ile uyarı ayrımını içselleştirmek zaman kazandırır: hata, zengin sonucu tümüyle iptal eder; uyarı ise sonucu engellemez ama tamamlandığında daha zengin bir görünüm (ör. yıldız, stok durumu) kazandırabilir. Yapısal verinin daha geniş SEO resmindeki yerini ve hangi tiplerin öncelikli olduğunu Google sıralama faktörleri yazımızda bütünsel olarak değerlendiriyoruz.

Yayın sonrası: Search Console ile canlı izleme

Test araçları "yayına almadan önce" kontrolüdür; gerçek dünyada işaretlemenizin nasıl performans gösterdiğini ise Google Search Console söyler. Schema yayınlandıktan sonra şu adımları izleyin:

• URL İnceleme aracı: İlgili sayfanın URL'sini girip "Canlı URL'yi test et" diyerek Google'ın o anki render'ında schema'nın görünüp görünmediğini doğrulayın; gerekirse "İndekslenmeyi iste" ile yeniden taramayı tetikleyin. Bu araç ayrıca Google'ın o sayfa için seçtiği kanonik URL'yi de gösterir — yapısal veriniz doğru ama sayfa başka bir kanoniğe işaret ediyorsa zengin sonuç beklediğiniz URL'de çıkmayabilir.
• "Geliştirmeler" raporları: Search Console, yalnızca desteklenen structured data tipleri için (Ürün, Kırıntı, Makale vb.) ayrı raporlar üretir ve geçerli/uyarılı/hatalı öğe sayılarını zaman içinde gösterir. Bir tip için hata sayısı artıyorsa, çoğu zaman bir şablon değişikliği veya CMS güncellemesi schema'yı bozmuştur. Not: FAQ raporu 2026 içinde bu listeden kaldırılıyor.
• Düzenli denetim: Schema "bir kez ekle, unut" işi değildir. Tema güncellemesi, eklenti çakışması veya fiyat/stok alanının kaynak değişmesi işaretlemeyi sessizce kırabilir; bu yüzden periyodik kontrolü standart bakım akışınıza alın. Özellikle e-ticarette fiyat ve stok alanları sık değiştiği için Product işaretlemesini ayrı izlemek değerlidir.

Yayından önce ve sonra hangi aracın hangi soruyu yanıtladığını tek tabloda toplamak, ekip içi iş akışını netleştirir:

Bu üç katmanlı yaklaşım — doğru JSON-LD üret, Rich Results Test ile doğrula, Search Console ile canlı izle — yapısal verinin hem klasik zengin sonuçlar hem de AI Overviews gibi üretken arama yüzeyleri için sağlam bir temel oluşturmasını sağlar. AI Overviews 2025 Mayıs'ından bu yana Türkiye'de ve Türkçe sorgularda aktif olduğundan, iyi yapılandırılmış schema yalnız SERP görünümü için değil, içeriğinizin yapay zekâ özetlerince doğru anlaşılması için de bugün daha kıymetlidir. Yapısal verinizin yapay zekâ aramaları açısından ne durumda olduğunu hızlıca görmek isterseniz GEO denetim aracımızı kullanabilir; sitenizin schema kurulumunu uçtan uca ele almamızı istiyorsanız dijital pazarlama danışmanlığı ekibimizle bir ücretsiz analiz başlatabilirsiniz.

E-Ticaret İçin Yapısal Veri: Product, Offer ve Review Schema'sı Nasıl Kurulur?

E-ticaret sitelerinde yapısal verinin en yüksek getirili kullanım alanı ürün sayfalarıdır. Kısaca: Product schema'sı ürünün adını, görselini ve markasını; Offer schema'sı fiyat, para birimi ve stok durumunu; Review/AggregateRating ise yıldız puanını ve yorum sayısını Google'a açık ve makine-okunur biçimde bildirir. Doğru kurulduğunda Google arama sonucunda klasik mavi linki, fiyat etiketi, yıldızlı puan ve "stokta var" rozetiyle birlikte gösterebilir; bu da rakip listelerin arasından öne çıkmanızı sağlar. Müşterilerimizde gördüğümüz en net etkilerden biri budur: aynı pozisyonda kalsanız bile, zengin sonuç (rich result) ile gelen ürün satırı belirgin biçimde daha fazla tıklama alır. Yapısal veri kavramına ve JSON-LD'nin temellerine henüz hâkim değilseniz, önce yapısal veri (schema markup) rehberimizdeki genel bölümleri okumanız bu adımları daha anlaşılır kılar.

Önemli bir çerçeve: 2026 Haziran itibarıyla Google'ın artık görsel zengin sonuç verdiği schema tipleri belirli bir listeyle sınırlı. FAQ ve HowTo zengin sonuçları bu süreçte kaldırılırken, Product + Offer + AggregateRating/Review e-ticaret için hâlâ aktif ve kritik olan tiplerin başında geliyor. Yani bir e-ticaret sitesi için yapısal veri "denenebilir bir ekstra" değil, ürün görünürlüğünün doğrudan bir parçasıdır. Bu farkı bir tabloyla netleştirelim; çünkü internette dolaşan birçok eski rehber hâlâ FAQ/HowTo zengin sonucunu canlıymış gibi anlatıyor:

Bu tablodan çıkan pratik sonuç şudur: e-ticaretteki schema bütçenizi FAQ veya HowTo gibi artık karşılığı olmayan tiplere değil, ürün görünürlüğünü doğrudan besleyen Product, Offer, AggregateRating ve BreadcrumbList'e ayırın. FAQ schema'sını isterseniz tutabilirsiniz (zarar vermez ve AI motorlarının içeriği anlamasına yardımcı olur) ama kararlarınızı "yıldızlı SSS çıkacak" beklentisiyle kurmayın.

Product Schema'sında Hangi Alanlar Bulunmalı?

Product schema'sı bir ürün sayfasının kimlik kartıdır. Google'ın ürün zengin sonucunu değerlendirebilmesi için en azından ürünün adı (name), görseli (image) ve fiyat bilgisini taşıyan bir teklifi (offers) görmesi gerekir. Pratikte e-ticaret ürün sayfasında doldurulması gereken temel alanlar şunlardır:

• name — Ürünün tam, kullanıcıya görünen adı. Sayfadaki H1 başlığıyla ve katalogdaki adla tutarlı olmalı; arama için yapay kelime eklenmiş "süslü" bir başlık değil, gerçek ürün adı.
• image — Ürünün yüksek çözünürlüklü, gerçek görseli. Birden fazla açı varsa dizi olarak verin; bu, görsel arama ve zengin sonuç kalitesi için önemlidir.
• description — Ürünün özgün açıklaması. Burada katalogdan kopyalanmış jenerik metin yerine kendi yazdığınız, ürünü gerçekten anlatan açıklama kullanın. Bu açıklamanın nasıl yazılacağını ürün açıklaması nasıl yazılır rehberimizde adım adım ele alıyoruz.
• brand — Markanın adı (Brand tipi). Markalı ürünlerde Google'ın ürünü doğru entity ile eşlemesine yardım eder.
• sku / gtin / mpn — Ürün tanımlayıcıları. Özellikle GTIN (barkod), Google'ın ürünü küresel olarak tanımasını ve doğru ürünle eşlemesini kolaylaştırır; varsa mutlaka ekleyin.
• offers — Fiyat ve stok bilgisini taşıyan Offer nesnesi (aşağıda detaylı).
• aggregateRating / review — Puan ve yorum verisi (aşağıda detaylı).

Bu alanları nasıl önceliklendireceğinizi netleştirmek için şöyle düşünün: name, image ve offers olmadan Google ürün zengin sonucunu hiç değerlendirmez; bunlar zorunlu çekirdektir. brand, gtin, sku, review ve aggregateRating ise önerilen alanlardır — eksik olmaları sayfayı diskalifiye etmez ama eklenmeleri hem zengin sonucu zenginleştirir hem de Google'ın ürünü doğru tanımlama olasılığını artırır. Bu yüzden bir e-ticaret projesinde önce çekirdeği eksiksiz kurar, sonra tanımlayıcı ve puan alanlarıyla genişletiriz.

Somut bir örnek üzerinden gidelim. Bir spor ayakkabısı satıyorsunuz: name alanı "Nike Air Zoom Pegasus 41 Erkek Koşu Ayakkabısı" gibi sayfadaki başlıkla birebir aynı olmalı; brand "Nike"; gtin kutunun üzerindeki 13 haneli barkod; image ürünün gerçek stüdyo fotoğrafının kanonik URL'si. Aynı modelin 40, 41, 42 numaraları varsa her numaranın kendi sku ve gerektiğinde kendi gtin değeri olur. Buradaki ince nokta, varyant tanımlayıcılarını tek bir ürüne karıştırmamaktır; her satılabilir varyant kendi kimliğini taşımalıdır.

Buradaki demir kural şudur: yapısal veride beyan ettiğiniz her bilgi, kullanıcının sayfada gördüğü bilgiyle birebir aynı olmalı. Sayfada görünmeyen bir fiyatı, var olmayan bir yıldız puanını veya stokta olmayan ürünü "stokta" göstermek, Google'ın yapısal veri politikalarının açık ihlalidir ve manuel işlem (yaptırım) riskini doğurur. Schema, sayfadaki gerçeği makine-okunur hâle getirmek içindir; gerçeği süslemek için değil.

Offer Schema'sı: Fiyat, Para Birimi ve Stok Durumu

Offer, ürün zengin sonucunun en görünür kısmını besler: SERP'te beliren fiyat etiketi ve stok durumu buradan gelir. Bir e-ticaret Offer nesnesinde olması gereken çekirdek alanlar:

• price — Ürünün güncel satış fiyatı, sayısal olarak (ör. 1299.90). Para birimi sembolü veya binlik ayraç koymayın; ham sayı verin.
• priceCurrency — ISO 4217 para birimi kodu. Türkiye için TRY. Bu alan eksikse fiyat zengin sonucu büyük ihtimalle görünmez.
• availability — Stok durumu schema.org URL'siyle: stokta için https://schema.org/InStock, tükendiyse https://schema.org/OutOfStock, ön sipariş için PreOrder. Bu değer mağaza sisteminizdeki gerçek stokla otomatik senkronize olmalı; elle güncellenen statik değerler kısa sürede yanlışa düşer.
• priceValidUntil — Fiyatın geçerlilik tarihi. Özellikle kampanyalı fiyatlarda Google'ın fiyatı ne zamana kadar güvenilir sayacağını bilmesini sağlar.
• url — Ürünün kanonik URL'si; varyantlı yapılarda doğru sayfaya işaret etmesi önemlidir.

Fiyatın price ve priceCurrency olarak ayrı verilmesi şarttır; bu ikili olmadan Google fiyatı çözemez. Türkiye'ye özgü bir tuzak da burada karşımıza çıkar: fiyatı 1.299,90 gibi Türkçe sayı biçimiyle (binlik nokta, ondalık virgül) yazmak. Schema'da fiyat İngilizce/makine biçiminde, yani ondalık ayraç olarak nokta ve binlik ayraç olmadan verilmelidir: 1299.90. Mağaza altyapınız sayfada Türkçe biçimi gösterirken schema'ya makine biçimini bastığından emin olun; bu ayrımı atlamak en sık gördüğümüz fiyat hatalarından biridir.

Stok durumunu dinamik tutmanın önemini özellikle vurgularız: ürün tükendiğinde schema hâlâ "InStock" diyorsa, kullanıcı tıklayıp tükenmiş ürünle karşılaşır; bu hem dönüşüm kaybı hem de Google nezdinde tutarsızlık sinyalidir. Üstelik bu tutarsızlık tek bir üründe kalmaz: binlerce ürünlü bir katalogda statik "InStock" kullanıyorsanız, her gün doğal olarak tükenen ürünler birikerek sistematik bir uyumsuzluk oluşturur. Bu yüzden Offer alanlarını mağaza altyapınızın (ikas, Shopify, WooCommerce vb.) ürün verisiyle programatik olarak besleyin. Hangi altyapıyı kullandığınızı bilmiyor veya bir rakip sitenin altyapısını merak ediyorsanız e-ticaret altyapı tespit aracımız ile hızlıca kontrol edebilirsiniz; çünkü schema'yı besleme yöntemi altyapıya göre değişir.

Birden fazla varyantı (renk/beden) farklı fiyatlarla satıyorsanız, tek bir Offer yerine fiyat aralığını ifade eden AggregateOffer (lowPrice, highPrice, offerCount) yapısını kullanabilirsiniz. Örneğin aynı tişörtün S bedeni 249,90 TL, XXL bedeni 299,90 TL ise, lowPrice 249.90, highPrice 299.90 ve offerCount mevcut varyant sayısı olur. Hangi yapının uygun olduğu, ürün sayfanızın varyantları nasıl sunduğuna bağlıdır: tek fiyatlı tekil bir ürün için sade bir Offer yeterliyken, geniş fiyat aralıklı çok varyantlı bir ürün için AggregateOffer daha doğru bir tablodur. İndirimli satışlarda ayrıca priceValidUntil'ı kampanya bitiş tarihine ayarlamak, indirimin "süresi geçmiş" görünmesini engeller.

Review ve AggregateRating: Yıldız Puanı Nasıl Doğru Eklenir?

Yıldızlı puan (yıldız zengin sonucu), e-ticaret SERP'inde tıklama oranını en çok etkileyen unsurlardan biridir; ama Google'ın bu konudaki kuralları katıdır. İki temel yapı vardır:

• AggregateRating — Ürünün tüm yorumlarının ortalamasını gösterir. Çekirdek alanları: ratingValue (ortalama puan, ör. 4.6), reviewCount veya ratingCount (yorum/oy sayısı), bestRating ve worstRating (ölçek, genelde 5 ve 1).
• Review — Tekil bir yorumu yapılandırır: yazarı (author), puanı (reviewRating) ve metni.

reviewCount ile ratingCount arasındaki ince farkı bilmek işe yarar: reviewCount metin yorumlarının sayısını, ratingCount ise yalnız puan veren (metin yazmamış olanlar dahil) tüm değerlendirmelerin sayısını ifade eder. Çoğu üründe ikisi farklıdır — örneğin 320 kişi yıldız vermiş ama yalnız 140'ı yorum yazmışsa, ratingCount 320, reviewCount 140 olur. Verinizi hangi sayıma dayandırdığınızı doğru alanla eşleştirin; ikisini karıştırmak Search Console'da uyarıya yol açabilir.

Kritik kısıt şudur: Google yıldız zengin sonucunu yalnızca izin verilen schema tiplerinde gösterir; e-ticaret için bunun başında Product gelir (diğerleri Recipe, Course, Book, LocalBusiness gibi sınırlı tiplerdir). Bir hizmeti veya markanın kendisini öven, kullanıcının site dışından doğrulayamayacağı "kendi kendine verilmiş" (self-serving) yıldızlar gösterilmez. Yani Organization veya soyut bir varlık üzerine iliştirilmiş ürün-dışı yıldızlar zengin sonuç getirmez. Pratik karşılığı şu: "Müşterilerimiz bize 5 yıldız veriyor" diye ana sayfadaki marka kutusuna yıldız iliştirmek işe yaramaz; yıldız ancak gerçek bir ürünün sayfasındaki gerçek müşteri puanlarına bağlandığında görünür.

Bir başka sık yapılan hata, gerçekte var olmayan veya sayfada görünmeyen yorumlara dayalı AggregateRating eklemektir. Puan ve yorum sayısı, ürün sayfasında kullanıcının görebildiği gerçek yorumlardan türemelidir. Sahte veya şişirilmiş puan beyanı, Google'ın yapısal veri ve spam politikalarının ihlalidir. Yeni açılmış, henüz yorumu olmayan bir ürünü "4,8 / 10 yorum" gibi göstermek de aynı kapıya çıkar; yorumu olmayan ürüne AggregateRating eklemeyin, ilk gerçek yorumlar geldikçe ekleyin. Yorum toplama altyapınızı kurarken hedefiniz, schema'yı "yıldız çıksın diye" zorlamak değil, gerçek müşteri yorumlarını hem kullanıcıya hem Google'a şeffaf biçimde sunmak olmalı. Bu yaklaşım aynı zamanda E-E-A-T'nin merkezindeki güven (Trust) bileşenini de güçlendirir; çünkü Trust, deneyim ve uzmanlık ne kadar güçlü olursa olsun yapısal verinizin yanıltıcı olmaması üzerine kuruludur.

JSON-LD ile Uygulama ve Doğrulama

Google, yapısal veri için önerilen format olarak JSON-LD'yi tavsiye eder; mikrodata yerine JSON-LD kullanmak, işaretlemeyi sayfanın HTML'inden ayırarak yönetimi ve bakımı kolaylaştırır. JSON-LD bloğu sayfanın HTML'ine bir script etiketi içinde gömülür ve içeriğin görsel sunumuyla iç içe geçmediği için tasarımı bozmadan güncellenebilir. E-ticaret altyapılarının çoğu (ikas, Shopify gibi) ürün schema'sını otomatik üretir; ancak bu otomatik çıktının tam, doğru ve sayfayla tutarlı olduğunu varsaymayın — çoğu projede ilk denetimde eksik priceCurrency, yanlış availability veya hiç bulunmayan tanımlayıcılar görüyoruz.

Bir noktayı önemle hatırlatalım: aynı ürün için birden fazla yerden schema üretilirse (örneğin altyapının otomatik çıktısı bir, sonradan eklediğiniz bir tema eklentisi iki) sayfa çelişen Product blokları taşıyabilir. Mobil-öncelikli indeksleme nedeniyle Google sayfanın mobil sürümünü tarar; bu yüzden masaüstü ve mobilde aynı yapısal verinin bulunduğundan da emin olun. Tek doğru kaynak ilkesini koruyun: ürün başına tek, eksiksiz ve sayfayla tutarlı bir Product bloğu en sağlıklısıdır.

Uyguladıktan sonra mutlaka doğrulayın. İki resmî araç vardır: Rich Results Test (sayfanızın hangi zengin sonuçlara uygun olduğunu gösterir) ve Schema Markup Validator (schema.org sözdizimini doğrular). Rich Results Test'i hem canlı URL üzerinde hem de henüz yayınlamadığınız kodu yapıştırarak çalıştırabilirsiniz; bu, değişikliği yayına almadan önce kontrol etmenin pratik yoludur. Yayına aldıktan sonra ise Google Search Console içindeki "Geliştirmeler / Ürün öğeleri" raporundan, Google'ın gerçek tarama sırasında bulduğu hata ve uyarıları takip edin. Bu rapor, "schema çalışıyor mu?" sorusunun en güvenilir cevabıdır; çünkü sizin gördüğünüz kodu değil, Google'ın işlediği hâli gösterir. Raporda "geçersiz öğe" (hata) ve "öneri" (uyarı) ayrımına dikkat edin: hatalar zengin sonucu engeller, uyarılar engellemez ama giderildiğinde sonucu zenginleştirir.

Yapısal veri, e-ticaret SEO'sunun yalnızca bir parçasıdır; ürün ve kategori sayfalarının bütününü ele alan e-ticaret SEO rehberimiz ile birlikte kurguladığınızda en yüksek getiriyi verir. Ürün sayfalarınızın schema kurulumunu, stok-fiyat senkronizasyonunu ve zengin sonuç uygunluğunu uçtan uca denetlememizi isterseniz, dijital pazarlama danışmanlığı kapsamında bu çalışmayı sizin için yürütüyor; dilerseniz ücretsiz ön analiz ile sitenizin mevcut yapısal veri durumunu çıkarıyoruz.

E-Ticaret Yapısal Veride En Sık Yapılan Hatalar

Müşteri sitelerinde tekrar tekrar karşılaştığımız, kolayca düzeltilebilen hatalar:

• Sayfa-schema uyumsuzluğu: Schema'daki fiyat veya stok, sayfada görünenle aynı değil. En sık ceza nedeni budur; her zaman sayfadaki gerçek değeri yansıtın.
• Eksik para birimi: price var ama priceCurrency yok; bu durumda fiyat zengin sonucu çıkmaz.
• Türkçe fiyat biçimi: Fiyat schema'ya 1.299,90 gibi nokta-virgül biçimiyle yazılmış; makine biçimi olan 1299.90 kullanılmalı.
• Statik stok durumu: Tüm ürünlerde sabit "InStock"; tükenenler güncellenmiyor. Stok mutlaka mağaza verisinden dinamik gelmeli.
• İzin verilmeyen yıldızlar: Ürün dışı varlıklara (marka, hizmet) iliştirilmiş self-serving yıldızlar; bunlar gösterilmez ve politika riski taşır.
• Yorumsuz üründe puan beyanı: Henüz hiç yorum almamış ürüne AggregateRating eklemek; gerçek yorum gelene kadar bu alan boş kalmalı.
• Eksik tanımlayıcılar: GTIN/MPN hiç girilmemiş; bu, Google'ın ürünü tanımasını ve eşlemesini zorlaştırır.
• Çift/çelişen Product bloğu: Altyapı ve eklenti aynı sayfaya iki ayrı schema basıyor; ürün başına tek doğru kaynak tutulmalı.
• Doğrulama atlanmış: Schema eklenmiş ama Rich Results Test ve Search Console raporuyla hiç kontrol edilmemiş; hatalar fark edilmeden aylarca durabilir.

Bu hataların ortak paydası, schema'yı "kur ve unut" yöntemiyle bırakmaktır. Oysa fiyat, stok ve yorum verisi sürekli değişen canlı verilerdir; yapısal verinin değeri de bu canlı veriyle senkron kaldığı sürece sürer. Pratik bir alışkanlık olarak, kataloğa yeni ürün tipi (ör. ilk kez bir paket/set ürün) eklediğinizde veya altyapı/tema güncellemesi yaptığınızda Rich Results Test'i tekrar çalıştırın; bu küçük kontrol, sessizce oluşan toplu hataların önüne geçer.

Özetle e-ticaret için yapısal verinin formülü nettir: Product ile ürünü tanımlayın, Offer ile fiyat-para birimi-stoğu dinamik ve doğru besleyin, izin verilen yerde AggregateRating/Review ile gerçek yıldız puanını ekleyin, JSON-LD ile uygulayın ve resmî araçlarla doğrulayın. Abartısız, sayfadaki gerçekle tutarlı ve dinamik tutulan bir kurulum, hem zengin sonuç şansınızı en üst düzeye çıkarır hem de uzun vadede Google nezdindeki güveninizi korur.

Hangi Schema Hataları Sıralamanıza ve Güvenilirliğinize Zarar Verir?

En sık ve en riskli yapısal veri hatası, sayfada görünmeyen içeriği işaretlemektir: kullanıcıya gösterilmeyen bir fiyatı, yıldız puanını, SSS sorusunu veya etkinlik tarihini schema'ya yazmak. Google'ın yapısal veri politikası bu konuda net — işaretlenen içerik, sayfayı ziyaret eden kullanıcının gerçekten gördüğü içerikle birebir örtüşmelidir. Örtüşmediğinde, en iyi senaryoda işaretleme görmezden gelinir; en kötü senaryoda yapısal veri ihlali nedeniyle manuel işlem (manual action) alırsınız ve sitenin tüm zengin sonuç (rich result) uygunluğu askıya alınabilir. Müşterilerimizde gördüğümüz en yaygın senaryo, geliştiricinin "ne kadar çok schema o kadar iyi" varsayımıyla sayfada hiç bulunmayan alanları doldurmasıdır. Bu bölümde, gerçek projelerde tekrar tekrar karşılaştığımız hataları somut biçimde ele alıyoruz; doğru kurulumun temelini ise yapay zeka görünürlüğü ölçümü ve genel teknik SEO denetimi yazılarımızla birlikte değerlendirmenizi öneririz.

Hataların maliyetini doğru anlamak için iki kavramı ayırmak gerekir. Birincisi, algoritmik görmezden gelme: schema'nız geçersiz, eksik ya da içerikle çelişkili olduğunda Google işaretlemenizi basitçe yok sayar; ceza yoktur ama kazanabileceğiniz zengin sonuç fırsatını da kaybedersiniz. İkincisi, çok daha ağır olan manuel işlem: değerlendiriciler kasıtlı, yanıltıcı işaretleme (görünmeyen yıldız, sahte indirim, alakasız tip) tespit ettiğinde sitenin tamamı zengin sonuç uygunluğundan çıkarılabilir ve bu durum Search Console'da "Güvenlik ve Manuel İşlemler" altında size bildirilir. İlki teknik bir kayıp, ikincisi itibar kaybıdır; ikincisinden çıkmak çok daha zahmetlidir. Pratikte hedefimiz her ikisinden de kaçınmaktır.

Görünmeyen İçeriği İşaretlemek (En Tehlikeli Hata)

Google'ın yapısal veri kuralı tektir: schema, kullanıcının sayfada gördüğü içeriği yansıtmalıdır. Pratikte sık tekrarlanan ihlaller şunlardır:

• Sahte yıldız (AggregateRating) işaretlemek: Sayfada hiç değerlendirme yokken, ya da değerlendirmeler kullanıcıya gösterilmiyorken Product/LocalBusiness altında yıldız puanı yazmak. Google yalnızca izin verilen tiplerde (Product, Recipe, Course, Book, LocalBusiness gibi) ve gerçekten sayfada görünen değerlendirmelerde yıldız gösterir. Kendi kendine atanmış ("self-serving"), kaynağı olmayan yıldızlar gösterilmez ve politika ihlalidir.
• Stokta olmayan veya görünmeyen fiyatı Offer olarak yazmak: Product schema'sındaki fiyat, para birimi ve stok durumu sayfadaki gerçek bilgiyle eşleşmeli. Sayfada "fiyat için arayın" yazıp schema'ya somut bir tutar koymak tutarsızlıktır.
• SSS bölümü olmayan sayfaya FAQPage eklemek: Soru-cevap bloğu sayfada hiç görünmüyorken FAQPage işaretlemek klasik bir görünmeyen içerik hatasıdır. (FAQPage'in zengin sonuç durumu ayrıca değişti — bir alt başlıkta ele alıyoruz.)
• Açılır/sekme içeriğini abartmak: Sekme veya akordeon arkasındaki içerik kullanıcı etkileşimiyle erişilebilir olduğu sürece kabul edilebilir; ancak hiçbir şekilde sayfada bulunmayan metni işaretlemek edilemez.

Bu hataların neden tehlikeli olduğunu somutlaştıralım. Bir e-ticaret müşterimizde, ürünlerin yarısında henüz hiç müşteri yorumu yokken tema şablonu her ürüne varsayılan "5,0 yıldız / 1 değerlendirme" enjekte ediyordu. Sayfada görünür hiçbir yorum olmadığı için bu işaretleme kuralın tam ihlaliydi; Rich Results Test geçiyor görünse de Google yıldızları göstermiyor, üstüne manuel işlem riski biriktiriyordu. Çözüm basitti: yorumu olmayan ürünlerden AggregateRating bloğunu tamamen kaldırmak, yorum geldikçe gerçek puanı ve sayıyı dinamik beslemek. Kural basit kalmalı: önce içeriği sayfaya gerçekten ekleyin, sonra o içeriği işaretleyin — tersini değil.

FAQ ve HowTo'dan Zengin Sonuç Beklemek (2026'da Geçersiz)

Bu, internette hâlâ en çok yanlış aktarılan konu. 2026 Haziran itibarıyla geçerli durum net olarak şudur:

• FAQPage zengin sonucu artık neredeyse hiçbir site için gösterilmiyor. Google, Ağustos 2023'te FAQ zengin sonucunu yalnızca iyi bilinen, otoriter devlet ve sağlık siteleriyle sınırladı. Sıradan işletme, e-ticaret, SaaS veya ajans sitesi açılır SSS görünümü almıyor. Dahası Google, FAQ desteğini tamamen kaldırıyor: search appearance, zengin sonuç raporu ve Rich Results Test desteği 2026 Haziran'da; Search Console API'deki FAQ desteği 2026 Ağustos'ta kaldırılıyor.
• HowTo zengin sonucu da kaldırıldı. Eylül 2023'te önce mobilde sınırlandı, ardından masaüstü dahil tamamen kaldırıldı. "HowTo schema eklersen adım adım zengin sonuç çıkar" iddiası artık geçersizdir.

Bunun pratik sonucu: bir blog yazısının veya ürün sayfasının altına FAQPage ekleyip "Google'da açılır sorular çıkacak, tıklanma artacak" beklentisine girmeyin — çıkmayacak. İyi haber, bu schema'ların zarar vermemesidir; Google kullanılmayan yapısal verinin Arama'ya sorun çıkarmadığını belirtti, dolayısıyla acele kaldırma şart değil. Ama konumlandırma değişti: FAQ/HowTo schema'sını artık görsel zengin sonuç için değil, içeriğin makineler tarafından anlaşılabilirliği ve AI Overviews görünürlüğü ile cevap motoru optimizasyonu (AEO) açısından değerlendirin. İçeriğinizi soru-cevap netliğiyle yapılandırmak, AI motorlarının doğrudan alıntılaması için hâlâ faydalıdır; bu yaklaşımı GEO rehberimizde derinlemesine işliyoruz.

Buradaki kritik ayrım şudur: schema tipini silmek ile ondan görsel zengin sonuç beklemek aynı şey değildir. Mevcut FAQPage işaretlemelerinizi panik içinde sökmenize gerek yok — Google bunların aramaya zarar vermediğini açıkça söylüyor. Yapmanız gereken tek şey, raporlama ve beklenti tarafını güncellemek: Search Console'da FAQ "Geliştirmeler" raporu 2026 Haziran'da kaybolacağı için orada veri aramayı bırakın, içerik takvimi ve KPI hedeflerinizden "FAQ rich result CTR artışı" varsayımını çıkarın. Pratik öneri: SSS içeriğinizi yine yazın çünkü kullanıcıya ve AI motorlarına faydalıdır, ancak onu schema sayesinde kazanılan bir SERP özelliği gibi raporlamayın.

İçerikle Çelişen veya Eksik Zorunlu Alanlar

Zengin sonuç vermeye devam eden tiplerde (Article/BlogPosting, Product+Offer, BreadcrumbList, Organization, LocalBusiness, Event, Recipe, VideoObject gibi) en sık görülen ikinci hata grubu, alan düzeyindeki tutarsızlıklar ve eksikliklerdir:

• Zorunlu (required) alanları atlamak: Her tipin Google tarafında zorunlu ve önerilen alanları vardır. Örneğin Product için isim ve uygun bir teklif/değerlendirme bilgisi; Article için başlık ve yayın bilgisi beklenir. Zorunlu alan eksikse o tip zengin sonuç için uygun sayılmaz.
• Görünür metinle çelişen değerler: Sayfada "1.299 TL" yazarken schema'da farklı bir tutar; başlıkta bir tarih, schema'da başka bir tarih; H1'de bir ürün adı, schema'da farklı bir ad. Bu çelişkiler hem zengin sonucu engeller hem güven sinyalini zayıflatır.
• Yanlış tip seçmek: Bir blog yazısını Product, bir hizmet sayfasını Recipe gibi işaretlemek. Tip, sayfanın gerçek içerik niyetiyle örtüşmeli.
• Yetkisiz Review/AggregateRating kullanımı: Yıldız puanı yalnızca Google'ın izin verdiği tiplerde (Product, Recipe, Course, Book, LocalBusiness vb.) gösterilir; bunun dışındaki sayfalarda yıldız işaretlemek beklenen sonucu vermez.

"Zorunlu" ve "önerilen" alan ayrımını içselleştirmek bu hataların çoğunu önler: zorunlu alanlardan biri eksikse o tip zengin sonuç için uygun bile sayılmaz; önerilen alanlar eksikse uygunsunuz ama daha zengin, daha tıklanır bir sonuç şansını kaçırırsınız. Aşağıdaki tablo, zengin sonuç vermeye devam eden başlıca tiplerde sahada en sık atlanan alanları ve doğru yaklaşımı özetliyor.

Bu hataların çoğu, doğru başlık hiyerarşisi ve sayfa içi tutarlılıkla iç içedir; on-page tarafını on-page SEO rehberimizde, başlık ve açıklama uyumunu da meta başlık ve açıklama yazımı yazımızda ayrıntılandırdık.

Teknik Kurulum ve Format Hataları

Schema'nın doğru "anlamını" yazmak kadar, onu doğru biçimde sunmak da önemlidir. Sahada en çok karşılaştığımız teknik hatalar:

• JSON-LD yerine dağınık microdata/RDFa ısrarı: Google JSON-LD'yi önerir; HTML'den ayrı, tek bir script bloğu olarak yönetmek hem bakımı kolaylaştırır hem hatayı azaltır.
• Geçersiz JSON sözdizimi: Eksik virgül, kapanmayan süslü parantez, kaçırılmamış özel karakter — tüm bloğu sessizce devre dışı bırakır. Yayına almadan önce mutlaka doğrulayın.
• Mobil ve masaüstünde farklı yapısal veri: Mobil-öncelikli indeksleme 5 Temmuz 2024'te tamamen tamamlandı; Google sinyalleri akıllı telefon taramasından alıyor. Mobil sürümde masaüstüyle aynı yapısal veri, başlıklar ve iç linkler bulunmalı. Mobilde schema'yı kırpmak, masaüstündeki işaretlemenizin görmezden gelinmesi demektir.
• Render edilmeyen (yalnızca tarayıcıda JS ile geç enjekte edilen) schema: Googlebot render edebilse de, kritik yapısal veriyi sunucu tarafında veya ilk HTML'de sağlamak en güvenli yoldur.
• Kanonik olmayan/yinelenen URL'lerde çelişkili işaretleme: Aynı içeriğin birden çok URL'sinde tutarsız schema, hangi sürümün dikkate alınacağını belirsizleştirir.

Türkçe içeriklerde özellikle dikkat edilmesi gereken sessiz bir tuzak, karakter kodlaması ve kaçış (escaping) meselesidir. Ürün açıklamasında veya başlıkta geçen çift tırnak, ters bölü ya da satır sonu karakterleri doğru kaçırılmazsa JSON-LD bloğu tek bir geçersiz karakter yüzünden komple devre dışı kalır — üstelik sayfa görsel olarak gayet normal göründüğü için sorun gözden kaçar. Bir başka yaygın senaryo, @id ve dahili referans tutarsızlığıdır: Organization ile LocalBusiness'ı ya da Article ile yazar (author) düğümünü birbirine doğru referanslarla bağlamak, Google'ın varlıkları (entity) doğru ilişkilendirmesini kolaylaştırır. Son olarak, çok sayfalı şablon sistemlerinde tek bir hatalı şablon yüzlerce sayfada aynı hatayı çoğaltabileceği için, schema'yı sayfa sayfa değil, şablon düzeyinde doğrulamak çok daha verimlidir.

Doğrulama Yapmadan Yayına Almak

Belki de en kolay önlenebilir hata, schema'yı test etmeden canlıya almaktır. Yayın öncesi ve sonrası kullanmanız gereken araçlar:

• Rich Results Test: Sayfanın zengin sonuç için uygun olup olmadığını, hangi tipin tanındığını ve varsa hata/uyarıları gösterir.
• Schema Markup Validator: schema.org sözdizimini genel olarak doğrular (zengin sonuç uygunluğundan bağımsız yapısal doğruluk için).
• Search Console "Geliştirmeler" raporları: Desteklenen tipler için canlı sitede biriken hata ve uyarıları gösterir. Not: FAQ raporu 2026 Haziran'da kaldırılıyor, dolayısıyla orada FAQ verisi aramayın. Search Console'u uçtan uca kullanmayı Google Search Console rehberimizde anlattık.

İki aracı doğru yerde kullanmak önemli: Rich Results Test "Bu sayfa Google'da zengin sonuç için uygun mu?" sorusunu yanıtlar ve yalnızca Google'ın desteklediği tipleri tanır; Schema Markup Validator ise "schema.org'a göre sözdizimim geçerli mi?" sorusuna bakar ve Google'ın zengin sonuç vermediği tipleri de doğrular. Hata ile uyarı arasındaki farkı da karıştırmayın: hata, tipin zengin sonuç için uygunluğunu tamamen engeller; uyarı ise uygunsunuz ama önerilen bir alan eksik demektir — kritik değildir, fakat fırsat kaybıdır. Pratik bir uyarı: bu araçlar canlı URL'yi tazece tarar, dolayısıyla yeni yayınladığınız bir değişikliği test ederken önbellek veya CDN nedeniyle eski sürümü görebilirsiniz; şüphede kalırsanız Search Console'un URL İnceleme aracıyla Google'ın gördüğü işlenmiş (rendered) HTML'i teyit edin. Test etmeyi tek seferlik bir adım olarak görmeyin; tema güncellemesi, fiyat değişikliği, eklenti çakışması veya şablon düzenlemesi schema'yı sessizce bozabilir. Düzenli denetimi rutininize katın.

Aşırıya Kaçmak ve Spam Algısı Yaratmak

Yapısal veri bir "sıralama hilesi" değildir; sayfayı daha iyi anlaşılır kılan bir bağlam katmanıdır. Aşırı veya manipülatif kullanım, anahtar kelime doldurma gibi spam politikası kapsamına girebilir:

• Alakasız tipleri üst üste yığmak: Tek bir sayfaya konuyla ilgisi olmayan onlarca schema tipi eklemek netlik katmaz, gürültü yaratır. Tavsiye edilen temel set sade tutmaktır: Organization + BreadcrumbList + içeriğe uygun ana tip (Article / Product / LocalBusiness). Spesifik zengin sonuç fırsatı doğdukça genişletin.
• Schema'yı içerik eksikliğini gizlemek için kullanmak: Zayıf, ince (thin) bir sayfayı schema ile "şişirmek" işe yaramaz; Google'ın derdi içeriğin gerçekten yardımcı (people-first) olmasıdır. Yapısal veri, iyi içeriği destekler, onun yerini tutmaz.
• Yanıltıcı/abartılı işaretleme: Gerçekte olmayan indirim, gerçekte verilmeyen değerlendirme ya da yanlış kategori — kısa vadede bir şey kazandırmaz, uzun vadede güveni (E-E-A-T'nin merkezindeki Trust bileşeni) zedeler.

Burada hatırlanması gereken üst ilke, schema'nın kendi başına bir sıralama faktörü olmadığıdır. Google, yapısal verinin içeriği anlamasına ve uygun olduğunda zengin sonuç üretmesine yardım ettiğini söyler; "schema ekledim, sıram yükselecek" şeklinde doğrudan bir vaat yoktur ve sıralama faktörlerinin tam ağırlığı zaten Google tarafından açıklanmaz. Asıl kazanç dolaylıdır: doğru işaretleme, arama sonucunda daha bilgilendirici, daha tıklanır bir görünüm sağlayabilir ve hem klasik aramada hem AI motorlarında içeriğinizin doğru bağlamda anlaşılmasını kolaylaştırır. Doğru zihniyet şudur: schema, doğru ve eksiksiz içeriğin makineler için özetidir. Yerel işletmeler için NAP (isim-adres-telefon) tutarlılığının LocalBusiness schema'sıyla, Search Console verileriyle ve Google İşletme Profili'yle birebir örtüşmesi de bu güvenin bir parçasıdır; yerel tarafı ayrıca yerel SEO rehberimizde ele aldık.

Özet: Schema'da Yapılması ve Yapılmaması Gerekenler

Yapısal verinin doğruluğu, daha geniş bir teknik temizliğin parçasıdır: hız, mobil uyumluluk, kanonik düzen ve tutarlı işaretleme bir bütün olarak güven sinyali üretir. Sitenizin schema kurulumunu ve genel teknik SEO sağlığını gözden geçirmemizi isterseniz GEO denetim aracımıza göz atabilir veya dijital pazarlama danışmanlığı ekibimizden destek alabilirsiniz. Hangi yapısal veri tiplerinin sizin için öncelikli olduğunu netleştirmek isterseniz, kısa bir ücretsiz analiz talebiyle başlayabilirsiniz.