Chat Sitelerinde Beğen–Cevapla–Paylaş Eylem Butonları SEO ve Botlar İçin Nasıl Render Edilmeli? Bot-Safe HTML Rehberi

Chat platformlarında mesajların yanında görünen “beğen”, “cevapla” ve “paylaş” gibi aksiyonlar sadece kullanıcı deneyimini değil; tarama ve sayfanın render edilme biçimini de etkileyebilir. Özellikle chat sitesi eylem butonları (beğen cevapla paylaş) bot-safe html mi olmalı sorusu; sayfanın indekslenebilirliğini, içerik çoğaltma riskini ve Google’ın “crawl budget” yaklaşımını doğrudan ilgilendirir.

Bu rehberde; aksiyon butonlarının HTML’de nasıl görünmesi gerektiğini (ve görünmemesi gerekenleri), botların sayfayı tararken ve (JS çalıştırmadan ya da kısmi render ile) nasıl değerlendirdiğini, SEO sinyallerini bozmadan en güvenli uygulamaları adım adım ele alacaksınız.

Sorun Tanımı: Kullanıcı aksiyonlarının HTML’ye yansıması neden SEO/indeks davranışını etkiler?

Chat arayüzlerinde “like”, “reply” ve “share” butonları çoğu zaman dinamik bir state taşır: kullanıcı daha önce beğenmiş mi, kaç kişi beğenmiş, cevap bağlantısı hangi thread’e gidiyor, paylaşımda hangi URL varyasyonu oluşuyor gibi. Tam da bu state’lerin HTML’e nasıl yansıdığı; tekil mesajların indekslenebilirliğiyle ilgili kritik sinyalleri etkileyebilir.

Örneğin aynı mesaj için “beğendin” durumuna göre DOM değişiyorsa, botlar bu varyasyonları farklı içerik sanabilir. Benzer şekilde “share” butonu URL parametreleriyle tetiklenirse ve canonical düzgün yönetilmezse, paylaşım yüzünden oluşan URL varyantları index bloat’a (gereksiz indekslenme) zemin hazırlayabilir.

En riskli senaryo şudur: Kullanıcıya özel state (personalized UI) HTML’de farklı üretilir ve botların gördüğü kısmi/yanlış varyasyonlar dizine eklenir ya da keşif sinyalleri dağıtılır. Sonuç; düşük kaliteli indeks, arama sonuçlarında tutarsız snippet’ler ve crawl verimsizliği olur.

Botların Gerçekte Ne Yaptığı: Tarama vs işleme farkı (JS çalıştırmayan botlar, kısmi render, crawl budget)

Googlebot’un tarama (fetch) ve render (execution) süreçleri farklı evrelerdir. Her zaman tam JavaScript çalıştırma garantisi yoktur; bazı botlar yalnızca HTML’i görür, bazıları ise kısmi render gerçekleştirir. Bu fark; butonların “sayfada görünüyor ama anlamı zayıf” öğeler haline gelmesine ya da tam tersine “indekse girecek bir varyasyon” üretmesine yol açabilir.

Aksiyon butonları, “JS ile sonradan ekleniyorsa” botlar tarafından görünmeyebilir. Bu durumda aksiyonların SEO’ya doğrudan etkisi sınırlı olabilir; fakat kullanıcı/terminal davranışını temsil eden metin alanları eksik kalır. Öte yandan butonlar SSR ile dönüp ama state’e göre değişken içerik üretiyorsa, botların değişen DOM’u ayrı sayfa/URL gibi algılama eğilimi artar.

Crawl budget açısından da tablo benzer: aksiyonların DOM/URL varyantları çoğaldıkça, Google daha değerli içerikleri daha geç keşfedebilir. Özellikle mesaj listeleri sonsuz scroll ya da yarım sayfa yükleniyorsa, her mesajda farklı “indexable link” üretilmesi gereksiz keşifleri artırabilir.

Eylem Butonları Türleri: beğen/cevapla/paylaş (stateful vs stateless) ve SEO etkisi

Beğen, cevapla ve paylaş aynı kategoriye giriyor gibi görünse de SEO ve bot etkileşimi açısından risk profilleri farklıdır. “Like” çoğu zaman stateful’dır; çünkü sayaç ve kullanıcının “beğendin” durumuna dair bir karşılığı olabilir. “Reply” tasarımların bir kısmında stateless görünebilir; ancak mesaj permalinki/anchor yönetimi ile indekslenebilir URL üretme potansiyeli vardır. “Share” ise en sık URL parametresi ve varyant üretimiyle tehlikeli hale gelir.

Bu nedenle aksiyonları tek bir standartla değil, “hangi state HTML’e girmeli / girmemeli” üzerinden sınıflandırmak daha doğru olur. Genel prensip şudur: Eğer aksiyon tıklanınca sayfa/URL varyantı yaratıyorsa, canonical ve indeks politikası tasarımıyla birlikte ele alınmalıdır.

Doğru Model: Bot-safe render prensipleri (stabil DOM, deterministik içerik, düşük içerik çoğaltma riski)

Bot-safe render yaklaşımı, aksiyon butonlarını “HTML’de stabil bir yapı” olarak teslim etmeyi hedefler. Stabil DOM demek; aynı mesaj sayfasında botların gördüğü HTML’in büyük oranda deterministik kalması demektir. Deterministik içerik demek; like sayısı gibi değişken metriklerin kontrolsüz şekilde kullanıcıya göre çoğalmaması; mümkünse SSR’de tutarlı ve güvenli bir stratejiyle verilmesidir.

Düşük içerik çoğaltma riski demek; buton tıklamalarıyla ortaya çıkabilecek farklı URL’lerin (query/fragment/anchor veya yeni thread filtreleri) indexlenebilirlik açısından sınırlandırılmasıdır. Özellikle aynı mesajın birden fazla “cevap görünümü” veya “filtreli thread” varyantı üretmesi, index bloat’a davetiye çıkarır.

• Stabil DOM: Buton iskeleti ve erişilebilir etiketler sabit olmalı.
• Deterministik SSR: Mümkünse sayfa ilk render’da değişken parçaları ya sabitlemeli ya da noindex stratejisiyle korumalı.
• Varyant kontrolü: Paylaş/cevap tıklanınca oluşan URL’ler canonical/noindex kurallarıyla uyumlu olmalı.
• JS fallback: JS’siz bot için buton “anlamsız div” olmamalı; en azından doğru link/etiket yapısı bulunmalı.

HTML’de Ne Olmalı? (buton iskeleti, erişilebilirlik, mikro-etiket/semantic yaklaşım) ve nelerin olmaması gerektiği

HTML’de hedef, aksiyon butonlarını hem erişilebilir hem de botlar için anlamlı hale getirmek; ama indekslenebilir varyant üretmemektir. Bu yüzden butonun temel iskeleti (ikon, label, aria-label, yardımcı metin) SSR ile sabit dönebilir. Ancak sayfayı her kullanıcıya göre farklılaştıran “kişiselleştirme metinleri” (ör. “Sen beğendin”) indexe girecek şekilde zenginleştirilmemelidir.

Semantic yaklaşım açısından; mümkünse “beğen” ve “cevapla” aksiyonları, sonuçta gerçekten bir URL’e götürüyorsa <a> olarak; sadece UI state değiştiriyorsa <button> olarak teslim edin. Paylaş aksiyonunda ise kullanıcıyı bir URL’e götürmek yerine “kopyala” veya “share dialog” açmak tercih edilebilir; yine de JS’siz senaryoda en azından anlamlı bir fallback link sunulmalıdır.

Şunlardan kaçının: Botların görebileceği HTML’de “kullanıcıya özel beğendin” yazısını indekslenebilir metin olarak basmak; her aksiyon state değişiminde URL üretmek; veri attribute’larına (ör. data-user-id) indekslenebilecek kişisel bilgiler gömmek.

Aksiyon State’i Nasıl Yönetilmeli? (like sayısı, “kullanıcı beğendi” durumu, reply bağlantıları) — SSR/CSR kombinasyonu

Like gibi stateful aksiyonlarda kritik soru şudur: SSR’de ne gösterilecek, CSR’de ne değişecek? En güvenlisi, SSR’de kullanıcıya özel durumları “indekslenebilir metin” seviyesinde çoğaltmamaktır. Örneğin SSR’de sadece deterministik gibi görünen like sayısını göstermek (veya düşük frekanslı güncellemek) daha emniyetlidir; “sen beğendin” gibi kişiselleştirilmiş ifadeleri ise CSR ile (JS çalışınca) göstermeyi tercih edin.

Reply (cevapla) butonunda ise hedef, mesaj permalinki/anchor tasarımını doğru kurmaktır. Kullanıcı reply’e tıklayınca aynı sayfada anchor’a kaymak veya yeni bir “thread view” açmak mümkün. Burada index bloat riskini azaltmak için “reply view” URL’leri kontrollü olmalı; sayfa çoğalması yerine tekil mesaj permalinki üzerinden ilerlenmelidir.

Paylaş butonunda ise “share parametreleri” ile UTM benzeri izleme yapılabilir; fakat canonical korunmazsa aynı içerik farklı query parametreleriyle indekslenebilir hale gelir. Bu yüzden canonical stratejisi ve canonicalize edilmesi gereken query parametreleri baştan doğru kurgulanmalıdır.

Paylaş Butonları: Open Graph/URL parametreleri, canonical ve share parametreleriyle çoğalma riski

Paylaş butonları çoğu zaman sosyal ağların önizleme (OG) üretmek için kullandığı URL’leri çağırır. Bu çağrıda ?utm_source=..., ?ref=... gibi parametrelerin kullanılması ölçüm açısından yaygındır. Ancak arama motorları bu parametreleri ayrı URL varyantları olarak keşfedebilir.

Doğru yaklaşım: Paylaşımda izleme parametresi kullanın; ancak canonical URL’yi sabit tutun. Örneğin paylaşım linki /mesaj/123?utm_source=chat&utm_campaign=share olabilir; fakat sayfa HTML’inde <link rel="canonical" href="/mesaj/123"> her zaman aynı mesaj URL’ini göstermelidir. Böylece içerik aynı kaldığı halde indekslenme varyasyonları azaltılır.

Ek olarak OG etiketleri mesajın ana içeriğine (başlık, mesaj metni, yazar/oda bilgisi) odaklanmalı; aksiyon state’lerine göre değişen “kişiselleştirilmiş” alanlar OG’de çoğalmamalıdır. “Like count” ya da “sen beğendin” gibi kişisel durumlar OG ile beslenmemelidir.

Cevapla Butonları: Dinamik thread/anchor/fragment yönetimi; indekslenebilir mesaj permalinki tasarımı

Cevapla butonları genellikle kullanıcıyı belirli bir mesajın altına yönlendirir. Bu yönlendirme, fragment (ör. #m-123) veya query (ör. ?replyTo=123) üzerinden yapılabilir. Fragment çoğu durumda arama motoru indeksinde ayrı URL gibi davranmaz; fakat sisteminiz “fragment değişimiyle farklı içerik üretme” yapıyorsa botlar farklı varyasyonlar görebilir.

En sağlam tasarım: Mesajın tek bir kalıcı permalinki olsun (ör. /mesaj/123). Reply butonu bu permalinki hedefler ve kullanıcı kaydırmayı fragment ile yapar. Eğer thread view gibi ayrı bir sayfa açılıyorsa, o sayfanın index/noindex politikası net tanımlanmalı; filtreli görünümler “kullanıcı aksiyonları sonucu” sınırsız çoğalmamalıdır.

Index bloat riskini azaltan kontrol: Reply tıklanınca oluşan URL varyantlarının canonical’i her zaman ana mesaj permalinki olmalı; replyTo gibi parametreler gerekiyorsa canonicalize edilmeli veya noindex uygulanmalıdır.

Beğen Butonları: Like count ve kullanıcıya özel durumun HTML’de varlığı/kısıtları

Beğen sayısı (like count) değişkendir; bu değişkenlik tek başına SEO açısından felaket değildir. Fakat “kişiselleştirilmiş” like durumu HTML’de indekslenebilir metin olarak görünür hale gelirse, aynı içerik farklı kullanıcılar için farklı görünmeye başlar. Botların gördüğü HTML varyantları da bu çoğalmayı tetikleyebilir.

İyi örnek yaklaşım: Like butonu sabit bir DOM yapısı olarak sunulur (ikon + label + erişilebilir metin). Like count’u SSR’de yalnızca deterministik bir stratejiyle verirsiniz: örneğin “son bilinen toplu sayı”yı SSR’de basın; kullanıcıya özel “beğendin” durumunu CSR’de güncelleyin. Böylece indekslenebilir metin daha stabil kalır.

Kötü örnek: Kullanıcı oturum bilgisiyle “sen beğendin” durumu HTML’e girer ve botlar bu varyantları ayrı içerik gibi keşfeder. Bu; aynı mesajın birden fazla versiyonunun indekse düşmesi riskini artırır.

Noindex/Canonical Politikası: Aksiyonların sayfada oluşturduğu varyasyonlar için genel kurallar

Noindex/canonical kararı, aksiyonun sayfayı farklılaştırma derecesi ve bu farklılığın gerçek değer üretip üretmediğiyle ilgilidir. Eğer aksiyon state yalnızca bir kullanıcı için geçerliyse ve içerik aynı kalıyorsa, indekslenmeyi hedeflemek doğru değildir. Bu durumda canonical sabit kalmalı; aksiyonla oluşan varyantlar noindex (ve mümkünse robots/headers) ile korunmalıdır.

Genel kurallar: (1) Kullanıcıya özel state (beğendin/katıldın) HTML’de indekslenmemeli. (2) Share parametreleri canonical’i bozmayacak şekilde yönetilmeli. (3) Reply view/filter gibi içerik keşfine açık yeni görünüm sayfaları ya tek bir canonical permalinke bağlanmalı ya da noindex olmalıdır.

Test ve Ölçüm: Googlebot + render davranışı, log analizi, index coverage, farklı cihaz/UA karşılaştırma

“Bot-safe” yaklaşımı varsayımla değil ölçümle doğrulanmalıdır. Önce HTML’in deterministik olup olmadığını görsel değil, ham DOM karşılaştırmasıyla test edin. Ardından Googlebot’un render davranışını “fetch & render” olarak gözlemleyin. Log analiziyle hangi URL varyantlarının gerçekten keşfedildiğini tespit etmek kritik rol oynar.

Index coverage tarafında da; mesaj permalikiyle birlikte aksiyon varyantlarının (ör. query’li reply/share URL’leri) dizine girip girmediğini kontrol edin. Farklı kullanıcı oturumları ve farklı cihaz/UA profilleriyle karşılaştırma yapın; kişiselleştirilmiş metinlerin SSR’de sızıp sızmadığını doğrulayın.

Kontrol Listesi: “Bot-safe” HTML teslim standardı

Aşağıdaki kontrol listesi, aksiyon butonlarının hem SEO hem bot güvenliği açısından doğru “teslim standardını” temsil eder. Bunu ekip içi “render politikası” dokümanı olarak versiyonlayabilirsiniz.

Kontrol Noktası	Beklenen Davranış	Gözlemlenecek Kanıt
Beğen butonu DOM yapısı	İkon + label + erişilebilir metin sabit	SSR HTML’de aynı yapı
“Sen beğendin” kişiselleştirme	Indekslenebilir metin olarak SSR’de yok	Farklı oturumlarda SSR farkı
Paylaş URL parametreleri	Canonical sabit mesaj URL’i	Canonical tag query’leri temizliyor
Cevapla yönlendirme	Tekil mesaj permalinki + fragment/anchor	Reply varyantları çoğalmıyor

• Adım adım doğrulama 1: Aynı mesaj URL’ini (anon + oturumlu) iki farklı oturumla fetch edin; SSR HTML farklarını diffleyin.
• Adım adım doğrulama 2: Paylaş ve reply tıklanınca oluşan URL’lerde canonical/noindex etiketlerini inceleyin.
• Adım adım doğrulama 3: Google Search Console’da URL denetimi ve “indexing” davranışını takip ederek index coverage değişimini ölçün.

Yaygın hatalar (kaçınılması gerekenler)

Birçok ekip aksiyon butonlarını “sadece UI” zannedip SEO etkisini ikinci plana atıyor. Oysa pratikte aksiyon state, HTML varyasyonu ve URL parametreleri üzerinden indeks davranışını ciddi şekilde etkileyebiliyor.

• Kişiselleştirilmiş like state’ini SSR’de basmak: “Beğendin” gibi kullanıcıya özel metinler botlar tarafından farklı içerik olarak keşfedilebilir.
• Paylaş linkinde canonical’ı bozan query parametreler: UTM/ref parametreleri canonicalize edilmezse index bloat oluşur.
• Reply için filtreli sayfa çoğaltmak: Her tıklamada yeni thread/funnel sayfası üretmek crawl bütçesini tüketir.
• JS’siz bot fallback’in bozuk olması: Butonlar “sadece div” olur ve anlamlı link/etiket kalmaz; bot sayfayı eksik içerikle değerlendirir.

Örnek Senaryolar ve Uygulanabilir Akışlar

Aşağıdaki örnekler, iyi ve kötü örnek mantığını daha net hale getirir. Amaç; butonların HTML’de bot-safe şekilde görünmesini sağlamak, aynı zamanda aksiyon sonucu doğabilecek indeks varyasyonlarını sınırlamaktır.

İyi örnek: Like butonu sabit DOM, count SSR’de deterministik strateji

Like butonu her mesaj kartında aynı iskelette render edilir; ikon ve erişilebilir label sabit kalır. Like count, SSR’de mümkünse “toplu” ve deterministik bir sayıyla basılır; kullanıcıya özel “beğendin” durumu CSR ile güncellenir.

Kötü örnek: Kullanıcı oturumuna göre HTML’de “beğendin” state’ini basıp botların farklı kullanıcı varyantlarını farklı içerik gibi görmesine neden olmak.

Cevapla butonu: mesaj permalinki ile çalışıp index bloat riskini azaltmak

Reply butonu her zaman mesaj permalinki üzerinde çalışır. URL tasarımı tekil olmalı: örneğin /oda/slug/mesaj/123. Kullanıcı “cevapla”ya tıklayınca ya aynı sayfada anchor’a kayılır (#reply-to-123) ya da yine mesaj permalinki ile ilgili bölüme yönlendirilir. Böylece reply tıklamaları yeni içerik URL’i çoğaltmaz.

Reply view gerekiyorsa canonical: ana mesaj permalinki; noindex: filtreli/ara görünümler. Bu yaklaşım hem keşfi toparlar hem de dizin şişmesini azaltır.

Paylaş butonu: utm kullan ama canonical’ı koru

Paylaşım için parametre kullanabilirsiniz: örneğin ?utm_source=chatyerim&utm_medium=share. Ancak sayfa HTML’inde canonical mutlaka /mesaj/123 gibi “temel” URL’i göstermelidir. Böylece ölçüm yapılırken SEO sinyalleri bozulmaz.

OG etiketlerinde de sabit mesaj içeriğine odaklanın; aksi halde aksiyon state’leri OG snippet’i değiştirebilir ve sosyal sinyaller varyanta bölünebilir.

JS’siz bot fallback: buton çalışmasın ama anlamlı kalsın

JS’siz çalışan botlar için “tıklama” beklemeyin; ancak butonların anlaşılır link/etiket yapısını koruyun. Örneğin “cevapla” butonu bir <a> fallback olarak mesaj permaliki hedeflemeli; “paylaş” için de copy/share dialog yoksa bile en azından paylaşılabilir URL bir link olarak bulunmalıdır.

SSS: Eylem butonları ve SEO kararları

Eylem butonlarını tamamen SSR mi yapmalıyız, yoksa sadece link/label yeterli mi?
Genellikle butonun iskeletini (ikon + erişilebilir label + anlamlı fallback link) SSR ile sabitlemek iyi bir başlangıçtır. Aksiyonun kendisi (like/reply state güncelleme) CSR ile yapılabilir; fakat indekslenebilir metinlerde deterministik davranış şarttır.

Like count kullanıcıya göre değişiyorsa HTML’de göstermeli miyim?
Kullanıcıya göre değişen kişiselleştirilmiş count/etiketler SSR’de indekslenebilir metin olarak gösterilmemelidir. Toplu sayı veya deterministik “genel” metrik SSR’de, kişisel durumlar CSR’de güncellenmelidir.

Paylaş butonunda URL parametresi kullanınca canonical nasıl korunmalı?
Canonical her zaman parametresiz temel mesaj URL’ini göstermelidir. Share linkinde utm_ gibi parametreler olabilir; fakat canonicalize edilmesi gerekir.

Cevapla butonuna tıklanınca oluşan yeni thread/filtrelenmiş görünüm indekslenmeli mi?
Genellikle hayır. Reply/filter görünümleri kullanıcı aksiyonuyla oluştuğu için içerik aynı kalıyorsa veya tekrar niteliğindeyse noindex/canonical ile korunmalıdır. Tekil mesaj permaliki ana indeks hedefi olmalıdır.

JS’siz çalışan botlar için butonlar nasıl “anlamlı” olmalı?
Butonlar en azından <a> fallback ile mesaj permaliki ya da ilgili sayfayı hedeflemeli. “Tıklama gerçekleşmeyebilir” kabul edilir; ama bot sayfada navigasyon/semantik anlamı görmelidir.

Aksiyon butonları event tracking için veri attribute’ları taşırsa SEO’yu etkiler mi?
Genellikle doğrudan SEO etkisi beklenmez; ancak kişisel/veri seti gibi bilgileri HTML’e gömüyorsanız varyasyon ve gizlilik riskleri doğar. Ayrıca attribute değişimleri SSR HTML’i kişiselleştiriyorsa deterministikliği bozabilir.

Aynı mesaj için birden fazla aksiyon varyasyonu (share/reply) sayfa çoğaltır mı?
Eğer share/reply farklı URL’ler üretip canonical/noindex politikası yanlışsa evet, çoğaltır. En iyi yaklaşım: tekil mesaj permaliki temel alınarak varyantların indekslenmemesidir.

Ne tür durumlarda noindex/canonical şart olur?
Kullanıcıya özel state’ler, filtrelenmiş thread görünümleri, paylaşım parametreli varyantlar ve içerik aynı/çok benzerken sadece URL farkı olan sayfalarda noindex/canonical şarttır. Aksiyonlar yeni “değerli farklı içerik” üretmiyorsa indekslemeye gerek yoktur.

İlgili okumalar

Ekip içinde benzer kararları bağlamlandırmak için şu teknik başlıklardan yararlanabilirsiniz: Chat’te Beğenilenler & Cevaplarım Sayfaları Crawl Edilsin mi? CTR–Dwell Time Ölçümüyle İndeks Kararı Rehberi ve Chat Sitelerinde “Message Tag” (Etiketlenmiş Mesajlar) URL Üretimi ve Noindex/Index Kararı.

Ayrıca, “bot-safe görünürlük” ve indeks sinyali ilişkisini görmek için Moderatör Yanıtı / Mod Note HTML Olarak Görünmüyorsa SEO Etkisi Olur Mu? (Bot Safe Görünürlük, Index Sinyalleri ve Kontrol Planı) içeriği de doğrudan yardımcı olur.