Schema.org yapılandırılmış veri: makineler şirketinizi buradan okur

§ 01 · SORUMLULUK

Schema.org yapılandırılmış veriyi kim yazar?

Tablo rakip firmaları değil, kategorileri tarif eder. Bu ayrımın tamamı ve neden tek sözleşmede topladığımız: Neden Baki Bilişim.

§ 02 · SORUN

Yapılandırılmış veri olmadan tam olarak ne kaybediliyor?

§ 03 · KAPSAM VE TESLİMATLAR

Bu hizmet tam olarak neyi teslim eder?

@id mimarisi, sayfalara schema yapıştırmaktan neden farklı?

Sayfa sayfa eklenen işaretleme, aynı şirketi her sayfada yeniden ve biraz farklı tanımlar: birinde unvan kısaltılmış, diğerinde adres eksik, üçüncüsünde telefon başka biçimde yazılmıştır. @id mimarisinde her varlık bir kez tanımlanır, kalıcı bir kimlik alır ve diğer sayfalardan yalnızca referansla çağrılır. Sonuç: tek şirket, tek adres, tek kimlik — site ne kadar büyürse büyüsün.

Kurumsal graf çekirdeği

Bu blok tüm sayfalarda aynı kalır. Şirketin tek tanımıdır; her sayfada yeniden yazılmaz, referans edilir.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://ornek.example/#organization",
      "name": "Örnek Metal Sanayi A.Ş.",
      "url": "https://ornek.example/",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "1. OSB 3. Cadde No 12",
        "addressLocality": "Gebze",
        "addressRegion": "Kocaeli",
        "addressCountry": "TR"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://ornek.example/#website",
      "url": "https://ornek.example/",
      "publisher": { "@id": "https://ornek.example/#organization" },
      "inLanguage": "tr-TR"
    }
  ]
}

Sayfa tipine özel düğümler

Her şablon yalnızca kendi düğümünü ekler ve çekirdeğe referans verir. Şirket bilgisi ikinci kez yazılmadığı için güncelleme tek yerden yapılır.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Service",
      "@id": "https://ornek.example/hizmet/lazer-kesim/#service",
      "name": "Lazer sac kesim",
      "serviceType": "Metal işleme",
      "provider": { "@id": "https://ornek.example/#organization" },
      "areaServed": { "@type": "Country", "name": "TR" }
    },
    {
      "@type": "WebPage",
      "@id": "https://ornek.example/hizmet/lazer-kesim/#webpage",
      "url": "https://ornek.example/hizmet/lazer-kesim/",
      "isPartOf": { "@id": "https://ornek.example/#website" },
      "about": { "@id": "https://ornek.example/#organization" },
      "dateModified": "2026-07-29"
    }
  ]
}

Bu sayfanın kaynak kodundaki JSON-LD bloğu da aynı yöntemle üretildi; tarayıcıda kaynağı görüntüleyip doğrulayıcıya yapıştırabilirsiniz.

§ 04 · SÜREÇ

Schema çalışması hangi aşamalardan geçiyor?

1. 01

   Envanter ve mevcut graf dökümü

   Yayındaki tüm sayfa tipleri çıkarılır, mevcut yapılandırılmış veri toplanır ve doğrulayıcıdan geçirilir. Çıktı: hangi sayfada hangi düğümün olduğu, nerede hata verdiği ve hangi sayfa tipinde hiç graf bulunmadığı.

   Teslimat

   Envanter tablosu ve hata dökümü

   Ölçüm kriteri

   Tüm sayfa tipleri listelenmiş, her biri için mevcut durum işaretlenmiş

   Sorumlu taraf

   Baki Bilişim (erişim: müşteri)

2. 02

   Varlık haritası

   Şirket, tüzel kişilikler, lokasyonlar, kişiler, hizmetler ve ürünler tek bir haritada ilişkilendirilir. Hangi varlığın hangi tiple modelleneceğine ve hangi dış kaynakların (kurumsal profiller, resmi kayıtlar) sameAs olarak bağlanacağına burada karar verilir.

   Teslimat

   Varlık diyagramı ve ilişki tablosu

   Ölçüm kriteri

   Her varlığın tipi, kaynağı ve sahibi belirli

   Sorumlu taraf

   Ortak (kurumsal bilgi doğrulaması müşteride)

3. 03

   @id mimarisi ve graf tasarımı

   Her varlığa kalıcı ve tekil bir @id verilir; tekrarlanan bilgi kopyalanmak yerine referansla çağrılır. Kanonik biçim (protokol, alan adı, sondaki eğik çizgi) tüm site için sabitlenir; böylece aynı varlık iki farklı kimlikle iki kez var olmaz.

   Teslimat

   Graf tasarım dokümanı ve @id kuralları

   Ölçüm kriteri

   Varlık başına tek @id; kanonik biçim tüm sayfalarda aynı

   Sorumlu taraf

   Baki Bilişim

4. 04

   Sayfa tipi eşlemesi ve şablon uygulaması

   Her şablona hangi düğümlerin ekleneceği matrisle belirlenir ve JSON-LD tekil sayfaya değil şablona yazılır. Çok lokasyonlu yapılarda lokasyon başına LocalBusiness, çok dilli yapılarda dil sürümleri ve hreflang ile tutarlı graf burada kurulur.

   Teslimat

   Eşleme matrisi ve şablon dosyaları

   Ölçüm kriteri

   Her şablon kendi düğümünü üretiyor; elle yazılan JSON-LD kalmadı

   Sorumlu taraf

   Baki Bilişim (CMS erişimi müşteride)

5. 05

   Doğrulama

   Schema.org doğrulayıcısı, Google Rich Results Test ve Search Console geliştirme raporları birlikte çalıştırılır. Her sayfa tipinden örnek alınır; hata ve uyarılar tekil sayfada değil, kaynağı olan şablonda kapatılır.

   Teslimat

   Doğrulama raporu (araç, tarih, sayfa örneği)

   Ölçüm kriteri

   Doğrulayıcıda 0 hata; hedeflenen tipte geçerli öğe

   Sorumlu taraf

   Baki Bilişim

6. 06

   Regresyon koruması ve devir

   Asıl risk ilk kurulumda değil, sonraki içerik güncellemelerindedir. Yayın öncesi kontrol, bozuk veya eksik grafla çıkışı engeller; içerik ekibine hangi alanın hangi düğümü beslediği yazılı olarak devredilir.

   Teslimat

   Kontrol betiği, kontrol listesi, devir dokümanı, eğitim oturumu

   Ölçüm kriteri

   Bozuk grafla yayına çıkış sayısı 0

   Sorumlu taraf

   Ortak (yayın akışı müşteride, kontrol bizde)

§ 05 · KABUL KRİTERLERİ

Hangi kriterler karşılanmadan iş teslim edilmiş sayılmaz?

Zengin sonuç gösterimi taahhüt edilmez, uygunluk taahhüt edilir: işaretlemenin geçerliliği bizim işimizdir, gösterim kararı arama motorunundur.

§ 06 · SEKTÖRLER

Hangi şirket yapılarında en çok fark yaratıyor?

• 01 Üretim ve fabrika → Ürün ailesi, teknik özellik tabloları ve kapasite bilgisi Product ve ItemList düğümleriyle modellendiğinde, satın alma tarafındaki arama tek üründe değil tüm katalogda karşılık bulur.
• 02 Mağaza zincirleri ve perakende → Her mağaza için ayrı LocalBusiness ve çalışma saati düğümü, mağaza bulucuyu yerel aramada okunabilir hale getirir; site, uygulama ve işletme profili aynı veriyi okur.
• 03 Bayilik ve franchise ağları → Merkez markanın tek Organization düğümü altında yüzlerce bayi lokasyonunun tutarlı biçimde tanımlanması, NAP tutarsızlığını kaynağında engeller.
• 04 İhracatçı sanayi → Çok dilli sürümlerde dil başına doğru inLanguage ve hreflang ile tutarlı graf, yabancı alıcının aradığı sürümün doğru pazarda görünmesini sağlar.
• 05 Kurumsal holding → Holding, iştirakler ve markalar arasındaki ilişki subOrganization ve parentOrganization düğümleriyle yazıldığında, motorlar hangi haberin hangi şirkete ait olduğunu ayırt eder.

§ 07 · İLGİLİ HİZMETLER

Bu hizmet hangi çalışmalarla birlikte alınır?

• 01 AEO — Answer Engine Optimization → Birlikte alınır: FAQPage ve HowTo düğümleri, cevap-önce yazılmış pasajların makine tarafında karşılığıdır. İşaretleme ile içerik yapısı aynı anda kurulmazsa ikisi de yarım kalır.
• 02 GEO — Generative Engine Optimization → Birlikte alınır: üretken motorlarda doğru tanıtılmanın temeli varlık netliğidir. sameAs ağı, tutarlı kimlik sinyalleri ve graf, GEO çalışmasının girdisidir.
• 03 Kurumsal web sitesi → Birlikte alınır: graf şablon seviyesinde kurulduğu için yeni site projesinde ek maliyeti düşüktür; yayındaki bir siteye sonradan eklemek her zaman daha pahalıdır.
• 04 Bayi ve şube ağı dijital yönetimi → Birlikte alınır: lokasyon sayfası mimarisi ile çoklu LocalBusiness grafı aynı veriyi kullanır; ikisi ayrı ajanslarda yürütülürse NAP tutarsızlığı kaçınılmaz olur.

Konunun teknik arka planı için: Schema.org ve JSON-LD rehberi · Terimler için: dijital görünürlük sözlüğü.

§ 08 · SIK SORULANLAR

Yapılandırılmış veri hakkında en çok sorulan yedi soru