Sohbet Sitelerinde robots.txt ile Hangi Endpoint’ler Engellenmeli? (WebSocket, Media, Moderation API Rehberi)

Sohbet platformlarında “robots.txt koyalım, huzur olsun” yaklaşımı sık duyulur. Fakat sohbet sitesi için robots.txt ile hangi endpoint’ler engellenmeli (websocket, media, moderation API) sorusunun cevabı; crawl bütçesi, indekslenme hedefleri ve güvenlik gereksinimleri arasında doğru dengeyi kurmayı gerektirir. Bu rehber, sohbet sitesi sahipleri ve teknik SEO/DevOps ekipleri için endpoint türlerini sınıflandırıp “engelleme/engellememe” karar çerçevesini uygulamalı bir dille ele alır.

Unutmayın: robots.txt bir “güvenlik bariyeri” değildir; daha çok arama motoru botlarının tarama davranışını nasıl yöneteceğine dair bir sinyaldir. Yine de doğru endpoint engellemesi; gereksiz istekleri azaltır, sunucu kaynaklarını korur ve yanlış tarama yüzünden oluşabilecek SEO performans kayıplarını önlemeye yardımcı olur.

Kapsam ve neden robots.txt (ve neden bazı şeyler için robots.txt tek başına yetmez)

Bu yazı; sohbet sitelerinde WebSocket bağlantıları, medya akışları (video/görüntü/thumbnail/stream), moderasyon ve admin benzeri API’ler gibi “endpoint” odaklı konuları ele alır. Hedef, arama motoru botlarının taraması gereken içerik sayfalarını (HTML odalar, dizinlenebilir arşiv sayfaları gibi) korurken, taranmaması gereken kaynak/işlem yoğun istekleri sınırlamaktır.

robots.txt; arama motoru botlarının isteklerini yönlendirmek için kullanılır. Ancak WebSocket oturumları, medya stream’leri ve moderasyon kontrolleri çoğu zaman sadece tarama değil, aynı zamanda uygulama tarafında iş yükü de doğurur. Bu yüzden robots.txt tek başına “tam çözüm” olmayabilir; kimlik doğrulama, hız sınırlama (rate-limit), WAF/firewall ve uygulama seviyesinde yetkilendirme gibi ek katmanlar da gerekir.

Arama motoru istekleri nasıl kategorize edilir: HTML sayfalar, statik varlıklar, media stream’leri, API çağrıları, WebSocket bağlantıları

Sohbet sitenizde botların yaptığı taramaları daha net okumak için istekleri “tip” bazında sınıflandırın. Pratikte beş ana grup öne çıkar: (1) HTML sayfalar (oda sayfaları, listeleme sayfaları), (2) statik varlıklar (CSS/JS/img), (3) medya akışları ve kaynaklar (thumbnail, video stream, stream chunk’ları), (4) API/endpoint çağrıları (mesajlar, arama, moderasyon, raporlar) ve (5) WebSocket bağlantıları / long-lived bağlantılar (real-time olayları taşıyan bağlantılar).

Bu ayrım kritik, çünkü tüm istek tipleri aynı risk/etkiyi üretmez. Örneğin HTML sayfaları indekslenmek istenen hedef olabilir; ama aynı botun /media/ altındaki stream chunk’larına girmesi hem crawl bütçesini gereksiz harcar hem de sunucu performansını etkiler. Benzer şekilde botların moderasyon API’lerini çağırması, hem gereksiz yük getirebilir hem de hassas akışların istemeden görünür hale gelme ihtimalini artırabilir.

Karar matrisi: Endpoint tipi / neden engellenir mi? (crawl bütçesi, indekslenme etkisi, güvenlik/performans)

Aşağıdaki karar matrisi, endpoint türü başına “engelle mi / engelleme mi?” yaklaşımını belirlerken işinizi kolaylaştıracak temel çerçeveyi verir. Asıl amaç; arama motorunun dizine eklemesini istediğiniz HTML içeriklerin crawl bütçesini boğmadan, kaynak/iş yükü yüksek uç noktaları sınırlamaktır.

Endpoint tipi	Engelleme kararı	Öne çıkan gerekçe
WebSocket /realtime, /ws, /socket.io	Genellikle Disallow	Long-lived bağlantı; “tarama” için uygun değildir, sunucu yükü ve gereksiz oturumlar yaratır
Media: /media/*, /stream/*, thumbnail	Genellikle kısmi (bazı kalıplar)	Stream chunk’ları crawl budget’ı yer; görsel/thumbnail doğru kısıtlanmazsa gereksiz tarama olur
Moderation API: /api/moderation/*	Genellikle Disallow	Hassas/operasyonel; botların tetiklemesi istemezsiniz; gereksiz otomasyon yükü
HTML oda sayfaları ve indekslenebilir arşiv	Engelleme (aksine Allow)	SEO hedefi: dizine ekleme; doğru internal linkleme ile değer üretir

Elbette “genellikle” kelimesi önemli. Çünkü bazı sitelerde medya varlıkları görsel arama için gerçekten değerli olabilir; bazı API’ler ise yalnızca doğrulanmış kullanıcılar içindir. Bu yüzden kararınızı mutlaka log analizi ve robots.txt testleriyle doğrulayın.

WebSocket endpoint’leri: robots.txt etkisi, doğru yaklaşım ve yaygın yanlışlar

WebSocket endpoint’lerinde kritik gerçek şudur: robots.txt, tarayıcıların ve botların HTTP isteklerini yönlendirse de WebSocket protokolü “bağlantı kurma” mantığıyla çalışır. Bu yüzden botların bazı durumlarda WebSocket çağrılarına hiç girmemesi beklenebilir; girse bile davranış her zaman tutarlı görünmeyebilir. Yine de sohbet platformlarında WebSocket URL kalıplarını robots.txt ile Disallow etmek, “botların gerçek zaman kanalıyla gereksiz meşgul olmasını” azaltmak için çoğu zaman faydalıdır.

Yaygın yanlış, WebSocket’i baştan sona düşünmeden yalnızca “/api/” engellemek ya da tersine tüm siteyi “Disallow: /” ile kilitlemektir. WebSocket engeli, crawl bütçesini korurken arama motorunun HTML oda içeriklerini görmesini engellememelidir. Bu yüzden WebSocket için hedefli kalıplar kullanın: ör. /ws/, /socket.io/, /realtime/, /events gibi.

• Hedefli engelle: Disallow: /ws/, Disallow: /socket.io/, Disallow: /realtime/
• HTML’i koru: oda sayfaları /room/* veya /o/* gibiyse bunları Disallow etme
• İhtiyaca göre istisna: Bazı sitelerde WebSocket üzerinden “render edilen” ara içerikler varsa, önce logdan doğrula sonra karar ver

Media endpoint’leri (video/thumbnail/stream): hangi URL kalıpları engellenmeli, hangileri engellenmemeli

Medya endpoint’leri ikiye ayrılır: (1) indekslenebilir görsel/video bileşenleri (ör. thumbnail’ler, meta ile ilişkili görüntüler) ve (2) taranmaması gereken stream kaynakları (stream chunk’ları, segmentler, uzun süreli akışlar). Sohbet sitelerinde özellikle canlı yayın/medya eklentileri; yüksek bant genişliği ve yoğun istek yükü doğurabilir.

Bu nedenle robots.txt stratejisi çoğu zaman “kısmi engelleme” olur: thumbnail görselleri bazen görsel aramada görünürlük sağlayabilir; ancak stream chunk’ları ve segmentler botlar tarafından taranmamalıdır. Örneğin aşağıdaki kalıplar genellikle engellenir: /stream/*, /media/* içinde segment üreten alt yollar, /events gibi canlı olay uçları.

Öte yandan aşağıdaki gibi “tekil görsel dosyası” mantığında çalışan, nispeten statik ve değerli varlıkları tamamen kilitlemek her zaman doğru değildir: ör. /images/* veya /thumbnails/*. Burada kararı; “arama sonuçlarına katkı” ve “botların neyi taradığı” üzerinden verin.

Moderation API / admin benzeri endpoint’ler: hassas içerik, otomasyon ve gereksiz tarama riskleri

Sohbet platformlarında moderasyon ve raporlama gibi endpoint’ler sıklıkla operasyonel iş akışına bağlıdır. Örneğin: /api/moderation/*, /api/reports/*, admin panel veri akışları, yanlış pozitif/negatifleri etkileyebilecek etkileşimler… Bu uçların botlara açık olması “SEO” açısından bir katkı sağlamaz; aksine gereksiz çağrı, log şişmesi ve olası bilgi sızıntısı risklerini artırır.

Bu yüzden moderasyon API’lerinde genellikle robots.txt ile Disallow yaklaşımı uygulanır. Yine de hatırlatmakta fayda var: robots.txt “erişim engeli” değildir. Gerçek koruma için endpoint’lerin kimlik doğrulama (auth), rol bazlı yetkilendirme, rate-limit ve WAF ile korunması gerekir. Böylece bot robots.txt’yi görse bile görmese de istekler başarılı olamaz.

Diğer sık endpoint’ler: rate-limit, long-polling, event stream (SSE), health/check URL’leri

Sohbet sitelerinde “gerçek zaman” için yalnızca WebSocket yoktur. Bazı mimariler long-polling veya SSE (Server-Sent Events) kullanır. Bu tür endpoint örnekleri: /events, /sse, /poll. Bu uçlar genellikle tarama için tasarlanmadığından crawl bütçesini tüketme ve kaynak israfı üretme potansiyeli vardır; çoğu senaryoda robots.txt ile Disallow mantıklıdır.

Health/check URL’leri ise genellikle /health, /status, /ping gibi çalışır. Buraları botların taraması çoğu zaman istenmez; ama bazı ekipler “botsuz izleme” yaklaşımında beklenmedik davranışlarla karşılaşabilir. Burada net karar için logdan bot davranışını görün: botlar sağlık endpoint’ini tarıyor mu, yoksa hiç mi uğramıyor? Tarama varsa Disallow düşünün; tarama yoksa boş yere karmaşıklık eklemeyin.

Teknik format: robots.txt yazım kuralları (User-agent ayrımı, Allow/Disallow önceliği, wildcard kullanımının sınırlılıkları)

robots.txt dosyası genellikle /robots.txt adresinde sunulur ve iki temel direktife dayanır: Allow ve Disallow. En doğru uygulama, kullanıcı aracına (User-agent) göre ayrım yapmaktır. Örneğin Googlebot, farklı ajanlardan farklı şekilde yorumlayabilir.

Öncelik mantığını göz ardı etmeyin: birçok aramada en “spesifik” kural (en uzun eşleşme) daha etkili olur. Ayrıca wildcard (*) kullanımının her motor tarafından aynı şekilde yorumlanmayabileceğini bilmelisiniz. Bu yüzden mümkünse wildcard yerine net URL prefix’leri kullanın. Aksi halde “beklenmedik şekilde” bazı oda sayfalarını veya statik varlıkları istemeden kilitleyebilirsiniz.

Örnek robots.txt şablonları (farklı senaryolara göre 3-4 örnek)

Aşağıdaki şablonlar sohbet sitelerinde pratikte kullanılan yaklaşımları temsil eder. Kendi URL yapınıza göre prefixleri güncelleyin.

Örnek 1: Tüm ajanlar için WebSocket + stream + moderasyon engeli (genel güvenli başlangıç)

User-agent: *
Disallow: /ws/
Disallow: /socket.io/
Disallow: /realtime/
Disallow: /events
Disallow: /stream/
Disallow: /media/
Disallow: /api/moderation/
Disallow: /api/reports/

Örnek 2: Sadece botları hedefle (bazı indeksleme ihtimallerini koru)

User-agent: GPTBot
Disallow: /ws/
Disallow: /socket.io/
Disallow: /realtime/
Disallow: /api/moderation/
Disallow: /api/reports/
User-agent: *
Allow: /room/
Allow: /o/
Disallow: /ws/
Disallow: /stream/

Örnek 3: Allow/Disallow çatışması – önceliği netleştirme

Çatışma çıktığında kritik olan, “Allow” ve “Disallow”ın birlikte bulunması ve en uzun eşleşmenin etkisinin anlaşılmasıdır. Örneğin stream’i engellerken belirli bir thumbnail klasörünü açık tutmak istersiniz:

User-agent: *
Disallow: /media/
Allow: /media/thumbnails/
Disallow: /stream/
Disallow: /events

Burada /media/thumbnails/ daha spesifik olduğu için “thumbnail’ler taransın” niyetini yansıtır. Yine de doğrulama adımlarını uygulayın (aşağıda anlatıldı).

Örnek 4: “Aşırı engelleme” yerine kademeli yaklaşım (yüksek riskli endpoint’leri seç)

User-agent: *
Disallow: /ws/
Disallow: /socket.io/
Disallow: /api/moderation/
Disallow: /api/reports/
Disallow: /api/search?*

Not: /api/search gibi sorgu parametreli alanlarda wildcard kullanımı değişebilir. Bu yüzden mümkünse exact prefix ile ilerleyin ve parametre varyasyonlarını logdan tespit edin.

Yaygın hatalar

robots.txt ile endpoint engellerken en sık yapılan hata, hedefi iyi tanımlamamak ve “genel bir disallow” ile SEO’yu istemeden kırmaktır. Örneğin sohbet odası sayfaları /room/ altında değil de / benzeri bir mimarideyse, yanlış wildcard oda arşivlerini de etkileyebilir. Sonuç: crawl azalır, ama asıl içerikler de erişilemez hale gelir.

İkinci sık hata, WebSocket ve media stream’leri “robots.txt ile güvenlik” sanmaktır. robots.txt erişimi engellemez; sadece botların tarama davranışını etkiler. Buna ek olarak tarayıcılar her zaman robots.txt’yi takip etmeyebilir. Dolayısıyla gerçek koruma için auth, firewall ve rate-limit olmadan moderasyon API’lerini veya medya uçlarını açık bırakmak riskli olur.

Üçüncü yaygın hata, Allow/Disallow çatışmasını doğrulamadan yayına almaktır. Örneğin /media/* engellerken /media/thumbnails/* açık bırakmayı denemek isteseniz bile, kural eşleşmesi tam beklediğiniz gibi çalışmayabilir. Bu yüzden “doğrulama adımları” mutlaka uygulanmalıdır.

Doğrulama ve izleme: Search Console robots.txt test, log analizi, Crawl stats, fetch/derleme doğrulaması

Bu bölüm, “nasıl kontrol edilir” sorusunu pratik hale getirir. Endpoint engelleme kararınızı doğrulamak için aşağıdaki doğrulama adımları ile ilerleyin:

1. Search Console robots.txt testi: Güncel robots.txt’yi yükleyin ve engellemeyi hedeflediğiniz URL örneklerini test edin. Örneğin /ws/, /socket.io/, /api/moderation/, /stream/abc gibi test URL’leri seçin.
2. Log analiziyle davranışı doğrulayın: Yayından sonra sunucu loglarında botların artık hangi endpointlere gittiğini inceleyin. Örnek hedef: HTML taraması artarken /api/moderation/ çağrıları düşmeli; stream chunk’ları (segment/stream path) azalmalı.
3. Crawl istatistikleri ve Fetch/derleme doğrulaması: Search Console veya benzeri crawl raporlarında kaç sayfa/fetch gerçekleştiğini izleyin. Artış HTML sayfalarda mı, yoksa engellenmeyen endpointlerde mi? Gerekirse ayrıca otomatik “fetch” senaryoları kurup robots.txt kuralı ile beklenen davranışı karşılaştırın.

Ek olarak, logda sık görülen bir örnek üzerinden yorum yapalım: Eğer robotların /api/moderation/ çağırdığını görüyorsanız ve bunu engellerseniz, birkaç gün içinde bu isteklerin yerini çoğunlukla HTML oda sayfaları almalıdır. Eğer yerini hiç bir şey almıyorsa (crawl dramatik düşüyor), robots.txt kuralınız yanlışlıkla daha geniş bir aralığı kapsıyor olabilir.

Kontrol listesi (yayına almadan önce)

Aşağıdaki “kontrol listesi” ile robots.txt yayın öncesi riski azaltın:

• URL envanteri çıkarın: Sohbet mimarinizi tarayın; /ws/, /socket.io/, /realtime/, /api/moderation/, /stream/*, /events gibi kalıpları listeleyin.
• Hedefleri netleştirin: İndekslenebilir HTML sayfaları hangileri? (oda sayfası, arşiv listeleme, profil/etkinlik gibi)
• Allow/Disallow çatışması var mı? Özellikle medya/varlık klasörlerinde kademeli engel kurgulayın.
• Wildcard kullanıyorsanız test edin: Kural eşleşmesini özellikle /media/* gibi geniş kalıplarda doğrulayın.
• Logdan trend bakın: Yayın öncesi botların hangi endpointlere geldiğini 24-72 saat toplayın; yayın sonrası kıyaslayın.
• Güvenlik katmanlarını atlamayın: robots.txt yanında auth + rate-limit + WAF uygulandığından emin olun.

Güvenlik notu: robots.txt erişimi engellemez; alternatif kontrol katmanları (auth, firewall, WAF, uygulama seviyesi kısıtlar)

robots.txt, arama motoru botlarının davranışına “niyet sinyali” verir. Botlar robots.txt’yi izlemeyebilir; ayrıca bazı isteklere tarayıcıların veya farklı ajanların uyumu değişebilir. Bu nedenle robots.txt’yi moderasyon API veya admin benzeri uçları korumak için tek katman gibi düşünmeyin.

Doğru yaklaşım şudur: uygulama katmanında yetkilendirme ve doğrulama (auth), ağ katmanında firewall/WAF, ayrıca hız sınırlama (rate-limit) ve istek türü bazlı kısıtlar. WebSocket için de handshake, token doğrulama ve bağlantı başına limitler tanımlayın. Media stream’leri için erişim kontrolünü ve CDN cache kurallarını doğru yapılandırın.

İlgili teknik odaklar (isterseniz tamamlayın)

Sohbet sitelerinde endpoint engelleme kararları tek başına yeterli olmayabilir; crawl bütçesi ve görünürlük mimarisi de aynı resmin parçasıdır. Bu bağlamda şu rehberler, endpoint kararlarınızı daha iyi konumlandırmanıza yardım eder:

• Chat Sitelerinde Launch Ramp (Yeni Oda Açma Hızı) ile Crawl Bütçesini Yönetme Rehberi
• Server log analizi ile bot davranışını doğrulama
• Chat Sitelerinde Mesaj İçeriği Index mi Noindex mi? (SEO ve Kullanıcı Değeri Dengesi için Karar Rehberi)

SSS (WebSocket/Media/Moderation API özelinde)

robots.txt WebSocket bağlantılarını gerçekten engeller mi?

robots.txt WebSocket’i “protokol olarak” engellemez; ancak WebSocket endpoint URL kalıplarını Disallow ederek arama motoru botlarının bu URL’leri taramasını azaltabilirsiniz. Uygulamanızda WebSocket handshake ve yetkilendirme zaten olmalı; robots.txt sadece crawl davranışını yönetir.

Google WebSocket isteklerini hangi amaçla görür; SEO etkisi var mı?

Googlebot/diğer ajanlar bazı durumlarda sayfa içindeki kaynakları keşfederken “bağlantı kurma” yerine farklı sinyaller gösterebilir. Yine de WebSocket bağlantıları SEO için doğrudan bir dizin sinyali değildir. SEO etkisi daha dolaylıdır: WebSocket taraması crawl bütçesini yerse HTML içeriklerin taranması azalabilir.

Media endpoint’lerini engellersem görseller/video sonuçlarında düşüş olur mu?

Özellikle thumbnail ve görsel dosyalarını yanlışlıkla geniş kalıplarla engellerseniz görsel/video aramalarında görünürlük etkilenebilir. Bu yüzden /media/* gibi genel engeller yerine thumbnail klasörlerini Allow ile ayırmayı veya logla hangi alt yolların tarandığını belirlemeyi hedefleyin.

Moderation API’yi engellemek crawl budget’ı nasıl etkiler?

Moderation endpoint’leri “SEO değeri üreten” içerik değildir. Bu endpoint’leri Disallow ederek botların boşa giden API isteklerini azaltırsınız. Sonuç genellikle: HTML/indekslenebilir sayfalara daha fazla fetch.

robots.txt ile engellenen bir endpoint yine de dizine alınır mı?

Genel mantık şudur: robots.txt taramayı engeller; ancak “daha önce” erişilmiş/indekslenmiş bir içerik otomatik olarak her zaman silinmez. Ayrıca başka sitelerden linklenmiş veya önbellekte kalmış içerikler yine görülebilir. Kalıcı kontrol için uygun yerde noindex/meta veya içerik düzeyinde kontrol gerekir.

robots.txt yerine noindex veya meta tag daha mı doğru?

Eğer amacınız “sayfayı index’ten çıkarmak” ise noindex daha doğru araçtır. robots.txt ise “tarama”ya yön verir. Sohbet sitelerinde bazı sayfalar taranmasın (API/WebSocket) ama bazı sayfalar taransın, sadece index’lenmesin (ör. düşük değerli sayfa) gibi senaryolar ayrı ayrı değerlendirilmelidir.

Wildcard/kısmi eşleşme kullanırken nasıl hata yapmamalıyım?

En yaygın hata, /media/* gibi geniş kalıpları koyup thumbnail/görüntü klasörlerini de istemeden engellemektir. Kuralı daha spesifik yapın; önce logdan alt yol örneklerini çıkarın, sonra Allow/Disallow çatışmasını kural eşleşme önceliğiyle test edin.

Search Console robots.txt test aracı neyi gösterir, neyi göstermez?

Test aracı, belirlediğiniz URL örneği için robots.txt kuralının “engelliyor mu?” mantığını gösterir; fakat botların gerçek zamanlı davranışını, crawl bütçesi dağılımını ve diğer sinyalleri tek başına göstermez. Bu yüzden log analizi ve crawl stats ile birlikte değerlendirin.

Loglarda botların endpoint çağrılarını nasıl ayırt ederim?

Loglarda User-Agent, path ve response time/pattern üzerinden ayırın. Örneğin HTML taraması için düzenli /room/123 çağrıları görürken, yanlış tarama belirtisi olarak /api/moderation/ veya /stream/segment_*.ts gibi çağrılar görürseniz robots.txt kuralınızın hedefini doğru kurduğunuzu ya da yanlış kurduğunuzu yorumlayabilirsiniz.

Kapanış: Doğru endpoint seti ile SEO + performans dengesini kurun

Sohbet sitelerinde robots.txt ile endpoint engelleme, doğru yapıldığında crawl bütçesini HTML içeriklere yönlendirir, sunucu yükünü azaltır ve gerçek zaman/medya/moderasyon gibi “tarama için uygun olmayan” kaynaklarda gereksiz trafiği düşürür. WebSocket, media stream’leri ve moderasyon API’lerini tek tek sınıflandırarak; kural setinizi örnek URL kalıplarıyla kurun ve “doğrulama adımları”yla sonuçları test edin.

Son tavsiye: En iyi robots.txt, statik bir metin değil; log trendleri ve crawl raporlarıyla yaşayan bir konfigürasyondur. Yayın sonrası bot davranışı değiştiğinde (ör. yeni endpoint eklendiğinde), endpoint envanterinizi tekrar gözden geçirip kural setini rafine edin.