WebSocket Tabanlı Sohbetlerde Googlebot Erişimi: robots.txt + Özel Crawling (Bot Simülasyonu) Stratejisi

WebSocket tabanlı sohbetlerde Google bot’un erişimi, çoğu ekip için çoğu zaman “görünmeyen bir tünel” gibi çalışır: Sayfa render edilebilir olsa bile gerçek zamanlı akış (mesajlar/oturumlar) WebSocket üzerinden aktığı için botun klasik sayfa taraması beklenen sinyalleri yakalayamayabilir. Bu yüzden websocket tabanlı sohbetlerde Google bot’un erişimi: robots.txt + özel crawling stratejisi yaklaşımı, yalnızca robots.txt yazmayı değil; Googlebot’un hangi URL’leri hangi içerik türleriyle temsil ettiğini önceden planlamayı gerektirir.

Bu rehberin amacı net: Sohbet ürününüzün “indexlenebilir” tarafını doğru kurgulamak (oda arşivi, konu başlıkları, listeleme sayfaları, SSR içerikleri) ve WebSocket’in “gerçek zamanlı” tarafını ise kontrolü elinizde tutarak keşfe kapatmadan, bot simülasyonu ile doğrulanabilir hale getirmek. En sonunda elinizde; robots.txt + sitemap + URL eşleştirme + log/Google Search Console test planı ile birlikte adım adım uygulanabilir bir yol haritası kalacak.

Özet: WebSocket neden bot erişimini zorlaştırır? (render vs erişilebilir içerik)

WebSocket üzerinden akan mesajlar, tarayıcının beklediği şekilde “sayfa HTML’ine gömülü” bir içerik değildir. Googlebot’un tarama davranışında kritik kırılım şudur: Bot bir HTTP dokümanını fetch eder, kaynakları (CSS/JS, bağlantılar) değerlendirir ve mümkünse render etmeye çalışır. Ancak WebSocket bağlantısı kurup oturum içinde sürekli gelen mesajları gerçekten “okur” varsayımı çoğu senaryoda güvenilir değildir.

Dolayısıyla asıl mesele WebSocket’in kendisi değil; içerik görünürlüğünün iki katmanda dağılmasıdır. Birinci katman: HTML/SSR ya da prerender ile sunulan, botun keşfedebileceği “sayfa içeriği”. İkinci katman: WebSocket üzerinden akan, kullanıcı etkileşimiyle ortaya çıkan “canlı içerik”. SEO başarısı için botun birinci katmanda doğru sinyalleri alması, ikinci katmanın ise indexlemeyi kirletmeden ürün değerini taşıması gerekir.

Googlebot’un web erişimi: HTTP istekleri, sayfa kaynakları ve WebSocket’in rolü (kavramsal çerçeve)

Google bot ekosisteminde keşif çoğunlukla HTTP üzerinden ilerler: bir URL’yi fetch eder, yanıtın başlıklarını, yönlendirmeleri ve HTML gövdesini inceler; iç bağlantıları ve sitemap sinyallerini takip eder. “Web erişimi” dediğimiz şey bu yüzden genellikle HTTP dokümanının etrafında şekillenir.

WebSocket ise bir “protokol upgrade” akışıdır. Botun WebSocket oturumunu kurup kuramayacağı, kurduktan sonra mesajları satır satır yorumlayıp yorumlamayacağı; her durumda ve her sürümde aynı şekilde olmayabilir. Bu nedenle tek hamlede “her şeyi disallow et” yaklaşımı yerine, WebSocket’i botun temsil ettiği sayfa katmanlarıyla uyumlu olacak biçimde ayrıştırmak hedeflenir.

robots.txt ile erişimi planlama: izin/verme senaryoları (dosya bazlı yerine yol bazlı mantık)

robots.txt’i bir “yasaklar listesi” gibi görmek yerine, keşfi hızlandıran ve botun harcayacağı bütçeyi indexlenebilir hedeflere yönlendiren bir kontrol paneli gibi düşünmek gerekir. Sohbet sitelerinde kritik olan nokta şudur: WebSocket endpoint’i tek başına bir “SEO nesnesi” değildir. SEO değeri; oda sayfalarında, arşiv sayfalarında ve indekslenebilir içerik bölümlerinde, bir de bunların iç bağlantı hiyerarşisinde doğar.

Bu yüzden robots.txt kararını dosya bazında değil, yol bazlı mantıkla kurun: arşiv yollarını allow, oturum/gerçek zamanlı akış yollarını disallow edin; ayrıca parametre/sonsuz rotaları (ör. filters, pagination varyantları) kontrol altında tutun. Aşağıdaki örnek; indexlenebilir arşiv yollarını allow, gerçek zamanlı oturum yollarını disallow etme fikrini somutlaştırır.

Örnek robots.txt senaryosu
User-agent: *
Allow: /oda/
Allow: /arşiv/
Allow: /sayfa/
Disallow: /ws/
Disallow: /socket/
Disallow: /live/
Disallow: /rooms/*/events
Sitemap: https://example.com/sitemap-index.xml

Not: robots.txt ile disallow edilen bir yol, içerik zaten indexlenmemesi için tasarlanmış olmalıdır. Yani “WebSocket yolunu disallow ettim” tek başına yeterli bir çözüm değildir; asıl içerik kaynağı SSR/prerender tarafında var olmalıdır.

WebSocket’te içerik görünürlüğü tasarımı: iki katmanlı yaklaşım (indexlenebilir SSR/prerender + gerçek zamanlı WebSocket)

İki katmanlı tasarım, hem ürün hem SEO hem de bot davranışı açısından en sürdürülebilir yol. Birinci katman: indexlenebilir sayfa katmanı. Oda sayfası ya SSR ile HTML olarak gelir ya da prerender/derleme mantığıyla botun görebileceği metin/başlık/açıklama üretir. Örneğin “/oda/{slug}” gibi URL’lerde sayfa HTML’inde oda bilgisi, kısa özet ve arşiv mesajlarından bir bölüm yer alır.

İkinci katman: gerçek zamanlı WebSocket katmanı. “/ws/{roomId}” gibi bir yol yalnızca canlı mesajları taşır; indexlenmesi hedeflenen metinleri taşımaz ya da taşımaya çalışsa bile bot bütçesini tüketmeyecek şekilde kapsamlı kontrol uygulanır. Böylece bot “sayfa katmanını” indeksler, kullanıcılar “oturum katmanını” gerçek zamanlı olarak yaşar.

Özel crawling stratejisi: bot simülasyonu mantığı, rate-limit, oturum yönetimi, kabul edilebilirlik/etik çerçeve

Googlebot gibi davranmak için “gerçek botu taklit” etmeye çalışmak yerine, hedefiniz doğrulama olmalı: Hangi URL’ler gerçekten fetch ediliyor? SSR içerik oluşuyor mu? Linkler takip ediliyor mu? Oda/mesaj arşivleri taranabilir durumda mı? WebSocket tarafında en azından handshake ve mesaj şeması doğrulanabiliyor mu?

Buradaki en sağlıklı yöntem, özel crawler’ınızı bir test aracına dönüştürmek: sitemap’ten URL çekin, SSR içerik doğrulayın; ardından gerekiyorsa sınırlı ve kontrollü bir oturum simülasyonu yapın. Bu aşamada rate-limit şarttır; oturumları sonsuz şekilde açmayın, veri üretmeyin, spam gibi davranmayın. Ayrıca robots.txt ve sitemap sinyalleriyle uyumlu kalın; doğrulama için disallow edilmiş alanlarda “zorla” keşif yapmayı hedeflemeyin.

1. Sitemap’ten URL listesi çek (önce arşiv/oda sayfaları).
2. Her URL için HTTP fetch + render sinyali kontrolü yap (başlıklar, meta, içerik bölümü var mı?).
3. Log’larda crawler kullanıcı aracını ve hangi endpoint’lerin tetiklendiğini doğrula (handshake var mı?).
4. Gerekirse WebSocket simülasyonunu çok düşük hacimle ve yalnızca test odalarında yap (ör. en yeni 1-2 oda, kısa süre).

Crawl edilebilir sayfa eşleştirme: oda/mesaj arşivi URL’ileri ↔ sohbet oturumları

Stratejik bir ayrım yapmak gerekiyor: Sohbet ürününüzde “oturum” ile “indekslenebilir arşiv” aynı şey değil. SEO için botun takip edeceği URL’ler odalar ve arşiv sayfaları olmalı. Oturum ise kullanıcının (ya da test crawler’ının) WebSocket ile bağlandığı, canlı mesajların aktığı alan.

Bu eşleştirmeyi somutlaştırın: Oda sayfası hangi URL üzerinden açılıyor? Arşiv mesajlarını hangi parametrelerle sayfalıyorsunuz? “En yeni/en eski” sıralaması URL’e yansıyor mu? Parametre varyantları oluşturuyorsanız bunların crawl edilebilirlik seviyesini belirleyin.

Örnek URL mimarisi: WebSocket endpoint’ini sayfa katmanından ayırın. Aşağıdaki örnek, /oda/{slug} (SSR) ve /ws/{roomId} (WebSocket) ayrımını netleştirir (akış şeması mantığı):

Akış şeması örneği: Bot /oda/abc-slug URL’sini fetch eder → HTML içinde oda metni + arşiv mesaj özeti görünür → iç bağlantılarla sayfalama/etiket keşfi büyür → canlı güncellemeler kullanıcı tarafında /ws/123 üzerinden akmaya devam eder.

Örnek URL mimarisi: - /oda/{slug} → SSR/prerender içerik (bot için) - /ws/{roomId} → canlı akış (bot için hedef değil, test/doğrulama için sınırlı)

Sitemap ve keşif akışı: URL’leri hangi sırayla sunmalısınız? (odalar, sayfalama, etiketler)

Sitemap yalnızca “var olan URL’lerin listesi” değil; keşif önceliğini planlayan bir araç. Sohbet sitelerinde arşiv odaklı keşif genellikle daha güvenli ve sürdürülebilir. Bu yüzden sitemap’i oda listeleri ve arşiv sayfaları etrafında kurun; WebSocket endpoint’lerini veya sınırsız oturum varyantlarını eklemeyin.

Keşif sırası için pratik bir kural: yüksek sinyal taşıyan, içerik yoğun sayfaları önce sunun. Ardından paginasyon ve etiket varyantlarıyla kapsamı genişletin. Eğer çok fazla oda varsa sitemap index + segmentasyon kullanarak bot bütçesini koruyun.

Ek olarak, oda sayfasından mesaj arşivlerine “iç link” ile gidin. Botun takip edeceği yol sadece sitemap değildir; HTML içinde mantıklı anchor’lar ve sayfalama linkleri de keşfi hızlandırır.

Server log ile doğrulama: hangi alanlar/URL’ler bot tarafından geliyor, WebSocket handshake var mı yok mu?

SEO hipotezini somut bir veriye çevirmek için server log’lar en hızlı geri bildirim veren kaynak. Özellikle WebSocket tarafında “handshake var mı?” sorusu kritik: log’da Upgrade header’ı, handshake denemesi ya da ws endpoint erişimi görülüyor mu? Görünmüyorsa bu çoğu zaman normal; çünkü WebSocket’in sayfa keşfi için zorunlu olmadığını bir önceki katman tasarımınız zaten hedefliyor.

Log’larda ayrıca şu ayrımı yapın: botun fetch ettiği URL’ler arşiv/oda sayfaları mı, yoksa disallow edilmesi beklenen canlı oturum yolları mı? Eğer canlı yollar da çok çağrılıyorsa robots.txt veya URL yönlendirme/canonical mantığında bir sızıntı olabilir.

Örnek log satırı okuma: kullanıcı ajanı/URI/handshake belirtisi üzerinden çıkarım örnekleri

[2026-04-15 10:22:11] "GET /oda/istanbul-haritasi HTTP/1.1" ua="Googlebot/2.1" status=200 bytes=24567 upgrade=false
[2026-04-15 10:22:20] "GET /ws/123 HTTP/1.1" ua="Googlebot/2.1" status=403 upgrade=true error="Blocked by robots policy"

İlk satır botun oda sayfasını gerçekten fetch ettiğini gösterir. İkinci satırda upgrade=true görülmesi veya 403/uygulama red cevabı almanız; bu endpoint’in SEO hedefi olmadığını teyit eder. Log’ların asıl değeri, robotun “beklenen katmandan” ilerleyip ilerlemediğini doğrulamaktır.

Google Search Console ile test planı: URL inspection, fetch & render, crawl stats

Search Console; teoriyi hızlı bir doğrulamaya çevirir. URL inspection ile tekil oda URL’ini inceleyin: canonical doğru mu, indekslenebilir durumda mı, içerik tarafında botun gördüğü metin beklendiği gibi mi? Fetch & render sonuçları, SSR/prerender katmanınızın çalışıp çalışmadığını anlamanıza yardım eder.

Crawl stats bölümünde ise hangi sayfa gruplarının daha sık tarandığını görebilirsiniz. Çok sayıda 4xx/5xx hatası veya gereksiz parameter varyantları görüyorsanız; sitemap ve robots kararınız ya da yönlendirme mantığınız bot bütçesini boşa harcıyor olabilir.

Kontrol için “doğrulama adımları” mantığını uygulayın: önce robots/sitemap ile keşif, sonra fetch-render ile içerik, ardından log ile doğrulama. Böylece kök nedeni tek seferde bulma şansınız artar.

Hatalar ve teşhis akışı: 404/410, noindex, geç redirect, canonical, hash/URL varyasyonları

WebSocket tabanlı sohbetlerde en sık karşılaşılan durum; URL’nin bot tarafından “doğru fetch edilmesi” ile “indekslenebilir içerik üretmesi” arasındaki kopukluk. Örneğin bot /oda/{slug} URL’sini görüyor ama içerik boş dönüyor (client-only rendering), ya da noindex başlığı taşıdığı için indekslenmiyor olabilir.

Bir diğer yaygın sorun alanı geç redirect (önce 302 sonra 200), canonical etiket hataları veya hash/URL varyasyonları (ör. #tab=messages gibi). Hash değişiklikleri genellikle “farklı URL” gibi algılanmaz; ancak uygulama bazı metinleri URL fragment’a bağladıysa botun gördüğü içerik eksik kalabilir. 404/410 ise arşiv silindiyse normal olabilir; fakat “yanlışlıkla” silinen crawl edilebilir URL’ler bot bütçesini gereksiz yere tüketir.

Bu teşhis akışını uygulayın: - Önce status kodlarını ve redirect zincirini kontrol edin. - Sonra canonical ve meta robots (noindex) var mı bakın. - En son olarak SSR/prerender ile botun gördüğü içeriğin dolu olup olmadığına odaklanın.

Yaygın hatalar

En sık yapılan hata, robots.txt’de WebSocket endpoint’ini disallow etmekle her şeyin çözüleceğini sanmak. WebSocket disallow edilse bile eğer /oda/{slug} sayfası bot için içerik üretmiyorsa, indeksleme yine de gerçekleşmez. Diğer bir hata ise sitemap’e canlı/oturum odaklı veya sınırsız varyantlı URL’lerin eklenmesidir; bot bu alanlarda gezinirken arşiv sayfalarını kaçırabilir.

• Client-only render: Oda sayfası tamamen React/Vue ile üretiliyor, SSR yok; bot içeriği boş görüyor.
• Noindex sızıntısı: login wall veya kullanıcı durumuna göre noindex döndürülüyor ama arşiv/oda için temizlenmiyor.
• Canonical karmaşası: aynı oda için birden fazla URL varyantı canonical ile doğru şekilde tekilleştirilmiyor.
• Parametre patlaması: filtre/sıralama parametreleri sınırsız URL üretiyor; bot bu alanlarda takılıyor.

Uygulanabilir kontrol listesi (adım adım)

Aşağıdaki kontrol listesi, websocket tabanlı sohbetlerde Google bot’un erişimi: robots.txt + özel crawling stratejisi hedefini pratik bir QA sürecine dönüştürür. Her adımı “kanıt” ile doğrulayın; özellikle log ve Search Console çıktıları olmadan “hissettim oldu” yaklaşımı risklidir.

Kontrol Alanı	Ne Kontrol Edilmeli?	Beklenen Sonuç
robots.txt	/ws/ ve /socket/ gibi WebSocket yolları disallow mu?	Arşiv/oda yolları allow, gerçek zamanlı oturum yolları disallow
sitemap.xml	Oda arşiv URL’leri doğru sırayla mı listelenmiş?	WebSocket endpoint’leri yok; oda + paginasyon + etiket keşfi destekli
SSR/Prerender	/oda/{slug} botun fetch ettiği anda içerik üretiyor mu?	Başlıklar/meta ve arşiv özeti HTML içinde görünüyor
Server log	Googlebot hangi URL’leri görüyor? handshake var mı?	Fetch: oda/arşiv; WebSocket: ya yok ya da beklenen blok/403

1. URL mimarisini kilitleyin: /oda/{slug} (SSR) ile /ws/{roomId} (WebSocket) ayrımını dokümante edin ve kodda tekilleştirin.
2. robots.txt + sitemap’i eşleyin: robots.txt’de allow/disallow kararınız sitemap segmentasyonunuzla tutarlı mı kontrol edin.
3. Özel crawler doğrulaması yapın: sitemap’ten URL çek → fetch-render benzeri kontrol → log’da crawler izini doğrula.
4. Search Console ile teyit edin: URL inspection’da indekslenebilir içerik var mı? Crawl stats doğru sayfa gruplarını mı gösteriyor?
5. Hata akışını yönetin: 404/410, canonical, geç redirect ve noindex sızıntılarını düzeltin; yeniden test edin.

İç bağlantılarla derinleşme

Bu rehber, WebSocket’i SEO açısından “katmanlara ayrıştırma + bot simülasyonu ile doğrulama” mantığında ele aldı. Uygulama detaylarını tamamlamak için aşağıdaki konulara göz atabilirsiniz:

• Chat Sitelerinde Oda Bazlı Index Sitemap (Sitemap Index + Segmentasyon) Nasıl Kurulur? (Adım Adım)
• robots.txt ve sitemap.xml yapılandırma rehberindeki temel mantık
• server log ile Googlebot erişimini doğrulama

Sık Sorulan Sorular

Googlebot WebSocket üzerinden mesajları görebilir mi? Teknik olarak WebSocket, bir protokol upgrade akışı olduğu için her zaman ve her durumda Googlebot’un mesajları “canlı akış” olarak okuyacağı varsayımı güvenilir değildir. Bu yüzden SEO için mesajların en azından oda arşiv sayfalarında SSR/prerender ile erişilebilir olması, WebSocket tarafının ise canlı güncelleme işleviyle sınırlandırılması önerilir.

robots.txt’de WebSocket endpoint’ini disallow etmek SEO’yu etkiler mi? Eğer SEO hedefiniz oda/arşiv sayfalarıysa, WebSocket endpoint’ini disallow etmek genellikle olumsuz bir etki yaratmaz. Ancak hatalı senaryoda problem büyüyebilir: oda sayfası içerik üretmiyorsa ve tüm metinler WebSocket’ten geliyorsa disallow, indekslenebilirliği fiilen bozabilir.

WebSocket kullandığım için neden sayfalar indexlenmiyor? (en yaygın nedenler) En yaygın nedenler: client-only rendering, noindex sızıntısı, canonical karmaşası, geç redirect zinciri, sitemap’e yanlış URL varyantlarının eklenmesi ve URL fragment/hash tabanlı içerik üretimi. Önce SSR/prerender’ı, sonra robots/sitemap’i, en son da log ve Search Console ile doğrulayın.

SSR/prerender ile WebSocket’i birlikte nasıl tasarlamalıyım? Basit fikir şu: /oda/{slug} sayfası bot için içerik üretir (başlık, özet, arşiv bölümü). Kullanıcı oturumunda yeni mesajlar WebSocket ile gelir. Böylece hem indekslenebilirlik korunur hem de ürün gerçek zamanlı kalır.

Sitemap’e arşiv URL’leri mi, sohbet oturum URL’leri mi eklenmeli? Arşiv/oda URL’leri eklenmelidir. Oturum veya canlı akış URL’leri (ör. /ws/{roomId}) keşif için amaçlı değildir. Keşif önceliğini arşiv sayfalarına verdiğinizde bot bütçesi doğru yere harcanır.

Özel bot simülasyonu yaparken nelere dikkat etmeliyim (rate-limit, doğruluk, etik)? Rate-limit uygulayın, çok az sayıda test odasında kısa süreli simülasyon yapın, veri üretmeyin veya spam tetiklemeyin. Ayrıca doğrulama yaptığınız aksiyonların robots.txt ve ürün güvenlik kurallarıyla uyumlu olduğundan emin olun. “Denedim oldu” değil, “log ve Search Console ile kanıtladım” yaklaşımını koruyun.

Search Console’da fetch-render farkları nasıl yorumlanır? Fetch edilen HTML ile render edilen çıktılar arasında belirgin fark varsa büyük ihtimalle client-only render ya da koşullu içerik üretimi vardır. Bu fark; SSR/prerender katmanınızın bot için çalışmadığını veya bazı sayfalarda noindex/erişim kısıtlarının etkili olduğunu gösterebilir.