Chat Mesajlarında “Çeviri Görüldü” (Translated Status) İndekslenmeli mi? Orijinal/Çeviri Varyantlarında Canonical ve Noindex Politikası

Chat/UGC platformlarında otomatik çeviri akışları büyüdükçe, “translated status/çeviri görüldü” gibi durum etiketlerinin SEO etkisi de daha görünür bir tasarım problemi haline geliyor. Çünkü aynı mesajın hem orijinal hem de çeviri varyantları bir anda ortaya çıkabiliyor; üstüne bir de çevrinin yüklenme zamanı (ilk render, sonra JS ile) indeks sinyallerini doğrudan etkiliyor.

Aradığınız merkez mesele şu: Chat mesajlarında “çeviri görüldü” etiketi indekslenmeli mi? Orijinal/çeviri varyantlarını nasıl canonicalize edeceksiniz? Bu yazıda, bu durumun indekslenip indekslenmeyeceğine karar verirken “tekil kaynak (canonical)” mantığını nasıl kuracağınızı; canonical/noindex/hreflang sinyallerini çelişkiye düşürmeden nasıl kurgulayacağınızı adım adım anlatacağım.

1) Sorunun tanımı: “çeviri görüldü/translated status” nedir?

“Çeviri görüldü” (translated status) genellikle bir UI/metadata işaretidir. Kullanıcı bir mesajı belirli bir dilde okuyunca sistem mesajı otomatik çevirir ve ekranda “çevrilmiş” bir temsil üretir. Bu temsil çoğu zaman iki şekilde ortaya çıkar: (1) ilk render’da hem orijinal hem çeviri birlikte döner ya da (2) orijinal döner, çeviri ise asenkron şekilde daha sonra yüklenir.

Bu etiketin iki varyant üretme olasılığı da vardır: Orijinal mesaj “dil=tr” gibi bir dil etiketine sahipken çeviri mesaj “dil=en” veya “translated=true” parametresiyle ayırt edilir. Böylece aynı bağlam için arama motoru gözünde farklı HTML/DOM çıktıları oluşur. Duplicate engine “aynı içeriği tekrar tekrar bulundurmayalım” diye önlem alabilir; fakat indeks/kanonik sinyaller çakışırsa yine de gereksiz karmaşa oluşur.

2) Duplicate/Thin content tuzağı: otomatik çeviri duplicate engellerken neden yine karmaşa olur?

Otomatik çeviri motoru çoğu zaman “duplicate üretilmesin” mantığıyla çalışır: aynı mesaj kimliği için bir kez çeviri üretir, aynı sonucu tekrar etmez. Ancak SEO açısından “aynı olmak” teknik olarak “aynı URL/aynı canonical sinyali/aynı indeks kararı” demek değildir.

Şu senaryolar özellikle sık görülür: Orijinal sayfada çeviri hazır değilken indekslenebilecek bir HTML basılır; sonra translated status devreye girer ve sayfa (aynı URL) farklı metinle yeniden render edilir. Googlebot bu değişimi farklı zamanlarda farklı şekillerde görebilir. Üstelik birçok platform cache/CDN kullanırken ilk varyantı saklayıp “çeviri görüldü” halini crawler’lar için farklılaştırabiliyor.

3) Senaryolar matrisi: hangi durumlar iki varyant üretir?

İndeks ve canonical kararını netleştirmek için önce “ne zaman iki varyant oluşuyor?” sorusunu sistematik ele almak gerekir. Aşağıdaki matris, translated status’ın kaynak sayfalarla nasıl ayrıştığını anlamaya yardımcı olur.

• (a) Aynı URL içinde durum değişimi: İlk render orijinaldir; daha sonra “translated=true” devreye girip aynı URL’nin içeriği değişir.
• (b) Ayrı URL varyantı: Orijinal ve çeviri farklı route’lar/paths ile sunulur (ör. /msg/123-orijinal vs /msg/123-translation).
• (c) Parametreli varyant: Aynı path korunur ama ?lang=en, ?translated=true gibi parametrelerle içerik değişir.
• (d) Render/JS ile koşullu çeviri: Server-side ilk HTML’de çeviri yoktur; JS çalışınca çeviri yüklenir (veya SSR fallback farklı olabilir).

4) İndeks kararı rehberi: “çeviri görüldü” sayfası ne zaman indekslenmeli, ne zaman noindex olmalı?

Genel ilke şu olmalı: translated status tek başına “değerli ve bağımsız bir arama hedefi” yaratıyorsa indekslenebilir; bağımsız hedef yaratmıyorsa noindex düşünülmelidir. Chat mesajları çoğu zaman ephemeral (kısa ömürlü) ya da kullanıcıya özel bağlam taşıdığı için, indekslenmesi gereken birincil hedef çoğu durumda “orijinal mesaj kimliği” olur.

Pratik bir karar kuralı tasarlayın:

İndeksle: (1) Çeviri gerçekten arama hedefi üretir (ör. belirli locale’de kalıcı ve erişilebilir bir içerik), (2) sayfa kullanıcıya özel değildir, (3) içeriğin kalitesi ve bağlamı korunur, (4) canonical tek bir kaynağa işaret eder.

Noindex: (1) Çeviri varyantı “salt görüntü” niteliğindeyse (orijinalin aynı bağlam içinde yalnızca görünüm değişikliği), (2) aynı mesaj için yüzlerce locale üretiliyorsa, (3) “ince içerik/thin” riski büyüyorsa, (4) JS ile geç yüklenen içerik yüzünden crawler tutarsız çıktılar görüyorsa.

5) Canonical politikası: orijinal mi canonical, çeviri mi? Dil-etiketi ve locale ile uyum

Canonical seçimi, arama motorunun hangi sayfayı tekil kaynak kabul edeceğini belirler. Chat mesajlarında iki ana yaklaşım öne çıkar:

Yaklaşım A (çoğu chat senaryosunda önerilir): Canonical her zaman orijinal mesaj olur; çeviri varyantları canonical’i orijinale taşır. Böylece indeks tekil kalır, crawl bütçesi korunur ve translated status yalnızca görüntü katmanı olarak kalır.

Yaklaşım B (çeviri birincil ise): Eğer sistem mesajı “locale’e göre bağımsız bir kopya” gibi yönetiyorsa (ör. farklı dilde ayrı kalıcı adresler, ayrı meta içerik, izin kontrolü farklı), canonical çeviri sayfasına taşınabilir. Ancak bu yaklaşımda hreflang stratejisinin çok sağlam kurulması gerekir.

Burada en kritik nokta şu: Aynı mesaj kimliği için canonical sinyali iki yönde de (orijinal → çeviri, çeviri → orijinal) birbirine referans veriyorsa çelişki oluşur. Tercih ettiğiniz “tekil kaynak” rolünü netleştirin: ya orijinal her zaman canonical, ya da locale bazlı çeviri seti canonical.

6) Hreflang/alternates ile canonical kullanımının doğru kurgusu (çelişki olmadan)

Canonical ile hreflang birlikte kullanılabilir; ancak rolleri farklıdır. Canonical “tek sayfa” tercihi yapar; hreflang ise aynı içeriğin dil/ülke varyantları arasında eşleşme bildirir. translated status için doğru kurguda genellikle şu dağıtım görülür:

Orijinal canonical (yaklaşım A): Orijinal sayfada canonical self-referential olur. Çeviri sayfalarında canonical orijinale gider; hreflang ise orijinalin dil/locale eşleşmelerini diğer varyantlara bağlar.

Çeviri seti canonical (yaklaşım B): Her locale çeviri sayfası self-canonical olur; orijinal sayfa da “o locale” mi yoksa “default” mı kurguladığınıza göre doğru canonical’e işaret eder. Bu noktada yapılan en büyük hata, hreflang eşlemesini canonical ile çakıştırmaktır.

7) Noindex + HTTP/HTML sinyali ve cache/render kontrol checklist’i

Noindex kararını uygularken yalnızca meta robots ile yetinmeyin. Platformunuz SSR mi, SSR+CSR mi, yoksa tamamen CSR mi? CDN/edge cache neyi saklıyor? Cloudflare benzeri sistemler varied URL’leri doğru vary etmiyorsa yanlış kopyayı farklı crawler’lara servis edebilirsiniz.

Aşağıdaki kontrol listesi, translated status varyantlarında noindex/canonical tutarlılığını yakalamak için pratik bir çerçeve sağlar:

1. HTTP header: Noindex kararının uygulandığı endpoint’te X-Robots-Tag: noindex veya eşdeğer header var mı? (Meta robots ile birlikte mi, tek başına mı kullanıyorsunuz?)
2. HTML robots: Noindex kararına sahip sayfada <meta name="robots" content="noindex,nofollow"> doğru şekilde dönüyor mu?
3. Canonical tutarlılığı: Noindex sayfada canonical hangi URL’ye gidiyor? Canonical ile noindex çelişiyor mu?
4. Cache varyantı: ?lang veya translated=true parametresi cache vary etmeyi etkiliyor mu? (Vary: Accept-Language / Cookie / custom vary)
5. Render zamanı: JS ile çeviri ekleniyorsa noindex/canonical kararının anı, render öncesine mi render sonrasına mı bağlı?

8) Durum değişimi: translated status güncellenince canonical/noindex nasıl güncellenir?

Örneğin 1’de göreceğiniz gibi, translated status aynı URL’de “sonradan” geliyorsa en büyük risk şu olur: crawler ilk kez orijinal metni görüp canonical/noindex kararını başka bir şekilde kaydeder; sonraki crawl’de çeviri metni görür ve tekrar eden/çelişkili sinyaller oluşur.

Politikanız şu iki seçenekten biri olmalı:

Seçenek 1 (aynı URL): Aynı URL’de içerik değişiyorsa canonical genellikle değişmemelidir. Yani URL “kimlik” olarak sabit; sadece görünüm katmanı (orijinal + çeviri) güncelleniyorsa canonical aynı kalır, noindex kararı da aynı davranışı sürdürür.

Seçenek 2 (yeni URL): Çeviri sonrasında farklı “sayfa kimliği” oluşuyorsa (ör. gerçekten farklı endpoint), ayrı URL route tasarlayın ve canonical/noindex’i ayrı şekilde uygulayın. Bu yaklaşım, crawler’ların “farklı sayfa” gördüğünü daha net hale getirir.

9) Bot-safe yaklaşım: çevrinin hangi DOM bileşenlerinde üretildiği indeks sinyalini nasıl etkiler?

translated status için bot-safe yaklaşım, “indeks sinyali ile kullanıcı deneyimi” arasındaki ayrımı net tutmaktır. JS ile geç yüklenen çeviri, botlar tarafından her zaman aynı şekilde işlenmeyebilir. Özellikle CSS/ARIA ile saklanan içerikler veya yalnızca kullanıcı etkileşimi sonrası DOM’a basılan alanlar, Google’ın keşif ve render sırasında farklı metin sinyali görmesine neden olur.

Bu yüzden bir standardizasyon önerisi: Çeviri içeriklerinin DOM’da nasıl bulunduğunu belirleyin. Örneğin:

(1) Eğer çeviri indekslenmeyecekse, DOM’da her zaman görünse bile noindex sinyali sağlam olmalı; canonical orijinale gitmeli. (2) Eğer çeviri indekslenmeyecek ve aynı zamanda thin risk taşıyorsa, çeviri metnini ilk HTML’de çok erken dökmeyip kontrollü şekilde yükleyin; ancak bu kararın render tutarsızlığı yaratmadığını doğrulayın.

(3) Eğer çeviri indekslenecekse, SSR/ön-render ile bot’un ilk bakışta doğru metni görmesini sağlayın ve hreflang + canonical uyumunu garanti edin.

10) Örnekler: orijinal/çeviri varyantlarını nasıl ayırırsınız?

Örnek 1: Aynı URL’de “translated=true” durumuna geçiş (first render orijinal, sonra çeviri). Canonical nasıl verilmeli?

Diyelim ki ilk yükleme şöyle döner:

/chat/room/abc/msg123 (first render): “Hello” (orijinal) görünür.

Süreç sonra “translated=true” durumuna geçer ve aynı URL’de “Hello” yerine “Merhaba” görünür (veya ekranda “Merhaba” eklenir).

Öneri: Canonical’i hiç değiştirmeyin. Eğer yaklaşım A’yı benimsiyorsanız:

Orijinal sayfada canonical: <link rel="canonical" href="/chat/room/abc/msg123">

translated status göründüğünde de aynı kalmalı; çeviri varyantı “ayrı URL” gibi davranmadığı için noindex’i de URL bazında sabitleyin. Eğer translated durumu noindex olmalıysa, aynı URL’de her iki durumda da noindex uygulamak gerekebilir (çünkü bot iki farklı anda farklı içeriği görecektir).

Örnek 2: Orijinal message için /chat/..../msg123 ve çeviri için /chat/..../msg123?lang=en. Canonical ve hreflang nasıl set edilmeli?

Bu senaryoda URL varyantı parametre ile ayrışıyor:

/chat/room/abc/msg123 (orijinal; varsayılan dil)

/chat/room/abc/msg123?lang=en (çeviri)

Yaklaşım A (orijinal canonical):

Orijinal sayfada canonical self;

Çeviri sayfasında canonical, orijinale gider: <link rel="canonical" href="/chat/room/abc/msg123">

hreflang tarafında ise şu eşleşme kurulur:

Orijinal sayfada hreflang="en" ile çeviri URL’sini; ayrıca kendi dilini de doğru şekilde bildirirsiniz. Bu sayede Google, translated status URL’sini “farklı dil sürümü” olarak anlayabilir; ama canonical orijinale taşıdığı için tekil kaynak kontrolünüz sizde olur.

Örnek 3: Ayrı sayfa/route: /msg/123-orijinal ve /msg/123-translation. Hangi sayfa kanonik seçilir?

Ayrı route’lar daha net sinyal verir:

/msg/123-orijinal

/msg/123-translation

Karar: Arama hedefini nerede kurduğunuza göre canonical’i seçin. Eğer mesajın asıl kimliği orijinal ise /msg/123-orijinal canonical olur; /msg/123-translation noindex ya da index ama canonical ile orijinale bağlanır (policy’nize göre).

Eğer çeviri, kullanıcıların aradığı dilde daha değerliyse ve “locale’e göre kalıcı sayfa” olarak yönetiliyorsa canonical’i çeviri route’una da alabilirsiniz. Fakat bu durumda orijinal route’unun da hreflang canonical uyumu sağlamalı ve “karşılıklı çelişki” üretmemelidir.

Örnek 4: JS ile çeviri sonradan yükleniyor. Render sonrası noindex/canonical tutarlılığı nasıl sağlanır?

JS ile çeviri geç geliyorsa crawler’ın göreceği HTML ile kullanıcı ekranındaki HTML aynı olmayabilir. Eğer noindex/canonical tutarlılığı istiyorsanız:

(1) Noindex kararını server tarafında (SSR ya da edge) uygulayın; meta/header render’a bağlı kalmasın.

(2) Canonical kararını da server tarafında sabitleyin; translated status DOM’a sonradan ekleniyor olsa bile canonical bağlantısı değişmesin.

(3) Render sonrası çeviri metni ekleniyorsa bile canonical/noindex uyumu “bot’un hangi aşamada yakaladığına” bağlı olmamalı. Bu, crawl tekrarlarında tutarsız indekslemeyi azaltır.

11) Yaygın hatalar: translated status ile canonical/noindex’i karıştırmak

En sık yapılan hata, “duplicate engellendi” varsayımıyla canonical/noindex kurallarının gevşetilmesidir. Duplicate engeli, aynı mesajdan farklı varyantların üretilmesini azaltabilir; ancak arama motorunun keşfettiği ilk temsil ile son temsilin sinyalleri çelişirse canonical karmaşası yine devam eder.

Diğer yaygın hata ise, çeviri sayfasında canonical’i orijinale taşıyıp hreflang’ı ters yönde veya eksik kurmaktır. Bu durumda Google, hreflang ile canonical’in anlattığı tekil kaynak arasında “anlamsal tutarsızlık” görebilir. Ayrıca noindex kararını sadece meta robots ile yapıp, cache/CDN veya client-only render yüzünden bazı botlarda meta etiketin hiç görünmemesi de ciddi bir tuzaktır.

12) Nasıl kontrol edilir? Adım adım doğrulama ve log/URL inspection planı

Bu konuyu kontrolsüz ilerletmek, özellikle 100+ locale gibi ölçeklerde maliyetli bir indeks kirliliği yaratır. Aşağıdaki “adım adım doğrulama” planı hem canonical/noindex hem de translated status davranışını sahada ölçmenizi sağlar.

Adım 1: URL Inspection ile senaryoyu iki aşamada test edin. Aynı URL’de orijinalden çeviriye geçiş oluyorsa, “ilk durum” ve “son durum” için Inspection alıp canonical/noindex/hreflang alanlarını karşılaştırın.

Adım 2: Crawl loglarını ve kullanıcı ajanı farklarını inceleyin. Googlebot, diğer crawler’lar ve gerçek tarayıcılar için aynı URL’de DOM üretimi farklı mı? Edge cache translated status parametresini doğru vary ediyor mu?

Adım 3: site: ve index coverage sinyallerini doğrulayın. site: aramaları tek başına yeterli değildir; ama “hangi varyantların indexlendiğini” hızlı görmenize yardım eder. Ardından Indexing/coverage raporlarında hangi URL kümelerinin arttığını izleyin.

Adım 4: HTTP + HTML sinyallerini doğrulayın. Noindex için hem HTTP header hem meta robots basılıyor mu? Canonical header ile link tag çelişiyor mu? “Çeviri görüldü” durumunda canonical farklılaşıyor mu?

Ek olarak translated status üretimini hangi DOM bileşenleri tetikliyor (ör. sadece belirli element visible olunca) bunu da gözlemleyin. Bazı crawler’lar için “yalnızca görünürlük değişimi” bile farklı metin sinyali yaratır.

13) Karar özeti tablosu: indeks mi noindex mi, canonical’i nereye sabitlemeli?

Aşağıdaki tablo, translated status ile oluşan varyantlar için hızlı bir “policy eşlemesi” sağlar. Kurallarınızı ekip içinde standardize etmek için tabloyu dokümana birebir koyabilirsiniz.

Senaryo	İndeks kararı	Canonical hedefi	hreflang stratejisi
Aynı URL içinde translated=true sonradan gelir	Tek bir karar (genelde noindex veya tutarlı index policy)	URL kimliğine sabit (çoğunlukla orijinal)	Eşleşmeler sabit; hreflang varyantları tanımlı
Parametreli çeviri (?lang=en) ayrı varyant	Çoğu durumda çeviri noindex veya index+canonical’e bağlı tekil kaynak	Orijinal (yaklaşım A) veya locale canonical (yaklaşım B)	hreflang ile “dil varyant” bağla
Ayrı route (/msg/123-orijinal vs /msg/123-translation)	Bağımsız değer varsa index; değilse noindex	Tekil kaynak seçimine göre tek taraflı	Çelişkisiz alternatif eşleşmeleri
JS ile geç çeviri yüklenir	Server-side sinyalle noindex/canonical tutarlılığı	Render bağımsız sabit canonical	SSR yoksa hreflang yine tanımlı, ama doğrulama şart

14) Ölçek büyüdükçe (100+ locale) crawl bütçesi ve canonicalizasyon maliyeti nasıl yönetilir?

Locale sayısı arttıkça her mesajın farklı dil varyantları için ayrı indekslenebilir URL üretme ihtimali doğar. Bu noktada en kritik strateji, canonical + noindex + hreflang üçlüsünü “crawl budget” ile uyumlu hale getirmektir. Buradaki hedef, tüm locale’leri indexlemek değil; arama için anlamlı olanları seçmektir.

Öneri: “Locale whitelist” yaklaşımı kurun. Yüksek talep gören dillerde indekslenebilir kalite varsa (yeterli kullanıcı erişimi, kalıcı içerik, yeterli bağlam), o dillere index ve hreflang; diğerlerine noindex ve canonical’e bağlanmış temsil verin. Böylece translated status’ın SEO’yu degrade etmesini engellersiniz.

15) Cloudflare/edge cache varyantları karıştırıyorsa nasıl test edilir?

Edge cache translated status parametrelerini doğru vary etmezse, bir kullanıcıya çevrili içerik servis edilirken başka bir crawler’a orijinalsiz/ters sırayla içerik gidebilir. Bu da canonical ve noindex sinyallerini dolaylı yoldan yanlışlaştırır.

Test için en pratik yaklaşım, farklı “cache keys” üretildiğini doğrulamaktır: ?lang ve translated=true parametreleri cache varyantına dahil mi? Ayrıca CDN’den dönen HTML’in robots ve canonical etiketleri her varyantta aynı mı? Gerekirse “noindex kararının geçersiz olduğu” edge cache davranışlarını ayrı rule ile override edin.

16) İlgili uygulamalar ve ek okuma

Bu yazı translate-status odaklı olsa da chat platformlarında indeks kararları benzer teknik problemlerle birlikte yaşanır. Özellikle durum değişimi, koşullu UI ve parametre tabanlı varyantlar gibi konularda şu rehberler iyi bir bağlam sağlar: Chat’te Poll (Oylama) Mesajları İndekslensin mi? Sonuçlar Değişince Canonical/Noindex Nasıl Yönetilir?

Ayrıca “aynı URL’de koşullu içerik” genel çerçevesi translate-status için de güçlü bir dayanak sunar: Kullanıcı Engeli Sonrası Aynı URL’de Koşullu İçerik: Chat Sitelerinde Varyant SEO Uyumlu Tasarım (Canonical/Cache/Noindex Stratejileri). Eğer sohbet arşivinde erişim kapanınca redirect/noindex eşik geçişini de aynı sistemde yönetiyorsanız: Chat Konuşma Arşivinde Private Room Sızıntısını Önleme: Teaser Yerine Yetki Kontrollü Güvenli Meta (noindex + SSR) makalesiyle entegre düşünebilirsiniz.

FAQ

“Çeviri görüldü” etiketini indekslemek SEO’yu iyileştirir mi, yoksa sadece duplicate/ince içerik riski mi yaratır? Çoğu chat senaryosunda iyileştirmekten ziyade kirlilik yaratır. Çünkü translated status tekil bir bilgi hedefi olmak yerine aynı mesajın görsel/metin temsilini değiştirir. İndeks ancak çeviri varyantlarının gerçekten arama talebi üretmesi ve canonical/noindex uyumunun oturmasıyla anlam kazanır.

Orijinal ve çeviri varyantlarında canonical mi yoksa hreflang mı önce düşünülmeli? Önce tekil kaynak kararı için canonical. Ardından hreflang ile dil/ülke eşleşmelerini doğru ve çelişkisiz biçimde bildirin. Hreflang tek başına canonical karmaşasını çözmez.

Aynı URL içinde durum değişiyorsa (translated status sonradan gelir) canonical nasıl korunur? Canonical’i URL kimliğine sabitleyin. İlk render orijinal olsa bile canonical değişmemeli; noindex gerekiyorsa iki durumda da noindex uygulanmalıdır. Böylece crawler’ın farklı zamanlarda gördüğü içerik değişse bile “tekil kaynak” sinyali tutarlı kalır.

Noindex HTTP header mı meta robots mı daha doğru? JS/SSR farkı var mı? JS ile geç yüklenen içeriklerde meta robots, render tutarsızlığından etkilenebilir. Bu yüzden noindex için mümkünse HTTP header (X-Robots-Tag) veya SSR/edge tabanlı meta tercih edilir. SSR varsa meta robots genelde yeterli olur; CSR-only senaryolarda header daha güvenilir.

Çeviri dil hedefleri çok olduğunda (100+ locale) canonicalizasyon maliyeti ve crawl bütçesi nasıl yönetilir? Tüm locale’leri indexlemeyin. Locale whitelist / threshold yaklaşımı kurun. İndexlenecek locale’lere canonical + hreflang; geri kalanlara noindex ve canonical bağlayın. Edge cache ile varyantların karışmasını da test edin.

Cloudflare/edge cache, varyantları karıştırıyorsa nasıl test edilir? Her varyant için (ör. ?lang ve translated=true) HTTP yanıtını inceleyin: canonical, robots, hreflang etiketleri doğru mu? Cache key/vary ayarları doğru mu? Farklı crawler/istemci (bot vs gerçek tarayıcı) için aynı URL’de etiketlerin tutarlılığını kontrol edin.