AI Search İçin Varlık (Entity) ve Schema Mimarisi

Şema, süsleme değil; makine tarafındaki gerçekliğin tanımıdır

Yapılandırılmış veri uzun süre "zengin sonuç almak için eklenen ek kod" olarak görüldü. Üretken arama katmanının yaygınlaşmasıyla bu tanım geçersizleşti. Bugün şema, bir kurumun makine tarafındaki kimliğini kuran veri modelidir: hangi varlıksınız, hangi varlıklarla ilişkilisiniz, hangi hizmeti hangi coğrafyada veriyorsunuz ve bu iddiaların doğrulanabilir karşılığı nerede? Bir dil modeli yanıt üretirken bu ilişki grafiğini kullanır; grafikte yeri olmayan kurum, yanıtta da yer almaz.

Ayrım şudur: parçalı şema (her sayfada birbirinden habersiz bloklar) ile grafik şeması (@id ile birbirine referans veren, site genelinde tek bir varlık ağı oluşturan yapı). Zengin sonuç için birincisi yeterlidir; AI Search görünürlüğü için ikincisi zorunludur.

Varlık grafiğinin çekirdeği: @id disiplini

Grafik kurmanın tek şartı, her varlığa kalıcı ve benzersiz bir @id vermek ve diğer sayfalarda bu varlığı tekrar tanımlamak yerine kimliğine referans vermektir. Yaygın hata, her sayfada tam Organization bloğunun tekrar edilmesidir; bu, ayrıştırıcı için potansiyel olarak farklı varlıklar üretir ve güven sinyalini böler.

{
 "@context":"https://schema.org",
 "@graph":[
  {"@type":"Organization","@id":"https://www.berpel.com/#organization",
   "name":"Berpel Digital Solutions","url":"https://www.berpel.com/",
   "foundingDate":"2007","sameAs":["https://www.instagram.com/berpeldigital/","https://www.linkedin.com/company/berpel-digital-solutions","https://maps.app.goo.gl/RQb1NKeFmjf7xWrP6","https://maps.app.goo.gl/jbaxibCiDkkq1Hyv8"],
   "department":[{"@id":"https://www.berpel.com/#ofis-istanbul"},
                 {"@id":"https://www.berpel.com/#ofis-sakarya"}]},
  {"@type":"WebSite","@id":"https://www.berpel.com/#website",
   "url":"https://www.berpel.com/","inLanguage":"tr-TR",
   "publisher":{"@id":"https://www.berpel.com/#organization"}}
 ]
}

Bu çekirdek bir kez kurulduktan sonra, sitedeki her Article, Service, WebPage ve FAQPage bloğu publisher, author, provider veya isPartOf alanlarında yalnızca {"@id":"..."} referansı taşır. Sonuçta tek bir kurum varlığı, çevresinde onlarca içerik ve hizmet varlığı bulunan tutarlı bir grafik oluşur.

Çoklu lokasyon: Organization + LocalBusiness departman modeli

Birden fazla fiziki ofisi olan kurumlarda en sık görülen hata, ana sayfada tek bir LocalBusiness tanımlamaktır. Bu yapı, ikinci şehirdeki aramalarda kurumu tamamen dışarıda bırakır. Doğru model, çatı Organization varlığına her ofisi ayrı LocalBusiness (veya ProfessionalService) varlığı olarak department ilişkisiyle bağlamaktır. Her departman kendi address, geo, telephone, openingHoursSpecification ve areaServed alanlarını taşır.

{"@type":"ProfessionalService",
 "@id":"https://www.berpel.com/#ofis-sakarya",
 "name":"Berpel Digital Solutions — Sakarya",
 "parentOrganization":{"@id":"https://www.berpel.com/#organization"},
 "address":{"@type":"PostalAddress","addressLocality":"Serdivan",
   "addressRegion":"Sakarya","addressCountry":"TR"},
 "geo":{"@type":"GeoCoordinates","latitude":40.7569,"longitude":30.3597},
 "areaServed":[{"@type":"City","name":"Sakarya"},{"@type":"City","name":"Kocaeli"}],
 "openingHoursSpecification":[{"@type":"OpeningHoursSpecification",
   "dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday"],
   "opens":"09:00","closes":"18:00"}]}

Kritik nokta çift yönlülüktür: ana sayfa departmanları listelerken, her lokasyon sayfası da parentOrganization ile geri referans vermelidir. Tek yönlü bağlar grafikte zayıf kenar oluşturur ve varlık çözümlemesinde kopmalara yol açar.

Hizmet varlıkları ve hizmet katalogu

Hizmet sayfaları çoğu sitede yalnızca WebPage olarak işaretlenir; oysa hizmetin kendisi bağımsız bir varlıktır. Service tipi, serviceType, provider, areaServed ve hasOfferCatalog alanlarıyla tanımlandığında model "bu kurum hangi işi yapıyor" sorusunu tahminle değil veriyle yanıtlar.

{"@type":"Service","@id":"https://www.berpel.com/rehber/ai-search-entity-ve-schema-mimarisi.html#service",
 "serviceType":"Teknik SEO",
 "provider":{"@id":"https://www.berpel.com/#organization"},
 "areaServed":[{"@type":"Country","name":"Türkiye"}],
 "hasOfferCatalog":{"@type":"OfferCatalog","name":"Teknik SEO paketleri",
  "itemListElement":[
   {"@type":"Offer","itemOffered":{"@type":"Service","name":"Teknik SEO denetimi"}},
   {"@type":"Offer","itemOffered":{"@type":"Service","name":"Log analizi ve crawl bütçesi"}},
   {"@type":"Offer","itemOffered":{"@type":"Service","name":"Core Web Vitals iyileştirme"}}]}}

Hizmet varlıkları aynı zamanda iç linkleme mimarisinin makine tarafındaki karşılığıdır. Bir hizmet sayfası Service olarak tanımlanıp, onu destekleyen rehber içerikleri Article olarak about veya mentions alanıyla bu hizmete bağlandığında, hub-spoke yapısı yalnızca HTML bağlantılarıyla değil veri düzeyinde de kurulmuş olur.

İçerik varlıkları: Article, FAQPage ve HowTo

Rehber içeriklerinde üç tip birlikte çalışır. Article içeriğin kendisini, FAQPage yanıt kutularını, HowTo ise adımlı süreçleri tanımlar. Üçünün de aynı sayfada bulunması sorun değildir; ancak her biri sayfada gerçekten görünen içeriği yansıtmalıdır. Sayfada olmayan bir soruyu FAQPage içine yazmak, en hızlı güven kaybı yollarından biridir.

• Article.about — içeriğin işlediği varlıkları (Thing) listeler; konu netliğini artırır.
• Article.mentions — geçen ama ana konu olmayan varlıklar; aşırı kullanımdan kaçınılmalıdır.
• Article.isPartOf — hub sayfasına (CollectionPage) bağlar; topikal küme ilişkisini kurar.
• speakable — sesli yanıt yüzeyleri için okunabilir bölümleri işaretler.
• citation — dış kaynak referansı; doğrulanabilirlik sinyalini güçlendirir.

sameAs, knowsAbout ve varlık çözümlemesi

Varlık çözümlemesi, sistemin "bu isim hangi gerçek dünya varlığına karşılık geliyor" sorusunu yanıtlama sürecidir. Türkiye pazarında marka adlarının benzerliği yüksek olduğu için bu adım kritiktir. sameAs alanına eklenen her doğrulanabilir profil (LinkedIn şirket sayfası, sektör dernekleri, ticaret sicil kayıtları, doğrulanmış sosyal hesaplar) çözümleme güvenini artırır. knowsAbout ise kurumun uzmanlık alanlarını makine okunur biçimde bildirir ve konu-otorite eşlemesinde kullanılır.

Burada tutarlılık, kapsamdan önemlidir. Beş profilde birebir aynı unvan ve adres, on beş profilde farklı yazımlardan daha güçlü sinyal üretir. Denetimlerde en sık bulduğumuz sorun, ticari unvan ile marka adının karışık kullanılması (ör. bazı yerlerde "Berpel", bazılarında "Berpel Dijital", bazılarında "Berpel Digital Solutions") ve bunun grafikte üç ayrı varlık üretmesidir.

Doğrulama ve dağıtım disiplini

Şema kodu yazmak işin kolay tarafıdır; asıl mesele yüzlerce sayfada tutarlılığı korumaktır. Statik veya CMS tabanlı fark etmeksizin uyguladığımız yöntem, şemayı sayfa şablonundan üretmektir: kurum çekirdeği tek bir parçadan gelir, sayfaya özgü alanlar (başlık, tarih, kırıntı yolu, hizmet adı) değişken olarak enjekte edilir. Elle yazılmış şema blokları kaçınılmaz olarak zamanla birbirinden ayrışır.

1. Her yayın öncesi Schema.org validator ve Google Rich Results Test ile sözdizimi ve uygunluk kontrolü.
2. Site genelinde @id çakışması taraması: aynı kimliğin farklı içerikle iki kez tanımlanmaması.
3. Kırık referans taraması: bir @id'ye referans veriliyorsa, o kimliğin en az bir yerde tam tanımı bulunmalıdır.
4. Search Console'da "Yapılandırılmış veri" raporlarının haftalık izlenmesi; hata sayısındaki artış çoğunlukla şablon değişikliğinin yan etkisidir.

# Tüm sayfalardaki JSON-LD bloklarını çıkarıp söz dizimi doğrulaması
grep -ro 'application/ld+json' public/ | wc -l
python3 - <<'PY'
import json,re,pathlib
for f in pathlib.Path('public').rglob('*.html'):
    for m in re.findall(r'<script type="application/ld\+json">(.*?)</script>', f.read_text(encoding='utf-8'), re.S):
        try: json.loads(m)
        except Exception as e: print(f, str(e)[:60])
PY

Şema ile içerik arasındaki tutarlılık kuralı

Üretken sistemler, yapılandırılmış veriyi görünür içerikle karşılaştırır. Şemada yazan fiyat sayfada yoksa, şemada tanımlı çalışma saati iletişim sayfasındakiyle çelişiyorsa veya aggregateRating hiçbir gerçek değerlendirmeye dayanmıyorsa, sistem yalnızca ilgili alanı değil kaynağın tümüne olan güvenini düşürür. Bu nedenle politikamız nettir: şemada yalnızca sayfada görünen ve doğrulanabilir olan veri bulunur.

Aynı kural tarih alanları için de geçerlidir. datePublished ile dateModified arasındaki fark, içerikte gerçek bir değişikliğe karşılık gelmelidir. Otomatik olarak her gün güncellenen dateModified değerleri kısa vadede tazelik izlenimi verir, orta vadede tutarsızlık sinyali üretir.

Vaka: çok şehirli hizmet kurumunda grafik yeniden yapılandırması

Üç şehirde hizmet veren bir kurumsal hizmet firmasında, başlangıç durumu şuydu: her sayfada tekrar eden tam LocalBusiness bloğu, üç farklı unvan yazımı, hizmet sayfalarında hiç şema yok ve blog yazılarında yazar tanımsız. Yapılan çalışma: tek kurum çekirdeği, üç departman varlığı, dokuz Service varlığı, tüm içeriklerde @id referanslı yazar bağlantısı ve hub sayfası için CollectionPage.

Sekiz hafta sonunda ölçülen değişim; harita paketinde ikinci ve üçüncü şehir için görünürlük kazanımı, marka adı sorgularında bilgi panelinin doğru adres ve hizmet listesiyle oluşması ve sabit soru setinde alıntı payının %9'dan %26'ya çıkması oldu. İçerik hacmi hiç artırılmadı; yalnızca mevcut gerçeklik makine okunur biçimde doğru tanımlandı.

Kontrol listesi

• Tek Organization çekirdeği, kalıcı @id ile; her sayfada tekrar tanımlanmıyor.
• Her fiziki ofis ayrı LocalBusiness/ProfessionalService, çift yönlü department ↔ parentOrganization bağı.
• Her hizmet sayfasında Service + hasOfferCatalog; rehber içerikleri about ile hizmete bağlı.
• İçeriklerde Article + BreadcrumbList + (gerçek içerikle örtüşen) FAQPage.
• Yazar varlıkları Person + worksFor + knowsAbout + tutarlı sameAs.
• Şemadaki her veri sayfada görünür ve doğrulanabilir; uydurma puanlama yok.
• Şema şablondan üretiliyor, elle çoğaltılmıyor; yayın öncesi otomatik doğrulama var.
• Kırık @id referansı ve kimlik çakışması için düzenli tarama yapılıyor.

Varlık ve şema mimarisi, GEO çalışmasının görünmeyen altyapısıdır. İçerik alıntılanabilirliği bu altyapı olmadan da bir noktaya kadar yükselir; ancak kurumun kimliği, konumları ve hizmetleri grafikte doğru tanımlanmadığında, alıntı marka değerine dönüşmez. İki katman birlikte kurulduğunda ise sonuç, yalnızca daha çok görünmek değil, doğru bağlamda ve doğru kimlikle görünmektir.

E-ticaret tarafı: Product, Offer ve stok gerçekliği

E-ticaret projelerinde varlık grafiği bir katman daha karmaşıklaşır; çünkü ürünler yalnızca içerik değil, durumu sürekli değişen ticari varlıklardır. Product varlığı sku, gtin, brand ve offers alanlarıyla tanımlanmalı; Offer içinde price, priceCurrency, availability ve priceValidUntil gerçek veriyle beslenmelidir. Stokta olmayan bir ürünün şemada InStock görünmesi, hem zengin sonuç yaptırımına hem de üretken yanıt katmanında güven kaybına yol açar.

Kategori sayfalarında ItemList kullanılarak ürün sıralaması makine okunur hâle getirilir; her öğe kendi ürün sayfasındaki @id'ye referans verir. Böylece kategori sayfası, ürünleri yeniden tanımlamak yerine grafikteki mevcut varlıklara bağlanır. Marka varlığı (Brand) ayrı bir kimlikle tanımlanıp hem ürünlere hem kuruma bağlandığında, "hangi markanın ürünleri" biçimindeki sorgularda doğru eşleşme sağlanır. Değerlendirme verisi kullanılacaksa Review nesneleri gerçek ve sayfada görünür olmalıdır; toplu aggregateRating değerleri kaynağı gösterilmeden verilmemelidir.

Türkçe içerikte varlık isimlendirme

Türkçe'nin ekli yapısı, varlık çözümlemesinde ek bir zorluk üretir. "SEO ajansı", "SEO ajansları", "SEO ajansıyız" biçimleri aynı varlığa işaret eder ancak ham eşleşmede farklı dizeler üretir. Şema alanlarında bu nedenle her zaman yalın hâl kullanılmalı, ek almış biçimler yalnızca görünür metinde bırakılmalıdır. Aynı şekilde İngilizce terimlerin Türkçe karşılıklarıyla birlikte verilmesi (ör. "tarama bütçesi (crawl budget)") hem okur hem model için eşleme köprüsü kurar.

Coğrafi varlıklarda ilçe-il ilişkisi açıkça yazılmalıdır. "Serdivan" tek başına belirsizdir; addressLocality Serdivan, addressRegion Sakarya biçimindeki tanım, modelin doğru idari birimle eşleşmesini sağlar. Hizmet alanı tanımlarında da il, ilçe ve komşu iller ayrı ayrı listelenmeli; "Marmara Bölgesi" gibi geniş ifadeler tek başına bırakılmamalıdır.

Grafik sağlığını izleme

Şema bir kez kurulup unutulacak bir yapı değildir. Tema güncellemeleri, eklenti değişiklikleri, yeni sayfa şablonları ve içerik göçleri grafiği sessizce bozar. İzleme çerçevemiz dört başlıkta çalışır. Birincisi kapsam: şema içeren sayfa oranı; ikincisi geçerlilik: sözdizimi ve tip hatası olmayan blok oranı; üçüncüsü bütünlük: kırık @id referansı sayısı; dördüncüsü tutarlılık: şemadaki künye, saat ve fiyat verisinin sayfa içeriğiyle örtüşme oranı.

Bu dört metrik aylık raporlanır ve her biri için eşik tanımlanır. Kapsam %95'in, geçerlilik %100'ün altına düştüğünde ya da kırık referans sayısı sıfırdan farklı olduğunda müdahale tetiklenir. Deneyimimizde grafik bozulmalarının büyük çoğunluğu içerik ekibinden değil, teknik dağıtımlardan kaynaklanır; bu yüzden kontrol, yayın süreçlerinin bir parçası hâline getirilmelidir.

Uygulama yol haritası

1. Envanter: Mevcut tüm JSON-LD bloklarının çıkarılması, tip dağılımının ve çakışan kimliklerin listelenmesi.
2. Çekirdek: Tek Organization + WebSite tanımı, kalıcı kimliklerin belirlenmesi ve şablona taşınması.
3. Lokasyonlar: Her ofis için departman varlığı, çift yönlü bağlar, harita ve künye tutarlılığının dış kaynaklarla hizalanması.
4. Hizmetler: Hizmet sayfalarına Service ve katalog, rehber içeriklerine about bağlantıları.
5. İçerik: Article, BreadcrumbList, gerçek içerikle örtüşen FAQPage ve yazar varlıkları.
6. Doğrulama: Otomatik sözdizimi ve referans taramasının yayın hattına eklenmesi.
7. Ölçüm: Kapsam, geçerlilik, bütünlük ve tutarlılık metriklerinin aylık raporlanması; alıntı payı ölçümüyle birlikte değerlendirilmesi.

Bu yedi adım, orta ölçekli bir kurumsal sitede tipik olarak dört–altı haftada tamamlanır ve sonrasında bakım maliyeti düşüktür. Yatırımın karşılığı tek bir zengin sonuç görseli değil; kurumun makine tarafındaki kimliğinin doğru, tutarlı ve referans verilebilir hâle gelmesidir. AI Search yüzeylerinde kalıcı görünürlüğün temeli budur.

Zengin sonuç ile AI yanıtı arasındaki fark

Klasik zengin sonuçlar kural tabanlıdır: belirli tipler, belirli zorunlu alanlar ve belirli görünüm biçimleri. Üretken yanıt katmanı ise olasılıksaldır; şema burada garanti değil, girdi kalitesidir. Bu farkı anlamamak iki yönlü hataya yol açar. Birinci hata, zengin sonuç almadığı için şemayı gereksiz saymaktır; oysa şemanın asıl işlevi görsel kazanım değil, varlık grafiğine katkıdır. İkinci hata, şemayı sihirli bir anahtar sanıp içerik ve erişim katmanını ihmal etmektir; grafikte doğru tanımlı ama erişilemeyen ya da özgün bilgi taşımayan bir kurum yine alıntılanmaz.

Doğru okuma şudur: şema kurumun kim olduğunu, içerik ise ne bildiğini anlatır. Yanıt katmanında kaynak seçimi bu ikisinin kesişiminde yapılır. Bir sorgu için en iyi bilgiye sahip olan ama kimliği belirsiz kaynak, bilgisi zayıf ama kimliği net kaynağa göre daha sık alıntılanır; ancak marka adı yanıtta geçmez, yalnızca bağlantı verilir. Marka bahsi, ancak kimlik grafiği tam olduğunda oluşur ve ticari değer büyük ölçüde buradadır.

Sık karşılaşılan sekiz sorun ve çözümü

• Her sayfada tam kurum bloğu tekrarı: Çekirdeği ana sayfada tanımlayın, diğer sayfalarda yalnızca @id referansı verin.
• Kırık referans: Tanımı hiç yapılmamış bir kimliğe referans vermek grafikte boşluk üretir; yayın öncesi otomatik tarama şart.
• Sayfada olmayan SSS: Şemadaki her soru görünür içerikte de bulunmalı; aksi hâlde tip yaptırımı gelir.
• Eklenti ve tema çakışması: İki farklı kaynaktan üretilen çelişkili bloklar; tek üretim noktası belirleyin.
• Yanlış tip seçimi: Hizmet firması için Store, ajans için Corporation yerine ProfessionalService ve Organization daha doğru eşleşir.
• Görsel ve logo alanı eksikliği: logo ve image mutlak URL olmalı, yönlendirme içermemelidir.
• Dil ve bölge tanımsızlığı: inLanguage ve adres alanları eksik bırakıldığında yerel eşleşme zayıflar.
• Test edilmemiş dağıtım: Şablon değişikliği sonrası doğrulama yapılmaması, en yaygın sessiz bozulma nedenidir.

Bu sekiz sorunun tamamı, şema üretimini tek bir şablon katmanına toplayıp yayın hattına otomatik doğrulama ekleyerek yapısal olarak önlenebilir. Elle yönetilen şema, sayfa sayısı arttıkça kaçınılmaz biçimde tutarsızlaşır; bu nedenle mimari kararı en baştan doğru vermek, sonradan yapılacak temizlikten çok daha ucuzdur.

Özet: grafik olgunluk seviyeleri

Kurumların varlık mimarisini dört olgunluk seviyesinde değerlendiriyoruz. Seviye 0: şema yok veya yalnızca eklenti varsayılanı var; kurum makine tarafında tanımsız. Seviye 1: kurum ve web sitesi tanımlı, ancak sayfalar arasında tekrar ve tutarsızlık var. Seviye 2: tek çekirdek, @id referanslı içerik ve hizmet varlıkları, doğrulanmış künye; zengin sonuç ve harita görünürlüğü stabil. Seviye 3: lokasyon ve hizmet varlıkları hub-spoke içerik grafiğiyle birleşmiş, otomatik doğrulama ve aylık sağlık metrikleri işliyor; AI yanıt yüzeylerinde marka bahsi ölçülebilir hâle gelmiş.

Çoğu kurumsal site bugün Seviye 1'dedir ve Seviye 2'ye geçiş genellikle iki–üç haftalık teknik bir çalışmadır. Asıl fark Seviye 3'te açılır; çünkü orada şema, içerik stratejisiyle aynı veri modelini paylaşır ve her yeni içerik grafiği otomatik olarak güçlendirir.