Chat Sitesi SEO: Oda ve Mesaj Sayfalarında Çok Dilli (hreflang) Slug Yönetimi ve Ortak İçeriği Ayrıştırma Modeli

Chat sitelerinde SEO’nun zor kısmı, “aynı veri setinin” birden fazla sayfa türünde (oda sayfası, mesaj akışı, sayfalama/filtre) tekrar etmesidir. Özellikle uluslararası dil kurgusunda chat sitesi için çok dilli (hreflang) oda ve mesaj sayfaları slug yönetimi: ortak içerik nasıl ayrıştırılır? sorusu, doğru URL tasarımı ve doğru sinyal (hreflang + canonical + indeksleme) olmadan hızla duplikasyon ve yanlış eşleştirme sorunlarına dönüşür.

Bu rehberde amaç; oda ve mesaj sayfalarını tek bir “ortak içerik kaynağı” gibi görmek yerine, sayfa türü ve dil varyantı üzerinden ayrıştıran bir model kurmaktır. Böylece hem hreflang eşleşmeleri doğru çalışır hem de kanonik/pagination sinyalleri tutarlı kalır.

Sorun Çerçevesi: Oda Sayfası, Mesaj Sayfası/Akışı ve “Ortak İçerik” Neden Oluşur?

Chat odalarında “oda kimliği” tek bir gerçekliği temsil eder: oda adı, açıklama, kurallar, moderasyon notları ve benzeri metaveriler. Ancak ürün tarafında bu gerçeklik çoğu zaman farklı ekranlarda, farklı sayfa türlerinde tekrar tekrar görünür. Oda sayfası odanın özetini anlatırken, mesaj akışı sayfası da oda kimliğini taşır (başlık, breadcrumb, oda açıklamasının kısa kısmı, üyelik durumu gibi).

Bu tekrar SEO açısından “ortak/tekrarlı içerik” hissini tetikler. Çünkü Google açısından oda açıklaması ile mesaj sayfasındaki oda açıklama blokları aynı metinle ve benzer meta verilerle gelirse, hangi sayfanın birincil olduğunu belirlemek daha zor hale gelir. Üstüne bir de çok dillilik eklendiğinde (tr/en), yanlış hreflang eşleşmeleri veya yanlış canonical seçimi dil varyantlarını da birbirine karıştırabilir.

Bir başka risk de mesaj sayfalarının dinamik yapısıdır: mesaj akışı bazen sonsuz scroll mantığıyla ya da cursor tabanlı akışla ilerler. UI doğru çalışsa bile tarayıcı açısından “sayfa üretimi” belirsiz kalırsa, indekslenen URL’ler beklenmedik varyantlara dönüşebilir. Bu yüzden hedef; oda sayfası ile mesaj sayfası arasındaki ayrımı URL düzeyinde netleştirmek ve indeks sinyallerini bir kural setiyle yönetmektir.

URL/Slug Mimarisi Gereksinimleri: Hangi Sayfalar İndekslenmeli, Hangileri Noindex Olmalı (Prensipler)

İlk prensip: Chat sitelerinde insanların aradığı şey genellikle oda metaverisi ve/veya belirli mesaj segmentleri değildir; çoğu kullanıcı sohbetin kendisini görmeye gelir. Buna rağmen SEO tarafında indekslenebilirliği sağlamak için seçici davranmanız gerekir. Hedef, arama motoruna “değerli, farklı ve doğrulanabilir” sayfalar sunmaktır.

Genel olarak oda sayfaları daha kararlı ve daha az değişken olduğu için indekslenmeye daha uygundur. Mesaj akışında ise tüm mesajların tamamını sınırsız sayfalar halinde indekslemek çoğu zaman crawl bütçesini hızla tüketir ve duplikasyonu büyütür. Bu nedenle indekslemeyi şu mantıkla sınırlamak daha sağlıklıdır: oda metaverisi = indeks, mesaj içeriklerinin tamamı = kontrollü indeks veya “sadece bazı sayfa tipleri” yaklaşımı.

Uygulanabilir prensip seti:

• Oda sayfası (ör. /room/{roomKey}-...): indekslenir; canonical dil varyantlarına göre doğru eşlenir.
• Mesaj akışı (ör. /room/{roomKey}/messages/...): ya sayfalama ile kontrollü indekslenir ya da içerik kalitesine göre kademeli noindex uygulanır.
• Çok kısa/yeniden oluşturulmuş oda: düşük içerik sinyali varsa noindex geçici kuralı (veya “conditional indexing”) uygulanabilir.
• Cursor/query tabanlı varyantlar: mümkünse URL segmentasyonuna çevrilir; çeviremiyorsanız query varyantları noindex edilir/kanonikleştirilir.

Oda Slug Şablonları: Kalıcı Oda Kimliği + Okunabilir Slug Ayrımı

Oda slug’unda iki şeye aynı anda ihtiyacınız var: arama motoru için kararlı bir kimlik ve kullanıcı için okunabilirlik. Bu yüzden “oda kimliği” için sabit bir anahtar kullanın (roomKey gibi). Yanına değişebilir ama açıklayıcı bir “slug metin” ekleyin (oda adı değişse bile kimlik sabit kalır).

Örnek oda URL şablonu:

/room/{roomKey}-{slug}

Burada roomKey kalıcıdır; slug ise title-friendly bir metin olabilir. Oda adı değiştiğinde slug metnini güncellemek zorunda değilsiniz; güncelliyorsanız bile yönlendirme (301) ve canonical stratejisiyle tutarlılığı korumalısınız. Bu ayrım SEO açısından kritik: mesaj sayfaları oda kimliğini referans alırken, kullanıcı görünen kısım değişse bile tarayıcı aynı varlığı yorumlamalıdır.

Çok dillilik eklemek için iki seçenek düşünün: dil prefix veya dil suffix. Prefix yaklaşımı genellikle en okunaklı ve hreflang üretimi açısından pratiktir.

Mesaj Sayfası/Akışı Slug Şablonları: Sayfa Parametreleri Yerine Segmentasyon veya Kontrollü İndeksleme

Mesaj akışında en sık görülen problem; “aynı içeriğin farklı URL’lerle görünmesi”dir. Eğer /messages?cursor=... gibi bir yaklaşım varsa, her tarama yeni bir URL varyantı üretir. Bu da tarayıcıya “sonsuz sayfa” hissi verir ve dizine giren sayfalar kontrolsüzleşebilir.

Bu nedenle mümkün olduğunda URL segmentasyonu kullanın. Örneğin sayfalama tipi bir model kurguluyorsanız:

/room/{roomKey}/messages/{page}

Alternatif olarak, belirli bir “tarih/part segmenti” ile indekslenebilir bloklar oluşturabilirsiniz. Tarih tabanlı segmentasyon tarayıcının ve kullanıcıların anlamasını kolaylaştırır; aynı zamanda ortak içerik karışıklığını da azaltır.

Kontrollü indeksleme için bir diğer pratik yaklaşım: Mesaj akışı URL’lerini tamamen indekslemek yerine, yalnızca “ilk sayfa” veya “ilk N sayfa” gibi kural bazlı indekslemektir. Çünkü oda sayfası zaten oda hakkında temel sinyali taşır; mesaj akışının indekslenmesi “arama motoruna değerli bir içerik kapısı” olarak sınırlandırılırsa crawl bütçesi daha dengeli yönetilir.

Çok Dilli (hreflang) Tasarım Modelleri: (a) Dil Prefix, (b) Alt Domain, (c) Aynı URL Ama Dil Varyantı

Hreflang tasarımında üç model pratikte en çok kullanılanlardır. Hangisini seçerseniz seçin, oda ve mesaj sayfası türlerini aynı dil şemasıyla tutarlı üretmeniz gerekir; aksi halde mesaj akışında hreflang’lar oda sayfasıyla çakışır ya da yanlış dil URL’sine işaret eder.

Model (a) Dil prefix: En yaygın ve yönetimi kolay olandır. Örnek:

/tr/room/{roomKey}-{slug}

/en/room/{roomKey}-{slug}

Model (b) Alt domain: Örn. en.example.com, tr.example.com. Burada hreflang genellikle daha sade görünür, ancak sistem mimarisinde domain bazlı sitemap ve doğrulama gerekir.

Model (c) Aynı URL ama içerik dili değişken: Dil seçimi cookie/header ile değişiyorsa (ve URL aynı kalıyorsa) tarayıcılar farklı dillere aynı URL üzerinden gidebilir. Bu yaklaşım hreflang ile “dil varyantını URL düzeyinde” ayırmadığı için genellikle daha risklidir. Chat sitelerinde ortak oda/mesaj sayfası tekrarları varken, bu model yanlış eşleşme olasılığını daha da artırabilir.

Ortak İçeriği Ayrıştırma Taktikleri: Dil Bazlı Varyant, Şablon Farkları ve İçerik Kanonik Sinyali

“Ortak içerik” dediğimiz şey çoğu zaman oda açıklamasının iki yerde de görünmesidir: oda sayfasında tam metin, mesaj akışında ise küçük bir özet veya sabit yan panel. SEO’da kritik nokta şu: Bu içerik aynı metinse bile, şablon farkları ve metaveri farklılaştırması ile sayfa türünü ayırt etmelisiniz.

Taktik 1: Dil bazlı varyantları yalnızca “görünen dil” olarak değil, metadata seviyesinde de üretin. Örneğin oda açıklaması metin olarak çevrilsin; ayrıca title ve description değerleri de dil bazında farklı olsun. Mesaj sayfasının başlığı “messages” odaklı olmalı (ör. “{Oda Adı} — Sohbet Mesajları” gibi).

Taktik 2: Şablonu sayfa türüne göre değiştirin. Oda sayfasında “kurallar/kurallar özeti, topluluk ilkeleri” gibi kalıcı metin blokları; mesaj akışında ise “son mesajlar, bağlamsal etiketler, sayfa türüne özel giriş” gibi dinamik ama indekslenebilir odaklar olmalıdır.

Taktik 3: Kanonik sinyalin kaynağını netleştirin. Genellikle oda sayfası “ana varlık” olarak canonical olabilir; mesaj akışı ise ya kendi canonical’ına sahip olur ya da sadece belirli segmentler indeksliyorsa oraya göre kanonik ilişki kurulur. Buradaki amaç, aynı içeriği iki sayfa türü arasında döndürmemektir.

Canonical + Hreflang Birlikte Nasıl Çalışır? (Pratik Doğrulama Mantığı)

Hreflang, “dil varyantları” arasında eşleştirme yapar; canonical ise “hangi URL’in birincil olduğu”na işaret eder. İkisi birlikte çalıştığında ideal senaryo şudur: Her dilde oda sayfası kendi canonical’ına sahip olmalı; mesaj sayfası ise ya kendi canonical’ını sağlamalı ya da dil varyantları içinde doğru kanonik ilişkiler kurmalıdır.

Pratik doğrulama mantığı: Bir tarayıcının gördüğü sayfa için (1) hreflang listesinde o dildeki karşılıklar var mı, (2) canonical etiketi hangi URL’i işaret ediyor, (3) bu işaret dil prefix/suffix/alt domain modelinize uygun mu, (4) mesaj akışı ile oda sayfası arasında tersine canonical oluşturuluyor mu?

Bu kontrolleri yapmadan “hreflang eklendi, sorun bitti” demek çoğu chat SEO projesinde yanıltıcı çıkarım olur. Çünkü ortak içerik ve çok URL varyantı olan sistemlerde canonical yanlışı, hreflang’ı etkisizleştirebilir.

Sayfa Türü Ayrımı: Oda Metaverisi (Title/Description) ve Mesaj Sayfası Metaverisi Nasıl Ayrılmalı?

Sayfa türü ayrımı yalnızca URL ile olmaz. Title/description gibi metadata alanlarında da “neden farklı bir sayfa türü?” sorusuna yanıt vermelisiniz. Oda metaverisi, oda kimliğinin “kalıcı” yönlerini vurgular: topluluk adı, kategori/etiketler, kurallar ve genel açıklama.

Mesaj sayfası metaverisi ise “zaman/segment” vurgusu yapmalıdır. Örneğin belirli sayfa/part içerik indekse giriyorsa, açıklamada “son mesajlar”, “{page} sayfası” gibi sinyallerin bulunması, sayfanın oda sayfasından farklı bir amaç taşıdığını gösterir.

Önemli nokta: Oda açıklamasının aynen mesaj sayfasına taşınması kaçınılmazsa, bunu aynen kopyalamak yerine dil bazlı farklılaştırın ve mesaj sayfasında ayrı bir “mesaj odaklı giriş” ekleyin. Böylece ortak içerik miktarı azalır ve canonical/hreflang ilişkisi daha anlamlı hale gelir.

İndeks Bütçesi ve Ölçek: Çok Sayıda Oda/Mesaj İçin Kural Seti (Noindex/Kontrol Listesi)

Chat ekosisteminde oda sayısı hızla artar, mesaj hacmi ise daha da hızlı büyür. Bu nedenle “her şeyi indeksle” yaklaşımı hem gereksiz hem de risklidir. İndeks bütçesi yalnızca crawl sıklığını değil; dizine giren varyantların sayısını, duplicate oranını ve kalite sinyallerini de etkiler.

Ölçek için önerilen kural seti:

• Oda sayfası: indekslenir. Oda “hazır” değilse (ör. yeni açıldı, kısa içerik var) kademeli noindex uygulanır.
• Mesaj akışı sayfası: yalnızca belirli segmentler indekslenir. Örn. /messages/1 ve /messages/2 gibi sınır.
• Query varyantları: cursor/page gibi parametreleri indexlemeyin; segmentasyon yoksa noindex + canonical ile kontrol edin.
• Ölçek doğrulama: haftalık log ve indeks raporlarıyla “hangi URL tipleri gerçekten dizine giriyor?” sorusunu ölçün.

İsterseniz bu konuda ekip içi kararlar alırken, UGC/dinamik içerik kaynaklı SEO riskleriyle birlikte düşünün. Oda/mesaj sayfalarının indekslenmesi; spam raporları, moderasyon süreçleri ve kullanıcı üretimi içerik kalitesiyle doğrudan bağlantılıdır.

Chat Sitesi İçin Server Log Analizi: Hangi Sayfalar Taranıyor? Crawl Bütçesi Nasıl Optimize Edilir? içeriği; hangi URL tiplerinin gerçekten tarandığını görmek isteyenler için iyi bir başlangıç noktasıdır.

Uygulama Adımları (Checklist): Rota/Slug Üretimi, Sitemap Stratejisi, Hreflang Üretimi, Log/Rapor Doğrulaması

Bu bölüm, ekiplerin “tasarım + sinyal + doğrulama” döngüsünü kurmasını amaçlar. Aşağıdaki adımlar, özellikle oda ve mesaj sayfalarında ortak içerik ayrıştırma modelini hayata geçirmede işinize yarar.

Adım adım doğrulama (kontrol listesi):

1. Rota/slug üretimi kuralını kilitleyin: Oda URL’i /{lang?}/room/{roomKey}-{slug} formatında; mesaj URL’i ise /{lang?}/room/{roomKey}/messages/{page} (veya kontrollü segment) formatında mı?
2. Hreflang matrisi üretin: Her URL tipi için (oda vs mesaj) dil varyantlarınızı ayrı ayrı eşleştirin. Aynı URL’in içerik dili cookie ile değişiyorsa, bu modeli yeniden gözden geçirin.
3. Canonical ilişkilerini belirleyin: Mesaj sayfası kendi canonical’ına sahip mi, oda sayfasına canonical gidiyor mu? “Tersine canonical” üretmeyin.
4. Sitemap’i sayfa türlerine bölün: Oda sitemap’i ile mesaj sitemap’i ayrı tutulabilir; dil varyantları ayrı listelere girsin.
5. Log ve indeks raporuyla ölçün: Search Console (ve log verisi) üzerinden indekslenen URL tipleri beklediğiniz gibi mi? Fazla varyant oluşuyor mu?

Ek olarak, eğer mesaj akışı sayfalama/aşamalı yükleme ile çalışıyorsa, tarayıcıların hangi sayfaları görebildiği kadar crawl edilebilir tasarım da kritik olur. Bu noktada şu rehberden yararlanabilirsiniz: Chat Sitesinde Paginasyon SEO: AJAX/Dinamik Yüklemede Crawl Edilebilir Sayfa Tasarımı Rehberi.

Örnek 1: Aynı Oda İçin Dil Prefix’li vs Dil Suffix’li URL Karşılaştırması ve Hreflang Çıktısı

Diyelim ki aynı oda için iki farklı URL dili kurgusu yaptınız: dil prefix ve dil suffix.

Prefix yaklaşımı:

/tr/room/abc123-istanbul-sohbeti

/en/room/abc123-istanbul-sohbeti

Suffix yaklaşımı (alternatif):

/room/abc123-istanbul-sohbeti-tr

/room/abc123-istanbul-sohbeti-en

Hreflang çıktısı hedef olarak her iki modelde de “doğru dil varyantına işaret” etmelidir. Prefix modeline örnek hreflang:

tr sayfası HTML hreflang örneği:

<link rel="alternate" hreflang="tr" href="https://example.com/tr/room/abc123-istanbul-sohbeti" />
<link rel="alternate" hreflang="en" href="https://example.com/en/room/abc123-istanbul-sohbeti" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/room/abc123-istanbul-sohbeti" />

Suffix modelinde href’ler URL formatınıza göre güncellenir. Önemli olan nokta: Oda sayfası ile mesaj sayfası hreflang listeleri birbirinin içine karışmamalıdır. Yani /tr/room/... için hreflang, sadece oda URL varyantlarına gitmeli; /tr/room/.../messages/... için ayrı bir hreflang seti olmalıdır.

Örnek 2: Mesaj Akışında Tarih/Part Segmentasyonu (/messages/{page} vs /messages?cursor=...) ve İndeksleme Kararı

Chat ürününüzde mesaj akışını iki farklı şekilde temsil edebilirsiniz. Biri segmentasyon temelli sayfalama, diğeri cursor/query temelli akış.

Segmentasyon temelli (önerilen kontrollü indeks):

/tr/room/abc123-istanbul-sohbeti/messages/1

/tr/room/abc123-istanbul-sohbeti/messages/2

Query/cursor temelli (genelde noindex veya güçlü kontrol):

/tr/room/abc123-istanbul-sohbeti/messages?cursor=QWERTY...

/tr/room/abc123-istanbul-sohbeti/messages?page=2

İndeksleme kararı:

• /messages/{page} segmentleri indeksleniyorsa, her page URL’i kendi canonical’ına sahip olmalı ve hreflang diliyle eşleşmelidir.
• ?cursor=... varyantları indekslenmiyorsa, noindex uygulanmalı ve canonical ile mümkün olduğunca “sayfalama temel sayfaya” veya “oda sayfasına” değil, aynı sayfa türünün temiz sürümüne işaret edilmelidir.

Bu ayrım ortak içerik sorununu da azaltır: query tabanlı her farklı cursor, aynı oda meta bloklarını taşıyabilir; segmentasyon ise “dizin için anlamlı bir sınır” koyar.

Örnek 3: “Ortak İçerik” (Oda Açıklaması Gibi) İçin Dil Bazlı Farklılaştırma (Metin + Metadata)

Oda açıklamanızın tr/en metin varyantları olduğunu varsayalım:

tr oda açıklaması: “İstanbul’da yeni insanlarla tanış, moderasyon kurallarına uyarak sohbet et.”

en oda açıklaması: “Meet new people in Istanbul—follow our moderation rules and keep the conversation respectful.”

Ortak içerik sorunu şuradan çıkar: Bu metin hem oda sayfasında hem mesaj akışında görünür. Çözüm: Mesaj sayfasındaki meta title/description oda açıklamasını birebir kopyalamak yerine, mesaj bağlamını ekleyin.

Oda sayfası title örneği (tr): “İstanbul Sohbeti — Kurallar ve Oda Bilgisi”

Mesaj sayfası title örneği (tr): “İstanbul Sohbeti — Son Mesajlar ve Sohbet Akışı”

Benzer şekilde description’da da yalnızca açıklamayı çevirmek değil, “son mesajlar” ve “segment/page” bilgisini ekleyerek sayfa türünü ayırın. En azından metadata düzeyinde ayrım yapıldığında, aynı metin payı olsa bile tarayıcı ve arama motoru sayfayı farklı bir amaç için yorumlar.

Bu sayede hreflang eşleşmeleri de netleşir: Oda URL’leri “oda meta seti” ile; mesaj URL’leri “mesaj meta seti” ile ilerler.

Örnek 4: Canonical Seçimi Örneği (Mesaj Sayfası Varyantı vs Oda Sayfası Canonical İlişkisi)

Varsayım: /tr/room/abc123-istanbul-sohbeti/messages/1 URL’i indeksleniyor. Mesaj akışı içinde aynı oda açıklama bloğunu gösteriyorsunuz.

Doğru yaklaşım (mesaj sayfası canonical’i): Mesaj sayfası, kendi dil varyantına canonical vermelidir.

Tr mesaj sayfasında canonical:

<link rel="canonical" href="https://example.com/tr/room/abc123-istanbul-sohbeti/messages/1" />

Hreflang (tr mesaj sayfasında): tr/en mesaj sayfaları karşılıklı eşleşir.

Yanlış yaklaşım örneği: Mesaj sayfasında canonical’ı oda sayfasına (ör. /tr/room/abc123-istanbul-sohbeti) yönlendirmek. Bu durumda mesaj sayfası “var ama en önemlisi değil” sinyali alır; dizine girse bile kısa sürede geriye düşebilir. Özellikle ortak içerik payı yüksekse, arama motoru eninde sonunda “oda ana varlık” lehine karar verir.

Dolayısıyla canonical kararı; “mesaj sayfasını indeksleyecek miyiz?” sorusuna bağlı olmalıdır. İndeksleyecekseniz canonical’i mesaj sayfasının kendisine daha tutarlı verin; indekslemeyecekseniz noindex ve controlled canonical stratejisi uygulayın.

Yaygın Hatalar / Kaçınılması Gerekenler

1) Oda ile mesaj hreflang’ını aynı eşleşme kümesinde karıştırmak: Örneğin /tr/room/... için hreflang listesinde yanlışlıkla /tr/room/.../messages/1 gibi mesaj URL’lerini de eklemek. Sonuç: arama motoru “dil varyantı”nı sayfa türü üzerinden yanlış yorumlayabilir.

2) Query/cursor URL’lerini sitemap’e karıştırmak: Sitemap’e cursor bazlı binlerce URL girerse, indekslenen varyantlar artar ve ortak içerik bloğu tekrar tekrar taranır. Bu da crawl bütçesini düşürür ve duplikasyon riskini büyütür.

3) Mesaj sayfasında canonical’ı oda sayfasına körlemesine bağlamak: Bu, mesaj sayfalarının indekslenebilirliğini fiilen baltalar. İndeksleme hedefiniz mesaj sayfalarıysa, canonical ilişkisi mesaj varyantları içinde kalmalıdır.

4) Dil varyantı yerine sadece içerik dilini çevirmek: Aynı URL’de (aynı path) içerik dili cookie/header ile değişiyorsa, hreflang’ın beklenen etkisi azalır. URL düzeyinde dil modeli net değilse, eşleşme hatalı davranabilir.

Nasıl Kontrol Edilir? Adım Adım Doğrulama Mantığı (Hreflang + Canonical + İndeks)

Uygulama sonrası doğrulama yapmadan “doğru tasarım” olduğunu varsaymak risklidir. Aşağıdaki adımlar, özellikle chat sitelerinde oda/mesaj ortak içerik ayrıştırma modelini doğrulamak için pratik bir kontrol listesi sağlar.

1. Tek tek test URL’leri seçin: Bir oda için tr/en oda sayfası ve mesaj sayfası (mesela page=1) olmak üzere en az 4 URL doğrulayın.
2. Her URL’de hreflang ve canonical etiketlerini karşılaştırın: Mesaj URL’leri kendi canonical’ına mı gidiyor? Oda URL’leri kendi canonical’ına mı gidiyor? hreflang içinde sayfa türü karışıyor mu?
3. Sitemap’te sayfa türü/dil bölümlenmesini kontrol edin: Oda sitemap’inde yalnızca oda URL’leri mi var? Mesaj sitemap’inde yalnızca mesaj URL’leri mi var? Query/cursor varyantları sızıyor mu?

Son olarak; Search Console “index coverage” ve istek loglarında hangi URL tiplerinin gerçekten dizine girdiğini izleyin. Beklentinizin dışına çıkan URL’ler, genellikle indeks/noindex veya canonical kuralındaki bir sapmaya işaret eder.

SSS

Oda ve mesaj sayfalarında hangilerini indekslemeliyim, hangilerini noindex yapmalıyım?
Genellikle oda sayfası indekslenir. Mesaj akışı ise tüm sayfaları indekslemek yerine kontrollü indeks (ör. mesaj page/part segmentleri) veya kaliteye göre kademeli noindex ile yönetilir. Cursor/query varyantları çoğunlukla noindex edilmelidir.

Hreflang’ta oda sayfası ile mesaj sayfası arasında ayrı mı eşleştirme yapmalıyım?
Evet. Oda URL’leri oda URL’leriyle; mesaj URL’leri mesaj URL’leriyle hreflang eşlenmelidir. Sayfa türlerini karıştırmak yanlış eşleşmeye yol açar.

Canonical’ı oda mı yoksa mesaj akışı mı belirlemeli?
Mesaj akışını indekslemeyi hedefliyorsanız canonical mesaj sayfası varyantına daha tutarlı olur. İndekslemeyecekseniz noindex/controlled canonical yaklaşımı kurun. Yani canonical kararı “hangi sayfayı indeksliyoruz?” hedefiyle birlikte verilmelidir.

Mesaj sayfalarında query parametre (cursor/page) kullanırsam hreflang ve sitemap nasıl etkilenir?
Query tabanlı URL’ler çok sayıda varyant üretir. Sitemap’e alınmamalı veya noindex edilmelidir. Hreflang içinde de bu varyantlar dolaştırılmamalı; mümkünse URL’leri segmentasyonla standardize etmelisiniz.

Sıfır içerik/az içerik (kısa oda, yeni mesaj) durumunda indeksleme nasıl yönetilir?
Kısa oda veya çok az mesaj içeren sayfalarda noindex geçici kuralı veya “kademeli indeks” uygulanabilir. Amaç, düşük kalite sinyaliyle indeks bütçesini tüketmemektir.

Sitemap’te dil varyantlarını ve sayfa türlerini nasıl bölmeliyim?
Oda ve mesajı ayrı sitemap’lerde tutmak (ve mümkünse dil varyantlarını da ayrı listelerde ayırmak) en az sürpriz veren yaklaşımdır. Böylece sitemap sinyali sayfa türü/dil mantığınızla uyumlu kalır.

URL değişikliği (slug rotasyonu) SEO’yu nasıl etkiler ve nasıl planlamalıyım?
Oda kimliği sabitken yalnızca okunabilir slug değişiyorsa rota sapması yönetilebilir. Yine de yeni slug’a 301 yönlendirme ve uygun canonical sinyaliyle tutarlılık sağlanmalıdır. Oda kimliğini sabitlemek, rotasyonun etkisini dramatik şekilde azaltır.

İç bağlantı stratejisi: Oda/mesaj slug kurgunuz oturduktan sonra, crawl ve paginasyon davranışını birlikte düşünün. Eğer proje ekibiniz crawl bütçesi ve indeks davranışını ölçmekte zorlanıyorsa şu kaynak faydalı olur: Chat Sitelerinde Crawl Budget Yönetimi: Oda Kapanınca 404/410 Yerine Doğru SEO Yaklaşımı.

Sayfa türü	Önerilen URL yapısı	Hreflang	Canonical	İndeksleme
Oda sayfası	/tr/room/{roomKey}-{slug}	tr/en oda URL’leriyle eşleş	Diliyle aynı oda URL’i	İndeks (hazır/kaliteli ise)
Mesaj akışı (kontrollü)	/tr/room/{roomKey}/messages/1	tr/en mesaj page URL’leriyle eşleş	Diliyle aynı mesaj page URL’i	İndeks (sınırlı segment)
Mesaj akışı (cursor/query)	/tr/room/{roomKey}/messages?cursor=...	Genellikle dahil etme	Kontrollü kanonikle (tercihen segmentli ana form)	Noindex (tercihen)