Chat Mesajında Eylem Butonları (Beğen/Cevapla/Paylaş) Bot-Safe HTML Nasıl Tasarlanır? SEO’da İndekslenmemesi/İndekslenmesi Gereken DOM Bölümleri
Chat deneyiminde mesaj başına “beğen”, “cevapla”, “paylaş” gibi eylem butonları eklemek, çoğu zaman gayet sıradan görünür; ama işin HTML ve DOM tarafı ihmal edilirse botlar bu UI parçalarını yanlış şekilde indekslemeye başlayabilir. Bu da crawl bütçesinin gereksiz yerlere akmasına, arama sonuçlarında kötü önizleme/snippet’lere kadar uzanabilir. Bu rehberde, “Chat sitesinde mesaj içeriği için ‘Eylem butonları’ (beğen, cevapla, paylaş) HTML’de hangi bileşenler bot-safe olmalı?” sorusunu, SEO hedefleriyle uyumlu bir DOM/HTML yaklaşımıyla ele alıyorum.
Amacımız basit: eylem butonlarının “kendi başına taranabilir sayfa içeriği” gibi davranmasını engellemek. Bunun yerine, yalnızca doğru DOM parçalarının (ör. asıl mesaj metni) görünür ve indekslenebilir olmasını sağlıyoruz. Bu yüzden SSR/CSR farklarını, aria/hidden stratejilerini, event izolasyonunu ve link/URL üretim yönetimini birlikte ele alacağız.
Kapsam ve varsayımlar: chat mesajı, eylem butonları ve bot-safe tanımı
Bu yazı, tek bir chat mesajı bileşenini düşünerek ilerler: kullanıcı bir mesaj gönderir, mesaj gövdesi (metin, görsel/ek, zaman bilgisi) render edilir; mesajın yanında ya da altında “beğen”, “cevapla”, “paylaş” gibi eylemler bulunur.
“Bot-safe” derken şunu kastediyorum: Arama motoru botları (ve diğer indexleyen “ışık botlar”) eylem butonlarının HTML’ini gördüğünde, bu butonlar onlara bir değerli sayfa içeriği gibi görünmemeli. Ayrıca butonlar istenmeyen URL’ler üretip crawl’i tetiklememelidir. Bot-safe tasarım, “tıklama davranışını” UI/JS katmanında tutar; “indeks değeri” olan içerik alanını ise mesaj gövdesine taşır.
SEO açısından hedefimiz, mesaj metninin ve gerçekten anlamlı sayfa içeriğinin indekslenebilmesi; eylem UI’sının ise ya hiç indekslenmemesi ya da indekslenme riski en düşük şekilde yönetilmesidir. Böylece hem indeks israfı azalır hem de performans iyileşir.
Eylem butonları için tipik riskler: index israfı, duplicate link, crawl tetikleme, yanlış zengin sonuç
Eylem butonları çoğu ekipte “salt UI” olarak görülür; ancak HTML yapısı ve link üretimi biçimi, crawler’ların gördüğü DOM üzerinde etkili olur. Özellikle ile yapılan aksiyonlar ve içinde track parametreleri olan href’ler, farklı varyantlar doğurabilir.
Tipik riskleri dört başlıkta toplayabiliriz: (1) index israfı: buton etiketleri/tooltip içerikleri “sayfa içeriği” gibi algılanabilir, (2) duplicate link/URL üretimi: beğen/cevapla/paylaş için her tıklamada ya da render’da farklı URL/parametre türetilmesi, (3) crawl tetikleme: botlar href üzerinden yeni sayfalara “takılabilir”, (4) yanlış zengin sonuç/önizleme: popover/modal içinde bulunan metinler, doğru noindex kurgusu yoksa snippet kalitesini bozabilir.
Bot-safe HTML prensipleri: görünürlük, erişilebilirlik, etkileşim izolasyonu
Bot-safe tasarımın omurgası “görünen içerik ile indekslenmesi istenen içerik” ayrımını netleştirmektir. Mesaj metni ve anlamlı bağlam SSR’de doğru şekilde bulunmalı; eylem butonları ise etkileşim için işlev görürken crawler açısından “anlamlı sayfa parçası” gibi durmamalıdır.
Görünürlük stratejisi, CSS/hidden ayrımıyla ele alınır. Örneğin popover içeriğini ilk yükte DOM’a basmak yerine lazy mount ile sonradan eklemek, botların içerik yüzeyini görmesini azaltır. Erişilebilirlik (aria-label, role, aria-expanded) korunmalı; ancak “ekran okuyucuya açık” olan bilgi her zaman “botun indeksleyeceği bir metin” olmak zorunda değildir.
İletişim izolasyonu için en iyi pratik, Progressive Enhancement yaklaşımıdır: temel HTML kullanıcıya anlaşılır görünür (ve erişilebilir), aksiyon akışları ise JS ile yönetilir. Böylece botlar “tıklama” yapmasa bile HTML üzerinde yanlış link/URL/örnek akış tetiklenmez.
DOM ayrıştırma: “mesaj içeriği” ile “eylem UI’sı”nı ayırın
Chat mesajında genellikle iki farklı doğa vardır: (a) içerik (mesaj metni, kaynak referansı, gönderim zamanı, kullanıcı adı/etiket bağlamı), (b) operasyon arayüzü (beğen/cevapla/paylaş butonları, popover menüler, tooltip açıklamaları). SEO ve bot-safe açısından bunları DOM’da ayırmak kritik önem taşır.
Pratikte şu kuralı uyguluyorum: Mesaj içeriği “indexlenebilir doğruluk alanı”dır; eylem UI’sı ise “etkileşim alanı”dır. SSR’de içerik alanını erken render edin; eylem UI’sını da gösterebilirsiniz ama içindeki “taranabilir link hedefleri” ve “kopya metin gövdeleri” botların yüzeyine minimum düzeyde çıkmalıdır.
HTML işaretleme stratejileri:
SEO’da en sık hata, aksiyonu etiketine koyup href’yi tıklama olmadan ya da hızlı render ile doldurmaktır. Eğer aksiyon bir “sayfa navigasyonu” değilse,
Yine de erişilebilirlikten vazgeçmeyin. aria-label, aria-controls, aria-expanded gibi nitelikler eylemin ne olduğunu ifade eder. Ayrıca veri bağlama (data-attribute) ile mesaj kimliğini taşıyın; bu veri indekslenmesin diye gerekliyse sadece JS tarafından okunan, görünmeyen alanlarda kurgulayın.
- Mesajı ve metnini “içerik alanı” olarak SSR’de görünür bırakın.
- Eylemleri “etkileşim alanı” olarak render edin; href üretmeyin veya üretilecekse canonical/uyarı politikası uygulayın.
- Popover/modal gibi kopyalanan metinleri ilk yükte mount etmeyin; lazy render ile ekleyin.
İndeksleme stratejisi: metin, sayfa içi anchor, modal/tooltip içerikleri
İndeksleme stratejisini “hangi DOM parçası botun dikkatini çekmeli?” sorusuyla kurun. Asıl mesaj metni, okunabilirliği yüksek olduğu için indekslenebilir olmalıdır. Sayfa içi anchor (ör. “yanıt akışına git”) gerekiyorsa bile href’nin oluşturduğu URL/parametreleri kontrol edin.
Modal/tooltip içerikleri için risk daha yüksektir. Örneğin “paylaş önizlemesi” veya “cevap verirken alıntılanan mesaj metni” popover içinde aynen duruyorsa, botlar bunu indekslemek isteyebilir. Bu yüzden popover gövdesini ilk yükte DOM’a eklemeyin; eylem tetiklenince lazy mount edin.
Bir diğer pratik: “beğen/yanıt sayıları (count)” gibi sayısal verileri indekslenmeye değer görmeyin. Bot-safe tasarımda bu değerler UI için vardır; ama “sayfa hakkında anlamlı bir içerik” olmamalıysa görünmez tutun veya semantic metinden ayırın.
CSR/SSR modeline göre yönergeler: ilk yükte DOM’da ne olmalı?
SSR kullanıyorsanız, ilk yükte mesaj metnini ve temel bağlamı (kimlik, zaman damgası, içerik) kullanıcıyla birlikte bot için de görünür kılın. Eylem butonlarını da gösterebilirsiniz; fakat eylem aksiyonlarının “görünen URL hedefleri” ile botun gezinmesini tetiklemeyecek şekilde tasarlayın.
CSR’de ise başlangıç HTML’i daha minimal olabilir. Bu durumda eylem butonlarını sonradan eklemek bot-safe olmayı artırabilir; ancak sosyal paylaşım gibi linklerin HTML’e sonradan basılması da botların gördüğü DOM’u değiştirebilir. Bu yüzden “Googlebot’un gördüğü DOM” ile “kullanıcıya görünen DOM” arasındaki farkı ölçmek şart.
Öneri: SSR’de içerik alanı “truth source” olsun; eylem UI’sı için ise güvenli state yönetimi tercih edin. Bu; etkileşimleri JS eventleriyle başlatır, crawler’ın tıklama beklemediği için yanlış gezinmeler oluşmaz.
Bot sinyalleriyle uyum: robots/x-robots, canonical ve event tetikleyen linklerden kaçınma
Robot sinyalleri tek başına “HTML tasarımı”nın yerini tutmaz; ama birlikte çalıştıklarında risk azalır. Eğer bazı sayfa/sekme türlerini index dışı tutuyorsanız (ör. kullanıcı eylemlerine bağlı varyantlar), x-robots-tag veya meta robots ile bunu netleştirin.
Canonical konusu da önemlidir: tracking parametreli href üretmek yerine, paylaşım/push mantığını UI katmanında yürütün. Örneğin “share sheet” açan buton, başlangıçta boş href ile render edilebilir; JS ile sadece kullanıcı etkileşimi sonrası doğru paylaşım hedefi üretilir. Böylece botun taradığı DOM’da çoğalmış varyant URL’ler olmaz.
Ek olarak “event tetikleyen linklerden kaçınma” ilkesini uygulayın. Eğer amaç navigasyon değilse yerine
Uygulama örnekleri (iyi/kötü): beğen, cevapla, paylaş
Aşağıdaki örneklerde amaç, eylem butonlarının mesaj içeriğiyle karışmamasını ve botların gereksiz URL/Popover içeriğini indekslememesini sağlamak. Üstelik erişilebilirlik tarafı da gözden kaçmıyor.
Beğen butonu: <button type='button'> + data-attribute, hidden state örneği
İyi yaklaşım, beğen aksiyonunu bir gezinti gibi göstermemektir. Buton mesaj ID’sini taşır; count ise indekslenmeyecek şekilde ayrılır.
<div class="chat-message" data-message-id="m123">
<p class="message-text">Bugün toplantı var.</p>
<div class="message-actions" aria-label="Eylemler">
<button type="button"
class="action-like"
data-target-id="m123"
aria-label="Mesajı beğen">
Beğen
</button>
<span class="like-count" aria-hidden="true">12</span>
<span class="sr-only">Beğeni sayısı: 12</span>
</div>
</div>Kötü örnek ise beğen için her mesajda indekslenebilir href üretmektir. Örneğin <a href="/messages/m123/like?utm=..."> gibi tracking’li gezinmeler crawler tarafından taranabilir veya varyantları artırabilir.
Cevapla butonu: “yanıt akışına git” aksiyonu için href yerine güvenli state
“Yanıt akışına git” gibi bir davranışta amaç navigasyon değil, UI içinde yeni bir “reply composer” açmaksa href üretmeyin. Bunun yerine güvenli state yönetimi kullanın; gerekliyse sadece kullanıcı etkileşimi sonrası anchor kaydırması yapın.
<button type="button"
class="action-reply"
data-reply-to="m123"
aria-label="Bu mesaja cevap ver">
Cevapla
</button>
<div id="replyComposer" hidden>
<!-- JS ile, sadece kullanıcı tıklayınca mount edilir -->
<textarea aria-label="Yanıt metni"></textarea>
</div>Bu örnekte “canonical/URL üretimi” devreye girmediği için botlar rastgele parametreli sayfalara gitmez. Eğer yine de sayfa içi URL değişimi gerektiriyorsanız (ör. geri/ileri davranışı), bunu yalnızca kullanıcı aksiyonu ile yapın ve duplicate üretimini engelleyin.
Paylaş butonu: sosyal URL’leri DOM’da önceden üretmek yerine JS ile üretme
Paylaş aksiyonlarında en kritik nokta, sosyal URL’lerin DOM’a önceden basılmasıdır. DOM’da önceden üretilen share linkler botun gördüğü yüzeyde çok sayıda dış hedef ve tracking parametresi oluşturabilir. Bot-safe yaklaşım: href’yi boş bırakın, JS ile kullanıcı tıklayınca doldurun.
<button type="button"
class="action-share"
data-message-id="m123"
aria-label="Bu mesajı paylaş">
Paylaş
</button>
<!-- Share sheet için link hedefi sadece tıklanınca üretilecek -->
<div id="shareSheet" class="share-sheet" hidden>
<a id="shareLink" href="#" rel="nofollow noopener" target="_blank">
Share
</a>
</div>
<!-- JS: kullanıcı tıklayınca href'yi güvenli şekilde doldur -->İsterseniz “href="#" yaklaşımı” yerine button ile doğrudan native paylaşım akışını da tercih edebilirsiniz. Ancak hedef dış domainlere giden linkleri mümkünse etkileşim sonrası üretin; böylece SEO açısından “görünen DOM” daha temiz kalır.
Popover/modal içeriği: lazy mount ile DOM’a ne zaman ekleyeceksiniz?
Popover/modal içinde mesaj metnini aynen kopyalamak indeksleme riskini artırabilir. “Lazy mount” ile popover gövdesini ilk yükte eklemeyin; buton tetiklenince ekleyin ve botların görme ihtimalini azaltın.
<button type="button" class="action-more" data-message-id="m123">
Daha fazla
</button>
<!-- Popover ilk yükte yok -->
<div id="morePopover" role="dialog" aria-modal="true" hidden>
<!-- JS ile açılınca mount edilecek içerik -->
</div>
<script>
// JS: tıklanınca içerik üret
// mount ederken aynen kopyalanacak metni minimum tutmayı düşün
</script>Yaygın hatalar: eylem butonlarını yanlış yapılandırmak
En sık görülen hatalardan biri, eylem butonlarını olarak yazıp href’yi (hatta tracking parametreleriyle) anında üretmektir. Böylece crawler, butonları “dolaşılacak içerik” sanabilir; özellikle yanıt akışına giden dinamik URL’ler veya share linkleri çoğaldığında crawl bütçesi zarar görür.
Bir diğer yaygın hata, tooltip/popover/modal içeriklerini ilk yükte DOM’a basmaktır. Özellikle “cevap verirken alıntı” gibi metinler, birden fazla mesaj için tekrar ederse indexlenme riski artar ve snippet kalitesini düşürür. Üçüncü hata ise beğen/yanıt gibi sayıları semantik metin gibi sayfa içine yerleştirmektir; botlar bunları sayfanın ana teması sanabilir.
İndekslenmesi gerekip gerekmeyen parçalar: net DOM haritası
Bu bölümde, chat mesaj bileşenini “botun gördüğü” açıdan sınıflandırıyorum. Unutmayın: Buradaki öneri, SEO ve performans hedefleri birlikte düşünüldüğünde en güvenli dengeyi kurar.
| DOM parçası | Bot açısından risk | Önerilen davranış (bot-safe) | Not |
|---|---|---|---|
| Mesaj metni (.message-text) | Düşük (ama kaliteye bağlı) | SSR’de görünür, indekslenebilir | Asıl içerik burada olmalı |
| Beğen butonu | Orta (yanlış href/hidden içerik) | Tracking’li URL üretmeyin | |
| Cevapla UI (composer) | Orta-Yüksek | href’siz state; composer lazy mount | Yanıt akışını kullanıcı aksiyonu açsın |
| Paylaş bağlantıları (shareLink) | Yüksek | href’yi önceden basmayın; JS ile etkileşim sonrası üretin | nofollow/noopener opsiyonel |
| Popover/modal gövdesi | Yüksek | İlk yükte mount etme; açılınca ekle | Mesaj metnini aynen kopyalamak risk yaratır |
Test ve ölçüm: nasıl kontrol edilir, adım adım doğrulama
Bot-safe tasarımın gerçekten çalıştığını kanıtlamanın yolu, “yalnızca gözle manuel test” yapmak değil. Googlebot’un gördüğü DOM ile kullanıcıya görünen DOM arasındaki farkı ölçmeli; ayrıca render akışını da doğrulamalısınız.
Aşağıdaki adım adım doğrulama akışı pratikte işe yarar:
- İlk yük DOM: Mesaj sayfasını “sayfa kaynağı” ve “render edilmiş DOM” olarak inceleyin. Eylem popover/modal içerikleri ilk yükte var mı yok mu kontrol edin.
- Bot senaryosu: Google Search Console’da URL inceleme ile “render” çıktısını karşılaştırın. Eylem butonlarının içinde botun tarayacağı anlamlı href/kopya metin var mı bakın.
- Fetch+render doğrulama: Headless testte buton tıklanmadan oluşan DOM’u loglayın; sadece mesaj içeriğinin indekslenebilir yüzeyde kaldığını doğrulayın.
- Site: ve log analizi: “/like”, “/share”, “reply?…” gibi aksiyon URL desenlerinin arama sonuçlarında veya crawler loglarında çoğalıp çoğalmadığını gözlemleyin.
Ek olarak, sayfa içi ölçüm olarak “hangi DOM nodları görünür ama indekse uygun” sorusunu izleyin. Örneğin event tetiklenmeden oluşan shareLink var mı? Varsa, href üretimi yanlış olabilir.
SEO kararı: eylem butonlarını indekslemek yerine kullanıcı değerini artırın
Buradaki temel yaklaşım, serp promise vaadini karşılamak içindir. Eylem butonlarının yanlışlıkla indekslenmesini önleyip crawler’ın gördüğü DOM ile kullanıcı deneyimi arasında kontrol sağlıyoruz. Bu tasarımla indeks israfını azaltırken kullanıcı etkileşimini de bozmuyorsunuz.
Özellikle dinamik chat etkileşimleri (beğen, cevapla, paylaş) doğası gereği çok varyant üretebilir. Bu varyantların sayfa yüzeyine “link/URL” olarak taşınması, indexlenmesi gerekmeyen alanların indexlenmesine kadar gidebilir. Bu yüzden bot-safe HTML tasarımını, SSR/CSR stratejinizin ayrılmaz parçası yapın.
Bu konuda daha fazlasını deneyimlemek ister misiniz?
Sohbet Odalarına Katılın →İç bağlantılarla tamamlayın: chat SEO mimarisi ve crawl bütçesi
Eylem butonlarının bot-safe HTML tasarımı, tek başına bir kazanım değildir. Chat ürünlerinde crawl bütçesi ve dinamik varyant yönetimi bütüncül ele alınmalıdır. Bu nedenle aşağıdaki rehberler, mesaj içeriği dışındaki yüzeylerin nasıl kontrol edileceğine dair tamamlayıcı bir çerçeve sunar.
Örneğin Chat’te “Yeni Odalar / Recent Rooms” SEO’da Kalıcı Landing Olmalı mı? Tarih Tabanlı URL Yerine Politika Rehberi dinamik listelemelerde index/noindex kararlarını netleştirir. Benzer şekilde Chat Sitelerinde “Room Sidebar” Crawl’i: Featured/Ads Taraması Nasıl Kontrol Edilir ve Crawl Bütçesi Nasıl Korunur? yan menü gibi taranması gerekmeyen UI alanlarını yönetme yaklaşımını destekler.
Sık sorulanlar (SSS): eylem butonları HTML’de nasıl düşünülmeli?
Eylem butonlarını <a> olarak mı, <button> olarak mı yazmalıyım? SEO/crawl açısından fark nedir? Aksiyonu bir navigasyon değilse <button> tercih edin. <a> ise href içeriyorsa botun tarayabileceği bir gezinme sinyali üretir; bu da crawl tetikleyebilir. Bot-safe yaklaşımda “tıklama” JS event ile yönetilir.
Beğen/yanıt sayıları (count) DOM’da görünür olmalı mı, yoksa bot-safe şekilde gizlenmeli mi? Kullanıcı için UI’de görünmesi gerekir; fakat indeks için “sayfa ana konusu” gibi davranmaması önemlidir. Bu yüzden aria-hidden kullanarak sayıyı indekslenebilir metin akışından ayırabilir, gerekiyorsa ekran okuyucu için sr-only ile taşıyabilirsiniz.
Modal/popover içinde mesaj metnini aynen kopyalamak indexlenme riskini artırır mı? Evet. Özellikle popover/modal ilk yükte DOM’a basılıyorsa veya bot bunu render edebiliyorsa risk artar. Lazy mount ve minimum metin kopyalama ile bu riski düşürün.
Paylaş butonunda sosyal URL’leri DOM’da önceden üretmek SEO’da sorun çıkarır mı? Çıkarabilir. DOM’a önceden yazılan çok sayıda share href, farklı parametre varyantları oluşturabilir. En bot-safe yaklaşım: href’yi boş tutup JS ile kullanıcı tıklayınca üretmektir (ve tracking parametreleri kontrol edilmelidir).
SSR ile ilk yükte eylem butonlarını render etmek mi, yoksa sadece CSR ile sonradan mı eklemek daha bot-safe? Aksiyon UI’sini SSR’de göstermek genelde sorun değildir; asıl mesele “indekslenebilir bağlantılar ve kopya metin” yüzeyidir. Yine de tamamen CSR ile geç render, popover içeriği gibi riskli parçalar için daha bot-safe olabilir. En iyi yöntem: içerik doğrusu SSR, riskli UI parçaları lazy/CSR.
Googlebot’un ‘gördüğü’ DOM ile kullanıcıya görünen DOM farklı olduğunda hangi kontroller yapılmalı? URL İnceleme/Render çıktısını ve headless render karşılaştırmalarını yapın. Butona basmadan oluşan DOM’da popover gövdeleri var mı, shareLink href dolu mu, tracking URL’ler görünüyor mu kontrol edin.
Aynı buton için farklı sayfalarda tekrar eden URL/parametre üretmek (tracking) index israfı yapar mı? Yapabilir. Tracking parametreli href’ler veya farklı query kombinasyonları, botun yüzeyde ekstra varyantlar görmesine neden olabilir. Bu nedenle aksiyon URL’lerini botun tarayacağı şekilde çoğaltmayın; gerekiyorsa event sonrası üretin.
Kontrol listesi + kısa özet
Aşağıdaki kontrol listesi, bu yazının “bot-safe HTML” hedefini pratikte sahaya indirir. Bir chat mesaj bileşenini audit ederken bunu doğrudan kullanabilirsiniz.
- Mesaj içeriği (metin/bağlam) SSR’de doğru ve indekslenebilir mi?
- Eylem aksiyonları navigasyon değilse
<button type="button">ile mi yazıldı? - href üretimi var mı? Tracking/parametreli share/like/reply URL’leri botun ilk yükte gördüğü DOM’da dolu mu?
- Popover/modal ilk yükte DOM’a basılmıyor mu? Lazy mount ile açılınca mı ekleniyor?
- Count ve sayısal veriler aria-hidden/sr-only ile indeks akışından ayrılmış mı?
- Googlebot render ile kullanıcı DOM’u karşılaştırıldı mı?
- Log/site: gözlemi ile aksiyon URL desenleri crawler tarafından çoğalıyor mu kontrol edildi mi?
Kısa özet: Chat mesajındaki “Eylem butonları” UI’sı kullanıcıya hızlı ve erişilebilir olmalı; fakat bot açısından anlamlı bir gezinme/indeks yüzeyi gibi davranmamalıdır. Bu dengeyi kurmanın ana yolu, DOM ayrımını yapmak (mesaj içeriği vs eylem UI’sı), SSR/CSR’de riskli parçaları lazy mount etmek, <a> ile gereksiz href üretimini azaltmak ve event tetikleyen linkleri botun tarayamayacağı şekilde kurgulamaktır.
ChatYerim'de Binlerce Kişi Seni Bekliyor
Hemen ücretsiz hesabını oluştur, sesli ve görüntülü sohbet odalarına katıl.
Hemen Katıl