JSON-LD'deki her düğümün, her @id'in ve her ilişkinin sayfanın gerçekten söylediğiyle örtüştüğü ölçülü bir işaretleme modeli. Kullanıcının doğrulayamayacağı hiçbir bilgi eklenmez.

Her şablonu tek bir sayfa rolüne ve tek bir birincil varlığa bağlar, kopya ya da desteksiz düğümleri ayıklar ve canlı production çıktısını doğrular. Taslak ölçüt sayılmaz. Sitedeki her JSON-LD bloğu, sayfanın ve onaylı grafiğin zaten söylediğiyle aynı şeyi söyler. Bunu canlı sayfada doğrularız. Her şablonun aynı varlığı kendi yapılandırılmış verisinde farklı şekilde ürettiği teknik SEO ve mühendislik sorumluları için.

Varlık düğümünü büyük bir bağlantı kafesine yerleştiren uzman illüstrasyonu

Birlikte çalıştığımız 500'den fazla markadan birkaçı

Tüm referansları gör
  • GE
  • Silverline
  • AVVA
  • Lezzet
  • Ekol
  • Yolcu360
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • MediaMarkt
  • Decathlon
  • Trendyol
  • Hepsiburada
  • Sahibinden.com
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • DenizBank
  • Acıbadem Sağlık Grubu
  • Abdi İbrahim

Onaylı grafikten doğrulanmış, canlı bir şablona uzanan beş adım.

Çalışma ilkelerimiz

  • Her şablona tek @id
  • Görünür içerikle eşitlik
  • Production'da doğrulanır
  • Hayali ilişki yok
  1. Şablonları kendi varlık rollerine bağlıyoruz

    Her sayfa tek bir rol ve tek bir izinli grafik dilimi alır. İçerik, varlık ve teknik ekipler bu rolü onaylar.

    Her şablonun birincil @id'ini ve izinli grafik parçasını gösteren şablon haritası.

  2. Tanımlayıcıları onaylı grafikle hizalıyoruz

    Yeni bir ilişki eklemeden önce mevcut tanımlayıcıları kayıtla karşılaştırıyoruz. Varlıktan sorumlu kişi ve mühendis bu kararı onaylar.

    Her @id için birleştirme, koruma veya değiştirme kararı.

  3. Her ilişkiyi kanıta dayanarak doğruluyoruz

    Yön, grafik bağlantısı ve görünür sayfa desteği birlikte kontrol edilir. Alan uzmanı, gizlilik ve hukuk ekipleri bu yönü onaylar.

    Desteksiz bağlantıların açıkça reddedildiği bir ilişki kaydı.

  4. Kopya ile desteksiz işaretlemeyi kaldırıyoruz

    Görünür sayfanın desteklemediği düğümleri ve özellikleri, bağımlılıkları bozmadan kaldırıyoruz. Mühendislik ve içerik ekipleri geçiş sırasını onaylar.

    Güvenli bir kaldırma sırası ve bağımlılık haritası.

  5. Canlı sözdizimini ve eşitliği doğruluyoruz

    Canlı JSON-LD'yi temsil edici sayfalarda ve uç sayfalarda ayrıştırıyoruz. Bağımsız bir teknik SEO incelemecisi sonucu onaylar.

    Production'daki sözdizimini, grafik eşitliğini ve regresyonu kapsayan rapor.

Mühendisliğin tek seferde uygulayabileceği şablon şartnamesi ve production çıktısının onaylı modelle hâlâ örtüşüp örtüşmediğini gösteren ölçüm.

  • Varlık işaretleme incelemesi

    Canlı sayfalardaki kopya kimlikleri ve çelişkili @id'leri gösterir.

  • Schema ilişki sözleşmesi

    Onaylı düğüm, yönlü ilişki, köken ve hariç tutulanlar şablon bazında tanımlanır.

  • Tekrar kullanılabilir şablon planı

    Yeni sayfa kimliği kopyalamaz, onaylı düğüme referans verir.

  • Grafik eşitliği oranı

    Taslakta geçen ama production'da bozulan bir şablon, başarı sayılmaz.

  • Yayın hattınıza bağlanmış eşitlik testleri

    Şablon, tanımlayıcı ya da ilişki değiştiğinde ilgili sürüm kontrolü yeniden başlatıyor. Bir kez geçmiş olmak, işaretlemenin sonrasında da yerinde durduğunun kanıtı sayılmıyor.

Aynı kuruluş için iki ayrı şablon iki farklı @id üretiyor ve JSON-LD, görünür metnin hiç değinmediği bir ilişkiyi iddia ediyor.

Şu durumlarda iyi bir seçim

  • Her şablon Schema yapısını kendi başına uyduruyor — Hakkımızda, ürün ve yazar sayfaları aynı Organization düğümünü birbirinden bağımsız üretir. Hiçbiri diğeriyle eşleşmez.
  • Grafik sayfayla ters düşüyor — JSON-LD, parentOrganization veya görev unvanı gibi bir bilgi iddia eder. Görünür metin bu iddiayı doğrulamaz.
  • Tanımlayıcılar dile veya şablona göre kayıyor — Türkçe ve İngilizce sayfalar aynı varlığı iki farklı canonical URL'yle gösterir.
  • Önce onaylı bir varlık grafiği gerekir — Onaylı kimlik modeli henüz yoksa önce Varlık ve İlişki Haritalama uygulanır.
  • Her şablon tek bir birincil @id'e çözümleniyor — Sayfa rolü ve onaylı tanımlayıcı uydurulmuyor, ikisi de onaylı grafikten geliyor.
  • Görünür içerikle eşitlik gözetiyoruz — Bir ilişki, ancak kullanıcı bunu aynı sayfanın görünür metninden doğrulayabiliyorsa JSON-LD'ye girer.
  • Doğrulamayı canlı sayfada yapıyoruz — Bir build adımı, önbellek veya CMS varsayılanı gerçek çıktıyı değiştirebilir. Bu yüzden production çıktısını kontrol ediyoruz.

Şu durumlarda başka bir çalışma daha doğru

  • İşaretlemeden zengin sonuç garantisi bekliyorsunuz — Doğru işaretleme gerekli uygunluğu kuruyor, zengin sonucu, bilgi panelini ya da AI atfını zorlamıyor.
  • Grafik dolu görünsün diye ilişki uydurulmasını istiyorsunuz — Sözdizimi doğru ama anlamı yanlış bir Schema ilerleme sayılmıyor, alanı boş bırakmak daha güvenli.
  • Sıralama, panel veya atıf için garanti vermeyiz — İşaretleme gerekli uygunluğu kurar. Dış sistemin sonucunu garanti etmez.
  • Schema App

    JSON-LD'yi onaylı grafa bağlıyor, desteklenmeyen düğümleri yayından önce yakalıyor

  • InLinks

    Şablonun entity referanslarını sayfa içeriğinden öneriyor, graph parçasını en küçük tutuyor

  • Schema.org Validator

    Tek bir arama motorundan bağımsız schema.org uyum kontrolünü yapıyor

  • Google Rich Results Test

    Taslağı değil, production'daki render çıktısının canlı uyumunu kontrol ediyor

  • Screaming Frog

    Şablonlar arasındaki render edilmiş JSON-LD'yi çıkarıp mükerrer @id değerlerini listeliyor

  • Sitebulb

    Markup'ı tarama sırasında doğrulayıp hataları üreten şablona göre gruplandırıyor

Mevcut şablonlarınızı ve JSON-LD'yi bize getirin. Zeo her şablonu tek bir varlığa bağlar, sayfanın desteklemediğini çıkarır ve canlıya çıkan sonucu doğrular.
Schema çalışmasını konuşalım

Bilgi grafiği ve Schema mimarisi kurmak arama motorlarında neyi değiştirir?

Sayfadaki metinlerin anlamsız kelimeler yerine kesin varlıklar (organizasyon, ürün, kurucu, hizmet) olarak tanımlanmasını sağlar; bilgi panelleri ve zengin sonuçların tetiklenmesini kolaylaştırır.

Mevcut CMS şablonlarımız zaten JSON-LD üretiyorsa bu çalışmaya neden ihtiyaç duyarız?

Çoğu standart CMS yalnızca temel ve kopuk şemalar üretir. Biz varlıklar arasındaki ilişkileri (sameAs, parentOrganization, knowsAbout, author) birbirine bağlayan bütünleşik bir anlamsal ağ kuruyoruz.

Schema işaretlemelerinin doğruluğunu ve standartlara uygunluğunu nasıl test ediyoruz?

Google Rich Results Test, Schema.org validator ve özel doğrulama betiklerimizle işaretlemelerin hatasız çalıştığını ve sayfadaki görünür içerikle birebir örtüştüğünü doğruluyoruz.

Schema mimarisinde yapılan güncellemelerin arama sonuçlarına yansıması ne kadar sürer?

Arama motorlarının sayfaları yeniden tarama sıklığına bağlı olarak genellikle 1 ila 3 hafta içerisinde zengin sonuçlarda ve bilgi grafiğinde güncellemeler görülür.