Yapay Zeka ve Arama

Yapılandırılmış Veri: Gerçekten İşe Yarayan Schema Türleri

Hangi Schema.org türleri zengin sonuç kazandırır, bağımsız bloklar yerine bilgi grafiği nasıl kurulur ve ceza getiren yorum işaretlemeleri.

Yapılandırılmış verinin (Schema / Structured Data) iki temel görevi vardır ve ikincisi sessizce birincisinden çok daha önemli hale gelmiştir:

Birinci görev: Arama sonuçlarında zengin sonuçlar (rich snippets) kazanmak — yıldız puanları, SSS akordeonları, içerik haritaları (breadcrumbs), ürün fiyatları. Bunlar arama sonuçlarında daha fazla yer kaplar ve tıklama oranını artırır.

İkinci görev: Yapay zeka modellerine işletmeniz hakkında kesin ve tartışmasız veriler sunmak. Bir model sitenizdeki pazarlama metinlerini okurken ne yaptığınızı ve nerede faaliyet gösterdiğinizi tahmin etmek zorundadır. Ancak Organization düğümünüzü okuyan bir modelin hiçbir şeyi tahmin etmesine gerek kalmaz. Bir yapay zeka arama motoru şirketiniz hakkında güvenle bir bilgi veriyorsa, bu özgüven genellikle doğrudan yapılandırılmış verilerinizden gelir.

Birinci görev iyi bilinir. İkinci görev ise üç yıl önceki "yeterli" kurulumların neden artık yetersiz kaldığının asıl sebebidir.

JSON-LD formatı kullanın

Üç farklı format mevcuttur (Microdata, RDFa, JSON-LD). Her zaman JSON-LD kullanın.

Google bunu açıkça önerir; HTML etiketlerinin arasına dağıtılmak yerine tek bir <script> etiketi içinde yaşar ve Microdata'yı sessizce bozan şablon güncellemelerinden etkilenmez. Sıfırdan bir şey kuruyorsanız başka hiçbir format kullanmayın.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Acme İmalat",
  "url": "https://example.com/"
}
</script>

Bilgi grafiğini birbirine bağlayın (@graph)

Çalışan bir kurulum ile sadece doğrulanabilen bir kurulum arasındaki fark buradadır.

Çoğu site birbirinden bağımsız izole bloklar yayınlar: bir köşede Organization, başka bir yerde Service, başka bir sayfada BlogPosting ve hiçbiri birbirine referans vermez. Tek tek bakıldığında hepsi geçerlidir ama birlikteyken aralarındaki ilişki hakkında hiçbir şey söylemezler.

Bunları birbirine bağlamak için @id kullanın:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Acme İmalat",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Service",
      "@id": "https://example.com/hizmetler/cnc/#service",
      "name": "CNC Frezeleme",
      "provider": { "@id": "https://example.com/#organization" },
      "areaServed": { "@type": "Place", "name": "Türkiye" }
    }
  ]
}

Artık bu hizmet belirli bir hizmet bölgesine sahip belirli bir kuruma doğrudan bağlanmıştır. Bir yapay zeka motoru sadece bu koda bakarak "CNC frezeleme hizmetini kim verir ve hangi bölgede çalışır?" sorusunu tereddütsüz yanıtlayabilir.

@graph sarmalayıcısı tüm seti tek bir script etiketinde yayınlamanızı sağlar; bu hem daha temizdir hem de sonraki geliştiriciler için ilişkileri çok net kılar.

Sahip olmaya değer temel Schema türleri

Tipik bir kurumsal site için değer sırasına göre:

Organization (veya fiziksel bir bölgeye hizmet veriyorsanız LocalBusiness, ajans ve danışmanlıklar için ProfessionalService). Bu sizin temel çapınızdır. name, url, logo, address, telephone, email, sosyal medya profillerinizi gösteren sameAs ve areaServed bilgilerini mutlaka ekleyin.

WebSite — Ana sayfada bir kez yayınlanır. SearchAction ile birlikte potentialAction eklemek Google'da site içi arama kutusu kazandırabilir.

BreadcrumbList — Ana sayfa dışındaki her sayfada bulunmalıdır. Arama sonuçlarındaki ham URL yerine okunabilir bir kategori yolu gösterir. Kazanması en kolay zengin sonuçtur ve en çok atlananlardandır.

Service veya Product — İlgili hizmet ve ürün sayfalarında. Gerçek price ve offers içeren bir Product şeması, arama sonuçlarında doğrudan fiyat görünmesini sağlar.

FAQPage — Soruları yanıtladığınız her yerde. Yapay zeka için olağanüstü değerlidir; çünkü tam olarak yapay zekanın veri çekme formatına uygun soru-cevap çiftleridir.

BlogPosting veya Article — Blog ve makale içeriklerinde. headline, datePublished, dateModified, author, image ve wordCount alanlarını içermelidir.

Sitelere ceza getiren kritik hata

Kendi topladığınız yorumları kendi Organization şemanıza aggregateRating olarak eklemeyin.

Google'ın yapılandırılmış veri kuralları çok nettir: Bir kurumun kendisi hakkında topladığı yorumları doğrudan şirket şemasına yıldız olarak eklemesi zengin sonuçlar için yasaktır. Bu manuel ceza (manual action) sebebidir, gri bir alan değildir.

Puanlamalar Product, LocalBusiness veya spesifik hizmetlere aittir ve sayfada gerçek kullanıcı yorumlarıyla birlikte görünür olmalıdır. Kodda olan ama sayfada bir insanın göremediği yıldız puanları doğrudan kural ihlalidir.

Kolayca gözden kaçan kurallar

İşaretlenen içerik sayfada görünür olmak zorundadır. Sayfada basılmayan bir SSS'i veya sadece sepete ekleyince çıkan bir fiyatı Schema'ya yazmak ihlaldir.

Zorunlu alanlar gerçekten zorunludur. Google'ın dokümantasyonu her tür için zorunlu alanları listeler. Bir tanesi bile eksikse Schema geçerli olsa dahi zengin sonuç çıkmaz.

Tarihler ISO 8601 formatında olmalıdır. 2026-09-08 veya 2026-09-08T10:00:00+03:00. "8 Eylül 2026" ayrıştırılamaz.

sameAs bizzat kontrol ettiğiniz profilleri göstermelidir — gerçek LinkedIn, gerçek X hesabınız. Başka bir şirketin Wikipedia sayfasına link vermek hiç eklememekten daha kötüdür.

Yapay zeka arama motorları için özel alanlar

Modeller için geleneksel aramadan daha kritik olan birkaç özellik:

  • Organization üzerinde slogan değil, somut bir cümleyle yazılmış description. Modeller burayı doğrudan alıntılar.
  • knowsAbout — Kurumunuzun uzmanı olduğu konuların dizisi.
  • areaServed — Hizmet bölgeleriniz.
  • availableLanguage — Hizmet verdiğiniz diller.

Çok dilli web siteleri

Her dil sürümünün çevrilmiş değerlerle kendi yapılandırılmış verisine ve doğru inLanguage etiketine ihtiyacı vardır. @id değerleri de dile göre ayrışmalıdır (https://example.com/tr/hizmetler/#service gibi); aksi takdirde Türkçe ve İngilizce hizmetlerin aynı düğüm olduğunu iddia etmiş olursunuz ki bu da hreflang mantığınızla çelişir.

Kontrol listesi ve uygulama sırası

  1. Tüm sitede birbirine bağlı bir Organization + WebSite grafiği yayınlayın.
  2. Ana sayfa haricindeki tüm sayfalara BreadcrumbList ekleyin.
  3. İlgili sayfalara @id ile kuruma bağlı Service veya Product şemaları ekleyin.
  4. Gerçek soruları yanıtladığınız yerlere FAQPage ekleyin.
  5. Blog yazılarına BlogPosting ekleyin.
  6. Yılda bir kez denetleyin; çünkü yapılandırılmış veriler sayfalardan çok daha hızlı eskir ve güncelliğini yitirmiş bir Schema hiç olmamasından daha kötüdür.

Herhangi bir sayfanın Schema yapısını ve bağlılıklarını Ücretsiz Yapılandırılmış Veri Kontrol Aracımız ile anında test edebilirsiniz.

Okumaya devam et

Neyi büyütmek istediğinizi anlatın.

Tek ekip. Üç ofis. 26 dil. Sorununuzu iletin, ezberlenmiş satış cümleleri değil, kıdemli bir uzmandan net yanıt alın.

Bir iş günü içinde kendi dilinizde yazılı teklif.