Chat Siteleri İçin Schema.org Yapılandırılmış Veri: ChatAction ve Conversation Nasıl Eklenir? (Topluluk Sinyalleriyle Uyumlu Uygulama Rehberi)

Chat sayfalarına yapılandırılmış veri eklemek çoğu ekibin aklına “WebPage’e bir şeyler yazalım” gibi geliyor. Ama chat ürünlerinde asıl değer, kullanıcı niyetini ve etkileşim akışını arama motorlarının okuyabileceği anlamsal bir dile çevirebilmek. Bu yüzden chat sitesi için yapılandırılmış veri (Schema.org): ChatAction, Conversation ve topluluk sinyalleri nasıl eklenir? sorusunu; doğru alanları doğru sayfalara bağlama mantığıyla ele almak gerekiyor.

Bu rehberin amacı; ChatAction ve Conversation şemasını (JSON-LD) chat oturumu/oda/etkileşim akışınıza uyacak şekilde kurgulamak, “topluluk sinyalleri” kısmını da spam veya yanıltma üretmeden ölçülü ve denetlenebilir biçimde temsil etmek. Sonrasında da schema ekledikten sonra Google tarafında nasıl kontrol edeceğinizi, yaygın hataları ve performans/payload risklerini birlikte yönetelim.

Giriş: Chat sitelerinde yapılandırılmış veri neden farklı? (ChatAction vs genel WebPage/Software)

Genel web içeriklerinde yapılandırılmış veri çoğu zaman sayfanın konusunu, başlığını ve temel varlığını tanımlar. Chat dünyasında ise aynı “sayfa” içinde her an değişen bir etkileşim akışı vardır: mesajlar gelir, kullanıcı katılır/ayrılır, moderasyon müdahalesi olur, oturumlar kapanır. Bu dinamik yapı, WebPage şemasının sunduğu düzeyin ötesine geçmenizi gerektirir.

ChatAction, kullanıcının bir eylemde bulunduğunu (ör. mesaj gönderme, sohbete başlama) ifade etmenize yardımcı olurken; Conversation bu eylemlerin geçtiği oturum/konuşma bağlamını temsil eder. Bu ikisini doğru tasarladığınızda arama motoru, “bu sayfa sadece metin değil; kullanıcı etkileşimiyle ilerleyen bir konuşma alanı” fikrini daha net yakalayabilir.

Schema.org seçim rehberi: Hangi sayfada hangi tür? (home, sohbet oda sayfası, kullanıcı profili, arama sonuçları vb.)

Chat ürünlerinde şemayı “tek şema her yerde” gibi düşünmek çoğu zaman yanlış sonuç verir. En doğru yaklaşım: sayfa türüne göre schema türlerini seçmek; sadece o sayfanın gerçek içeriğini yansıtan alanları eklemek ve aynı alanları gereksiz yere çakıştırmamaktır. Özellikle dynamic (AJAX/stream) mesajlarda, şemanın “anlık” değil “sayfanın temsil ettiği durum” ile uyumlu olması gerekir.

Aşağıdaki kısa yönlendirme pratikte çok iş görür:

• Ana sayfa / keşif sayfaları: Conversation’ın kaba bir temsilini “her şeymiş gibi” kullanmayın. Bunun yerine site/ürün bağlamını destekleyen daha genel şemaları tercih edin; ChatAction’ı da “kullanıcının genel eylemi” olarak tutarlı ve sınırlı ele alın.
• Sohbet oda sayfası (conversation/room): Conversation ile oturum bağlamını, ChatAction ile kullanıcıların oturum içindeki kritik aksiyonlarını (ör. katılma, mesaj gönderme) anlatın.
• Mesaj arşivi / konuşma detay sayfası: Conversation + gerekiyorsa belirli bir segmentte ChatAction davranışlarını yansıtın. Mesaj içeriği ve kişisel veri riskine dikkat edin.
• Kullanıcı profili: Bu rehber kapsamına mesaj metnini taşımayın. Bunun yerine varlık/kimlik doğrulama veya moderatör rolü gibi genel bilgileri düşünün; kişisel veri ile şişirmeden.

ChatAction şeması: doğru kullanım mantığı, gerekli/önerilen alanlar ve örnek JSON-LD

ChatAction kullanımında sorulması gereken en temel soru şudur: “Bu sayfada gerçekten hangi eylem gerçekleşiyor?” Yapılandırılmış veri, rastgele bir log dökümü gibi düşünülmemeli. Kullanıcının niyetini ve etkileşimin türünü arama motorunun anlayacağı biçimde ifade edebilmelisiniz. Bu yüzden ChatAction’ı, sayfayı temsil eden bağlam içinde (özellikle kullanıcı aksiyonuna dayalı sayfalarda) yayınlamak daha tutarlı olur.

Aşağıda ChatAction için üç senaryo örneği göreceksiniz. Not: Değerler şablondur; “actionStatus”, “agent”, “object” gibi alanları kendi modelinize göre sağlamlaştırın. Mesaj metnini veya kimlik doğrulama bilgilerini doğrudan şemaya koymayın.

1. sendMessage örneği (kullanıcı bu sayfada mesaj gönderdi):

{
  "@context": "https://schema.org",
  "@type": "ChatAction",
  "name": "sendMessage",
  "agent": {
    "@type": "Person",
    "name": "SessionUser"
  },
  "object": {
    "@type": "Conversation",
    "identifier": "room-123",
    "url": "https://example.com/chat/room-123"
  }
}

2. startConversation örneği (kullanıcı sohbeti başlattı):

{
  "@context": "https://schema.org",
  "@type": "ChatAction",
  "name": "startConversation",
  "agent": {
    "@type": "Person",
    "name": "SessionUser"
  },
  "result": {
    "@type": "Conversation",
    "identifier": "conv-789",
    "url": "https://example.com/chat/conversation/conv-789"
  }
}

3. joinConversation örneği (kullanıcı odaya katıldı):

{
  "@context": "https://schema.org",
  "@type": "ChatAction",
  "name": "joinConversation",
  "agent": {
    "@type": "Person",
    "name": "SessionUser"
  },
  "object": {
    "@type": "Conversation",
    "identifier": "room-123",
    "url": "https://example.com/chat/room-123"
  }
}

Bu üç senaryoyu, sayfanın gerçek durumuna göre üretin. Örneğin “joinConversation” kullanacaksanız kullanıcı gerçekten odaya o an katılmış olmalı. “sendMessage” senaryosunda ise mesaj gönderme işlemi tamamlanmadan şemayı yayınlamak tutarsızlık doğurabilir; arama motoru ile sayfa gerçekliği arasındaki uyumu bozabilirsiniz.

Conversation şeması: conversation/participation mantığı, mesaj ve oturum verisini nasıl modellemeli

Conversation tarafında hedef “mesajın kendisi”nden çok “konuşma bağlamı”dır: oturum ID’si, oda ID’si, konuşmanın başlangıç/bitiş durumu, katılımcıların genel tasviri gibi bilgiler. ChatAction ile oturum ilişkisini kurarken Conversation nesnesinin identifier/URL gibi referans alanları kritik rol oynar.

Oda/oturum sayfası modelinde conversationId mantığını şöyle düşünebilirsiniz: oda daha kalıcı bir “room-123”, oturum ise “conv-789” gibi zaman içinde türeyen bir bağlam olabilir. Katılımcıları doğrudan “@type: Person + kullanıcı adı” ile şişirmek yerine anonim/oturum tabanlı temsiller tercih etmek çoğu senaryoda daha sağlıklıdır.

{
  "@context": "https://schema.org",
  "@type": "Conversation",
  "name": "Oda: room-123",
  "identifier": "conv-789",
  "url": "https://example.com/chat/conversation/conv-789",
  "participant": [
    { "@type": "Person", "name": "SessionUserA" },
    { "@type": "Person", "name": "SessionUserB" }
  ],
  "status": "Active"
}

Burada “participant” dizisini gerçek kullanıcı ID’leriyle doldurmak yerine, en az bilgiyle temsil eden anonim isimler veya oturum tabanlı roller kullanmak hem güvenlik hem de veri minimizasyonu açısından daha doğru olur. Ayrıca “status” alanını her oturum için tutarlı yönetmek gerekir; kapanmış bir conversation için “Active” dememelisiniz.

Topluluk sinyalleri: Moderasyon, katılımcı etkileşimi ve kalite sinyallerini schema’da nasıl temsil edebileceğiniz (ve temsil edemeyecekleriniz)

Topluluk sinyalleri chat ürünlerinde gerçekten değerlidir; ancak yapılandırılmış veri, “kayıtlı içeriği propaganda gibi şişirmek” için kullanılmamalı. Buradaki doğru yaklaşım: ölçülebilir davranışları (ör. moderasyon kararı var/yok, etkileşim seviyesi, katılımcı yoğunluğu) anlamsal bir çerçevede ve yanıltmayan şekilde yansıtmak.

Schema.org’da “communitySignals” gibi tek ve standart bir alan yok. Bu yüzden bu sinyalleri uydurmak yerine, mevcut sınıfların kapsadığı anlamlarla temsil etmeye çalışın. Örneğin moderasyon için “ChatAction” aksiyonları içinde “actionStatus” benzeri genel durum belirtmek; “engelleme” ya da “bekletme” gibi eylemleri ise kullanıcı metnini ifşa etmeden semantik olarak anlatmak daha güvenli bir yoldur.

Örnek (ölçülü) moderasyon/engelleme yansıması: Aşağıdaki yaklaşım mesaj içeriğini paylaşmaz; sadece “bu etkileşimde moderasyon aksiyonu” olduğunu semantik düzeyde belirtir.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Conversation",
      "identifier": "conv-789",
      "url": "https://example.com/chat/conversation/conv-789",
      "status": "ModerationInProgress"
    },
    {
      "@type": "ChatAction",
      "name": "moderateConversation",
      "actionStatus": "InReview",
      "object": {
        "@type": "Conversation",
        "identifier": "conv-789"
      }
    },
    {
      "@type": "ChatAction",
      "name": "blockOrRestrictInteraction",
      "actionStatus": "Applied",
      "object": {
        "@type": "Conversation",
        "identifier": "conv-789"
      }
    }
  ]
}

Temsil edemeyeceğiniz ya da çok riskli olanlar ise şunlar: spam/kalite için “tam puan” gibi kesin iddialar, kullanıcı seviyesinde “bu kullanıcı kesin şudur” tarzı etiketlemeler veya moderasyon gerekçesinin mesaj içeriğiyle birlikte verilmesi. Bunlar hem veri koruma açısından riskli olabilir hem de arama görünürlüğü tarafında yanlış sinyal üretir.

Uygulama stratejisi: hangi veriyi sayfa içeriğine dahil etmeli, server-side vs client-side, cache ve dinamik içerik yaklaşımı

Dinamik sohbet akışlarında en iyi pratik, şemanın arama motoru tarafından “görülebilir” ve “tutarlı” biçimde sunulmasını sağlamak. Sadece client-side (AJAX ile) üretim çoğu zaman doğrulama/indeksleme davranışlarını belirsizleştirir. Bu yüzden mümkünse server-side rendering (SSR) veya prerender ile Conversation ve temel ChatAction bağlamını ilk HTML’de verin.

Pratikte şu ayrımı yapın: statik/yarı statik bağlam (oda URL’si, conversationId, durum) server-side; gerçek zamanlı mesaj metni ise şemaya mümkün olduğunca hiç girmesin. Mesaj metni gerekiyorsa bile, kişisel veri/minimal içerik ilkelerine sıkı bağlı kalın ve sadece “test ortamında” doğrulayarak ilerleyin.

Cache ve tekrar/çakışma: Şema içerikleri farklı kullanıcılar için farklı olabiliyorsa cache strat’ini doğru kurun. Aynı sayfada herkes için “SessionUser” yazmak çakışma yaratabilir; bunun yerine conversation bağlamını evrensel tutup kullanıcıya özel ChatAction’ı mümkün olduğunca sayfa içeriğiyle senkron yayınlayın.

Performans ve doğrulama: yapılandırılmış veri boyutu, tekrar/çakışma riskleri

JSON-LD boyutu büyüdükçe sayfa ağırlığı ve ayrıştırma maliyeti artar. Chat sitelerinde özellikle “oturum başına yüzlerce mesaj” gibi durumlarda şemayı mesajlarla doldurmak hem performansı hem de doğruluk beklentisini bozar. En iyi yaklaşım: Conversation’ı temsil eden küçük bir çekirdek set; ChatAction’ı ise sayfada yaşanan kritik bir/kaç eylem ile sınırlı tutmaktır.

Bir diğer risk “çakışma”dır: aynı @type için farklı identifier değerleri, aynı sayfada birden fazla script tag içinde zıt @graph akışları veya birbirini yalanlayan status bilgileri. Bu yüzden tek bir JSON-LD kaynağında (tercihen tek script içinde) bütünleştirme yapın ya da graph’i tekilleştirin.

Yaygın hatalar

ChatAction ve Conversation şemalarında en sık görülen problem, şemayı “log deposu” gibi kullanmaktır. Mesaj metnini veya kullanıcıya ait kişisel verileri (kullanıcı adı, e-posta, telefon, IP vb. dolaylı kimlik işaretleri) JSON-LD içine gömmek; hem gizlilik açısından riskli hem de spam/manipülasyon izlenimi oluşturabilir. Özellikle “rich result” hedefi olmayan metin parçalarını şemaya taşımak çoğu zaman gereksizdir.

İkinci yaygın hata dynamic içerik ile şemanın senkron olmamasıdır. Örneğin kullanıcı mesaj gönderdikten sonra sayfa güncelleniyor ama şema hâlâ eski durumla birlikte geliyor; bu da Conversation status’unun “Active” iken actionStatus’un “Applied” veya “InReview” ile tutarsız görünmesine neden olur. Üçüncü hata ise sayfada birden fazla conversation/oda varken tek conversation’ı her zaman varsayıyor olmanızdır. Bu durumda yanlış bağlamda ChatAction yayınlayarak anlamsal doğruluğu kaybedersiniz.

Yaygın hatalar ve güvenlik (kişisel veri, kimlik doğrulama, logların şemaya yansıtılması)

Güvenlik tarafında “veri minimizasyonu” kuralını şemaya kadar indirmeniz gerekir. Oturum bilgisi ve katılımcı temsili gibi bilgiler gerekiyorsa bile, şemada yalnızca arama motorunun anlayacağı kadarını bırakın. Kullanıcıların birebir tanımlanmasına yol açacak referanslar (tam kullanıcı adı eşleşmesi, benzersiz ID’nin ham hali, mesaj içeriğine bağlanan sorgu belirteçleri) risk üretir.

Kimlik doğrulama ve loglar da aynı şekilde düşünülmelidir. Backend’de tutulan ayrıntılı güvenlik loglarını (tüm istek/yanıt metrikleri, fail sebepleri) şemaya taşımak hem veri sızıntısı hem de kontrol edilemez içerik artışı demektir. Şema yalnızca “sayfa bağlamı”nı anlatmalı; operasyonel kayıtları yayınlamamalıdır.

Birden fazla şema objesini aynı sayfada birleştirme örneği (array ile JSON-LD)

Chat sayfalarında genellikle hem Conversation hem de birden fazla ChatAction birlikte anlamlıdır. Burada doğru yöntem: tek bir script içinde @graph kullanmak ya da JSON-LD’yi birden fazla objeyi tek dizide birleştirerek yayınlamak. Böylece tekrar/çakışma riskini azaltırsınız.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Conversation",
      "identifier": "conv-789",
      "url": "https://example.com/chat/conversation/conv-789",
      "name": "Oda sohbeti",
      "status": "Active"
    },
    {
      "@type": "ChatAction",
      "name": "joinConversation",
      "actionStatus": "Completed",
      "object": { "@type": "Conversation", "identifier": "conv-789" }
    },
    {
      "@type": "ChatAction",
      "name": "sendMessage",
      "actionStatus": "Completed",
      "object": { "@type": "Conversation", "identifier": "conv-789" }
    }
  ]
}

Eğer sayfada birden fazla oda/konuşma “liste” halinde yer alıyorsa, şemayı her öğe için ayrı ayrı basmak (payload şişer) yerine yalnızca sayfanın temsil ettiği ana conversation’a odaklanın. Listelenen tüm conversation’ları tek tek şemaya basmak çoğu zaman doğru bir strateji değildir.

Google test/uyumluluk kontrol adımları: nasıl kontrol edilir, adım adım doğrulama

Şemayı eklemek kadar doğru doğrulamak da kritiktir. “Zaten var” varsayımıyla ilerlemek, dinamik sayfalarda tutarsızlıklara göz yummaya yol açar. Aşağıda pratik bir kontrol listesi mantığıyla nasıl ilerleyebileceğinizi görebilirsiniz.

1. Sayfa kaynağını doğrulayın: Şemayı gerçek HTML’de görüyor musunuz? (AJAX ile sonradan basılıyorsa testler geçebilir ama indeksleme davranışı farklı olabilir.)
2. Google Zengin Sonuçlar / Schema test ile doğrulayın: JSON-LD sözdizimi ve temel alanlar doğru mu? Hata varsa, çakışan @context veya yanlış @type gibi durumlar var mı kontrol edin.
3. Senaryo uyumunu test edin: joinConversation, sendMessage, startConversation durumlarında şema aynı conversationId ile tutarlı mı? Conversation status ile ChatAction actionStatus çelişiyor mu?

Bu adımları her deployment’da (özellikle şema üretim katmanı değiştiğinde) otomatikleştirmek idealdir. Ayrıca farklı tarayıcı/renderer koşullarında (SSR vs CSR) davranışı kıyaslayın.

ChatAction vs Conversation vs topluluk sinyalleri: hızlı eşleştirme tablosu

Şema / Alan	Ne sağlar?	Chat sayfasında nereye uygulanır?	Dikkat edilmesi gerekenler
ChatAction (sendMessage)	Kullanıcı aksiyonu türünü belirtir	Mesaj gönderme aksiyonunun gerçekleştiği oda/konuşma sayfası	Mesaj metnini koymayın; actionStatus ile tutarlılık sağlayın
Conversation	Oturum/oda bağlamını temsil eder	Conversation detay sayfaları ve oda sayfaları	identifier ve url aynı conversation’ı göstermeli; status doğru olmalı
Topluluk sinyali (ölçülü)	Moderasyon/kalite bağlamı gibi durumları anlamsal yansıtır	Moderatör aksiyonu veya topluluk durumunun öne çıktığı sayfa varyasyonları	Spam/puan/etiketle yanıltmayın; kişisel veri ifşa etmeyin

Dinamik sohbet içeriklerini (AJAX ile gelen mesajlar) schema içine nasıl dahil etmeliyim?

AJAX ile gelen mesajlarda en doğru yaklaşım “tam mesaj akışını schema’ya basmak” değil; mesajların oluşturduğu bağlamı anlatmaktır. Örneğin sayfanın header’ında veya sayfa durumunda (oda aktif mi, moderasyon var mı, oturum ID’si nedir) güncel bilgiler varsa Conversation status’u veya sınırlı bir ChatAction’ı senkronlayabilirsiniz.

Mesaj metinlerini şemaya koymak SEO’ya otomatik bir katkı sağlamayabilir; hatta yanlış uygulandığında gizlilik riskini artırır. Deney yapmak istiyorsanız, yalnızca sınırlı bir örnek cümleyle ve kişisel veri içermeyecek şekilde (anonimleştirilmiş, maskeleme uygulanmış) test edin. Sonuçları Google test araçlarıyla doğrulayın; ardından gerçek kullanıcı trafiğinde kademeli devreye alın.

Mesaj metinlerini schema’ya koymak SEO’ya yarar mı, riskleri neler?

Mesaj metinlerini schema’ya koymak “her zaman kötü” değildir; ancak chat platformlarında mesajlar yüksek hacimlidir ve kişisel veri içerebilir. Mesaj metni şeması; arama motorlarının indekslemeyi nasıl yorumlayacağı konusunda belirsizlik yaratabilir ve “duygu/kalite tahmini” gibi istemediğiniz sinyaller üretme riskini artırabilir.

Bu yüzden genel öneri: mesaj metinlerini şemaya taşımayın. Bunun yerine Conversation bağlamı ve ChatAction gibi eylem temsilleriyle sınırlı kalın. Mesajların kendisini SEO için değerlendirmek istiyorsanız, bunu ayrı bir indeksleme stratejisi (örn. bazı mesajların indekslenmesi, bazılarının gizlenmesi) ile ele almak daha doğru olur. Bu konuya paralel olarak “chat konuşma arşivleri” yaklaşımını da incelemek iyi bir başlangıç sayılır: Chat Konuşma Arşivleri (Loglar) SEO Rehberi: Hangi Mesajlar İndekslenmeli, Hangileri Gizlenmeli?

Conversation şemasında katılımcıları nasıl tanımlarım (anonim/oturum tabanlı)?

Katılımcıları tanımlarken amaç “tam kimliği ifşa etmek” değil; conversation bağlamının gerçek bir etkileşim ortamı olduğunu göstermek. Oturum tabanlı anonim temsil en pratik yoldur: SessionUserA, SessionUserB gibi isimler ya da hashlenmiş ama geri çözümsüz bir temsille ilerleyebilirsiniz.

Anonimleştirme yaptığınızda iki koşulu koruyun: (1) aynı conversation için aynı katılımcı temsilini tutarlı yayınlayın, (2) farklı sayfalar arasında çelişkili participant listesi üretmeyin. Aksi halde arama motoru için anlamsal bir “kararsızlık” oluşur. Ayrıca topluluk sinyali yaklaşımında moderasyon/kalite durumlarını kişiyi hedefleyen bir dille şemaya taşımaktan kaçının.

Bir sayfada birden fazla conversation veya oda varsa JSON-LD nasıl kurgulanır?

Liste sayfalarında veya birden fazla panelin aynı sayfada göründüğü senaryolarda şema tasarımı daha dikkatli yapılmalı. Tek tek tüm conversation’ları dökmek payload’u şişirir ve test/validasyon süreçlerini zorlaştırır. Bunun yerine sayfanın birincil oda/konuşma bağlamını seçin ve Conversation/ChatAction’ı yalnızca o bağlam için yayınlayın.

Alternatif olarak, sayfa gerçekten “her conversation’ın detayını aynı anda temsil ediyorsa” her öğe için ayrı @graph bloğu üretilebilir. Ancak bu durumda her @graph için identifier/url net olmalı; birden fazla script yerine tutarlı birleştirme stratejisi izlenmelidir. Aksi halde çakışan identifier’lar yanlış anlamsal bağlar kurar.

Uygulama devamlılığı: performansı ve doğruluğu izlemek için server log yaklaşımı

Schema’nın etkisini görmek için sadece doğrulama yeterli değildir; tarama ve rendering davranışını da ölçmeniz gerekir. Chat sitelerinde hangi sayfaların tarandığı, hangi varyasyonların (oda açık/kapalı) indekslendiği pratikte kritikleşir. Bu noktada server log analizi, şema üretim stratejinizi de gerçek verilerle besler.

İlgili rehber: Chat Sitesi İçin Server Log Analizi: Hangi Sayfalar Taranıyor? Crawl Bütçesi Nasıl Optimize Edilir?

Sonuç + kontrol listesi

Chat sitelerinde schema uygulaması, klasik SEO sayfa etiketlemesinden daha fazlasıdır. ChatAction ile kullanıcının yaptığı kritik eylemi; Conversation ile konuşmanın oturum/oda bağlamını; topluluk sinyalleriyle de moderasyon/etkileşim durumunu ölçülü ve yanıltmayan şekilde anlatabilirsiniz. Başarı, “doğru sayfada doğru durumla” şemayı üretmek ve doğrulama/performans disiplinini korumaktan gelir.

Schema kontrol listesi (pratik):

• ChatAction: action name (sendMessage/startConversation/joinConversation) sayfanın gerçek olayına karşılık geliyor mu?
• Conversation: identifier ve url aynı conversation’ı doğru temsil ediyor mu?
• Status / actionStatus: Conversation status ile ChatAction actionStatus çelişiyor mu?
• Topluluk sinyalleri: Moderasyon/engelleme/bekletme gibi durumlar anlamsal ve ölçülü mü; kişisel veri yok mu?
• Dinamik içerik: Şema SSR/prerender ile ilk HTML’de görünüyor mu (veya testte beklediğiniz gibi çıkıyor mu)?
• Payload: Mesaj metinlerini şişiriyor musunuz? En az alanla çekirdek modeli koruyor musunuz?
• Gizlilik: Kimlik doğrulama/log/kişisel veri şemaya girmiş mi?

Sık Sorulan Sorular (FAQ)

ChatAction ve Conversation farkı nedir, hangisini hangi sayfada kullanmalıyım?
ChatAction kullanıcı eylemini (sendMessage/startConversation/joinConversation) anlatır. Conversation ise sohbetin oturum/oda bağlamını temsil eder. Oda/konuşma detay sayfalarında Conversation merkezde olmalı; kullanıcı aksiyonunun gerçekleştiği anlarda ChatAction eklenmelidir.

Dinamik sohbet içeriklerini (AJAX ile gelen mesajlar) schema içine nasıl dahil etmeliyim?
Mesaj metinlerini şemaya taşımak yerine, sayfanın temsil ettiği bağlamı (oturum ID, durum, moderasyon var/yok gibi) Conversation ve sınırlı ChatAction ile yansıtın. Mümkünse SSR/prerender ile ilk HTML’de şemayı gösterin.

Mesaj metinlerini schema’ya koymak SEO’ya yarar mı, riskleri neler?
Otomatik SEO faydası garanti değildir; veri minimizasyonu bozulabilir ve kişisel veri riskleri oluşabilir. Genellikle mesaj metni şemaya konmaz; indeksleme hedefi varsa bunu ayrı bir arşiv/indeks stratejisiyle yönetin.

Conversation şemasında katılımcıları nasıl tanımlarım (anonim/oturum tabanlı)?
Tam kullanıcı kimliğini ifşa etmek yerine oturum tabanlı anonim temsiller (SessionUserA gibi) kullanın. Tutarlılık için aynı conversation içinde participant temsilleri kararlı olmalıdır.

Topluluk sinyalleri (aktif kullanıcı/etkileşim/kalite) schema’da nasıl temsil edilir?
Standart tek alan olmadığı için anlamsal ve ölçülü yansıtın: Conversation status veya moderasyon bağlamında ChatAction aksiyonları gibi. Spam/manipülasyon izlenimi verecek kesin iddialardan ve kişisel veriden kaçının.

Bir sayfada birden fazla conversation veya oda varsa JSON-LD nasıl kurgulanır?
Öncelikle sayfanın ana temsil ettiği conversation’ı seçin. Liste sayfalarında her öğeyi şemaya dökmek payload’u şişirebilir. Gerçekten çoklu bağlam temsil ediliyorsa @graph içinde her identifier/url net olmalı.

Schema hataları Google rich sonuçlarını etkiler mi, nasıl test etmeliyim?
Evet; sözdizim veya semantik tutarsızlıklar testte görünür ve sonuçları etkileyebilir. “adım adım doğrulama” için önce HTML kaynak görünürlüğünü, sonra Zengin Sonuçlar/Schema test araçlarını, ardından senaryo uyum testlerini yapın.

Schema doğrularken hangi alanlar zorunlu/önerilir?
Zorunluluk alanları kullanım senaryosuna göre değişir. Genelde Conversation için identifier/url/status çekirdektir; ChatAction için name (eylem türü), object (Conversation referansı) ve mümkünse actionStatus önerilir. Her şey için en temel kural: şemadaki değerler sayfa içeriğiyle tutarlı olmalıdır.