Teknik rehber
Schema markup nasıl eklenir?
Yapılandırılmış veri (JSON-LD) rehberi: hangi şema tipleri gerekir, Organization ve FAQPage nasıl yazılır, nasıl doğrulanır — kopyala-yapıştır bloklarla.
Schema markup (yapılandırılmış veri), sayfadaki bilgiyi makinelerin kesin okuyabileceği biçimde etiketleyen koddur; günümüzde en yaygın taşıyıcısı sayfaya gömülen JSON-LD bloklarıdır. Kuruluş adı, adres, hizmetler ve sık sorulan sorular bu işaretlemeyle modele tahminsiz aktarılır. İnsan ziyaretçi bu kodu görmez — model için sayfanın kimlik kartıdır.
Yapay zeka için neden önemli?
Çünkü modelin sizi önerebilmesi için önce sizi tekil bir varlık olarak tanıması gerekir: kim, nerede, ne yapıyor. Serbest metinden bunu çıkarmak tahmindir; şema aynı bilgiyi kesin biçimde verir. Tahmin yerine beyan — varlık netliği denen şeyin teknik karşılığı büyük ölçüde budur.
Şemanın gücü tek sayfada değil, tutarlılıkta: sitenizdeki kuruluş bilgisi, dizin kayıtlarınız ve sosyal profillerinizle birebir aynı olduğunda model bu kaynakları tek varlıkta birleştirir. Taramamızda gördüğümüz tablo bunun neden kritik olduğunu anlatıyor: 46 firmadan 37'si cevaplarda görünüyordu ama ortalama Anlatı Kontrolü %21,6 idi — model firmaları tanıyor, fakat bilgiyi başkasından alıyor. Kendi sayfanızın kaynak olabilmesi, sayfanın makinece okunur olmasından geçiyor.
Beklentiyi de doğru kuralım: şema tek başına sıralama veya görünürlük satın almaz — o bir zemin taşıdır. Kesin sonuç vaat eden değil, bilgiyi doğru okutan bir katmandır; erişilebilir site, cevap yapılı içerik ve şema birlikte çalışır. Sıra ve bütünün içindeki yeri için uygulama bölümüne bakın.
Şemanın bir başka değeri, insan diliyle makine dili arasındaki boşluğu kapatması. Bir sayfada 'İzmir'de kurulduk, üç kişilik bir ekibiz' cümlesi insana çok şey anlatır ama modelin bundan adres, kuruluş türü ve ekip bilgisini kesin çıkaracağının hiçbir teminatı yoktur. Aynı bilgiyi şemayla işaretlediğinizde tahmin ortadan kalkar: addressLocality alanı İzmir'dir, nokta. Serbest metin şiirdir, şema ise düzgün doldurulmuş bir formdur — model şiiri yorumlar ama formu olduğu gibi okur, ikincisinde yanılma payı çok daha düşüktür.
Hangi şema tiplerini kullanmalıyım?
Yüzlerce tip var; işletme sitesinin işini beş tanesi görür. Organization temeldir ve her sayfada durur; FAQPage soru-cevap bölümlerini işaretler; Article bilgi sayfalarını; Service hizmetleri; Person kurucuyu kuruluşa bağlar. Önce Organization'ı doğru kurun; kimliğinizin temeli odur ve kalan tipler ona bağlanarak anlam kazanır.
| Tip | Neyi işaretler | Nerede kullanılır |
|---|---|---|
| Organization | Kuruluş kimliği: ad, adres, kurucu, profiller | Her sayfada — temel |
| FAQPage | Soru-cevap çiftleri | SSS bölümü olan sayfalarda |
| Article | Yazı: başlık, yazar, tarihler | Rehber ve bilgi sayfalarında |
| Service | Sunulan hizmet ve kapsamı | Hizmet sayfalarında |
| Person | Kişi — worksFor ile kuruluşa bağlı | Kurucu ve yazar bilgisinde |
Seçim ilkesi basit: sayfada gerçekten ne varsa onu işaretleyin. SSS'i olmayan sayfaya FAQPage koymak, hizmet anlatmayan sayfaya Service eklemek işe yaramaz — şema, içeriğin makinece okunur kopyasıdır, süsü değil. Bu sitede beş tipin beşi de canlı olarak duruyor; herhangi bir sayfamızın kaynak kodunda application/ld+json bloklarını açıp gerçek örnekleri inceleyebilirsiniz.
Organization nasıl yazılır?
Aşağıdaki blok eksiksiz bir başlangıçtır: kimlik, adres, kurucu ve sameAs ile sosyal profiller. Kendi bilgilerinizle doldurup her sayfanın koduna ekleyin. İki alan özellikle önemli: sameAs, modelin sizi diğer platformlardaki hesaplarınızla birleştirmesini sağlar; founder ise kuruluşa gerçek bir kişiyi, yani doğrulanabilir bir varlığı bağlar.
Organization — tam örnek
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://ornekfirma.com/#kurulus",
"name": "Örnek Firma",
"url": "https://ornekfirma.com",
"description": "Örnek Firma, İzmir merkezli bir danışmanlık şirketidir; küçük işletmelere finansal planlama hizmeti verir.",
"email": "info@ornekfirma.com",
"address": {
"@type": "PostalAddress",
"addressLocality": "İzmir",
"addressCountry": "TR"
},
"founder": {
"@type": "Person",
"name": "Ad Soyad",
"worksFor": { "@id": "https://ornekfirma.com/#kurulus" }
},
"sameAs": [
"https://instagram.com/ornekfirma",
"https://linkedin.com/company/ornekfirma"
]
}
</script>Üç yazım kuralı bloğu sağlam yapar. description alanına kendi başına anlamlı tek cümlelik tanımınızı koyun ve aynı cümleyi her platformda birebir kullanın — tutarlılık, doğrulanmışlık sinyalidir. @id verin ve sabitleyin: diğer şemalar kuruluşa bu kimlikle bağlanır, sayfadan sayfaya değişmemelidir. sameAs listesine yalnızca gerçekten sizin olan ve yaşayan profilleri yazın — ölü bağlantı güven eksiltir.
FAQPage nasıl yazılır?
Sayfanızdaki gerçek soru-cevap çiftlerini Question ve acceptedAnswer düğümlerine taşırsınız — görünen metinle şemadaki metin birebir aynı olmalıdır. Model bu bloktan soruyu ve cevabı hazır çift olarak alır; cevaba hazır yapının en doğrudan işaretlemesi budur. Aşağıdaki örnek iki soruluk tam bir bloktur; aynı kalıba sayfanızdaki her gerçek soru-cevap çiftini ekleyebilirsiniz.
FAQPage — tam örnek
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Ücretlendirme nasıl işliyor?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Aylık sabit ücret modeliyle çalışıyoruz; kapsam ve tutar sözleşmede açıkça yazılır."
}
},
{
"@type": "Question",
"name": "İlk görüşme ücretli mi?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Hayır — ilk görüşme ücretsizdir ve yaklaşık yarım saat sürer; ihtiyacınızı dinleyip nasıl çalıştığımızı anlatırız."
}
}
]
}
</script>Tek uyarı, bire bir eşleşme: şemadaki soru ve cevaplar sayfada görünen SSS metniyle aynı olmalı. Sayfada olmayan soruları şemaya gömmek — görünmez içerik — hem güven sinyalini bozar hem doğrulama araçlarında sorun çıkarır. Doğru kurulum, SSS bölümünü ve şemayı aynı kaynaktan üretmektir; biz de sitemizde tam olarak bunu yapıyoruz — sayfadaki metin ile şemadaki metin tek listeden geliyor, ayrışamıyor. Bu disiplin küçük görünür ama uzun vadede en çok işe yarayan alışkanlıktır: içerik her güncellendiğinde şema da kendiliğinden güncellenir, elle senkron tutma yükü ve onun kaçınılmaz hataları ortadan kalkar.
Nereye konur, nasıl doğrulanır?
JSON-LD bloğu, sayfanın HTML koduna script etiketiyle gömülür — head veya body içinde, her ikisi de geçerli. Her sayfa kendi gerçeğini taşır: temel Organization her yerde, FAQPage yalnızca SSS'i olan sayfada. Yayınladıktan sonra doğrulamadan geçirmeden bitti saymayın; iki ücretsiz araç bu işi görür.
- Google Rich Results Test: sayfa adresinizi verin — Google'ın şemanızı okuyup okuyamadığını ve zengin sonuca uygunluğu gösterir
- Schema.org doğrulayıcısı (validator.schema.org): tip ve alan hatalarını, eksik zorunlu alanları listeler
- Yayın sonrası kaynak kontrolü: sayfanın kaynak kodunda bloğun gerçekten çıktığını görün — bazı site altyapıları özel kodu sessizce süzebiliyor
- Her şablon değişikliğinden sonra tekrar test edin: tema ve eklenti güncellemeleri bloğu sessizce kırabilir
Doğrulama araçları hatayı satır satır gösterir, o yüzden korkulacak bir adım değil: bir eksik tırnak veya fazladan virgül bulunduğunda araç tam yerini söyler. Yayınlamadan önce iki dakikalık bu kontrol, aylarca fark edilmeyen bozuk bir şemadan çok daha ucuza gelir — kurduğunuz kimlik kartının gerçekten okunabildiğinden emin olmadan sayfayı bitmiş saymayın.
Kurulum yerleşkeden yerleşkeye değişir: hazır site platformlarında “özel kod” alanına yapıştırılır, kendi kodunuzu yazıyorsanız şablona eklenir. Önemli olan blokların sayfayla birlikte sunucudan gelmesi — sonradan JavaScript ile enjekte edilen şema, bazı okuyucular için hiç var olmamıştır. Bu, bot erişimi konusuyla aynı kök soruna dayanır: model sayfanın ham hâlini okur, tarayıcının işlediği hâlini değil. Şemanız ne kadar doğru olursa olsun, sunucudan gelmiyorsa okunmayabilir. Erişim tarafı zaten açık olmalı: şemayı okuyacak botların kapıdan girebildiğinden bot izinleri sayfasıyla emin olun.
Sık yapılan hatalar neler?
Beş hata tekrar edip duruyor: görünen içerikle çelişen şema, bozuk JSON sözdizimi, her sayfaya kopyalanan aynı blok, kimliksiz düğümler ve test edilmeden yayınlanan kod. Hepsinin ortak sonucu aynı — şema ya hiç okunmaz ya da güven sinyalini tersine çevirir. Kaçınması kolay; liste aşağıda.
- Görünmez içerik: sayfada olmayan bilgiyi şemaya gömmek — şema içeriğin kopyasıdır, gizli genişletmesi değil
- Sözdizimi hatası: eksik virgül veya tırnak tüm bloğu geçersiz kılar — sessizce; bu yüzden doğrulayıcı şart
- Kopyala-yapıştır tekrarı: her sayfaya aynı FAQPage veya alakasız Article koymak — her sayfa kendi gerçeğini işaretler
- Kimlik kopukluğu: @id kullanmamak veya sayfadan sayfaya değiştirmek — kurucu, hizmet ve yazı kuruluşa bağlanamaz
- Tanım tutarsızlığı: şemadaki description ile sitedeki ve dizinlerdeki tanımın farklı olması — varlık sinyalini böler
- Test etmemek: yayınlayıp unutmak — tema güncellemesi bloğu kırar, aylarca kimse fark etmez
Bu hataların ortak kökü, şemayı bir defalık süs sanmak. Doğrusu onu içerikle aynı yerden üretmek ve içerik değiştikçe birlikte değişmesini sağlamaktır — elle eşzamanlılık, llms-full.txt rehberinde anlattığımız sebeple burada da sürdürülemez. Kurulumunuzun bugünkü durumunu merak ediyorsanız alan adınızı girin: teknik denetim, yapılandırılmış verinizin var olup olmadığını da raporluyor.
Sık sorulan sorular
Şema eklemek sıralamayı doğrudan yükseltir mi?
Hayır — ve yükselttiğini kesin dille vaat edene temkinli yaklaşın. Şemanın işi sıralama puanı değil, kesinliktir: bilginizi tahminsiz okutur, zengin sonuç biçimlerine aday yapar ve varlık tanınırlığını besler. Etkisi zemin etkisidir — tek başına değil, erişim ve içerik yapısıyla birlikte çalışır.
Kod bilmeden ekleyebilir miyim?
Evet — bu sayfadaki blokları kopyalayıp kendi bilgilerinizle doldurmanız yeterli; çoğu site platformunun “özel kod” alanı bunun için var. Dikkat edilecek tek teknik nokta tırnak ve virgülleri bozmamak. Yapıştırdıktan sonra doğrulayıcıdan geçirin; hata varsa hangi satırda olduğunu söyler.
JSON-LD yerine başka format kullanabilir miyim?
Eski yöntemler (HTML özniteliklerine gömülü işaretlemeler) hâlâ geçerlidir ama günümüzün önerilen ve en kolay yönetilen biçimi JSON-LD: içerikten ayrı tek blok, okunabilir, taşınabilir. Yeni kuruluma başlıyorsanız tartışmasız JSON-LD; eski işaretlemesi olan siteyi de acilen değil, elden geçirme sırasında dönüştürmek yeter.
Kaç şema bloğu eklemek gerekir — sınır var mı?
Sayı sınırı yok; ölçü, sayfanın gerçeğidir. Tipik bir sayfa iki-üç blok taşır: her yerde Organization, içerik sayfasında Article, SSS varsa FAQPage. Aynı bilgiyi iki kez işaretlemek gerekmiyor — düğümleri @id ile birbirine bağlayıp her gerçeği tek yerde tanımlamak, kalabalık bloktan daha değerlidir.
İlgili sayfalar
- GEO ve AEOGEO ve AEO'nun tanımı, aralarındaki fark, Anlatı Kontrolü ile ölçümü ve kendi başınıza atabileceğiniz teknik adımlar — tek sayfada.
- Yapay zeka botlarıGPTBot'tan Google-Extended'a bot listesi, sitenizin gerçekten açık olup olmadığını kontrol etme adımları ve farkında olmadan engelleme tuzakları.
- llms.txt rehberillms.txt dosyasının işi, dürüst sınırları, robots.txt'ten farkı ve kopyala-yapıştır çalışan tam örnekler — llms-full.txt dahil.
Peki sizin durumunuz ne?
Alan adınızı girin; sektörünüzün gerçek sorularını yapay zeka motorunda çalıştırıp markanızın kaç kez önerildiğini ve bilginin nereden alındığını ölçelim. Ücretsiz.