Schema Markup Nedir? Yapısal Verinin SEO'ya Katkısı ve Kurulumu

Schema markup, arama sonuçlarında yıldızlı ürünler, fiyat bilgisi ya da etkinlik tarihleri gördüğünüzde perde arkasında çalışan koddur. Sahada 2012'den beri çalışıyorum ve bu konunun en çok yanlış anlaşılan SEO başlıklarından biri olduğunu rahatlıkla söyleyebilirim. Kimi onu sihirli bir sıralama düğmesi sanıyor, kimi de tamamen gereksiz görüyor. Bu yazıda yapısal verinin gerçekte ne yaptığını, hangi türlerin hâlâ işe yaradığını, Google'ın hangilerini kaldırdığını ve kurulumu adım adım nasıl yapabileceğinizi anlatıyorum.

Schema markup nedir ve ne işe yarar?

Schema markup, bir sayfadaki bilgileri schema.org sözlüğüyle etiketleyerek arama motorlarına "bu bir ürün, bu fiyatı, bu da stok durumu" diye açıkça anlatan yapısal veri kodudur. Google bu kodu içeriği anlamak ve sayfayı zengin sonuçlara uygun hâle getirmek için kullanır.

Basit bir benzetme yapayım. Sayfanızı okuyan bir insan, "1.250 TL" yazısının fiyat olduğunu hemen anlar. Tarayıcı bot ise bu metni yalnızca karakter dizisi olarak görür. Yapısal veri, bu belirsizliği ortadan kaldıran bir etiket katmanıdır. Böylece Google tahmin yürütmek zorunda kalmaz; ne gördüğünü sizin beyanınızla doğrular.

Schema.org sözlüğü Google, Microsoft, Yahoo ve Yandex'in ortak girişimiyle doğdu. Bugün sözlükte 800'den fazla tür ve 1.500'den fazla özellik var. Ancak Google bu türlerin yalnızca küçük bir kısmını görsel bir zengin sonuca dönüştürüyor. Bu nedenle "schema.org'da var" ile "Google'da görünür" arasındaki farkı en baştan akılda tutmanız gerekir.

Yapısal veri Google'da tam olarak neyi değiştirir?

Yapısal verinin iki ayrı etkisi var. Birincisi anlama katmanıdır: Google sayfanızın bir tarif mi, bir iş ilanı mı, yoksa bir yerel işletme sayfası mı olduğunu daha az tahminle çözer. İkincisi görünüm katmanıdır: uygun türlerde arama sonucunuz yıldız, fiyat, stok, tarih veya görsel gibi ek öğelerle zenginleşir.

Google'ın yapısal veriye giriş belgesinde paylaştığı vaka çalışmaları bu görünüm etkisini rakamlarla anlatıyor. Örneğin Rotten Tomatoes, yapısal veriyle zenginleşen sayfalarda yüzde 25 daha yüksek tıklama oranı ölçmüş. Nestlé, zengin sonuç olarak görünen sayfaların görünmeyenlere göre yüzde 82 daha yüksek tıklama oranı aldığını bildirmiş. Food Network ise sayfalarının yüzde 80'ini dönüştürdükten sonra ziyaretlerde yüzde 35 artış görmüş.

Bu rakamları kendi sitenize doğrudan taşımayın; her biri büyük bir markanın kendi ölçümüdür. Yine de yön net: aynı sırada duran iki sonuçtan daha bilgilendirici görüneni kullanıcının gözüne önce çarpar. Kısacası yapısal veri, sıranızı değil, o sıradaki vitrininizi güçlendirir.

Schema markup sıralamayı doğrudan yükseltir mi?

Hayır, en azından doğrudan değil. Google yapısal veriyi genel bir sıralama sinyali olarak konumlandırmıyor. Resmi yapısal veri yönergeleri de doğru işaretlenmiş bir sayfanın bile zengin sonuç göstereceğini garanti etmiyor. Algoritma, kullanıcıya en iyi deneyimi hangi görünümün sunacağına kendisi karar veriyor.

Peki bu durum schema markup çalışmasını değersiz kılar mı? Kesinlikle hayır. Dolaylı etkiler gerçektir. Daha dikkat çekici bir sonuç daha fazla tıklama alır. Google içeriğinizi daha doğru sınıflandırdığında da sayfanız yanlış sorgularda görünmek yerine doğru niyetle eşleşir. Ayrıca ürün ve yerel işletme bilgileri, Google'ın alışveriş ve harita yüzeylerinde tutarlı veri kullanmasına katkı sağlar.

Müşterilerime genelde şöyle özetliyorum: schema kötü bir sayfayı birinci sıraya taşımaz. Buna karşılık iyi bir sayfanın hak ettiği tıklamayı almasına yardım eder. Bu yüzden onu içerik ve teknik temelin üzerine eklenen bir katman olarak düşünmelisiniz, temelin yerine değil.

JSON-LD, Microdata ve RDFa arasında hangisini seçmelisiniz?

Google üç biçimi de destekliyor, ancak açıkça JSON-LD önermektedir. Gerekçesi basit: JSON-LD, sayfanın görünen HTML'inden ayrı bir script bloğunda durur. Dolayısıyla tasarım değiştiğinde bozulmaz ve bakımı en kolay seçenektir. Aşağıdaki tablo farkları özetliyor.

Kendi projelerimde yeni bir kurulumu her zaman JSON-LD ile yapıyorum. Microdata ile kurulmuş eski bir siteyi devraldığımda ise hemen sökmüyorum. Önce hata raporuna bakıyor, çalışıyorsa bir sonraki tasarım yenilemesinde JSON-LD'ye geçiriyorum. Çalışan bir şeyi yalnızca biçim tercihi için bozmak gereksiz risktir.

Bir JSON-LD bloğu nasıl okunur?

JSON-LD ilk bakışta korkutucu görünebilir, ama mantığı bir form doldurmaya benzer. Blok, sayfanın head veya body bölümüne eklenen bir script etiketinin içinde durur. Tipik bir yerel işletme bloğunu parçalara ayırdığınızda şu satırları görürsünüz:

• @context: Kullandığınız sözlüğü bildirir. Neredeyse her zaman schema.org adresidir.
• @type: Varlığın türünü söyler. Örneğin LocalBusiness, Product, Article veya Event.
• name, address, telephone: Türe ait özelliklerdir. Hangi özelliklerin zorunlu olduğunu Google'ın ilgili tür belgesi belirler.
• İç içe nesneler: Adres gibi bilgiler kendi türünü taşır. Örneğin address alanı PostalAddress türünde bir alt nesnedir.
• @id: Varlığa kalıcı bir kimlik verir. Böylece aynı kuruluşu farklı sayfalarda tek varlık olarak birbirine bağlarsınız.

İşin püf noktası şu: bloktaki her değer, sayfada kullanıcının gördüğü bilgiyle birebir eşleşmeli. Sayfada 09:00 ile 18:00 arası açık yazıyorsa, JSON-LD'de başka bir saat olmamalı. Tutarsızlık hem güveni zedeler hem de yönerge ihlaline dönüşebilir.

Birden fazla varlığı tek sayfada tanımlamanız gerekirse @graph dizisini kullanabilirsiniz. Örneğin bir blog yazısında Article, yazarı temsil eden Person ve siteyi yöneten Organization aynı dizide yer alır. Her birine bir @id verip birbirine referans verdiğinizde, Google bu parçaları tek bir bilgi ağı olarak okur. Bu yöntem, aynı kuruluş bilgisini her sayfada yeniden yazmaktan çok daha düzenlidir.

Elle yazmak istemiyorsanız, ücretsiz schema oluşturucu aracımız ile türü seçip alanları doldurarak hazır bir JSON-LD bloğu alabilirsiniz. Ardından bu bloğu doğrulama aracında test etmeniz yeterli.

İşletmeler için en çok işe yarayan schema türleri hangileri?

Her siteye her türü eklemek gerekmez. Sayfanın gerçekte ne olduğuna uyan türü seçersiniz. Saha tecrübeme göre çoğu işletmenin ihtiyacı şu listede toplanıyor:

• Organization: Logo, resmi ad, iletişim ve sosyal profiller. Kurumsal her sitenin ana sayfasında olmalı.
• LocalBusiness: Adres, çalışma saatleri ve telefon. Fiziksel adresi olan işletmeler için temel türdür.
• Product ve Offer: Fiyat, stok, kargo ve iade bilgisi. E-ticaret sitelerinin en değerli türüdür.
• Article: Blog ve haber içeriğinde başlık, yazar, yayın ve güncelleme tarihi.
• BreadcrumbList: Sayfanın site hiyerarşisindeki yeri.
• Event: Konser, seminer ve eğitim gibi tarihli etkinlikler.
• JobPosting: İş ilanları. Google'ın iş arama deneyimine girmenin yoludur.
• VideoObject: Sayfada gömülü videonun süresi, küçük resmi ve yüklenme tarihi.

Bir de ProfilePage ve DiscussionForumPosting gibi daha dar kullanımlı türler var. Örneğin topluluk forumu işletiyorsanız ikincisi anlamlıdır. Ancak bir hizmet sitesine forum şeması eklemek, yalnızca yanlış bir beyan olur.

Google hangi zengin sonuç türlerini hâlâ destekliyor?

Google, desteklediği türleri Search Central'daki arama galerisinde listeliyor. Bu yazıyı hazırlarken galeride makale, içerik haritası, döngü (carousel), kurs listesi, veri kümesi, tartışma forumu, eğitim soru cevap, işveren puanı, etkinlik, görsel meta verisi, iş ilanı, yerel işletme, matematik çözücü, film, kuruluş, ürün, profil sayfası, soru cevap, tarif, yorum snippet'i, yazılım uygulaması, speakable, abonelik ve ücretli içerik, tatil kiralama ve video bulunuyordu.

Bu listeyi okurken iki noktaya dikkat etmenizi öneririm. Birincisi, bazı türler yalnızca belirli ülkelerde veya dillerde görünür. Örneğin bir türün İngilizce sonuçlarda görünmesi, Türkçe aramada da aynı şekilde görüneceği anlamına gelmez. İkincisi, galeri sürekli değişiyor. Dolayısıyla bir ajansın iki yıl önce hazırladığı kontrol listesi bugün eksik ya da hatalı olabilir.

Benim pratiğim şu: yeni bir projeye başlamadan önce galeriyi ve Google'ın belge güncellemeleri sayfasını yeniden okuyorum. On dakikalık bu kontrol, artık görünmeyen bir özellik için saatler harcamanızı engeller.

Google hangi yapısal veri türlerini kaldırdı?

Son yıllarda Google arama sonuç sayfasını sadeleştirme gerekçesiyle pek çok zengin sonucu emekliye ayırdı. Aşağıdaki tablo, Google'ın resmi güncelleme kayıtlarına dayanan başlıca değişiklikleri özetliyor.

Bu tabloyu bir uyarı olarak okuyun: zengin sonuç kalıcı bir hak değildir. Google, kullanımın az olduğu ya da kullanıcıya ek değer katmadığı görünümleri kaldırabiliyor. Bu nedenle stratejinizi tek bir görsel özelliğe bağlamamalısınız.

FAQ işaretlemesini sitenizden silmeli misiniz?

Google, 8 Mayıs 2026'da FAQ zengin sonuç belgesine kullanımdan kaldırma notu ekledi ve özelliğin 7 Mayıs 2026'dan itibaren aramada görünmeyeceğini duyurdu. Haziran 2026'da da belgeyi tamamen kaldırdı. Aslında bu sürecin başlangıcı Ağustos 2023'e dayanıyor; o tarihte Google SSS sonuçlarını yetkili devlet ve sağlık siteleriyle sınırlamıştı.

Mevcut FAQPage kodunu silmek zorunda değilsiniz. Geçerli ve sayfadaki içerikle uyumlu bir işaretleme hata üretmez. Üstelik FAQPage schema.org sözlüğünde yaşamaya devam ediyor ve başka sistemler bu veriyi okuyabilir. Ancak yalnızca zengin sonuç kazanmak için yeni SSS bölümleri yazmanın bugün bir anlamı kalmadı.

Benim önerim şu: SSS bölümünüz kullanıcıya gerçekten yardım ediyorsa sayfada kalsın. Sorular gerçek müşteri sorularından geliyorsa, bu içerik hem uzun kuyruklu aramalarda hem de cevap motoru optimizasyonunda işe yarar. Kısacası SSS'yi Google için değil, okur için yazın.

Schema markup kurulumu adım adım nasıl yapılır?

Schema markup kurulumunu yıllardır aynı sırayla yapıyorum. Bu sıra, gereksiz kod eklemeyi ve sonradan çıkan tutarsızlıkları büyük ölçüde önlüyor:

1. Sayfa envanteri çıkarın. Ana sayfa, hizmet sayfaları, ürünler, blog yazıları ve iletişim sayfası gibi şablon tiplerini listeleyin.
2. Her şablona tür atayın. Ürün şablonuna Product, blog şablonuna Article, iletişim sayfasına LocalBusiness gibi.
3. Google belgesinden zorunlu ve önerilen özellikleri okuyun. Zorunlu alanlar eksikse sayfa zengin sonuç için uygun olmaz.
4. Veriyi kaynaktan üretin. Fiyatı ve stoğu elle yazmak yerine veritabanından alın; böylece sayfa ile kod hep eşleşir.
5. Test ortamında doğrulayın. Kodu Zengin Sonuç Testi ve Schema Markup Validator ile kontrol edin.
6. Yayına alın ve URL Denetimi yapın. Search Console'da canlı URL'yi test ederek Google'ın kodu gördüğünü teyit edin.
7. Raporları izleyin. Search Console'daki geliştirme raporlarında hata ve uyarıları haftalık takip edin.

Dördüncü adımı özellikle vurgulamak istiyorum. Elle yazılmış JSON-LD, ilk fiyat güncellemesinde eskir. Dinamik üretim ise baştan biraz daha fazla emek ister ama yıllarca bakım derdi çıkarmaz.

WordPress ve hazır altyapılarda şemayı nasıl eklersiniz?

WordPress kullanıyorsanız popüler SEO eklentileri temel Organization, WebSite, Article ve BreadcrumbList işaretlemesini zaten otomatik üretir. Bu yüzden ilk işiniz, sayfa kaynağını açıp mevcut kodu görmek olmalı. Eklentinin ürettiği blokların üstüne ikinci bir eklentiyle aynı türü eklemek, çift ve çelişkili veri üretir.

Shopify ve WooCommerce gibi e-ticaret altyapılarında temanın ürün şeması ürettiği sık görülür. Ancak tema kodu çoğu zaman eksiktir. Örneğin kargo ücreti, iade politikası veya marka alanı boş kalabilir. Böyle durumlarda temayı düzenlemek ya da bir uygulamayla eksik alanları tamamlamak gerekir.

Özel yazılım sitelerde ise şemayı şablon katmanında, sunucu tarafında üretmenizi öneririm. Google Etiket Yöneticisi ile JavaScript üzerinden şema eklemek teknik olarak mümkün. Yine de ürün gibi sık değişen veride sunucu tarafı üretim daha güvenilirdir. Sıfırdan bir site planlıyorsanız, web tasarım sürecinde şemayı baştan mimariye dahil etmek en ucuz yoldur.

Zengin Sonuç Testi ile kodunuzu nasıl doğrularsınız?

Google'ın Zengin Sonuç Testi aracı, bir URL'yi ya da yapıştırdığınız kodu tarar. Ardından hangi zengin sonuç türlerine uygun olduğunuzu, hangi alanların hata veya uyarı verdiğini listeler. Araç yalnızca Google'ın desteklediği türleri değerlendirir.

Schema.org'un kendi doğrulayıcısı olan Schema Markup Validator ise farklı bir iş görür. Google'ın desteklemediği türler dahil tüm schema.org sözdizimini kontrol eder. Bu yüzden ikisini birlikte kullanıyorum. Zengin Sonuç Testi "Google'da uygun muyum?" sorusunu yanıtlar. Validator ise "Kodum sözlüğe göre doğru mu?" sorusunu yanıtlar.

Sonuçları okurken hata ile uyarıyı ayırın. Hata, zorunlu bir alanın eksik olduğunu gösterir ve zengin sonucu engeller. Uyarı ise önerilen bir alanın eksik olduğunu söyler; sayfanız yine uygundur, yalnızca daha az bilgilendirici görünür. Önce hataları, sonra ticari değeri yüksek uyarıları kapatırsınız.

Search Console'da yapısal veri hatalarını nasıl takip edersiniz?

Test aracı tek bir sayfaya bakar. Search Console ise tüm sitenizi izler. Google, sitenizde desteklenen bir tür bulduğunda "Geliştirmeler" veya zengin sonuç durumu bölümüne ilgili raporu ekler. Örneğin ürün snippet'leri, satıcı listelemeleri, içerik haritaları veya videolar için ayrı raporlar görürsünüz.

Her rapor sayfaları geçerli, uyarılı ve geçersiz olarak ayırır. Bir hatayı düzelttikten sonra "Düzeltmeyi doğrula" düğmesine basarsınız. Google ardından etkilenen sayfaları yeniden tarar. Bu süreç birkaç gün ile birkaç hafta arasında sürebilir; sabırlı olmanız gerekir.

Ayrıca Performans raporundaki "Arama görünümü" filtresi, zengin sonuç alan sayfaların gösterim ve tıklamalarını ayrıca görmenizi sağlar. Böylece şema çalışmasının etkisini tahminle değil, veriyle konuşursunuz. Başlık ve açıklamanızın sonuçta nasıl duracağını önceden görmek için SERP önizleme aracını da kullanabilirsiniz.

Hangi hatalar manuel işleme yol açabilir?

Google, yapısal veri yönergelerini ihlal eden sitelere manuel işlem uygulayabiliyor. Önemli bir ayrıntı var: bu işlem genellikle sayfanın normal sıralamasını değil, zengin sonuç uygunluğunu etkiler. Yine de bu durum, emeğinizin boşa gitmesi demektir. Sahada en sık gördüğüm ihlaller şunlar:

• Görünmeyen içeriği işaretlemek. Sayfada olmayan yorumları veya fiyatları yalnızca kodda göstermek.
• Kendi kendine yorum. İşletmenin kontrol ettiği yorumlarla LocalBusiness veya Organization sayfasına yıldız eklemeye çalışmak. Google bu sayfaları yıldız özelliği için uygun saymıyor.
• Alakasız tür. Hizmet sayfasını Product ya da Event olarak işaretlemek.
• Uydurma puanlar. Gerçek kullanıcılardan gelmeyen puan ve yorumlar.
• Eskimiş veri. Bitmiş etkinlikler, kapanmış ilanlar veya stokta olmayan ürünü stokta göstermek.

Search Console'daki Manuel İşlemler raporunu ayda bir kontrol etmenizi öneririm. Bir işlem varsa sorunu düzeltip yeniden inceleme talebi gönderirsiniz.

Schema markup yapay zeka aramalarında avantaj sağlar mı?

Bu soruyu son bir yılda neredeyse her toplantıda duyuyorum. Google'ın yapay zeka özellikleri belgesi açık konuşuyor: AI Overviews veya AI Mode'da görünmek için özel bir schema.org işaretlemesi gerekmiyor. Aynı belge, yapısal verinin görünen metinle uyumlu olmasını genel iyi uygulamalar arasında sayıyor.

Yani schema markup yapay zeka aramalarında sihirli bir kısayol değil. Buna karşın varlıklarınızı, yani kuruluşunuzu, ürünlerinizi ve yazarlarınızı tutarlı biçimde tanımlamak, makinelerin sizi doğru anlamasına katkı sağlar. Özellikle Organization şemasındaki sameAs alanı, resmi sosyal profillerinizi tek bir kimlikte bağlar.

Benim yaklaşımım şu: şemayı yapay zeka için ayrı bir proje olarak görmüyorum. İyi yapılandırılmış içerik, net cevaplar ve güvenilir kaynaklar asıl işi yapar. Bu konuyu AI Overviews için içerik yazımı ve yapay zeka sonrası teknik SEO yazılarımda ayrıntılı anlattım.

E-ticaret sitelerinde ürün şeması neden ayrı dikkat ister?

Ürün şeması, arama sonuçlarında fiyat, stok, puan ve kargo bilgisini gösterebilen en ticari türdür. Google ürün işaretlemesini iki farklı deneyim için değerlendiriyor: ürün snippet'leri ve satıcı listelemeleri. Satın alma yapılabilen sayfalarda Offer içindeki fiyat, para birimi ve stok durumunun eksiksiz olması gerekir.

Google, son dönemde iade politikası ve sadakat programı için de ayrı belgeler yayımladı. Dolayısıyla yalnızca fiyat vermek yetmiyor; kargo süresi, iade koşulları ve varsa üye fiyatı gibi bilgileri de tanımlayabilirsiniz. Bu alanlar, alışverişçinin karar anında aradığı bilgilerdir.

En sık gördüğüm hata, stok bittiğinde şemanın "InStock" kalmasıdır. Kullanıcı sonuçta stokta görüp tıklıyor, sayfada "tükendi" yazısıyla karşılaşıyor. Bu hem hayal kırıklığı yaratır hem de veri tutarsızlığı demektir. Bu yüzden ürün şemasını mutlaka ürün veritabanından besleyin. Büyük kataloglarda kategori yapısı ile şemayı birlikte planlamak da ayrıca işinizi kolaylaştırır.

Yerel işletmeler için hangi şema kombinasyonu mantıklı?

Klinik, restoran, avukatlık bürosu ya da oto servis gibi yerel işletmeler için temel kombinasyon oldukça sade. Ana sayfada Organization, iletişim veya şube sayfasında LocalBusiness ya da onun alt türü yeterlidir. Örneğin Dentist, Restaurant veya AutoRepair gibi daha özel bir alt tür seçebilirsiniz.

LocalBusiness içinde adres, telefon, çalışma saatleri, konum koordinatları ve fiyat aralığı en işe yarayan alanlardır. Birden fazla şubeniz varsa her şubenin kendi sayfası ve kendi LocalBusiness bloğu olmalı. Tek sayfaya on şube adresi yığmak, Google'ın hangi şubeyi kastettiğinizi anlamasını zorlaştırır.

Unutmayın ki yerel aramada asıl belirleyici Google İşletme Profili'dir. Şema, sitenizdeki bilgilerin profille tutarlı olduğunu teyit eden destekleyici bir sinyaldir. Harita görünürlüğünün diğer adımlarını Google Haritalar SEO rehberinde ayrıntılı anlattım.

Schema markup çalışmasının başarısını nasıl ölçersiniz?

Schema markup çalışmasını ölçerken önce doğru soruyu sormalısınız. Soru "sıram yükseldi mi?" değil, "zengin sonuç aldığım sayfaların tıklama oranı değişti mi?" olmalı. Bunun için şu metrikleri takip ediyorum:

• Geçerli öğe sayısı: Search Console geliştirme raporlarındaki geçerli sayfa sayısının zaman içindeki seyri.
• Zengin sonuç gösterimleri: Performans raporunda arama görünümü filtresiyle ayrılmış gösterim ve tıklamalar.
• Tıklama oranı: Aynı sayfanın şema öncesi ve sonrası dönemlerdeki tıklama oranı; benzer ortalama konumdaki dönemleri karşılaştırın.
• Hata sayısı: Yeni yayınlar sonrası artan hata, şablonda bir kırılma olduğunu gösterir.

Bu metrikleri basit bir tabloda aylık olarak kaydetmenizi öneririm. Satırlara şablon tiplerini, sütunlara geçerli öğe, hata, gösterim ve tıklama oranını yazın. Böylece bir tema güncellemesinin ürün şemasını bozduğunu ya da yeni bir blog şablonunun Article alanlarını eksik bıraktığını, trafik düşmeden önce fark edersiniz.

Karşılaştırma yaparken mevsimselliği de hesaba katın. Örneğin bir e-ticaret sitesinde Kasım ayını Şubat ile kıyaslamak yanıltır. Saha tecrübeme göre anlamlı bir okuma için en az dört ile sekiz haftalık bir dönem gerekir; bu bir başlangıç aralığıdır, garanti değil.

Schema markup ile ilgili en yaygın yanılgılar nelerdir?

Yıllar içinde müşteri toplantılarında aynı yanılgıları defalarca duydum. Bunları bilmek, hem bütçenizi hem de zamanınızı korur.

Birinci yanılgı, "ne kadar çok tür, o kadar iyi" düşüncesidir. Oysa alakasız tür eklemek fayda sağlamaz, hatta yönerge ihlaline dönüşebilir. İkinci yanılgı, zengin sonucun kalıcı olduğunu sanmaktır. FAQ ve HowTo örnekleri bunun tersini gösterdi. Üçüncü yanılgı ise şemanın içerik eksikliğini kapatacağı beklentisidir. Zayıf bir ürün açıklaması, mükemmel bir Product bloğuyla da zayıf kalır.

Bir de ajans tekliflerinde sık rastladığım bir vaat var: "Şema ekleyelim, yıldızlar çıksın." Hizmet sayfanızda kendi topladığınız yorumlar varsa, yukarıda anlattığım kural yüzünden bu yıldızlar büyük ihtimalle hiç görünmez. Böyle bir vaatle karşılaşırsanız, hangi türle ve hangi Google belgesine dayanarak yapılacağını sormanızı öneririm.

Dördüncü yanılgı biraz daha tekniktir: test aracında yeşil tik görmek, zengin sonucun geleceği anlamına gelmez. Test yalnızca uygunluğu gösterir. Son kararı, sorgu ve kullanıcı bağlamına göre Google verir. Bu yüzden beklentiyi baştan doğru kurmak, ekip içinde hayal kırıklığını önler.

Schema markup çalışmasını ne zaman bir uzmana bırakmalısınız?

Tek sayfalık bir kurumsal site için Organization ve LocalBusiness bloğunu kendiniz ekleyebilirsiniz. Araç kullanır, test eder ve yayına alırsınız. Ancak bazı durumlar uzman desteği gerektirir.

Örneğin binlerce ürünlü bir katalog, çok dilli bir yapı, sık değişen fiyatlar veya birden fazla altyapıdan beslenen bir site işi karmaşıklaştırır. Ayrıca Search Console'da sürekli artan hatalar görüyorsanız, sorun genellikle şablon ya da veri akışı katmanındadır. Bu tür işleri SEO danışmanlığı kapsamında teknik denetimin bir parçası olarak ele alıyorum. E-ticaret tarafında ise e-ticaret danışmanlığı ile ürün verisini ve şemayı birlikte düzenliyoruz.

Sitenizin mevcut şema durumuna birlikte bakmak isterseniz iletişim sayfasından bana yazabilirsiniz. İlk görüşmede neyin eksik, neyin gereksiz olduğunu açıkça konuşuruz.

Özetle schema markup'a nasıl yaklaşmalısınız?

Schema markup, arama motorlarıyla aynı dili konuşmanızı sağlayan bir çeviri katmanıdır. Doğrudan sıralama getirmez, ama doğru kurulduğunda sonuçtaki görünümünüzü ve anlaşılırlığınızı güçlendirir. Google'ın desteklediği türler zaman içinde değişiyor; bu nedenle kurulumu bir kez yapıp unutmak yerine düzenli olarak gözden geçirmelisiniz.

Başlamak için üç adım yeterli. Önce sitenizdeki mevcut kodu test edin. Ardından şablon başına doğru türü atayın ve veriyi kaynaktan üretin. Son olarak Search Console'da hataları ve tıklama oranını izleyin. Bu döngüyü kurduğunuzda yapısal veri, sessizce çalışan güvenilir bir SEO bileşenine dönüşür.