Geçen hafta bir müşterimiz şunu sordu: "Kod tabanımızda bir schemas.ts dosyası duruyor ama kimse neden orada olduğunu ve içindeki blokların ne işe yaradığını hatırlamıyor." Bu hiç de istisna değil. Önüme gelen projelerin en az yarısında, bir geliştiricinin bir zamanlar yerleştirdiği, sonra kimsenin dokunmadığı bir JSON-LD dosyası vardır — dokümantasyonu yok, amacı belirsiz ve çoğu zaman hâlâ doğru çalışıp çalışmadığını bilen de yok.
Bu gerçekten yazık; çünkü structured data, ChatGPT, Perplexity ve Google'ın AI Overviews gibi sistemlerin tam da açlık duyduğu bilgi türü. Makine tarafından okunabilen bir bağlam sunar: "Biz şu şirketiz, şurada bulunuyoruz, sık sorulan soruların yanıtları bunlar." Bu bağlam olmadığında bir dil modeli, yapılandırılmamış metne bakıp tahmin yürütmek zorunda kalır. Bağlam olduğunda ise elinde doğrudan ve güvenilir bir kaynak olur.
Bu yazıda en çok kullanılan üç schema türünü — Organization, LocalBusiness ve FAQPage — bugün uygulayabileceğiniz somut örneklerle anlatıyorum.
Yapay zeka çağında structured data neden hâlâ önemli
Structured data (çoğunlukla JSON-LD) 2011'den beri var; schema.org, Google, Bing, Yahoo ve Yandex'in ortak girişimiyle kuruldu. O günkü amaç basitti: arama motorlarının içeriği anlamasına yardımcı olmak, böylece zengin sonuçlar gösterebilmeleri — yıldızlı değerlendirmeler, çalışma saatleri, arama sonuçlarında açılır FAQ kutuları.
Değişen şu: structured data'nızın "okuyucusu" artık yalnızca bir sonuç listesi için indeksleme yapan bir tarayıcı değil. Artık sizin sitenize hiç uğramayan bir kullanıcıya yanıt yazmak üzere içeriğinizi ayrıştıran bir dil modeli de var. Biri ChatGPT'ye "Utrecht'te yapay zeka danışmanlığı yapan şirketler hangileri" diye sorduğunda, JSON-LD'nizin yanıta dahil edilme olasılığı, bir pazarlama metni parçasının yorumlanma olasılığından kat kat yüksek.
Bunun nedeni structured data'nın belirsizliğe yer bırakmaması. "Utrecht'in tam kalbindeyiz" gibi bir cümleyi bir modelin yorumlaması ve varsayımda bulunması gerekir. addressLocality: "Utrecht" içeren bir PostalAddress nesnesinin ise yoruma ihtiyacı yoktur — doğrudan çıkarılabilen bir gerçektir.
Bu tür bir optimizasyonun arkasındaki daha geniş strateji için GEO'nun tam olarak ne anlama geldiği yazımızı da okumanızı öneririm — structured data, daha büyük bir bütünün yalnızca bir parçası.
Neredeyse her zaman ihtiyaç duyacağınız üç schema türü
Organization: siz kimsiniz, gerçekten?
Organization schema temeldir. AI sistemlerinin en sık yanıtlayamadığı soruyu yanıtlar: Bu şirket ne, ona neden güveneyim? Bu schema ana sayfanızda yer almalı; ideal olarak layout üzerinden her sayfada tekrarlanmalı (ya da ona referans verilmeli).
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "ChatGPT, Perplexity ve Google AI Overviews tarafından bulunmak isteyen işletmeler için AI-native web geliştirme ve GEO/AEO optimizasyonu.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Burada önemli olan şu: sameAs süs değildir. Bu alan şirketinizi dışarıdan doğrulanabilir kaynaklara bağlar — LinkedIn sayfanız, varsa Wikipedia maddeniz, Crunchbase profiliniz. AI modelleri bir varlığın "gerçek" olup olmadığına karar verirken bu tür çapraz referansları kullanır. sameAs alanı olmayan bir Organization schema, bağlantısı olmayan bir LinkedIn profili gibidir: teknik olarak geçerli, ama pek ikna edici değil.
description alanını meta açıklamanızdan kopyalamayın. Ne yaptığınızı ve kime hitap ettiğinizi net biçimde anlatan bir cümle yazın — "sektörün önde gelen ajansıyız" değil; somut olarak ne, kimin için, neden farklı.
LocalBusiness: fiziksel olarak bulunmanız gerekiyorsa kritik
Fiziksel bir konumunuz varsa — ofis, mağaza, klinik — LocalBusiness (ya da daha spesifik bir alt türü: ProfessionalService, Restaurant, Store) vazgeçilmezdir. AI asistanlarının "yakınımdaki" sorularını yanıtlayabilmesinin arkasındaki doğrudan neden bu schema'dır.
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
Sık yapılan iki hata var. Birincisi: geo koordinatları unutuluyor; oysa sistemlerin "en yakın" sorgularında mesafe hesaplamak için kullandığı tam olarak bu veri. İkincisi: @type çoğu zaman fazla genel bırakılıyor. Daha spesifik bir alt tür mevcutsa varsayılan olarak LocalBusiness kullanmayın — Google ve AI sistemleri, spesifik bir türle (mevcutsa Dentist, Accountant gibi) niyete çok daha isabetli eşleme yapabilir.
Bu konuyu yerel işletmeler için GEO yazımızda daha ayrıntılı ele alıyorum; birden fazla şube yönetiminin nasıl yapılacağına da orada değiniyorum.
FAQPage: AEO'nun en hafife alınan schema'sı
Bir AI yanıtında alıntılanıp alıntılanmamanızı doğrudan etkileyen tek bir schema türü varsa o da FAQPage. Neden? Çünkü bir dil modelinin içeriğinizi kendi yanıtında yeniden kullanabilmesi için ihtiyaç duyduğu soru-cevap yapısını — çoğu zaman kelimesi kelimesine — hazır sunar.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "AI-native bir web sitesi ne kadar tutar?",
"acceptedAnswer": {
"@type": "Answer",
"text": "AI-native bir web sitesi aşamalar hâlinde teslim edilir. Maliyeti sayfa sayısına, dil sayısına ve mevcut sistemlerle kurulacak entegrasyonlara bağlıdır. Kendi kapsamınıza göre, aşama başına saat bazlı bir teklif isteyin."
}
},
{
"@type": "Question",
"name": "Structured data teknik bir ekip olmadan da çalışır mı?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Evet. Çoğu CMS ve framework, JSON-LD'yi eklentiler veya basit kod snippet'leri üzerinden destekler. Organization veya FAQPage schema'sını uygulamak için ayrı bir geliştiriciye ihtiyacınız yok."
}
}
]
}
Buradaki tuzak şu: insanlar FAQPage schema'sını gerçek sorular yerine pazarlama sorularıyla ("Neden bizi seçmelisiniz?") dolduruyor. Oysa kullanıcıların arama motoruna ya da AI asistanına gerçekten sorduğu soruları kullanmak gerekiyor. Google'daki "People Also Ask" (bunları başkaları da soruyor) bölümüne bakın veya ChatGPT ve Perplexity'de konunuz etrafında hangi soruların çıktığını kendiniz test edin. Yanıtları tek başına anlaşılır yazın — bir yanıt, soruyu yeniden okumadan da anlaşılabilmeli; çünkü bir dil modeli onu tam olarak böyle kesip alır.
Bunu pratik AEO rehberi yazımızda daha kapsamlı işledim; hangi soruların yanıtlanmaya değer olduğunu nasıl belirleyeceğiniz de dahil.
Dağınık dosyadan çalışan sisteme: pratik uygulama
Bunu kod tabanınızda nereye yerleştirmelisiniz?
Elinizde zaten bir lib/schemas.ts (ya da benzeri) varsa, mantıklı yapı şudur: statik metinler değil, içeriğinize göre JSON-LD nesneleri üreten fonksiyonlar dışa aktarın. Şöyle bir şey:
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Bu yaklaşım, schema'ların içerikten kopmasını önler. Sık karşılaşılan bir sorun şudur: sayfadaki FAQ metni güncellenir ama arkasındaki schema birlikte güncellenmez. Görünen içerik ile schema verisi arasındaki tutarsızlık tam olarak istemediğiniz şeydir; hem Google hem de AI tarayıcıları nezdinde güveni sarsar.
Yayına almadan önce test edin ve doğrulayın
Bir şeyi yayınlamadan önce Google'ın Rich Results Test aracını ve Schema.org'un kendi doğrulayıcısını kullanın. Sık yapılan bir hata @type alanındaki yazım yanlışıdır (örneğin Organization yerine Britanya yazımıyla Organisation yazmak) — schema o zaman sessizce başarısız olur, sitenizde hiçbir hata mesajı görmezsiniz ve ancak "neden hiçbir şey çalışmıyor" diye düşündüğünüzde fark edersiniz.
Ayrıca robots.txt dosyanızın, bu verileri okuması gereken AI tarayıcılarını engellemediğinden emin olun — yapılandırmanızın doğru olduğundan şüpheleniyorsanız robots.txt ve AI tarayıcıları rehberi yazımıza bakın.