Schema.org ve JSON-LD: kurumsal siteler için rehber

Schema.org yapılandırılmış veri, bir sayfadaki bilgiyi arama motorlarının ve dil modellerinin tahmin etmeden okuyabileceği ortak bir sözlükle etiketlemektir. Kurumsal sitelerde bu etiketlemenin taşıyıcı biçimi JSON-LD'dir.

Son güncelleme: 29 Temmuz 2026 Tahmini okuma: 15 dakika Yazan: Erdi Baki

Ücretsiz Dijital Varlık Denetimi Yapılandırılmış Veri Hizmeti

Özet

Yapılandırılmış veri, sayfadaki bilgiyi schema.org sözlüğüyle etiketler; kurumsal sitelerde JSON-LD ile yazılır. Doğru kurulmuş bir graf kim olduğunuzu, ne yaptığınızı, nerede bulunduğunuzu ve hangi soruya cevap verdiğinizi tek kaynaktan bildirir. Zengin sonuç garantisi vermez; makine tarafından doğru okunma garantisi verir.

Schema.org yapılandırılmış veri nedir?

Cevap

Schema.org yapılandırılmış veri, bir sayfadaki bilgiyi ortak bir sözlükle etiketleyerek makinelere tahmin ettirmeden bildirmektir. İnsan "Karabaş Mahallesi" yazan satırın adres olduğunu görür; makine göremez. Etiketleme, bu satırın bir PostalAddress olduğunu, hangi kuruma ait olduğunu ve hangi şehirde bulunduğunu kesin biçimde söyler.

Sözlüğün adı schema.org, taşıyıcı biçimin adı JSON-LD. Bu ikisi sık karıştırılır: schema.org hangi kelimeleri kullanabileceğinizi (Organization, Service, FAQPage) tanımlar; JSON-LD ise bu kelimeleri sayfaya nasıl yazacağınızı belirler. Sözlük ortaktır, biçim seçilebilir.

Yapılandırılmış veri bir pazarlama katmanı değil, bir veri sözleşmesidir. Sayfada yazan ile grafta yazan aynı olmak zorundadır. Bu sitede yayımlanan grafta telefon, adres ve e-posta alanları doğrulanmış değerlerle doludur; posta kodu, çalışma saati ve koordinat alanları ise doğrulanmadığı için hiç yazılmamıştır. Boş bırakılmamış, uydurulmamış, çıkarılmıştır.

JSON-LD, Microdata ve RDFa: hangisini seçmelisiniz?

Cevap

Kurumsal sitelerde JSON-LD seçilir. Üç biçim de aynı schema.org sözlüğünü taşır, ancak JSON-LD işaretlemeyi HTML'den ayırır: veri tek bir betik bloğunda toplanır, tasarım değişince bozulmaz ve sunucu tarafında üretilmesi kolaydır. Google da dokümantasyonunda JSON-LD kullanılmasını önerir. Microdata ve RDFa geçerliliğini korur, ancak bakım maliyeti belirgin biçimde yüksektir.

Üç işaretleme biçiminin karşılaştırması
Biçim	Nereye yazılır	Güçlü yanı	Zayıf yanı
JSON-LD	Tek bir betik bloğu; HTML'den bağımsız	Bakımı kolay, tasarımdan etkilenmez, graf ilişkileri kurulabilir	Sayfadaki içerikle eşleşmesi ayrıca denetlenmelidir
Microdata	HTML etiketlerinin içine öznitelik olarak	İşaretleme görünen içeriğe fiziksel olarak bağlıdır	Şablon değişince kolayca kırılır, karmaşık ilişkiler zordur
RDFa	HTML etiketlerinin içine öznitelik olarak	Bağlantılı veri ekosistemiyle geniş uyum	Kurumsal ekipler için en dik öğrenme eğrisi

Pratik kural: mevcut sitenizde Microdata varsa ve çalışıyorsa aceleyle silmeyin; yeni yapıyı JSON-LD ile kurun, ardından eskisini kaldırın. İki biçimin aynı anda ve farklı değerlerle yayında olması, tek başına en sık karşılaştığımız hata tipidir.

Kurumsal bir site hangi schema tiplerini kullanmalı?

Cevap

Her sayfada aynı kurumsal çekirdek bulunur: Organization, WebSite, WebPage ve ana sayfa dışında BreadcrumbList. Bunun üzerine sayfanın kendi tipi eklenir: hizmet sayfasına Service, rehbere TechArticle, iletişime ContactPage, şube sayfasına LocalBusiness. Kural tektir: tip, sayfada gerçekten var olan bir varlığı tarif etmiyorsa eklenmez.

Karar tablosu: hangi sayfaya hangi düğüm
Sayfa tipi	Sayfaya özel düğüm	Koşullu / dikkat
Ana sayfa	WebPage + ItemList (hizmet dizini)	LocalBusiness yalnızca doğrulanmış adres ve telefon varsa
Hizmet detay	Service + FAQPage	offers yalnızca yayımlanmış bir fiyat varsa yazılır
Sektör / çözüm	Service veya CollectionPage	audience ile hedef sektör belirtilebilir
Rehber / makale	TechArticle + Person (yazar)	HowTo ve DefinedTerm içerik gerçekten varsa
Sıkça sorulan sorular	FAQPage	Soru ve cevap sayfada görünür olmak zorunda
İletişim	ContactPage + ContactPoint	NAP bilgisi footer ve grafta birebir aynı
Şube / bayi lokasyonu	LocalBusiness (her lokasyon ayrı @id)	parentOrganization ile merkeze bağlanır
Ürün / e-ticaret	Product + Offer	Fiyat, para birimi ve stok durumu gerçek zamanlı olmalı
Yasal metin	WebPage	Ek tip gerekmez; zorlama işaretleme yapılmaz

Tabloda olmayan bir tip aklınıza geliyorsa sorulacak soru şudur: bu tip, sayfada gerçekten var olan bir varlığı mı tarif ediyor? Cevap hayırsa eklenmez. Schema.org sekiz yüzden fazla tip içerir; kurumsal bir sitenin ihtiyacı genellikle on ile on beş tip arasındadır.

@id ve varlık grafı nedir, neden önemlidir?

Cevap

@id, bir varlığa verilen kalıcı kimliktir. Aynı kurum otuz altı sayfada tekrar tanımlanmak yerine tek bir @id ile bir kez tanımlanır, diğer sayfalar bu kimliğe referans verir. Böylece arama motoru otuz altı ayrı kurum değil, otuz altı sayfada geçen tek bir kurum görür.

Bu sayfanın kaynak kodunda yayımlanan grafın iskeleti. Kutular varlık, oklar ilişki.

@id için üç kural yeterlidir. Bir: kimlik mutlak bir adres olsun (https://www.bakibilisim.com/#organization). İki: protokol ve alt alan adı tüm sitede aynı olsun; http ile https veya www ile www olmayan sürümlerin karışması iki ayrı varlık üretir. Üç: kimlik bir daha değişmesin — kimlik değişimi, varlığın sıfırlanması demektir.

Varlık netliğinin ikinci ayağı sameAs alanıdır: kurumun doğrulanabilir dış profilleri buraya yazılır. Bu sitede yalnızca doğrulanmış Instagram adresi bulunduğu için sameAs tek girdilidir. Var olmayan profilleri listelemek, varlık netliğini artırmaz; azaltır.

Çok lokasyonlu ve çok dilli yapılarda schema nasıl kurulur?

Cevap

Her fiziksel lokasyon kendi sayfasını ve kendi @id değerini alır; hepsi parentOrganization ile merkeze bağlanır. Çok dilli yapıda graf her dilde tekrar yayımlanır: @id değerleri aynı kalır, inLanguage ve metin alanları değişir. Kimlik dile göre değişmez. On şubeyi tek düğüm altında toplamak, adresi sürekli değişen tek bir işletme tarif etmek anlamına gelir.

Bayi, şube ve mağaza ağlarında en sık görülen kurulum hatası, tüm lokasyonların tek bir LocalBusiness düğümü altında toplanmasıdır. Bu, arama motoruna "bir işletmem var ve adresi sürekli değişiyor" demekle aynı anlama gelir. Doğru kurulum, lokasyon başına bir sayfa ve lokasyon başına bir kimliktir; merkez kurum ise değişmeyen tek Organization düğümüdür.

Lokasyon sayfası: kendi LocalBusiness düğümü, kendi adresi, kendi telefonu, kendi @id değeri.
Merkez: tek Organization; lokasyonlar parentOrganization ile buraya bağlanır.
Çok dillilik: inLanguage her sayfada doğru; hreflang etiketleriyle graf birbirini doğrular.
Tutarlılık: ad, adres ve telefon; sayfa, graf ve işletme profillerinde birebir aynı yazılır.

Bu kurulumun operasyonel tarafını bayi ve şube ağı yönetimi ile mağaza zincirleri çözümü sayfalarında ayrıntılandırdık.

Yapılandırılmış veri doğrulaması nasıl yapılır?

Cevap

İki farklı araç, iki farklı soruyu yanıtlar. Schema Markup Validator sözlük geçerliliğini ölçer: tip ve özellik adları doğru mu? Google Rich Results Test ise arama motoru uygunluğunu ölçer: bu graf hangi zengin sonuç türüne aday? Kurumsal yayın öncesi ikisi de sıfır hata vermelidir.

Doğrulama araçları ve kapsamları
Araç	Ne doğrular	Ne doğrulamaz
Schema Markup Validator	Sözlük geçerliliği: tip, özellik adı, veri tipi, sözdizimi	İşaretlemenin sayfadaki içerikle eşleşip eşleşmediğini
Google Rich Results Test	Google'ın desteklediği zengin sonuç türlerine uygunluk	Zengin sonucun gerçekten gösterileceğini
Search Console raporları	Yayındaki sayfalarda zaman içindeki hata ve uyarı sayısı	Henüz taranmamış yeni sayfaları
İnsan denetimi	Sayfada görünen bilgi ile graf değerlerinin birebir eşleşmesi	Otomatikleştirilemez; her yayın öncesi tekrarlanır

Araçlara doğrudan erişim: Schema Markup Validator (dış bağlantı, yeni sekmede açılır) ve Google Rich Results Test (dış bağlantı, yeni sekmede açılır). Bu sayfanın adresini iki araca da girip çıktıyı kendiniz görebilirsiniz — kendi ölçümlerimizi kanıt sayfasında ölçüm tarihiyle yayımlıyoruz.

Yapılandırılmış veri yapay zekâ motorlarında işe yarar mı?

Cevap

Dolaylı olarak evet. Dil modelleri yanıt üretirken sayfayı ayrıştırır; yapılandırılmış veri bu ayrıştırmayı kolaylaştırır ve varlığın kim olduğunu belirsizlikten kurtarır. Ancak hiçbir arama motoru veya asistan "schema eklersen alıntılarım" demez. İşaretleme, alıntılanabilirliğin garantisi değil, ön koşuludur. Ölçülebilen şey işaretlemenin geçerliliğidir; alıntılanma ise gözlemlenen bir sonuçtur.

Doğrulanabilir olan şudur: aynı kurum adı, adres ve tanımı sayfada, grafta ve dış profillerde tutarlı olduğunda varlık belirsizliği azalır. Belirsizlik azaldıkça bir modelin sizi başka bir şirketle karıştırma olasılığı düşer. Bu, bir vaat değil, bir mekanizma açıklamasıdır.

Cevap ve üretken motor tarafının tamamı ayrı iki rehberde: AEO nedir ve GEO nedir. Yapılandırılmış veri bu iki çalışmanın da altyapı katmanıdır; tek başına ikisinin yerine geçmez.

Kaynağıyla birlikte üç doğrulanabilir gerçek

Cevap

Yapılandırılmış veri hakkında dolaşan iddiaların çoğu kaynaksızdır. Aşağıdaki üç veri, kamuya açık ve doğrulanabilir belgelere dayanır: sözlüğün kim tarafından kurulduğu, arama motorunun ne garanti ettiği ve kaç işaretleme biçiminin tanındığı. Her satırın kaynağı ve erişim tarihi yazılıdır; kaynağı olmayan bir sayıyı bu sitede yayımlamıyoruz.

2011

Schema.org sözlüğünün Google, Microsoft, Yahoo ve Yandex tarafından ortak bir sözlük olarak yayımlandığı yıl.

Kaynak: schema.org — Sık Sorulan Sorular · Erişim: 2026-07-29

0

Geçerli yapılandırılmış verinin verdiği zengin sonuç garantisi. Google, işaretlemenin görünümü garanti etmediğini dokümantasyonunda açıkça yazar.

Kaynak: Google Search Central — Yapılandırılmış veriye giriş · Erişim: 2026-07-29

3

Google'ın tanıdığı işaretleme biçimi sayısı: JSON-LD, Microdata ve RDFa. Google bu üçü arasından JSON-LD kullanılmasını önerir.

Kaynak: Google Search Central — Yapılandırılmış veri genel kuralları · Erişim: 2026-07-29

Kopyalanabilir JSON-LD örnekleri

Cevap

Aşağıdaki altı blok, kurumsal bir sitenin ihtiyaç duyduğu çekirdeği kapsar. Hepsi bu sitenin gerçek değerleriyle yazılmıştır; kendi kurumunuz için adres, telefon ve kimlik değerlerini değiştirmeniz yeterlidir. Blokların tamamı sayfanın başındaki tek betik etiketinin içine, tek bir @graph dizisi olarak yerleştirilir.

Betik etiketi nereye konur?

JSON-LD, belgenin head bölümüne tek bir betik etiketiyle yerleştirilir. Aşağıdaki iskelet, sonraki örneklerin nereye gireceğini gösterir.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    /* Organization */,
    /* ProfessionalService */,
    /* Person */,
    /* WebSite */,
    /* WebPage */,
    /* BreadcrumbList */
  ]
}
</script>

Organization — kurumsal kimlik

{
  "@type": "Organization",
  "@id": "https://www.bakibilisim.com/#organization",
  "name": "Baki Bilişim",
  "url": "https://www.bakibilisim.com/",
  "email": "bilgi@bakibilisim.com",
  "telephone": "+905078172717",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Karabaş Mah. Salim Dervişoğlu Cad., Ncity AVM, Kat 2",
    "addressLocality": "İzmit",
    "addressRegion": "Kocaeli",
    "addressCountry": "TR"
  },
  "founder": { "@id": "https://www.bakibilisim.com/#erdibaki" },
  "foundingDate": "2019",
  "sameAs": ["https://www.instagram.com/bakibilisim"],
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "Kocaeli" },
    { "@type": "Country", "name": "Türkiye" }
  ]
}

Dikkat: postalCode, openingHours ve geo alanları bu örnekte yok. Çünkü bu değerler doğrulanmadı. Doğrulanmamış alanı boş bırakmak da uydurmak da aynı sonucu doğurur: graf güvenilirliğini kaybeder.

LocalBusiness — fiziksel lokasyon

{
  "@type": "ProfessionalService",
  "@id": "https://www.bakibilisim.com/#localbusiness",
  "name": "Baki Bilişim",
  "url": "https://www.bakibilisim.com/",
  "telephone": "+905078172717",
  "email": "bilgi@bakibilisim.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Karabaş Mah. Salim Dervişoğlu Cad., Ncity AVM, Kat 2",
    "addressLocality": "İzmit",
    "addressRegion": "Kocaeli",
    "addressCountry": "TR"
  },
  "parentOrganization": { "@id": "https://www.bakibilisim.com/#organization" },
  "knowsLanguage": ["tr", "en"],
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "Kocaeli" },
    { "@type": "AdministrativeArea", "name": "İstanbul" }
  ]
}

ProfessionalService, LocalBusiness tipinin alt tipidir ve danışmanlık/ajans işi için daha kesindir. Şube ağınız varsa bu bloğu her lokasyon sayfasında tekrarlar, yalnızca @id, adres ve telefon alanlarını değiştirirsiniz.

Service — hizmet sayfası

{
  "@type": "Service",
  "@id": "https://www.bakibilisim.com/hizmetler/yapilandirilmis-veri-schema/#service",
  "name": "Yapılandırılmış veri (schema.org) kurulumu",
  "serviceType": "Yapılandırılmış veri mühendisliği",
  "description": "Kurumsal siteler için varlık grafı tasarımı, JSON-LD üretimi ve doğrulama.",
  "provider": { "@id": "https://www.bakibilisim.com/#organization" },
  "areaServed": [
    { "@type": "AdministrativeArea", "name": "Kocaeli" },
    { "@type": "Country", "name": "Türkiye" }
  ],
  "availableChannel": {
    "@type": "ServiceChannel",
    "serviceUrl": "https://www.bakibilisim.com/iletisim/"
  }
}

Bu blokta offers alanı bilinçli olarak yok: yayımlanmış bir fiyat listesi olmadan fiyat işaretlemesi yapılmaz. Fiyatı yayımlıyorsanız Offer düğümünü ekleyin ve değeri sayfadaki fiyatla birebir eşitleyin.

FAQPage — soru ve cevap

{
  "@type": "FAQPage",
  "@id": "https://www.bakibilisim.com/bilgi-merkezi/schema-org-rehberi/#faq",
  "inLanguage": "tr-TR",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Yapılandırılmış veri sıralamamı yükseltir mi?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Doğrudan bir sıralama faktörü değildir. Sayfanın konusunu ve
                 varlıklarını tahmine bırakmadan bildirir; etkisi dolaylıdır."
      }
    }
  ]
}

Tek şart: buradaki soru ve cevabın sayfada görünür olması. Bu sayfanın alt bölümündeki altı soru, yukarıdaki blokla birebir aynı metni taşır.

{
  "@type": "BreadcrumbList",
  "@id": "https://www.bakibilisim.com/bilgi-merkezi/schema-org-rehberi/#breadcrumb",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Ana Sayfa",
      "item": "https://www.bakibilisim.com/" },
    { "@type": "ListItem", "position": 2, "name": "Bilgi Merkezi",
      "item": "https://www.bakibilisim.com/bilgi-merkezi/" },
    { "@type": "ListItem", "position": 3, "name": "Schema.org Rehberi",
      "item": "https://www.bakibilisim.com/bilgi-merkezi/schema-org-rehberi/" }
  ]
}

Person — sorumlu kişi

{
  "@type": "Person",
  "@id": "https://www.bakibilisim.com/#erdibaki",
  "name": "Erdi Baki",
  "jobTitle": "Kurucu",
  "url": "https://www.bakibilisim.com/hakkimizda/",
  "worksFor": { "@id": "https://www.bakibilisim.com/#organization" },
  "knowsAbout": [
    "Schema.org yapılandırılmış veri",
    "Answer Engine Optimization",
    "Core Web Vitals"
  ]
}

Rehber ve makale sayfalarında Person düğümü yazar alanına bağlanır. Bu sayfanın TechArticle düğümünde author değeri, yukarıdaki kimliğe referans verir — yazar adı ikinci kez yazılmaz, kimlikle bağlanır.

Sıfırdan bir varlık grafı nasıl kurulur?

Cevap

Yedi adım: varlık envanteri, kalıcı kimlik şeması, kurumsal çekirdek, sayfa tipi düğümleri, kimlik referanslarıyla bağlama, görünen içerikle eşleştirme, doğrulama ve izleme. Sıra önemlidir; kimlik şeması belirlenmeden yazılan graf, ilk yeniden yapılandırmada dağılır. Her adımın bir çıktısı ve bir kontrol sorusu vardır, kontrolü geçmeyen adım bir sonrakine devredilmez.

01

Varlık envanterini çıkarın

Sitede gerçekten var olan varlıkları listeleyin: kurum, sorumlu kişi, lokasyonlar, hizmetler, ürünler, içerikler. Bu liste grafın sınırıdır — envantere girmeyen hiçbir şey işaretlenmez.

Çıktı
Varlık listesi ve her varlığın hangi sayfada yaşadığı

Kontrol
Her varlığın tek bir kanonik sayfası var mı?
02

Kalıcı bir kimlik şeması belirleyin

Her varlığa değişmeyecek bir @id verin. Protokol, alt alan adı ve sondaki eğik çizgi tüm sitede tek biçim olmalıdır. Kimlik sözdizimini bir kez kararlaştırıp yazıya dökün.

Çıktı
Kimlik sözleşmesi: https://www.alanadi.com/#organization deseni

Kontrol
Tüm kimliklerde protokol ve alt alan adı aynı mı?
03

Kurumsal çekirdeği yazın

Organization, LocalBusiness, Person ve WebSite düğümleri bir kez yazılır ve her sayfada birebir aynı değerlerle yayımlanır. Doğrulanmamış alan yazılmaz.

Çıktı
Tüm sayfalarda tekrarlanan sabit çekirdek graf

Kontrol
Ad, adres, telefon; footer ve grafta birebir aynı mı?
04

Sayfa tipi düğümünü ekleyin

Her sayfa kendi tipini taşır: WebPage, Service, TechArticle, FAQPage, ContactPage veya Product. Ana sayfa dışında her sayfada BreadcrumbList bulunur.

Çıktı
Sayfa tipi haritası: hangi şablon hangi düğümü basar

Kontrol
Zorlama tip var mı? Karşılığı olmayan tip eklenmemeli
05

Düğümleri kimlik referanslarıyla bağlayın

Aynı varlığı yeniden yazmak yerine @id ile referans verin. Sayfa başına tek bir betik etiketi ve tek bir @graph dizisi kullanın.

Çıktı
Tek betik, tek graf, referanslarla bağlı düğümler

Kontrol
Sayfada çelişen ikinci bir graf kaldı mı?
06

İşaretlemeyi görünen içerikle eşleştirin

İşaretlenen her alanın karşılığı sayfada görünür olmalıdır. Sayfada bulunmayan telefon, fiyat, puan veya yorum işaretlenmez. Bu adım otomatikleştirilemez; gözle denetlenir.

Çıktı
Alan-içerik eşleşme tablosu

Kontrol
Grafta olup sayfada olmayan tek bir değer var mı?
07

Doğrulayın ve yayın sonrası izleyin

Schema Markup Validator ile sözlük geçerliliğini, Rich Results Test ile arama motoru uygunluğunu ölçün. Yayından sonra Search Console'daki yapılandırılmış veri raporlarını izleyin.

Çıktı
Ölçüm tarihli doğrulama çıktısı

Kontrol
Her iki araçta da hata sayısı sıfır mı?

Sık yapılan sekiz schema hatası nedir?

Cevap

Denetimlerde en sık gördüğümüz sekiz hata şunlardır: görünmeyen içeriği işaretlemek, boş alan bırakmak, kimlik tutarsızlığı, çelişen çift graf, uydurulmuş yorum ve puan, yanlış tip seçimi, çok lokasyonlu yapıyı tek düğüme sıkıştırmak ve grafı taşınmadan sonra güncellememek. Hepsi birkaç dakikalık bir denetimde görünür; düzeltmeleri de tek tek sayfalarda değil, şablonda yapılır.

Görünmeyen içeriği işaretlemek. Sayfada olmayan bir soruyu FAQPage içine yazmak. Düzeltme: önce içeriği sayfaya ekleyin, sonra işaretleyin.
Boş alan bırakmak. telephone: "" veya addressLocality: "" gibi boş değerler. Düzeltme: değer yoksa alan tamamen çıkarılır; boş dize bir değer değildir.
Kimlik tutarsızlığı. Bir sayfada http://, diğerinde https://www ile başlayan @id değerleri. Düzeltme: tek kanonik biçim belirleyin ve tüm şablonlarda uygulayın.
Çelişen çift graf. Tema, eklenti ve elle eklenen kodun aynı anda graf basması. Düzeltme: kaynakları tek tek kapatın, tek üretici bırakın.
Uydurulmuş yorum ve puan. Gerçek bir değerlendirme sistemi olmadan AggregateRating yazmak. Düzeltme: gerçek yorum yoksa bu düğüm hiç yazılmaz — yaptırım riski yüksektir.
Yanlış tip seçimi. Bir hizmet sayfasını Product olarak işaretlemek. Düzeltme: tip, sayfadaki varlığın gerçek doğasına göre seçilir.
Çok lokasyonlu yapıyı tek düğüme sıkıştırmak. On şubeyi tek LocalBusiness altında toplamak. Düzeltme: lokasyon başına sayfa ve kimlik.
Taşıma sonrası grafı güncellememek. Alan adı veya adres değişince eski değerlerin grafta kalması. Düzeltme: taşıma kontrol listesine graf denetimini de ekleyin.

Bu sekiz hatanın yedisi teknik değil, süreç kaynaklıdır: kimsenin sahibi olmadığı bir alan kimsenin güncellemediği bir alana dönüşür. Sorumluluğun kimde olduğunu neden Baki Bilişim sayfasında satır satır yazdık.

Yayına almadan önce neleri kontrol etmelisiniz?

Cevap

On dört maddelik bir kontrol yeterlidir. Liste iki soruyu yanıtlar: graf teknik olarak geçerli mi ve grafta yazan her şey sayfada gerçekten var mı? İkinci soru, otomatik araçların yanıtlayamadığı ve denetimlerde en çok hata çıkan sorudur; onu yanıtlamak için grafı okumak yetmez, sayfayı da açmak gerekir.

Sayfada tek bir JSON-LD betiği ve tek bir @graph dizisi var.
Tüm @id değerleri aynı protokol ve alt alan adıyla yazılmış.
Organization düğümü sitedeki her sayfada birebir aynı.
LocalBusiness içinde telephone ve addressLocality dolu.
Doğrulanmamış alan (posta kodu, koordinat, çalışma saati, fiyat) hiç yazılmamış.
Ana sayfa dışındaki her sayfada BreadcrumbList var ve görünen konum iziyle eşleşiyor.
Her sayfanın kendi tipi (Service, TechArticle, ContactPage) tanımlı.
FAQPage içindeki her soru ve cevap sayfada görünür.
dateModified değeri sayfadaki görünür güncelleme tarihiyle aynı.
inLanguage değeri sayfanın diliyle ve hreflang etiketleriyle uyumlu.
sameAs listesinde yalnızca doğrulanmış profiller var.
Gerçek bir değerlendirme sistemi yoksa AggregateRating ve Review yok.
Schema Markup Validator çıktısında hata sayısı sıfır.
Rich Results Test çıktısında hata sayısı sıfır; uyarılar gözden geçirilmiş.

Bu listeyi kendi sitenizde uygulamak isterseniz, ücretsiz dijital varlık denetimi beş eksenden biri olarak yapılandırılmış veri geçerliliğini de ölçer.

Bu rehberdeki terimler nerede tanımlıdır?

Cevap

Rehberde geçen her teknik terimin kısa tanımı sözlükte, kendi bağlantı noktasında bulunur. Aşağıdaki altı terim bu sayfayı okurken en çok ihtiyaç duyulanlardır; tamamı için dijital görünürlük sözlüğüne bakabilirsiniz. Tanımlar kısa ve tek başına anlamlı tutulur; her biri kendi bağlantı noktasından doğrudan alıntılanabilir.

Sık sorulan sorular

Cevap

Aşağıdaki altı soru, yapılandırılmış veri konusunda kurumsal ekiplerden en sık gelen sorulardır. Cevaplar sayfada görünür biçimde ve aynı metinle FAQPage şemasında da yayımlanır — bu rehberin anlattığı kuralın kendi üzerimizdeki uygulaması budur. Her cevap tek başına anlamlıdır ve bağlamından koparıldığında da doğru kalır.

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

Yapılandırılmış veri doğrudan bir sıralama faktörü değildir; Google bunu belgelerinde açıkça yazar. Yaptığı iş, sayfanın konusunu ve varlıklarını tahmine bırakmadan bildirmektir. Dolaylı etkisi şuradan gelir: sayfa doğru sorguyla eşleşir, zengin sonuç bileşenlerine aday olur ve cevap motorları içeriği daha güvenle alıntılar.

Schema eklemek zengin sonuç garantisi verir mi?

Hayır. Google, geçerli yapılandırılmış verinin zengin sonuç görünümünü garanti etmediğini dokümantasyonunda belirtir. İşaretleme uygunluk şartıdır, karar değildir. Zengin sonuç gösterimi arama motorunun sorgu, cihaz ve kalite değerlendirmesine bağlıdır. Bu nedenle sözleşmelerimizde zengin sonuç taahhüdü değil, sıfır doğrulama hatası taahhüdü yer alır.

WordPress eklentisiyle eklenen schema yeterli mi?

Çoğu kurumsal sitede yeterli değildir. Eklentiler tek tip bir çekirdek graf üretir; hizmet, çok lokasyonlu şube, bayi ağı, çok dilli yapı ve sektöre özgü ilişkiler dışarıda kalır. Ayrıca birden fazla eklenti aynı anda graf basarsa çelişen düğümler oluşur. Eklenti başlangıç noktasıdır, varlık modelinin yerine geçmez.

Sayfada görünmeyen içeriği işaretleyebilir miyim?

Hayır. Google'ın yapılandırılmış veri genel kuralları, işaretlemenin sayfada kullanıcıya görünen içeriği temsil etmesini şart koşar. Görünmeyen içeriği işaretlemek yalnızca zengin sonuç uygunluğunu kaybettirmekle kalmaz, manuel işlem riski de doğurur. Kural basittir: sayfada yoksa grafta da olmaz.

Bir sayfada kaç tane JSON-LD bloğu olmalı?

Teknik olarak birden fazla blok geçerlidir, ancak kurumsal sitelerde tek bir blok ve tek bir @graph dizisi önerilir. Tek blok, aynı varlığın iki farklı yerde farklı değerlerle tanımlanmasını engeller ve hata ayıklamayı basitleştirir. Bu sitede de her sayfada tek bir JSON-LD bloğu yayımlanır.

Schema.org güncellendiğinde grafımı değiştirmem gerekir mi?

Genellikle hayır. Schema.org geriye dönük uyumluluğu korur; yeni sürümler çoğunlukla tip ve özellik ekler. Değişiklik gerektiren durum, kullandığınız bir özelliğin kullanımdan kaldırılması veya arama motorunun bir zengin sonuç türü için gereksinimlerini değiştirmesidir. Bu nedenle grafı yılda bir kez, ölçüm tarihiyle birlikte gözden geçiririz.

Bu rehberi kim yazdı?

Erdi Baki

Kurucu · Baki Bilişim

Bu rehberi Baki Bilişim kurucusu Erdi Baki yazdı. Kurumsal web inşası ile arama görünürlüğü mühendisliğini tek sorumluluk altında birleştiren bir ekip yürütüyor; yapılandırılmış veri, AEO ve Core Web Vitals çalışmalarının teknik sorumlusu.

Bu sayfadaki her sayının kaynağı ve erişim tarihi yazılıdır. Kendi sitemizin ölçülmüş skorlarını kanıt sayfasında yayımlıyoruz; ekip ve sorumluluk yapısı hakkımızda sayfasında.

Bu rehberden kaynak göstererek alıntı yapabilirsiniz. Alıntı koşulları: kullanım koşulları.

Schema.org ve JSON-LD: kurumsal siteler için rehber

Schema.org yapılandırılmış veri nedir?

JSON-LD, Microdata ve RDFa: hangisini seçmelisiniz?

Kurumsal bir site hangi schema tiplerini kullanmalı?

@id ve varlık grafı nedir, neden önemlidir?

Çok lokasyonlu ve çok dilli yapılarda schema nasıl kurulur?

Yapılandırılmış veri doğrulaması nasıl yapılır?

Yapılandırılmış veri yapay zekâ motorlarında işe yarar mı?

Kaynağıyla birlikte üç doğrulanabilir gerçek

Kopyalanabilir JSON-LD örnekleri

Betik etiketi nereye konur?

Organization — kurumsal kimlik

LocalBusiness — fiziksel lokasyon

Service — hizmet sayfası

FAQPage — soru ve cevap

BreadcrumbList — konum izi

Person — sorumlu kişi

Sıfırdan bir varlık grafı nasıl kurulur?

Varlık envanterini çıkarın

Kalıcı bir kimlik şeması belirleyin

Kurumsal çekirdeği yazın

Sayfa tipi düğümünü ekleyin

Düğümleri kimlik referanslarıyla bağlayın

İşaretlemeyi görünen içerikle eşleştirin

Doğrulayın ve yayın sonrası izleyin

Sık yapılan sekiz schema hatası nedir?

Yayına almadan önce neleri kontrol etmelisiniz?

Bu rehberdeki terimler nerede tanımlıdır?

Sık sorulan sorular

Bu rehberi kim yazdı?

Mevcut grafınızın gerçekten geçerli olup olmadığını 5 iş günü içinde görün.