Blog ve Kurumsal İçeriklerde JSON-LD Schema Manipülasyonu

Bir blog yazısının HTML tarafında kusursuz görünmesi, arama motorlarının sayfadaki yazar, yayıncı, tarih, ana konu ve sayfa türü ilişkilerini aynı açıklıkta anlayacağı anlamına gelmez. Blog ve Kurumsal İçeriklerde JSON-LD Schema Manipülasyonu burada devreye girer ve içeriğin gerçek yapısını makine tarafından okunabilir bir entity modeli halinde tanımlamayı sağlar. On yıllık web geliştirme ve teknik SEO projelerinde gördüğüm en önemli konu, structured data çalışmalarında başarıyı daha fazla property eklemekten çok doğru entity'yi, doğru URL'yi ve doğru veri kaynağını seçmenin belirlemesidir. Dinamik JSON-LD schema markup nasıl oluşturulur ve güncellenir sorusu da yalnızca birkaç JSON satırı üretmekten ibaret değildir; CMS, canonical, author, deployment ve validation süreçlerinin birlikte tasarlanmasını gerektirir. Bu rehberde blog ve kurumsal içeriklerde JSON-LD schema nasıl uygulanır, Article BlogPosting ve Organization schema JSON-LD nasıl yapılandırılır ve JSON-LD yapılandırılmış veri hataları ve rich results optimizasyonu nasıl yapılır sorularını güvenli, sürdürülebilir ve gerçek içerikle uyumlu bir yaklaşımla ele alacağız.

JSON-LD Nedir?

JSON-LD, web sayfalarındaki entity ve ilişkileri JSON söz dizimine yakın bir formatla ifade etmeyi sağlayan Linked Data yöntemidir. HTML içeriğini değiştirmeden ayrı bir script etiketi içinde yapılandırılmış veri tanımlanabilir. Bu durum geliştirici açısından schema kodunu template ve CMS verilerinden üretmeyi kolaylaştırır. Arama motorları sayfadaki BlogPosting, Person, Organization veya WebPage gibi entity'leri daha açık biçimde yorumlayabilir. Kurumsal projelerde JSON-LD'nin asıl değeri, veri modelini görünür içerikle uyumlu ve merkezi şekilde yönetebilmesidir.

JSON-LD Açılımı Nedir?

JSON-LD ifadesi JavaScript Object Notation for Linked Data açılımından gelir. JSON biçiminin okunabilirliğini Linked Data kavramlarıyla birleştirir. @context, @type ve @id gibi özel alanlar sayesinde bir nesnenin ne olduğu ve diğer entity'lerle nasıl ilişkilendiği açıklanabilir. Web geliştiricileri açısından standart JSON üretme araçlarıyla rahat çalışılması önemli avantajdır. Ancak JSON söz diziminin geçerli olması schema anlamının veya arama motoru uygunluğunun otomatik olarak doğru olduğu anlamına gelmez.

Linked Data Nedir?

Linked Data, web üzerindeki bilgileri birbirinden kopuk metin parçaları yerine birbirleriyle ilişkili entity'ler olarak modelleme yaklaşımıdır. Bir blog yazısı bir yazara, yazar bir profil sayfasına ve içerik bir kuruma bağlanabilir. @id kullanımı aynı entity'nin farklı sayfalarda tekrar tanımlanmak yerine referans verilmesini kolaylaştırır. Bu yaklaşım özellikle kurumsal sitelerde yazar, yayıncı, site ve sayfa ilişkilerinin tutarlı tutulmasına yardımcı olur. Semantic yapı kurulurken yalnızca gerçek ve doğrulanabilir ilişkiler kullanılmalıdır.

JSON ile JSON-LD Arasındaki Fark

Normal JSON veri taşımak veya uygulamalar arasında bilgi paylaşmak için genel amaçlı bir formattır. JSON-LD ise JSON yapısına semantik bağlam ve entity ilişkileri ekler. Örneğin sıradan JSON içindeki “name” alanının neyi temsil ettiği uygulama tarafından bilinirken JSON-LD içinde @context ve @type anlamı standart bir vocabulary ile ilişkilendirir. Bu yüzden her JSON-LD geçerli JSON olmalıdır fakat her JSON structured data değildir. Kurumsal schema üretiminde serialization ile semantic modeling ayrı sorumluluklar olarak ele alınmalıdır.

Schema.org ile JSON-LD Arasındaki İlişki

Schema.org, web üzerindeki entity türleri ve property'ler için ortak vocabulary sağlar. JSON-LD ise bu vocabulary'nin sayfaya uygulanabileceği formatlardan biridir. BlogPosting, Person, Organization ve BreadcrumbList gibi türler Schema.org tarafından tanımlanır. Bir geliştirici JSON-LD formatını kullanırken property'lerin semantic anlamını Schema.org modeline göre seçer. Dolayısıyla doğru syntax kullanmak kadar doğru type ve property ilişkisi kurmak da önemlidir.

Structured Data ve Schema Markup Nedir?

Structured data, bir web sayfasındaki bilgilerin makineler tarafından belirli bir sözlük ve yapı içinde yorumlanabilmesini sağlayan veridir. Schema markup ise bu yapılandırılmış veriyi Schema.org vocabulary'siyle ifade etme yaklaşımıdır. Blog sayfasında headline, author ve datePublished gibi alanlar içeriğin temel özelliklerini açıklayabilir. Kurumsal sitede Organization entity'si şirket kimliğini merkezi biçimde tanımlayabilir. Bu işaretlemeler yalnızca görünür içeriği açıklamalı ve sayfada bulunmayan gerçekler yaratmak için kullanılmamalıdır.

Structured Data Nedir?

Structured data belirli alan ve değerlerin önceden tanımlanmış anlamlarla sunulmasıdır. İnsan için yazılmış bir paragrafta yazar adı doğal metin içinde bulunabilirken structured data bunu açıkça author olarak işaretler. Böylece arama motoru ilgili değerin kişi, kurum veya farklı bir entity olup olmadığını daha kolay yorumlayabilir. Web bağlamında JSON-LD, Microdata ve RDFa bu bilgiyi sunmanın farklı yöntemleridir. Teknik tasarımda veri kaynağının gerçek içerikle senkron olması temel gereksinimdir.

Schema Markup Nedir?

Schema markup, sayfa içeriğindeki entity'leri Schema.org vocabulary kullanarak açıklayan işaretlemedir. Sayfanın bir blog yazısı, hizmet, profil veya kurumsal sayfa olup olmadığı bu modelle ifade edilebilir. Property seçimi sayfanın gerçek içeriğine göre yapılmalıdır. Kullanılabilecek çok sayıda alan bulunması hepsinin eklenmesi gerektiği anlamına gelmez. Gereksiz property üretmek yerine doğru ve sürdürülebilir model oluşturmak daha değerlidir.

Structured Data Arama Motorlarına Ne Anlatır?

Structured data sayfadaki bilgilerin türünü ve entity ilişkilerini açık hale getirir. Arama motoruna bir metnin başlık, bir URL'nin yazar profili veya belirli bir kurumun publisher olduğunu anlatabilir. Bu açıklık entity disambiguation ve bazı arama özelliklerine uygunluk açısından fayda sağlayabilir. Ancak işaretleme, sayfada bulunmayan içeriği arama motoruna farklı göstermemelidir. Structured data bir gizli SEO metni değil görünür içeriğin makine tarafından okunabilir temsilidir.

Structured Data SEO'nun Hangi Katmanındadır?

Structured data teknik SEO, bilgi mimarisi ve içerik modelleme arasında bulunan bir katmandır. Crawl ve index sorunlarını tek başına çözmez. İçerik kalitesini veya site otoritesini de tek başına oluşturmaz. Buna karşılık sayfanın anlamını, entity ilişkilerini ve bazı rich result uygunluklarını daha açık biçimde ifade edebilir. Bu nedenle canonical, rendering, içerik ve site mimarisi sorunları çözülmeden schema tek başına büyük sonuç beklenen bir araç haline getirilmemelidir.

JSON-LD Neden Blog ve Kurumsal Sitelerde Kullanılır?

Blog ve kurumsal siteler yalnızca birbirinden bağımsız URL'lerden oluşmaz. İçerik, yazar, kurum, kategori, site ve profil sayfaları arasında anlamlı ilişkiler bulunur. JSON-LD bu ilişkileri entity graph şeklinde ifade etmeyi kolaylaştırır. Özellikle büyük CMS sistemlerinde alanların template üzerinden otomatik üretilmesi bakım maliyetini azaltabilir. Blog ve Kurumsal İçeriklerde JSON-LD Schema Manipülasyonu güvenli biçimde uygulandığında temel hedef daha fazla işaretleme üretmek değil bu ilişkileri tutarlı hale getirmektir.

İçerik Türünü Açıklamak

Sayfanın BlogPosting, Article, NewsArticle, Service veya farklı bir tür olduğunu açıkça ifade etmek arama motorunun içerik bağlamını anlamasına yardımcı olur. Type seçimi sayfanın gerçek amacıyla eşleşmelidir. Kurumsal blog yazısına sırf hizmetten bahsediyor diye Service type eklemek doğru değildir. Primary entity yaklaşımı bu kararı sadeleştirir. Her URL için önce “Bu sayfanın esas konusu ve amacı nedir?” sorusu cevaplanmalıdır.

Yazar Kimliğini Tanımlamak

Author alanı yalnızca metin olarak bir isim vermek yerine Person veya gerektiğinde Organization entity'sine bağlanabilir. Yazarın profil URL'si ve stabil @id değeri aynı kişinin farklı içeriklerde tanınmasını kolaylaştırır. Aynı isimde farklı kişiler olduğunda bu ayrım daha da önem kazanır. Yazar bilgisi görünür sayfa içeriğiyle uyumlu olmalıdır. Gerçekte yazarı olmayan veya ekip tarafından üretilen içerikte uydurma kişi üretmekten kaçınılmalıdır.

Kurumsal Entity'yi Tanımlamak

Organization schema kurumun adı, canonical URL'si, logosu ve resmi profilleri gibi temel kimlik bilgilerini merkezi olarak tanımlayabilir. Aynı kurum her blog sayfasında farklı ad veya URL ile yeniden yaratılmamalıdır. Stabil bir Organization @id kullanılarak publisher alanından referans verilmesi daha temiz yapı oluşturur. Bu yaklaşım schema drift riskini azaltır. Kurumsal entity verisinin source of truth sistemi açıkça belirlenmelidir.

İçerikler Arasındaki İlişkileri Açıklamak

WebPage ile BlogPosting, Person ile ProfilePage veya BlogPosting ile publisher Organization arasında doğrudan ilişkiler kurulabilir. @id referansları aynı graph içindeki tekrarları azaltır. BreadcrumbList ise sayfanın site içindeki navigasyon bağlamını ifade edebilir. İlişkiler gerçek sayfa yapısından türetilmelidir. İçerikte bulunmayan veya site navigasyonunda var olmayan yapıları yalnız schema içinde yaratmak doğru değildir.

Arama Motorlarının İçeriği Anlamasını Kolaylaştırmak

Structured data belirsiz metin ilişkilerini daha açık alanlarla ifade eder. Örneğin bir kişinin adı sayfada geçebilir fakat author property bu kişinin içeriğin yazarı olduğunu daha net belirtir. Benzer şekilde Organization publisher ilişkisi kurumsal yayıncının hangi entity olduğunu gösterir. Bu açıklık teknik SEO için yararlıdır. Buna rağmen işaretleme, iyi içerik ve doğru crawl yapısının yerine geçmez.

JSON-LD Schema Manipülasyonu Ne Demektir?

Schema manipülasyonu ifadesi iki farklı anlamda kullanılabilir ve bu ayrım önemlidir. Birinci anlam, CMS veya uygulama verisinden JSON-LD'nin programatik olarak oluşturulması ve yönetilmesidir. İkinci anlam ise arama görünümünü yanıltmak amacıyla sahte veya alakasız structured data üretilmesidir. Güvenli uygulamada property ekleme, kaldırma ve entity linking gerçek sayfa durumuna göre yapılır. Yanıltıcı uygulamada ise schema kullanıcıya görünmeyen veya doğrulanamayan bilgiler taşır ve bu yaklaşım ciddi SEO riski oluşturabilir.

Meşru Programatik Schema Yönetimi

Meşru schema yönetimi mevcut içerik ve kurumsal master data üzerinden doğru JSON-LD üretmeyi amaçlar. CMS alanlarından headline, author ve tarih verileri alınabilir. Sayfa türüne göre bazı property'ler koşullu olarak eklenebilir veya kaldırılabilir. Entity registry içindeki kurum ve yazar kimlikleri @id ile referans verilebilir. Bütün bu işlemler test, validation ve deployment süreçleriyle yönetildiğinde schema kod parçası olmaktan çıkıp sürdürülebilir veri mimarisine dönüşür.

Property ekleme

Property yalnızca sayfada karşılığı bulunan bilgi için eklenmelidir. Örneğin gerçek bir featured image varsa image alanı üretilebilir. Yazar profil URL'si varsa author.url eklenebilir. Yeni property template'e eklenmeden önce hangi CMS alanından besleneceği belirlenmelidir. Kaynağı belirsiz property uzun vadede schema drift oluşturur.

Property kaldırma

Her property her sayfada zorunlu değildir. Veri yoksa boş string üretmek yerine property'yi koşullu olarak kaldırmak çoğu zaman daha temizdir. Deprecated veya yanlış kullanılan alanlar template migration ile kaldırılabilir. Removal işlemi diff test ile izlenmelidir. Search feature etkisi varsa rollout öncesi pilot yapılmalıdır.

Dinamik değer üretme

Dinamik değer CMS veya routing sisteminden gerçek zamanlı alınabilir. Canonical URL routing katmanından, tarih alanı CMS'den ve yazar bilgisi author profile kaynağından gelebilir. Dinamik üretim manuel hatayı azaltır. Buna karşılık yanlış source mapping bütün siteye hatalı veri basabilir. Bu nedenle validation otomatik olmalıdır.

Entity linking

Entity linking aynı kurum, yazar veya site nesnesini stabil @id ile birbirine bağlamaktır. BlogPosting içindeki author tam Person objesi yerine doğru @id referansı kullanabilir. Organization publisher ilişkisi de aynı mantıkla kurulabilir. Böylece tekrar eden entity verisi azalır. @id standardının site genelinde değişmemesi önemlidir.

Yanıltıcı Schema Manipülasyonu

Yanıltıcı schema manipülasyonu, arama motoruna sayfada gerçekte bulunmayan veya doğrulanamayan bilgi sunmayı amaçlar. Sahte rating, görünmeyen FAQ veya alakasız entity type kullanımı bunun tipik örnekleridir. Bu tür uygulamalar kısa vadeli görünüm beklentisiyle yapılsa bile güven ve uyumluluk riski oluşturur. Arama motoru yönergeleri structured data ile sayfa içeriğinin uyumlu olmasını bekler. Kurumsal projelerde schema governance bu tür hataları deployment öncesinde engellemelidir.

Sahte veri

Gerçekte olmayan ödül, müşteri sayısı veya değerlendirme schema içine eklenmemelidir. Structured data kullanıcıya görünür içerikle doğrulanabilir olmalıdır. Sahte veri semantic modelin güvenilirliğini bozar. Kurumsal hukuk ve iletişim ekipleri iddiaları gerektiğinde doğrulamalıdır. Otomasyon sistemleri serbest metinden kontrolsüz iddia üretmemelidir.

Gizli içerik

Kullanıcıya sunulmayan FAQ veya açıklamaları yalnız JSON-LD içinde göstermek risklidir. Accordion gibi kullanıcı tarafından açılabilen içerik farklı değerlendirilebilir çünkü sayfanın gerçek içeriğinin parçasıdır. CSS ile tamamen kullanıcıdan saklanan metin daha sorunlu olabilir. CMS'te bulunup rendered sayfada görünmeyen alanlar otomatik schema'ya aktarılmamalıdır. Visible content parity testi bu nedenle değerlidir.

Alakasız schema

Sayfanın amacıyla ilişkili olmayan type'lar rich result beklentisiyle eklenmemelidir. Blog yazısına Product veya Service eklemek yalnızca kelimenin içerikte geçmesi nedeniyle doğru olmaz. Primary entity sayfanın ana amacını temsil etmelidir. Yan entity gerekiyorsa about veya mentions daha uygun olabilir. Schema type stuffing sürdürülebilir SEO yaklaşımı değildir.

Sahte review

Gerçek kullanıcı değerlendirmesi bulunmayan sayfaya yıldız rating eklemek ciddi structured data riski oluşturur. Kurumun kendi kendine verdiği puan kullanıcı değerlendirmesi değildir. Review verisi görünür olmalı ve kaynağı açık olmalıdır. Blog yazısına sırf yıldız sonucu hedefiyle AggregateRating eklenmemelidir. Validation yalnız syntax değil içerik doğruluğunu da kontrol etmelidir.

Schema Manipülasyonu ile Structured Data Spam Arasındaki Sınır

Sınırın temelinde gerçeklik ve içerikle eşleşme bulunur. Programatik olarak üretilmiş schema tek başına spam değildir. Otomasyonun ürettiği veri sayfada gösterilen gerçek bilgilerden geliyorsa güvenli bir yönetim yaklaşımıdır. Sorun, otomasyon görünür içerikten kopup kullanıcıya sunulmayan veya doğrulanamayan iddialar üretmeye başladığında ortaya çıkar. Bu nedenle kurumsal web sitesi JSON-LD schema ve teknik SEO optimizasyon hizmeti tasarlanırken semantic doğruluk için teknik test kadar editoryal kontrol de kurulmalıdır.

Sayfadaki İçerikle Eşleşme

Headline, author, tarih ve FAQ gibi alanlar rendered sayfa ile uyumlu olmalıdır. CMS içindeki farklı bir başlığın schema'ya aktarılması tutarsızlık yaratabilir. Sayfa güncellenince JSON-LD de aynı source üzerinden güncellenmelidir. Automated crawler visible text ile structured data arasında fark tespit edebilir. Bu kontrol regression testing'in parçası yapılabilir.

Gerçek ve Doğrulanabilir Bilgi

Schema içinde sunulan kurum, yazar, ödül veya değerlendirme bilgisi gerçek olmalıdır. Data source açıkça tanımlanmalıdır. Bir property için güvenilir kaynak yoksa eklenmemesi daha doğrudur. Kurumsal claim'ler legal veya corporate communication onayı gerektirebilir. Semantic doğruluk rich result beklentisinden daha öncelikli tutulmalıdır.

Kullanıcıya Görünmeyen Veri

Kullanıcıya görünmeyen her veri otomatik olarak yasak değildir çünkü teknik identifier veya @id gibi alanlar doğal olarak arayüzde gösterilmeyebilir. Ancak içerik iddiası taşıyan FAQ, rating veya açıklama sayfanın gerçek içeriğiyle uyumlu olmalıdır. Schema kullanıcıya farklı bir sayfa anlatmamalıdır. Template hidden field'ları dikkatle incelenmelidir. CMS'teki internal notların schema'ya yanlışlıkla aktarılması önlenmelidir.

Alakasız Entity Kullanımı

Entity yalnızca keyword benzerliği nedeniyle eklenmemelidir. İçerikte bir markanın adı bir kez geçti diye ana konu olarak işaretlemek semantic modeli bozabilir. about içeriğin ana konularını, mentions ise ikincil olarak geçen entity'leri ifade etmek için düşünülebilir. Her kelimeyi entity'ye dönüştürmek gereksiz graph büyümesine yol açar. Human review özellikle otomatik entity extraction sistemlerinde önemlidir.

Yanıltıcı Kurumsal İddialar

“En iyi”, “lider” veya “bir numara” gibi ifadeler kanıtlanabilir bağlam olmadan structured data'ya dönüştürülmemelidir. Marketing copy ile factual entity data ayrı tutulmalıdır. Ödül ve sertifika gibi bilgiler gerçek kaynaktan gelmelidir. Müşteri sayısı sürekli değişiyorsa otomatik güncelleme kaynağı tanımlanmalıdır. Schema kullanıcıya sunulan kurumsal gerçeği temsil etmelidir.

Schema.org Geçerliliği ile Google Uyumluluğu Aynı Şey midir?

Hayır, Schema.org vocabulary açısından geçerli bir property kullanmak Google'ın bu property'yi belirli bir arama özelliği için desteklediği anlamına gelmez. Schema.org daha geniş semantic model tanımlar. Google ise kendi structured data özellikleri için belirli tür ve alanları destekleyebilir. Bu nedenle Schema Markup Validator ve Rich Results Test farklı amaçlarla kullanılır. Teknik ekip her iki seviyeyi birbirinden ayırarak test yapmalıdır.

Schema.org Vocabulary

Schema.org type ve property'lerin semantic anlamını tanımlar. Çok geniş bir vocabulary bulunur. Bir property geçerli şekilde type ile kullanılabilir. Bununla birlikte arama motoru bu alanı özel bir rich feature için kullanmayabilir. Semantic modeling ile search eligibility ayrı katmanlardır.

Google Structured Data Features

Google belirli içerik türleri için structured data özellikleri sunabilir. Bu özelliklerin gereksinimleri Schema.org genel vocabulary'sinden daha dar olabilir. Required veya recommended alanlar değişebilir. Kurumsal ekip güncel dokümantasyonu deployment öncesi kontrol etmelidir. Feature desteği zaman içinde değişebileceği için monitoring önemlidir.

Rich Result Eligibility

Geçerli markup rich result garantisi vermez. İçerik, site kalitesi, feature availability ve farklı sistemler sonucu etkileyebilir. Structured data yalnızca uygunluk sinyallerinden biridir. Rich Results Test teknik uygunluğu kontrol etmeye yardımcı olur. SEO raporlarında “schema eklendi, sonuç garanti” yaklaşımından kaçınılmalıdır.

Google'ın Desteklemediği Schema.org Özellikleri

Schema.org içinde Google tarafından özel arama özelliğinde kullanılmayan pek çok type ve property bulunur. Bunlar yine semantic modeling amacıyla anlamlı olabilir. Ancak sırf mevcut oldukları için graph'a eklenmeleri gerekmez. Kurumsal template minimal ve kullanılabilir tutulmalıdır. Search feature hedefi varsa Google dokümantasyonu ayrı kontrol edilmelidir.

JSON-LD, Microdata ve RDFa Arasındaki Fark

JSON-LD, Microdata ve RDFa structured data ifade etmek için kullanılan farklı yöntemlerdir. JSON-LD ayrı script bloğu içinde bulunur. Microdata HTML elementlerinin içine attribute ekler. RDFa da HTML içine semantic attribute'lar yerleştirir. Büyük kurumsal sitelerde JSON-LD çoğu zaman template yönetimi ve test kolaylığı nedeniyle daha rahat ölçeklenir.

JSON-LD

JSON-LD HTML içeriğinden ayrı tutulabilir. Bu durum CMS mapping ve graph generation işlerini sadeleştirir. Standard JSON serializer kullanılabilir. Entity ilişkileri @graph ve @id ile açık biçimde tanımlanabilir. Server-side rendering ile güvenilir şekilde üretilebilir.

Microdata

Microdata structured data attribute'larını doğrudan HTML elementlerine ekler. Görünür içerikle yakın olması parity açısından avantaj sağlayabilir. Ancak büyük template'lerde markup dağınık hale gelebilir. Component değişiklikleri semantic attribute'ları etkileyebilir. Kurumsal bakım maliyeti JSON-LD'ye göre daha yüksek olabilir.

RDFa

RDFa HTML ve XML tabanlı dokümanlara semantic metadata eklemek için kullanılır. Linked Data yaklaşımıyla güçlü ilişki ifade edebilir. Web SEO projelerinde JSON-LD kadar yaygın tercih edilmeyebilir. Existing RDF altyapısı bulunan sistemlerde anlamlı olabilir. Ekip deneyimi seçim kararında önemlidir.

Kurumsal Sitelerde Hangisi Daha Yönetilebilir?

Kurumsal CMS ve headless yapılarda JSON-LD genellikle en rahat yönetilen seçeneklerden biridir. Schema generator ayrı library olarak geliştirilebilir. Unit test ve diff testing kolay uygulanabilir. HTML component değişikliklerinden daha az etkilenir. Bununla birlikte mevcut platformun mimarisi ve ekip yetkinliği nihai kararı belirlemelidir.

Blog İçeriğinde Hangi Schema Türü Kullanılmalıdır?

Blog sayfasının type seçimi içeriğin gerçek yayın formatına göre yapılmalıdır. Genel içerik için Article, tipik blog yazısı için BlogPosting ve gerçek editoryal haber formatı için NewsArticle düşünülebilir. En spesifik doğru türü kullanmak semantic modeli daha açık hale getirir. Her blog yazısını otomatik NewsArticle olarak işaretlemek doğru değildir. CMS page type ile schema type arasında merkezi mapping oluşturmak yönetimi kolaylaştırır.

Article

Article geniş kapsamlı yazılı içerik türünü temsil eder. BlogPosting ve NewsArticle gibi türler bunun daha özel alt türleri olarak düşünülebilir. Sayfa belirgin şekilde blog veya haber formatına uymuyorsa Article kullanılabilir. Type seçimi template adına göre değil gerçek içerik amacına göre yapılmalıdır. Kurumsal içerik ekipleri page taxonomy ile schema taxonomy'yi eşleştirmelidir.

BlogPosting

BlogPosting blog gönderileri için daha spesifik bir Article türüdür. Kurumsal blog yazılarında sık kullanılan seçimdir. headline, author, publisher ve tarih alanlarıyla birlikte kullanılabilir. WebPage entity'siyle mainEntity ilişkisi kurulabilir. Blog kategorisi veya listeleme sayfasına BlogPosting verilmemelidir.

NewsArticle

NewsArticle haber niteliğindeki editoryal içerikler için tasarlanmıştır. Kurumsal basın veya haber bölümü gerçekten bu özellikleri taşıyorsa değerlendirilebilir. Normal evergreen blog yazısı sırf güncel konu işliyor diye NewsArticle yapılmamalıdır. Editorial workflow type seçiminde önemlidir. Google'ın haberla ilişkili structured data gereksinimleri ayrıca kontrol edilmelidir.

En Spesifik Doğru Türü Seçmek

Schema seçiminde amaç mümkün olan en fazla type'ı eklemek değildir. Sayfanın gerçek doğasını en doğru ifade eden spesifik type tercih edilmelidir. BlogPosting uygun olduğunda generic Article yerine kullanılabilir. Birden fazla type ihtiyacı varsa primary entity açık tutulmalıdır. Semantic minimalism bu noktada bakım ve doğruluk avantajı sağlar.

Article ile BlogPosting Arasındaki Fark

Article daha genel bir içerik türüdür, BlogPosting ise blog yazısını temsil eden daha spesifik bir alt türdür. İki type'ın birçok ortak property alanı vardır. Kurumsal blog sayfasında BlogPosting çoğu zaman daha açık seçimdir. Editoryal içerik formatı farklıysa Article veya NewsArticle değerlendirilebilir. Type kararının bütün site template'lerinde aynı standarda göre verilmesi schema drift'i azaltır.

Article Üst Türü

Article genel makale ve yazı içeriklerini kapsar. Daha spesifik alt tür mevcut değilse kullanılabilir. Semantic olarak geniş bir çerçeve sunar. Property yapısı BlogPosting ile büyük ölçüde örtüşebilir. Page type mapping sırasında default article seçeneği olarak kullanılabilir.

BlogPosting Alt Türü

BlogPosting blog formatındaki içerikleri daha açık ifade eder. Kurumsal bloglarda yazar, tarih ve içerik ilişkisi net şekilde modellenebilir. WebPage ile ilişkilendirilmesi tavsiye edilen temiz graph yapısı oluşturur. Blog feed veya category page için uygun değildir. CMS content type doğrudan BlogPosting'e map edilebilir.

Kurumsal Blog İçin Seçim

Kurumsal blog şablonunda içerikler gerçek blog yazısıysa BlogPosting mantıklı default seçimdir. Yazar bilgisi Person veya Organization olarak doğru şekilde verilmelidir. Publisher merkezi Organization entity'sine referans vermelidir. Tarihler görünür içerikle uyumlu tutulmalıdır. Template değişikliklerinde bütün blog URL'leri regression test ile kontrol edilmelidir.

Editoryal Haber İçeriği İçin Seçim

Kurumsal haber merkezi ayrı editoryal süreçle çalışıyorsa NewsArticle değerlendirilebilir. İçerik sadece blogda yayınlanan güncel bir yazıysa type değiştirmek gerekmez. Haber ve blog taxonomy'si CMS düzeyinde ayrılmalıdır. Page type assertion testleri yanlış type basılmasını önleyebilir. Structured data seçimi arama özelliği beklentisiyle değil gerçek yayın modeline göre yapılmalıdır.

BlogPosting Schema İçin Temel Alanlar

BlogPosting schema oluştururken headline, description, image, author, publisher, datePublished, dateModified ve mainEntityOfPage temel yapı taşlarıdır. Bu alanların tamamı aynı kaynaktan kontrolsüz şekilde alınmamalıdır. Her property için doğru source of truth belirlenmelidir. Örneğin canonical routing servisinden, yazar CMS profilinden ve publisher merkezi entity registry'den gelebilir. Böyle bir mapping yaklaşımı Article BlogPosting ve Organization schema JSON-LD nasıl yapılandırılır sorusuna ölçeklenebilir cevap verir.

headline

headline sayfanın gerçek başlığını temsil etmelidir. CMS page title veya editorial headline kaynak olarak kullanılabilir. Schema headline ile görünür H1 arasında gereksiz fark oluşturulmamalıdır. Otomatik SEO başlığı kullanılıyorsa bunun içerik başlığıyla anlamlı uyumu kontrol edilmelidir. Schema audit sırasında headline parity otomatik test edilebilir.

description

description içeriğin kısa açıklamasını verir. CMS excerpt veya onaylı meta açıklama source olarak kullanılabilir. Otomatik kırpma yapılacaksa cümle bütünlüğü bozulmamalıdır. İçerikte bulunmayan pazarlama iddiası description içine eklenmemelidir. Null durumda property koşullu üretilebilir.

image

image blog yazısını temsil eden görseli tanımlar. Featured image canonical ve erişilebilir URL ile verilmelidir. Placeholder veya tracking pixel kullanılmamalıdır. Görsel değiştiğinde schema da source üzerinden güncellenmelidir. Birden fazla uygun görsel varsa array yapısı değerlendirilebilir.

author

author içeriğin gerçek yazarını temsil eder. Person veya belirli senaryolarda Organization kullanılabilir. Stabil @id ve profil URL'si entity sürekliliği sağlar. Guest author için yine ayrı entity oluşturulabilir. CMS'te boş author alanı varsa sahte kişi yaratmak yerine editoryal süreç düzeltilmelidir.

publisher

publisher içeriği yayınlayan Organization veya uygun entity'ye işaret eder. Kurumsal bloglarda genellikle merkezi Organization @id kullanılır. Her sayfada ayrı kurum kopyası üretmek yerine referans yaklaşımı tercih edilebilir. Publisher verisi kurum master data'sıyla eşleşmelidir. Rebranding sırasında merkezi entity güncellenmelidir.

datePublished

datePublished içeriğin ilk yayın tarihini göstermelidir. CMS publish timestamp güvenilir source olmalıdır. Tarih ISO 8601 formatında üretilebilir. Timezone standardı site genelinde tutarlı olmalıdır. Migration sırasında original publish date korunması gerekebilir.

dateModified

dateModified içeriğin anlamlı biçimde güncellendiği zamanı göstermelidir. Her deployment veya cache purge nedeniyle değişmemelidir. Editoryal sistem gerçek değişiklik zamanını ayrı alan olarak tutabilir. Otomatik güncelleme freshness manipülasyonu riskini artırır. Görünür güncelleme tarihiyle schema arasında uyum sağlanmalıdır.

mainEntityOfPage

mainEntityOfPage Article entity'sinin hangi WebPage üzerinde ana entity olduğunu ifade eder. Stabil webpage @id ile ilişki kurulabilir. Canonical URL ile tutarlı tasarım önemlidir. Self-referencing loop hataları schema graph tasarımında kontrol edilmelidir. WebPage tarafında mainEntity ile ters ilişki kurulabilir.

datePublished Nasıl Yönetilmelidir?

datePublished içerik yaşam döngüsündeki ilk yayın anını temsil etmelidir. CMS migrate edildiğinde bu alanın yanlışlıkla migration tarihine dönüşmesi sık görülen hatadır. İlk yayın tarihi içerik kaydında ayrı tutulmalıdır. Timezone ve ISO 8601 standardı bütün site için aynı şekilde uygulanmalıdır. Tarih gösterimi kullanıcıya farklı formatta sunulabilir fakat semantic değer gerçek publish zamanını doğru temsil etmelidir.

İlk Yayın Tarihi

İlk yayın tarihi içerik ilk kez erişilebilir hale geldiğinde oluşan tarihtir. Republishing politikası varsa ayrıca belgelenmelidir. Migration veya template değişikliği ilk yayın tarihini değiştirmemelidir. Legacy içeriklerde source belirsizse veri kalite çalışması yapılmalıdır. Uydurma tarih üretmekten kaçınılmalıdır.

CMS Kaynağı

CMS publish date alanı structured data için source olabilir. Ancak bazı sistemlerde created_at ile published_at farklı anlam taşır. Draft oluşturma tarihi kullanıcıya yayın tarihi olarak gösterilmemelidir. Schema generator doğru alanı map etmelidir. Unit test sample içeriklerle mapping'i doğrulayabilir.

Timezone

Timezone farkı gün değişimine neden olabilir. CMS UTC saklayıp kullanıcıya yerel saat gösterebilir. JSON-LD standardı net olmalıdır. Offset ile birlikte ISO değer kullanmak belirsizliği azaltır. Çok bölgeli sistemlerde içerik yayın politikası önceden tanımlanmalıdır.

ISO 8601

ISO 8601 makine tarafından okunabilir tarih formatı sağlar. Tarih ve saat offset ile sunulabilir. String formatı merkezi helper üzerinden üretilmelidir. Manuel string concatenation syntax hatası yaratabilir. Validation pipeline invalid date formatını deployment öncesi yakalamalıdır.

dateModified Ne Zaman Güncellenmelidir?

dateModified gerçek ve anlamlı içerik değişikliğini temsil etmelidir. Büyük paragraf güncellemesi, veri düzeltmesi veya editoryal yeniden yazım buna örnek olabilir. Küçük typo düzeltmesi için güncelleme politikası kurum tarafından tanımlanabilir. Teknik deployment'ın kendisi içerik değişikliği değildir. Her build sırasında dateModified üretmek hem kullanıcı hem arama motoru açısından yanlış freshness sinyali oluşturabilir.

Gerçek Editoryal Güncelleme

İçeriğe yeni bölüm eklenmesi veya önemli bilgi değişikliği dateModified güncellemesini hak eder. Kullanıcıya da güncellendi bilgisi göstermek şeffaflık sağlar. CMS revision sistemi değişiklik zamanını tutabilir. Schema generator bu alanı güvenilir şekilde kullanmalıdır. Büyük içerik ekiplerinde editorial approval sonrası tarih güncellenebilir.

Typo Düzeltmesi

Bir harf hatasının düzeltilmesi her kurumda aynı policy ile ele alınmayabilir. SEO için her küçük düzenlemede tarihi ileri taşımak doğru yaklaşım değildir. Kullanıcı açısından anlamlı içerik değişikliği kriteri belirlenmelidir. CMS revision kayıtları küçük değişiklik ile substantive update'i ayırabilir. Policy bütün içerik ekibinde aynı uygulanmalıdır.

Teknik Deployment

CSS, JavaScript veya template deployment içerik güncellemesi anlamına gelmez. Build timestamp dateModified olarak kullanılmamalıdır. Static site generator yanlış yapılandırılırsa bütün sayfaların tarihi her deploy'da değişebilir. Bu hata automated test ile yakalanabilir. Content timestamp ile deployment timestamp ayrı tutulmalıdır.

Otomatik Tarih Güncellemenin Riskleri

Her sayfa render edildiğinde mevcut tarihi yazmak yapay freshness oluşturur. Kullanıcının gördüğü tarih ile schema tarihi farklılaşabilir. Search sistemleri tutarsızlık görebilir. İçerik geçmişi anlamını kaybeder. Tarih kaynağı CMS revision veya editorial metadata olmalıdır.

İçeriğin Tarihini Yapay Olarak Güncellemek Doğru mudur?

Hayır, içeriğin anlamlı biçimde değişmediği durumlarda tarihi sırf daha yeni görünmek için güncellemek sağlıklı bir yaklaşım değildir. Freshness gerçek editoryal faaliyetle ilişkili olmalıdır. dateModified kullanıcının gördüğü bilgiyle uyumlu tutulmalıdır. Template veya deployment otomasyonu tarihleri kendiliğinden ileri taşımamalıdır. Kurumsal governance, güncelleme kriterlerini hem içerik hem geliştirici ekip için açıkça tanımlamalıdır.

Freshness Manipülasyonu

Freshness manipülasyonu gerçek değişiklik olmadan yeni tarih sinyali üretmektir. Kullanıcı eski içeriği yeniymiş gibi algılayabilir. Schema bu davranışı güçlendirmek için kullanılmamalıdır. Otomatik yayın sistemleri bu riski yanlışlıkla oluşturabilir. Audit sırasında tarih değişim pattern'leri incelenebilir.

Gerçek İçerik Değişikliği

Yeni veri, güncel yöntem veya önemli açıklama eklendiğinde tarih güncellenebilir. Revision diff değişikliğin boyutunu gösterebilir. Editör değişikliği onaylayabilir. Kullanıcıya “güncellendi” bilgisi gösterilebilir. Schema aynı değeri source üzerinden kullanmalıdır.

Kullanıcıya Gösterilen Tarihle Uyumluluk

Schema tarihi ile sayfadaki görünür tarih tutarlı olmalıdır. Birinde 2024 diğerinde 2026 yazması güvenilirliği azaltır. Frontend ve JSON-LD aynı CMS field'ından beslenebilir. Localization yalnız formatı değiştirmelidir. Semantic tarih değeri aynı kalmalıdır.

Author Schema Nasıl Oluşturulmalıdır?

Author schema içerik üreticisinin kimliğini açık şekilde tanımlamalıdır. Gerçek kişi için Person, ekip veya kurum tarafından yazılan içeriklerde uygun durumda Organization kullanılabilir. author.name, author.url ve stabil @id temel ilişkiyi oluşturur. sameAs yalnız resmi ve doğrulanmış entity sayfaları için eklenmelidir. Author modeling özellikle büyük kurumsal bloglarda entity consistency açısından önemli yapı taşıdır.

Person

Person gerçek bireysel yazarı temsil eder. name, url ve gerektiğinde sameAs kullanılabilir. Profil sayfası varsa stabil person @id ile ilişkilendirilmelidir. Yazarın görev unvanı gibi bilgiler doğru ve güncel kaynaktan alınmalıdır. Person entity marketing amacıyla uydurulmamalıdır.

Organization

Organization author bazı ekip içeriklerinde uygun olabilir. Örneğin içerik gerçek anlamda editoryal ekip veya kurum adına yayımlanıyorsa kullanılabilir. Sahte person yaratmaktan daha doğru olabilir. Ancak bireysel yazar varsa kurum author olarak kullanılmamalıdır. Publisher ve author rollerinin farklı olduğu unutulmamalıdır.

author.name

author.name görünür yazar adıyla eşleşmelidir. CMS profile display name kaynak olabilir. Unvanı isim alanına karıştırmak gerekmez. Aynı kişi farklı sayfalarda farklı yazım biçimleriyle sunulmamalıdır. Entity registry normalization sağlayabilir.

author.url

author.url yazarın canonical profil sayfasını gösterebilir. Profil sayfası gerçek, erişilebilir ve yazarı açıklayan içerik taşımalıdır. Social profile doğrudan author.url yerine sameAs kapsamında değerlendirilebilir. URL migration olduğunda person @id ve redirect planı birlikte ele alınmalıdır. Broken profile link audit edilmelidir.

sameAs

sameAs aynı entity'nin başka güvenilir sayfalardaki kimliğini ilişkilendirir. Resmi sosyal profiller buna örnek olabilir. Rastgele backlink, directory veya başka kişiye ait profil eklenmemelidir. Aynı bağlantı source of truth üzerinden yönetilmelidir. Yazar kendi profillerini editoryal onay süreciyle doğrulayabilir.

Yazar URL'si Neden Önemlidir?

Yazar URL'si yalnız navigasyon kolaylığı sağlamaz, aynı zamanda entity identity açısından stabil referans noktası olabilir. Aynı isimli kişilerin ayrılması kolaylaşır. Yazarın bio, uzmanlık ve içerik geçmişi tek sayfada toplanabilir. BlogPosting author ilişkisi bu profile bağlanabilir. Büyük içerik sitelerinde profil URL standardı değişmeden korunmalıdır.

Aynı İsimli Yazarları Ayırmak

İki farklı yazar aynı adı taşıyabilir. Sadece name string kullanıldığında entity belirsiz kalır. Unique profil URL ve @id bu kişileri ayırır. CMS author id internal olarak farklı tutulabilir. Public schema stabil URL üzerinden kimliği ifade edebilir.

Entity Identity

Entity identity aynı kişinin farklı içeriklerde aynı nesne olarak tanınmasını sağlar. @id bu amaçla önemli araçtır. Profil URL entity'nin kullanıcıya görünen merkez sayfasıdır. sameAs dış kaynaklarla ilişki kurabilir. Tüm bu alanlar aynı kişiyi tutarlı temsil etmelidir.

Yazar Profil Sayfasına Bağlantı

Profil sayfasında bio, uzmanlık ve yayınlar bulunabilir. ProfilePage schema ile Person entity ilişkilendirilebilir. BlogPosting author bu Person @id'sine referans verebilir. Profil sayfası thin content olmamalıdır. Kullanıcı için de anlamlı kaynak sunmalıdır.

İçerikler Arası Yazar Tutarlılığı

Aynı yazarın adı, URL'si ve @id'si tüm içeriklerde tutarlı olmalıdır. CMS duplicate author kaydı oluşturursa schema drift ortaya çıkar. Merge mekanizması geliştirilmelidir. Yazar adı değişirse migration policy belirlenmelidir. Entity registry bu tutarlılığı merkezi yönetebilir.

ProfilePage Schema Nedir?

ProfilePage bir kişi veya kurum profilini merkezine alan sayfaları tanımlamak için kullanılabilir. Yazar profili bunun doğal örneğidir. mainEntity alanında Person entity tanımlanabilir. BlogPosting author referansı aynı Person @id'ye bağlanabilir. Böylece yazar profili ile yazılar arasında daha temiz entity graph oluşturulur.

Yazar Profil Sayfası

Yazar profil sayfası yalnız isimden oluşan boş sayfa olmamalıdır. Bio, rol ve içerik listesi kullanıcıya değer sağlar. ProfilePage type bu sayfanın amacını açıklar. Person mainEntity olarak tanımlanabilir. Canonical URL stabil tutulmalıdır.

mainEntity Person

ProfilePage'in ana konusu ilgili kişidir. Bu nedenle mainEntity Person ilişkisi anlamlıdır. Person için ayrı stabil @id kullanılmalıdır. Profil WebPage @id ile Person @id birbirinden farklı olmalıdır. Self-reference hatası böylece önlenir.

ProfilePage + Person İlişkisi

ProfilePage sayfayı, Person ise kişiyi temsil eder. İkisini tek entity gibi kullanmak semantic belirsizlik yaratabilir. Page mainEntity olarak Person'a bağlanır. Person url profil sayfasını gösterebilir. Bu çift yönlü ilişki graph tutarlılığını güçlendirir.

BlogPosting Author ile ProfilePage'i Bağlamak

BlogPosting author doğrudan ProfilePage'e değil Person entity'ye referans verebilir. Person url ilgili ProfilePage URL'sini gösterir. Bu yapı yazar kimliğini sayfa nesnesinden ayırır. CMS author mapping aynı @id'yi üretmelidir. Unit test author relation'ı doğrulayabilir.

Kurumsal Bloglarda Birden Fazla Yazar Nasıl Yönetilir?

Büyük kurumsal bloglarda çalışan yazarlar, misafir yazarlar, editoryal ekipler ve kurum adına yayınlanan içerikler bulunabilir. Her yazar için unique identity modeli kurulmalıdır. CMS author entity yalnız display name değil stabil internal id taşımalıdır. Guest author için de ayrı profil veya kontrollü entity kaydı oluşturulabilir. Organization author yalnız gerçekten kurum adına yazılan içeriklerde kullanılmalıdır.

Her Yazar İçin Unique ID

İsim tek başına unique değildir. CMS internal id ve public @id ayrı ama ilişkili olabilir. Aynı kişi yeniden kayıt edildiğinde duplicate kontrolü yapılmalıdır. Public person @id URL standardına dayanabilir. Migration sırasında id continuity korunmalıdır.

CMS Author Entity

CMS author kaydı name, bio, profile URL ve sameAs gibi alanları yönetebilir. Schema generator doğrudan bu entity'den veri alabilir. Content entry yalnız author relation saklar. Böylece yazar adı yüzlerce içerikte ayrı yazılmaz. Merkezi düzeltme tüm sayfalara yansır.

Guest Author

Guest author gerçek bir kişi olarak Person entity'siyle modellenebilir. Geçici olması kimlik bilgisinin uydurulabileceği anlamına gelmez. Profil sayfası zorunlu değilse en azından doğru name ve uygun URL politikası belirlenmelidir. Guest content ownership açık olmalıdır. sameAs yalnız doğrulanmış bağlantılarla kullanılmalıdır.

Editorial Team

Editorial Team kurum içinde tanımlı gerçek bir ekip olabilir. Bireysel yazar verilmiyorsa Organization veya uygun entity yaklaşımı değerlendirilebilir. Hayali kişi kullanmaktan kaçınılmalıdır. Kullanıcıya içerik sahipliği açıkça gösterilmelidir. Kurumsal governance ekip adının zaman içinde değişimini yönetmelidir.

Organization Author

Organization author kurum tarafından kolektif olarak üretilen içerikte kullanılabilir. Bunun her kurumsal blog yazısında otomatik uygulanması doğru değildir. Gerçek bireysel yazar varsa Person daha açıklayıcıdır. Publisher ile author aynı entity olabilir ancak roller semantic olarak farklıdır. İçerik politikası bu seçimi standardize etmelidir.

Organization Schema Nedir?

Organization schema kurumsal entity'nin temel kimlik bilgilerini makine tarafından okunabilir formatta açıklar. name, url, logo, contactPoint, sameAs ve address gibi property'ler uygun olduğunda kullanılabilir. Site genelinde aynı kurumu farklı nesneler halinde üretmek yerine merkezi @id yaklaşımı tercih edilmelidir. Kurumsal master data schema generator için source of truth olabilir. Logo veya şirket adı değişiklikleri version controlled biçimde güncellenmelidir.

name

name kurumun resmi veya kullanılan ana adını temsil eder. Sayfalar arasında farklı varyasyonlar üretilmemelidir. Legal name gerekiyorsa ayrı property değerlendirilebilir. Brand değişimi merkezi entity kaydından yönetilmelidir. Typo veya pazarlama sloganı kurum adı alanına karıştırılmamalıdır.

url

url kurumsal entity'nin canonical ana sayfa adresini göstermelidir. HTTPS ve hostname standardıyla uyumlu olmalıdır. www ile non-www varyasyonu karıştırılmamalıdır. Redirect edilen eski domain kullanılmamalıdır. Routing ve canonical standardı merkezi olmalıdır.

logo

logo kurumun resmi logo görseline işaret eder. Stable ve erişilebilir URL tercih edilmelidir. Kampanya görseli logo yerine kullanılmamalıdır. Rebranding sırasında asset URL migration planı hazırlanmalıdır. Image object gerekirse daha ayrıntılı tanımlanabilir.

contactPoint

contactPoint gerçek müşteri veya kurumsal iletişim noktalarını açıklayabilir. Her sayfada farklı telefon üretmek doğru değildir. İletişim bilgisi source of truth sisteminden gelmelidir. Kullanılmayan telefonlar kaldırılmalıdır. Privacy ve operasyon politikası dikkate alınmalıdır.

sameAs

sameAs kurumun resmi ve güvenilir harici profillerini gösterebilir. Sosyal medya hesapları örnek olabilir. Link building amacıyla directory listesi eklenmemelidir. Sahibi belirsiz profil kullanılmamalıdır. Merkezi registry üzerinden doğrulanmış bağlantılar tutulabilir.

address

address gerçek kurumsal adresi açıklayabilir. Global kurumlarda headquarters ile yerel ofisler ayrılmalıdır. Her blog yazısında address objesini tekrar etmek gerekmeyebilir. Organization merkez entity içinde tutulabilir. Çok bölgeli yapılarda department veya yerel entity modeling ayrıca değerlendirilmelidir.

Organization Schema Nerede Kullanılmalıdır?

Organization entity'sinin merkezi tanımı ana sayfa veya kurumsal entity açısından anlamlı merkezi sayfada oluşturulabilir. Alt sayfalar aynı @id'yi referans alabilir. Böylece yüzlerce blog yazısında kurum verisi tekrar tekrar tam nesne olarak üretilmez. Publisher relation aynı entity'ye bağlanır. Bu yaklaşım schema drift ve bakım maliyetini belirgin biçimde azaltır.

Ana Sayfa

Ana sayfa kurumun merkezi web varlığıdır. Organization ve WebSite entity'leri burada graph içinde tanımlanabilir. URL ve logo gibi temel bilgiler merkezi source'tan gelir. Homepage schema bütün alt sayfaların kopyası olmamalıdır. Site genel entity identity için temel referans noktası olabilir.

Kurumsal Entity'nin Merkezi Tanımı

Merkezi tanım kurumun tek stabil @id ile temsil edilmesini sağlar. Farklı template'ler bu entity'yi yeniden yaratmak yerine referans verir. Master data güncellendiğinde tek kaynak değişir. Test sistemi farklı Organization @id'lerini tespit edebilir. Kurumsal semantic governance için bu model çok değerlidir.

Alt Sayfalardan @id ile Referans

BlogPosting publisher içinde Organization @id kullanılabilir. WebSite publisher da aynı entity'ye referans verebilir. Böylece graph daha sade olur. @id tam URL veya belirlenmiş fragment standardına göre üretilmelidir. Hostname ve protocol canonical ile uyumlu olmalıdır.

Her Blog Yazısına Ayrı Organization Objesi Eklemek Gerekir mi?

Genellikle aynı kurum için her blog yazısında yeni ve bağımsız Organization nesnesi üretmek gerekli değildir. Aynı @id ile referans vermek daha tutarlı graph oluşturabilir. Tam obje tekrarlandığında küçük veri farklılıkları zaman içinde schema drift yaratır. Publisher ilişkisinde merkezi Organization referansı yeterli olabilir. Template architecture entity reuse prensibine göre tasarlanmalıdır.

Duplicate Organization Problemi

Aynı kurum farklı @id, logo veya isimlerle tekrar üretilebilir. Search engine bunları farklı entity olarak yorumlayabilir. Duplicate graph analizi audit sürecine eklenmelidir. Merkezi registry duplicate riskini azaltır. Migration sırasında eski entity id'leri dikkatle ele alınmalıdır.

Tek Kurumsal Entity ID

Organization için tek stabil @id standardı belirlenmelidir. Örneğin ana domain üzerinde /#organization kullanılabilir. Bu değer farklı template'lerde hard-code yerine shared helper ile üretilmelidir. Domain migration olduğunda özel migration planı gerekir. Unit test Organization @id sabitliğini kontrol etmelidir.

Publisher Reference

BlogPosting publisher alanında yalnız @id referansı kullanılabilir. Full Organization object başka graph node'unda tanımlanabilir. Bu yöntem duplication azaltır. Publisher source içerik ekibinin manuel girişi olmamalıdır. Kurumsal registry güvenilir kaynak olmalıdır.

Schema Drift'i Önlemek

Schema drift aynı entity'nin farklı sayfalarda zamanla farklılaşmasıdır. Shared component ve central registry bu riski azaltır. Deployment öncesi crawler site-wide entity comparison yapabilir. Farklı logo veya sameAs değerleri alarm üretebilir. Governance owner düzeltme sürecini yönetmelidir.

WebSite Schema Nasıl Kullanılır?

WebSite schema alan adının temsil ettiği site entity'sini açıklar. Publisher ilişkisi merkezi Organization entity'sine bağlanabilir. inLanguage site veya sürüm diline göre tanımlanabilir. WebSite ile WebPage birbirinden farklı entity'lerdir. Site genelinde stabil website @id kullanmak diğer graph node'larının aynı siteye referans vermesini kolaylaştırır.

Site Entity

WebSite domain seviyesindeki web varlığını temsil eder. Organization ile aynı şey değildir. Bir kurum birden fazla WebSite işletebilir. @id genellikle ana domain üzerinde stabil fragment ile tanımlanabilir. URL normalization kuralları burada da uygulanmalıdır.

publisher

WebSite publisher siteyi yayınlayan kurumla ilişki kurar. Organization @id tekrar kullanılabilir. Farklı dillerde aynı publisher korunabilir. Yanlış local entity'ye bağlanmamalıdır. Çok markalı yapılarda site ownership ayrıca modellenmelidir.

inLanguage

inLanguage site veya sayfa dilini açıklar. Çok dilli sitelerde page-level değer daha ayrıntılı olabilir. Dil kodları tutarlı standarda göre kullanılmalıdır. CMS locale ile schema language mapping otomatikleştirilebilir. Yanlış locale fallback'leri test edilmelidir.

Organization ile Bağlantı

WebSite publisher veya ilgili property üzerinden Organization'a bağlanabilir. Aynı entity @id kullanıldığında graph ilişkisi netleşir. Kurumsal logo ve sameAs tekrar edilmez. Site ve kurum rolleri semantic olarak ayrı kalır. Bu ayrım büyük site ekosistemlerinde önemlidir.

WebPage Schema Nedir?

WebPage bir URL'nin temsil ettiği sayfa entity'sini tanımlar. Sayfanın ana konusu BlogPosting, Person veya Organization gibi farklı bir entity olabilir. Bu nedenle URL ile içerikteki ana entity aynı nesne olarak düşünülmemelidir. Blog yazısında WebPage ve BlogPosting birlikte tanımlanabilir. mainEntity ve mainEntityOfPage ilişkileri bu iki nesneyi birbirine bağlar.

URL Bir Sayfadır

Web üzerinde belirli canonical URL bir sayfayı temsil eder. Bu sayfanın HTML ve navigasyon yapısı olabilir. Sayfanın konusu ise ayrı entity'dir. WebPage @id sayfa kimliğini tanımlar. Canonical migration olduğunda bu kimlik stratejisi değerlendirilmelidir.

Sayfanın Ana Entity'si Ayrıdır

Blog sayfasının ana entity'si BlogPosting olabilir. Yazar profil sayfasının ana entity'si Person olabilir. Hakkımızda sayfasının ana entity'si Organization olabilir. Page ve entity ayrımı semantic modeli temiz tutar. mainEntity bu ilişkiyi ifade etmek için kullanılabilir.

WebPage + BlogPosting İlişkisi

WebPage mainEntity olarak BlogPosting'e bağlanabilir. BlogPosting mainEntityOfPage ile WebPage'e geri referans verebilir. İki @id farklı olmalıdır. Aynı canonical kökten fragment standardı kullanılabilir. Graph testleri yanlış loop veya duplicate node tespit edebilir.

WebPage ile BlogPosting Nasıl Bağlanır?

WebPage ve BlogPosting ayrı entity'lerdir ancak aynı URL'deki içerik deneyiminin farklı yönlerini temsil eder. WebPage sayfayı, BlogPosting ise yayınlanan yazıyı ifade eder. mainEntity ve mainEntityOfPage property'leri bu ilişkiyi açıklayabilir. @id referansları stabil olmalıdır. Template generator iki node'u aynı canonical kaynak üzerinden üretmelidir.

mainEntity

mainEntity sayfanın esas konusu olan entity'yi gösterir. WebPage node'u BlogPosting @id'sine referans verebilir. Sayfada birden fazla nesne bulunsa bile primary entity açık tutulmalıdır. Yan entity'ler mentions veya about ile ilişkilendirilebilir. mainEntity gereksiz yere çoklu hale getirilmemelidir.

mainEntityOfPage

mainEntityOfPage bir entity'nin hangi sayfanın ana konusu olduğunu belirtir. BlogPosting WebPage @id'sine bağlanabilir. Canonical URL değişiminde relation güncellenmelidir. Aynı article farklı canonical sayfalara bağlanmamalıdır. Migration testleri bu alanı kontrol etmelidir.

@id Referansları

@id entity identity için stabil identifier sağlar. WebPage ve BlogPosting farklı fragment id kullanabilir. Örneğin #webpage ve #article ayrımı uygulanabilir. Aynı pattern bütün blog template'lerinde kullanılmalıdır. Manuel string üretmek yerine ortak URL helper tercih edilmelidir.

mainEntity ve mainEntityOfPage Arasındaki Fark

mainEntity sayfadan ana entity'ye doğru ilişki kurar. mainEntityOfPage ise entity'den sayfaya doğru ilişkiyi ifade eder. İki property benzer görünse de yönleri farklıdır. Doğru @id tasarımıyla birlikte kullanıldıklarında WebPage ve içerik entity'si arasındaki bağ daha açık olur. Yanlış self-reference her iki node'un aynı id ile oluşturulmasından kaynaklanabilir.

WebPage → Entity

WebPage mainEntity alanı ana içerik entity'sine işaret eder. Blog sayfasında bu BlogPosting olabilir. Hakkımızda sayfasında Organization olabilir. Relation gerçek sayfa amacına göre belirlenmelidir. Page type mapping otomatik uygulanabilir.

Entity → WebPage

BlogPosting mainEntityOfPage ile WebPage entity'sine referans verir. Bu yön entity'nin hangi sayfa tarafından temsil edildiğini açıklar. Person profilinde benzer ilişki modeli kullanılabilir. Canonical değişiklik ilişkiyi etkiler. Regression test migration sonrası bunu doğrulamalıdır.

Self-Referencing Loop Hatası

WebPage ve BlogPosting aynı @id ile oluşturulursa entity ayrımı kaybolur. mainEntity kendisine referans verebilir. Bu durum graph'ın semantic kalitesini düşürür. Fragment naming standardı hatayı önlemeye yardımcı olur. Unit test farklı node id'lerini doğrulayabilir.

@graph Nedir?

@graph tek JSON-LD script içinde birden fazla entity tanımlamaya imkan verir. Organization, WebSite, WebPage ve BlogPosting aynı graph içinde ilişkilendirilebilir. Bu yöntem ilişkili node'ları tek yerde yönetmeyi kolaylaştırır. Her node stabil @id taşıdığında referanslar açık hale gelir. Büyük kurumsal sitelerde graph generator reusable component olarak tasarlanabilir.

Tek Script İçinde Birden Fazla Entity

@graph array içinde birden fazla node bulunabilir. Her node @type ve @id taşıyabilir. Bu yapı ayrı script bloklarını azaltabilir. Ancak graph gereksiz entity ile doldurulmamalıdır. Sayfa bağlamında gerekli node'lar seçilmelidir.

Entity İlişkilerini Birleştirmek

Organization publisher, Person author ve BlogPosting mainEntity ilişkileri aynı graph içinde çözülebilir. Full object kopyalamak yerine @id referansları kullanılabilir. Bu yapı daha okunabilir ve test edilebilir olur. Graph linter duplicate id kontrol edebilir. Relation mapping dokümante edilmelidir.

Site-Wide ve Page-Level Graph

Organization ve WebSite site-wide entity'lerdir. BlogPosting ve WebPage page-level entity'lerdir. Generator her request'te gerekli node'ları birleştirebilir. Site-wide veriler central registry'den gelir. Page-level veriler CMS content entry üzerinden üretilir.

Blog İçin Örnek Entity Graph

Tipik kurumsal blog graph'ında Organization, WebSite, Person, ProfilePage, WebPage, BlogPosting ve BreadcrumbList bulunabilir. Her node sayfanın gerçek yapısında bir role sahiptir. Bu listenin tamamı her blog URL'sinde zorunlu değildir. Örneğin ProfilePage genellikle yazar profil URL'sinde merkezi şekilde bulunabilir ve blog yazısı Person @id'ye referans verebilir. Graph tasarımında amaç entity sayısını artırmak değil gerçek ilişkileri açık hale getirmektir.

Organization

Organization publisher kurumunu temsil eder. Merkezi @id kullanılmalıdır. name ve URL master data'dan gelir. BlogPosting publisher bu node'a bağlanır. Duplicate Organization üretilmemelidir.

WebSite

WebSite kurumsal web sitesini temsil eder. Publisher Organization'a bağlanabilir. Site @id sabit tutulmalıdır. inLanguage gerektiğinde kullanılabilir. Page node'ları isPartOf ile siteye bağlanabilir.

Person

Person gerçek yazarı temsil eder. Profil URL ve @id tutarlı olmalıdır. BlogPosting author bu entity'yi kullanır. sameAs yalnız doğrulanmış profillerden gelir. Aynı kişi duplicate node olmamalıdır.

ProfilePage

ProfilePage yazarın profil URL'sini temsil eder. mainEntity Person olarak tanımlanabilir. WebPage ile Person ayrımı korunur. Blog yazısı doğrudan Person'a bağlanır. Profil sayfası kullanıcıya gerçek bilgi sunmalıdır.

WebPage

WebPage blog yazısının sayfa entity'sidir. Canonical ve @id tutarlı olmalıdır. mainEntity BlogPosting olabilir. isPartOf WebSite'e bağlanabilir. Breadcrumb relation ayrıca kurulabilir.

BlogPosting

BlogPosting asıl yazı entity'sidir. headline, author ve tarihleri içerir. publisher Organization'a bağlanır. mainEntityOfPage WebPage'i gösterir. about ve mentions gerektiğinde eklenebilir.

BreadcrumbList

BreadcrumbList gerçek navigasyon yolunu temsil eder. Ana sayfa, blog, kategori ve içerik adımları olabilir. URL'ler canonical olmalıdır. Sayfada görünür breadcrumb ile uyum sağlanmalıdır. Gereksiz seviyeler eklenmemelidir.

@id Nedir?

@id JSON-LD içinde entity için stabil kimlik tanımlamak amacıyla kullanılır. URL ile aynı olmak zorunda değildir ancak çoğu web projesinde URL tabanlı identifier kullanmak pratiktir. Fragment id sayesinde aynı sayfaya ait WebPage, BlogPosting ve Breadcrumb node'ları ayrılabilir. @id yalnız link değil entity identity olarak düşünülmelidir. Site-wide naming standardı değişmeden korunmalıdır.

Entity İçin Stabil Kimlik

Stabil kimlik entity'nin farklı sayfalarda aynı nesne olarak tanınmasını sağlar. Organization @id site genelinde değişmemelidir. Person @id yazar içeriklerinde aynı kalmalıdır. Random UUID üretmek public schema için gereksiz olabilir. URL tabanlı standart daha okunabilir olabilir.

URL'den Farkı

url property kullanıcıya erişilebilir sayfayı gösterir. @id ise entity kimliğidir. İkisi aynı temel URL'yi paylaşabilir fakat fragment ile ayrılabilir. Bir WebPage URL'si ve BlogPosting @id'si farklı semantic rol taşır. Bu ayrım graph modeling açısından önemlidir.

Fragment ID

Fragment id URL sonuna #organization veya #article gibi değer ekler. Farklı entity'leri aynı canonical taban altında ayırır. Naming convention merkezi tanımlanmalıdır. Büyük küçük harf farklılıkları önlenmelidir. Trailing slash kuralı da standartlaştırılmalıdır.

Aynı Entity'yi Tekrar Kullanmak

Aynı Organization node farklı içeriklerde aynı @id ile referans edilebilir. Böylece duplicate entity yaratılmaz. Yazar için de aynı model geçerlidir. Registry service @id üretiminden sorumlu olabilir. Schema diff tool değişiklikleri izleyebilir.

Kurumsal @id Naming Standardı Nasıl Kurulur?

Kurumsal @id standardı entity türüne göre tahmin edilebilir ve stabil formatlar belirlemelidir. Organization, WebSite, Person, Article, WebPage ve Breadcrumb için farklı fragment pattern'leri kullanılabilir. Naming sistemi canonical URL politikasına dayanmalıdır. Developers helper function üzerinden değer üretmelidir. Dokümantasyon ve unit test bu standardın zaman içinde bozulmasını önler.

Organization

Organization site-wide entity olduğu için ana domain temel alınabilir. Fragment okunabilir olmalıdır. Tüm sayfalarda aynı değer kullanılmalıdır. Domain migration özel süreç gerektirir. Merkezi registry bu id'yi saklayabilir.

/#organization

/#organization yaygın ve okunabilir naming örneğidir. Ana domain canonical yapısıyla birleştirilebilir. www ve slash standardı sabit olmalıdır. Farklı template'ler aynı helper'ı kullanmalıdır. Hard-coded farklı varyasyonlara izin verilmemelidir.

WebSite

WebSite için ayrı identifier kullanılmalıdır. Organization ile aynı @id verilmemelidir. Site ve kurum semantic olarak farklı entity'lerdir. Domain migration her ikisini etkileyebilir. Standard dokümante edilmelidir.

/#website

/#website WebSite entity'si için anlaşılır fragment örneğidir. Site genelinde aynı kalmalıdır. WebPage isPartOf relation bu id'ye bağlanabilir. Organization publisher ayrı id kullanır. Automated test yanlışlıkla #organization kullanılmasını yakalayabilir.

Person

Person id genellikle yazar profil URL'sine dayanabilir. Aynı isimli kişiler slug ile ayrılmalıdır. Slug değişimi entity continuity açısından dikkat ister. Internal author id mapping saklanabilir. Yazar deaktive edilse bile eski içerik relation'ı korunabilir.

/yazar/isim/#person

/yazar/isim/#person okunabilir person id örneğidir. Gerçek profil URL'si canonical olmalıdır. Slug normalization kuralı uygulanmalıdır. Türkçe karakter veya isim değişimi migration planı gerektirebilir. Eski profile redirect kullanılabilir.

Article

Article veya BlogPosting id içerik canonical URL'sine dayanabilir. Page id ile karışmamalıdır. İçerik migration'ında entity identity kararı önemlidir. Kalıcı article identity korunmak istenebilir. Redirect mapping schema generator tarafından bilinmelidir.

/blog/yazi/#article

/blog/yazi/#article belirli yazının içerik entity'sini ifade eder. #webpage ile farklı olmalıdır. Canonical taban URL doğru normalize edilmelidir. BlogPosting type için #article adı semantic olarak kabul edilebilir bir convention'dır. Kurum isterse #blogposting standardı da seçebilir fakat tutarlılık önemlidir.

WebPage

WebPage sayfa entity'si için ayrı id kullanılmalıdır. Article ve WebPage karıştırılmamalıdır. Canonical URL tabanı aynı olabilir. Fragment farklılığı semantic rolü ayırır. Testler id uniqueness kontrol etmelidir.

/blog/yazi/#webpage

/blog/yazi/#webpage ilgili URL'nin WebPage entity'sini temsil eder. mainEntity article id'ye bağlanabilir. isPartOf website id'ye referans verebilir. Migration sırasında canonical tabanı güncellenebilir. Diff report değişikliği gösterebilir.

Breadcrumb

BreadcrumbList için ayrı node id kullanılabilir. Aynı sayfanın navigation entity'sini temsil eder. WebPage breadcrumb property bu node'a bağlanabilir. URL segmentleri gerçek navigasyondan gelmelidir. Kategori değişikliğinde breadcrumb güncellenmelidir.

/blog/yazi/#breadcrumb

/blog/yazi/#breadcrumb açık naming convention sağlar. Article ve WebPage id'lerinden ayrıdır. Breadcrumb item URL'leri canonical olmalıdır. Gerçek UI navigation ile eşleşmelidir. Page deletion durumunda node da kaldırılmalıdır.

Canonical URL ile JSON-LD @id Nasıl Uyumlu Olmalıdır?

Canonical URL politikası ile schema URL ve @id üretimi aynı normalization kurallarını kullanmalıdır. HTTPS, www tercihi, trailing slash ve lowercase standardı farklı servislerde ayrı ayrı belirlenmemelidir. Bir URL HTML canonical'da başka, JSON-LD içinde başka varyasyonla görünürse entity consistency bozulabilir. Routing veya canonical service source of truth olarak kullanılabilir. Dinamik schema generator doğrudan bu servisten normalize edilmiş URL almalıdır.

HTTPS

Site canonical olarak HTTPS kullanıyorsa JSON-LD URL'leri de HTTPS olmalıdır. Eski HTTP adresleri redirect edilse bile schema içinde kullanılmamalıdır. Internal helper protocol normalization yapmalıdır. Mixed protocol audit edilebilir. Migration sonrası eski HTTP @id kalıntıları temizlenmelidir.

www / non-www

Site hangi hostname varyasyonunu canonical seçtiyse bütün schema aynı standardı izlemelidir. www ve non-www karışımı duplicate identity hissi oluşturabilir. Redirect olması tutarsızlığı meşru hale getirmez. Merkezi URL builder kullanılmalıdır. Automated crawler hostname mismatch raporu üretebilir.

Trailing Slash

Trailing slash politikası site genelinde tutarlı olmalıdır. /blog/yazi ve /blog/yazi/ farklı string değerlerdir. Canonical hangisini kullanıyorsa schema aynı değeri üretmelidir. Framework route helper bunu merkezi çözebilir. Manual string concatenation önlenmelidir.

Lowercase URL

URL policy lowercase ise schema da lowercase canonical kullanmalıdır. Case-sensitive sistemlerde farklı URL gerçek farklı resource olabilir. CMS slug normalization yayın öncesi yapılmalıdır. JSON-LD tarafında sonradan rastgele lowercase dönüşümü riskli olabilir. Source canonical service olmalıdır.

URL Normalization

Normalization protocol, hostname, path, query ve slash kurallarını kapsar. Schema generator kendi bağımsız normalization mantığını yazmamalıdır. Application canonical service ortak source olabilir. Query parametreli içerik canonical URL'ye map edilmelidir. Unit test representative URL örneklerini doğrulamalıdır.

Canonical ve Schema Çakışması Nasıl Tespit Edilir?

Canonical çakışması HTML canonical, JSON-LD url, @id, mainEntityOfPage ve breadcrumb URL'lerinin farklı canonical varyasyonlara işaret etmesiyle oluşabilir. Automated crawler bu değerleri aynı URL için çıkarıp karşılaştırabilir. Mismatch oranı kurumsal schema dashboard'unda KPI olarak izlenebilir. Migration sonrası bu kontrol özellikle önemlidir. Dinamik URL üretim prensipleriyle ilgili daha geniş teknik yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/e-ticaret-siteleri-icin-dinamik-url-ve-slug-uretim-algoritmalari adresindeki URL ve slug üretim mantıkları da faydalı bir referans olabilir.

HTML Canonical

HTML canonical sayfanın tercih edilen URL'sini açıklar. Schema comparison'ın temel referansı olabilir. Rendered DOM içinden değer alınmalıdır. Client-side değişiklik varsa crawler bunu görmelidir. Birden fazla canonical bulunması ayrıca teknik hatadır.

JSON-LD URL

url property gerçek canonical sayfayı göstermelidir. Redirect veya tracking URL kullanılmamalıdır. JSON-LD script parse edilip value çıkarılabilir. Template bazında mismatch raporu hazırlanabilir. Farklı page type'lar ayrı analiz edilmelidir.

@id

@id canonical taban kullanıyorsa normalization karşılaştırması yapılmalıdır. Fragment kısmı entity türüne göre farklı olabilir. Base URL canonical ile eşleşmelidir. External entity id'leri ayrı tutulmalıdır. Test logic entity türünü dikkate almalıdır.

mainEntityOfPage

mainEntityOfPage WebPage id veya canonical sayfa referansıyla uyumlu olmalıdır. Eski URL migration sonrası kalabilir. Bu durum graph continuity sorununa yol açar. Automated test redirect chain kontrol edebilir. Yeni template doğru id üretmelidir.

Breadcrumb URL

Breadcrumb item URL'leri gerçek canonical navigasyon hedeflerini kullanmalıdır. Parametreli veya eski kategori URL'leri bulunmamalıdır. UI breadcrumb ile schema breadcrumb karşılaştırılabilir. Kategori migration'ı bu alanı etkiler. Broken item list kullanıcı deneyimini de bozar.

BreadcrumbList Schema Bloglarda Nasıl Kullanılır?

BreadcrumbList blog yazısının site hiyerarşisi içindeki gerçek yolunu açıklayabilir. Ana sayfa, blog, kategori ve içerik gibi seviyeler kullanılabilir. Ancak schema'da gösterilen yol kullanıcıya sunulan navigasyonla uyumlu olmalıdır. Yapay kategori seviyeleri eklemekten kaçınılmalıdır. Breadcrumb URL ve position değerleri template üzerinden otomatik üretilebilir.

Ana Sayfa

Breadcrumb başlangıç noktası ana sayfa olabilir. URL canonical homepage olmalıdır. Name kullanıcıya görünen label ile uyumlu olmalıdır. Position doğru sıradan başlamalıdır. Çok dilli sitede label lokalize edilebilir.

Blog

Blog index sayfası gerçek navigasyon katmanıysa breadcrumb içinde kullanılabilir. URL canonical blog root olmalıdır. Eğer site doğrudan kategoriden içerik sunuyorsa yapay blog katmanı eklenmemelidir. Navigation source of truth kullanılabilir. Template hard-code yerine route metadata kullanabilir.

Kategori

Kategori sayfası gerçek ve indekslenebilir navigation adımıysa breadcrumb'a eklenebilir. İçerik kategori değiştirince schema otomatik güncellenmelidir. Bir yazının birden fazla kategorisi varsa primary category policy gerekir. Rastgele ilk kategori seçilmemelidir. CMS editorial field bunu belirleyebilir.

İçerik

Son breadcrumb öğesi mevcut içeriği temsil eder. Bazı implementation'larda URL verilebilir. Name headline ile uyumlu olmalıdır. Çok uzun başlık kısaltılıyorsa UI ve schema farkı mantıklı şekilde yönetilmelidir. Position önceki seviyelerden devam etmelidir.

Gerçek Navigasyonla Uyumluluk

Breadcrumb schema görünür navigasyondan kopmamalıdır. Kullanıcıya üç seviye gösterilirken schema beş seviye üretmemelidir. CSS ile hidden navigation ayrı değerlendirilmelidir. Site IA değiştiğinde schema template de güncellenmelidir. Regression test rendered breadcrumb ve structured data karşılaştırması yapabilir.

Kurumsal Hizmet Sayfalarında Hangi Schema Kullanılmalıdır?

Kurumsal hizmet sayfasının primary entity'si çoğu zaman blog yazısından farklıdır. WebPage temel sayfa entity'si olarak kullanılabilir. Gerçek hizmet anlatılıyorsa Service değerlendirilir. Organization provider veya ilgili kurum entity'siyle ilişkilendirilebilir. BreadcrumbList gerçek navigasyonu açıklar ve schema type'ları sayfa amacına göre sınırlı tutulmalıdır.

WebPage

Hizmet URL'si bir WebPage entity'sidir. mainEntity olarak Service bağlanabilir. WebPage canonical ve breadcrumb ilişkisini taşır. Site ve Organization'a bağlanabilir. BlogPosting yalnız içerik gerçekten blog yazısıysa kullanılmalıdır.

Service

Service gerçek sunulan hizmeti temsil eder. Blog yazısında bir hizmetten bahsedilmesi Service primary entity gerektirmez. Hizmet sayfasında name, provider ve description gibi alanlar gerçek içerikten alınabilir. Fiyat veya areaServed yalnız gerçek ve uygun olduğunda eklenmelidir. Service stuffing yapılmamalıdır.

Organization

Organization hizmeti sunan kurumla ilişki kurabilir. Merkezi @id kullanılmalıdır. Her service sayfasında yeni kurum objesi yaratılmamalıdır. Provider relation yeterli olabilir. Kurum bilgisi master data'dan gelmelidir.

BreadcrumbList

Hizmet sayfasının site içi yolu breadcrumb ile açıklanabilir. Hizmet kategorisi varsa gerçek navigation ile eşleşmelidir. URL'ler canonical olmalıdır. Position sırası doğru olmalıdır. Template SEO ve UX breadcrumb'ı aynı kaynaktan üretebilir.

Blog Yazısında Service Schema Kullanılmalı mı?

Genel olarak blog yazısının ana amacı bilgi vermekse BlogPosting primary entity olarak kalmalıdır. Yazı içinde bir hizmetin geçmesi sayfayı hizmet sayfasına dönüştürmez. Gerçek hizmet entity'si ikincil bağlam olarak mentions veya uygun relation ile ele alınabilir. Sırf ek schema türü kullanmak için Service eklemek type stuffing riskidir. Sayfa amacı seçimde temel kriterdir.

Sayfa Amacını Belirlemek

URL neden var sorusu önce yanıtlanmalıdır. Bilgilendirici içerik mi yoksa doğrudan hizmet sunumu mu olduğu belirlenmelidir. CTA bulunması tek başına Service type gerektirmez. Template type ve content model birlikte değerlendirilmelidir. Primary entity decision matrix hazırlanabilir.

BlogPosting Primary Entity

Blog yazısı bilgi sunuyorsa BlogPosting ana entity'dir. Service kelimesi içerikte geçebilir. Publisher ve author ilişkileri BlogPosting üzerinden devam eder. WebPage mainEntity BlogPosting'e işaret eder. Semantic model sade kalır.

Service'in Yazıda Geçmesi

Hizmet gerçekten içerikte konu olarak ele alınıyorsa about veya mentions kullanılabilir. Ayrı Service node eklemek her durumda gerekli değildir. Entity linking kullanıcıya sunulan bilgiyle uyumlu olmalıdır. Keyword nedeniyle otomatik entity üretiminden kaçınılmalıdır. AI extraction sonrası human review yapılmalıdır.

Schema Type Stuffing Riski

Çok sayıda type eklemek semantic kaliteyi otomatik artırmaz. Aksine sayfa amacı belirsiz hale gelebilir. Her type için gerçek entity ve kullanım gerekçesi olmalıdır. Rich result hedefi type seçiminden ayrı düşünülmelidir. Minimalism uzun vadeli bakım sağlar.

AboutPage Schema Ne Zaman Kullanılır?

AboutPage kurum, kişi veya proje hakkında bilgi veren hakkımızda sayfaları için kullanılabilir. Normal blog yazısına uygulanmamalıdır. Kurumsal Hakkımızda sayfasında Organization mainEntity olabilir. Sayfa aynı zamanda WebPage özelliklerini taşıyabilir. Template page type üzerinden koşullu schema üretilmelidir.

Hakkımızda Sayfası

Hakkımızda sayfası kurumun kimliğini ve geçmişini anlatır. AboutPage bu amacı açık biçimde ifade eder. Organization merkezi entity olarak ilişkilendirilebilir. Gerçek kurumsal bilgi visible content ile eşleşmelidir. Marketing claim'ler factual data gibi schema'ya dönüştürülmemelidir.

Organization mainEntity

AboutPage'in ana konusu kurum olabilir. mainEntity Organization @id'sine bağlanabilir. Organization full data merkezi graph node'unda bulunabilir. Sayfa kendi WebPage id'sini korur. Böylece page ve organization ayrımı netleşir.

Normal Blog Yazısından Farkı

BlogPosting belirli bir yazılı içeriği temsil eder. AboutPage ise sayfa fonksiyonunu tanımlar. Hakkımızda metni blog gibi yazılmış olsa bile page intent farklıdır. CMS content type buna göre ayrı olmalıdır. Schema template page type'tan türetilmelidir.

ContactPage Schema Ne Zaman Kullanılır?

ContactPage kullanıcıların kurumla iletişim kurduğu sayfaları tanımlamak için kullanılabilir. Bu sayfa hizmet sayfası değildir. Organization iletişim bilgisiyle ilişkilendirilebilir. Form, adres ve telefon gibi görünür bilgiler gerçek data source ile uyumlu olmalıdır. Sayfa template'i farklı type'larla gereksiz biçimde doldurulmamalıdır.

İletişim Sayfası

İletişim sayfasının ana amacı kullanıcıya iletişim yolu sunmaktır. ContactPage bu fonksiyonu açıklar. WebPage özellikleriyle birlikte kullanılabilir. Breadcrumb gerçek navigasyonu gösterebilir. BlogPosting burada kullanılmamalıdır.

Organization Bilgisi

Sayfada kurum telefon ve adres bilgisi bulunabilir. Organization merkezi entity'sine referans verilebilir. contactPoint gerçek bilgiyle eşleşmelidir. Local office ilişkisi gerektiğinde ayrıca modellenebilir. Duplicate organization yaratılmamalıdır.

Service Sayfasından Ayrımı

Service sayfası belirli hizmeti anlatır. ContactPage ise iletişim kurma fonksiyonuna odaklanır. Aynı URL üzerinde her iki amacın karışması UX açısından da sorun olabilir. Primary entity sayfa intent'ine göre seçilmelidir. Schema kullanıcı yolculuğundaki gerçek rolü yansıtmalıdır.

Blog Kategori Sayfalarında Hangi Schema Kullanılır?

Blog kategori sayfaları tek bir makale değil içerik koleksiyonudur. CollectionPage bu yapıyı ifade etmek için değerlendirilebilir. BreadcrumbList kategori sayfasının site hiyerarşisini açıklayabilir. ItemList gerçekten görünür içerik listesini temsil ediyorsa kullanılabilir. Kategori URL'sine BlogPosting primary entity eklemek genellikle doğru değildir.

CollectionPage

CollectionPage birden fazla içeriği bir araya getiren sayfalar için uygundur. Kategori veya arşiv sayfası buna örnektir. WebPage'in özel türü olarak düşünülebilir. Liste içerikleri doğru source'tan gelmelidir. Pagination durumunda canonical policy dikkate alınmalıdır.

BreadcrumbList

Kategori sayfası için ana sayfa ve blog kökü gibi navigasyon adımları gösterilebilir. UI breadcrumb ile eşleşme korunmalıdır. Kategori adı ve URL canonical olmalıdır. Taxonomy değişince güncellenmelidir. Duplicate kategori slug kontrol edilmelidir.

ItemList Gereksiniminin Değerlendirilmesi

Sayfadaki gerçek liste ItemList ile modellenebilir. Ancak her listing page için zorunlu değildir. ListItem URL ve position değerleri rendered içerikle uyumlu olmalıdır. Infinite scroll yapısında kapsam dikkatle belirlenmelidir. Yalnız server'da görünmeyen öğeler schema'ya eklenmemelidir.

BlogPosting Kullanılmaması Gereken Durumlar

Kategori sayfası tek bir blog yazısı değildir. Bu nedenle primary BlogPosting yanlış olur. Sayfadaki her card için tam BlogPosting objesi üretmek gereksiz graph büyümesi yaratabilir. ItemList daha uygun olabilir. Page intent collection olarak korunmalıdır.

about Property Nedir?

about property içeriğin ana konularını veya üzerinde yoğunlaştığı entity'leri tanımlamak için kullanılabilir. Her keyword about entity'si değildir. Thing, Person, Organization veya SoftwareApplication gibi gerçek entity'ler bağlama göre kullanılabilir. Ana konu ile ikincil mention ayrımı önemlidir. Otomatik entity extraction sistemi relevance threshold ve human review kullanmalıdır.

İçeriğin Ana Konuları

about yalnızca içeriğin gerçekten merkezinde bulunan konuları temsil etmelidir. Başlık ve ana bölümler bu karara yardımcı olur. Bir kelimenin tekrar sayısı tek başına yeterli sinyal değildir. Editorial taxonomy source olarak kullanılabilir. Gereksiz entity listesi semantic noise oluşturur.

Thing

Thing en genel Schema.org türüdür. Daha spesifik uygun type yoksa kullanılabilir. name ve sameAs ile belirli kavram tanımlanabilir. Ancak her keyword için generic Thing üretmek fayda sağlamaz. Entity gerçekten içeriğin konusu olmalıdır.

Person

İçerik belirli bir kişi hakkında ise about Person kullanılabilir. Sadece kişinin adı bir kez geçtiyse mentions daha uygun olabilir. Person id doğrulanmalıdır. Yanlış aynı isim eşleşmesi önlenmelidir. Entity extraction modeline identity resolution eklenebilir.

Organization

İçerik bir kurum üzerineyse about Organization kullanılabilir. Markanın kısa mention edilmesi ana konu olduğu anlamına gelmez. Official URL ve identity doğrulanmalıdır. sameAs gerektiğinde güvenilir kaynaklarla desteklenebilir. Kurumsal claim'ler içerikle uyumlu olmalıdır.

SoftwareApplication

Yazı belirli bir yazılımı ana konu olarak işliyorsa SoftwareApplication entity'si düşünülebilir. Version ve operating system gibi property'ler yalnız içerikte gerçekse eklenmelidir. Sırf teknik anahtar kelime geçti diye kullanılmamalıdır. Entity reference official source üzerinden doğrulanabilir. BlogPosting primary entity olmaya devam eder.

mentions Property Nedir?

mentions içerikte geçen fakat ana konu olmayan yan entity'leri tanımlamak için kullanılabilir. Bu property about ile aynı amaçta değildir. İkincil kişi, kurum veya yazılım referansları örnek olabilir. Her entity mention'ı schema'ya eklemek gerekmez. Kurumsal graph'ın okunabilir ve bakım yapılabilir kalması önemlidir.

İçerikte Geçen Yan Entity'ler

Yan entity içeriğin anlaşılmasına yardımcı olan fakat ana odak olmayan nesnedir. Bir teknik yazıda kullanılan araç veya kurum örnek olabilir. mentions ile ilişkilendirilebilir. Identity doğrulanmalıdır. Otomatik extraction sonrası false positive kontrol edilmelidir.

about ile mentions Arasındaki Fark

about ana konuyu, mentions ise ikincil referansı ifade eder. Bir entity yazının başlığında ve temel anlatısında bulunuyorsa about olabilir. Kısa örnek olarak geçiyorsa mentions daha uygundur. Bu ayrım semantic graph kalitesini artırır. Keyword frequency tek kriter olmamalıdır.

Her Keyword'ü Entity Yapmamak

SEO keyword listesi entity graph listesi değildir. Uzun kuyruklu sorguları otomatik about veya mentions haline getirmek gereksizdir. Entity gerçek bir kişi, kurum, kavram veya nesne kimliğine dayanmalıdır. Graph şiştikçe validation ve maintenance zorlaşır. Semantic minimalism uygulanmalıdır.

Schema Keyword Stuffing Nedir?

Schema keyword stuffing, arama görünürlüğü beklentisiyle keywords, about, knowsAbout veya farklı alanlara gereksiz anahtar kelime ve entity doldurma davranışıdır. Bu yaklaşım structured data'nın semantic amacını bozar. İçerik ile doğrudan ilişkili, gerçek ve anlamlı alanlar kullanılmalıdır. Kurumsal template SEO keyword listesini otomatik olarak entity property'lerine aktarmamalıdır. Schema graph kullanıcıya sunulan gerçek içeriği temsil etmelidir.

keywords Property

keywords belirli içeriklerde anahtar kelimeleri ifade etmek için kullanılabilir. Bunun arama sıralamasını doğrudan artıracağı varsayılmamalıdır. Yüzlerce kelime eklemek faydalı değildir. Editorial taxonomy veya sınırlı konu listesi source olabilir. Keyword stuffing'den kaçınılmalıdır.

knowsAbout

knowsAbout Person veya Organization gibi entity'lerin uzmanlık alanlarını ifade edebilir. Bir blog yazısının SEO keyword'lerini burada taşımak doğru değildir. Uzmanlık gerçek ve kanıtlanabilir olmalıdır. Yazar profilindeki bio ile uyumlu olabilir. Central profile data source kullanılmalıdır.

about

about içerik ana konusunu açıklamak içindir. Keyword listesi gibi kullanılmamalıdır. Birkaç anlamlı entity yeterli olabilir. Relation editorial logic ile belirlenmelidir. Otomatik topic extraction threshold kullanmalıdır.

Gereksiz Entity Üretimi

Her keyword için ayrı Thing node üretmek graph'ı gereksiz büyütür. Duplicate veya belirsiz entity'ler oluşabilir. Validation teknik olarak geçse bile semantic kalite düşer. Entity registry yalnız doğrulanmış node'ları saklamalıdır. Governance owner graph kapsamını kontrol etmelidir.

knowsAbout Nasıl Kullanılmalıdır?

knowsAbout bir kişi veya kurumun gerçek uzmanlık alanlarını ifade etmek için kullanılabilir. Bu alan pazarlama sloganlarıyla doldurulmamalıdır. Person profili, özgeçmiş veya kurumsal hizmet kapsamı gibi kanıtlanabilir kaynaklardan beslenebilir. Uzmanlık listesi sınırlı ve anlaşılır tutulmalıdır. İçerik SEO keyword'leri ile knowsAbout otomatik eşlenmemelidir.

Person Uzmanlık Alanları

Person knowsAbout gerçek mesleki veya teknik uzmanlığı yansıtmalıdır. Yazarın yayın geçmişi ve profil bilgisiyle uyumlu olabilir. Otomatik olarak her yazdığı konuyu uzmanlık saymak doğru değildir. Editoryal onay mekanizması kurulabilir. Güncelliği periyodik review ile kontrol edilebilir.

Organization Uzmanlık Alanları

Organization knowsAbout kurumun gerçekten faaliyet gösterdiği alanları açıklayabilir. Hizmet sayfaları ve kurumsal bilgiler source olabilir. Rakip veya ilgisiz sektör keyword'leri eklenmemelidir. Rebranding veya hizmet değişiminde güncellenmelidir. Data owner kurumsal iletişim veya ilgili ekip olabilir.

Gerçek Uzmanlık ve Kanıtlanabilirlik

Structured data iddiası dışarıdan veya site içeriğinden desteklenebilir olmalıdır. “En uzman” gibi ölçülemeyen ifadelerden kaçınılmalıdır. Sertifika, proje ve içerik geçmişi uzmanlığı destekleyebilir. Schema tek başına uzmanlık yaratmaz. Semantic model gerçek kurumsal kimliği yansıtmalıdır.

sameAs Property Nedir?

sameAs aynı entity'nin başka URL'lerdeki güvenilir kimliklerini ilişkilendirmek için kullanılır. Resmi sosyal profiller veya güvenilir entity sayfaları örnek olabilir. Amaç link sayısını artırmak değildir. Kurumsal ve yazar entity'leri için doğrulanmış bağlantılar merkezi registry'de tutulabilir. Yanlış sameAs identity confusion oluşturabilir.

Entity Identity

sameAs entity disambiguation için yardımcı olabilir. Aynı isimli kişi veya kurumları ayırmaya katkı sağlar. URL gerçekten aynı entity'ye ait olmalıdır. Affiliate veya backlink sayfası identity değildir. Review süreci gerekir.

Resmi Sosyal Profiller

Kuruma veya kişiye ait resmi sosyal hesaplar sameAs için uygun olabilir. Username değişiklikleri takip edilmelidir. Taklit hesaplar eklenmemelidir. Profile ownership doğrulanmalıdır. Central registry bakım sağlar.

Güvenilir Harici Entity Sayfaları

Belirli güvenilir harici profil veya entity sayfaları uygun olduğunda kullanılabilir. Her directory entry aynı değerde değildir. Link source identity bilgisini gerçekten desteklemelidir. SEO backlink amacı sameAs kullanım gerekçesi değildir. Liste sınırlı tutulmalıdır.

sameAs Manipülasyonunda En Sık Hatalar

sameAs en sık yanlış kullanılan schema alanlarından biridir. Bazı uygulamalar bu alanı genel link directory gibi kullanır. Başka kişiye ait sosyal profil veya alakasız Wikipedia sayfası eklemek entity kimliğini yanlış temsil eder. Otomatik link extraction bu nedenle güvenilir değildir. sameAs yalnız aynı entity'yi temsil eden doğrulanmış sayfalara bağlanmalıdır.

Link Directory Eklemek

Directory sayfası kurumun kaydını içerse bile her durumda identity kaynağı olarak uygun olmayabilir. SEO link listesi sameAs değildir. Çok sayıda directory URL'si graph'ı şişirir. Resmi ve güvenilir profillere öncelik verilmelidir. Governance policy izin verilen kaynak türlerini tanımlayabilir.

Backlink Sayfası Eklemek

Bir web sayfasının kuruma backlink vermesi aynı entity olduğu anlamına gelmez. sameAs relation semantic identity ifade eder. PR yazıları veya referans sayfaları bu amaçla kullanılmamalıdır. mentions veya citation farklı kavramlardır. Automated SEO tool bu alanı backlink listesiyle doldurmamalıdır.

Alakasız Wikipedia Entity'si

Aynı isimde Wikipedia sayfası yanlış kişi veya kuruma ait olabilir. Entity resolution yapılmalıdır. İsim eşleşmesi tek başına yeterli değildir. Yanlış sameAs ciddi semantic confusion yaratır. Human review gerekir.

Başkasına Ait Sosyal Profil

Benzer kullanıcı adına sahip hesap aynı kişi olmayabilir. Profile ownership doğrulanmalıdır. Otomatik search result eşleşmesi güvenilir değildir. Yanlış profil privacy ve reputation sorunu oluşturabilir. Kurumsal registry yalnız onaylı hesapları saklamalıdır.

Kurumsal İddialar JSON-LD'ye Eklenebilir mi?

Kurumsal iddialar ancak gerçek, doğrulanabilir ve ilgili property ile anlamlı şekilde ifade edilebiliyorsa structured data'ya taşınmalıdır. Marketing sloganı otomatik factual property olmamalıdır. Ödül, sertifika veya belirli sayıların source ve güncellik bilgisi bulunmalıdır. “En iyi” gibi subjektif ifadeler dikkatle ele alınmalıdır. Legal ve corporate communication ekipleri yüksek riskli claim'ler için governance sürecine dahil edilebilir.

Doğrulanabilir Bilgi

Schema'daki kurumsal veri kullanıcı tarafından veya güvenilir kaynakla doğrulanabilir olmalıdır. name, logo ve resmi adres temel örnektir. Dinamik sayıların update kaynağı olmalıdır. Manual copy-paste zamanla drift yaratır. Master data source tercih edilmelidir.

Ödüller

Gerçek ödül varsa uygun property ve context içinde ifade edilebilir. Ödül adı ve veren kurum doğru olmalıdır. Pazarlama metni ödül gibi modellenmemelidir. Eski veya geçersiz iddialar kaldırılmalıdır. Legal review gerekebilir.

Sertifikalar

Sertifikalar gerçek belge ve geçerlilik durumuna dayanmalıdır. Schema vocabulary içinde uygun representation yoksa zorla farklı property kullanılmamalıdır. Visible content ile desteklenmelidir. Expiration takip edilmelidir. CMS field doğrulanmadan yayınlanmamalıdır.

Müşteri Sayısı

Müşteri sayısı sık değişen bir metriktir. Structured data için açık ve uygun property yoksa pazarlama iddiasını zorla modele eklemek gerekmez. Sayfa üzerinde gösteriliyorsa doğruluğu korunmalıdır. Otomatik data source kullanılabilir. Yuvarlanmış sayılar factual precision gibi sunulmamalıdır.

“En İyi” ve “1 Numara” İddiaları

Bu ifadeler çoğu zaman subjektiftir. Bağımsız ve açık metodoloji olmadan factual schema property'ye dönüştürülmemelidir. Marketing copy ile semantic data farklı katmanlardır. Kullanıcıya yanıltıcı impression verilmemelidir. Kurumsal governance bu tür claim'leri review etmelidir.

Review ve AggregateRating Manipülasyonu

Review ve AggregateRating structured data alanındaki en yüksek riskli manipülasyon konularından biridir. Gerçek kullanıcı değerlendirmesi bulunmadan rating üretmekten kaçınılmalıdır. Self-serving değerlendirmeler ile bağımsız kullanıcı feedback'i ayrılmalıdır. Blog içeriğinde yıldız görünümü elde etmek amacıyla rating eklemek doğru değildir. Review kaynağı, görünürlüğü ve doğrulanabilirliği açık olmalıdır.

Gerçek Kullanıcı Değerlendirmeleri

Gerçek kullanıcı review'ları görünür içerikle eşleşmelidir. Rating sayısı ve ortalama gerçek data source'tan hesaplanmalıdır. Silinen review'lar aggregate değeri güncellemelidir. Sahte kullanıcı üretmek ciddi güven sorunudur. Review moderation politikası olmalıdır.

Self-Serving Rating

Kurumun kendi hizmetine verdiği puan kullanıcı değerlendirmesi olarak gösterilemez. Self-serving yapı rich result beklentisiyle kullanılmamalıdır. Review ecosystem ayrı bir kaynağa dayanmalıdır. Kullanıcıya rating'in kaynağı açık olmalıdır. Schema governance bunu yüksek risk olarak sınıflandırabilir.

Sahte Rating

Sahte rating tamamen kaçınılması gereken uygulamadır. Manuel veya otomatik üretilmiş olması fark etmez. Arama görünümü amacıyla gerçek dışı yıldız verisi kullanıcıyı yanıltır. Audit bu property'leri özellikle incelemelidir. Gerekirse tamamen kaldırılmalıdır.

Blog İçeriğinde Yıldız Sonucu Arayışı

Blog yazısına alakasız Review veya AggregateRating eklemek schema type stuffing örneğidir. İçerik gerçekten review formatında olsa bile ilgili structured data gereksinimleri ayrıca değerlendirilmelidir. Genel bilgi yazısı rating taşımaz. Search appearance hedefi semantic doğruluğun önüne geçmemelidir. Bu prensip uzun vadede daha güvenli SEO sağlar.

FAQ Schema Bloglarda Nasıl Yönetilmelidir?

FAQ schema yalnız sayfada gerçek, görünür ve ilgili soru-cevap içeriği bulunuyorsa değerlendirilmelidir. Template seviyesinde her bloga aynı FAQ'yı eklemek içerik özgünlüğünü ve parity'yi bozabilir. Başka sayfadan kopyalanan FAQ bu URL'nin gerçek içeriği değilse kullanılmamalıdır. Ayrıca Schema.org geçerliliği ile Google'ın ilgili feature desteği ayrı değerlendirilmelidir. FAQ verisi CMS içinde görünür içerikle aynı source'tan üretilmelidir.

Sayfada Görünür Soru-Cevap

Soru ve cevap kullanıcı tarafından sayfada erişilebilir olmalıdır. Accordion içinde olması görünürlük açısından farklı olabilir çünkü kullanıcı açabilir. JSON-LD metni rendered içeriğin gerçek karşılığını taşımalıdır. Yanıt değiştiğinde schema otomatik güncellenmelidir. Rich result beklentisiyle fazladan soru yaratılmamalıdır.

Template FAQ

Aynı template FAQ yüzlerce blog sayfasına otomatik basılmamalıdır. Soru gerçekten her sayfanın içeriğiyle ilgiliyse yine görünür UI'da bulunmalıdır. Generic kurumsal sorular contact veya service sayfasına daha uygun olabilir. Blog content model ayrı FAQ field tutabilir. Conditional rendering uygulanmalıdır.

Başka Sayfadan Kopyalanan FAQ

Bir başka URL'deki FAQ'yı yalnız schema içine kopyalamak parity sorununa yol açar. Her page kendi visible content'ini temsil etmelidir. Reusable content kullanılıyorsa HTML tarafında da gerçekten gösterilmelidir. Duplicate content ayrı SEO konusudur. Schema bu içeriği saklamak için kullanılmamalıdır.

Google Feature ve Schema.org Validity Ayrımı

FAQPage Schema.org açısından geçerli olabilir. Ancak Google'ın arama görünümünde bu type'ı nasıl kullandığı ayrı politikaya bağlıdır. Feature availability değişebilir. Schema sırf rich result için eklenmemelidir. Semantic ihtiyaç ve user content öncelikli olmalıdır.

Görünmeyen İçerik Schema'ya Eklenebilir mi?

Teknik identifier gibi kullanıcıya gösterilmeyen alanlarla içerik iddiası taşıyan gizli veriyi birbirinden ayırmak gerekir. @id'nin ekranda görünmesi gerekmez. Fakat FAQ, rating veya açıklama gibi kullanıcı içeriği sayfadaki gerçek deneyimle uyumlu olmalıdır. CMS'te bulunan ancak frontend'de render edilmeyen metni otomatik schema'ya eklemek risklidir. Visible content parity kontrolü kurumsal schema testlerinin önemli parçasıdır.

Visible Content Parity

Structured data ile kullanıcı içeriği anlam açısından eşleşmelidir. Exact HTML string eşitliği her durumda gerekmez. Ancak headline, author ve önemli claim'ler tutarlı olmalıdır. Crawler hem HTML hem JSON-LD çıkarımı yapabilir. Parity score dashboard'a eklenebilir.

Accordion İçerikleri

Accordion içinde kullanıcı tarafından açılabilen içerik sayfanın gerçek parçasıdır. FAQ schema bu sorularla uyumlu olabilir. Client-side lazy load varsa rendered HTML kontrol edilmelidir. Schema sunucuda bulunurken içerik hiç yüklenmiyorsa tutarsızlık olabilir. UX ve technical rendering birlikte değerlendirilmelidir.

CSS ile Gizlenen İçerik

CSS ile tamamen gizlenen metni schema'da görünür içerik gibi sunmak risklidir. Responsive veya accessibility amaçlı hidden içerik ayrı incelenebilir. Amaç arama motoruna kullanıcıdan farklı veri göstermek olmamalıdır. DevTools rendered DOM kontrol edilmelidir. Schema audit hidden content pattern'lerini tespit edebilir.

CMS'te Var Ama Sayfada Yok

CMS alanının dolu olması otomatik schema eligibility anlamına gelmez. Frontend component alanı kullanmıyorsa kullanıcı içeriği görmez. Schema generator frontend render state'ini bilmeli veya ortak content model kullanmalıdır. Feature flag durumları dikkate alınmalıdır. Deployment testleri gerçek URL üzerinde yapılmalıdır.

JSON-LD İçeriğin HTML ile Eşleşmesi Nasıl Kontrol Edilir?

HTML parity kontrolü headline, author, date, image, FAQ ve Organization gibi kritik alanlarda yapılabilir. Automated crawler sayfanın rendered HTML'ini ve JSON-LD graph'ını birlikte parse edebilir. Alanlar normalize edilerek karşılaştırılır. Farklar page type bazında raporlanabilir. Bu yöntem JSON-LD yapılandırılmış veri hataları ve rich results optimizasyonu nasıl yapılır sorusunun en pratik operasyonel cevaplarından biridir.

Headline

H1 veya görünür article headline ile schema headline karşılaştırılabilir. Küçük punctuation farkları normalize edilebilir. Tamamen farklı başlık alarm üretmelidir. CMS title mapping kontrol edilir. SEO meta title ile article headline karıştırılmamalıdır.

Author

Görünür author adı schema author.name ile uyumlu olmalıdır. Ekip adı veya kişi farklıysa hata olabilir. Multiple author sayfalarında array order önemli olmayabilir. Profil linkleri de kontrol edilebilir. CMS author relation source olmalıdır.

Date

Visible publish veya update date schema tarihleriyle karşılaştırılabilir. Timezone farkı normalize edilmelidir. Template deploy sonrası toplu tarih değişimi alarm üretmelidir. Tarih label'ı kullanıcıya açık olmalıdır. Legacy içerikler ayrı rule gerektirebilir.

Image

Featured image ile schema image URL'si eşleştirilebilir. Responsive image farklı boyutları normal olabilir. Canonical asset veya primary image policy belirlenmelidir. Broken URL kontrol edilmelidir. Placeholder detection yapılabilir.

FAQ

Schema soru ve cevapları görünür FAQ bölümünde bulunmalıdır. Text normalization ile karşılaştırma yapılabilir. Client-rendered accordion crawler tarafından render edilmelidir. Eksik soru alarm üretmelidir. Template generic FAQ ayrıca raporlanabilir.

Organization

Kurumsal name ve logo görünür site identity ile çelişmemelidir. Footer veya About page kaynak olabilir. Merkezi registry ile JSON-LD graph karşılaştırılır. Site-wide drift tespit edilir. Rebrand rollout dikkatle izlenir.

JSON-LD Dinamik Olarak Nasıl Üretilir?

Dinamik JSON-LD server-side template, CMS, client-side JavaScript, Google Tag Manager veya edge rendering üzerinden üretilebilir. En güvenilir yaklaşım çoğu kurumsal sitede source data'nın sunucu tarafında mevcut olduğu noktada schema oluşturmaktır. Client-side injection özel koşullarda çalışabilir fakat rendering ve debugging yükü artar. GTM hızlı pilot için kullanılabilir. Uzun vadede dinamik JSON-LD schema markup nasıl oluşturulur ve güncellenir sorusunun cevabı source of truth, validation ve governance ile birlikte verilmelidir.

Server-Side Template

Server-side rendering sırasında CMS verisinden JSON-LD üretilebilir. Kullanıcı ve crawler aynı response içinde schema alır. Serialization framework helper ile güvenli yapılabilir. Template page type'a göre doğru node'ları seçer. Kurumsal ölçek için güçlü temel yaklaşım sunar.

CMS

CMS içerik alanları schema property'lerine map edilebilir. Author relation, publish date ve image doğrudan content modelden gelir. Site-wide Organization ayrı config veya registry'den alınır. Validation publish workflow'a eklenebilir. Editörler raw JSON yazmak zorunda kalmaz.

Client-Side JavaScript

Client-side script runtime'da JSON-LD ekleyebilir. Veri yalnız tarayıcıda mevcutsa kullanılabilir. Rendering ve script failure riski vardır. Hydration değişiklikleri duplicate script oluşturabilir. Server-side seçenek mümkünse genellikle daha yönetilebilirdir.

Google Tag Manager

GTM Custom HTML tag ile JSON-LD enjekte edebilir. Hızlı pilot veya developer kaynağı sınırlı durumda faydalı olabilir. Trigger yanlışsa farklı page type'lara schema basılabilir. Version drift ve debugging zorlaşabilir. Uzun vadeli enterprise governance için source code entegrasyonu çoğu zaman daha kontrollüdür.

Edge Rendering

Edge middleware response üzerine schema ekleyebilir. Merkezi route metadata kullanılıyorsa bazı mimarilerde faydalıdır. CMS data erişimi latency yaratabilir. Cache ve personalization dikkatle tasarlanmalıdır. Edge katman schema source of truth olmamalıdır.

CMS ile JSON-LD Manipülasyonu

CMS tabanlı schema yönetiminde temel fikir içerik alanlarını semantic property'lere kontrollü biçimde map etmektir. Her alan zorunlu olarak JSON-LD'ye aktarılmaz. Conditional property, template variable, default value ve validation katmanları gerekir. Editörler structured data teknik detayını yönetmek yerine gerçek içerik verisini doğru girmelidir. Schema generator bu veriyi güvenli biçimde serialize edip graph oluşturmalıdır.

CMS Field Mapping

Her schema property hangi CMS alanından beslendiğini açıkça tanımlamalıdır. headline page title'dan, author author relation'dan gelebilir. Mapping dokümante edilmelidir. Field rename breaking change olabilir. Unit test mapping'i korur.

Conditional Property

Veri bulunmadığında property koşullu olarak atlanabilir. Boş sameAs array üretmek gereksizdir. Guest author için farklı relation kullanılabilir. Page type'a göre property set değişebilir. Conditional logic test edilmelidir.

Template Variables

Template variable schema generation sırasında gerçek content data sağlar. Variable type güvenli olmalıdır. String içine manuel JSON eklemekten kaçınılmalıdır. Serializer kullanılması injection riskini azaltır. Null değerler ayrıca ele alınmalıdır.

Default Values

Default value yalnız gerçekten evrensel bilgi için kullanılmalıdır. Publisher Organization @id buna örnek olabilir. Author name gibi içerik özel alanlarda generic default kullanmak yanlış olabilir. Fallback değeri gerçek anlam taşımıyorsa property atlanmalıdır. Default source dokümante edilmelidir.

Validation

CMS publish öncesi required field kontrolleri yapılabilir. Schema generation sonrası JSON parse ve semantic validation çalıştırılabilir. Invalid content entry editöre geri bildirim verebilir. Bulk content import ayrıca taranmalıdır. Validation sonucunu deployment log'unda saklamak faydalıdır.

CMS Alanlarından Schema Property Nasıl Üretilir?

CMS alanlarının schema property'lerine dönüşümü açık mapping sözleşmesine dayanmalıdır. Page Title headline, Excerpt description ve Featured Image image alanını besleyebilir. Author relation doğrudan author entity'sine bağlanabilir. Publish ve updated tarihleri doğru timestamp alanlarından alınmalıdır. Bu yaklaşım manuel schema kopyalamaktan çok daha güvenilir ve ölçeklenebilirdir.

Page Title → headline

Page title gerçek article headline ise doğrudan kullanılabilir. SEO title ayrıysa karıştırılmamalıdır. Visible H1 ile eşleşme kontrol edilir. Localization her dil entry'sinden gelir. Empty title publish'i engelleyebilir.

Excerpt → description

Excerpt editoryal özet olarak kullanılabilir. HTML içeriyorsa plain text'e dönüştürülmelidir. Otomatik truncate gerekirse karakter sınırı değil anlam bütünlüğü dikkate alınmalıdır. Empty excerpt durumunda property atlanabilir veya kontrollü fallback kullanılabilir. Meta description ile aynı olmak zorunda değildir.

Author → author

Author relation CMS entity reference olmalıdır. Free-text name duplicate riskini artırır. Person @id helper üzerinden üretilir. Multiple author varsa array kullanılabilir. Deleted author kayıtları migration sürecinde ele alınmalıdır.

Publish Date → datePublished

Publish timestamp gerçek ilk yayın tarihinden gelmelidir. Created date kullanılmamalıdır. Timezone normalization uygulanır. ISO 8601 serializer kullanılır. Migration original publish value'yu korumalıdır.

Updated Date → dateModified

Updated Date bütün teknik değişiklikleri değil editoryal değişiklikleri yansıtmalıdır. CMS revision modeli bu ayrımı sağlayabilir. Auto-save timestamp kullanılmamalıdır. User-visible update date ile eşleşmelidir. Policy merkezi belirlenmelidir.

Featured Image → image

Featured image asset URL'si schema image olarak kullanılabilir. Image CDN transformation URL'si stabil olmalıdır. Broken asset publish sırasında yakalanmalıdır. Placeholder görsel kullanılmamalıdır. Alt text schema image property yerine görsel accessibility alanında yönetilmelidir.

Schema Generation İçin Null Handling

Null handling dinamik schema üretiminin en sık gözden kaçan konularından biridir. Boş string, null ve undefined farklı programlama ortamlarında farklı davranabilir. Zorunlu bilgi eksikse sayfayı geçerli göstermek için uydurma değer üretilmemelidir. Çoğu optional property veri yoksa hiç üretilmeyebilir. Validation layer missing required data için açık hata üretmelidir.

Boş Property

Boş string değerli property genellikle anlam taşımaz. name:"" gibi alanlardan kaçınılmalıdır. Serializer öncesi validation boş değerleri filtreleyebilir. Editoryal required field ise publish engellenebilir. Data quality dashboard boş alanları raporlayabilir.

Null

Null gerçek veri olmadığını gösterir. JSON içinde teknik olarak geçerli olsa bile semantic property için kullanımı gereksiz olabilir. Optional alan çoğu durumda tamamen atlanabilir. Null handling library merkezi olmalıdır. Farklı template'ler farklı davranmamalıdır.

Undefined

JavaScript'te undefined JSON.stringify sırasında farklı davranabilir. Array ve object context'i önemlidir. Schema generator output'u serialization sonrası test etmelidir. Raw template interpolation kullanılmamalıdır. TypeScript type safety yardımcı olabilir.

Eksik Zorunlu Alan

Required data yoksa sistem fallback uydurmamalıdır. Editorial workflow eksik alanı kullanıcıya bildirmelidir. Bazı durumlarda schema node tamamen üretilmeyebilir. Rich feature eligibility düşebilir ama yanlış data üretmekten daha iyidir. Quality score eksik alanı ölçebilir.

Property'yi Koşullu Üretmek

Optional value doluysa property eklenir, değilse atlanır. Bu logic reusable helper ile uygulanabilir. Nested object boş kalıyorsa parent relation da kaldırılabilir. Unit test null kombinasyonlarını kapsamalıdır. Schema diff unexpected removal'ı gösterebilir.

CMS Verisi Güvenilir Değilse Ne Yapılmalı?

CMS içindeki her alan otomatik olarak güvenilir structured data kaynağı kabul edilmemelidir. Free-text girişler yanlış URL, HTML veya doğrulanmamış claim içerebilir. Validation, sanitization ve editorial approval katmanları gerekir. Fallback yalnız güvenli ve gerçek değer varsa kullanılmalıdır. Kurumsal schema generator CMS verisini olduğu gibi değil belirlenmiş data contract üzerinden işlemelidir.

Validation Layer

Validation type, format ve business rule kontrol eder. URL HTTPS olmalı veya tarih geçerli formatta bulunmalıdır. Person relation gerçek author entity'ye bağlanmalıdır. Validation failure loglanmalıdır. High-severity error deployment'ı durdurabilir.

Sanitization

CMS string içinde HTML veya kontrol karakterleri bulunabilir. Plain text gerektiren alanlar temizlenmelidir. Sanitization içerik anlamını değiştirmemelidir. URL alanlarında protocol ve host doğrulaması yapılabilir. Güvenli serializer son adım olmalıdır.

Editorial Approval

Yazar ve claim bilgileri editoryal onay gerektirebilir. Schema editörü raw JSON düzenlemek zorunda kalmamalıdır. Onay gerçek CMS alanları üzerinden yapılır. Change log reviewer bilgisini saklayabilir. High-risk property'ler ayrı approval isteyebilir.

Fallback Değeri

Fallback yalnız veri gerçekten varsayılan olabiliyorsa kullanılmalıdır. Organization publisher @id gibi site-wide sabitler uygun örnektir. Missing author için “Admin” uydurmak doğru değildir. Eksik veri açıkça hata olarak ele alınmalıdır. Fallback policy dokümante edilmelidir.

JSON-LD ve Input Sanitization

JSON-LD üretimi kullanıcı veya CMS girdisini script içine yerleştirdiği için güvenli serialization önemlidir. Quote escaping manuel yapılmamalıdır. HTML içeren alanlar doğru biçimde plain text veya güvenli değer haline getirilmelidir. JSON injection ve script breaking riskleri framework serializer ile azaltılabilir. Security review schema generator kodunu normal application code kadar ciddiye almalıdır.

Quote Escaping

Başlık içinde tırnak bulunabilir. Manuel string concatenation JSON syntax'ını bozabilir. JSON.stringify veya server-side serializer kullanılmalıdır. Escape işlemi framework'e bırakılmalıdır. Test set özel karakter örnekleri içermelidir.

HTML İçeren CMS Alanları

Description alanına rich text HTML doğrudan taşınmamalıdır. Gerekliyse text extraction uygulanır. Entity encoding iki kez yapılmamalıdır. Script tag veya inline markup güvenlik riski oluşturabilir. Sanitization library kullanılmalıdır.

JSON Injection Riski

Kontrolsüz kullanıcı girdisi JSON-LD script bağlamını bozabilir. Özellikle script closing sequence ve özel karakterler önemlidir. Safe serializer bu riskleri yönetmelidir. CMS güvenilir kabul edilse bile compromised account ihtimali düşünülmelidir. CSP ve security controls ayrıca destek sağlar.

Güvenli Serialization

Structured object önce uygulama belleğinde oluşturulmalıdır. Sonra güvenilir serializer ile JSON string'e çevrilmelidir. Handwritten JSON template azaltılmalıdır. Serialization çıktısı parse testinden geçirilmelidir. Framework-specific escape önerileri takip edilmelidir.

JSON-LD Google Tag Manager ile Eklenebilir mi?

Teknik olarak GTM üzerinden JSON-LD eklemek mümkündür ve bazı pilot projelerde pratik olabilir. Custom HTML tag içinde script oluşturulabilir. Trigger doğru page type'a sınırlandırılmalıdır. Dynamic variable kullanılıyorsa data doğruluğu test edilmelidir. Uzun vadeli kurumsal yönetimde GTM'nin deployment, ownership ve debugging riskleri ayrıca değerlendirilmelidir.

Custom HTML Tag

Custom HTML tag JSON-LD script oluşturabilir. Raw string yerine güvenli data üretimi tercih edilmelidir. Tag version control GTM container üzerinden yapılır. Duplicate schema script riski vardır. Site source code ile çakışma kontrol edilmelidir.

Trigger

Trigger hangi URL veya page type'ta schema çalışacağını belirler. URL pattern tek başına kırılgan olabilir. Data layer page type daha güvenli sinyal sağlayabilir. Yanlış trigger bütün siteye BlogPosting basabilir. Preview mode ile test yapılmalıdır.

Dynamic Variable

Dynamic variable headline veya author gibi değerleri DOM'dan çekebilir. DOM selector değişirse schema bozulabilir. Data layer veya structured CMS payload daha güvenilirdir. Null handling uygulanmalıdır. Client timing problemi test edilmelidir.

Deployment

GTM publish ayrı deployment kanalıdır. Developer source deployment'ından bağımsız değişebilir. Change approval süreci kurulmalıdır. Container version release note saklanmalıdır. Production test publish sonrası yapılmalıdır.

Validation

GTM schema rendered DOM üzerinde kontrol edilmelidir. Rich Results Test veya crawler JavaScript render etmelidir. Trigger olmayan sayfalar da negative test olarak incelenmelidir. Duplicate entity alarmı kurulabilir. Monitoring yalnız ilk deploy günüyle sınırlı olmamalıdır.

GTM ile Schema Manipülasyonunun Avantajları

GTM geliştirici deployment döngüsüne girmeden hızlı schema pilotları yapmayı sağlayabilir. Küçük sitelerde veya kısa testlerde zaman kazandırır. Koşullu trigger ile belirli URL grupları hedeflenebilir. SEO ekibi teknik denemeyi daha hızlı yürütebilir. Buna rağmen kalıcı çözüm seçiminde uzun vadeli ownership ve version drift göz önünde bulundurulmalıdır.

Hızlı Deployment

Container publish uygulama release'i beklemez. Pilot birkaç URL'de hızla denenebilir. Search feature uygunluğu ölçülebilir. Rollback kolay olabilir. Ancak change governance yine gerekir.

Developer Bağımlılığını Azaltmak

Basit schema testleri SEO ekibi tarafından yürütülebilir. Developer backlog bekleme süresi azalabilir. Fakat complex entity graph GTM içinde zorlaşır. Teknik ownership tamamen ortadan kalkmaz. Security ve performance review yine gerekir.

Pilot Test

Yeni schema type küçük URL grubunda test edilebilir. Search Console etkisi gözlenebilir. Validation error düşük riskle yakalanır. Pilot sonrası source code entegrasyon kararı verilebilir. Test sonucu dokümante edilmelidir.

Koşullu Trigger

Belirli template veya route yalnız hedeflenebilir. Page type data layer kullanmak URL regex'ten daha güvenilirdir. Trigger unit test benzeri kontrol gerektirir. Negative page type'lar test edilmelidir. Migration sonrası trigger pattern güncellenmelidir.

GTM ile Schema Yönetiminin Riskleri

GTM schema yönetiminde trigger hatası, version drift ve debugging güçlüğü önemli risklerdir. Analytics tag'leriyle aynı container içinde structured data logic'i karışabilir. DOM bağımlı variable'lar frontend değişikliğinde sessizce bozulabilir. Source code repository'sindeki test pipeline bu değişiklikleri göremeyebilir. Kurumsal sitelerde GTM daha çok pilot veya özel geçiş çözümü olarak değerlendirilmelidir.

Trigger Hatası

Yanlış regex hizmet sayfasına BlogPosting basabilir. Data layer yanlışsa daha geniş sorun oluşur. Preview mode bütün page type'larda test edilmelidir. Production crawler schema distribution kontrol edebilir. Unexpected type alarm üretmelidir.

Yanlış Sayfada Schema

Page intent ile schema type uyuşmazlığı semantic sorundur. Her URL'ye aynı GTM tag'ini basmak sık hatadır. Page-type assertion kullanılmalıdır. Negative test özellikle önemlidir. Wrong-type coverage dashboard'da izlenebilir.

Version Drift

Source code schema ve GTM schema farklı zamanlarda güncellenebilir. Duplicate veya çelişkili node oluşabilir. Change ownership açık olmalıdır. GTM change log merkezi release kaydıyla ilişkilendirilebilir. Tek source prensibi tercih edilmelidir.

Analytics Tag'leriyle Karışıklık

GTM çoğu kurumda analytics ve marketing tag'leri taşır. Schema logic aynı container içinde görünürlüğünü kaybedebilir. Folder ve naming standardı kullanılmalıdır. SEO owner approval eklenebilir. Container permission ayrımı yapılabilir.

Debugging Zorluğu

Schema yalnız belirli trigger koşullarında oluşabilir. Client timing ve consent mode etkileyebilir. Rendered HTML crawler kullanmak gerekir. Source view yeterli olmayabilir. Incident playbook GTM kontrol adımını içermelidir.

Server-Side JSON-LD mi GTM mi?

Kalıcı kurumsal uygulamalarda server-side JSON-LD çoğu zaman daha kontrol edilebilir ve test edilebilir bir temel sağlar. GTM ise hızlı pilot veya küçük kapsamlı testlerde faydalı olabilir. Küçük site operasyon kapasitesine göre farklı seçim yapabilir. Uzun vadede schema source of truth'un içerik ve uygulama katmanına yakın olması bakım avantajı getirir. Governance ihtiyacı büyüdükçe source code, CMS mapping ve automated test yaklaşımı daha güçlü hale gelir.

Küçük Site

Küçük sitede GTM hızlı çözüm olabilir. Ancak DOM extraction yerine mümkünse güvenilir page data kullanılmalıdır. Schema kapsamı sınırlı tutulmalıdır. Teknik borç büyümeden source code'a taşınabilir. Manual monitoring yeterli olabilir.

Kurumsal Site

Kurumsal site çok sayıda template ve owner içerir. Server-side generator merkezi kontrol sağlar. CI/CD testleri çalıştırılabilir. Entity registry entegrasyonu kolaylaşır. GTM yalnız belirli pilotlarda kullanılabilir.

Hızlı Pilot

Pilot 5 veya 10 URL üzerinde GTM ile uygulanabilir. Search eligibility ve validation gözlenir. Başarılı sonuç production architecture kararını besler. Pilot kodu kalıcı çözüm olmak zorunda değildir. Exit criteria önceden belirlenmelidir.

Uzun Vadeli Governance

Source control ve code review uzun vadede güçlü avantaj sağlar. Schema template versionlanabilir. Automated regression test uygulanabilir. Data owner ve developer owner açık hale gelir. Bu nedenle enterprise yaklaşımda server-side çözüm genellikle daha yönetilebilir olur.

React ve Next.js Sitelerde JSON-LD

React ve Next.js sitelerde JSON-LD server veya client tarafında üretilebilir. SEO açısından mümkün olduğunda server-rendered output daha tahmin edilebilir yapı sağlar. SSR ve SSG içerik verisini build veya request anında schema'ya dönüştürebilir. Server Components yeni mimarilerde data mapping'i sunucu tarafında tutmayı kolaylaştırır. Serialization ve script escape konusu özellikle kullanıcı veya CMS metni kullanıldığında dikkatle yönetilmelidir.

SSR

Server-Side Rendering her request'te HTML ve JSON-LD üretebilir. CMS verisi request sırasında alınabilir. Canonical ve route metadata aynı render context içinde bulunur. Response source'ta schema görülebilir. Cache policy performansı etkiler.

SSG

Static Site Generation build sırasında sayfa ve schema üretir. Blog içerikleri için oldukça uygundur. CMS değişikliği rebuild gerektirir. dateModified build timestamp olmamalıdır. Incremental regeneration kullanılıyorsa content timestamp korunmalıdır.

Server Components

Server Components data fetch ve rendering logic'ini sunucuda tutabilir. Schema object server tarafında oluşturulabilir. Client bundle gereksiz büyümez. Shared schema library kullanılabilir. Framework upgrade regression test gerektirir.

Client-Side Injection

Client-side injection teknik olarak mümkündür. Ancak JavaScript failure veya hydration timing sorunları oluşabilir. Duplicate script üretimi kontrol edilmelidir. Browser-rendered crawler ile test yapılmalıdır. Server-side seçenek varsa daha sade olabilir.

Escape ve Serialization

JSON-LD script içine CMS string'leri güvenli serialize edilmelidir. Raw dangerouslySetInnerHTML kullanımı ekstra dikkat gerektirir. JSON.stringify çıktısı framework recommendation'larına göre escape edilmelidir. XSS riski yalnız schema diye küçümsenmemelidir. Security test özel karakterleri kapsamalıdır.

Vue ve Nuxt Sitelerde JSON-LD

Vue ve Nuxt projelerinde JSON-LD server rendering veya dynamic head yönetimi üzerinden üretilebilir. CMS verisi content modelden alınır. Page type ve route metadata schema generator'a aktarılır. SSR kullanıldığında crawler ilk response içinde structured data görebilir. Head management çözümü upgrade edildiğinde regression test yapılmalıdır.

Server Rendering

Nuxt SSR içerik ve schema'yı server tarafında üretebilir. CMS payload aynı render cycle içinde kullanılabilir. Canonical source route helper'dan gelir. Client dependency azalır. Cache invalidation content update ile uyumlu olmalıdır.

Dynamic Meta

Dynamic head sistemi JSON-LD script ekleyebilir. Page title ve canonical ile aynı data source kullanılabilir. Duplicate head tag kontrol edilmelidir. Route change SPA modunda eski script temizlenmelidir. Automated browser test faydalıdır.

CMS Integration

Headless CMS content entry Nuxt uygulamasına data sağlar. Mapping layer schema property'lerini üretir. Author ve Organization registry ayrı source olabilir. Null handling uygulanır. Publish preview ortamında validation yapılabilir.

Headless CMS ile Schema Yönetimi

Headless CMS mimarisinde içerik modeli frontend'den ayrıdır ve bu durum schema yönetimi için güçlü fırsat sunar. Content model semantic alanları daha açık tanımlayabilir. Schema mapping layer CMS verisini graph node'larına dönüştürür. Frontend yalnız doğrulanmış graph'ı render eder. Validation ve entity registry merkezi servislerle bağlanabilir.

Content Model

Blog content type headline, excerpt, author ve tarih alanları taşımalıdır. SEO ve schema için aynı gerçek data kullanılmalıdır. Free-text entity girişleri azaltılmalıdır. Relation field'lar tercih edilmelidir. Migration script schema mapping'i dikkate almalıdır.

Schema Mapping Layer

Mapping layer CMS field'larını Schema.org property'lerine dönüştürür. Page type'a göre node seçer. Null handling ve normalization burada yapılır. Mapping versionlanabilir. Unit test fixture'ları kullanılır.

Frontend Template

Frontend hazır graph'ı script olarak render edebilir. Business logic mümkün olduğunca generator'da kalır. Template yalnız page-level relation ekleyebilir. Duplicate schema oluşmamalıdır. Rendering framework güvenli serialization kullanmalıdır.

Graph Generator

Graph generator Organization, WebSite ve page entity'lerini birleştirir. @id helper merkezi kullanılır. Duplicate node deduplication yapılabilir. Schema type page intent'e göre seçilir. Output deterministic olmalıdır.

Validation

Generator çıktısı JSON parse edilmelidir. Schema vocabulary ve business rule testleri çalıştırılır. Required page type assertion yapılır. Canonical mismatch kontrol edilir. Validation başarısızsa preview veya deployment uyarı verir.

Schema Source of Truth Ne Olmalıdır?

Schema'nın tek bir genel source of truth'u yoktur çünkü farklı entity verileri farklı sistemlerden gelir. Organization verisi master data'dan, author verisi CMS profilinden, article verisi content entry'den ve URL verisi routing veya canonical servisinden alınabilir. Önemli olan her property için birincil kaynağın açıkça tanımlanmasıdır. Aynı veri birden fazla sistemde manuel tutulmamalıdır. Bu yaklaşım Blog ve Kurumsal İçeriklerde JSON-LD Schema Manipülasyonu süreçlerini daha güvenilir hale getirir.

Organization Verisi

Organization verisi merkezi ve kontrollü olmalıdır. Corporate master data veya config registry kullanılabilir. name, logo ve sameAs gibi alanlar buradan gelir. Content editor her yazıda kurum adı girmemelidir. Rebrand tek kaynaktan yönetilmelidir.

Master data

Master data kurum kimliğinin güvenilir kaynağıdır. Değişiklik approval gerektirebilir. Schema generator read-only olarak kullanabilir. Version ve last review date tutulabilir. Farklı uygulamalar aynı entity verisini paylaşabilir.

Author Verisi

Author bilgisi CMS profile entity'den gelebilir. name, bio, URL ve sameAs burada tutulur. İçerik author id referansı taşır. Duplicate profile kontrolü yapılır. Profile deletion policy eski içerikleri korumalıdır.

CMS profile

CMS profile editör ve yazar ekiplerinin yönetebildiği kontrollü kaynaktır. Required field tanımlanabilir. Social link doğrulaması yapılabilir. ProfilePage aynı veriyi kullanır. Schema drift azalır.

Article Verisi

Article data content entry'nin kendisinden gelmelidir. Headline, description ve tarihler burada bulunur. Featured image relation kullanılabilir. Category ve topic metadata ayrıca saklanabilir. Revision history değişiklikleri izler.

CMS content entry

Content entry yazının ana kaydıdır. Schema generator published revision'ı kullanmalıdır. Draft değer production schema'ya sızmamalıdır. Locale ayrı content variant olabilir. Update event revalidation tetikleyebilir.

URL Verisi

URL verisi CMS slug alanından tek başına türetilmemelidir. Routing ve canonical kuralları hostname, locale ve slash davranışını belirler. Schema canonical service'i kullanmalıdır. Redirect mapping migration sırasında önemlidir. Query parameter normalization yapılmalıdır.

Routing/canonical service

Canonical service URL üretiminin tek kaynağıdır. HTML canonical ve JSON-LD aynı helper'ı kullanabilir. Host migration burada yönetilir. Hreflang URL'leri de aynı sistemden gelebilir. Testler farklı locale ve route örneklerini kapsar.

Schema Drift Nedir?

Schema drift, aynı entity veya page type için structured data değerlerinin zaman içinde farklı template ve sistemlerde tutarsız hale gelmesidir. Aynı Organization farklı isim, logo, URL, @id veya sameAs listesiyle üretilebilir. Bu durum manuel copy-paste ve birden fazla source of truth nedeniyle sık görülür. Merkezi entity registry ve shared schema library drift riskini azaltır. Dashboard site-wide entity consistency ölçebilir.

Aynı Organization İçin Farklı İsim

Kurum adı bir sayfada kısa, diğerinde legal form ile gelebilir. Bu fark intentional değilse drift'tir. Master data tek display name tanımlamalıdır. Legal name gerekiyorsa ayrı property kullanılabilir. Automated comparison farkı raporlayabilir.

Farklı Logo

Eski logo asset'i bazı template'lerde kalabilir. Campaign logo yanlışlıkla organization.logo olabilir. Registry tek resmi asset belirlemelidir. CDN migration sonrası URL'ler güncellenmelidir. Image status check uygulanmalıdır.

Farklı URL

www, HTTP veya eski domain farklı Organization URL'leri yaratabilir. Canonical helper kullanmak gerekir. Redirect edilen URL source olarak tutulmamalıdır. Migration report eski hostları taramalıdır. URL normalization merkezi olmalıdır.

Farklı @id

Aynı kurum #organization ve #org gibi farklı id'lerle üretilebilir. Bu durum farklı entity gibi yorumlanabilir. Naming standard tek olmalıdır. Unit test expected @id doğrular. Historical template'ler migrate edilmelidir.

Farklı sameAs

Bazı sayfalarda eski sosyal profil bulunabilir. Manual page-level sameAs entry drift oluşturur. Merkezi registry doğrulanmış link listesi tutmalıdır. Broken URL check yapılmalıdır. Değişiklik owner approval gerektirebilir.

Schema Drift Nasıl Önlenir?

Schema drift'i önlemek için merkezi entity registry, shared component, ortak schema generator ve automated test birlikte kullanılabilir. Aynı kurum veya yazar verisi farklı template'lerde manuel yazılmamalıdır. Deployment sonrası crawler entity consistency kontrolü yapmalıdır. Change log büyük entity değişikliklerini kaydetmelidir. Governance owner drift alarmının kimin tarafından çözüleceğini belirlemelidir.

Merkezi Entity Registry

Registry entity id, type ve canonical data saklar. Organization ve Person gibi site-wide node'lar burada tutulabilir. Tek source of truth sağlar. API veya config olarak kullanılabilir. Access control gerektirir.

Shared Component

Schema rendering shared component üzerinden yapılabilir. Farklı page template'ler aynı helper'ları kullanır. Bug fix tek yerde uygulanır. Version controlled olur. Component API semantic contract gibi yönetilir.

Schema Generator Library

Generator library page data'dan graph üretir. TypeScript veya başka dilde yazılabilir. Mapping, normalization ve null handling içerir. Unit test kapsamı yüksek tutulmalıdır. Package version ile template release takip edilir.

Automated Test

Automated test JSON parse, @type ve @id kontrol edebilir. Canonical mismatch yakalanabilir. Entity duplication raporlanabilir. Page type assertion uygulanabilir. CI/CD deployment'ı bloklayabilir.

Entity Registry Nedir?

Entity registry kurumun structured data'da tekrar kullanılan önemli entity'lerini merkezi olarak yöneten kayıt sistemidir. Entity ID, type, canonical URL, source system, owner ve last review date gibi alanlar tutulabilir. Organization, WebSite ve önemli Person entity'leri için özellikle faydalıdır. Registry semantic identity ile content entry'yi birbirinden ayırır. Büyük kurumsal sitelerde schema governance için önemli altyapı haline gelebilir.

Entity ID

Entity ID stabil @id değerini temsil eder. Tek entity için zaman içinde değişmemelidir. Naming policy'ye göre üretilir. Duplicate registry kaydı engellenmelidir. Migration özel approval gerektirebilir.

Type

Type entity'nin Organization, Person veya farklı bir tür olduğunu belirtir. Schema mapping type'a göre property set seçebilir. Yanlış type değişikliği breaking change olabilir. Review gerekir. Type history saklanabilir.

Canonical URL

Entity'nin kullanıcıya sunulan ana URL'si saklanabilir. Person için profile, Organization için homepage olabilir. Redirect durumları izlenmelidir. URL ve @id ilişkisi açık tutulmalıdır. Migration mapping registry'ye yazılabilir.

Source System

Verinin hangi sistem tarafından yönetildiği bilinmelidir. Organization master data, Person CMS olabilir. Ownership conflict önlenir. Data sync sorunu kolay teşhis edilir. Registry lineage sağlar.

Owner

Her entity data'sından sorumlu ekip veya rol bulunmalıdır. Person için editorial, Organization için corporate communication olabilir. Teknik schema owner farklı olabilir. RACI bu ayrımı açıklar. Review reminder owner'a gönderilebilir.

Last Review Date

Entity verisinin son doğrulama tarihi tutulabilir. Uzun süre review edilmemiş social profile veya logo alarm üretebilir. Periyodik governance süreci oluşturulur. Otomatik güncelleme review yerine geçmez. High-risk entity'ler daha sık kontrol edilebilir.

Schema Template Versioning Nasıl Yapılır?

Schema template'leri uygulama kodu gibi versionlanmalıdır. BlogPosting v1 ve v2 farklı mapping veya graph yapısı taşıyabilir. Breaking change migration planı gerektirir. Deprecated template belirli sürede kaldırılmalıdır. Version bilgisi source control ve change log içinde açık şekilde tutulmalıdır.

BlogPosting v1

İlk template temel headline, author ve tarih alanlarını içerebilir. Production davranışı referans olur. Test fixture saklanmalıdır. Yeni version ile diff karşılaştırılır. Old URLs inventory bilinir.

BlogPosting v2

Yeni version entity graph veya property mapping geliştirebilir. Pilot URL grubunda test edilmelidir. Search Console trend izlenir. Schema diff expected değişiklikleri göstermelidir. Full rollout kontrollü yapılır.

Breaking Change

@id naming veya page type değişikliği breaking change olabilir. Entity continuity etkilenebilir. Migration planı ve redirect mapping gerekebilir. Downstream crawler ve testler güncellenmelidir. SEO owner approval alınmalıdır.

Migration

Migration eski ve yeni template'leri belirli dönemde birlikte yönetebilir. URL segmentasyonu yapılır. Validation her grupta çalışır. Rollback hazırlığı bulunur. Completion sonrası legacy code kaldırılır.

Deprecated Template

Deprecated template yeni içerikte kullanılmamalıdır. Mevcut sayfalar migration backlog'una alınır. End date belirlenmelidir. Documentation kullanım dışı olduğunu açıklar. Monitoring old version coverage ölçebilir.

Schema Change Log Nasıl Tutulur?

Schema change log yapılan semantic ve teknik değişikliklerin izlenmesini sağlar. Tarih, değişen property, gerekçe, developer ve SEO owner bilgileri kaydedilebilir. Bu kayıt incident ve Search Console değişimlerini açıklamada çok değerlidir. Template version ile ilişkilendirilmelidir. Büyük kurumlarda release note sürecine entegre edilebilir.

Değişiklik Tarihi

Deployment veya effective date kaydedilmelidir. Search Console trend ile eşleştirme kolaylaşır. Timezone standardı kullanılmalıdır. Planned ve actual tarih ayrılabilir. Rollback tarihi ayrıca tutulabilir.

Değişen Property

Added, removed veya modified property açıkça yazılmalıdır. “Schema update” gibi genel ifade yeterli değildir. @id değişikliği özel olarak işaretlenmelidir. Page type kapsamı belirtilmelidir. Diff link eklenebilir.

Gerekçe

Değişikliğin neden yapıldığı açıklanmalıdır. Bug fix, migration veya new feature gibi kategori kullanılabilir. Search guideline değişikliği varsa referans eklenebilir. Technical debt azaltımı da gerekçe olabilir. Sonradan karar geçmişi anlaşılır olur.

Developer

Kodu uygulayan kişi veya ekip kaydedilebilir. Bu bilgi sorumluluk paylaşımı için kullanılır. Blame amacı taşımamalıdır. Code review link'i eklenebilir. Ownership transfer kolaylaşır.

SEO Owner

Semantic requirement ve acceptance kriterinden sorumlu kişi belirtilmelidir. Validation sonucu onaylayabilir. Search feature requirement kontrol eder. Developer ile birlikte rollout kararı verir. RACI ile rol tanımlanır.

Çok Dilli Kurumsal Bloglarda JSON-LD

Çok dilli bloglarda her locale kendi headline, description, canonical ve inLanguage değerine sahip olmalıdır. Author ve publisher entity'leri dil sürümleri arasında aynı kimliği koruyabilir. Lokal URL'ler hreflang yapısıyla uyumlu olmalıdır. Cross-language @id stratejisi page entity ve global entity için ayrı düşünülmelidir. Content translation workflow schema translation mapping'ini de içermelidir.

inLanguage

inLanguage sayfa içeriğinin dilini belirtir. CMS locale güvenilir source olabilir. Dil kodları standardize edilmelidir. Fallback locale yanlış schema üretmemelidir. Page-level value her URL için doğru olmalıdır.

Lokal Headline

Her dil sayfası kendi görünür headline değerini kullanmalıdır. Ana dil başlığı diğer locale schema'sına taşınmamalıdır. Translation CMS field source'tur. H1 parity kontrol edilir. Missing translation publish policy ile yönetilir.

Lokal Description

Description ilgili dilde olmalıdır. Auto-translation review gerekebilir. Meta description ile aynı olması zorunlu değildir. Empty locale fallback risklidir. Schema kullanıcıya gösterilen dil deneyimiyle uyumlu olmalıdır.

Author

Yazar aynı kişi ise Person @id global olarak korunabilir. Name transliteration gerekmedikçe aynı kalabilir. Bio profile page lokalize olabilir. Author url locale-specific veya global olabilir. Naming policy dokümante edilmelidir.

Publisher

Global publisher Organization aynı @id ile kullanılabilir. Yerel legal entity farklıysa architecture değişebilir. Kurum adı brand standardına göre gösterilir. Local office publisher olarak otomatik kullanılmamalıdır. Entity ownership doğru modellenmelidir.

Lokal Canonical

Her dil URL'si kendi self-canonical değerini taşımalıdır. JSON-LD url ve @id tabanı buna uymalıdır. Hreflang alternate relation ayrı mekanizmadır. Language prefix route helper üzerinden üretilir. Cross-locale canonical hatası ciddi index sorunu oluşturabilir.

Hreflang ile JSON-LD Nasıl Uyumlandırılır?

Hreflang ve JSON-LD farklı amaçlara hizmet eder fakat URL ve dil modelinin tutarlı olması gerekir. Her dil için ayrı URL ve doğru inLanguage kullanılmalıdır. Page-level @id lokal canonical'a dayanabilir. Global Organization entity'si diller arasında aynı kalabilir. Migration veya locale değişikliği iki sistemi birlikte test etmelidir.

Her Dil İçin Ayrı URL

Locale sayfaları farklı canonical URL taşır. Hreflang bunları alternate olarak ilişkilendirir. JSON-LD page URL ilgili locale'i göstermelidir. Tek canonical'a bütün dilleri bağlamak doğru değildir. Routing service source olmalıdır.

Her Dil İçin Doğru inLanguage

tr, en veya uygun BCP 47 kodu kullanılabilir. Locale fallback yanlış dili üretmemelidir. CMS content locale ile route locale karşılaştırılmalıdır. Automated crawler language mismatch bulabilir. Localization pipeline test edilmelidir.

Cross-Language @id Problemleri

Page ve BlogPosting @id locale URL'ye bağlıysa her dil sürümü ayrı identifier taşıyabilir. Organization gibi global entity aynı kalabilir. Article translation aynı conceptual work olarak farklı modeling gerektirebilir. Kurum basit ve tutarlı policy seçmelidir. Rastgele locale mix önlenmelidir.

Organization Entity'sini Koruma

Global kurum entity'si her dil için duplicate edilmemelidir. Aynı @id publisher olarak kullanılabilir. name lokalizasyon politikası markaya göre değişebilir. Local legal entity varsa ayrı node gerekebilir. Entity registry bu farkı yönetir.

Çok Bölgeli Kurumsal Sitelerde Organization Schema

Çok bölgeli kurumsal yapılarda global Organization, yerel ofis ve department entity'leri birbirinden ayrılmalıdır. Her ülke sayfasına bağımsız ana Organization üretmek her zaman doğru değildir. LocalBusiness yalnız gerçek yerel işletme koşulları varsa değerlendirilmelidir. Kurumsal ownership ve legal structure schema modeline yön vermelidir. Entity registry global ve local node'lar arasındaki relation'ı saklayabilir.

Global Organization

Ana şirket global Organization olarak tanımlanabilir. Merkezi @id korunur. WebSite publisher buna bağlanabilir. Global sameAs listesi burada tutulur. Local office ayrı node olabilir.

Yerel Ofis

Yerel ofis fiziksel lokasyonu temsil edebilir. Organization subOrganization veya farklı modeling değerlendirilebilir. Address ve contact local data'dan gelir. Global entity ile karıştırılmamalıdır. Local page visible content ile uyumlu olmalıdır.

Department

Department kurum içindeki belirli birim için kullanılabilir. Gerçek organizasyon yapısı varsa anlamlıdır. Her service page'e department yaratmak gereksizdir. Owner ve URL ilişkisi tanımlanmalıdır. Registry duplicate'i önlemelidir.

LocalBusiness Gereksinimi

LocalBusiness her yerel sayfa için otomatik seçim değildir. Gerçek fiziksel müşteri hizmeti ve uygun business type bulunmalıdır. Kurumsal ofis yalnız idari merkezse farklı modeling gerekebilir. Search feature beklentisi type seçimini zorlamamalıdır. Local SEO gereksinimleri ayrıca değerlendirilmelidir.

İçerik Migration'ında Schema Nasıl Taşınmalıdır?

İçerik migration'ı yalnız URL redirect çalışması değildir. Canonical, @id, author URL, image ve breadcrumb ilişkileri de etkilenir. Eski entity identity ile yeni URL arasında continuity planlanmalıdır. Redirect map schema generator tarafından bilinmelidir. Migration sonrası automated crawler eski host ve id kalıntılarını tespit etmelidir.

Eski URL

Eski URL inventory'de tutulmalıdır. Redirect hedefi tanımlanmalıdır. Structured data yeni sayfada eski canonical'ı kullanmamalıdır. Historical analytics mapping korunabilir. Redirect chain önlenmelidir.

Yeni URL

Yeni URL canonical source olmalıdır. JSON-LD url ve page @id yeni tabanı kullanabilir. Hreflang güncellenmelidir. Breadcrumb yeni route'u göstermelidir. Search Console migration takip edilmelidir.

@id Değişimi

@id URL tabanlıysa migration ile değişebilir. Entity continuity açısından bu karar dikkatle verilmelidir. Organization gibi global id daha stabil tutulabilir. Article id yeni canonical'a taşınabilir. Old reference cleanup gerekir.

Canonical

HTML canonical yeni URL'yi göstermelidir. JSON-LD ile eşleşme kontrol edilir. Old canonical kalıntısı index sinyalini karıştırır. Sitemap de güncellenmelidir. Automated test bütün katmanları karşılaştırmalıdır.

Redirect

Eski URL uygun yeni URL'ye kalıcı yönlendirilmelidir. Chain veya loop olmamalıdır. Redirect map content equivalence'a dayanmalıdır. Schema yeni final destination'ı kullanır. Crawler status raporu hazırlanabilir.

Entity Continuity

Migration entity'nin tamamen yeni bir varlık olduğu anlamına gelmeyebilir. Yazar ve kurum identity korunmalıdır. Content revision history mümkünse taşınmalıdır. @id strategy dokümante edilmelidir. Search ve semantic continuity birlikte düşünülmelidir.

URL Değiştiğinde Article @id Değişmeli mi?

Article @id URL tabanlı naming convention kullanıyorsa canonical migration sırasında değişmesi doğal olabilir. Ancak karar entity identity ve sistem mimarisi açısından düşünülmelidir. Eski URL yeni URL'ye redirect edilmelidir. Downstream referanslar güncellenmelidir. Kurum genelinde tek policy seçmek rastgele page-level kararlardan daha güvenlidir.

Entity Identity

Article aynı içerik olarak devam edebilir. URL yalnız adres değişikliğidir. @id kalıcı opaque identifier da olabilirdi. URL-based yaklaşımda migration semantics dokümante edilmelidir. Search engine redirect relation'dan continuity sinyali alabilir.

Canonical Migration

Canonical yeni URL'ye taşınır. Page @id ve article @id policy'ye göre güncellenir. Sitemap ve hreflang da değişir. Structured data diff büyük değişikliği gösterir. Pilot migration ile doğrulanabilir.

Redirect Mapping

Eski ve yeni URL mapping sistemi korunmalıdır. Automated test eski URL'nin doğru target'a gittiğini kontrol eder. Internal linkler güncellenmelidir. Breadcrumb eski URL kullanmamalıdır. Registry migration metadata tutabilir.

Eski Referansların Yönetimi

Site içinde eski article @id referansı kalabilir. Crawler graph reference analizi yapabilir. Legacy schema template'leri güncellenmelidir. External references kontrol edilemez ancak redirect yardımcı olur. Cleanup planı migration kapsamına eklenmelidir.

Schema Markup Nasıl Test Edilir?

Schema testing birkaç katmandan oluşmalıdır. İlk olarak JSON syntax geçerli olmalıdır. Ardından Schema.org vocabulary ve Google rich result gereksinimleri ayrı araçlarla incelenebilir. Rendered HTML içinde gerçek script'in bulunduğu doğrulanmalıdır. Search Console production sonuçlarını zaman içinde takip etmek için kullanılmalıdır.

JSON Syntax Validation

JSON parser output'u parse edebilmelidir. Trailing comma ve invalid quote hataları bu aşamada yakalanır. CI/CD içinde hızlı test olarak çalışabilir. Her page fixture test edilebilir. Parse failure deployment blocker olmalıdır.

Schema.org Validation

Schema vocabulary'nin doğru type ve property kullanımı incelenir. Genel semantic validity sağlar. Search engine feature desteğinden bağımsızdır. Custom graph relation hataları yine human review gerektirebilir. Validation report saklanabilir.

Google Rich Results Validation

Google'ın desteklediği structured data feature'ları için uygunluk kontrol edilir. Required ve recommended field uyarıları görülebilir. Her valid schema rich result üretmez. Pilot URL'ler araçla test edilebilir. Feature support zamanla değişebilir.

Rendered HTML Kontrolü

Source code yerine gerçek rendered DOM incelenmelidir. GTM veya client-side injection böyle görünür. Duplicate script ve hydration sorunları yakalanabilir. Headless browser crawler kullanılabilir. Network failure senaryosu test edilebilir.

Search Console

Search Console production index seviyesinde structured data raporları sunabilir. Valid ve invalid trend izlenebilir. Deployment sonrası ani düşüş alarm kabul edilmelidir. URL inspection sample kontrol için kullanılabilir. Tool verisi gecikmeli olabilir, bu yüzden local automated test yine gereklidir.

Rich Results Test ile Neler Kontrol Edilir?

Rich Results Test belirli URL veya kod parçasında Google'ın desteklediği structured data öğelerini tespit etmeye yardımcı olur. Detected items, errors ve warnings görülebilir. Bazı özellikler için preview bulunabilir. Araç semantic bütünlüğün tamamını garanti etmez. Kurumsal test pipeline'ın tek aracı olarak kullanılmamalıdır.

Detected Items

Araç tespit ettiği desteklenen item'ları listeler. Beklenen BlogPosting görünmüyorsa rendering veya type sorunu olabilir. Duplicate item ayrıca fark edilebilir. Page type assertion ile karşılaştırılır. Sonuç screenshot veya log olarak saklanabilir.

Errors

Error feature eligibility'yi etkileyebilecek ciddi problemi gösterebilir. Missing required field veya invalid value örnek olabilir. Root cause CMS mapping veya template olabilir. Tek URL yerine template coverage incelenmelidir. Fix sonrası tekrar validate edilmelidir.

Warnings

Warning çoğu zaman recommended alan eksikliği veya iyileştirme fırsatıdır. Her warning production blocker olmak zorunda değildir. Business ve content availability değerlendirilmelidir. Sahte data ile warning kapatılmamalıdır. Quality backlog'a alınabilir.

Preview

Bazı feature'larda potansiyel görünüm preview edilebilir. Bu preview gerçek SERP garantisi değildir. İçerik ve site sinyalleri ayrıca etkilidir. Stakeholder iletişiminde bu fark açıklanmalıdır. Test aracı yalnız teknik doğrulama katmanıdır.

Schema Markup Validator Ne İçin Kullanılır?

Schema Markup Validator Schema.org vocabulary açısından structured data'yı değerlendirmek için kullanılır. Google Rich Results Test'ten daha genel semantic kapsam sunar. Google'ın özel search feature destek listesine bağlı değildir. Type ve property ilişkilerini kontrol etmek için değerlidir. Enterprise validation pipeline bu iki araç mantığını kendi testleriyle tamamlayabilir.

Schema.org Vocabulary

Validator type ve property'nin vocabulary içinde tanımlı olup olmadığını kontrol eder. Typo alanlar yakalanabilir. Range expectation görülebilir. Custom extension kullanılıyorsa ayrıca değerlendirilmelidir. Semantic model doğruluğu human review gerektirebilir.

Google Rich Result Testinden Farkı

Rich Results Test Google'ın desteklediği search feature'lara odaklanır. Schema Markup Validator daha genel vocabulary doğrulaması yapar. Bir markup Validator'da geçerli olabilir fakat rich feature desteklenmeyebilir. İki sonuç çelişki değildir. Farklı katmanları test ederler.

Genel Semantic Validation

Node relation ve property kullanımını gözden geçirmek için faydalıdır. Buna rağmen content parity veya factual doğruluk ölçmez. Sahte review syntax olarak geçerli olabilir. Bu yüzden editorial validation ayrıca gereklidir. Automated business rule testleri eklenmelidir.

Search Console Structured Data Raporları

Search Console structured data raporları production URL'lerde valid, invalid ve uyarılı item trendlerini takip etmeye yardımcı olabilir. Template deployment sonrası ani invalid artışı erken uyarı sağlar. Validation süreci düzeltme sonrası yeniden değerlendirme başlatabilir. Ancak raporlar her custom schema type için aynı kapsamı sunmayabilir. Kurumsal dashboard Search Console verisini internal crawler ile birleştirebilir.

Valid Items

Valid item teknik gereksinimleri karşılayan tespitleri gösterir. Sayı trendi coverage ile birlikte okunmalıdır. Valid sayının düşmesi URL azalması veya template hatası olabilir. Deployment tarihleriyle karşılaştırılmalıdır. Business impact ayrı değerlendirilir.

Invalid Items

Invalid item ciddi structured data problemi gösterir. Error type ve affected URL sample incelenir. Template-wide hata hızla yayılabilir. Incident severity buna göre belirlenir. Fix ve rollback seçenekleri değerlendirilir.

Warning

Warning recommended field veya kalite konusu olabilir. Tüm warning'leri kör biçimde kapatmaya çalışmak doğru değildir. Gerçek veri bulunuyorsa enrichment yapılabilir. Yoksa sahte property eklenmemelidir. Backlog priority belirlenebilir.

Trend

Trend zaman içindeki değişimi gösterir. Deployment, migration veya CMS release ile ilişkilendirilebilir. Ani kırılmalar investigation tetikler. Seasonality veya URL sayısı değişimi dikkate alınmalıdır. Change log korelasyon sağlar.

Validation

Düzeltme sonrası validation süreci başlatılabilir. Sonuç hemen gelmeyebilir. Internal crawler önce fix'i doğrulamalıdır. Search Console production confirmation katmanıdır. Validation success change log'a eklenebilir.

Unparsable Structured Data Nedir?

Unparsable structured data JSON-LD'nin syntax nedeniyle parse edilememesi durumudur. Broken JSON, trailing comma, quote hatası ve invalid escape yaygın nedenlerdir. Bir script parse edilemiyorsa içindeki semantic verinin anlamı da kullanılamaz. Bu nedenle JSON parse testi CI/CD'deki en temel gate olmalıdır. Güvenli serializer kullanımı manuel syntax hatalarını büyük ölçüde azaltır.

Broken JSON

Eksik bracket veya yanlış separator JSON'u tamamen bozabilir. Template string interpolation sık kaynak olabilir. JSON parser testleri bunu anında yakalar. Production'a ulaşmaması gerekir. Structured object yaklaşımı raw string'e göre daha güvenlidir.

Trailing Comma

Son property'den sonra kalan virgül geçersiz JSON oluşturabilir. Conditional template logic bu hatayı yaratabilir. Serializer otomatik yönetir. Manual string builder kullanılmamalıdır. Test fixture null property kombinasyonlarını içermelidir.

Quote Hatası

Smart quotes veya escape edilmemiş çift tırnak JSON'u bozabilir. CMS headline içindeki quote dikkat gerektirir. Serializer doğru escape eder. Copy-paste edilen JSON kodları risklidir. Linter kullanılabilir.

Invalid Escape

Backslash ve kontrol karakterleri yanlış escape edilirse parse error oluşur. Windows path veya rich text content örnek olabilir. Güvenli serialization gerekir. Test dataset özel karakterler içermelidir. Log output gerçek string'i görünür kılmalıdır.

Syntax Error

Her syntax error deployment öncesi otomatik yakalanmalıdır. JSON schema generator output'u parse edilmelidir. Build failure kritik page template için tercih edilebilir. Runtime error monitoring de eklenmelidir. Incident sonrasında regression test yazılmalıdır.

JSON-LD'de En Sık Syntax Hataları

En sık syntax hataları trailing comma, smart quotes, escape edilmeyen karakterler, eksik süslü parantez ve yanlış array yapısıdır. Bu hataların çoğu JSON-LD'nin elle string olarak yazılmasından kaynaklanır. Uygulama kodunda object oluşturup güvenli serializer kullanmak daha doğru yaklaşımdır. Lint ve unit test build sırasında çalıştırılabilir. CMS custom field içine raw JSON yazma yetkisi mümkün olduğunca azaltılmalıdır.

Trailing Comma

Conditional property eklemede kolayca oluşabilir. Raw template içinde son eleman kontrolü zorlaşır. Serializer sorunu ortadan kaldırır. Parse test hızlıdır. CI failure olmalıdır.

Smart Quotes

Word veya rich text editörden kopyalanan tırnaklar JSON syntax'ına uygun olmayabilir. Editor auto-formatting dikkat gerektirir. Raw JSON editörü kullanılmamalıdır. String serializer düzeltir. Linter hata verir.

Escape Edilmeyen Karakter

Newline veya özel karakter string'i bozabilir. CMS description alanı buna açıktır. JSON.stringify gibi araçlar güvenli escape yapar. Manual replacement eksik kalabilir. Security açısından da serializer tercih edilmelidir.

Eksik Süslü Parantez

Nested object'lerde elle yazılan JSON kolay bozulabilir. Code formatter yardımcı olur. Object literal yaklaşımı daha güvenlidir. Unit test parser ile kontrol eder. Merge conflict sonrası özellikle test edilmelidir.

Yanlış Array Yapısı

author veya image gibi alanlar yanlış nested array haline gelebilir. Type-safe schema model yardımcı olur. Fixture expected output ile karşılaştırılabilir. Schema.org range kontrolü yapılmalıdır. Empty array yerine property atlanabilir.

Structured Data Manual Action Nedir?

Structured data manual action yanıltıcı veya spam niteliğindeki markup nedeniyle Search Console'da uygulanabilecek manuel işlem türlerinden biridir. Misleading markup ve sahte structured data ciddi risk oluşturur. Sorun yalnız syntax hatasından farklıdır çünkü semantic ve policy ihlali söz konusudur. Düzeltme sonrasında ilgili süreç izlenmeli ve gerekirse reconsideration talebi hazırlanmalıdır. En iyi önlem schema'yı baştan gerçek içerikle uyumlu ve doğrulanabilir tutmaktır.

Misleading Markup

Sayfanın içeriğinden farklı bilgi sunmak misleading markup örneğidir. Sahte review veya görünmeyen claim buna girebilir. Teknik geçerlilik riski ortadan kaldırmaz. Audit factual parity incelemelidir. Yüksek riskli property'ler manuel review gerektirir.

Spammy Structured Data

Rich result elde etmek amacıyla alakasız veya sahte markup kullanımı spam niteliği taşıyabilir. Type stuffing de bu risk alanına yaklaşabilir. Otomasyon spam üretimini daha hızlı yayabilir. Governance guardrail gerekir. Search guideline review düzenli yapılmalıdır.

Search Console Manual Actions

Manual Actions bölümü manuel işlem durumunu gösterebilir. SEO owner düzenli kontrol yapmalıdır. Incident playbook tanımlanabilir. Etkilenen template ve URL inventory çıkarılır. Root cause yalnız tek URL değil sistem seviyesinde çözülmelidir.

Düzeltme

Yanıltıcı property kaldırılmalı veya gerçek içerikle eşleştirilmelidir. Template source düzeltilmelidir. Automated tests yeni hatayı önlemelidir. Etkilenen URL'ler crawl edilmelidir. Change log tutulmalıdır.

Reconsideration

Gerekli durumda düzeltme sonrası reconsideration süreci yürütülebilir. Açıklama net ve gerçek olmalıdır. Hangi sistemsel önlemlerin alındığı belirtilmelidir. Tekil patch değil root cause çözümü göstermek önemlidir. Sonuç beklenirken schema güvenli durumda tutulmalıdır.

Schema Manipulation Risk Matrisi

Schema değişikliklerini risk seviyesine göre sınıflandırmak kurumsal governance sürecini kolaylaştırır. CMS alanından headline üretmek düşük riskli olabilir. Client-side injection veya AI entity enrichment orta risk gerektirebilir. Sahte review, gizli FAQ ve sahte kurum bilgisi yüksek risklidir. Risk seviyesi validation ve approval derinliğini belirlemelidir.

Düşük Risk

Düşük riskli işlemler mevcut gerçek veriyi doğru property'ye map etmeyi içerir. Yine de otomatik test yapılmalıdır. Büyük template kapsamı operasyon riskini artırabilir. Change log tutulabilir. Hızlı rollout mümkündür.

CMS alanından headline oluşturmak

Headline görünür page title'dan üretilebilir. Parity testi uygulanır. Null field kontrol edilir. Serializer güvenli olmalıdır. Mapping değişikliği unit test ile korunur.

dateModified güncellemek

Gerçek editoryal updated field kullanılıyorsa düşük risklidir. Build timestamp kullanılmamalıdır. Visible date ile uyum kontrol edilir. Timezone normalize edilir. Policy belgelenir.

author bağlantısı kurmak

CMS author relation doğru Person @id'ye bağlanabilir. Duplicate yazar kontrol edilir. Profile URL valid olmalıdır. Guest author policy uygulanır. Test empty author senaryosunu kapsar.

Orta Risk

Orta riskli işlemler runtime, otomasyon veya model tabanlı enrichment içerir. False positive ve rendering sorunları daha olasıdır. Pilot rollout yapılmalıdır. Human review belirli sample üzerinde gerekir. Monitoring sıklaştırılmalıdır.

Client-side injection

JavaScript render dependency oluşturur. Timing ve script error schema'yı etkileyebilir. Headless browser test yapılmalıdır. Duplicate injection kontrol edilir. Server-side fallback değerlendirilebilir.

Otomatik entity enrichment

Metinden otomatik entity çıkarımı yanlış eşleşme üretebilir. about ve mentions ayrımı kontrol edilmelidir. Registry doğrulaması gerekir. Confidence threshold kullanılabilir. Human review örneklemesi yapılmalıdır.

AI tarafından schema üretimi

AI draft oluşturabilir fakat factual doğruluk garanti etmez. Fake entity ve yanlış property riski vardır. Output structured validation'dan geçmelidir. Human review yapılmalıdır. Production'a doğrudan serbest üretim verilmemelidir.

Yüksek Risk

Yüksek riskli uygulamalar gerçek dışı veya kullanıcıya görünmeyen iddiaları içerir. Bunlar arama politikası ve kurumsal güven açısından ciddi sonuç doğurabilir. Automated deployment engellenmelidir. Legal veya SEO governance review gerekebilir. En doğru yaklaşım çoğu durumda bu veriyi hiç üretmemektir.

Sahte review

Gerçek kullanıcı verisi olmadan rating üretilmemelidir. Test sistemleri review source kontrol edebilir. Manual input kısıtlanmalıdır. High-risk policy ihlali sayılmalıdır. Bulunduğunda kaldırılmalıdır.

Gizli FAQ

Sayfada görünmeyen soru cevaplar schema'ya eklenmemelidir. CMS field render state kontrol edilmelidir. Accordion gerçek visible content sayılabilir. Hidden template content audit edilmelidir. FAQ feature eligibility ayrıca değerlendirilmelidir.

Sahte kurum bilgisi

Gerçek olmayan ödül, adres veya claim eklenmemelidir. Master data dışı manual override sınırlandırılmalıdır. Corporate approval gerekir. Audit source lineage kontrol eder. Hata bütün siteye yayılabileceği için kritiktir.

Alakasız entity type

Sayfa amacına uymayan type rich result beklentisiyle kullanılmamalıdır. BlogPost'a Product eklemek tipik örnektir. Page type assertion bunu engelleyebilir. Primary entity policy olmalıdır. Semantic minimalism uygulanmalıdır.

Schema Type Stuffing Nedir?

Schema type stuffing bir sayfaya gereğinden fazla ve çoğu zaman alakasız entity type ekleme davranışıdır. Daha fazla schema'nın otomatik olarak daha güçlü SEO sinyali oluşturacağı varsayımından doğar. Oysa çok sayıda type page intent'i bulanıklaştırabilir ve bakım maliyetini artırır. Primary entity açık seçilmeli, yan entity'ler yalnız gerçek ilişki varsa eklenmelidir. Semantic minimalism daha güçlü ve güvenilir yaklaşım sunar.

Gereksiz Çok Sayıda Entity

Her başlık veya keyword için node oluşturmak gerekmez. Graph yalnız gerçek entity ilişkilerini içermelidir. Duplicate entity daha ciddi sorun yaratabilir. Coverage metric entity sayısından daha önemli değildir. Quality score semantic consistency'yi ölçmelidir.

Sayfa Amacıyla Eşleşmeyen Türler

Blog sayfasına Service, Product ve FAQ type'larını sırf görünürlük için eklemek doğru değildir. Her type'ın gerçek content karşılığı bulunmalıdır. Primary entity page intent'i belirler. Side entity relation gerekirse mentions kullanılabilir. Page type matrix hazırlanabilir.

Primary Entity Seçimi

Her URL için birincil entity tanımlamak kararları sadeleştirir. BlogPosting, Service veya Person gibi seçim yapılabilir. WebPage bu entity'ye mainEntity ile bağlanır. Diğer node'lar destekleyici olur. Bu model test edilebilir.

Semantic Minimalism

Yalnız gerekli type ve property'ler kullanılmalıdır. Empty ve speculative alanlar çıkarılır. Graph okunabilir kalır. Maintenance ve migration kolaylaşır. SEO hedefi semantic doğrulukla uyumlu olur.

“Daha Fazla Schema Daha İyi SEO” Yaklaşımı Doğru mu?

Hayır, schema miktarı tek başına kalite göstergesi değildir. Relevant, complete, accurate ve maintainable data daha değerlidir. Gereksiz property sayısı arttıkça schema drift ve validation sorunu büyüyebilir. Structured data ranking manipülasyon aracı olarak görülmemelidir. Kurumsal projede küçük fakat doğru graph, büyük ve belirsiz graph'tan daha sağlıklıdır.

Relevant Data

Property sayfa ve entity ile ilgili olmalıdır. Keyword ilgisi semantic ilişki anlamına gelmez. Business rule relevance kontrol edebilir. Page type'a göre allowlist kullanılabilir. Gereksiz alanlar kaldırılır.

Complete Data

Gerekli temel alanların eksiksiz olması önemlidir. Complete olmak bütün Schema.org property'lerini doldurmak değildir. Headline ve author gibi anlamlı alanlar önceliklidir. Eksik data sahte fallback ile tamamlanmamalıdır. Coverage metric gerçek eksikleri gösterir.

Accurate Data

Doğruluk bütün schema çalışmalarının temelidir. Tarih, URL ve kurum bilgisi gerçek source'tan gelmelidir. Manual override sınırlandırılır. Drift monitoring yapılır. Factual review gerekir.

Maintainable Data

Schema bugün doğru olup altı ay sonra bozulmamalıdır. Shared library ve registry bakım sağlar. Change ownership belirlenir. Automated test regresyonu önler. Maintainability design kriteri olmalıdır.

Schema Minimalism Nedir?

Schema minimalism yalnız sayfa ve entity için gerçekten gerekli, doğru ve sürdürülebilir property'leri kullanma yaklaşımıdır. Boş alanlar eklenmez. Kanıtlanamayan veri çıkarılır. Graph gereksiz node'larla büyütülmez. Bu yaklaşım validation ve governance maliyetini düşürürken semantic kaliteyi korur.

Yalnız Uygun Property'leri Kullanmak

Her type için onlarca property bulunabilir. Hepsini doldurmak amaç değildir. Page use case'ine uygun alanlar seçilir. Search feature requirement varsa ayrıca dikkate alınır. Mapping dokümante edilir.

Boş Alan Eklememek

Empty string semantic değer taşımaz. Null veya boş array gereksizdir. Conditional generation kullanılmalıdır. Required field eksikse data quality problemi çözülmelidir. Schema output temiz kalır.

Kanıtlanamayan Veriyi Eklememek

Claim doğrulanamıyorsa schema dışında tutulmalıdır. Marketing copy factual data değildir. AI extraction confident görünse bile review gerekir. sameAs ve awards özellikle doğrulanmalıdır. Source lineage saklanmalıdır.

Graph'ı Gereksiz Büyütmemek

Her keyword veya mention node olmamalıdır. Site-wide entity tekrar edilmemelidir. @id reference kullanılabilir. Smaller graph debugging'i kolaylaştırır. Performance ve payload da iyileşebilir.

Kurumsal Schema Governance Nasıl Kurulur?

Kurumsal schema governance SEO, developer, content, brand ve gerektiğinde legal ekiplerinin sorumluluklarını açık biçimde tanımlar. Schema yalnız SEO ekibinin veya geliştiricinin tek başına yönettiği kod parçası olmamalıdır. Verinin sahibi ile kodun sahibi farklı olabilir. RACI modeli karar ve approval akışını netleştirir. Yeni type ve önemli entity değişiklikleri belirlenmiş rollout sürecinden geçmelidir.

SEO Owner

SEO owner schema strategy ve search feature gereksinimini yönetir. Page type mapping'e katkı sağlar. Validation ve Search Console trendini takip eder. Semantic accuracy için content owner ile çalışır. Production change approval rolü olabilir.

Developer Owner

Developer owner generator, rendering ve test altyapısından sorumludur. Serialization ve performance konularını yönetir. CI/CD gate kurar. Bug fix ve rollback uygular. SEO requirement'i teknik modele dönüştürür.

Content Owner

Content owner headline, author ve tarih gibi editoryal verilerin doğruluğundan sorumludur. CMS field'ları doğru kullanır. FAQ ve claim içeriğini doğrular. Schema raw JSON yönetmez. Data quality sorunlarını düzeltir.

Brand / Corporate Communications

Organization name, logo ve resmi profile bilgileri bu ekip tarafından doğrulanabilir. Rebrand değişikliklerini yönetir. sameAs ve corporate claim review yapabilir. Registry source olarak kullanılabilir. SEO ve developer'a approved data sağlar.

Legal / Compliance

Yüksek riskli claim, review veya kişisel veri içeren durumlarda legal ekip devreye girebilir. Bütün schema değişikliklerini onaylaması gerekmez. Risk matrisi hangi senaryoda review gerektiğini belirler. Data privacy özellikle Person ve address alanlarında değerlendirilebilir. Governance süreci gereksiz bürokrasi yaratmadan uygulanmalıdır.

Schema Governance RACI

RACI kimin Responsible, Accountable, Consulted ve Informed olduğunu belirler. Schema type kararı, kod uygulaması, veri kaynağı, içerik doğrulaması ve deployment onayı için roller farklı olabilir. Bu ayrım ownership belirsizliğini azaltır. Incident olduğunda kimin aksiyon alacağı daha nettir. Kurumsal ölçekte structured data kalitesinin sürdürülebilirliği için bu yapı çok değerlidir.

Schema Type Kararı

SEO ve content owner birlikte page intent'i değerlendirebilir. Developer teknik feasibility sağlar. Final accountable rol belirlenmelidir. Search guideline kontrol edilir. Karar documentation'a eklenir.

Kod Uygulaması

Developer responsible olabilir. Code review başka developer tarafından yapılır. SEO acceptance test sağlar. Security gerektiğinde consulted olur. Deployment pipeline automated test çalıştırır.

Veri Kaynağı

Data owner source of truth'u belirler. CMS, master data veya routing service olabilir. Developer integration yapar. SEO semantic mapping'i kontrol eder. Duplicate source engellenir.

İçerik Doğrulaması

Content owner visible content parity'yi onaylar. Author ve claim bilgileri kontrol edilir. SEO schema representation'ı inceler. Automated crawler destek sağlar. High-risk data legal review alabilir.

Deployment Onayı

Risk seviyesine göre approval workflow değişebilir. Düşük risk auto-deploy olabilir. Yüksek risk SEO ve developer sign-off isteyebilir. Pilot metric gözlenir. Rollback criteria önceden belirlenir.

Yeni Schema Türü Yayına Nasıl Alınmalı?

Yeni schema type doğrudan bütün siteye eklenmemelidir. Önce use case ve page intent belirlenmelidir. Search feature ve Schema.org uygunluğu kontrol edilir. Data mapping tasarlanır, küçük pilot uygulanır ve validation tamamlanır. Başarılı sonuç sonrası kontrollü rollout yapılır.

Use Case

Yeni type neden gerekli sorusu cevaplanmalıdır. Page intent ile ilişkisi olmalıdır. Rich result tek gerekçe olmamalıdır. Mevcut type yeterli mi incelenmelidir. KPI belirlenebilir.

Search Feature Kontrolü

Google veya ilgili arama motorunun destek durumu incelenir. Required field belirlenir. Feature availability değişebilir. Search feature yoksa semantic use case yine değerlendirilebilir. Beklenti stakeholder'a doğru anlatılır.

Schema.org Kontrolü

Type ve property vocabulary anlamı incelenir. Daha spesifik type var mı kontrol edilir. Property range doğrulanır. Unsupported custom field eklenmemelidir. Validator ile test yapılır.

Data Mapping

Her property source sistemle eşlenir. Null handling tanımlanır. Owner belirlenir. Dynamic URL normalization yapılır. Mapping document versionlanır.

Pilot

Beş veya on temsilci URL seçilebilir. Farklı edge case'ler bulunmalıdır. Production benzeri ortamda render edilir. Validation ve parity kontrol edilir. Search trend izlenir.

Validation

JSON, semantic ve rich feature testleri çalışır. Negative page type kontrol edilir. Entity id consistency bakılır. Content owner sample review yapar. High-risk error çözülmeden rollout yapılmaz.

Rollout

Traffic veya URL segmentine göre kademeli rollout yapılabilir. Monitoring yoğunlaştırılır. Invalid item artışı takip edilir. Feature flag rollback sağlar. Change log güncellenir.

Structured Data İçin CI/CD Pipeline

Structured data uygulama kodunun parçasıysa CI/CD içinde otomatik test edilmelidir. Build aşamasında representative page fixture'ları üretilir. JSON validation, schema test ve page-type assertion çalıştırılır. Deployment sonrası production monitoring devam eder. Bu yaklaşım template değişikliğinin binlerce URL'de hata üretmesini erken yakalar.

Build

Schema generator package build edilir. Type check ve lint çalışır. Fixture output üretilir. Dependency version sabitlenir. Build artifact versionlanır.

JSON Validation

Bütün output parse edilir. Syntax error deployment'ı durdurur. Special character fixture'ları test edilir. Empty field kontrol edilir. Safe serialization doğrulanır.

Schema Test

Expected type ve property relation test edilir. Vocabulary validation çalışabilir. @graph duplicate id kontrol edilir. Page-specific business rule uygulanır. Test report saklanır.

Page-Type Assertion

Blog sayfasında BlogPosting beklenir. Service sayfasında BlogPosting olmamalıdır. About page farklı type kullanır. Assertion mapping config'ten gelir. Wrong schema type release blocker olabilir.

Deployment

Validated artifact staging'e çıkar. Smoke test representative URL'lerde yapılır. Feature flag kullanılabilir. Production rollout kademeli olabilir. Release id change log'a yazılır.

Monitoring

Post-deploy crawler schema coverage ölçer. Search Console trend izlenir. Invalid artışı alarm üretir. Canonical mismatch kontrol edilir. Rollback kriteri uygulanır.

Schema Regression Testing Nedir?

Schema regression testing daha önce doğru çalışan structured data'nın template, CMS, framework veya URL değişikliği sonrası bozulup bozulmadığını kontrol eder. Baseline production graph saklanabilir. Yeni deployment graph ile karşılaştırma yapılır. Beklenmeyen property removal veya entity id değişikliği tespit edilir. Özellikle büyük kurumsal sitelerde bu test önemli koruma sağlar.

Template Değişikliği

Frontend component değişikliği headline source'u etkileyebilir. Schema shared helper kullanıyor olsa bile smoke test gerekir. Rendered DOM parity kontrol edilir. Diff expected olmalıdır. Unexpected node removal alarm üretir.

CMS Değişikliği

Field rename mapping'i bozabilir. Author relation formatı değişebilir. Migration script schema test fixture'larını güncellemelidir. Null increase izlenmelidir. CMS release staging'de validate edilir.

Framework Upgrade

React, Next veya Nuxt upgrade head rendering davranışını değiştirebilir. Duplicate script veya hydration issue oluşabilir. Browser-level test gerekir. Server source karşılaştırılır. Dependency change log incelenir.

URL Migration

Canonical ve @id değişir. Breadcrumb ve mainEntityOfPage etkilenir. Redirect mapping test edilir. Old host reference taranır. Search Console migration monitor edilir.

Automated Schema Testlerinde Neler Kontrol Edilmeli?

Automated testler syntax, type, id, canonical, required data ve visible content parity gibi katmanları kapsamalıdır. Her test aynı severity seviyesinde olmak zorunda değildir. JSON parse failure kritik olabilirken optional image warning orta önemde olabilir. Page type'a göre farklı assertion setleri uygulanmalıdır. Test çıktısı URL, template ve schema version bilgisi taşımalıdır.

JSON Parse Ediliyor mu?

İlk kontrol budur. Parse edilemeyen schema kullanılamaz. CI test hızlı çalışır. Her fixture test edilir. Production crawler parse rate ölçebilir.

Beklenen @type Var mı?

Blog URL BlogPosting içermelidir. Kategori sayfasında CollectionPage beklenebilir. Wrong type template mapping hatasıdır. Multiple type kontrol edilir. Business rule config kullanılır.

@id Doğru mu?

Naming convention regex ile test edilebilir. Base canonical URL ile uyum kontrol edilir. Organization id sabit olmalıdır. Duplicate id graph içinde bulunmamalıdır. Fragment doğru entity'ye ait olmalıdır.

Canonical ile URL Eşleşiyor mu?

HTML canonical ve schema base URL karşılaştırılır. Protocol, hostname ve slash normalize edilir. Redirected URL alarmdır. Locale doğru olmalıdır. Breadcrumb URL ayrıca kontrol edilebilir.

Required Data Var mı?

Page type için gerekli temel field'lar kontrol edilir. Empty string geçerli sayılmamalıdır. CMS data quality issue ayrı raporlanır. Fallback uydurulmamalıdır. Coverage metric oluşturulur.

Görünür İçerikle Eşleşiyor mu?

Headline ve author text compare edilir. Date normalize edilir. FAQ visible content'ten çıkarılır. Image primary asset ile karşılaştırılır. Mismatch severity belirlenir.

Schema Diff Testing Nedir?

Schema diff testing aynı URL veya template'in eski production graph'ı ile yeni deployment graph'ını karşılaştırır. Eklenen, kaldırılan ve değişen property'ler görünür hale gelir. Entity id değişikliği özellikle yüksek önemle işaretlenebilir. Expected change list ile otomatik diff karşılaştırılabilir. Bu yöntem “kod çalışıyor” kontrolünün ötesinde semantic regression yakalar.

Önceki Production Graph

Baseline crawler production JSON-LD'yi saklar. Representative URL set kullanılabilir. Sensitive data bulunmamalıdır. Hash ve timestamp eklenir. Version registry ile ilişkilendirilir.

Yeni Deployment Graph

Staging veya canary URL'den yeni graph alınır. Normalization sonrası karşılaştırılır. Array order gereksiz diff üretmemelidir. Dynamic timestamp policy dikkate alınır. Report build artifact'a bağlanır.

Property Added

Yeni property expected change ise kabul edilir. Unexpected addition type stuffing olabilir. Source mapping kontrol edilir. Optional field rollout ölçülür. Change log ile eşleştirilir.

Property Removed

Required field removal critical olabilir. Deprecated field removal normaldir. Bulk removal CMS mapping sorunu gösterebilir. Coverage dashboard etkilenir. Rollback değerlendirilebilir.

Entity Changed

@id veya @type değişimi yüksek önemlidir. Entity identity bozulabilir. Rebrand veya migration gibi planned change olmalıdır. Owner approval gerekir. Search monitoring sıklaştırılır.

Schema Unit Test Örnekleri

Schema unit test küçük, deterministik ve hızlı kontrollerle generator davranışını güvence altına alır. Blog sayfasında BlogPosting bulunması ve hizmet sayfasında bulunmaması temel örneklerdir. Author'ın boş olmaması, datePublished formatı ve Organization @id sabitliği test edilebilir. Edge case fixture'ları null ve multiple author durumlarını kapsamalıdır. Unit test production crawler'ın yerine geçmez fakat erken hata yakalamada çok etkilidir.

Blog Sayfasında BlogPosting Var

Fixture blog content type oluşturur. Generator çıktısında BlogPosting aranır. @id ve headline doğrulanır. Author relation kontrol edilir. Test her build'de çalışır.

Hizmet Sayfasında BlogPosting Yok

Negative assertion gereksiz type stuffing'i önler. Service page fixture oluşturulur. Output içinde BlogPosting bulunmamalıdır. WebPage ve Service beklenebilir. Regression template değişikliğinde yakalanır.

Article Author Boş Değil

Published blog entry author relation taşımalıdır. Empty value test failure olabilir. Guest author farklı fixture ile test edilir. Organization author policy ayrıca doğrulanır. Fake fallback kabul edilmez.

datePublished Geçerli

ISO 8601 parser kullanılabilir. Invalid timezone test edilir. Created date ile publish date mapping fixture üzerinden doğrulanır. Empty date error olabilir. Legacy content exception ayrıca tanımlanabilir.

Organization @id Sabit

Bütün template fixture'ları aynı Organization id üretmelidir. Hostname değişikliği unexpected failure verir. Config source test edilir. Rebrand name değişse bile id policy korunabilir. Migration intentional ise test update edilir.

Schema Coverage Nasıl Ölçülür?

Schema coverage hedef page type'ların ne kadarında beklenen structured data bulunduğunu ölçer. Toplam blog URL sayısı ile BlogPosting bulunan URL sayısı karşılaştırılabilir. Valid BlogPosting oranı ayrıca hesaplanmalıdır. Missing author ve missing image gibi alanlar alt metrik olabilir. Coverage tek başına kalite değildir, entity consistency ve parity ile birlikte okunmalıdır.

Toplam Blog URL

CMS veya sitemap inventory source olabilir. Canonical, indexable URL'ler sayılmalıdır. Pagination ayrı tutulabilir. Deleted content çıkarılmalıdır. Page type classification doğru olmalıdır.

BlogPosting Bulunan URL

Crawler her blog URL'de BlogPosting arar. Missing type oranı hesaplanır. Client-rendered schema için JavaScript crawler gerekir. Template segmenti raporlanır. Zero coverage incident olabilir.

Valid BlogPosting

Presence tek başına yeterli değildir. JSON parse ve required rule geçmelidir. Semantic validator sonucu eklenebilir. Valid coverage yüzdesi hesaplanır. Trend deployment sonrası izlenir.

Eksik Author

Author missing URL sayısı data quality metriğidir. CMS content owner ile paylaşılır. Guest post veya legacy exception ayrı tutulabilir. Root cause mapping veya data olabilir. Düzelme trendi izlenir.

Eksik Image

Featured image bulunmayan içerikler raporlanabilir. Placeholder kullanılmamalıdır. Content policy bazı yazılarda image zorunlu olmayabilir. Metric segmentlenmelidir. Rich feature requirement ayrıca dikkate alınır.

Entity Coverage Nasıl Ölçülür?

Entity coverage özellikle yazar ve kurum graph kalitesini ölçmek için kullanılır. Toplam yazar sayısı, Person entity'si olan yazarlar, ProfilePage varlığı ve doğrulanmış sameAs oranı takip edilebilir. Bu metrik içerik schema coverage'dan farklıdır. Entity registry ile CMS author listesi karşılaştırılabilir. Amaç her alanı zorla doldurmak değil eksik kimlik modelini görünür hale getirmektir.

Toplam Yazar

CMS published content author listesi source olabilir. Duplicate profile merge edilmelidir. Inactive author ayrıca tutulabilir. Guest author ayrı segment olabilir. Sayı registry ile karşılaştırılır.

Person Entity'si Olan Yazar

Her gerçek bireysel yazar Person entity'ye sahip olabilir. Organization-authored content ayrı tutulur. Person id uniqueness kontrol edilir. Missing entity backlog oluşturur. Coverage yüzdesi hesaplanır.

ProfilePage Olan Yazar

Profil sayfası kullanıcı ve entity clarity için faydalıdır. Her yazar için zorunlu policy olmayabilir. Site standardına göre coverage ölçülür. Thin profile kalite sorunu ayrıca değerlendirilir. Canonical URL valid olmalıdır.

sameAs Doğrulanmış Yazar

sameAs optional olabilir. Yalnız doğrulanmış profile sahip yazarlar sayılır. Sahte link ekleyerek coverage artırılmamalıdır. Verification status registry'de tutulabilir. Quality coverage quantity'den önemlidir.

Structured Data Quality Score Nasıl Oluşturulur?

Structured Data Quality Score teknik validity, completeness, content parity, entity consistency ve search eligibility gibi birden fazla boyutu bir araya getirebilir. Tek bir skor bütün kaliteyi mükemmel temsil etmez fakat site segmentlerini önceliklendirmeye yardımcı olur. Her bileşene ağırlık verilebilir. Sahte data gibi yüksek riskli sorunlar skoru doğrudan düşürebilir. Score trendi release ve migration dönemlerinde izlenebilir.

Technical Validity

JSON parse ve schema syntax kontrol edilir. Invalid script en düşük kalite sinyalidir. Validator error sayısı kullanılabilir. Rendered presence ölçülür. CI test sonucu entegre edilir.

Completeness

Beklenen temel property'lerin varlığı ölçülür. Her optional field zorunlu sayılmaz. Page type rule set kullanılır. Empty value geçerli kabul edilmez. Missing coverage raporlanır.

Content Parity

Headline, author ve date visible content ile karşılaştırılır. FAQ için daha derin text matching yapılabilir. Mismatch severity tanımlanır. Client-rendered UI dikkate alınır. Parity score semantic güveni temsil eder.

Entity Consistency

Organization ve Person id'lerinin site genelinde tutarlılığı ölçülür. Duplicate id ve farklı logo drift sayılır. Registry reference doğrulanır. Canonical hostname kontrol edilir. Entity graph stability önemlidir.

Search Eligibility

Google'ın desteklediği feature varsa gerekli alanlar kontrol edilir. Bu skor semantic validity'den ayrı tutulabilir. Feature desteği değişebilir. Rich result garantisi verilmez. Search Console data tamamlayıcıdır.

Kurumsal Schema Dashboard'unda Hangi KPI'lar Olmalı?

Kurumsal dashboard yalnız toplam valid item sayısını göstermemelidir. Invalid URL, warning, schema coverage, entity coverage, canonical mismatch ve schema drift gibi metrikler birlikte izlenmelidir. KPI'lar page type ve locale bazında segmentlenebilir. Deployment annotation trend yorumlamayı kolaylaştırır. Dashboard teknik ekip ile SEO ve content ekiplerinin aynı kalite dilini kullanmasını sağlar.

Valid Structured Data URL Sayısı

Beklenen schema'yı geçerli biçimde taşıyan URL sayısıdır. Toplam URL sayısıyla birlikte okunmalıdır. Template ve locale bazında ayrılabilir. Trend düşüşü alarm olabilir. Crawl sample size bilinmelidir.

Invalid URL Sayısı

Parse veya critical rule hatası bulunan URL sayısıdır. Severity ve root cause ile gruplanmalıdır. Bir template bug binlerce URL etkileyebilir. Incident priority buna göre belirlenir. Fix sonrası hızla düşmesi beklenir.

Warning Sayısı

Warning optional veya recommended kalite konularını gösterebilir. Her warning aynı önemde değildir. Type ve source'a göre segmentlenir. Backlog trendi izlenir. Sahte data ile kapatılmamalıdır.

Schema Coverage

Target URL'lerin kaçında beklenen schema bulunduğunu gösterir. Presence ve validity ayrı metric olmalıdır. Page type inventory ile karşılaştırılır. New content otomatik dahil olur. Missing coverage root cause belirlenir.

Entity Coverage

Yazar ve kurum entity modelinin kapsamını ölçer. Person profile, registry ve sameAs gibi alt metrikleri olabilir. Optional field zorunlu sayılmaz. Duplicate entity kaliteyi düşürür. Trend governance'e yardımcı olur.

Canonical Mismatch

HTML canonical ile schema URL tabanının uyuşmadığı URL sayısıdır. Migration döneminde özellikle önemlidir. Hostname ve trailing slash normalize edilmelidir. High-severity mismatch ayrı alert üretebilir. Routing team'e atanabilir.

Schema Drift

Aynı entity için farklı name, logo veya @id varyasyonlarının sayısı ölçülebilir. Merkezi registry beklenen değer sağlar. Drift template kaynağına göre gruplanır. Rebrand sonrası geçici değişim izlenebilir. Long-term hedef minimum drift'tir.

Template Deployment Sonrası Schema Monitoring

Template deployment tamamlandıktan sonra ilk kontrol birkaç representative URL üzerinde yapılmalıdır. Ardından Search Console ve internal crawler trendleri takip edilir. Invalid item artışı veya valid item düşüşü rollback sinyali olabilir. İlk gün hızlı teknik test, sonraki günlerde production trend takibi gerekir. Monitoring release checklist'in zorunlu adımı olmalıdır.

İlk 10 URL Testi

Farklı kategori ve author senaryolarından sample seçilir. Rendered HTML incelenir. Rich Results ve validator testleri yapılabilir. Canonical ve id kontrol edilir. Sonuç release log'a eklenir.

Search Console Trend

Structured data report zaman içinde izlenir. Data gecikmeli olabilir. Deployment annotation dashboard'da bulunur. Invalid pattern template hatasını gösterebilir. Internal crawler ile doğrulanır.

Invalid Item Artışı

Ani artış investigation tetiklemelidir. Error type belirlenir. Affected URL coverage hesaplanır. Hotfix veya rollback kararı verilir. Root cause test suite'e eklenir.

Valid Item Düşüşü

Schema kaldırılmış veya crawler render edemiyor olabilir. URL inventory değişimi kontrol edilir. Client-side issue araştırılır. Search feature report kapsamı değişmiş olabilir. Internal metrics ile çapraz kontrol yapılır.

Rollback Kriteri

Critical parse failure veya widespread wrong type rollback kriteri olabilir. Threshold önceden tanımlanmalıdır. Feature flag hızlı dönüş sağlar. Rollback sonrası monitoring devam eder. Incident retrospective yapılır.

Schema Rollback Planı Nasıl Hazırlanır?

Rollback planı yeni schema release sorun çıkardığında önceki güvenilir duruma hızlı dönüş sağlamalıdır. Feature flag, eski template versiyonu veya GTM container rollback kullanılabilir. Monitoring kriteri geri dönüşü tetikler. Rollback'in kendisi de test edilmelidir. Plan yalnız dokümanda bulunmamalı, deployment sistemi gerçekten desteklemelidir.

Feature Flag

Yeni generator belirli page type veya URL grubunda açılabilir. Sorunda hızlı kapatma sağlar. Flag default state güvenli olmalıdır. Config change audit edilir. Long-term dead flag temizlenmelidir.

Eski Template Versiyonu

Previous stable template artifact korunmalıdır. Deployment sistemi hızlı restore yapabilmelidir. Data migration backward compatibility kontrol edilir. Version registry tutulur. Rollback smoke test çalıştırılır.

GTM Version Rollback

GTM container eski version'a döndürülebilir. Hangi version stable olduğu change log'da bilinmelidir. Analytics tag etkileri dikkate alınmalıdır. Rollback sonrası trigger test edilir. Source code schema ile conflict kontrol edilir.

Monitoring

Rollback sonrası invalid rate düşmeli ve valid coverage geri gelmelidir. Search Console gecikmeli olabilir. Internal crawler hızlı confirmation sağlar. Metric baseline ile karşılaştırılır. Incident ancak stabilite doğrulanınca kapanır.

AI ile JSON-LD Üretilebilir mi?

AI schema type önerisi, property mapping, entity extraction ve JSON draft üretiminde yardımcı olabilir. Ancak modelin çıktısı doğrudan güvenilir veri kaynağı kabul edilmemelidir. Gerçekte olmayan entity veya property üretme riski bulunur. Structured output schema ile format kontrol edilebilir fakat factual doğruluk yine ayrı doğrulama ister. Kurumsal kullanımda AI yardımcı araç olmalı, source of truth olmamalıdır.

Schema Type Önerisi

AI sayfa metninden olası type önerebilir. Page intent metadata ile birlikte kullanılırsa daha iyi sonuç verir. Öneri final karar değildir. Allowlist ve business rule uygulanmalıdır. Human review high-impact template için gerekir.

Property Mapping

AI CMS field'ları ile schema property'leri arasında draft mapping önerebilir. Developer ve SEO owner doğrular. Unsupported field filtrelenir. Type compatibility test edilir. Mapping kod olarak versionlanır.

Entity Extraction

Metinden Person, Organization veya Software entity'leri çıkarılabilir. Entity identity resolution gerekir. False positive ve same-name problemi bulunur. Confidence threshold uygulanabilir. Registry lookup doğrulama sağlar.

JSON Draft

AI örnek JSON-LD draft oluşturabilir. Syntax hatası structured output ile azaltılabilir. Ancak URL ve date gibi değerler gerçek source'tan çekilmelidir. Prompt içeriğine güvenilmemelidir. Production generator deterministic olmalıdır.

AI ile Üretilen Schema Doğrudan Yayına Alınmalı mı?

Hayır, AI tarafından üretilen schema doğrudan kontrolsüz şekilde production'a alınmamalıdır. Hallucination, fake entity ve yanlış property riski bulunur. Automated validation syntax ve type hatalarını azaltabilir. Human review özellikle kurumsal claim ve entity identity için gereklidir. Güvenilir AI çıktılarında doğruluk kontrolüyle ilgili daha geniş yaklaşım, benzer şekilde veri kaynağı ve doğrulama disiplinine dayanmalıdır.

Hallucination Riski

Model içerikte olmayan bilgi üretebilir. Şirket ödülü veya yazar profili uydurabilir. Structured output formatı bunu engellemez. Source-grounded generation kullanılmalıdır. Final value registry veya CMS ile doğrulanmalıdır.

Fake Entity Riski

AI benzer isimli entity'yi yanlış eşleyebilir. sameAs özellikle risklidir. Entity resolution service kullanılabilir. Unknown entity default olarak reddedilebilir. Human review gerekir.

Yanlış Property

Property type ile semantic olarak uyumsuz olabilir. Schema.org validator bazı hataları yakalar. Google feature requirement ayrıca kontrol edilir. AI prompt'a vocabulary sınırı verilebilir. Final mapping allowlist'ten gelmelidir.

Human Review

İnsan review içerik ve claim doğruluğunu kontrol eder. Her URL manuel incelenmek zorunda değildir. Template-level rule ve sample review kullanılabilir. High-risk property daha sık review edilir. Reviewer decision loglanabilir.

Automated Validation

JSON parse, schema rule ve content parity otomatik çalıştırılır. Registry match yapılabilir. Canonical mismatch yakalanır. AI confidence düşükse publish engellenebilir. Validation human review'ı tamamlar.

AI ile Entity Extraction

AI entity extraction içerikten kişi, kurum, ürün, yer veya yazılım gibi varlıkları belirlemek için kullanılabilir. Schema about ve mentions enrichment süreçlerinde fayda sağlayabilir. Ancak extraction ile identity resolution aynı şey değildir. Model “Python” kelimesini doğru bulabilir fakat belirli kurum veya kişi URL'sini yanlış eşleyebilir. Bu nedenle registry lookup ve human review gereklidir.

Person

Model kişi isimlerini çıkarabilir. Aynı isimli kişiler disambiguation gerektirir. Author ile mentioned person ayrılmalıdır. Profil URL otomatik uydurulmamalıdır. Registry veya trusted source kontrolü yapılmalıdır.

Organization

Şirket ve kurum isimleri tespit edilebilir. Brand alias normalization gerekebilir. Subsidiary ve parent organization karıştırılmamalıdır. sameAs yalnız doğrulanmış kaynakla eklenir. about veya mentions relation content context'e göre seçilir.

Product

İçerikte ürün isimleri bulunabilir. Blog sayfasının primary entity'si yine BlogPosting olabilir. Product node yalnız gerçek ihtiyaç varsa eklenir. Commercial data source doğrulanmalıdır. Type stuffing önlenmelidir.

Place

Şehir, ülke veya lokasyon entity'leri çıkarılabilir. Aynı isimli yerler disambiguation ister. Address veya geo verisi uydurulmamalıdır. Yer içeriğin ana konusuysa about düşünülebilir. Kısa mention için mentions yeterlidir.

Software

Yazılım adı model tarafından tespit edilebilir. Version ve official URL doğrulanmalıdır. Generic teknoloji terimi ile belirli uygulama ayrılmalıdır. SoftwareApplication node her mention için gerekmez. Entity registry kullanılabilir.

AI Entity Extraction Sonrası Doğrulama

Extraction sonrasında dört temel soru sorulmalıdır: Entity gerçekten içeriğin ana konusu mu, kimliği doğru mu, URL doğru mu ve duplicate entity var mı? Bu kontroller olmadan otomatik enrichment graph kalitesini düşürebilir. about ve mentions yanlış seçilebilir. Registry ve semantic rules doğrulamayı otomatikleştirebilir. Human sample review model performansını izlemek için gereklidir.

Gerçekten İçeriğin Ana Konusu mu?

Başlık, giriş ve içerik yoğunluğu incelenebilir. Tek mention ana konu sayılmamalıdır. Editorial taxonomy güçlü sinyal olabilir. AI confidence tek başına yeterli değildir. about threshold belirlenmelidir.

Entity Doğru mu?

Aynı isimli kişi veya kurumlar ayrılmalıdır. Context match kontrol edilir. Registry identifier kullanılabilir. Unknown entity manual review'a gider. Yanlış identity sameAs riskini artırır.

URL Doğru mu?

Official veya canonical URL doğrulanmalıdır. Search result ilk link otomatik kullanılmamalıdır. Redirect ve hostname kontrol edilir. Internal entity ise site canonical service kullanılabilir. Broken URL rejection sebebidir.

Duplicate Entity Var mı?

Graph içinde aynı entity farklı id ile tekrar oluşabilir. Registry deduplication yapmalıdır. Name similarity ve sameAs eşleşmesi kullanılabilir. Merge rule dikkatli uygulanmalıdır. Different entity yanlışlıkla merge edilmemelidir.

JSON-LD AI Search ve GEO İçin Neden Konuşuluyor?

JSON-LD makine tarafından okunabilir context ve entity relationship sunduğu için AI search ve generative search tartışmalarında sık anılmaktadır. Structured metadata içerikteki kişi, kurum ve konu ilişkilerini açık hale getirebilir. Bununla birlikte herhangi bir AI sisteminin bu veriyi mutlaka kullanacağı veya citation sağlayacağı garanti değildir. İçerik kalitesi, kaynak güvenilirliği ve erişilebilirlik ayrı faktörlerdir. JSON-LD bu ekosistemde semantic açıklık sağlayan katmanlardan biri olarak düşünülmelidir.

Machine-Readable Context

JSON-LD açık field ve type yapısı sunar. Model veya crawler metinden infer etmek yerine bazı ilişkileri doğrudan görebilir. Bu potansiyel faydadır. Her sistem structured data'yı aynı şekilde kullanmaz. İçerik yine temel kaynaktır.

Entity Relationship

Author, publisher ve about ilişkileri graph içinde açık olur. Entity disambiguation kolaylaşabilir. Organization identity site genelinde tutarlı kalır. Search ve AI sistemleri bu context'ten yararlanabilir. Garantili kullanım iddiasından kaçınılmalıdır.

Content Disambiguation

Aynı isimli entity'ler @id ve sameAs ile ayrılabilir. Person ve Organization relation daha açık olur. Yanlış sameAs ters etki yaratabilir. Semantic doğruluk önemlidir. Text context ile birlikte değerlendirilir.

Structured Metadata

Tarih, yazar ve headline structured biçimde sunulur. CMS data machine-readable hale gelir. Metadata görünür içerikle uyumlu olmalıdır. Search feature dışında farklı tüketiciler de kullanabilir. Open web interoperability avantaj sağlar.

Schema Kullanmak AI Citation Garantisi Verir mi?

Hayır, schema kullanmak AI citation garantisi vermez. Structured data semantic açıklık sağlar fakat citation kararı içerik kalitesi, kaynak güvenilirliği, erişilebilirlik ve ilgili sistemin retrieval yöntemi gibi birçok faktörden etkilenir. Schema yalnızca metadata katmanıdır. Kurumsal iletişimde “JSON-LD eklersek AI bizi kaynak gösterir” gibi kesin vaatlerden kaçınılmalıdır. Doğru structured data yine de içerik ve entity modelini daha anlaşılır hale getirdiği için değerlidir.

Structured Data ile Citation Arasındaki Fark

Structured data sayfa anlamını açıklar. Citation başka bir sistemin kaynak seçim kararıdır. İki kavram aynı değildir. JSON-LD citation oluşturmaz. Search veya AI sistemi kendi algoritmasını kullanır.

İçerik Kalitesi

Doğru, özgün ve yararlı içerik temel önem taşır. Schema zayıf içeriği güçlü kaynak yapmaz. Güncellik ve uzmanlık ayrıca değerlidir. Kaynaklar gerektiğinde açıkça gösterilebilir. Structured data içeriği tamamlar.

Kaynak Güvenilirliği

Kurumsal kimlik ve author transparency güvenilirliğe katkı sağlayabilir. Ancak bunu tek başına schema oluşturmaz. Gerçek site geçmişi ve kaynak niteliği önemlidir. Fake claim ters etki yaratır. Entity data truthful olmalıdır.

Entity Authority

Entity authority farklı sistemlerin değerlendirdiği geniş bir kavramdır. sameAs eklemek otomatik otorite üretmez. Gerçek yayın geçmişi ve dış referanslar daha anlamlıdır. Schema identity clarity sağlar. Marketing guarantee verilmemelidir.

Schema Markup Ranking Factor mıdır?

Schema markup'ı doğrudan ve garantili sıralama artışı sağlayan basit ranking faktörü olarak görmek doğru değildir. Structured data arama motorlarının içeriği anlamasına ve uygun search appearance özelliklerine katkı sağlayabilir. Rich result ile ranking birbirinden farklıdır. CTR değişimi belirli görünüm farklılıklarından etkilenebilir fakat bu doğrudan sıralama garantisi değildir. Teknik SEO iletişiminde bu ayrım açık biçimde anlatılmalıdır.

Ranking ile Rich Result Farkı

Ranking sonuç sırasını ifade eder. Rich result ise sonucun sunum biçimindeki gelişmiş özellikleri ifade edebilir. Structured data bazı rich result uygunluklarında rol oynar. Aynı URL'nin sırası değişmek zorunda değildir. KPI'lar ayrı izlenmelidir.

Semantic Understanding

Schema entity ve relation bilgisini açık hale getirir. Bu semantic understanding'e katkı sağlayabilir. Arama sistemi bunu diğer sinyallerle birlikte kullanır. Yanlış schema fayda yerine belirsizlik yaratabilir. Accuracy önceliklidir.

CTR ve Search Appearance

Search appearance değişirse kullanıcı tıklama davranışı etkilenebilir. CTR artışı ranking artışıyla aynı değildir. A/B benzeri doğrudan test SERP üzerinde zor olabilir. Search Console trend yardımcı olur. Seasonality ve query mix dikkate alınmalıdır.

Garantili Sıralama Artışı İddialarından Kaçınmak

Teknik SEO hizmetlerinde kesin ranking vaadi verilmemelidir. Schema çok sayıda faktörden yalnız biridir. Search engine policy ve UI değişebilir. Hedef doğruluk ve maintainability olmalıdır. Kullanıcı beklentisi gerçekçi tutulmalıdır.

Blog İçeriklerinde Open Source Schema Yönetimi

Open source yaklaşımı shared schema library, JSON-LD generator, validator ve test suite geliştirmek için güçlü fırsat sunar. Ortak bileşenler tekrar kullanılabilir. Community review syntax ve semantic bug'ları daha hızlı ortaya çıkarabilir. Kuruma özel master data public repository'ye eklenmemelidir. Genel generator ve test araçları ise topluluk katkısıyla gelişebilir.

Shared Schema Library

Reusable function'lar page type graph üretir. Type definitions ortak tutulur. Bug fix bütün projelere yayılabilir. Semantic versioning uygulanır. Documentation açık olmalıdır.

JSON-LD Generator

Generator input data contract'tan structured graph oluşturur. Framework bağımsız olabilir. Safe serialization helper sağlar. Unit test kapsamı güçlü olmalıdır. Community yeni type katkısı sunabilir.

Validator

Validator JSON parse ve business rule test edebilir. Canonical mismatch plugin eklenebilir. Page type assertion yapılabilir. CLI ve CI entegrasyonu sunulabilir. False positive rate izlenmelidir.

Test Suite

Fixture tabanlı testler expected output doğrular. Edge case author ve migration örnekleri bulunur. Regression bug tekrarını önler. Pull request otomatik test çalıştırır. Coverage raporu sunulabilir.

Community Contribution

Developer issue ve pull request ile katkı sağlayabilir. Documentation ve sample project üretilebilir. SEO uzmanları semantic test case ekleyebilir. Version discussion açık yürütülebilir. Security disclosure policy bulunmalıdır.

Open Source ve İş Birliği Schema Kalitesini Nasıl Artırabilir?

Open source iş birliği reusable component, peer review, bug report ve ortak test araçlarının gelişmesini sağlar. Schema.org community değişiklikleri daha hızlı takip edilebilir. Farklı framework kullanıcıları edge case paylaşabilir. Ancak public tool'un çıktısı yine kurumun gerçek veri ve governance kurallarından geçmelidir. Açık kaynak kod semantic sorumluluğu otomatik üstlenmez.

Reusable Components

Aynı Organization helper farklı projelerde kullanılabilir. Standard naming yaygınlaşır. Bug tekrarları azalır. Component config ile özelleştirilebilir. Hard-coded kurum verisi bulunmamalıdır.

Peer Review

Farklı geliştiriciler semantic ve teknik hatayı görebilir. SEO uzmanı PR review'a katılabilir. Accessibility ve security etkileri de tartışılır. Review checklist standardize edilebilir. Bilgi paylaşımı artar.

Bug Reports

Production edge case issue olarak paylaşılabilir. Minimal reproducible example eklenir. Community çözüm önerebilir. Regression test bug fix'e eklenir. Version release note güncellenir.

Schema.org Community

Vocabulary gelişimi community çalışmalarıyla ilerler. Yeni type ve property değişiklikleri takip edilebilir. Kurumsal generator güncel tutulur. Deprecated kullanım erken fark edilir. Ancak her yeni property hemen production'a eklenmemelidir.

Ortak Test Araçları

CLI validator ve crawler modülleri paylaşılabilir. Framework-specific plugin geliştirilebilir. JSON diff tool ortak ihtiyaçtır. CI integration kolaylaşır. Test data gerçek kişisel bilgi içermemelidir.

Schema Otomasyonu İçin En İyi Programlama Dili Hangisidir?

Schema otomasyonu için tek bir en iyi programlama dili yoktur. Teknoloji seçimi mevcut web framework, CMS ve ekip deneyimine göre yapılmalıdır. JavaScript veya TypeScript web framework entegrasyonunda doğal seçim olabilir. Python audit ve crawling tarafında güçlüdür, PHP WordPress'te yaygındır, Java veya .NET enterprise CMS sistemlerinde anlamlıdır. JSON-LD'nin kendisi dil bağımsızdır ve asıl değer doğru veri modelindedir.

Tek Bir En İyi Dil Var mı?

Hayır, sistem context'i belirleyicidir. Next.js projesinde TypeScript daha mantıklıdır. Python crawler service farklı rol oynayabilir. WordPress PHP zaten mevcut runtime'dır. Enterprise platform kendi stack'ini kullanmalıdır.

JavaScript / TypeScript

JavaScript ve TypeScript web uygulamasıyla yakın entegrasyon sağlar. JSON object üretimi doğaldır. TypeScript type safety schema modelinde faydalıdır. SSR ve SSG framework'leriyle çalışır. Shared package geliştirilebilir.

Web framework entegrasyonu

Next.js, Nuxt ve Node tabanlı framework'lerde aynı dil kullanılır. Route ve canonical data kolay erişilir. Schema component reusable olur. Build-time test eklenebilir. Client injection gereksiz azaltılabilir.

JSON üretimi

Object literal ile graph oluşturulur. JSON.stringify güvenli serialization sağlar. Type definition invalid structure'ı azaltır. Zod benzeri validator kullanılabilir. Raw string template önlenir.

SSR

Server rendering schema'yı initial HTML response'a ekler. CMS data server tarafında kullanılabilir. Search crawler dependency azalır. Cache stratejisi önemlidir. Page-specific graph request sırasında oluşturulur.

Python

Python crawling, audit ve data validation için güçlüdür. BeautifulSoup veya browser automation kullanılabilir. JSON graph parse ve comparison kolaydır. Pandas ile coverage raporu hazırlanabilir. Production web generator ayrı dilde olsa bile audit Python olabilir.

Audit

URL inventory crawl edilir. JSON-LD script'leri parse edilir. Type ve field coverage çıkarılır. Canonical mismatch raporlanır. CSV veya dashboard output üretilebilir.

crawling

HTTP crawler veya headless browser kullanılabilir. JavaScript rendering gerektiğinde browser automation eklenir. Rate limit uygulanmalıdır. Robots ve site policy dikkate alınmalıdır. Crawl result versionlanabilir.

data validation

Pydantic benzeri modeller data contract sağlayabilir. URL ve tarih formatı kontrol edilir. Registry data ile karşılaştırma yapılır. Batch validation hızlıdır. CI pipeline'a entegre edilebilir.

PHP

PHP WordPress ve birçok CMS ortamında doğal seçimdir. Theme veya plugin seviyesinde schema generator geliştirilebilir. CMS field'larına doğrudan erişim sağlar. Safe JSON encoding kullanılmalıdır. Plugin conflict ve cache test edilmelidir.

WordPress

Post title, author ve date hazır API'lerden alınabilir. SEO plugin'leriyle duplicate schema kontrol edilir. Custom post type mapping yapılabilir. Hook kullanımı dikkatle tasarlanır. Update sonrası regression test gerekir.

CMS template

Template page type'a göre schema üretir. Shared function tekrar kullanım sağlar. Organization config merkezi tutulur. Null field filtrelenir. JSON encoding PHP helper ile yapılır.

Java / .NET

Java ve .NET büyük enterprise publishing platformlarında yaygındır. Strong typing schema data modeline avantaj sağlar. Merkezi service ve template engine ile integration yapılabilir. CI/CD ve governance olgun olabilir. JSON serializer standard library kullanılmalıdır.

Kurumsal CMS

Enterprise CMS structured content model sunabilir. Schema mapping backend service'te yapılır. Approval workflow entegre edilir. Multi-site ve locale yönetimi desteklenir. Master data bağlantısı kurulabilir.

enterprise publishing

Büyük yayın sisteminde çok sayıda content type bulunur. Page type assertion önemlidir. Entity registry ayrı servis olabilir. Release governance gerektirir. Monitoring merkezi dashboard'a aktarılır.

Yazılımcı Olmak İsteyenler JSON-LD Öğrenmeli mi?

Web geliştirme, teknik SEO veya içerik platformlarıyla ilgilenen yazılımcılar için JSON-LD öğrenmek oldukça faydalıdır. Bu konu JSON, HTML, API, data modeling ve semantic web kavramlarını birlikte kullanmayı öğretir. Test otomasyonu ve server-side rendering becerileri de projeye dahil olabilir. Küçük bir schema generator projesi hem frontend hem backend düşünme becerisini geliştirir. JSON-LD tek başına kariyer alanı değildir fakat web mimarisini daha bütünsel anlamaya yardımcı olur.

JSON Bilgisi

Object, array ve primitive değerler öğrenilmelidir. Escape ve serialization anlaşılmalıdır. JSON parse error debugging yapılabilmelidir. API geliştirme için de temel beceridir. JSON-LD bu temelin üzerine semantic context ekler.

HTML

Structured data görünür sayfa içeriğiyle ilişkilidir. HTML semantic structure bilinmelidir. H1, author ve time elementleri anlaşılmalıdır. Rendered DOM ile source farkı öğrenilmelidir. Client-side framework davranışı önemlidir.

SEO Temelleri

Canonical, crawl, index ve page intent bilinmelidir. Schema bunların yerine geçmez. Search appearance ile ranking farkı anlaşılmalıdır. URL normalization önemlidir. Technical SEO collaboration kolaylaşır.

API ve Data Modeling

CMS verisi API üzerinden gelebilir. Entity ve relation modeling öğrenilir. Source of truth kavramı önemlidir. Contract validation yapılır. Schema generator API design becerisini güçlendirir.

Semantic Web

Entity identity ve linked data kavramları öğrenilir. @id ve relation mantığı anlaşılır. Data'nın yalnız string olmadığını görmeyi sağlar. Knowledge graph çalışmalarına temel oluşturur. Semantic modeling disiplini gelişir.

Test Otomasyonu

Schema project unit ve integration test için iyi örnektir. JSON parse, canonical ve page type assertion yazılabilir. CI/CD integration öğrenilir. Regression testing uygulanır. Production monitoring eklenebilir.

Schema Çalışmaları Yazılımcıya Hangi Yetkinlikleri Kazandırır?

Schema projeleri yalnız SEO bilgisini değil data modeling, entity modeling, serialization, testing ve web architecture becerilerini de geliştirir. Developer içerik ve business data arasındaki ilişkiyi daha iyi öğrenir. Edge case ve migration düşünme alışkanlığı kazanır. SEO ve content ekipleriyle ortak dil geliştirmek de önemli beceridir. Bu nedenle structured data çalışmaları iyi bir full-stack problem çözme alanıdır.

Data Modeling

Hangi alanın hangi kaynaktan geleceği tasarlanır. Optional ve required data ayrılır. Entity relation belirlenir. Versioning düşünülür. Bu yaklaşım API tasarımında da kullanılır.

Entity Modeling

Person, Organization ve WebPage farkı anlaşılır. Identity ve URL ayrımı görülür. Duplicate entity problemi çözülür. Registry yaklaşımı öğrenilir. Knowledge graph düşüncesine temel sağlar.

JSON Serialization

Safe string handling öğrenilir. Escape ve null behavior görülür. Framework serializer kullanımı pekişir. Security etkileri anlaşılır. Raw template riskleri azaltılır.

Testing

Unit, regression ve integration test uygulanır. Positive ve negative assertion yazılır. Fixture data hazırlanır. Diff testing kullanılır. CI pipeline experience kazanılır.

Web Architecture

CMS, frontend, routing ve canonical katmanları birlikte düşünülür. SSR ve client rendering farkı anlaşılır. Cache ve migration etkisi görülür. Source of truth tasarlanır. Production monitoring eklenir.

SEO–Developer İş Birliği

SEO requirement teknik contract'a dönüşür. Developer semantic kararın nedenini anlar. SEO ekibi implementation limitation görür. Shared test criteria oluşturulur. Daha az iletişim hatası yaşanır.

“En İyi Yazılımcı” Schema Projesinde Nasıl Değerlendirilir?

Schema projesinde iyi geliştirici yalnız JSON çıktısını ekrana basan kişi değildir. Semantic model kurabilmeli, test yazabilmeli, edge case yönetebilmeli ve kararlarını dokümante edebilmelidir. SEO ekibiyle iş birliği yapması önemlidir. Migration ve rollback gibi production senaryolarını düşünmelidir. Kodun bugün çalışması kadar altı ay sonra yönetilebilir olması da değerlendirilmelidir.

Kodu Çalıştırmak

Temel gereksinim doğru çalışan generator üretmektir. Syntax geçerli olmalıdır. Performance kabul edilebilir olmalıdır. Framework standardına uyulmalıdır. Ancak bu yalnız başlangıç seviyesidir.

Semantic Model Kurmak

WebPage ile BlogPosting ayrımını anlayabilmelidir. @id ve entity registry tasarlamalıdır. Primary entity seçimini teknik modele dönüştürmelidir. Duplicate'i önlemelidir. Data source'u açık tutmalıdır.

Test Yazmak

Generator test edilmeden production'a bırakılmamalıdır. Null, multiple author ve migration fixture'ları olmalıdır. Page-type negative tests yazılmalıdır. Canonical mismatch kontrol edilir. Test okunabilir olmalıdır.

Edge Case Yönetmek

Guest author veya missing image gibi durumlar düşünülmelidir. URL migration planlanmalıdır. Client-side rendering failure ele alınmalıdır. Multi-language page test edilir. Fallback policy bilinmelidir.

Dokümantasyon

@id naming ve mapping açıkça yazılmalıdır. Yeni ekip üyesi sistemi anlayabilmelidir. Change log tutulmalıdır. Ownership belirtilmelidir. Runbook incident sürecine yardımcı olur.

SEO Ekibiyle İş Birliği

Requirement yalnız ticket olarak alınmamalıdır. Page intent ve search guideline birlikte tartışılmalıdır. Trade-off açık anlatılmalıdır. Validation sonucu paylaşılır. Ortak acceptance criteria oluşturulur.

Diyarbakır Yazılım Topluluğu Gibi Yapılarda Schema Projeleri

Yazılım toplulukları structured data konusunda uygulamalı workshop, JSON-LD eğitimi ve açık kaynak generator projeleri geliştirebilir. Technical SEO hackathon çalışmaları frontend, backend ve SEO uzmanlarını aynı problem üzerinde buluşturabilir. Schema validator veya diff tool genç geliştiriciler için gerçek bir open source proje fırsatı sunar. Diyarbakır Yazılım Topluluğu'nun genel yapısı hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alınabilir. Topluluk odaklı çalışma, teknik SEO bilgisini yalnız teorik anlatım yerine çalışan kod ve testlerle pekiştirir.

Structured Data Workshop

Workshop temel Schema.org ve JSON-LD kavramlarıyla başlayabilir. Katılımcılar gerçek blog template'i üzerinde çalışabilir. @id graph tasarımı yapılabilir. Validation araçları uygulanır. Son bölümde CI test yazılabilir.

JSON-LD Eğitimleri

Eğitim JSON temellerinden entity modeling'e ilerleyebilir. BlogPosting ve Organization örnekleri kullanılır. Wrong schema örnekleri analiz edilir. CMS mapping senaryosu gösterilir. Katılımcı kendi generator'ını geliştirir.

Open Source Schema Generator

Topluluk TypeScript veya Python tabanlı generator geliştirebilir. Reusable type templates sunulabilir. Test suite açık olur. Documentation Türkçe hazırlanabilir. Katılımcılar pull request ile katkı sağlar.

Schema Validator

Validator canonical mismatch ve page type assertion ekleyebilir. CLI olarak çalışabilir. CSV URL listesi tarayabilir. CI integration gösterilebilir. Open source katkı için uygun scope oluşturur.

Technical SEO Hackathon

Takımlar audit, generator veya dashboard problemi seçebilir. Gerçek olmayan demo dataset kullanılabilir. Bir gün içinde proof of concept üretilebilir. SEO uzmanları acceptance criteria sağlar. Başarılı proje sonradan topluluk repository'sinde geliştirilebilir.

Diyarbakır'daki Yazılımcılar İçin Örnek Open Source JSON-LD Projesi

Diyarbakır'daki geliştiriciler için örnek proje olarak CMS tabanlı schema generator ve validation pipeline geliştirilebilir. Proje BlogPosting template, Organization registry ve diff tool bileşenlerinden oluşabilir. CI ortamında testler çalıştırılabilir. Documentation yeni başlayanların katılımını kolaylaştırır. Diyarbakır Yazılım Topluluğu'nun farklı proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden incelemek, böyle bir açık kaynak çalışma için fikir verebilir.

CMS Schema Generator

Demo CMS JSON payload kabul eden service geliştirilebilir. Content type'a göre graph üretilir. Safe serializer kullanılır. Null handling uygulanır. Unit test eklenir.

BlogPosting Template

Blog fixture headline, author ve tarih taşır. Generator WebPage ve BlogPosting node üretir. @id standardı uygulanır. Breadcrumb eklenebilir. Expected snapshot test edilir.

Organization Entity Registry

Basit JSON veya database registry kullanılabilir. Organization id ve logo saklanır. API endpoint sunulabilir. Duplicate id engellenir. Change log tutulur.

Schema Diff Tool

İki JSON-LD graph karşılaştırılır. Added ve removed property raporlanır. @id change yüksek severity alır. CLI output renkli olabilir. CI gate olarak kullanılabilir.

Validation Pipeline

JSON parse ve custom rule testleri çalışır. Canonical fixture kontrol edilir. Page type assertion uygulanır. Test sonucu badge ile gösterilebilir. Pull request'te otomatik çalışır.

Documentation

README kurulum ve mimariyi açıklar. Entity naming standardı yazılır. Contribution guide eklenir. Example input ve output gösterilir. Yeni başlayan issue listesi hazırlanabilir.

Blog İçin Örnek Schema Yönetim Mimarisi

Örnek mimaride CMS article ve author verisini sağlar, entity registry site-wide Organization, WebSite ve Person kimliklerini yönetir. Schema generator mapping ve validation yapar. Web application doğrulanmış JSON-LD'yi render eder. Monitoring Search Console ve automated crawler ile production kaliteyi takip eder. Bu ayrım source of truth ve sorumlulukları net hale getirir.

CMS

CMS article ve author relation'ı taşır. Editorial workflow burada yürür. Publish ve update timestamp tutulur. Featured image ilişkilendirilir. Locale content variant yönetilir.

Article data

Headline, description ve tarih content entry'den gelir. Data validation publish öncesi çalışabilir. Category relation bulunur. Revision history korunur. Schema generator yalnız published data kullanır.

Author data

Author name ve profile CMS entity'den gelir. Duplicate profile önlenir. sameAs doğrulanabilir. Guest author iş akışı bulunur. Person id registry ile eşlenir.

Entity Registry

Registry site-wide kimlikleri merkezi tutar. Generator node reference alır. Data owner bilgisi saklanır. Review date bulunur. Migration history takip edilir.

Organization

Organization id, name, URL ve logo tutulur. Publisher referansı buraya bağlanır. Rebrand tek source'tan güncellenir. sameAs doğrulanır. Duplicate entity engellenir.

WebSite

Website id ve canonical root saklanabilir. Publisher Organization'a bağlanır. Language policy tanımlanır. Multi-site yapıda ayrı kayıt olabilir. Route service ile uyumlu olmalıdır.

Person

Person registry yazar kimliğini stabil tutar. Profile URL ve @id saklanır. CMS author id mapping yapılır. Name change history tutulabilir. sameAs verification eklenebilir.

Schema Generator

Generator farklı kaynakları tek graph içinde birleştirir. Page type mapping uygular. URL normalization yapar. Null property filtreler. Output deterministic olmalıdır.

Mapping

CMS field property mapping config ile tanımlanır. Version controlled olur. Breaking change review gerektirir. Unit test her mapping'i doğrular. Documentation açık tutulur.

Validation

Input ve output validation çalışır. Missing author gibi data quality issue yakalanır. JSON parse garantilenir. Business rule uygulanır. Invalid graph render edilmez veya alert üretilir.

Web Application

Web application page ve schema'yı kullanıcıya sunar. Canonical aynı routing data'dan gelir. SSR tercih edilebilir. Client hydration duplicate script üretmemelidir. CSP policy dikkate alınmalıdır.

JSON-LD rendering

Validated object güvenli serializer ile script'e yazılır. Script type application/ld+json olur. Birden fazla graph duplicate edilmez. Render output smoke test edilir. Page cache doğru invalidation alır.

Monitoring

Production kalite sürekli izlenir. Crawler page-level schema çıkarır. Search Console external sinyal sağlar. Dashboard drift ve coverage gösterir. Alert ownership tanımlanır.

Search Console

Valid ve invalid trend takip edilir. Manual action kontrol edilir. Validation süreçleri izlenir. Search appearance değişimleri gözlenebilir. Internal test ile birlikte yorumlanır.

Automated crawler

Crawler site inventory tarar. JSON-LD parse eder. Canonical ve parity karşılaştırır. Entity drift raporlar. Scheduled job olarak çalışabilir.

Kurumsal İçerik İçin Örnek JSON-LD Yaşam Döngüsü

Kurumsal içerik structured data yaşam döngüsü içerik oluşturma ile başlar ve arşivlemeye kadar devam eder. Content Created sonrası entity mapping yapılır, schema üretilir ve automated validation çalışır. Editorial validation gerçek içerikle eşleşmeyi kontrol eder. Deployment sonrası search monitoring başlar. İçerik güncellendiğinde schema aynı lifecycle içinde yeniden üretilir.

Content Created

Editör CMS entry oluşturur. Required content field'lar girilir. Author relation seçilir. Draft henüz production schema üretmez. Preview test yapılabilir.

Entity Mapping

Author Person ve publisher Organization id'leri çözülür. about entity varsa registry lookup yapılır. Canonical route hesaplanır. Duplicate kontrol edilir. Mapping loglanabilir.

Schema Generated

Generator page type'a göre graph oluşturur. Null field filtrelenir. URL normalize edilir. @id pattern uygulanır. Safe serialization hazırlanır.

Automated Validation

JSON parse edilir. Required rule kontrol edilir. Canonical parity test edilir. Wrong type aranır. Error publish'i durdurabilir.

Editorial Validation

Headline ve author visible content ile kontrol edilir. FAQ ve claim gerçekliği incelenir. Yüksek riskli property review edilir. Gerekirse düzeltme CMS'de yapılır. Raw JSON edit edilmez.

Deploy

Validated content yayınlanır. Schema aynı release içinde render edilir. Release id loglanır. Smoke test representative URL'de çalışır. Monitoring başlar.

Search Monitoring

Search Console trend izlenir. Crawler coverage ölçer. Invalid artışı alarm üretir. Search feature görünümü gözlenebilir. Data gecikmesi dikkate alınır.

Update

İçerik değişince CMS revision oluşur. dateModified policy uygulanır. Schema yeniden üretilir. Diff test değişiklikleri gösterir. Deployment validation tekrarlanır.

Archive

İçerik kaldırılırsa URL status ve redirect policy uygulanır. JSON-LD eski sayfada kalmamalıdır. Entity relation cleanup yapılır. Sitemap güncellenir. Archive decision loglanır.

Blog İçeriği Güncellendiğinde Schema'da Neler Değişmeli?

Blog içeriği güncellendiğinde yalnız dateModified değil gerçekten değişen alanlar schema'ya yansıtılmalıdır. Headline, description veya featured image değiştiyse ilgili property güncellenir. Author yalnız gerçek yazar değişimi varsa değiştirilir. about ve mentions içerik konusu değiştiğinde yeniden değerlendirilebilir. Generator CMS source'tan çalıştığı için manuel schema update ihtiyacı ortadan kalkmalıdır.

dateModified

Anlamlı editoryal değişiklikte güncellenir. Build timestamp kullanılmaz. Visible update date ile uyumludur. Timezone normalize edilir. Revision source kullanılır.

headline

Başlık değişirse schema headline aynı source'tan yenilenir. Old title cache temizlenmelidir. H1 parity kontrol edilir. SEO title farklı kalabilir. Diff report değişikliği gösterir.

description

Excerpt değişirse description güncellenir. Manual schema override olmamalıdır. Rich text temizlenir. Null durumda property kaldırılır. Search appearance etkisi ayrı değerlendirilir.

image

Featured image değiştiğinde image property güncellenir. CDN cache invalidation gerekebilir. Broken asset test edilir. Old URL redirect gerekmeyebilir. Visible article image ile uyum korunur.

author Gerekiyorsa

Yazar değişikliği gerçek editoryal karar olmalıdır. Person relation yeni entity'ye bağlanır. Eski attribution tarihsel olarak önemli olabilir. Policy belirlenmelidir. Profile URL validation yapılır.

about / mentions Gerekiyorsa

İçerik konusu önemli ölçüde değişirse entity relations güncellenebilir. AI extraction yeniden çalışabilir. Human review uygulanmalıdır. Keyword listesi doğrudan kullanılmamalıdır. Duplicate entity kontrol edilir.

İçerik Silindiğinde Schema'ya Ne Olur?

İçerik silindiğinde artık aktif olmayan sayfanın JSON-LD'si de aynı şekilde ele alınmalıdır. URL 404, 410 veya redirect politikasına göre davranır. Eski HTML response içinde BlogPosting schema bırakmak doğru değildir. Entity reference'ları başka sayfalarda kaldıysa gerekiyorsa cleanup yapılır. Sitemap ve internal link güncellemeleri structured data cleanup ile birlikte yürütülmelidir.

JSON-LD Kaldırılır

Silinen sayfa artık structured content sunmamalıdır. 404 template generic schema taşıyorsa page intent'e uygun olmalıdır. Eski BlogPosting script cache'te kalmamalıdır. CDN purge gerekebilir. Crawler doğrulama yapmalıdır.

URL Status

URL'nin 404, 410 veya redirect olması content strategy'ye bağlıdır. Status ile canonical uyumlu olmalıdır. Soft 404 oluşmamalıdır. Search Console izlenir. Schema status'u gerçeğe uygun olmalıdır.

Redirect

Eşdeğer yeni içerik varsa redirect kullanılabilir. Alakasız homepage redirect'i doğru değildir. Target schema yeni içeriği temsil eder. Old article id migration policy ile ele alınır. Redirect chain önlenir.

Entity Referansları

Başka sayfalarda silinen article'a mentions veya list relation kalabilir. Internal graph audit yapılabilir. Author Person entity silinmemelidir çünkü başka içerikleri olabilir. Category ItemList güncellenir. Registry orphan node kontrolü yapabilir.

Kurumsal Blog Migration'ında JSON-LD Checklist

Blog migration sırasında canonical URL, @id, author URL, image URL, breadcrumb, redirect ve validation birlikte kontrol edilmelidir. Yalnız HTML sayfanın açılması migration'ın tamamlandığı anlamına gelmez. Schema eski domain veya route'u kullanabilir. Crawler eski hostname pattern'lerini aramalıdır. Pilot migration sonuçları full rollout öncesi değerlendirilmelidir.

Canonical URL

Yeni URL self-canonical olmalıdır. Protocol ve hostname doğru olmalıdır. JSON-LD URL aynı source'tan gelmelidir. Hreflang güncellenmelidir. Old canonical bulunmamalıdır.

@id Migration

Page ve article id policy uygulanır. Organization id gerekmedikçe değişmez. Old references taranır. Registry mapping saklanabilir. Diff test büyük değişikliği doğrular.

Author URL

Yazar profilleri de migrate edilmiş olabilir. author.url yeni canonical profile gitmelidir. Redirect çalışmalıdır. Person @id policy değerlendirilir. Broken profile audit edilir.

Image URL

Asset CDN değişmiş olabilir. Image URL erişilebilir olmalıdır. Old domain hotlink kalıntıları temizlenir. Featured image parity kontrol edilir. Redirect chain performance etkileyebilir.

Breadcrumb

Yeni site IA breadcrumb'ı değiştirebilir. UI ve schema birlikte güncellenmelidir. Category route doğru olmalıdır. Item position korunur. Old path kaldırılır.

Redirect

Eski URL yeni eşdeğer URL'ye gider. Status code doğru olmalıdır. Chain yoktur. Sitemap yalnız yeni URL içerir. Crawler mapping doğrular.

Validation

Representative URL'ler parse edilir. Rich Results ve Schema Validator kontrolü yapılabilir. Canonical mismatch raporu çalışır. Search Console trend izlenir. Rollback planı hazır tutulur.

Schema Audit Nasıl Yapılır?

Schema audit URL, page type, schema type, @id, entity ve error envanterini birlikte çıkarır. Önce site segmentlere ayrılır. Her URL'deki rendered structured data parse edilir. Expected type ile actual type karşılaştırılır. Sonuçlar KEEP, ENRICH, REPLACE, CONSOLIDATE, REMOVE veya RE-EVALUATE gibi aksiyonlara dönüştürülebilir.

URL Envanteri

Sitemap, CMS ve crawl data birleştirilebilir. Canonical URL listesi çıkarılır. Status code eklenir. Page type sınıflandırılır. Duplicate URL temizlenir.

Page Type Envanteri

Homepage, blog, author, category, service, about ve contact ayrılır. CMS content type source olabilir. Unknown page type manuel review ister. Page intent mapping yapılır. Expected schema matrix oluşturulur.

Schema Type Envanteri

Her URL'de bulunan @type listelenir. Unexpected type raporlanır. Duplicate type incelenir. Missing primary entity belirlenir. Template bazında gruplanır.

@id Envanteri

Bütün entity id'leri çıkarılır. Duplicate ve varyasyonlar bulunur. Organization id consistency kontrol edilir. Old host pattern aranır. Naming standard deviation raporlanır.

Entity Envanteri

Person, Organization ve WebSite node'ları listelenir. Registry ile karşılaştırılır. Duplicate author bulunabilir. sameAs doğrulaması yapılır. Orphan entity işaretlenir.

Error Envanteri

Syntax, semantic ve parity error ayrı kategorilenir. Severity atanır. Affected URL sayısı hesaplanır. Root cause template veya data olarak sınıflandırılır. Remediation backlog oluşturulur.

Schema Audit İçin URL'ler Nasıl Segmentlenir?

Audit sonuçlarının anlamlı olması için URL'ler page type'a göre segmentlenmelidir. Homepage, blog, author, category, service, about ve contact sayfalarının beklenen schema yapıları farklıdır. Tek global rule hatalı sonuç üretir. Segmentasyon CMS type veya route pattern ile yapılabilir. Unknown segment manual review'a alınmalıdır.

Homepage

Organization ve WebSite merkezi node'lar incelenir. Canonical root kontrol edilir. Duplicate Organization aranır. SearchAction gerekiyorsa ayrıca değerlendirilir. Site-wide entity baseline buradan alınabilir.

Blog

BlogPosting, author ve date alanları kontrol edilir. WebPage relation incelenir. Breadcrumb parity ölçülür. FAQ varsa visible content kontrol edilir. Coverage hesaplanır.

Author

ProfilePage ve Person ilişkisi incelenir. Author URL canonical kontrol edilir. sameAs doğrulanır. Duplicate person id aranır. Content listesi kullanıcı açısından değerlendirilir.

Category

CollectionPage ve breadcrumb kontrol edilir. BlogPosting misuse aranır. ItemList varsa visible list ile eşleşir. Pagination policy incelenir. Canonical doğru olmalıdır.

Service

WebPage ve Service type doğru mu kontrol edilir. BlogPosting yanlışlığı aranır. Organization provider relation incelenir. Claim doğruluğu değerlendirilir. Breadcrumb kontrol edilir.

About

AboutPage ve Organization mainEntity ilişkisi değerlendirilebilir. Kurumsal data master ile karşılaştırılır. sameAs ve logo drift incelenir. Marketing claim'ler ayrıca review edilir. Canonical kontrol edilir.

Contact

ContactPage doğru mu kontrol edilir. Organization contact data visible içerikle eşleşir. Address ve phone güncelliği incelenir. Service misuse aranır. Privacy açısından gereksiz personal data kontrol edilir.

Schema Audit Decision Matrix

Audit çıktısını aksiyona dönüştürmek için decision matrix kullanmak faydalıdır. Doğru type ve doğru data KEEP olabilir. Doğru type fakat eksik data ENRICH edilir. Yanlış type REPLACE, duplicate entity CONSOLIDATE, misleading data REMOVE ve desteklenmeyen rich feature RE-EVALUATE aksiyonu alabilir. Bu yapı backlog önceliklendirmesini kolaylaştırır.

Doğru Type + Doğru Data

Schema sayfa amacıyla uyumludur. Temel alanlar doğru source'tan gelir. Parity problemi yoktur. Canonical ve id tutarlıdır. Büyük değişiklik gerekmez.

KEEP

Mevcut yapı korunur. Automated monitoring devam eder. Test coverage eklenebilir. Change log baseline olarak kaydedilir. Gereksiz enrichment yapılmaz.

Doğru Type + Eksik Data

Type doğru ama author veya image gibi anlamlı alan eksik olabilir. Önce source data var mı kontrol edilir. Yoksa sahte değer eklenmez. CMS improvement gerekebilir. Search feature requirement değerlendirilir.

ENRICH

Gerçek ve doğrulanmış veri bulunduğunda eksik property eklenir. Mapping layer güncellenir. Pilot test yapılır. Coverage ölçülür. Change log tutulur.

Yanlış Type

Page intent ile schema type uyuşmuyorsa semantic düzeltme gerekir. Blog yerine Service veya ters durum olabilir. Root cause template mapping'dir. Farklı property'ler de etkilenir. Replace planı hazırlanır.

REPLACE

Yanlış type kaldırılır. Doğru primary entity eklenir. Related graph relation güncellenir. Regression test yazılır. Rollout kontrollü yapılır.

Duplicate Entity

Aynı Organization veya Person birden fazla @id ile bulunabilir. Registry comparison yapılır. Hangi identity canonical belirlenir. References update edilir. Historical migration dikkatle yönetilir.

CONSOLIDATE

Tek stabil entity id seçilir. Duplicate node'lar kaldırılır. Publisher ve author relation yeni id'ye bağlanır. Drift test eklenir. Registry central source olur.

Misleading Data

Sahte review veya görünmeyen FAQ gibi data ciddi risktir. Kaynak doğrulanamıyorsa enrichment yapılmamalıdır. Page content ile mismatch incelenir. High-priority fix gerekir. Manual action riski değerlendirilir.

REMOVE

Yanıltıcı property veya node tamamen kaldırılır. Template source düzeltilir. Affected URL'ler crawl edilir. Regression test eklenir. Governance policy güncellenir.

Unsupported Rich Feature

Schema vocabulary valid olabilir fakat hedef search feature desteklenmeyebilir. İşaretlemenin semantic değeri değerlendirilir. Maintenance maliyeti hesaba katılır. Feature expectation düzeltilir. Gereksiz kod kaldırılabilir.

RE-EVALUATE

Use case yeniden değerlendirilir. Semantic değer varsa korunabilir. Yalnız rich result beklentisiyle eklenmişse kaldırılabilir. Search documentation kontrol edilir. Owner kararı change log'a yazar.

İlk 30 Günlük JSON-LD İyileştirme Planı

İlk 30 günlük plan envanter, entity model, template, pilot ve rollout aşamalarına bölünebilir. İlk günlerde mevcut durum görünür hale getirilir. Sonraki aşamada Organization, WebSite, Person ve BlogPosting standardı oluşturulur. Küçük pilot gerçek URL'lerde test edilir. Son on günde kontrollü deployment ve monitoring uygulanır.

Gün 1–5 — Envanter

İlk beş gün site URL ve page type inventory çıkarılır. Mevcut schema type'lar crawl edilir. @id varyasyonları bulunur. Search Console error baseline alınır. Kritik misleading markup varsa hızlı aksiyon planlanır.

URL types

Homepage, blog ve service gibi page type'lar ayrılır. CMS type ile route karşılaştırılır. Unknown URL sample review edilir. Canonical status kaydedilir. Matrix sonraki aşamayı besler.

mevcut schemas

Her segmentte kullanılan type listelenir. Duplicate ve missing schema bulunur. GTM ve source code kaynakları ayrılır. Syntax error sayılır. Baseline dashboard oluşturulur.

entity IDs

Organization, Person ve WebSite id'leri çıkarılır. Hostname ve fragment varyasyonları raporlanır. Duplicate entity tespit edilir. Naming pattern karşılaştırılır. Registry tasarımı için veri sağlar.

Gün 6–10 — Entity Model

Entity naming ve relation standardı bu aşamada belirlenir. Organization ve WebSite central node olarak tasarlanır. Person author modeli tanımlanır. BlogPosting ve WebPage ilişkisi dokümante edilir. SEO, developer ve content ekipleri ortak onay verir.

Organization

Tek kurumsal @id belirlenir. Name, URL ve logo source of truth seçilir. sameAs doğrulanır. Rebrand policy not edilir. Registry kaydı oluşturulur.

WebSite

Website id ve publisher relation belirlenir. inLanguage policy tanımlanır. Multi-site senaryosu incelenir. Canonical root kaynağı seçilir. Test fixture hazırlanır.

Person

Yazar profile ve @id standardı oluşturulur. Guest author senaryosu tanımlanır. sameAs verification policy hazırlanır. Duplicate author merge planı yapılır. CMS mapping belirlenir.

BlogPosting

Headline, author ve tarih mapping yazılır. WebPage relation tanımlanır. Breadcrumb relation değerlendirilir. about ve mentions optional policy olur. Required field listesi belirlenir.

Gün 11–15 — Template

Schema generator ve CMS mapping geliştirilir. Null handling ve URL normalization merkezi uygulanır. Graph output safe serialization ile hazırlanır. Automated validation build'e eklenir. Representative fixtures unit test'e dahil edilir.

CMS mapping

Field-to-property contract yazılır. Data source owner belirtilir. Missing field behavior tanımlanır. Locale mapping eklenir. Documentation versionlanır.

graph generator

Reusable functions entity node üretir. @id helper kullanılır. Duplicate node dedupe edilir. Page type config uygulanır. Output deterministic olmalıdır.

validation

JSON parse ve business rule test edilir. Canonical mismatch yakalanır. Wrong type negative test vardır. Visible content parity staging'de kontrol edilir. Failure severity tanımlanır.

Gün 16–20 — Pilot

Farklı edge case içeren 5 veya 10 sayfada yeni yapı uygulanır. Rendered HTML kontrol edilir. Rich Results Test ve Schema Validator kullanılabilir. Search Console ve internal crawler baseline ile karşılaştırılır. Hata varsa rollout öncesi template düzeltilir.

5–10 sayfa

Farklı yazar ve kategori örnekleri seçilir. Güncellenmiş ve eski içerik dahil edilir. Client rendering farklılığı varsa test edilir. Locale sample eklenebilir. Sonuç dokumente edilir.

Rich Results Test

Desteklenen item ve error kontrol edilir. Warning'ler gerçek data availability ile değerlendirilir. Preview garanti olarak yorumlanmaz. Test URL listesi saklanır. Fix sonrası yeniden çalıştırılır.

rendered HTML

Browser view source değil rendered DOM incelenir. GTM veya hydration etkisi görülür. Headline parity kontrol edilir. Duplicate script aranır. Canonical relation doğrulanır.

Gün 21–30 — Rollout

Pilot başarılıysa template daha geniş URL grubuna açılır. Full deployment feature flag veya kademeli rollout ile yapılabilir. Search Console ve crawler trendleri izlenir. Invalid artışı için rollback threshold belirlenir. 30. gün sonunda coverage ve quality baseline yeniden hesaplanır.

full deployment

Target page type'ların tamamına rollout yapılır. Legacy schema kaldırılır. Cache purge uygulanabilir. Release version kaydedilir. Smoke test çalıştırılır.

Search Console

Valid ve invalid trend takip edilir. Manual action kontrol edilir. Search appearance not alınır. Data delay dikkate alınır. Internal crawler ile çapraz doğrulama yapılır.

monitoring

Schema coverage ve canonical mismatch dashboard'a eklenir. Drift alarmı oluşturulur. Owner atanır. Weekly review yapılabilir. Sonraki 60 gün roadmap'e geçilir.

90 Günlük Kurumsal Structured Data Yol Haritası

Doksan günlük yol haritası ilk ay schema standardizasyonu, ikinci ay entity graph ve otomasyon, üçüncü ay governance ve monitoring üzerine kurulabilir. Bu süre her kurumda aynı olmak zorunda değildir. Ama aşamaları sıralamak teknik borcun kontrollü azaltılmasını sağlar. İlk ay yanlış markup düzeltilmeden AI enrichment gibi ileri özelliklere geçilmemelidir. Maturity seviyesi gerçek ihtiyaç ve ekip kapasitesine göre yükseltilmelidir.

Gün 1–30 — Schema Standardizasyonu

Page type matrix oluşturulur. BlogPosting, Service ve Organization standardı belirlenir. URL ve @id normalization uygulanır. Critical spam ve drift sorunları çözülür. CI temel validation eklenir.

Gün 31–60 — Entity Graph ve Otomasyon

Entity registry devreye alınır. Person ve Organization relation merkezi hale gelir. Schema generator shared library olur. CMS mapping otomatize edilir. Diff testing ve coverage dashboard geliştirilir.

Gün 61–90 — Governance ve Monitoring

RACI ve change approval süreçleri resmileştirilir. Search Console ve crawler monitoring birleştirilir. Quality score hesaplanır. Rollback ve incident playbook hazırlanır. Quarterly entity review planlanır.

JSON-LD Schema Maturity Model

Maturity model kurumsal structured data yönetiminin manuel snippet seviyesinden semantic governance seviyesine nasıl ilerlediğini gösterir. Her kurumun en üst seviyeye çıkması zorunlu değildir. Küçük site için template tabanlı yapı yeterli olabilir. Büyük çok dilli platformlarda merkezi entity graph ve monitoring daha fazla değer üretir. Amaç maturity seviyesini yükseltmek değil iş ihtiyacına uygun güvenilir sistem kurmaktır.

Seviye 1 — Manuel Kod Parçaları

Schema elle sayfalara eklenir. Copy-paste hatası yüksektir. Drift kolay oluşur. Validation çoğu zaman manualdır. Küçük demo dışında sürdürülebilir değildir.

Seviye 2 — Template Tabanlı Schema

Page template common JSON-LD üretir. Repetition azalır. Basic dynamic values kullanılabilir. Still entity data dağınık olabilir. Unit test eklenebilir.

Seviye 3 — CMS Dinamik Schema

Schema CMS content field'larından otomatik üretilir. Author ve date mapping merkezi olur. Null handling uygulanır. Content update schema'ya yansır. Data quality önem kazanır.

Seviye 4 — Merkezi Entity Graph

Organization, WebSite ve Person registry ile yönetilir. @id standardı oturur. Duplicate entity azalır. Page graph reusable generator ile birleşir. Migration daha kontrollü olur.

Seviye 5 — Automated Testing ve Monitoring

CI validation ve regression test vardır. Production crawler coverage ölçer. Search Console trend dashboard'a gelir. Rollback kriterleri tanımlıdır. Incident hızlı yakalanır.

Seviye 6 — Kurumsal Semantic Governance

RACI, entity owner ve change log süreçleri olgundur. Multi-site ve multilingual policy bulunur. AI enrichment controlled pipeline ile çalışabilir. Quality score yönetim metriği olur. Semantic data enterprise architecture parçasına dönüşür.

Blog ve Kurumsal İçeriklerde En Sık Yapılan Schema Hataları

En sık hatalar her sayfaya aynı schema'yı basmak, Article ile Service'i karıştırmak, Organization bilgisini farklı template'lerde farklı üretmek ve @id standardını korumamaktır. Canonical mismatch, görünmeyen FAQ ve sahte review daha ciddi risklerdir. dateModified'ın her deploy'da değişmesi de sık görülür. sameAs'ın link listesine dönüşmesi semantic kimliği bozar. Validation ve Search Console monitoring bu hataları erken tespit etmek için birlikte kullanılmalıdır.

Her Sayfaya Aynı Schema'yı Basmak

Homepage, blog ve service aynı page intent'e sahip değildir. Tek global schema yanlış type üretir. Page type mapping yapılmalıdır. GTM universal trigger risklidir. Negative test gerekir.

Article ile Service'i Karıştırmak

Blogda hizmetten bahsetmek sayfayı Service yapmaz. Hizmet sayfası da Article değildir. Primary entity page intent'e göre seçilmelidir. Wrong type search feature hedefiyle kullanılmamalıdır. Audit matrix sorunu gösterir.

Organization Bilgisini Farklı Sayfalarda Farklı Üretmek

Manuel template data drift yaratır. name, logo ve URL farklılaşabilir. Central registry kullanılmalıdır. Publisher reference aynı id'ye gitmelidir. Rebrand tek source'tan yönetilmelidir.

@id Kullanmamak

@id her durumda zorunlu değildir fakat entity reuse ve graph relation için güçlü araçtır. Büyük kurumsal sitede kimlik tutarlılığı zorlaşır. Person ve Organization duplicate olabilir. Naming standard eklenmelidir. Migration planı düşünülmelidir.

@id Formatını Değiştirmek

#org'dan #organization'a kontrolsüz geçiş identity drift yaratır. Breaking change olarak ele alınmalıdır. References güncellenir. Diff test uygulanır. Change log tutulur.

Canonical ile Farklı URL Kullanmak

HTTP veya old domain schema içinde kalabilir. Canonical service ortak source olmalıdır. Breadcrumb ve mainEntityOfPage de kontrol edilir. Migration sonrası crawler tarar. Mismatch KPI oluşturulur.

Görünmeyen FAQ Eklemek

FAQ kullanıcıya görünür olmalıdır. CMS hidden field doğrudan schema'ya aktarılmamalıdır. Accordion gerçek content olabilir. Page parity test edilir. Rich result beklentisiyle gizli soru eklenmez.

Sahte Review Eklemek

Gerçek kullanıcı review kaynağı yoksa rating kullanılmamalıdır. Self-serving skor farklıdır. Blog yıldızı hedefi yanlış gerekçedir. High-risk governance uygulanır. Bulunan markup kaldırılır.

dateModified'ı Yapay Güncellemek

Build timestamp kullanılmamalıdır. Gerçek editoryal update source olmalıdır. User-visible date ile uyum sağlanır. Static generator config test edilir. Freshness manipülasyonu önlenir.

sameAs Alanını Link Listesine Dönüştürmek

sameAs identity içindir. Backlink ve directory listesi değildir. Official profile doğrulanır. Central registry tutulur. Unknown link eklenmez.

Validation Yapmadan Yayına Almak

Syntax hatası kolayca bütün template'i etkiler. CI parse test zorunlu olmalıdır. Staging rendered validation yapılır. Pilot URL seçilir. Search Console yalnız sonradan öğrenilen hata kaynağı olmamalıdır.

Search Console'u Takip Etmemek

Production trend görünmez kalır. Invalid item artışı geç fark edilir. Manual action kontrolü yapılmaz. Internal crawler tek başına search engine view sağlamaz. Düzenli dashboard review önerilir.

Kurumsal JSON-LD Yönetiminin 12 Temel Kuralı

Kurumsal JSON-LD yönetimi teknik syntax'tan daha geniş bir disiplindir. On iki temel kural gerçek içerik, primary entity, doğru type, merkezi entity, stabil @id, canonical tutarlılığı, CMS doğrulaması, görünür içerik parity'si, automated test, monitoring, versioning ve manipülasyondan kaçınma etrafında toplanır. Bu prensipler implementation detaylarından daha uzun ömürlüdür. Framework değişse bile kurallar geçerliliğini korur. Governance document olarak ekip içinde paylaşılmaları faydalıdır.

1. Schema Sayfanın Gerçek İçeriğini Temsil Etmelidir

Structured data sayfanın alternatif hikayesi olmamalıdır. Visible content temel kaynaktır. Claim ve FAQ eşleşmelidir. Hidden SEO data üretilmemelidir. Parity test uygulanmalıdır.

2. Her URL'nin Primary Entity'si Belirlenmelidir

BlogPosting, Service veya Person gibi ana entity seçilir. WebPage bu entity'ye bağlanır. Secondary entity'ler ayrı ilişki taşır. Type stuffing azalır. Page intent netleşir.

3. En Spesifik Uygun Schema Type Kullanılmalıdır

Blog için BlogPosting, haber için NewsArticle gibi doğru seçim yapılır. Daha spesifik type gerçekten uygunsa kullanılır. Search feature beklentisi type'ı zorlamaz. CMS type mapping centraldır. Review matrix hazırlanır.

4. Site-Wide Entity'ler Merkezi Yönetilmelidir

Organization ve WebSite page-level copy olmamalıdır. Registry source kullanılır. @id reuse edilir. Rebrand kolaylaşır. Drift azalır.

5. @id Değerleri Stabil Olmalıdır

Entity id rastgele değişmemelidir. Naming convention dokümante edilir. Helper function kullanılır. Migration breaking change olabilir. Test continuity kontrol eder.

6. JSON-LD URL'leri Canonical ile Tutarlı Olmalıdır

Protocol, host ve slash standardı aynı olmalıdır. Old domain kullanılmamalıdır. Routing service source olur. Breadcrumb URL de kontrol edilir. Mismatch dashboard KPI'dır.

7. CMS Alanları Doğrulanmadan Schema'ya Aktarılmamalıdır

Free-text input validation gerektirir. Null ve HTML temizlenir. Author relation doğrulanır. High-risk claim approval alır. Safe serialization uygulanır.

8. Görünmeyen veya Kanıtlanamayan Veri Eklenmemelidir

Fake review ve hidden FAQ kullanılmaz. sameAs doğrulanır. Marketing claim factual property yapılmaz. Source lineage tutulur. Semantic trust korunur.

9. Structured Data Otomatik Test Edilmelidir

JSON parse CI'da çalışır. Page type assertion eklenir. Canonical mismatch kontrol edilir. Diff test uygulanabilir. Production crawler tamamlar.

10. Template Değişiklikleri Sonrası Monitoring Yapılmalıdır

Smoke test ilk URL'lerde yapılır. Search Console trend izlenir. Invalid artışı alarm üretir. Rollback threshold vardır. Incident test suite'i geliştirir.

11. Schema Versioning ve Change Log Kullanılmalıdır

Template version kayıtlı olmalıdır. Breaking change migration planı alır. Property değişikliği loglanır. SEO ve developer owner bilinmelidir. Historical debug kolaylaşır.

12. Schema Ranking Manipülasyon Aracı Olarak Görülmemelidir

Structured data gerçek semantic açıklama aracıdır. Fake rating ve keyword stuffing yapılmamalıdır. Rich result garanti değildir. Ranking artışı vaadi verilmemelidir. Uzun vadeli güvenilirlik önceliklidir.

Sonuç — JSON-LD Manipülasyonundan Semantic Content Architecture'a

Blog ve Kurumsal İçeriklerde JSON-LD Schema Manipülasyonu doğru ele alındığında birkaç script etiketi ekleme işi olmaktan çıkar ve içerik, yazar, kurum, URL ve yayın süreçlerini birbirine bağlayan semantic content architecture problemine dönüşür. Sağlıklı sistem daha fazla schema üretmeye değil doğru entity'leri doğru ilişkilerle tanımlamaya odaklanır. CMS field mapping, merkezi entity registry, stabil @id standardı ve automated validation aynı mimarinin parçalarıdır. Kurumsal web sitesi JSON-LD schema ve teknik SEO optimizasyon hizmeti planlanırken GTM gibi hızlı çözümler ile uzun vadeli server-side governance arasındaki fark baştan değerlendirilmelidir. Kendi kurumsal içerik altyapınızda bu yaklaşımı uygulamak için Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about adresinden bilgi alabilir ve proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects üzerinden inceleyebilirsiniz.

Amaç Daha Fazla Schema Eklemek Değildir

Kalite node veya property sayısıyla ölçülmemelidir. Gereksiz markup teknik borç oluşturur. Sayfanın gerçek amacı temel alınmalıdır. Search feature yalnız bir sonuç alanıdır. Minimal ve doğru graph daha değerlidir.

Amaç Doğru Entity'leri Doğru İlişkilerle Tanımlamaktır

Person gerçek yazara bağlanmalıdır. Organization tek kurumsal identity olmalıdır. WebPage ve BlogPosting ayrılmalıdır. Relation @id ile açık olmalıdır. Semantic model içerik yapısını temsil etmelidir.

Blog, Yazar ve Kurum Aynı Entity Graph İçinde Tutarlı Olmalıdır

BlogPosting author Person'a bağlanır. Publisher merkezi Organization olur. WebSite aynı kurumla ilişkilidir. ProfilePage Person identity'yi destekler. Graph drift automated test ile izlenir.

Dynamic Schema Yönetimi Governance Gerektirir

Otomasyon hatayı da ölçekleyebilir. Source of truth açık olmalıdır. Change approval ve rollback gerekir. Monitoring production davranışını takip eder. RACI ownership sağlar.

Structured Data Gerçek İçeriği Temsil Etmelidir

Schema görünür içerikten kopmamalıdır. Headline, author ve tarih eşleşmelidir. Fake review kullanılmamalıdır. Hidden FAQ eklenmemelidir. Trust teknik SEO'nun temelidir.

Kurumsal Ölçekte Schema Kod Değil Veri Mimarisi Problemidir

En büyük sorun JSON syntax değil source consistency olur. CMS, routing ve entity registry birlikte çalışır. Versioning ve lineage gerekir. Farklı ekipler data ownership paylaşır. Bu nedenle schema enterprise data architecture'ın küçük ama önemli bir parçasıdır.

Sıkça Sorulan Sorular

JSON-LD hakkında en sık sorular type seçimi, @id, canonical, tarih yönetimi, GTM, framework entegrasyonu ve test yöntemleri çevresinde toplanır. Tek bir template bütün sayfalara uygulanmamalıdır. Page intent ve gerçek data source her sorunun temelinde bulunur. Schema.org validity ile arama motoru feature desteği ayrıca değerlendirilmelidir. Aşağıdaki yanıtlar teknik ekiplerin sık karşılaştığı konular için kısa uygulama çerçevesi sunar.

JSON-LD nedir?

JSON-LD Linked Data bilgisini JSON benzeri formatta ifade eder. Web sayfasındaki entity ve ilişkileri açıklar. @context, @type ve @id temel kavramlardır. Schema.org vocabulary ile sık kullanılır. HTML'den ayrı script içinde yönetilebilir.

Schema markup nedir?

Schema markup sayfa içeriğini standardize entity ve property'lerle tanımlar. Arama motorlarının içeriği daha açık anlamasına yardımcı olabilir. JSON-LD, Microdata veya RDFa ile uygulanabilir. Gerçek içerikle eşleşmelidir. Ranking garantisi değildir.

JSON-LD schema manipülasyonu nedir?

Meşru anlamda schema'yı programatik olarak üretme, güncelleme ve entity'leri bağlama işlemidir. CMS field mapping buna örnektir. Yanıltıcı anlamda sahte veya alakasız veri ekleme davranışı da bu ifadeyle anılabilir. İki yaklaşım birbirinden ayrılmalıdır. Kurumsal uygulama yalnız gerçek veriyi yönetmelidir.

JSON-LD manipülasyonu Google tarafından spam sayılır mı?

Programatik schema üretmek spam değildir. Sorun markup yanıltıcı, sahte veya sayfayla alakasız olduğunda ortaya çıkar. Visible content parity önemlidir. Fake review ve hidden FAQ yüksek risk taşır. Güncel search guidelines ayrıca takip edilmelidir.

Bloglarda Article mı BlogPosting mi kullanılmalıdır?

Gerçek blog yazısı için BlogPosting daha spesifik seçimdir. Generic makale için Article kullanılabilir. Haber niteliğinde içerik NewsArticle olabilir. Type sayfa amacına göre belirlenmelidir. En fazla type eklemek hedef olmamalıdır.

BlogPosting schema nasıl oluşturulur?

Headline, description, image, author, publisher ve tarih alanları CMS'den alınabilir. WebPage ile mainEntity relation kurulabilir. @id naming standardı uygulanır. Safe serialization kullanılır. Output validation'dan geçer.

Organization schema her sayfaya eklenmeli mi?

Aynı kurumu her sayfada full object olarak tekrar etmek gerekli değildir. Merkezi Organization node oluşturulabilir. Alt sayfalar @id ile referans verebilir. Publisher relation bu id'yi kullanır. Bu yaklaşım drift'i azaltır.

Yazarlar için Person schema nasıl kullanılır?

Gerçek yazar Person olarak tanımlanabilir. name, url ve stabil @id kullanılabilir. Profil sayfası varsa ProfilePage ile ilişkilendirilebilir. sameAs yalnız doğrulanmış profilleri içerir. CMS author relation source olmalıdır.

ProfilePage schema nedir?

ProfilePage belirli kişi veya kurum profil sayfasını temsil eder. Yazar profili tipik örnektir. mainEntity Person olabilir. BlogPosting author aynı Person @id'ye bağlanabilir. Sayfa kullanıcıya gerçek bio bilgisi sunmalıdır.

@graph nedir?

@graph tek JSON-LD script içinde birden fazla entity tanımlar. Organization, WebSite ve BlogPosting birlikte bulunabilir. @id referansları ilişkileri kurar. Duplicate data azalır. Graph gereksiz node'larla büyütülmemelidir.

JSON-LD'de @id ne işe yarar?

@id entity için stabil identifier sağlar. Aynı kurum veya yazara farklı sayfalardan referans verilebilir. URL ile ilişkili olabilir ama semantic kimlik rolü taşır. Fragment convention kullanılabilir. Site-wide standard önemlidir.

mainEntity ve mainEntityOfPage arasındaki fark nedir?

mainEntity WebPage'den ana entity'ye relation kurar. mainEntityOfPage entity'den WebPage'e geri relation sağlar. Yönleri farklıdır. BlogPosting ve WebPage arasında birlikte kullanılabilir. @id'ler farklı olmalıdır.

JSON-LD canonical URL ile aynı olmalı mı?

Page URL ve @id tabanı canonical policy ile tutarlı olmalıdır. HTTPS, hostname ve trailing slash farkları önlenmelidir. Fragment id farklı entity'leri ayırabilir. Redirected eski URL kullanılmamalıdır. Canonical service ortak source olmalıdır.

Schema'da dateModified ne zaman değiştirilmelidir?

Gerçek ve anlamlı editoryal güncellemede değiştirilmelidir. Build veya deployment timestamp kullanılmamalıdır. Visible update date ile uyumlu olmalıdır. Typo düzeltmesi için kurum policy'si belirlenebilir. CMS revision source kullanılabilir.

Schema ile içeriğin görünür metni aynı olmak zorunda mı?

Anlam açısından uyumlu olmalıdır. Exact string eşitliği her property için şart değildir. Headline, author, date ve FAQ gibi içerikler çelişmemelidir. Technical @id gibi alanların görünür olması gerekmez. Parity testi kritik alanları kontrol etmelidir.

Görünmeyen FAQ için FAQ schema kullanılabilir mi?

Kullanıcıya sunulmayan soru cevapları yalnız JSON-LD içinde eklemekten kaçınılmalıdır. Accordion içerik kullanıcı tarafından erişilebiliyorsa farklıdır. CMS hidden field otomatik schema'ya taşınmamalıdır. Google feature desteği ayrıca değişebilir. Gerçek içerik önceliklidir.

Sahte review schema kullanmanın riski nedir?

Sahte review kullanıcıyı ve arama sistemini yanıltır. Structured data spam riski doğurabilir. Manual action olasılığı değerlendirilmelidir. Review gerçek kullanıcı kaynağına dayanmalıdır. Bulunduğunda kaldırılması gerekir.

sameAs nasıl kullanılmalıdır?

sameAs aynı entity'nin güvenilir harici kimliklerini gösterir. Resmi sosyal profiller uygun olabilir. Backlink ve directory listesi değildir. Yanlış kişiye ait profil eklenmemelidir. Registry üzerinden doğrulama yapılabilir.

JSON-LD Google Tag Manager ile eklenebilir mi?

Evet, Custom HTML tag ile eklenebilir. Hızlı pilot için faydalı olabilir. Trigger ve dynamic variable dikkatle test edilmelidir. Version drift ve debugging riski vardır. Kurumsal kalıcı çözümde server-side yaklaşım genellikle daha yönetilebilirdir.

Server-side JSON-LD mi GTM mi daha iyidir?

Uzun vadeli kurumsal yönetimde server-side çoğu zaman daha kontrollüdür. Source code ve CI test kullanılabilir. GTM hızlı pilot sağlar. Küçük site farklı karar verebilir. Seçim governance ve mevcut mimariye göre yapılmalıdır.

React ve Next.js sitelerde JSON-LD nasıl oluşturulur?

Server-side object oluşturulabilir. SSR, SSG veya Server Components kullanılabilir. Safe serialization gerekir. Client injection mümkün olsa da ekstra rendering riski getirir. CMS mapping shared library içinde tutulabilir.

Headless CMS'te schema nasıl yönetilir?

Content model structured field'lar sağlar. Mapping layer Schema.org property'lerine dönüştürür. Entity registry site-wide data verir. Frontend validated graph'ı render eder. Automated validation publish ve CI aşamasında çalışır.

JSON-LD nasıl test edilir?

Önce JSON parse testi yapılır. Schema.org vocabulary validator kullanılabilir. Rich Results Test search feature uygunluğunu kontrol eder. Rendered HTML incelenir. Search Console production trendini tamamlar.

Rich Results Test ile Schema Markup Validator arasındaki fark nedir?

Rich Results Test Google'ın desteklediği search features üzerine odaklanır. Schema Markup Validator genel Schema.org vocabulary'sini kontrol eder. Bir markup birinde valid olup diğerinde rich feature üretmeyebilir. Bu normaldir. İki araç farklı amaçlara sahiptir.

Search Console structured data hataları nasıl takip edilir?

İlgili raporlarda valid ve invalid trend izlenebilir. Deployment sonrası ani değişim araştırılır. Error sample URL'ler incelenir. Internal crawler ile root cause doğrulanır. Fix sonrası validation süreci kullanılabilir.

Schema markup ranking faktörü müdür?

Schema'yı garantili sıralama artışı sağlayan doğrudan araç olarak görmek doğru değildir. Semantic understanding ve rich result uygunluğuna katkı sunabilir. Search appearance CTR'yi etkileyebilir. Ranking ve presentation ayrı kavramlardır. Kesin sıralama vaatlerinden kaçınılmalıdır.

JSON-LD AI aramalarında fayda sağlar mı?

Machine-readable entity context sunabilir. Bazı sistemlerin içeriği anlamasına yardımcı olabilir. Ancak kullanım şekli platforma göre değişir. Citation veya görünürlük garantisi sağlamaz. İçerik kalitesi yine temel faktördür.

AI ile otomatik schema oluşturulabilir mi?

AI draft ve mapping önerisi üretebilir. Entity extraction yapabilir. Ancak hallucination ve fake entity riski vardır. Automated validation ve human review gerekir. Production source of truth AI olmamalıdır.

Schema otomasyonu için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. JavaScript ve TypeScript web framework'lerinde uygundur. Python audit ve crawling için güçlüdür. PHP WordPress'te doğal seçimdir. Enterprise sistemler Java veya .NET kullanabilir.

Open source JSON-LD araçları geliştirilebilir mi?

Evet, generator, validator ve diff tool geliştirilebilir. CI plugin yapılabilir. Community test case katkısı sunabilir. Gerçek kurumsal secret veya personal data public repository'ye eklenmemelidir. Documentation projeyi sürdürülebilir kılar.

Kurumsal schema governance nasıl oluşturulur?

SEO, developer, content ve data owner rolleri belirlenir. RACI hazırlanır. Entity registry ve template versioning kullanılır. Change log ve rollout policy uygulanır. Monitoring ownership açık tutulur.

JSON-LD schema audit'i nasıl yapılır?

Önce URL ve page type envanteri çıkarılır. Rendered JSON-LD parse edilir. Expected type, @id ve canonical karşılaştırılır. Entity drift ve content parity incelenir. Sonuçlar remediation matrix ile aksiyona dönüştürülür.

Blog ve Kurumsal İçeriklerde JSON-LD Hakkında Ek Sık Sorulan Sorular

Aşağıdaki sorular özellikle kurumsal bloglarda doğru type seçimi, dinamik üretim, temel Article alanları, hatalı markup önleme ve teknik SEO danışmanlığı açısından sık gündeme gelir. Blog ve kurumsal içeriklerde JSON-LD schema nasıl uygulanır sorusunun yanıtı yalnız bir kod örneğinden ibaret değildir. Content model, canonical service ve entity registry aynı süreçte ele alınmalıdır. Otomasyon kullanıldığında hata da çok hızlı ölçeklenebileceği için validation temel gereksinimdir. JSON-LD schema ve teknik SEO danışmanlığı yakınımda şeklinde araştırma yapan ekipler bu bütünsel yaklaşımı değerlendirmelidir.

Blog ve kurumsal içeriklerde JSON-LD Schema nasıl doğru uygulanır?

Önce her URL'nin gerçek page type'ı ve primary entity'si belirlenmelidir. Blog yazıları için BlogPosting, kurumsal ana entity için Organization ve sayfa nesnesi için WebPage gibi doğru türler seçilebilir. CMS alanları structured data property'lerine açık mapping ile bağlanmalı, canonical ve @id değerleri aynı URL normalization sisteminden üretilmelidir. Görünür içerikle headline, author, date ve FAQ gibi alanların eşleştiği automated testlerle doğrulanmalıdır. Production sonrasında Search Console ve internal crawler ile coverage, invalid item, canonical mismatch ve schema drift izlenmelidir.

BlogPosting ve Article Schema arasındaki fark nedir ve hangisi kullanılmalıdır?

Article genel yazılı içerik türüdür, BlogPosting ise blog gönderileri için daha spesifik bir Article alt türüdür. Kurumsal blogdaki gerçek blog yazılarında BlogPosting genellikle daha açıklayıcı seçimdir. Farklı editoryal yapıya sahip genel makale sayfasında Article tercih edilebilir. Haber niteliğindeki içerikler ayrıca NewsArticle kapsamında değerlendirilebilir. En doğru yaklaşım, rich result beklentisine göre değil sayfanın gerçek içerik türüne göre en spesifik doğru type'ı seçmektir.

JSON-LD içerisinde author, publisher, datePublished, dateModified ve mainEntityOfPage alanları nasıl yapılandırılmalıdır?

author gerçek Person veya gerektiğinde Organization entity'sine stabil @id ile bağlanmalıdır. publisher kurumsal bloglarda merkezi Organization entity'sini referans verebilir ve her sayfada farklı kurum nesnesi yaratılmamalıdır. datePublished ilk yayın zamanından, dateModified ise yalnız gerçek editoryal güncellemeden üretilmelidir. Her iki tarih de güvenilir CMS alanından alınmalı ve ISO 8601 formatında sunulmalıdır. mainEntityOfPage BlogPosting entity'sini ilgili WebPage ile bağlamalı ve bu ilişkinin canonical URL ile tutarlı olduğu otomatik test edilmelidir.

Dinamik veya otomatik üretilen JSON-LD Schema verilerinde hatalı ve çakışan işaretlemeler nasıl önlenir?

İlk adım her property için tek bir source of truth belirlemektir. Organization verisi master data'dan, author bilgisi CMS profile'dan, article bilgisi content entry'den ve URL verisi canonical service'ten alınabilir. Shared schema generator, null handling, safe serialization ve @id naming standardını merkezi biçimde uygular. CI/CD sürecinde JSON parse, page-type assertion, canonical mismatch ve schema diff testleri çalıştırılmalıdır. Deployment sonrası automated crawler ile duplicate entity, schema drift ve görünür içerik parity sorunları izlenerek geniş çaplı hatalar erken fark edilebilir.

Blog ve kurumsal içerikler için JSON-LD Schema optimizasyonu konusunda yakınımda teknik SEO danışmanlığı nerede bulabilirim?

JSON-LD schema ve teknik SEO danışmanlığı yakınımda şeklinde araştırma yapan kurumların yalnız birkaç schema snippet'i ekleyen yaklaşım yerine CMS mapping, canonical yönetimi, entity graph, validation ve monitoring süreçlerini birlikte ele alan teknik çalışmaları değerlendirmesi daha faydalıdır. Diyarbakır Yazılım Topluluğu hakkında https://www.diyarbakiryazilim.com.tr/about üzerinden bilgi alınabilir. Topluluğun ve teknik proje çalışmalarının örneklerini https://www.diyarbakiryazilim.com.tr/projects adresinden incelemek mümkündür. Dinamik URL ve canonical altyapısına ilişkin teknik yaklaşım için https://www.diyarbakiryazilim.com.tr/posts/e-ticaret-siteleri-icin-dinamik-url-ve-slug-uretim-algoritmalari adresindeki içerik de schema URL standardizasyonunu planlarken tamamlayıcı bir kaynak olabilir. Kurumsal bir çalışmada ilk adım olarak küçük bir URL grubunda schema audit yapılması, ardından merkezi entity ve template standardının kurulması daha kontrollü ve ölçülebilir ilerleme sağlar.