Chat’te Parent-Child (Thread) URL Yapısını SEO’da Kanonik Hale Getirme Rehberi: Yorum/Cevap Sayfaları

Chat/yorum tabanlı topluluklarda “aynı konuşmanın farklı görünümleri” ne yazık ki çok hızlı büyür: cevapların ayrı sayfalarla açılması, sıralama/sayfalama parametreleri, zaman damgaları, hatta kullanıcı eylemlerine göre değişen durumlar… İşin kötü tarafı şu: Bu çoğalma, doğru bir kanonik strateji tasarlanmadığında indeksleme dalgalanmasına ve URL kalabalığına dönüşür.

Chat topluluğunda kullanıcı yorumu/cevapları için parent-child URL yapısı SEO’da nasıl kanoniklenir? sorusunun cevabı “tek bir satır rel=canonical ekleyin” demek kadar basit değil. Hiyerarşiyi (root → thread → reply/child), hangi seviyelerin indekslenebilir olacağını ve varyant URL’lerin nasıl tekleştirileceğini baştan birlikte kurgulamak gerekir.

Sorun tanımı: yorum/cevap thread’lerinde URL çoğalması ve kanonik karmaşa neden olur?

Bir sohbet odasında ya da yorum thread’inde her mesaj/cevap ayrı bir “adres” gibi çalışabilir. Kullanıcı belirli bir cevabı açtığında yeni bir URL üretilir; kullanıcı aynı cevabı sıralamayı değiştirerek, sayfayı ilerleterek ya da farklı filtrelerle görüntüleyerek tekrar tekrar açtığında, aslında aynı içerik aynı konuşma içinde farklı parametrelerle yeniden URL olur.

Özellikle parent-child mantığı devreye girdiğinde (thread kök mesajı + cevapların child sayfası), Google botu bu varyantları keşfetmeye başlar. Bu keşif sürecinde kanonik sinyaliniz bir yandan doğru root’a işaret ederken, diğer yandan child sayfayı noindex yapmıyorsanız ya da paginated/sort varyantlarını eşleştirmiyorsanız “hangi sayfa asıl?” sorusunda kanonik döngüler ya da belirsizlik oluşur.

Terminoloji: parent-child, thread, reply, root post, leaf reply, indekslenebilirlik vs.

Bu yazıda birkaç temel terimi netleştirelim. Root post genellikle bir konuşmanın başlangıç mesajıdır; thread ise root ile ilişkili yorum/cevap zincirinin tamamını ifade eder.

Parent-child yapısı, bir mesajın bir üst mesajla (parent) bağını ve alt mesajların (child/leaf reply) bu zinciri tamamladığını anlatır. Leaf reply ise genellikle başka child içermeyen en uç cevapları temsil eder. İndekslenebilirlik ise “arama sonuçlarına girebilsin mi?” kararının kendisidir: root, bazı reply’ler, bazı state’ler (sort/pagination) ya da hiçbiri.

URL şeması tasarım seçenekleri (örnek dizilimler) ve ne zaman hangisi seçilir?

Chat/yorum platformlarında en sağlıklı yaklaşım genelde hiyerarşiyi URL içinde açık ve tutarlı taşımaktır. Aşağıdaki iki örnek dizilim, parent-child ilişkisinin hem insanlar hem botlar için anlaşılır olmasını sağlar.

• Thread bazlı root: Kullanıcının arama niyeti “konuşmanın özünü” arıyorsa root thread sayfasını ana hedef yaparsınız.
• Reply bazlı child: Kullanıcı “şu cevabı” arıyorsa child sayfası erişilebilir kalır; fakat çoğu durumda indekslenmesi gerekmez. Bu durumda canonical ile root’a tekleştirirsiniz.
• Derin cevap (leaf) erişimi: Çok sayıda nested reply varsa leaf URL’leri için indeksleme yerine “içerik erişimi + canonical tekilleştirme” tercih edilir.
• State URL’leri (sort/pagination/cursor): Parametreli varyantları asıl sayfaya canonical etmek, URL çoğalmasını kontrol altına alır.

Buradaki seçim kriteri açık: “Arama motoru için hangi sayfa gerçekten değer üretir?” sorusudur. Çoğu senaryoda root thread, en bütüncül içeriği sunduğu için kanonik aday olur; child reply sayfaları ise ancak gerçekten ayrı arama değeri taşıyorsa indekslenmelidir.

Canonical hiyerarşisi kural seti: kök mesaj mı, parent mi, tüm thread mi kanonik olacak?

Canonical kararını hiyerarşinin “tek kaynağı” olarak düşünün. En yaygın ve ölçeklenebilir kurgu: tüm child/leaf reply sayfalarının canonical’i ilgili root thread’e gider. Böylece Google’ın “benim asıl sayfam hangisi?” sorusu netleşir ve kanonik sinyal tek bir hedefe yönlendirilir.

Yine de bazı ürünlerde thread’in kendisi de varyantlaşabilir (sayfalı thread, cursor’lu yüklemeler, sort’a göre farklı sıralı listeler). İşte bu noktada kural setinizi netleştirin: ya “root thread + varsayılan sort/pagination” tek kanonik olur ya da “paginated seriler için canonical seri mantığı” kurulur. Bu yazıda iki yaklaşımı da örnekleriyle birlikte ele alacağız.

Indexing/Noindex stratejisi: hangi seviyeler indekslenmeli (root, bazı reply’ler, paginated state)?

İndekslenebilirlik kararını sadece canonical ile çözmeye çalışmayın. Çünkü Google canonical’ı dikkate alsa bile noindex/robots sinyallerini ayrıca değerlendirir ve bazı keşif süreçlerinde farklı davranabilir. Bu yüzden index/noindex stratejisini katmanlı düşünmek gerekir.

Pratikte önerilen kurgu genelde şöyle ilerler: root thread (varsayılan görünüm) index alır; child reply sayfaları çoğu durumda noindex olur; paginated/sort varyantları ise çoğu zaman ya noindex olur ya da canonical ile root’a teklenir. Yine de “tekil bir reply’nin aramada gerçekten karşılığı var mı?” sorusunu ürün analitiğiyle doğrulayın.

Varyant URL’ler: sıralama (sort), sayfa/pagination, kullanıcı eylemleri, zaman damgaları nasıl canonicalize edilir?

Chat’te varyantlar çoğunlukla parametrelerle ya da küçük path değişiklikleriyle gelir. Örneğin kullanıcı “top” sıralamasını seçtiğinde aynı thread içeriği farklı sırada döner; pagination/cursor ile de görünen aralık değişir. Zaman damgası (last seen, güncellenme, yeni mesaj vurgusu) ise aynı içeriği “farklı bir an” gibi gösterebilir.

Bu tür varyantlar URL çoğalmasını büyüttüğü için canonical mapping tablosu gibi net bir kurala bağlanmalıdır. Aşağıdaki örnek tablo, sık kullanılan sort/pagination kombinasyonlarında canonical eşleştirmeyi gösterir.

Varyant URL örneği	Ne değişiyor?	Canonical hedef	Önerilen ek sinyal
/c/{room}/t/{thread-id}/?sort=top	Mesajların sırası değişiyor	/c/{room}/t/{thread-id}/	child ise noindex; thread ise index + canonical root
/c/{room}/t/{thread-id}/?page=2	Sayfalama ile görünen aralık değişiyor	/c/{room}/t/{thread-id}/?page=1	genelde noindex (opsiyonel) veya paginated canonical

Cursor’lu sistemlerde ise “sayfanın devamı” çoğu zaman sonsuz akıştır; arama motoru için indekslenebilir net bir state olmayabilir. Bu durumda canonical’ı varsayılan “ilk yüklenen” state’e bağlamak ya da tüm cursor sayfalarını noindex yapmak daha sürdürülebilir olur.

Canonical yönergeleri: rel=canonical, x-robots-tag, HTTP/HTML sinyallerinin birlikte kullanımı

Canonical tekniği iki katmanda çalışır: (1) HTML içinde rel="canonical" ve (2) bazı durumlarda başlık seviyesinde x-robots-tag. Mantık şu: canonical, Google’a “asıl sayfa bu”yu söyler; noindex ise “bu sayfayı aramaya alma” mesajını verir. İkisini doğru seviyede birlikte kullanmak kanonik karmaşayı azaltır.

Aşağıdaki snippet, root ile child sayfalarının sinyallerinin nasıl ayrılabileceğine dair örnek bir modeldir.

<head>
  <link rel="canonical" href="https://example.com/c/room-1/t/1001/" />
  <meta name="robots" content="index,follow" />
</head>


<head>
  <link rel="canonical" href="https://example.com/c/room-1/t/1001/" />
  <meta name="robots" content="noindex,follow" />
</head>


x-robots-tag: noindex,follow

Not: HTTP başlığında robots/noindex verdiyseniz, HTML meta robots ile çelişmemesine dikkat edin. Tutarlı sinyal, “canonical var ama neden hâlâ indeksleniyor?” gibi vakaların sayısını düşürür.

İç linkleme mimarisi: root thread’e yönlendiren anchor’lar ve reply etiketleme

Canonical sadece meta etiket değildir; site içi link mimarisi de Google’ın asıl sayfayı anlamasına ciddi katkı sağlar. Örneğin bir kullanıcı “belirli bir cevabı” açtığında, o child URL’de kullanıcıya görünür bir “thread’e dön” bağlantısı ve içerik içinde güçlü bir “root mesaj referansı” konumlandırın.

İç linkleme yaklaşımı için şu prensipleri rehber alın: (a) root thread sayfasına giden linklerin anchor metni anlamlı olsun (“Bu konuşmanın tamamı” gibi), (b) child sayfadan root’a geri giden link her zaman mevcut olsun, (c) sayfalama ve sort varyantlarında “varsayılan view”a işaret eden canonical tutarlı kalsın.

Şema (schema.org) önerileri: Article/DiscussionForumPosting mantığı ve uygulanabilirlik notları

Schema.org, thread yapısını tekil bir “conversation” gibi düşünmenize yardımcı olabilir. Tam olarak tüm nested reply’leri birebir modellemek her zaman mümkün değildir; ancak en azından root thread’i DiscussionForumPosting mantığıyla ya da konuşma/başlık yaklaşımında Article üzerinden işaretleyin.

Öneri: root thread sayfasında, thread başlığı ve yazar/kullanıcı bilgileriyle DiscussionForumPosting veya BlogPosting benzeri bir yapı kurun; child sayfada ise mümkünse replyTo gibi ilişkileri daha zayıf/temkinli kurun. Noindex olan child sayfalar için şema yine kullanılabilir ama arama sonuçlarını belirlemek için root’un şeması genelde daha kritik rol oynar.

Uygulama adımları: geliştirme backlog’ı, test senaryoları, yayına alma checklist’i

Bu çalışma tek seferlik bir ayar değildir. URL üretim noktaları, template’ler, caching katmanı ve yönlendirme akışlarıyla birlikte ele alınmalıdır. Geliştirme backlog’ınıza “URL şema sözleşmesi”, “canonical/noindex kuralları”, “varyant parametre normalizasyonu” gibi başlıkları ekleyin.

Aşağıdaki gibi bir test planı kurun: (1) root thread’in index aldığı, (2) child reply’nin noindex + canonical root aldığı, (3) sort/pagination parametreli varyantların canonical eşlemesinin doğru çalıştığı, (4) beklenmedik yönlendirmelerde (örn. 301) sinyallerin bozulmadığı.

1. Ön test (staging): Seçilmiş 20–50 thread için tüm varyant URL’leri tarayın; HTML ve response header robots/canonical’ı doğrulayın.
2. Keşif simülasyonu: Log’larda botların child URL’lere gidip gitmediğini izleyin; gidiş varsa child sayfaların noindex sinyalinin gönderildiğini teyit edin.
3. Indexlenme kontrolü: Google bot simülasyonu sonrası (veya Search Console veri toplama sürecinde) “root index alıyor mu / child indeksleniyor mu” gözleyin.
4. Regression: Önbellek/CDN ile canonical header değişmiyor mu, varyant parametreleri canonical’i override ediyor mu test edin.

Örnek URL seti 1: /c/{room}/t/{thread-id}/ (root) ve /r/{reply-id}/ (child) — canonical kuralı

En net şemalardan biri şöyle kurulabilir. Root thread URL: /c/{room}/t/{thread-id}/. Child reply URL: /c/{room}/t/{thread-id}/r/{reply-id}/. Bu modelde canonical kuralı tutarlı olmalıdır: child sayfanın canonical’i her zaman root thread’e gider.

Örneğin:

Root: https://example.com/c/room-1/t/1001/

Child: https://example.com/c/room-1/t/1001/r/50001/ → canonical: https://example.com/c/room-1/t/1001/

Örnek URL seti 2: ?sort=top, ?page=2, ?cursor=... — canonical mapping tablosu

Thread içeriği aynı kalsa bile kullanıcı “top/new” sıralamasını değiştirdiğinde başka bir görünüm oluşur. Arama motoru için bu farklı görüntüler ayrı değer üretmediği sürece tek kanonik hedef belirleyin. Aksi halde yüzlerce parametre varyantı keşfedilip indekslemeye aday olabilir.

Örnek canonical mapping yaklaşımı:

Varyant	Örnek URL	Canonical dönüş
sort=top	/c/room-1/t/1001/?sort=top	/c/room-1/t/1001/
page/cursor varyantları	/c/room-1/t/1001/?page=2 veya ?cursor=abc	/c/room-1/t/1001/?page=1 (tercihen) veya noindex

Örnek URL seti 3: aynı reply farklı context’lerde açılırsa (farklı filtreler) canonical nasıl seçilir?

Gerçek hayatta aynı reply farklı filtreler altında (örn. kategori, etiket, kullanıcıya özel görünüm) yeniden açılabilir. Bu durumda “canonical’i nereye bağlayacağım?” sorusunun cevabı, içerik değil bağlam seçimi üzerinden verilir.

Genel kural: canonical’i reply’nin ait olduğu asıl root threade bağlayın. Filtre parametreleri canonical’e eklenmesin; çünkü filtre, içerik parçasını aynı konuşma içinde farklı bir kesitte gösterir ve arama değeri “root conversation”da toplanır.

Senaryo: child sayfası erişilebilir ama indekslenmeyecek (noindex) — canonical root’a nasıl gider?

Child URL’ler kullanıcı deneyimi için erişilebilir kalabilir: paylaşım linkleri, derin linkleme veya moderasyon akışında doğrulama gibi. Fakat SEO açısından child sayfanın “arama sonucu hedefi” olmasını istemezsiniz.

Bu senaryoda child sayfası: (1) kullanıcıya açık olur, (2) noindex alır, (3) canonical root thread’i gösterir. Böylece Google child sayfayı keşfetse bile indekslemeyi root’a taşır; aynı mesajın farklı URL’lerde yarattığı çoğalma azalır.

Yaygın hatalar

1) “Sadece canonical ekledim, sorun çözüldü” sanmak: Eğer child sayfalar noindex almazsa veya sort/pagination parametreleri canonical’e eşlenmezse bot yine varyantları indekslemeye çalışabilir. Canonical tek başına her varyantı garantili biçimde tekilleştirmez.

2) “Yanlış hiyerarşi hedefi” vermek: Child reply canonical’i bazen parent node’a değil de yanlış bir “yakın görünüm”e bağlanır. Örneğin child için canonical /t/{thread-id}/?sort=top gibi parametreli bir URL olursa, canonical hedefin kendisi de varyant olabilir ve döngüye zemin hazırlar.

3) Cache/CDN ile canonical’in görünmemesi: Edge cache, canonical’i veya robots başlığını farklı varyantlara göre değiştirir. Sonuç: HTML’de canonical doğru görünse bile response header’da noindex/kural çelişir ve bot farklı karar verir.

Nasıl kontrol edilir? Adım adım doğrulama (kontrol listesi)

Aşağıdaki kontrol listesi, kanonik kararlarınızın gerçekten uygulandığını doğrulamak içindir. “Etiket eklendi” varsayımıyla ilerlemeyin; hem HTML hem header hem de keşif davranışı birlikte doğrulanmalıdır.

1. URL örneklerini çoğaltın: Her thread için root, child, sort=top, page=2 (veya cursor) gibi en az 6 varyant üretin; otomasyonla hepsine istek atın.
2. HTML’i doğrulayın: Her varyantta rel=canonical hedefinin doğru root’a gittiğini ve child için robots sinyalinin noindex içerdiğini kontrol edin.
3. HTTP header’i doğrulayın: x-robots-tag kullanıyorsanız response header’da doğru değeri aldığınızı doğrulayın; HTML meta ile çakışma var mı bakın.
4. Google Search Console gözlemi: “Indexing” raporlarında child URL’lerinin indekse girip girmediğini ve canonical uyuşmazlığı uyarısı oluşup oluşmadığını inceleyin.
5. Server log/rawl crawl sinyali: Botların hangi URL’leri taradığını görün; canonical hedef doğru değilse tarama davranışı genelde “yanlış sayfalarda” yoğunlaşır.

Hangi durumlarda kanonik tek bir sayfaya zorlamak zordur ve alternatifler?

Her zaman “tek root sayfaya” zorlamak mümkün olmayabilir. Örneğin çok büyük thread’lerde sayfalama kaçınılmazdır; “page=2” gibi state’ler gerçekten farklı içerik bölümleri barındırıyor olabilir. Bu durumda tek bir canonical hedef yerine paginated seriler için kontrollü bir canonical kurgusu gerekebilir.

Alternatifleri şöyle düşünebilirsiniz: (1) paginated canonical: her sayfanın canonical’i kendi sayfasına değil ama serinin en uygun temsilcisine; (2) consolidation: bazı derin sayfaları otomatik noindex yapıp içeriği root’un içinde “lazy expanded” hale getirme; (3) içerik farkı kriteri: eğer page=2’deki mesajlar belirgin olarak arama değeri taşıyorsa “indexlenebilirlik” kararını yeniden ele almak.

SERP istikrarını etkileyen bağımsız dinamikler: snippet/özet güncellemeleri

Kanoniklik iyi olsa bile SERP snippet’i dalgalanıyorsa kullanıcı deneyimi ve tıklama etkilenebilir. Chat’te otomatik teaser/özet alanları güncellendikçe snippet değişebilir; bu da aynı URL için arama sonucu görünümünde oynama yaratır.

Bu nedenle thread/parent-child kanonikleşmesini yaparken özet/teaser üretimini de hesaba katın. İsterseniz şu rehberle snippet değişimini ve nasıl daha stabil tutulacağını birlikte düşünebilirsiniz: Chat Sohbetinde Otomatik Teaser (Özet) Güncellenince Google Snippet’i Neden Değişir, Nasıl Sabit Tutulur?

Dinamik alanlar ve noindex kombinasyonları: last seen/read receipt benzeri durumlar

Last seen / read receipt gibi zaman damgasına dayalı alanlar aynı mesajın sayfa gövdesini küçük değişikliklerle güncelleyebilir. Bu, canonical stratejiniz doğru olsa bile crawl farklı içerik varyantlarını tetikleyebilir. Bu yüzden bu tip alanlar için noindex/indekslenebilirlik sınırlarını net koymak gerekir.

Örnek olarak, Chat Kullanıcı Profili (Last Active/Last Seen) SEO Noindex Kararı: Last Seen Yerine Özet UI’ı Nasıl Tasarlamalı? yazısındaki mantık, thread reply sayfalarında zaman damgası etkisini azaltmak için de bir çerçeve sunar.

Modülasyon ve SEO ilişkisi: güncellemeler indekslemeyi bozmasın

Chat’te içerik sürekli değişebilir; moderasyon notları, spoiler açma, raporlama aksiyonları gibi etkileşimler sayfayı farklı içerik durumlarında sunabilir. Bu değişimlerin her biri canonical hedefi dolaylı olarak etkileyebilir.

Bu yüzden “canonical ile tekleştiriyorum” yaklaşımını, hangi içerik durumlarının indekslenebileceği ve hangi durumların UI değişimi olarak kalacağıyla birlikte ele alın. Bazı durumlarda yeni URL üretmek zorundaysanız, canonical kuralını bir “içerik durum sözleşmesi” olarak dokümante edin.

Sık Sorulan Sorular (SSS)

Child (cevap) sayfaları tamamen noindex mi olmalı, yoksa bazıları indekslenmeli mi? Çoğu senaryoda child reply’leri noindex + canonical root yaklaşımı en sürdürülebilirdir. Ancak bazı leaf reply’ler (ör. çok referanslı, “tek başına cevap değeri” olan teknik çözüm mesajları) ayrı indeks değeri üretiyorsa sınırlı sayıda indekslenebilir. Kararı Search Console’daki tıklama/izlenim ve içerik benzersizliği belirlemelidir.

Canonical parent mı root thread mi olmalı? Karar kriterleri neler? Ürün ölçeğinde en az sürtünme root thread’e canonical vermektir. Parent node’a canonical vermek, derin cevaplarda “yakın görünüm”e kayma ve varyant hedef çoğalması riskini artırır. Kriter: Arama motoru için en bütüncül ve kararlı temsil hangisi?

Pagination/cursor URL’lerinde canonical nasıl yönetilir? Cursor tabanlı “sonsuz liste” genellikle indekslenmemeli; canonical’i ilk yüklenen temsil state’ine bağlayın veya noindex verin. Sayfalı (page=1,2,3) sistemde page’lerin içerik farkı ciddi ise paginated canonical kurgusu veya indeksleme kararı yeniden değerlendirilmelidir.

Sort (top/new) ve filtre parametreleri canonical’i nasıl etkiler? Sort/filtre parametreleri genelde asıl içerik değerini değiştirmediği için canonical’i varsayılan view’e sabitleyin. Filtreli canonical’ı parametreli URL’ye bağlamak, canonical hedefin de varyant olmasına neden olur.

Aynı reply birden fazla thread bağlamında görünebiliyorsa canonical nasıl seçilir? Reply’nin ait olduğu “asıl root thread”e canonical atayın. Eğer sistem reply’yi gerçekten farklı kökler altında yeniden yayınlıyorsa, ürün tasarımında kalıcılık (tekil bir canonical kaynağı) gereklidir; aksi halde “aynı içerik farklı kökenler” problemi yaşarsınız.

Kullanıcı aksiyonları (mute/hide gibi) canonical’i değiştirir mi? Bu aksiyonlar yalnızca görünümü kişiselleştiriyorsa canonical’i değiştirmeyin; indekslenebilirliği ise genellikle noindex/kişiselleştirilmiş sayfa ayrımıyla yönetin. Aksiyon bazlı yeni URL üretiyorsanız canonical hedefi sabitleyin.

Canonical ile 301 yönlendirme ne zaman birlikte kullanılmalı? URL şemanızı değiştirirken veya bir endpoint’i kalıcı olarak kaldırırken (ör. eski /t/{id}?view=... → yeni /t/{id}/) 301 ile yönlendirme + yeni sayfaya canonical mantığı birlikte kullanılabilir. Ancak sadece sort/pagination gibi parametre varyantlarında genellikle 301 kullanmak doğru değildir; canonical/noindex daha uygundur.

Google Search Console’da canonical uyuşmazlığını nasıl tespit ederiz? Indexing/URL inceleme alanlarında “canonical seçimi” ile ilgili uyarıları ve “Google tarafından seçilen canonical farklı” benzeri mesajları kontrol edin. Ayrıca “Fetched as” ile canlı HTML canonical’ını doğrulayın; edge cache/renderer farkı varsa tespit edilir.

Yayına alma için indirme tarzı kontrol listesi (implementation template)

Bu yazıdaki kararları bir “backlog + QA” formatında takip etmek için aşağıdaki maddeleri worksheet gibi kullanın: root thread canonical hedef, child reply noindex, sort/pagination canonical mapping, cursor noindex kuralı ve cache tutarlılığı testi.

Aşağıdaki checklist’i doğrudan ekip akışınıza ekleyebilirsiniz: “URL sözleşmesi” dökümü, template canonical/noindex doğrulaması, test thread seti, log tabanlı crawl doğrulaması ve Search Console doğrulaması.

• Root URL: varsayılan sort/pagination ile indekslenir.
• Child URL: erişilebilir ama noindex; canonical her zaman root thread’e gider.
• Sort/Filter URL’leri: canonical’i parametresiz root temsil state’ine bağlar.
• Pagination/Cursor URL’leri: page=2+ ve cursor state genellikle noindex veya paginated canonical politikasına tabidir.
• Doğrulama: HTML + HTTP header (x-robots-tag) tutarlılığı test edilir.