Arkadaşlık Sitesi Chat’te “Like/Beğeni” Sayımı Bot-Safe Nasıl Yapılır? JSON-LD ile Yapılandırılmış Veri Sınırı Rehberi

Arkadaşlık ve sohbet platformlarında “like/beğeni” sayacı çoğu zaman sadece UX’i etkiliyor gibi görünür; ama SEO teknik sorumluları ve JS bot/renderer davranışlarını izleyen ekipler için bu sayaç, sayfanın bot-safe (botların sorunsuz okuyabildiği) olmasını doğrudan belirleyen bir risk alanıdır. Özellikle “arkadaşlık sitesi chat’te mesaj beğeni/like sayılırken bot-safe nasıl çalışır? JSON-LD ile sınırlandırma” konusu; dinamik sayaç, hydration sırası, yetkilendirme kapıları ve cache/pagination gibi katmanların aynı anda devreye girmesiyle kritik hale gelir.

Bu yazıda amacımız şu: Chat mesaj kartında like sayımının yanlış render edilmesini engellemek, indeksleme tarafında yanıltıcı sinyaller üretmesini önlemek ve yapılandırılmış verinin (JSON-LD) yanlış yere “kişiselleştirilmiş/etkileşim tabanlı” içerik taşımasını durdurmak. Böylece hem botların gördüğü HTML tutarlı kalır, hem de arama motorlarına iletilen şema “doğru ama sınırlı” kalır.

Problem tanımı: Chat’te like sayımı neden SEO/JS-bot uyumsuzluğu çıkarır?

Chat arayüzlerinde like sayacı genellikle bir API çağrısıyla (reactions endpoint’i) sonradan doldurulur. Bu durumda iki problem ortaya çıkar: (1) Server tarafında görünen değer ya yoktur ya da “0/placeholder”dır, (2) tarayıcı tarafında hydration tamamlandıktan sonra sayaç değişir. Bazı botlar ya script’i hiç çalıştırmaz ya da kısmi çalıştırır; bu yüzden sayfa, bot perspektifinde yanlış ya da eksik sayaçla “kalıcı” hale gelebilir.

İkinci problem auth gating ile ilgilidir. Örneğin “kullanıcı kendi beğenisini görsün” diye /me/reactions gibi yetkilendirmeli bir endpoint kullanırsınız. Bot ise yetkisiz erişimle “kim beğendi” veya “kullanıcının beğendi durumu” yerine farklı bir UI ile karşılaşır. Bu farklılık, aynı URL için farklı kullanıcılarda farklı içerik üretip indeks kalitesini düşürür.

Üçüncü problem cache/pagination ve dinamik sayfalanmadır. Chat mesaj listelerinde sonsuz kaydırma veya offset tabanlı sayfalama kullanmak oldukça yaygındır. Like sayısı çok sık değiştiğinde CDN/uygulama cache’i eski sayacı gösterebilir; bot ise “değeri sabit sanıp” tutarsız sinyali indeksleyebilir. Hydration anındaki yarış (race condition) da “like sayısı bir an doğru göründü sonra resetlendi” gibi durumlar yaratır.

Bot-safe render prensipleri: server-rendered görünür metin, progressive enhancement, graceful fallback

Bot-safe yaklaşımın özü şudur: Arama motorları ve statik/yarı dinamik render eden agentler, ideal olarak sayfanın ilk yüklemesinde anlamlı metin görebilmelidir. Like sayısı gibi sık değişen veri, botların “nihai doğruluk” beklediği bir alan olmak yerine, bot-safe bir görsel/semantik iskelet üzerinde ilerlemelidir.

Bu yüzden üç prensibi birlikte düşünün:

• Server-rendered temel: Sayaç yerleşimi HTML içinde durmalı; en azından sayısal alan için placeholder/iskelet olmalı.
• Progressive enhancement: İstemci (client) çalıştıkça gerçek değer API’den çekilip yerine oturmalı.
• Graceful fallback: API gecikirse, hata olursa veya bot script çalıştırmazsa UI “sahte kullanıcı etkileşimi iddia etmeyen” güvenli bir formda kalmalı.

Like sayımı modeli: “toplam like”, “kullanıcı kendi beğenisi”, “kim beğendi” ayrımı ve indeksleme riski

Bot-safe tasarım için ilk adım veri modelini netçe ayırmaktır. Pratikte üç farklı “like-beğeni” katmanı görürüz:

1) Toplam like: Mesajın kaç beğeni aldığı. Genellikle anon-friendly olur ve indeks dışı/hesaplamalı gösterime daha uygun olabilir; ama güncellik ve cache risklerini ayrıca yönetmek gerekir.

2) Kullanıcının kendi beğenisi: “Ben bu mesajı beğendim mi?” Bu kişiselleştirilmiş bir durumdur. Aynı URL’ye farklı kullanıcılar farklı değer gördüğü için schema ve indeks sinyallerine taşımak sakıncalıdır.

3) Kim beğendi: Beğenen kullanıcı listesi. Mahremiyet ve güvenlik açısından riskli kabul edilir; ayrıca botlar bu tür sosyal grafiği tekrar tekrar çekerek veri sızıntısına benzer davranışlar sergileyebilir.

Bu ayrımı yapmadığınızda tek bir “like” objesiyle her şeyi aynı anda render etmeye çalışırsınız. Oysa bot-safe plan şu soruları ayırmayı gerektirir: “Toplam sayıyı güvenle gösterebilir miyiz?” ve “Kişisel/kimlik bilgisi içeren alanlar JSON-LD ve ilk HTML’de olmamalı mı?” Kararları netleştirdiğiniz anda risk azalır.

JSON-LD ile sınırlandırma: Şemada ne gösterilir/ne gösterilmez?

Yapılandırılmış veriyi (JSON-LD) like sayımı için kullanmak cazip görünür; çünkü “Google bunu görsün” fikri güçlüdür. Ancak chat mesajları dinamik olduğundan en büyük hata, JSON-LD’nin içerik doğruluğunu yanlış temsil etmesidir. JSON-LD’nin rolü kişiselleştirme yapmak değil; sayfanın/mesajın genel kimliğini ve anlamını “sınırlı ve stabil” şekilde anlatmaktır.

Bu yüzden şema kapsamını şöyle çerçeveleyin:

• Gösterebilirsiniz (sınırlı): Mesajın genel varlığı, mesajın dili, mesaj metninin bir özeti (tam metin yerine uygun bir özet), mesajı üreten chat/konu bilgisi (anon bilgileri hariç).
• Dikkatli olun: “Toplam like sayısı” yalnızca sayısal bir dekor değil; değişken bir metrik gibi ele alınır. Çok sık değişiyorsa JSON-LD’ye hiç taşımamak daha güvenli olur.
• Göstermeyin: Kullanıcının kendi beğeni durumu (“beğendim: evet/hayır”), kim beğendi listesi, kullanıcı kimliği/anon ID gibi kişisel alanlar.

Özellikle kişiselleştirilmiş etkileşim alanları JSON-LD’ye taşınmamalıdır. Çünkü Google’ın ve diğer botların bir kullanıcı akışıyla aynı sayfayı aynı şekilde görmesi garanti değildir; ayrıca schema alanları indeks sinyali olarak algılanabilir ve “şu an doğru olan” bir metrik sonradan yanlış hale gelebilir.

Doğru uygulama desenleri: sayaç için SSR skeleton + istemci doğrulaması, rate limit/caching, varyantlar

Like sayımında bot-safe yaklaşımın pratik karşılığı iki katmanlı UI’dır: (1) İlk yüklemede HTML içinde sayısal alanın güvenli iskeleti, (2) istemcide API ile güncellenen nihai değer. Böylece botlar en azından yerleşimi ve sayısal alanın varlığını görür; ama kişisel beğeni/kimlik gibi riskli veriler ilk render’da yer almaz.

Aşağıdaki desen hem performans hem de tutarlılık sağlar:

1. SSR/edge ile message kartını üretin: “Like” etiketli bir sayaç alanı koyun; sayıyı ya gerçek değerle doldurun ya da “—”/“…” skeleton olarak bırakın.
2. İstemci doğrulaması: İstemci yüklendiğinde GET reactions endpoint’i çağırın; sadece toplam sayıyı (anon-friendly) güncelleyin.
3. Kişisel durumu ayrı endpoint ile alın: “Ben beğendim mi?” gibi alanları kişiselleştirilmiş UI’da gösterin; ama JSON-LD’ye asla koymayın.
4. Rate limit ve cache planı: Like sayaçları çok sık değişiyorsa kısa TTL + doğru ETag/If-None-Match kullanın. İstemci tarafı “throttle” ile gereksiz istekleri azaltın.
5. Varyantları kontrol edin: Yetkilendirme ve kişiselleştirme varsa HTML’de büyük farklılık üretmeyin. Mümkünse aynı URL’ye göre içerik stabil olsun.

İyi örnek: SSR’de like sayısının yalnızca sayısal değeri için placeholder + JSON-LD’de mesajın genel bilgisinin sınırlı alanları yer alır. Yani JSON-LD “mesaj nedir?” sorusunu cevaplar; “şu an kaç like var?” iddiasına girmez.

Kötü örnek: Sayaç ve kullanıcı-etkileşiminin tümünü schema ve HTML’de kimlik/doğrulama olmadan yerleştirmek (veya tamamen CSR kalması). Özellikle “kullanıcının beğenisi” gibi alanlar botların/anonların gördüğü içerik ile çakışmadığında indeks kalitesi düşer ve mahremiyet riski artar.

API tasarımı örneği: GET /messages/{id}/reactions?type=like + cache süreleri

Like sayımı için “anon-friendly ama güvenli” bir API tasarlayın. İdeali şudur: Botların ve anon kullanıcıların görebileceği veri düzeyi ile yetkilendirme gerektiren veri düzeyini ayrı uç noktalarda tutmak. Böylece hem güvenlik hem de cache optimizasyonu daha kolaylaşır.

Örnek endpoint tasarımı:

GET /messages/{id}/reactions?type=like

Bu endpoint yalnızca toplam like döner. Kullanıcının kendi beğeni durumu veya kim beğendi gibi bilgileri içermemelidir.

Örnek yanıt:

{
  "messageId": "123",
  "type": "like",
  "count": 128,
  "updatedAt": "2026-04-25T10:12:30Z"
}

Cache stratejisi:

• CDN/edge cache: TTL’yi kısa tutun (ör. 10-60 sn) ve ETag kullanın.
• Client cache: Aynı mesaj kartı ekranda kaldıkça tekrar fetch’i azaltın.
• Reactions write endpoint: POST/PUT istekleri için anti-abuse (rate limit) ekleyin.

JSON-LD örneği: Message/ChatMessage için sınırlı alanlar; count alanını neden her zaman dahil etmeyebileceğin

JSON-LD örneğini mesajın kimliğine ve bağlamına odaklı tasarlayın. Like sayısı alanını her zaman dahil etmek zorunda değilsiniz; çünkü sayaç saniyeler içinde değişebilir ve schema’nın “stabil anlamı” zedelenir. Bu durumda count’u ne zaman dahil edeceğiniz, tamamen uygulama politikası meselesidir.

Yaklaşım: Message/ChatMessage için genel alanları verin; like count’u ya hiç vermeyin ya da “güncel ama stabil olmayan” metrik olarak kontrollü şekilde verin. Ayrıca “ben beğendim” durumunu schema’ya taşımayın.

Örnek (sınırlı JSON-LD):

{
  "@context": "https://schema.org",
  "@type": "Message",
  "inLanguage": "tr",
  "text": "Kısa bir özet ya da kontrollü snippet...",
  "isPartOf": {
    "@type": "ChatChannel",
    "name": "Genel kanal adı"
  }
}

Count’u dahil etmek isterseniz bile (opsiyonel), “anon kullanıcıya gösterilen toplam count” ile sınırlayın ve kişiselleştirilmiş alanları asla eklemeyin. Çok sık değişen sayılarda, bunu doğrudan JSON-LD’ye taşımak yerine HTML’deki UI değerine bırakmak genellikle daha bot-safe olur.

HTTP/indeksleme stratejisi: like sayımı değiştiğinde canonical/ETag/cache-Control; noindex gerekebilir mi?

Like sayısı değiştiğinde HTTP katmanında verdiğiniz tercihler botların gördüğü içeriği etkiler. En sık unutulan nokta şu: Aynı URL’nin farklı anlarda farklı içerik taşıdığı gerçeğini yönetmeniz gerekir. Bunu doğru yapmazsanız, bot/sıralama tarafında beklenmedik sinyaller oluşabilir.

Şunları planlayın:

• ETag ve conditional requests: Reactions sayacı sık değişse bile sayfanın ana HTML’i mümkün olduğunca stabil kalmalı. API response’larında ETag kullanın.
• cache-Control: Mesaj kartı HTML’i için uzun cache kullanacaksanız, sayaç gibi alanlar için ayrıştırılmış fetch ve kısa TTL tercih edin.
• Canonical: “like sayısı değişti diye” canonical değişmemeli. Canonical yalnızca sayfa kimliğini temsil eder.
• noindex düşünün: Sayaç nedeniyle içerik çok sık değişiyorsa ve sayfa asıl SEO hedefi değilse, alan bazında noindex/indeks politikası uygulamak mantıklı olabilir. Ancak bu karar site stratejisiyle birlikte verilmeli.

Örneğin chat mesaj sayfaları “haber değeri” taşımayan ve çok dinamik ise noindex + internal linklerle taze UX sağlamak daha güvenli olabilir. Bu kararın nasıl verileceği için benzer dinamik karar çerçevelerini şu rehberden inceleyebilirsiniz: Kullanıcı Raporu Sonrası Maskeleme (Redaction) İndeklenir mi? Chat Odalarında Alan Bazlı Noindex Kurgusu.

Erişim/mahremiyet: botların/anonların görebileceği veri seviyesi; kişisel etkileşimleri schema’ya taşımama

Like sayımı bot-safe değilse, sadece SEO hatası olmaz; güvenlik ve mahremiyet riski de ortaya çıkar. Bu yüzden anonim/botların erişebileceği veri seviyesi ile kullanıcı oturumu gerektiren veri seviyesi aynı olmamalıdır.

Pratikte uygulayın:

• Anon friendly: Toplam like count’u gösterin (veya sayaç yerini iskelet olarak bırakın).
• Kişisel friendly değil: “Ben beğendim mi?” gibi bilgileri JSON-LD’de asla kullanmayın.
• Kimlik/graph riskli: “Kim beğendi” listesini indekslenebilir bir şemaya taşımayın; gerekiyorsa yetkili ekranda kısıtlı gösterin.

Yetkilendirme (premium/yaş doğrulama) durumlarında ayrıca dikkatli olun. Örneğin yaş doğrulaması olmadan sayfa içeriklerinin bir kısmını maskelerseniz, botların gördüğü DOM ile kullanıcıların gördüğü DOM arasında büyük fark doğabilir. Burada E-E-A-T perspektifi de devreye girer: hangi verinin neden ve nasıl sağlandığı şeffaf olmalı. Şeffaflık/indeks sinyali dönüşümünü Arkadaşlık Sitesi Sohbet Odalarında Kullanıcı Güvenini E-E-A-T ile Somutlaştırma: İçerik Tasarımı, Şeffaflık ve İndeks Sinyaline Dönüşüm Rehberi perspektifinden de ele alabilirsiniz.

Test planı: Googlebot/diğer botlar için render test yaklaşımı, fetch öncesi/sonrası doğrulama

Like sayımı bot-safe değilse testler genellikle sadece “insan tarayıcısında” yapılır. Oysa botların gördüğü içeriği de doğrulamanız gerekir. Bu bölüm, kontrol yaklaşımını somutlaştırır: fetch öncesi/sonrası DOM farkını ölçün ve JSON-LD’nin kapsadığı alanların doğru yerde olup olmadığını doğrulayın.

Kontrol yaklaşımı: Aynı mesaj URL’sini (veya mesaj kartını) bot simülasyonu ile açın. Ardından DOM’da özellikle “like sayacı” ve JSON-LD içeriğini karşılaştırın. Değişim çok sık oluyorsa, en azından JSON-LD’nin stabil kaldığını ve kişisel/kimlik alanı içermediğini kontrol edin.

Yaygın hatalar

Bu alanda en sık görülen sorunlar, “çalışıyor gibi görünse de” bot/sıralama açısından yanlış sinyal üretmesidir. Aşağıdaki hatalar özellikle like sayacı + JSON-LD + dinamik chat için sık görülür.

• Like sayısını JSON-LD’ye her zaman gömmek: Count saniyeler içinde değiştiğinde schema “yanlış gerçeklik” iddia eder. Ayrıca kişiselleştirilmiş değerle eşleşme riski doğar.
• Kullanıcının beğendi durumu schema’da taşımak: Aynı URL farklı kullanıcıda farklı JSON-LD üretebilir; bu da indeks kalitesini düşürür.
• CSR’e tamamen yaslanmak: Botlar script’i çalıştırmadığında sayaç görünmez veya 0/placeholder kalır; bu da anlamsız içerik üretir.
• Cache varyantlarını göz ardı etmek: CDN/uygulama cache, hızlı değişen sayacı güncel tutamayabilir; botlar eski değerleri “doğru” sanabilir.

Kontrol listesi + adım adım doğrulama: bot-safe like sayımı nasıl kontrol edilir?

Asıl mesele “tasarladım” demek değil; gerçekten botların gördüğü şeye uygun olup olmadığını doğrulamaktır. Aşağıdaki adım adım doğrulama süreci, problemi hızlıca yakalamanıza yardımcı olur.

1. Render öncesi doğrulama: Bot simülasyonu (veya headless render) ile sayfayı açın, like sayacı HTML’de var mı? Sayaç alanı placeholder mı yoksa gerçek mi?
2. Render sonrası doğrulama: Client hydration sonrası sayaç değişiyor mu? Değişim sadece “toplam count” ile mi sınırlı, yoksa kişisel/kimlik alanları DOM’a sızıyor mu?
3. JSON-LD doğrulama: Page source içinde JSON-LD var mı? JSON-LD “Message/ChatMessage” için doğru alanları içeriyor mu? Count dahil edildiyse bunun stabil olmayan metrik olarak kabul edilip edilmediğini kontrol edin.
4. Anon vs oturum fark testi: Anon kullanıcı ile oturumlu kullanıcı aynı URL’de farklı JSON-LD üretiyor mu? Üretiyorsa kişisel alanları temizleyin.
5. HTTP doğrulama: API response’larında cache-Control ve ETag çalışıyor mu? Like sayısı değişimine rağmen canonical değişmiyor mu?

Örnek mimari: mesaj kartı (HTML) + sayaç (API) + JSON-LD (sınırlı) akışı

En sağlıklı kurgu, UI katmanlarını ayrıştırır. Mesaj kartı HTML’i şemayı besler; sayaç API’si sadece UX günceller; JSON-LD ise yalnızca sayfanın genel anlamını anlatır.

Aşağıdaki akış, “bot-safe render + JSON-LD sınırlandırma” hedefini bir araya getirir:

Katman	Görev	Bot/Anon İçeriği	JSON-LD’ye Girer Mi?
Mesaj Kartı HTML	Yerleşim ve temel metin	Mesaj özeti/snippet + “Like” etiketi + skeleton/placeholder	Genellikle hayır (yalnızca genel message bilgisi sınırlı alanlarla eklenir)
Reactions API	Toplam like sayısı	Anon-friendly: count (kimlik/kişisel durum olmadan)	Opsiyonel/riski yönetilerek (çoğu senaryoda JSON-LD’ye taşımamak daha bot-safe)
Kişisel Beğeni Durumu	“Ben beğendim mi?”	Yetkili oturumda; anon için yok	Kesinlikle hayır
Kim beğendi / Liste	Sosyal kanıt	Yetkili/gerekli koşullarda maskeli	Hayır

Bu mimaride botlar, ilk yüklemede mesajin kendisini ve güvenli sayaç yerleşimini görür. İstemci, API ile sayacı günceller. JSON-LD ise “dinamik sayım” yerine “mesajın anlamı” üzerinde kalır. Böylece serp_promise vaadi olan “yanlış render’ı engelleme + indeks/şema sinyali kontrolü” aynı anda sağlanır.

Sık sorulan sorular (SSS)

Like sayısını kesinlikle SEO’ya katkı için indekslemek gerekir mi, yoksa sadece UX mi olmalı?
Çoğu chat senaryosunda like sayısı “SEO katkısı”ndan çok “anlık sosyal sinyal”dir. İndeks hedefi mesaj içeriği ise, sayaç indekslenmemeli; bot-safe bir UX güncellemesi olarak kalmalıdır.

JSON-LD içinde like sayısı vermek ne zaman uygundur, ne zaman risklidir?
Uygun olduğu durum: sayaç çok yavaş değişiyor ve kişiselleştirme yoksa. Riskli olduğu durum: sayaç saniyeler içinde akıyorsa, cache/CDN eski değer döndürebiliyorsa veya JSON-LD ile kişisel durum karışıyorsa. Bu yazının ana çizgisi “JSON-LD’yi sınırlı tut” yaklaşımıdır.

SSR yapmak mümkün değilse tamamen CSR ile bot-safe nasıl sağlanır?
Tam bot-safe garanti zorlaşır. Yine de yaklaşım şu olabilir: İlk HTML’de anlamlı sayaç yeri/skeleton bulunmalı, JSON-LD’de kişisel/etkileşim alanı olmamalı, API cevapları anon-friendly olmalı ve hatada güvenli fallback sağlanmalıdır. Yani “CSR ile her şeyi getir” değil; “ilk içerik anlamlı olsun” hedeflenir.

Like sayısı çok sık değişiyorsa cache ve canonical nasıl yönetilir?
Canonical URL kimliği için sabit kalmalı. Sayaç verisi API’de kısa TTL + ETag ile güncellenmeli. Ana sayfa HTML’i aşırı varyant üretmemeli; mümkünse sayım değişimi, indekslenebilir şema/ana HTML üzerinden değil ayrı bir endpoint üzerinden yönetilmelidir.

Anon kullanıcı için like sayımı göstermek ile indeksleme arasında nasıl denge kurulur?
Anon kullanıcıya toplam count göstermek genelde kabul edilebilir; fakat bu değeri JSON-LD’ye taşımayı otomatikleştirmeyin. İndeksleme hedefi mesaj metni ise, sayaç “UI katmanı” olarak kalmalı; kişisel durum ve kimlik bilgisi kesinlikle schema’ya girmemelidir.

Kullanıcının “beğendi” durumu neden schema’ya konmamalı?
Çünkü bu bilgi kişiselleştirilir ve aynı URL’de farklı kullanıcıya göre farklı içerik doğurur. JSON-LD’nin indeks sinyali üretme potansiyeli nedeniyle doğruluk ve adillik sorunları oluşur; ayrıca mahremiyet riski artar.

Yetkilendirmeli içerikte (premium/yaş doğrulama) sayaç nasıl bot-safe kalır?
Yetkili olmayan bot/anon kullanıcı için sayaç alanı skeleton/placeholder veya anonim-friendly toplam count ile sınırlı olmalı. Yetkili kullanıcıya özel “ben beğendim” veya “kim beğendi” gibi veri, ilk HTML/JSON-LD’ye taşınmamalı; erişim kontrolü hem API hem UI katmanında uygulanmalıdır.

İsterseniz bir sonraki adım olarak, mevcut sisteminizde “hangi katmanın bot render’da ne ürettiğini” birlikte çıkarabilirsiniz: HTML mi, API mi, yoksa JSON-LD mi yanlış yere değer taşıyor? Bu ayrımı yaptıktan sonra en az riskli yolu (SSR/edge mi, API cache mi, JSON-LD sınırı mı) netleştirmek çok daha kolay olur.

Ek bir optimizasyon fikri olarak, beğenilenler/cevaplar gibi listelerin crawl edilebilirliğini ayrıca planlamak isterseniz şu içeriğe de göz atabilirsiniz: chat’te kullanıcının beğenilenler/cevaplar sayfası crawl edilebilir mi? dinamik yükleme/pagination yerine offset planı.