Sohbet Odaları İçin Schema.org Yapılandırılmış Veri Nasıl Eklenir? (JSON-LD Örnekleriyle Adım Adım)

Sohbet odaları için içerik sadece metin ve tasarımdan ibaret değil. Asıl kritik nokta, arama motorlarının sayfanın “ne anlattığını” daha net anlayabilmesi için doğru bağlamı kurabilmeniz. Bu bağlamın en pratik yolu sohbet odaları için yapılandırılmış veri (Schema.org) nasıl eklenir yaklaşımıdır. Özellikle sohbet odası detayları, şehir/kategori sayfaları ve canlı oturum sayfaları gibi farklı sayfa tiplerinde doğru şema seçimi; görünürlük ve zengin sonuç (rich result) potansiyelini doğrudan etkiler.

Bu rehberde sohbet odası sayfalarına odaklanarak, hangi varlıkların işaretleneceğini, hangi Schema türlerinin mantıklı eşleştirmeler olduğunu ve JSON-LD ile nasıl uygulanacağını adım adım ele alacağım. Ayrıca dinamik (JS ile yüklenen) içeriklerde yapılandırılmış verinin doğru render edilmesi, doğrulama/test adımları ve yayın sonrası izleme süreçleri için de uygulanabilir bir kontrol listesi sunacağım.

Yapılandırılmış veri nedir, sohbet odalarında neden önemlidir?

Yapılandırılmış veri, bir web sayfasındaki bilgilerin makinelere anlaşılır şekilde etiketlenmesidir. Schema.org ise bu etiketleme için ortak bir sözlük sunar. Böylece arama motoru, sayfanın “bir sohbet odası mı”, “bir liste mi”, “şehir bazlı bir sayfa mı” gibi unsurlarını daha net okumaya başlar.

Sohbet odalarında bu önem daha da artar; çünkü içerik çoğu zaman dinamik, filtrelenmiş ya da kategori/konum temelli şekilde hazırlanır. Yapılandırılmış veri, sayfanın bağlamını güçlendirerek indeksleme sürecinde daha tutarlı bir çerçeve sağlar. Tabii bu tek başına “kesin sonuç” demek değildir; yine de doğru şema + doğru eşleme, Google’ın sayfayı yorumlama kalitesine ciddi katkı verir.

Bu yazıda farklı sayfa türlerini ayrı ayrı ele alacağım: sohbet odası detay sayfaları, liste/kategori sayfaları ve canlı oturum/etkinlik benzeri sayfalar. Çünkü “aynı şemayı her yere koymak” yerine, sayfanın sunduğu varlığa uygun şemayı seçmek gerçekten fark yaratır. Böylece SERP vaadini somutlaştırırsınız: sayfanızın doğru alanlarının işaretlendiğini test ederek Google Rich Results Test ve doğrulama raporlarında netlik elde edersiniz.

Sohbet odası sayfalarında hangi varlıkları işaretlemelisiniz?

Şema tasarımında ilk adım, sayfanın hangi “gerçek varlığı” anlattığını netleştirmektir. Sohbet platformlarında bu varlıklar çoğu zaman sayfa bazında değişir: oda detay sayfası, liste sayfası, kategori/şehir sayfası, canlı oturum sayfası gibi.

Bu noktada özellikle dikkat edilmesi gereken bir çizgi var: kullanıcı profilleri veya rol/kimlik gibi kişisel veri ve kimliklendirme alanlarını, bu yazının oda sayfası bağlamında işaretlemeye çalışmayın. Odak; sayfanın sunduğu sohbet deneyimi ve sayfaya konu olan “oda/oturum/kategori” varlıkları olmalıdır.

• Sohbet odası detay sayfası: Oda adı, açıklama, URL, görünür kategori/etiket, konum etiketi (varsa), sayfanın kimliği.
• Sohbet odaları liste/kategori sayfası: Filtre uygulanan liste; ör. “İstanbul sohbet odaları”, “Yeni odalar”, “Müzik temalı odalar”.
• Canlı etkinlik/oturum sayfası: Başlık, tarih/saat, konum veya sanal etkinlik bilgisi.
• Kullanıcı/roller: Bu yazının kapsamı içinde doğrudan “role” gibi kimliklendirmeleri Schema ile genelleştirmeyin; KVKK ve veri doğruluğu riskleri doğurabilir.

Schema.org’da sohbet odaları için en uygun şema türleri: olası eşleşmeler ve seçim kriterleri

Schema.org tarafında “ChatRoom” kavramı biraz tartışmalı bir alan. Bazı topluluklarda “ChatRoom” gibi türleri görürsünüz; ancak pratikte Google’ın gerçekten hangi yaklaşımı desteklediği ve hangi alanların zengin sonuç tetiklediği senaryodan senaryoya değişebilir. Bu yüzden seçim yaparken “en doğal eşleşme”yi ve “görünen içerikle tutarlılığı” merkeze alın.

Sohbet odası detay sayfası için pratikte genelde WebPage ya da oda bağlamını güçlendirmek adına Thing/CreativeWork benzeri yaklaşımlara kayılır. Liste sayfalarında ItemList mantıklı bir çerçeve sunar. Canlı oturum sayfalarında ise Event gibi bir modelleme daha net görünür. En kritik kriter aynı: Etiketlediğiniz özelliklerin sayfada gerçekten görünmesi ve söylediklerinizin doğrulanabilir olması.

WebPage yaklaşımı neden sık kullanılır?

Çünkü sohbet odası detay sayfası özünde “bir sayfa” anlatır. İçerik belli bir konu ve bağlama sahiptir. WebPage üzerinde headline, description, URL gibi alanları tutarlı verdiğinizde, Google sayfanın içeriğini daha düzgün bir bağlama oturtabilir.

ItemList yaklaşımı neden liste/kategori sayfalarında daha güçlü?

Çünkü bu sayfalar “bir dizi oda” sunar. ItemList ile 10-20 öğeyi doğru formatta anlattığınızda hem sayfanın yapısı daha anlaşılır olur hem de öğelerin listelenme mantığı netleşir. Ayrıca sayfalama stratejisini kurarken de size sağlam bir temel verir (ör. “sayfa 2”).

ChatRoom benzeri bir yaklaşım eklemeli misiniz?

Eğer kullandığınız Schema türü Google’ın o tür için kullandığı alanlarla gerçekten uyumlu değilse ya da sayfada doğrulanmayan alanları eklemeye itiyorsa, bu zayıf bir sinyale dönüşebilir. Bu yüzden ilerlerken şu soruyla hareket edin: “Tam olarak neye ihtiyacımız var?” Zengin sonuç hedefiniz varsa yalnızca doğrulanabilen alanları kullanın ve her zaman Rich Results Test ile geri bildirim alın.

JSON-LD ile uygulama: temel yapı, @context/@type, property eşleştirme

JSON-LD, yapılandırılmış veriyi sayfaya script etiketi içinde eklemenin en kolay yollarından biridir. Temel mantık şudur: @context değerini Schema.org olarak verirsiniz ve @type alanında kullanacağınız şema türünü belirtirsiniz. Ardından property mantığıyla sayfanızın görünür içerik alanlarını Schema özelliklerine eşlersiniz.

Önerilen akış: Önce sayfadaki görünür başlık/açıklama/oda adı gibi veriyi sabitleyin. Sonra bu veriyi JSON-LD’de birebir kullanın. Örneğin sayfada “Oda adı: Moda Rock Sohbet Odası” gibi net bir alan varsa, JSON-LD’de name/headline gibi alanlara aynı değeri yazın. Sayfada olmayan bir “ek bilgi”yi JSON-LD’ye eklemek, doğrulama testlerinde uyumsuzluk ve kalite düşüşü riski doğurur.

1. Sayfa türünü belirleyin: oda detayı mı, liste/kategori mi, etkinlik/oturum mu?
2. En doğal Schema modelini seçin: detay için WebPage oda bağlamı, liste için ItemList, etkinlik için Event benzeri.
3. JSON-LD’yi sayfanın başında/şablonda konumlandırın; mümkünse SSR (server-side render) ile ilk HTML’de üretin.
4. İçerik tutarlılığı kontrolü yapın: JSON-LD’deki ad/açıklama sayfada görünür mü?
5. Google test araçlarıyla doğrulayın ve sonuçları Search Console raporlarıyla izleyin.

Sohbet odası sayfası için örnek JSON-LD (kopyala-yapıştır)

Aşağıdaki örnek, sohbet odası detay sayfası için “sayfa bağlamını” ve oda kimliğini güçlendirmeye odaklanır. Lütfen değerleri kendi sayfanıza göre güncelleyin ve yalnızca sayfada görünen bilgileri kullanın.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Moda Rock Sohbet Odası",
  "description": "Moda Rock sohbet odasında müzik severlerle canlı sohbet et. Sohbet odasına katıl, yeni insanlarla tanış.",
  "url": "https://ornek-sitesi.com/sohbet-odalari/moda-rock",
  "isPartOf": {
    "@type": "WebSite",
    "name": "Ornek Sohbet Sitesi",
    "url": "https://ornek-sitesi.com/"
  },
  "about": {
    "@type": "Thing",
    "name": "Moda Rock Sohbet Odası",
    "sameAs": []
  }
}
</script>

Bu modelde bilerek “oda adını, açıklamasını, sayfa URL’sini” veriyoruz. Eğer kategori/konum gibi etiketleri de sayfanızda görünür şekilde sunuyorsanız, bunu about içinde eklemeyi düşünebilirsiniz. Ancak “şehir/kategori” bilgisi sayfada yoksa eklemeyin; tutarsızlık risktir.

İsterseniz kategori/konum etiketini görünür alana bağlamak için örneği şöyle güçlendirebilirsiniz (örnek mantık): “İstanbul” gibi bir etiket sayfada görünüyorsa, about içindeki nesneye ek alanlar yerleştirin veya açıklamada doğal biçimde yansıtın.

Sohbet odaları liste/kategori sayfası için örnek JSON-LD (ItemList benzeri) ve sayfalama stratejisi

Liste/kategori sayfaları, “birden fazla oda” içerir. Bu yüzden ItemList ile 10-20 öğe aralığında örnek bir yapı kurmak hem pratik hem de yönetilebilir bir başlangıçtır. Elbette her öğe için en azından görünen bir başlık ve mümkünse öğenin kendi URL’si olmalıdır.

Sayfalama stratejisi: Eğer sayfanız “sayfa 1 / sayfa 2” gibi bölünüyorsa, JSON-LD’de yalnızca o sayfada görünen öğeleri işaretleyin. Böylece test ve doğrulama sırasında liste öğeleri ile sayfadaki içerik çakışmaz; ayrıca canonical yaklaşımınızı da daha doğru konumlandırırsınız. Parametreli URL kullanıyorsanız canonical stratejisini ayrıca sağlamlaştırın.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "İstanbul Sohbet Odaları",
  "url": "https://ornek-sitesi.com/sohbet-odalari/istanbul",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Kadıköy Genel Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/kadikoy-genel" },
    { "@type": "ListItem", "position": 2, "name": "Beşiktaş Film Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/besiktas-film" },
    { "@type": "ListItem", "position": 3, "name": "Beyoğlu Oyun Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/beyoglu-oyun" },
    { "@type": "ListItem", "position": 4, "name": "Şişli Teknik Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/sisli-teknik" },
    { "@type": "ListItem", "position": 5, "name": "Karaköy Yaratıcı Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/karakoy-yaratıcı" },
    { "@type": "ListItem", "position": 6, "name": "Etiler İngilizce Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/etiler-ingilizce" },
    { "@type": "ListItem", "position": 7, "name": "Nişantaşı Müzik Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/nisantasi-muzik" },
    { "@type": "ListItem", "position": 8, "name": "Sarıyer Doğa Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/sariyer-doga" },
    { "@type": "ListItem", "position": 9, "name": "Ataşehir Yeni Nesil Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/atasahir-yeni-nesil" },
    { "@type": "ListItem", "position": 10, "name": "Üsküdar Kitap Sohbet", "url": "https://ornek-sitesi.com/sohbet-odalari/uskudar-kitap" }
  ]
}
</script>

Bu örnekte 10 öğe verdim; ihtiyaç olursa 20’ye kadar çıkabilirsiniz. Ancak her zaman “gerçekten sayfada görünen” öğelerle sınırlayın. Kullanıcı filtre değiştiriyorsa daha fazla öğe eklemek, yapılandırılmış veriyi içerikle uyuşmaz hale getirebilir.

Dinamik içerik için (JS ile yüklenen oda bilgileri) önerilen uygulama yaklaşımı

Sohbet platformlarında oda bilgileri çoğu zaman API’den çekilir ve JS ile DOM’a basılır. Burada kritik nokta şudur: Google’ın ilk HTML’de gördüğü veri ile daha sonra render edilen veri aynı değilse yapılandırılmış verinin değerlendirilmesi zayıflayabilir.

Bu nedenle önerilen yaklaşım, JSON-LD’yi mümkünse SSR (server-side render) ile üretmektir. SSR mümkün değilse, “ön-render” benzeri bir yaklaşımla en azından sayfa iskeleti ve ilk içerik seti gelir gelmez JSON-LD’nin de DOM’a eklenmesini sağlayın. Ayrıca Rich Results Test ve Search Console testlerinde, görünür içerikle uyumu doğrulayın.

<!-- Örnek yaklaşım: Oda detay sayfasında ilk render sırasında veri varsa JSON-LD’yi de bas -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Kadıköy Genel Sohbet",
  "description": "Kadıköy Genel Sohbet odasında canlı sohbet et.",
  "url": "https://ornek-sitesi.com/sohbet-odalari/kadikoy-genel"
}
</script>

<!-- Sonra JS ile oda listesi güncellense bile, JSON-LD’nin de görünür veriyle uyumunu koruyun. -->

Pratikte en sağlıklı model şudur: sunucuda HTML üretimi sırasında ilk oda/filtre seti bilinir ve JSON-LD de o set üzerinden üretilir. Filtre tamamen kullanıcı etkileşimiyle oluşuyorsa, her filtre varyasyonu için ayrı sayfa/kaynak üretmek ve JSON-LD’yi o sayfada göstermek genellikle daha temiz sonuç verir.

CMS/tema entegrasyonu: WordPress/özelleştirilmiş tema/SSR-CSR farkları (genel çerçeve)

CMS entegrasyonunda amaç, JSON-LD’nin doğru sayfa şablonuna “garanti” ile eklenmesini sağlamaktır. WordPress tarafında bu genellikle tema şablonları, block/shortcode çıktıları veya özel bir plugin katmanı üzerinden yürür. Yine de kullandığınız yöntem ne olursa olsun “önbellek” ve “dinamik alanların” JSON-LD’ye etkisini düşünmeniz gerekir.

SSR-CSR farkına özellikle dikkat edin: SSR’de JSON-LD ilk HTML ile gelir; bu da doğrulama/test süreçlerini kolaylaştırır. CSR’de ise JSON-LD sonradan basılır. Bazı arama motoru süreçleri gecikmeli render’a tolerans gösterebilir; ancak en güvenlisi ilk yüklemede görünür hale getirmektir. Eğer “tema JSON-LD’yi sayfa altına basıyor” gibi bir durum varsa, bunu kontrol edin; testlerde görünmediğinde yanlış negatif alabilirsiniz.

CMS entegrasyonunda ayrıca canonical/parametre yönetimiyle uyumu koruyun. Örneğin liste/kategori sayfaları parametrele filtreleniyorsa, canonical stratejiniz yapılandırılmış verinin doğruluğunu da etkiler. Bu noktada Chat Sitelerinde Parametreli URL’ler (Query String) İçin Canonical Nasıl Ayarlanır? | SEO Rehberi yaklaşımı işinizi kolaylaştırır.

Doğrulama ve test: Rich Results Test, Schema Markup Validator, Search Console raporları

Yapılandırılmış veriyi ekledikten sonra “çalışıyor” demek yeterli değil. Asıl mesele doğru alanları doğru formatta aktardığınızın test edilmesi. En pratik test sırası genellikle şöyle ilerler: önce Schema Markup Validator ile sözdizimi/şema uyumluluğunu kontrol edin; ardından Google Rich Results Test ile zengin sonuç açısından değerlendirmeyi tekrar gözden geçirin.

Sonrasında Search Console tarafında yapılandırılmış veri raporlarını takip edin. Buradaki hedef sadece hataları görmek değil; hataların kaynağını sayfa türüne göre ayırmaktır. Örneğin “ItemList’te beklenen property eksik” tarzı bir hata çoğu zaman liste sayfası şablonundan çıkar; detay sayfası için ayrı bir düzeltme gerekebilir.

Yaygın hatalar (Sık yapılan hatalar / Kaçınılması gerekenler)

Yapılandırılmış veri uygulamalarında en sık karşılaşılan sorun, şemanın “kopyala-yapıştır” ile her sayfaya aynı şekilde uygulanmasıdır. Sohbet odalarında ise sayfa türleri farklıdır; bu yüzden detay ve liste şemalarını aynı property setiyle ele almak çoğu zaman sorun üretir.

Kaçınılması gereken diğer hatalar şunlardır:

• Görünmeyen içerik eklemek: JSON-LD’de yer alan ad/açıklama sayfada kullanıcıya gösterilmiyorsa tutarsızlık riski artar.
• Kişisel veri veya doğrulanmamış iddia: Kullanıcı kişisel verisi, doğrulanmamış istatistik iddiaları veya “kesin” sonuç cümleleri eklemek kalite sinyalini zedeler.
• Eksik zorunlu alan mantığı: Şema türünün mantıklı değerlendirilmesi için sık kullanılan alanların eksik bırakılması sorun çıkarır.
• Spam sinyali gibi algılanabilecek aşırı şema: Aynı sayfaya gereksiz tekrarlarla çok sayıda JSON-LD eklemek sinyalin gürültüye dönüşmesine yol açabilir.

Hata ayıklama: hatalı property, eksik zorunlu alanlar, tutarsız içerik

Testlerde hata mesajlarını okurken, mesajın “neyle ilgili” olduğuna odaklanın. Örneğin bir hata “property beklenmiyor” diyorsa, büyük olasılıkla yanlış şema türünü yanlış property ile birlikte kullanıyorsunuzdur. “Zorunlu alan eksik” benzeri hatalarda ise seçtiğiniz şema modeline uygun minimum alan setini tamamlamanız gerekir.

Tutarsız içerik durumlarında pratik yöntem: sayfayı açın ve JSON-LD’de geçen değerleri tek tek görünür içerikle karşılaştırın. Uyuşmuyorsa, JSON-LD üretim noktasında veri çekme/mapper tarafında bir hata vardır. Ayrıca liste sayfalarında pozisyon (position) sırası ile görsel sıranın farklı olması da kaliteyi düşüren bir etkendir.

Dinamik sayfalarda ise sık görülen problem: JSON-LD’nin “çok geç” basılmasıdır. Çözüm, mümkünse SSR veya ön-render stratejisi, değilse JSON-LD’nin ilk render anında DOM’a eklenmesidir. Ek olarak filtrelenmiş/segmentlenmiş içeriklerde her varyasyon için ayrı HTML/JSON-LD döndürmek genellikle daha güvenli olur.

Adım adım doğrulama: nasıl kontrol edilir? (pratik süreç)

Bu bölümde metninize uygun şekilde “doğrulama adımlarını” daha net hale getiriyorum. Aşağıdaki kontrol akışını bir SOP (standart iş akışı) olarak ekiplerinizle paylaşabilirsiniz.

1. Kaynağı test edin: Sohbet odası detay sayfasını açın ve JSON-LD script bloğunun gerçekten sayfada görünüp görünmediğini doğrulayın.
2. Rich Results Test çalıştırın: Detay/list/sayfa 2 gibi varyasyonları ayrı ayrı test edin; beklenen şema uyumluluğunu kontrol edin.
3. Schema Validator ile biçimsel doğrulama yapın: Syntax ve şema property uyumsuzluklarını giderin.
4. Search Console raporlarını izleyin: Uyarı/hata trendini sayfa türlerine göre ayırın (detay mı, liste mi?).
5. İçerik tutarlılığı kontrolü yapın: Sayfada görünmeyen alanlar varsa JSON-LD’den çıkarın veya sayfaya ekleyin.

Bu “adım adım doğrulama” akışı, sohbet odaları gibi sayfa sayısı ve varyasyon sayısı yüksek sistemlerde özellikle değerlidir. Yine de şema testleri doğru olsa bile crawl/indexleme süreci beklediğiniz kadar hızlı gitmeyebilir. Bu durumda Sohbet Sitelerinde Crawl Budget (Indexleme Bütçesi) Yönetimi: Sayfa Patlamasını Kontrol Etme Rehberi yaklaşımıyla indeksleme sağlığını birlikte ele almanız iyi olur.

Yayın sonrası izleme: indeksleme, zengin sonuç uygunluğu, log/rapor kontrolü

Yapılandırılmış veriyi yayınladıktan sonra sadece “testte geçti” demeyin. Arama motoru süreçleri zaman alır; bu yüzden Search Console’daki yapılandırılmış veri raporlarını ve indeksleme durumlarını düzenli takip edin. Zengin sonuç uygunluğu için de doğrulama raporlarındaki değişimi gözlemek gerekir.

Bir diğer pratik adım: server log veya uygulama log’larıyla JSON-LD üretim akışını kontrol etmek. Örneğin bazı filtre varyasyonlarında template yanlış çalışıyor ve JSON-LD hiç üretilmiyorsa, logdan yakalamak düzeltmeyi hızlandırır. Ayrıca CDN/cache katmanı JSON-LD’yi eski içerikle birlikte saklıyorsa, kullanıcıya farklı içerik gösterilip JSON-LD başka bir şeyi temsil edebilir. Bu da veri tutarlılığı problemlerini beraberinde getirir.

Kontrol listesi (Checklist)

Aşağıdaki kontrol listesi, sohbet odası sayfalarında yapılandırılmış veriyi daha “sistematik” hale getirmek için hazırlandı. Teknik ekibinizle paylaşabilir ve her sayfa türü için ayrı bir rubrik gibi kullanabilirsiniz.

Kontrol Noktası	Detay Sayfası (Oda)	Liste/Kategori Sayfası	Dinamik (JS) Sayfalar
JSON-LD sayfa içeriğiyle tutarlı mı?	Açıklama/ad birebir	Liste öğeleri sayfada görünenlerle uyumlu	İlk render’da doğru değerler
Şema türü sayfa amacına uygun mu?	WebPage / oda bağlamı	ItemList benzeri liste modeli	SSR veya ön-render stratejisi

• Her sayfa türü için ayrı JSON-LD şablonu var mı?
• İçerik görünür mü? (testlerde görünmeden geçen JSON-LD’ler risklidir)
• Sayfalama varsa JSON-LD yalnızca o sayfadaki öğeleri mi içeriyor?
• Hata/uyarı mesajları giderildi mi ve tekrar test edildi mi?
• Yayın sonrası izleme (Search Console raporları + indeksleme) takibe alındı mı?

İsterseniz teknik ekibinize hızlı bir başlangıç için genel teknik SEO denetimine de bağlayabilirsiniz. Bu kapsamda teknik SEO kontrol listesi yaklaşımıyla şema uygulamasını birlikte ele almak, hataları daha hızlı azaltmanıza yardım eder.

Yanlış/kaçınılması gereken örnekler

Şema kalitesini bozan örnekler genellikle “fazla bilgi” ekleme veya “görünmeyen veriyi” JSON-LD’ye taşıma davranışlarıdır. Aşağıdaki yanlış örnek mantığını, ekibinizin hatasız uygulama yapması için bir “anti-örnek” olarak düşünebilirsiniz.

<!-- YANLIŞ: Kullanıcı kişisel verisi / doğrulanmamış iddia -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Sohbet Odası",
  "description": "Bu odada 2026'da 1.000.000 kişi kesinlikle katılıyor!",
  "potentialAction": {
    "@type": "ViewAction",
    "target": "https://ornek-sitesi.com/sohbet-odalari/oda?user_id=12345"
  }
}
</script>

Yukarıdaki gibi kişisel veri içeren query parametreleri veya doğrulanmamış istatistikler, kaliteyi düşürür. Ayrıca user_id gibi kişisel veriyle ilişkilendiren alanlar, sadece KVKK/etik açıdan değil; aynı zamanda yapılandırılmış veri tutarlılığı açısından da tehlikelidir. Doğru yaklaşım: JSON-LD’de yalnızca sayfanın konusu olan oda/oturum/likitle ilgili, görünür ve doğrulanabilir bilgileri kullanmaktır.

Sık sorulan sorular

Sohbet odaları için hangi Schema türleri kullanılmalı? ChatRoom var mı, nasıl eşleştirilir?
Detay sayfasında sıklıkla WebPage yaklaşımıyla sayfanın oda bağlamını güçlendirmek, liste sayfasında ItemList kullanmak mantıklıdır. “ChatRoom” doğrudan birebir görünüyorsa eklenebilir; ancak doğru property seti ve beklenen alanlar olmadan eklemek yerine, zengin sonuç beklentinize göre Schema modelini test ederek ilerleyin.

JSON-LD mi Microdata mı? Hangisi daha iyi ve neden?
Genellikle JSON-LD daha yönetilebilir ve şablona entegre etmesi kolaydır. Ayrıca tek bir script bloğunda toplanabildiği için sohbet odası gibi sık değişen sayfa içeriklerinde bakım maliyeti düşer.

Dinamik (JS) yüklenen sohbet odası bilgileri için yapılandırılmış veri nasıl doğru görünür?
En güvenlisi SSR/ön-render ile JSON-LD’yi ilk HTML’de üretmektir. CSR’de JSON-LD’nin sonradan basılması normal olsa da, testlerde görünür olmasını sağlayın; aksi halde doğrulama doğru olsa bile değerlendirme düşebilir.

Zengin sonuç almazsam sorun mu? Yapılandırılmış veri her zaman zengin sonuç verir mi?
Hayır. Yapılandırılmış veri her zaman zengin sonuç üretmez. Ancak hata/uyarıların çözülmesi ve içerik tutarlılığı, en azından indeksleme bağlamı açısından fayda sağlar. Rich Results Test sonuçlarını ve Search Console raporlarını birlikte değerlendirin.

Schema doğrulama hataları nasıl okunur ve nasıl düzeltilir?
Hatayı “şema türü mü property mi” ayrımıyla okuyun. Property beklenmiyor ise yanlış eşleme vardır; eksik alan ise minimum alan setini tamamlayın. Dinamik sayfalarda JSON-LD’nin render zamanını kontrol edin.

Aynı sayfada birden fazla JSON-LD bloğu kullanmak doğru mu?
Genellikle mümkündür; ancak gereksiz tekrarlar yapmayın. Sayfa türüne göre tek bir tutarlı model tercih edin ve çelişen değerler üretmeyin. Çoklu blok kullanıyorsanız her bloğun aynı içeriği farklı şekillerde “yarıştıramamasını” kontrol edin.

Şehir/kategori sayfalarında yapılandırılmış veri nasıl kurgulanmalı (sayfalama/kanonik)?
Her sayfalı varyasyon için yalnızca o sayfada görünen öğeleri ItemList’e koyun. Kanonik/canonical stratejiniz düzgün değilse, yapılandırılmış veriniz farklı varyasyonlarda farklı içerik taşıyabilir. Bu yüzden kanonik ve indexleme stratejisini birlikte düşünün; gerekirse parametreli URL yönetimi için ek rehberleri referans alın.

Sonuç: sohbet odası şemasıyla net, doğrulanabilir bağlam kurun

Sohbet odaları için yapılandırılmış veri uygulaması; genel teknik SEO’dan biraz farklı şekilde “sayfa türü → varlık → şema seçimi → property eşleştirme → test/izleme” mantığıyla yönetilmelidir. sohbet odaları için yapılandırılmış veri (Schema.org) nasıl eklenir sorusunun cevabı, tam da bu eşleştirmeyi doğru kurduğunuzda netleşir: hem kodunuz daha temiz olur hem de Google’ın beklediği tutarlılık sağlanır.

Bir sonraki adım olarak elinizdeki en önemli 10 oda detay sayfasını ve en önemli 2 liste/kategori sayfasını seçin. JSON-LD şablonlarınızı bu yazıdaki örneklere göre uyarlayın, Rich Results Test ile doğrulayın ve Search Console raporlarıyla iterasyon yapın. İsterseniz bu makaleyi teknik ekibinizin çalışma sayfası gibi kullanarak, “şema entegrasyon kontrol listesi” yaklaşımıyla ilerleyebilirsiniz.