Blog Yazısı · SEO

Yapılandırılmış Veri: Schema’yı Sayfa Amacına Göre Seçin

KepezWeb Ekibi 8 dk okuma SEO
Yapılandırılmış Veri: Schema’yı Sayfa Amacına Göre Seçin

Yapılandırılmış veri, arama motoruna süsleme kodu göndermek değil; sayfanın gerçek işini makineye anlatmaktır. Bu rehberde Schema türünü sayfa amacına göre nasıl seçeceğinizi, hangi işaretlemenin fazla veya hatalı olduğunu ve temizlik rutininizi adım adım göreceksiniz.

Yapılandırılmış veri sayfanın işini tarif eder

Yapılandırılmış veri, birçok sitede şablonun altına yapıştırılmış bir JSON bloğu gibi durur. Sayfa bir hizmet anlatırken Product, bir rehber yazısı FAQPage, her şablon da Organization ve sahte yıldızla şişer. Arama motoru bu kodu süsleme olarak okumaz. Sayfanın ne olduğunu, kime ait olduğunu ve kullanıcının burada hangi kararı vereceğini bu işaretlemeden çıkarmaya çalışır.

Schema, bu tarifi ortak bir sözlükle yazmanın yoludur. Kullanıcı kodu görmez. Motor ise başlık, fiyat, yazar, iş türü veya soru-cevabı serbest metinden tahmin etmek yerine sizin verdiğiniz varlıklarla eşlemeye çalışır. Kod görünür içerikle aynı cümleyi kurmuyorsa süsleme değil, yanlış tarif üretmiş olursunuz.

Doğru tür, sıralama vaadi taşımaz. Anlamı netleştirir ve bazı sorgularda zengin sonucun kapısını aralayabilir. Yanlış tür o kapıyı kapatır; üstüne sayfanın asıl işini de gölgeler. Bu rehber eklenti kopyalamayı değil, sayfanın gerçek görevine uyan türü seçmeyi ve hatalı işaretlemeyi ayıklamayı anlatır.

Önce sayfa amacı, sonra Schema türü

Tür seçimine JSON’dan başlamak, boyayı duvar kurumadan sürmeye benzer. Önce sayfanın işi netleşir. Bu iş, menü etiketinden değil; kullanıcının sorusundan ve sayfanın verdiği yanıttan okunur. Aynı anahtar kelimeyi taşıyan iki URL farklı niyet taşıyabilir. Biri karşılaştırma bekler, diğeri satın alır. İşaretleme de bu ayrımı izlemelidir.

Sayfa amacını üç soruyla sıkıştırın. Bu sayfa hangi varlığı temsil ediyor: makale, ürün, hizmet, yerel işletme, kategori listesi mi? Kullanıcıya ne vaat ediyor: öğretmek, karşılaştırmak, satın aldırmak, randevu aldırmak mı? Sayfadaki tek ana eylem nedir? Bu üç cevap net değilse Schema türü de net olmaz.

Arama tarafında bu iş, sorgunun arama niyeti ile aynı hizaya gelmesidir. Bilgi niyeti taşıyan bir rehberi Product gibi işaretlemek, ticari niyeti taşıyan bir ürün kartını yalnızca Article gibi bırakmak kadar yanlıştır. Motor, görünür hiyerarşi ile işaretleme çelişince görünür içeriği esas alır; çelişki tekrarlanırsa işaretlemeyi yok sayabilir.

Sayfada görünmeyen bir iddiayı işaretlemeyin. Kod, ekrandaki vaadin makine dilindeki kopyasıdır; fazlası değil.

Amaç değişince tür de değişir. Kampanya sayfası kalıcı hizmet sayfasına dönmüşse Offer ve geçici fiyat kalmamalıdır. Blog yazısı ürün detayına evrilmişse Article tek başına yetmez. Schema’yı bir kez ekleyip unutmak, eski meta başlığı bırakmakla aynı tür ihmalkârlıktır.

Sayfa tipine göre doğru türü eşleyin

Aşağıdaki eşleme bir şablon değil, karar tahtasıdır. Bir sayfada birden fazla tür bulunabilir; ancak bir tane ana varlık vardır. Destekleyen türler ana varlığı açıklar, onun yerini almaz.

Sayfa Asıl iş Uygun türler Sık hata
Ana sayfa Markayı ve yolları tanıtmak WebSite, Organization Product, sahte SSS yığını
Hizmet / kurumsal Teklifi ve kapsamı anlatmak Service, gerekirse Organization Uydurma AggregateRating
Rehber / makale Bir soruyu yanıtlamak Article veya BlogPosting Her yazıya otomatik FAQPage
Ürün Satın alma kararını netleştirmek Product, Offer Stokta yokken InStock demek
Kategori Seçenekleri taratmak CollectionPage, ItemList (dikkatli) Tek ürüne ait Offer’ı listeye yapıştırmak
Yerel iletişim Adres, saat, yol tarifi LocalBusiness (gerçekten yerel ise) Her şablona aynı NAP bloğu
SSS sayfası Tekrarlayan soruları yanıtlamak FAQPage İki soruluk süsleme bloğu

Ana sayfa ve kurumsal sayfalar

Ana sayfanın işi vitrin kurmaktır: kimsiniz, kime hitap ediyorsunuz, ziyaretçi nereye gitsin. WebSite arama kutusunu ve site adını, Organization yasal kimliği ve yayıncıyı tarif eder. Bu ikisi ana sayfada anlamlıdır. Aynı bloğu her alt sayfaya yapıştırmak, her odaya aynı tabela asmak gibidir; gürültü üretir.

Hizmet sayfasında asıl varlık hizmetin kendisidir. Service, ne sunulduğunu ve kimin sunduğunu bağlar. Burada Product kullanmak, satılmayan bir SKU uydurmak anlamına gelir. Yıldızlı puan görünür bir, bağımsız ve sayfada duran bir derleme değilse AggregateRating eklemeyin. KepezWeb işlerinde bu ayrım, şablon eklentisinin varsayılanını olduğu gibi bırakmamayı gerektirir.

Rehber, makale ve bilgi sayfaları

Rehberin işi bir soruyu kapatmaktır. Article veya BlogPosting; başlık, yazar, yayın ve güncelleme tarihini görünür metinle eşler. BreadcrumbList sayfanın sitedeki yerini tarif eder, ana varlık olmaz. Yazının sonunda iki kısa soru varsa bu bir SSS sayfası değildir. FAQPage, sayfanın asıl biçimi soru-cevap olduğunda anlam taşır.

Zengin sonuç umuduyla her yazıya FAQPage basmak, türü süslemeye çevirir. Üstelik bu türde görünürlüğün her sitede ve her sorguda açılması beklenmemelidir; uygunluk kuralları zamanla daralabilir. Asıl test şudur: bu soruları silseniz sayfa hâlâ aynı işi görür mü? Görürse FAQPage ana tarif değildir.

Ürün, teklif ve kategori

Ürün sayfasının işi kararı tamamlamaktır. Product adı, görseli ve tanımlı Offer’ı görünür fiyat, para birimi ve stok cümlesiyle aynı tutmalıdır. Kasada KDV dahil tutar yazıyorken işaretlemede başka bir rakam bırakmak, kullanıcıya değil motora yalan söylemektir. Varyant varsa hangi SKU’nun işaretlendiği sayfadaki seçili hale bağlanır.

Bu tarifi kurmadan önce ürün detay sayfası bilgisinin kendisi net olmalıdır. Ekranda beden, kargo ve stok dağınıkken Schema düzeni kurtarmaz. Kategori sayfası ise tek ürün değildir. Listeyi ItemList ile tarif etmek, her karta eksik Offer basmak anlamına gelmez. Vitrin tarama işi görür; satın alma işi ürün URL’sindedir.

Hatalı işaretlemeyi ayıklamak

Hatalı Schema çoğu zaman kötü niyetten değil, şablon tembelliğinden doğar. Aynı blok her sayfaya basılır, eski kampanya alanı silinmez, eklenti “SEO tamamlansın” diye Review üretir. Ayıklama, yeni tür eklemeden önce yapılacak iştir. Fazla kod, eksik koddan daha çok zarar verir çünkü çelişki üretir.

Üç kaynak tekrar tekrar karşınıza çıkar. Birincisi şablon kirliliği: header’da Organization, body’de Product, footer’da LocalBusiness ve yazının altında FAQPage. İkincisi görünmeyen içerik: kapalı sekmede kalan SSS, kullanıcının görmediği fiyat, yalnızca işaretlemede duran stok. Üçüncüsü abartı: kendi yazdığınız beş yıldız, olmayan yazar, güncellenmemiş tarih.

  • Sayfada durmayan fiyat, stok, puan ve yorumu silin.
  • Ana varlıkla çelişen ikinci türü kaldırın; destekleyen türü ana türün altına bağlayın.
  • Her URL’de tekrarlayan Organization bloğunu ana sayfa ve yayıncı ilişkisine indirgeyin.
  • Kampanyası bitmiş Offer, eski SKU ve kalkmış etkinlik işaretlemesini temizleyin.
  • Otomatik FAQ, HowTo veya Review üreten eklentiyi sayfa tipine göre kapatın.

Yerel işletme işaretlemesi ayrı bir tuzaktır. Tek ofisi olan, NAP bilgisi her sayfada aynı olan bir firmada LocalBusiness ana sayfada veya iletişim sayfasında durabilir. Şubesi yokken her blog yazısına aynı adres ve saatleri basmak, her makaleyi mağaza gibi gösterir. Adres sayfada yoksa işaretlemede de yoktur.

Aynı sayfada birden fazla tür

Bir sayfa birden fazla gerçeği taşıyabilir. Bir ürün yazısı hem Article hem Product değildir; ya incelemedir ya ürün detayıdır. Asıl varlık hangisiyse tür odası ona aittir. Destekleyen bilgiler—yayıncı, ekmek kırıntısı, görsel, yazar—ana varlığa bağlanır. Bağ kurulmazsa motor iki rakip tarif görür.

Pratik kural sadedir. Önce ana varlığı seçin. Sonra yalnızca o varlığı açıklayan özellikleri ekleyin. Üçüncü adımda “acaba şu tür de zengin sonuç getirir mi” diye eklenen her bloğu geri alın. Zengin sonuç, doğru tariften doğabilecek bir yan üründür; hedef değildir.

JSON-LD’nin bakımı mikro veriye göre genellikle daha kolaydır çünkü içerik şablonundan ayrı durur. Ayrı durması, onu bağımsız bir süsleme dosyası yapmaz. Betik, o URL’de görünen başlık, tarih, fiyat ve işle aynı isimleri kullanmalıdır. İsimler sapınca doğrulama aracı yeşil yaksa bile anlam bozulur.

Kontrol listesi: eklemeden önce ve sonra

Yayın öncesi kontrol, doğrulama aracının tikine indirgenemez. Araç sözdizimini ve zorunlu alanları yakalar. Sayfa amacına uygunluğu yakalamaz. Uygunluk, editörün işidir: bu tür bu URL’nin vaadine uyuyor mu, görünür metinle aynı mı, başka bir şablondan sızmış mı?

  1. URL’nin işini bir cümleyle yazın; cümleye uymayan türü eleyin.
  2. Ana varlığı seçin; destekleyen türleri ana varlığa bağlayın.
  3. Zorunlu özellikleri görünür alanlardan doldurun; boşluğu uydurmayın.
  4. Fiyat, stok, tarih, yazar ve puanı kaynak sistemle karşılaştırın.
  5. Aynı şablonu kullanan diğer sayfa tiplerinde bloğun sızmadığını kontrol edin.

Yayın sonrası iş, tarama ve dizin gerçeğine bakmaktır. Google Search Console içinde URL denetimi ve zengin sonuç raporları, işaretlemenin taranıp taranmadığını ve hangi türün hata verdiğini gösterir. Rapordaki uyarı, her zaman “daha fazla tür ekle” demez. Sık görülen ihtiyaç, fazla türü silmek veya özelliği içerikle eşlemektir.

Sayfa amacı değiştiğinde aynı rutini tekrarlayın. Ürün kalkmışsa Product kalmamalıdır. Yazı arşive alınmışsa güncel tarih iddiası durmamalıdır. Yapılandırılmış veri, yayın anının fotoğrafı değil; sayfa sözleşmesinin güncel kopyasıdır. KepezWeb tarafında bu kopya, şablon, içerik ve tarama raporunun aynı haritada durmasıyla korunur.

Sıkça Sorulan Sorular

Her sayfaya Organization ve WebSite eklemek gerekir mi?

Hayır. Organization ve WebSite ana sayfada, gerekirse yayıncı ilişkisinde anlam taşır. Her URL’ye aynı kimlik bloğunu basmak ana varlığı boğar. Alt sayfada ihtiyaç varsa yayıncı olarak bağlayın; her şablona ikinci bir ana tür eklemeyin.

FAQPage her blog yazısının sonuna konmalı mı?

Konmamalı. FAQPage, sayfanın asıl biçimi soru-cevap ise işe yarar. Yazının altına eklenen iki kısa soru, türü süslemeye çevirir. Zengin sonucun her sitede görüneceği de varsayılmamalıdır; uygunluk kuralları değişebilir.

Yapılandırılmış veri sıralamayı yükseltir mi?

Sıralama vaadi yoktur. İşaretleme, sayfanın ne olduğunu netleştirir. Bazı sorgularda zengin sonuç için uygunluk doğabilir; bu görünürlük de garanti değildir. Yanlış veya çelişen tür, beklenen faydayı getirmez ve anlamı bulanıklaştırır.

Ürün olmayan sayfada Product kullanmak ne bozar?

Olmayan bir SKU, fiyat ve stok uydurmuş olursunuz. Motor sayfayı satın alma nesnesi sanır; kullanıcı hizmet veya bilgi bulur. Bu çelişki hem ürün zengin sonuçlarını hem de sayfanın asıl niyetini zayıflatır. Product yalnızca gerçekten satılan, sayfada duran ürüne aittir.

Eski Schema nasıl ayıklanır?

Önce şablonu ve eklentiyi bulun; hangi bloğun hangi sayfa tipine basıldığını çıkarın. Ana varlıkla çelişen türleri, görünmeyen özellikleri ve bitmiş kampanya alanlarını silin. Temizlikten sonra doğrulama aracı ve Search Console raporuna bakın; yeşil tik, fazla türün doğru olduğu anlamına gelmez.

Sonuç ve Sonraki Adım

Schema’yı süsleme kodu gibi taşıyan şablonlar, sayfa amacı değişince eski türleri de beraberinde sürükler. KepezWeb ile türü içeriğe ve tarama verisine göre yeniden eşlemek için teklif alabilirsiniz. Harita netleşince işaretleme de sadeleşir.

Bu yazıyı paylaş