# Schema.org İşaretlemesi ile Yapay Zekâ Görünürlüğü Rehberi

> Schema.org ve JSON-LD işaretlemesinin yapay zekâ görünürlüğüne etkisi: kritik şema tipleri, LocalBusiness örneği, @id ile entity grafiği ve doğrulama araçları.

Kaynak: https://promptfront.com.tr/rehber/schema-org-ile-yapay-zeka-gorunurlugu
Yayıncı: PromptFront (https://promptfront.com.tr)
Tarih: 2026-08-01
Yazar: PromptFront

---

Schema.org işaretlemesi, web sayfanızdaki bilgileri makinelerin doğrudan anlayabileceği yapılandırılmış veriye dönüştüren ortak bir sözlüktür. JSON-LD formatında eklenen bu işaretleme, ChatGPT, Gemini, Claude ve Perplexity gibi sistemlerin işletmenizi doğru tanımasını ve güvenle önermesini kolaylaştırır. 2026 itibarıyla schema işaretlemesi, yapay zekâ görünürlüğü çalışmasının en somut ve en hızlı uygulanabilir teknik adımıdır.

## JSON-LD nedir?

**JSON-LD (JavaScript Object Notation for Linked Data)**, yapılandırılmış veriyi sayfanın HTML koduna bir `<script type="application/ld+json">` bloğu içinde ekleyen formattır. Görünür içeriğe dokunmaz; sayfanın tasarımını, metnini veya hızını değiştirmez. Yalnızca makinelere yönelik bir "kimlik kartı" olarak çalışır ve [Schema.org](https://schema.org) sözlüğündeki tipleri kullanarak "bu sayfa bir işletmeyi anlatıyor, adı şu, adresi şu, hizmetleri şunlar" bilgisini net biçimde bildirir.

Schema.org sözlüğünü uygulamanın üç yöntemi vardır: Microdata, RDFa ve JSON-LD. Microdata ve RDFa işaretlemeyi HTML etiketlerinin içine dağıtırken, JSON-LD tüm veriyi tek bir blokta toplar. Bu yüzden hem Google hem de yapay zekâ tarafında fiilî standart JSON-LD'dir: bakımı kolaydır, şablon sistemlerine tek parça hâlinde eklenir ve içerik güncellendiğinde ayrıştırma hatası üretme riski düşüktür.

Kritik nokta şudur: JSON-LD, sayfada görünen bilgiyle **tutarlı** olmalıdır. Sayfada yazmayan bir hizmeti veya adresi işaretlemeye eklemek, hem arama motoru yönergelerine aykırıdır hem de veri kaynakları arasında çelişki yaratarak güven puanınızı düşürür. Bu tutarlılık ilkesi, [NAP tutarlılığı](/sozluk/nap-tutarliligi) kavramının sayfa içi karşılığıdır.

## Schema işaretlemesi LLM görünürlüğü için neden önemli?

Büyük dil modelleri, bir işletme hakkında konuşurken web'den topladıkları sinyalleri bir [entity](/sozluk/entity) (varlık) etrafında birleştirir. Serbest metin bu sinyallerin en belirsiz hâlidir: "Kadıköy'deki kliniğimizde yılların tecrübesiyle hizmet veriyoruz" cümlesinden işletme türünü, tam adresi ve hizmet listesini çıkarmak modele yorum yükü bindirir. Schema işaretlemesi ise aynı bilgiyi alan-değer çiftleri hâlinde, yoruma yer bırakmadan sunar.

Bu netliğin üç somut sonucu vardır:

1. **Doğru sınıflandırma:** Model, sitenizin bir diş kliniği mi, hukuk bürosu mu yoksa ajans mı olduğunu tahmin etmek yerine `@type` alanından okur. Yanlış kategoride anılma ve [halüsinasyon](/sozluk/halusinasyon) riski azalır.
2. **Güvenli alıntılama:** Perplexity gibi kaynak gösteren motorlar ve [RAG](/sozluk/rag) mimarisiyle web'e erişen asistanlar, yapılandırılmış alanlardan çektikleri telefon, adres ve çalışma saati gibi bilgileri daha yüksek güvenle cevaba taşır.
3. **Entity pekiştirmesi:** Schema verisi; Google Business Profile, dizin kayıtları ve sosyal profillerle aynı kimliği tekrar ederek işletmenin bilgi grafiğindeki varlığını güçlendirir. Bu da [GEO](/rehber/geo-nedir) çalışmasının veri katmanını oluşturur.

Şunu da netleştirmek gerekir: hiçbir platform "schema ekleyene öncelik veririz" diye bir taahhüt yayınlamaz. Ancak modellerin eğitim ve erişim hattındaki veri kaynakları — arama indeksleri, bilgi grafikleri, tarayıcı botları — yapılandırılmış veriyi on yılı aşkın süredir tüketiyor. Schema işaretlemesi bu hatta beslenen en temiz sinyaldir; etkisi dolaylı ama kalıcıdır.

## Hangi şema tipleri yapay zekâ görünürlüğü için kritik?

Schema.org sözlüğünde yüzlerce tip vardır; hepsini kullanmak gerekmez. Aşağıdaki sekiz tip, bir işletme sitesinin yapay zekâ görünürlüğü için gereken kapsamın büyük bölümünü karşılar:

| Şema tipi | Ne bildirir? | Ne zaman kullanılır? |
|---|---|---|
| **Organization** | Marka adı, logo, kurumsal kimlik, sosyal profiller | Her sitede; genellikle ana sayfada, sitenin sahibini tanımlamak için |
| **LocalBusiness** | Fiziksel konum, adres, telefon, çalışma saatleri | Ofisi, kliniği veya mağazası olan yerel işletmelerde; Organization yerine veya onunla bağlantılı |
| **Service** | Sunulan hizmetin adı, kapsamı, hizmet bölgesi | Her hizmet detay sayfasında (ör. implant tedavisi, boşanma davası danışmanlığı) |
| **FAQPage** | Soru-cevap çiftleri | Gerçek SSS bölümü içeren sayfalarda; cevap motorlarının en kolay alıntıladığı yapı |
| **Article** | Başlık, yazar, yayın ve güncelleme tarihi | Blog yazıları ve rehber içeriklerde; tazelik sinyali taşır |
| **HowTo** | Adım adım süreç tanımı | Sıralı talimat içeren rehberlerde (kurulum, başvuru, hazırlık süreçleri) |
| **BreadcrumbList** | Sayfanın site hiyerarşisindeki yeri | Tüm iç sayfalarda; modelin site yapısını ve konu ilişkilerini kavramasına yardım eder |
| **DefinedTerm** | Bir terimin tanımı ve ait olduğu sözlük | Sözlük/terimler bölümlerinde; markanızı kavram tanımlarıyla ilişkilendirir |

Seçim kuralı basittir: sayfa neyi anlatıyorsa onu işaretleyin. Hizmet sayfasına FAQPage, blog yazısına LocalBusiness eklemek gibi uyumsuz eşleşmeler değer üretmez. Yerel işletmeler için tip seçimi ve öncelik sırası konusunda [yerel işletmeler için GEO rehberi](/rehber/yerel-isletmeler-icin-geo-rehberi) daha ayrıntılı bir yol haritası sunar.

## Basit bir LocalBusiness JSON-LD örneği nasıl görünür?

Aşağıdaki blok, İstanbul'daki hayali bir kliniğin ana sayfasına eklenebilecek asgari ama sağlıklı bir LocalBusiness işaretlemesidir:

```json
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://www.ornekklinik.com/#isletme",
  "name": "Örnek Diş Kliniği",
  "url": "https://www.ornekklinik.com",
  "telephone": "+90 212 000 00 00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Örnek Caddesi No: 12",
    "addressLocality": "Kadıköy",
    "addressRegion": "İstanbul",
    "postalCode": "34710",
    "addressCountry": "TR"
  },
  "openingHours": "Mo-Sa 09:00-19:00",
  "sameAs": [
    "https://www.instagram.com/ornekklinik",
    "https://www.linkedin.com/company/ornekklinik"
  ]
}
```

Bu örnekte üç ayrıntı özellikle önemlidir. Birincisi, `sameAs` alanı işletmenin diğer platformlardaki profillerini aynı kimliğe bağlar; entity doğrulamasının en ucuz yoludur. İkincisi, telefon ve adres bilgisi sitenin görünür bölümleriyle ve Google Business Profile kaydıyla birebir aynı olmalıdır. Üçüncüsü, `@id` alanı — bir sonraki bölümün konusu — bu işletme tanımına kalıcı bir referans adresi verir. Mümkünse `LocalBusiness` yerine `Dentist`, `LegalService` gibi daha spesifik alt tipleri tercih edin; sözlükteki tip hiyerarşisini [schema.org](https://schema.org) üzerinde gezinerek inceleyebilirsiniz.

## @id ile entity grafiği nasıl kurulur?

**@id**, bir JSON-LD düğümüne verilen benzersiz ve kalıcı tanımlayıcıdır; farklı sayfalardaki işaretlemelerin aynı varlıktan söz ettiğini makinelere kanıtlar. `https://www.ornekklinik.com/#isletme` gibi bir @id tanımladığınızda, sitenin her sayfasında işletmeyi yeniden tarif etmek yerine bu adrese referans verirsiniz. Böylece dağınık işaretleme parçaları tek bir **entity grafiğine** dönüşür.

Pratikte grafiği şöyle kurarsınız: ana sayfadaki LocalBusiness bloğu `"@id": "https://www.ornekklinik.com/#isletme"` ile kimliğini ilan eder. Hizmet sayfasındaki Service bloğu `"provider": { "@id": "https://www.ornekklinik.com/#isletme" }` diyerek hizmeti aynı işletmeye bağlar. Blog yazısındaki Article bloğu `publisher` alanında yine aynı @id'yi gösterir. Sonuç, modelin gözünde tutarlı bir tablodur: tek işletme, ona bağlı hizmetler, onun yayımladığı içerikler.

@id kullanmadan her sayfada işletmeyi baştan tanımlarsanız, küçük farklılıklar (bir sayfada "Örnek Klinik", diğerinde "Örnek Diş Kliniği") ayrı varlıklar gibi algılanabilir ve sinyal bölünür. @id disiplini bu bölünmeyi engeller; işletme kimliğini [llms.txt](/rehber/llms-txt-nedir-nasil-hazirlanir) dosyası ve tutarlı dizin kayıtlarıyla birleştirdiğinizde, yapay zekâ sistemlerinin okuyabileceği bütünlüklü bir kimlik katmanı ortaya çıkar.

## Schema işaretlemesi nasıl doğrulanır?

Doğrulama, işaretlemeyi yayına almadan önceki zorunlu adımdır; sözdizimi hatalı bir JSON-LD bloğu hiç yokmuş gibi yok sayılır. Süreç şu sırayla ilerler:

1. **Schema Markup Validator ile sözdizimi kontrolü:** Schema.org'un resmî doğrulayıcısı ([validator.schema.org](https://validator.schema.org)) sayfa URL'sini veya kod parçasını tarar; eksik parantez, yanlış alan adı ve tip uyumsuzluklarını listeler. Her tip için buradan geçerlilik kontrolü yapın.
2. **Google Rich Results Test ile uygunluk kontrolü:** Google'ın test aracı ([search.google.com/test/rich-results](https://search.google.com/test/rich-results)), işaretlemenin zengin sonuç üretmeye uygun olup olmadığını gösterir. Zengin sonuç kazanmak birincil hedef olmasa da bu test, Google'ın veriyi nasıl yorumladığını görmenin en hızlı yoludur; ayrıntılı yapılandırılmış veri yönergeleri için [Google Search dokümantasyonuna](https://developers.google.com/search) bakın.
3. **Görünür içerikle karşılaştırma:** İşaretlemedeki her değerin sayfada gerçekten yer aldığını elle doğrulayın. Araçlar sözdizimini denetler; tutarlılığı denetlemek size kalır.
4. **Yayın sonrası izleme:** Site güncellemeleri işaretlemeyi sessizce bozabilir. Şablon değişikliklerinden sonra doğrulamayı tekrarlayın ve etkisini [yapay zekâ görünürlüğü ölçümü](/rehber/yapay-zeka-gorunurlugu-nasil-olculur) ile düzenli takip edin.

Ağustos 2026 itibarıyla bu iki araç da ücretsizdir ve kayıt gerektirmez. Teknik ekibi olmayan işletmeler için schema kurulumu, PromptFront'un [GEO optimizasyonu](/hizmetler/geo-optimizasyonu) hizmeti kapsamında entity grafiği tasarımıyla birlikte 7 günlük teslim sürecinin standart adımlarından biridir.