Chat Sitelerinde Reply Thread (Cevap/Zincir) İndeksleme: Parent-Child URL Tasarımı, Canonical ve Crawl Kontrolleri

Chat sitelerinde “cevap/response” zincirinin (reply thread) indekslenip indekslenmeyeceği sorusu, yalnızca SEO kararını değil; crawl bütçesi, duplicate içerik riski ve kullanıcı niyeti (search intent) yönetimini birlikte ele almayı gerektirir. Bu rehber de tam olarak reply thread düzeyinde indeksleme mimarisini netleştirmek için hazırlandı.

Chat sitesinde “cevap/response” zinciri (reply thread) indekslenir mi? Burada kritik olan; parent-child URL tasarımı ile canonical sorusuna verilecek doğru yanıt. Çünkü thread’in ayrı URL’ler üretmesi tek başına yeterli bir sinyal değildir. Thread sayfalarının içerik kalitesi, aramanın karşılığı olup olmadığı ve platformun erişim/erişilebilirlik katmanlarıyla birlikte düşünülmelidir. Aşağıda senaryo bazlı bir karar ağacıyla, hangi sinyallerle nasıl standardize edeceğinizi adım adım göreceksiniz.

Konu kapsamı: Reply thread neden ayrı URL üretir, neden indeks riski doğar?

Chat uygulamalarında bir mesajı tek başına bir “sayfa” gibi düşünmek çoğu zaman yanıltır. Genellikle o mesaj, daha büyük bir bağlamın içindedir. Bir parent mesajın altındaki her response, ayrı bir bağlam etkisi yaratır. Bu yüzden ürün ekipleri, kullanıcı etkileşimini hızlandırmak ve anlamı korumak için thread görünümünü ayrı URL’lerle konumlandırmayı seçer.

Fakat ayrı URL üretmek, SEO açısından otomatik olarak “duplicate risk = düşük” demek değildir. Reply thread sayfaları çoğu zaman (i) ince/eksik içerik (çok kısa yanıtlar), (ii) aynı içeriğin farklı görünüm varyantları (thread view vs conversation view), (iii) parametreli varyasyonlar ve (iv) sürekli değişen içerik (yeni mesajlar) nedeniyle index israfı üretebilir.

Özellikle canonical/robots stratejisi net değilse Google’ın keşfettiği her thread URL’si için indeks sinyali oluşur. Sonuç olarak asıl hedef sayfalarınız (room archive, conversation özetleri, kaliteli landing’ler) daha zayıf sinyallerle rekabet etmek zorunda kalır.

Terminoloji: parent mesaj, child/response mesaj, thread sayfası, thread vs conversation

İndeksleme kararlarını doğru kurgulamak için terimlerin ürün tarafından kullanılan haliyle net olması gerekir. Genelde şu kavramlar kullanılır:

Parent mesaj: Bir mesajın üzerine “cevap/response” yazılan ana ileti. Child/response mesaj: Parent’a yanıt olarak eklenen ileti. Thread sayfası: Belirli bir parent ve onun altındaki cevap zincirini (reply thread) tek ekranda veya derlenmiş görünümde gösteren sayfa. Conversation view: Aynı konuşmanın daha geniş zaman aralığını veya oda içindeki akışını gösteren görünüm.

İndekslenme kararını belirleyen sinyaller: kalite, kullanıcı niyeti, erişim, moderasyon

Reply thread URL’lerini indekslemek/indekse izin vermek, “her thread URL = index” gibi basit bir ilkeye dayanmaz. Aşağıdaki sinyaller kararınızı doğrudan belirlemeli.

• Kalite/unique value: Thread sayfası, arama sorgusuna özgü bir değer sunuyor mu? (Örn. belirli bir hatanın çözümü, karar/oy verme sonucu, referanslı bir cevap)
• Kullanıcı amacı: Arayan kullanıcı “tüm sohbeti” değil, spesifik bir cevabı mı istiyor? Spesifik cevap varsa thread indeks mantıklı hale gelebilir.
• Erişim kısıtı: Login gerektiriyor mu? Rate limit/ban nedeniyle görünürlük değişiyor mu?
• Moderasyon durumu: Mesaj silinmiş, anonime edilmiş, içeriği kısıtlanmış thread’ler indeks için aday olmamalı.
• İçerik uzunluğu/aktiflik: Tek cümlelik “katılıyorum” gibi kısa cevaplar, düşük içerik sinyali üretip index israfını büyütebilir.
• Aktiflik/kalıcılık: Çok hızlı akan ve sürekli değişen thread’ler zamanla içerik kalitesini kaybetmeye veya farklı bağlamlara evrilmeye eğilimlidir.

Senaryo matrisi: 4 farklı indeksleme yolu

Aşağıdaki matriste thread URL’leri için dört ana yolu düşünün. Bu yolların amacı, “indekslemek mi, konsolide etmek mi, kısmi izin mi” sorusunu sistematik hale getirmek.

Senaryo	Ne tür URL’ler var?	Hedef	Önerilen sinyaller	Risk
(1) Son mesajlar/özet thread indeksi	Thread’te en güncel cevap + özet görünüm	Hızlı, kaliteli snippet üretmek	Thread view canonical self + indeks; eski/uzun varyantlara noindex	Yanlış snippet veya güncelliğini yitirme
(2) Tam thread indeksi	Parent + tüm child’lar tek sayfada	Arama niyeti karşılığı “tam cevap”	Kalite eşiği üstündekiler index; düşük kalite için noindex	İnce içerik & duplicate

Senaryo	Ne tür URL’ler var?	Hedef	Önerilen sinyaller	Risk
(3) Sadece parent/konuşma indeksi	Thread URL var ama derin indeks istenmiyor	Bağlamı tek canonical’da toplamak	Thread URL’lere canonical parent + noindex veya sadece robots/limit	Thread’ün arama fırsatını kaçırma
(4) Arama sonuç/terim bazlı indeks (index israfı riski)	Terim/filtre/etiket ile üretilen thread türevleri	Yalnız “yüksek niyet” sayfaları indexlemek	Çoğuna noindex + canonical normalize; threshold şart	Index israfı, crawl bütçesi tüketimi

Parent-child URL tasarımı seçenekleri: sabit slug + child ID, hiyerarşik vs düzleştirilmiş

Reply thread’in URL mimarisi, canonical kararlarınızı doğrudan etkiler. Burada iki ana tasarım düşünün: hiyerarşik URL ve düzleştirilmiş URL. Amaç; (i) benzersizliği korumak, (ii) varyantları azaltmak, (iii) canonical sinyalini tutarlı vermek.

Örnek 1: Sorgu parametresi ile child hedefleme (daha hızlı prototip, ancak varyant üretmeye yatkın)

/c/{roomSlug}/{conversationId}/?m={parentId}

Örnek 2: Child’ı URL yoluna almak (daha temiz, daha deterministik)

/c/{roomSlug}/{conversationId}/{parentId}/{childId}/

Hiyerarşik modelin avantajı, thread’in path içinde kendini daha iyi ifade etmesidir. Düzleştirilmiş (query ağırlıklı) model ise ürün ekibinin “mevcut sayfa üzerinde odak” yaklaşımına daha kolay uyar; ancak SEO tarafında aynı içeriğin farklı URL’lerle çoğalmasına yol açabilir.

Canonical stratejileri: tek hedef mi, canonical zinciri mi, child’a mı parent’a mı?

Canonical stratejisinde temel kural şudur: “Arama için hangisini en çok göstermek istiyorsunuz?” sorusuna tek bir cevap vermelisiniz. Reply thread modelinde bazen birden fazla sayfa türü devreye girer; thread view ile conversation view birbirini tamamlayabilir.

En sık görülen senaryo: child URL → parent canonical. Yani child sayfasını tek bir canonical ile standardize edersiniz. Örnek:

Child URL: /c/{roomSlug}/{conversationId}/{parentId}/{childId}/

Canonical: /c/{roomSlug}/{conversationId}/?m={parentId} (parent/derlenmiş thread hedef)

Thread view ile conversation view çakışıyorsa; thread view “tam cevap” gösteriyorsa canonical self yapılabilir. Conversation view yalnızca daha geniş akış sunuyorsa canonical parent/thread’a yönlendirilir.

Thread view -> canonical self örneği:

/c/{roomSlug}/{conversationId}/?m={parentId} sayfasında canonical: self

Özel erişim durumunda canonical davranışı ise kritik bir başlık. Login gerektiren cevaplar veya ban/limitli mesajlar görünen içeriğin görünümünü değiştirebilir. Bu durumda canonical sinyali ile sayfada görünen içerik arasında tutarsızlık riski büyür. Basit ilke: Kullanıcı için farklı içerik sunuyorsanız canonical’i, erişilebilir olan ve arama için anlamlı olan sürüme göre belirleyin. Aksi halde Google, canonical’a rağmen sayfada gördüğü içerğin farklı olduğunu fark edebilir.

Noindex/robots kombinasyonları: soft-hide vs hard-hide

Reply thread URL’lerini kısmen gizlemek için iki araç vardır: robots.txt ve meta robots / HTTP header (noindex). Bu iki yöntem aynı şey değildir. robots, taramayı kısıtlar; noindex ise taransa bile indekslemeyi reddeder.

Öneri olarak “kısa ve düşük kalite” thread’ler için noindex tercih edin. “Sonsuz varyant” üreten, crawl bütçesini tüketen türler için robots + crawl limit ile taramayı azaltmak daha doğru olur.

Soft-hide: Sayfa taranır ama indekslenmez (meta robots noindex). Hangi URL’ler? Kalite eşiği altındaki reply’ler.

Hard-hide: Taramayı büyük ölçekte durdur (robots.txt disallow). Hangi URL’ler? Çok sayıda parametreli veya geçici arayüz varyantları.

Noindex örneği (kalite eşiği altında kalan reply’ler):

• Thread’te sadece 1 kısa mesaj var ve parent ile bağlantı kurmuyor.
• İçerik moderasyon nedeniyle “anonim + kırpılmış” hale geliyor.
• Thread görünümü “yalnızca kullanıcıya özel” (login) bir içerik sunuyor.

Bu durumda thread URL’lerinde meta robots: noindex,follow (linklerin değer taşıdığı durumlarda) veya noindex,nofollow (linklerin değeri olmadığı durumlarda) yaklaşımı değerlendirilir. Hangisini seçeceğiniz, sayfanın link sinyali/örümcek dağılımı hedefleriyle doğrudan ilişkilidir.

Crawl bütçesi ve filtreler: pagination, infinite scroll, sayfa derinliği

Chat ekosisteminde asıl tehlike, “index edeceğiniz kadar crawl edilmesi” değil; çok daha geniş bir ağın keşfedilmesi ve crawl bütçesinin boşa harcanmasıdır. Reply thread URL’leri bu yüzden mutlaka crawl kontrolüne tabi tutulmalıdır.

Örneğin infinite scroll kullanılan odalarda thread sayfaları sonradan yüklenen içeriklerle tetiklenebilir. Bu durum bot’lar için de “ek keşif” anlamına gelir. En azından şu filtreleri uygulayın: pagination veya sayfa derinliği kontrolü, max depth, “yalnızca en güncel N thread” tarama penceresi ve crawl limit.

İpucu: Oda sidebar/crawl kaynaklı keşif artışları da thread indeksini dolaylı etkiler. Bu nedenle room sidebar ve reklam/featured bloklarının taranma davranışı ayrı gözden geçirilmelidir. (Bu konuda yaklaşımı benzer mantıkla ele almak için şu rehber faydalı olabilir: Chat Sitelerinde “Room Sidebar” Crawl’i: Featured/Ads Taraması Nasıl Kontrol Edilir ve Crawl Bütçesi Nasıl Korunur?)

Erişim/özel içerik etkisi: login, ban/limit, silinmiş/anonim içerik

Reply thread’in indekslenip indekslenmeyeceğini belirleyen en güçlü sinyallerden biri içerik erişilebilirliğidir. Kullanıcı login olmadan child message içeriğini göremiyorsa, arama botu sayfada “boş/eksik” içerik görecektir.

Bu durumda iki yaklaşım mümkündür: (i) thread sayfasını hiç indekslemeyin (noindex) veya (ii) erişilebilir bir “özet/teaser” sürümünüz varsa onu canonical yapın. Ayrıca ban/limit nedeniyle bazı cevaplar kısalıyor veya tamamen kaldırılıyorsa, thread içeriği zaman içinde değişir. Bu yüzden canonical ve noindex kararı “içerik standardı” ile aynı çizgide kalmalıdır.

Pratikte şu kurala uyun: “Canonical’e verdiğiniz hedef URL, arama botunun görebildiği içerik standardını temsil etmelidir.” Eğer canonical hedef URL login ister ve bot bunu alamıyorsa, canonical çakışması riski artar.

Moderasyon ve edit history ile etkileşim: thread canonical’ini edit sonrası nasıl sabitleyeceksiniz?

Chat’te silme/ban/edit yaygındır. Reply thread’de edit history veya düzenleme sonrası içerik değişikliği, canonical’in “sabit hedef” olmasını zorlaştırır. Ancak SEO açısından istikrar değerlidir.

Burada iki tasarım düşünün. Birincisi: Edit sonrası içerik tamamen değişmez; sadece küçük düzeltmeler olur ve canonical aynı thread view üzerinde kalır. İkincisi: Edit ile anlam değişir (örneğin teknik çözüm güncellenir, “yanlış bilgi” düzeltilir). Bu senaryoda canonical’i değiştirmek yerine aynı canonical hedefte “güncellenmiş” içeriği göstermek çoğu zaman daha tutarlı görünür.

Edit history ayrı bir URL olarak indekslenmesin; bu konuya dair daha geniş kapsamlı stratejiyi başka bir rehberde ele almak daha doğru olacaktır. Bu yazının odaklandığı kritik nokta şudur: Thread canonical hedefiniz edit sonrası içerik standardını temsil etmeli ve thread’in “duplicate varyantlar” üretmesine izin vermemelidir.

CTA

Duplicate örnekleri: İki net çakışma senaryosu

Reply thread indeksleme mimarisinde duplicate riskini somutlaştırmak için iki tip örneği ele alalım.

(a) Aynı reply’ın farklı görünüm parametreleriyle çoğalması:

Bir reply aynı parent’a bağlıdır; fakat thread view şu iki URL’den erişilebilir durumdadır:

/c/{roomSlug}/{conversationId}/?m={parentId}

/c/{roomSlug}/{conversationId}/?m={parentId}&view=compact

İçerik aynıysa canonical’i “tek bir sürüme” sabitleyin. Farklı view parametrelerini ya normalize edin (canonical/redirect) ya da noindex yapın.

(b) Thread view vs conversation view çakışması:

Thread view parent’a odaklanıp sadece cevap zincirini gösterir; conversation view ise daha geniş akışı gösterir. Ancak pratikte conversation view yeterince benzer içerik sunduğunda iki URL aynı sorgu için rekabete girebilir.

Bu durumda karar: Eğer “search intent” spesifik cevap zincirini istiyorsa thread view canonical self olabilir. Aksi halde conversation view canonical olabilir. Önemli olan, hangisinin arama için “primary” olduğunu doğru seçmek ve bunu tutarlı sürdürmektir.

Nasıl kontrol edilir / adım adım doğrulama: GSC + log + URL davranışı

İndeksleme mimarisini tasarladıktan sonra doğrulama yapmadan “doğru çalışıyor” varsayımıyla ilerlemeyin. Aşağıdaki doğrulama adımları ile sistemi sistematik şekilde kontrol edin:

1. GSC URL Inspect: Örnek 20 thread URL seçin (yüksek kalite + düşük kalite) ve “Indexing allowed” / “Crawled - currently not indexed” / “Indexed” durumlarını karşılaştırın. Canonical hedefinin doğru URL olup olmadığını inceleyin.
2. Log analizi: Sunucu loglarında bot kullanıcı ajanları için hangi path’lerin tarandığını listeleyin. Infinite scroll tetiklenen thread’ler geliyor mu, çok parametreli varyantlar keşfediliyor mu kontrol edin.
3. Canonical & noindex doğrulaması: Thread URL HTML’inde meta robots noindex var mı, canonical tag doğru hedefe mi gidiyor? Erişim kısıtlı sayfalarda canonical “boş içerik” hedefe mi veriliyor, birlikte kontrol edin.
4. İndeks dağılımı metrikleri: İçerik sınıflarına göre indeks oranını izleyin (örn. “yüksek kalite thread %X indeksli”). Düşük kalite URL’lerde indeks oranı yükseliyorsa kalite eşiği veya noindex kurgusu revize edilmelidir.

Bu kontrol planı, reply thread stratejisinin sadece SEO değil aynı zamanda platform performansı (crawl + tarama yükü) tarafını da dengelemenizi sağlar.

Yaygın hatalar: Reply thread indekslemeyi bozan anti-pattern’ler

Teknik SEO ekipleri genellikle canonical’i “duplicate çözümü” gibi görür; ancak reply thread dünyasında canonical tek başına yetmeyebilir. Aşağıdaki hatalar sık görülür ve çoğu zaman indeks israfını büyütür.

• Thread URL’lere her durumda indeks izni vermek: Kalite eşiği yoksa Google kısa/tekrarlı cevapları indeksleyip snippet kalitesini düşürür.
• Canonical zinciri üretmek: Child -> parent canonical, parent -> conversation canonical gibi birden fazla yönlendirme katmanı; tutarsız sinyal ve “en iyi aday” seçiminde belirsizlik yaratabilir.
• Özel erişimde canonical tutarsızlığı: Login gerektiren varyant canonical yapılınca bot’un gördüğü içerik ile canonical hedefin içerik standardı uyuşmaz.
• Parametre normalizasyonu yapılmaması: view=compact, sort=latest, highlight=true gibi parametreler aynı içeriğin çok URL ile keşfedilmesine neden olur.

Kontrol listesi (uygulanacak teknik doküman formatında)

Aşağıdaki listeyi “PRD/Tech design doc” içine doğrudan kopyalayabileceğiniz şekilde yazdım. Reply thread indeksleme mimarinizin her katmanı için karar ve uygulama alanlarını tanımlar.

• URL mimarisi: Thread view ve child URL varyantlarını tanımla; path/query tasarım kararlarını dokümante et.
• Canonical hedef standardı: Her thread sınıfı için primary URL’i belirle (thread view mi parent mı conversation mı?). Canonical davranışını erişim kısıtlı durumlarda da yaz.
• İndeksleme kural seti (threshold): Minimum içerik uzunluğu, moderasyon durumu, aktiflik ve “unique value” ölçütleri.
• Noindex stratejisi: Kalite eşiği altı reply’lerde meta robots noindex/noindex+follow tanımla; alternatifte erişilebilir teaser varsa canonical’i ona ver.
• Robots stratejisi: Sonsuz varyant üreten path’leri robots ile kıs; tarama bütçesi hedefleriyle eşleştir.
• Crawl filtreleri: max depth, pagination kuralları, infinite scroll’da bot davranışı (örn. yalnız ilk sayfa/son N thread).
• Edit/moderasyon etkisi: Edit sonrası canonical değişiyor mu? Tarihsel stabilite kuralı oluştur (çoğu zaman canonical’i sabitlemek tercih edilir).
• Test planı: GSC URL inspect senaryoları, log doğrulaması, indeks dağılım raporları.

Ek not: Eğer thread içinde kullanıcı etkileşimleri (örn. eylem butonları) DOM’un bir kısmında yükleniyorsa, indekslenmemesi gereken parçaları bot-safe tasarlamak da yanlış sinyal üretimini azaltır. Bu konuya benzer bir yaklaşımı görmek için şu yazı faydalı olabilir: 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.

FAQ

Reply thread URL’leri indekslenirse duplicate content riski nasıl yönetilir?
Thread view ile conversation view çakışmasını canonical ile tek bir primary hedefe indirgemek gerekir. Ek olarak view/sort/highlight gibi parametrelerin aynı içeriği üretip üretmediğini test edin; aynı içeriği farklı URL’de tutuyorsanız canonical veya noindex ile varyantları söndürün.

Canonical’i child URL’den parent URL’ye vermek SEO’da ne zaman doğru olur?
Child URL’ler yalnızca parent bağlamının bir parçasını gösteriyor ve “tekil arama değeri” parent tarafında toplanıyorsa (ör. parent’ın derlenmiş thread özeti) canonical’i parent’a vermek mantıklıdır. Ancak child sayfası arayan için tam cevap niteliğinde ise child’ı primary yapmak daha doğru olabilir.

Thread view ile conversation view aynı içeriği gösteriyorsa hangisi canonical olmalı?
Kullanıcı niyetine daha iyi hizmet eden ve ürün açısından daha kalıcı bir sürüm hangisiyse onu primary canonical yapın. Eğer iki sayfa gerçekte aynıysa, canonical self’i “tek URL”e sabitleyin; farklı URL’leri birlikte yaşatmayın.

Kullanıcı login olmadan göremediği cevaplar için canonical/noindex nasıl olmalı?
Login gerektiren içerik bot’un erişemeyeceği “boş veya kırpılmış” görünüm yaratıyorsa noindex kullanın ya da erişilebilir “teaser/özet” sürümü olan bir canonical hedefe yönlendirin. Canonical hedefin bot gördüğü içerik standardıyla uyumlu olması kritik.

Moderasyon (ban/sil/edit) sonrası thread canonical değişmeli mi?
Çoğu durumda canonical’i sık sık değiştirmek yerine aynı primary URL’de güncellenmiş içeriği göstermek daha tutarlı olur. Eğer içerik türü temelden değiştiyse (ör. thread artık tamamen farklı bir şeye dönüştü) o zaman primary seçimini yeniden gözden geçirin; değişimi de kontrollü yönetin.

Infinite scroll kullanılan chat’lerde thread sayfalarının crawl edilmesini nasıl sınırlandırırız?
Bot’a özel olarak yalnızca belirli derinlik/pencere sunun (ilk sayfa veya son N thread). robots meta ve HTTP seviyesinde crawl limit davranışı tanımlayın; sonsuz scroll’un arka planda sınırsız URL keşfine dönüşmesini engelleyin.

Sonraki adım: Veriyle karar verin

Reply thread indeksleme mimarisinin başarısı “varsayım” ile değil, GSC ve log analizindeki gözlemlere dayanır. Yüksek kalite thread’lerde indeks oranı yükselirken düşük kalite thread’lerde noindex’in çalıştığını doğrulayın.

Bu rehberin vaadi şuydu: Thread düzeyinde indeks gerekip gerekmediğini, parent-child URL tasarımı ve canonical standardizasyonu ile birlikte nasıl yöneteceğinizi senaryolar üzerinden netleştirmek. Şimdi sıradaki adım; kontrol listesine göre kendi ürününüzde thread view/conversation view farklarını ve erişim/kalite sinyallerini ölçerek sistemi “kilitlemek”.

İsterseniz mevcut URL şemalarınızı (thread view, child URL, parametreler) ve “erişilebilen/erişilemeyen” içerik durumlarını paylaşırsanız, size uygun bir canonical + noindex + crawl limit planını taslaklayabilirim.