Chat’te “Translated/Çeviri” Etiketi SEO’yu Nasıl Etkiler? Canonical + Hreflang İçin Pratik Yönetim Rehberi

Çok dilli sohbet/mesajlaşma ürünlerinde “Translated/Çeviri” gibi bir durum etiketi (translated status) ilk bakışta sadece kullanıcı arayüzü gibi görünebilir. Ama işin SEO tarafı daha hassas: Bu etiketin görünümü, beklenmedik indeksleme davranışlarını tetikleyebilir. Özellikle aynı mesajın farklı dil varyantları farklı URL’ler üzerinden sunuluyorsa ya da aynı URL içinde dinamik içerik olarak “çeviri sürümü” üretiyorsanız, Google’ın aklına takılacak kritik soru şudur: “Hangi varyant asıl kaynak?” Bu soruya tutarlı bir cevap vermeniz gerekir.

Bu rehberin odağı şu anahtar cümle: “chat mesajlarında çeviri (translated status) etiketi SEO’da nasıl yönetilir? (canonical + hreflang)”. Burada temel problem şu: Chat mesajı seviyesinde ortaya çıkan çeviri durumu, sayfa/akış varyantlarıyla birlikte doğru şekilde indekslenmeli. Aynı içerikten fazla sayıda kopya oluşma (duplicate) riski azaltılmalı ve yanlış dil/versiyonların SERP’e düşmesi engellenmelidir.

Konu tanımı: “translated status/çeviri etiketi” nedir, SEO’da neden kritik olabilir?

“Translated status/Çeviri etiketi”, bir mesajın otomatik ya da kullanıcı isteğiyle başka dile çevrildiğini belirtmek için kullanılan bir UI öğesidir. Uygulamada bu etiket; mesaj kartı içinde “Translated”, “Çeviri”, “This message was translated” gibi görünebilir. Ancak bazı mimarilerde çeviri sonucu yalnızca ekranda gösterilmez; URL parametreleri (ör. ?lang=tr), farklı endpoint’ler (ör. /chat/{id}/tr/) ya da JSON/HTML parçaları olarak “çeviri varyantı” üretilebilir.

SEO’da kritik olmasının nedeni genellikle “Google’ın ekranda gördüğünüz şeyi birebir temel alması” değil; içeriklerin “erişilebilir URL üzerinden” nasıl sunulduğu ve hangi sayfanın hangi sinyali taşıdığıdır. Chat akışında çeviri yüzünden aynı mesajın farklı dil sürümleri indekse aday olursa; aynı mesajın farklı dil kopyaları farklı sayfalarda “double indexing” etkisi yaratabilir. Bu durum hem crawl bütçesini gereksiz yere tüketir hem de arama sonuçlarında yanlış dil varyantlarının görünmesine yol açabilir.

Kanibalizasyon/double indexing risk haritası (sayfa bazında vs mesaj bazında çeviri)

Önce risk alanlarını netleştirmek gerekir. Chat uygulamalarında çoğu zaman iki katman bulunur: (1) sayfa katmanı (oda sohbeti sayfası, mesajlar listesi, arşiv sayfası vb.) (2) mesaj/akış katmanı (tekil mesaj kartı, mesaj içinde orijinal+çeviri sunumu, “translated status” seçeneği).

Aşağıdaki risk haritası, canonical ve hreflang’ı yalnızca sayfa URL’sinde değil “mesaj varyantları” seviyesinde de nasıl düşünmeniz gerektiğini gösterir:

• Sayfa bazında çeviri varyantı: Odanın tamamı bir dil varyantına göre sunuluyorsa (/chat/123?lang=tr veya /chat/123/tr/), Google farklı URL’leri ayrı sayfalar gibi algılayabilir.
• Mesaj bazında çeviri varyantı: Aynı URL içinde bazı mesajlar çevrilmiş, bazıları çevrilmemiş olabilir; “translated status” nedeniyle HTML/JSON parçaları değişir. Bu durumda mesaj kartları farklı içerik üretir ama URL aynı kalabilir.
• Orijinal+çeviri birlikte gösterim: Tek sayfada hem kaynak dil hem hedef dil birlikte sunuluyorsa, Google hangi dili “asıl” kabul edecek sorusunu daha dikkatli biçimde ele alır.
• Sadece çeviri gösterimi: Kullanıcı ayarına göre orijinal gizlenip yalnız hedef dil kalıyorsa, içerik akışı kullanıcıya göre değişir. Bu değişkenlik canonical/hreflang ile tutarlı yönetilmezse indeks karmaşası görülebilir.

Canonical stratejileri: hangi URL’ler canonical olur? (parametre/dil/endpoint kurgusu)

Canonical etiketi, “bu sayfanın asıl/tercih edilen varyantı hangisi?” sorusunun cevabıdır. Chat uygulamalarında canonical kararınızı iki şeye göre verin: (a) aynı oda/akış için dil varyantları URL’ye yansıyor mu? (b) “translated status” yalnızca arayüz etiketi mi yoksa içerik gerçekten farklı bir dil sürümü mü üretiyor?

Pratikte iki yaygın URL mimarisi görürsünüz ve canonical stratejisi bu mimariye göre değişir:

Örnek 1: Query parametre bazlı dil mimarisi (ör. /chat/{id}?lang=tr). Bu mimaride, “Google’ın indekslemesini istediğiniz asıl dil varyantı” için canonical’ı o dilin URL’sine yazarsınız. Eğer çeviri sadece kullanıcının otomatik tercihiyle ekranda beliriyorsa ve arama motoru için tek “asıl” dil belirlemek istiyorsanız, canonical’ı orijinal dilin URL’sine bağlamak çoğu durumda daha sağlıklıdır.

Örnek 2: Path bazlı dil mimarisi (ör. /chat/{id}/tr/). Bu mimaride canonical kararını path’i esas alarak verirsiniz. Örneğin çeviri yalnızca “translated status” etiketiyle UI’da saklanıyorsa, indekslenecek sayfa için canonical tek bir dil path’ine sabitlenebilir; diğer varyantlar noindex veya canonical ile aynı asla yönlendirilir.

Senaryo örneği: Orijinal dil kullanıcıya göre değişiyor — canonical nasıl belirlenir? Eğer uygulamanız “kullanıcının tercih ettiği dilde” akışı otomatik seçerek gösteriyorsa, canonical’ı “kullanıcının anlık tercihi”ne bağlamayın. Bunun yerine şu yaklaşımı düşünün: chat akışında indekslenecek asıl dil varyantını sabitleyin (ör. oda sahibinin dili “default source language” kabul etmek) ya da mümkünse dil bazlı ayrı sabit URL’ler üretin. Böylece ?lang=tr gibi parametreler canonical’ı sürekli değiştiren bir faktöre dönüşmez.

Hreflang stratejileri: dil-ülke kombinasyonları, self-referencing, dönüşüm kuralları

Hreflang, aynı içeriğin farklı dil/ülke varyantları arasında doğru eşleşmeyi sağlar. Chat mesajlarında “translated status” nedeniyle dil varyantları oluşuyorsa, hreflang’ı doğru kurmak daha da önemli hale gelir. Çünkü canonical tek başına “diğer diller yok sayılır” gibi algılansın istemezsiniz; hreflang ise kullanıcı/lokasyonla uyumlu sürümü doğru şekilde eşleştirir.

Örnek bir hreflang seti (self-referencing dahil) şöyle kurgulanabilir:

Örnek Hreflang seti (örnek dili/ülkeyi uygulamanıza göre güncelleyin):

<link rel="alternate" hreflang="tr" href="https://example.com/chat/123/tr/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/chat/123/en-gb/" />
<link rel="alternate" hreflang="en-US" href="https://example.com/chat/123/en-us/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/chat/123/" />

Self-referencing kuralı açısından: Her dil varyant sayfasında, kendi dil kodunu da hreflang setinin içinde bulundurmalısınız. Böylece Google, “bu varyantın kendisi de diğerleriyle eşleşen setin bir parçası mı?” sorusuna net bir yanıt alır.

Chat akışı için pratik senaryolar: (1) orijinal+çeviri birlikte, (2) sadece çeviri, (3) dinamik yükleme

Chat uygulamasında “translated status” davranışı her zaman aynı şekilde ilerlemez. Bu yüzden canonical/hreflang kararınızı senaryoya göre netleştirmeniz gerekir.

Senaryo 1: Aynı mesajın orijinali + çevirisi birlikte gösteriliyor (ör. kullanıcı “Auto-translate” açmış, UI hem kaynak hem hedef metni birlikte basıyor). Burada iki seçenek vardır: (a) Arama motoru için asıl dil sayfayı sabitleyin ve diğer dili içeride görünse bile indeks sinyalini asıl dile yönlendirin, (b) Eğer gerçekten iki dil arasında anlamlı ayrışma varsa (ör. kaynak metin çevrilmiş metin yerine ikinci bir içerik alanı şeklinde ele alınıyorsa), “dil varyant” oluşturup iki sürümü ayrı URL’lerde yayınlayın. Aksi halde aynı URL içinde iki dil birlikte yer alıyorsa Google hangi dili “primary content” sayacağını daha tutarsız belirleyebilir.

Senaryo 2: Sadece çeviri gösteriliyor (ör. kullanıcı ayarında “orijinali gizle” veya “translate-only” modu). Bu durumda sayfa hedef dile göre içerik sunar. Canonical’ı hedef dilin URL’sine bağlayın. Eğer UI seçimi orijinal dil kaynağını da etkiliyorsa (ör. kaynak saklanıyor ya da farklı kayıtlar dönüyorsa), canonical’ı kullanıcıya göre dinamik değiştirmeyin; bunun yerine sabit bir dil endpoint’i kullanın.

Senaryo 3: Kullanıcı isteğine göre dinamik yüklenen çeviriler (ör. sayfa yüklendikten sonra “Translate” butonuyla çevrilen içerik). SEO açısından en riskli senaryolardan biridir. Çünkü Googlebot bu çeviriyi her zaman göremeyebilir. Bu nedenle canonical/hreflang uyumu için, indekslenmesini istediğiniz dil içeriğini mümkünse sunucu tarafında (SSR) veya ilk yüklemede erişilebilir hale getirin. Çeviri içerikleri sadece sonradan JS ile geliyorsa, indekse değer bir “dil varyantı” beklemeyin.

Dinamik içerik & JS render: Googlebot’un gördüğü canonical/hreflang uyumu

Google, canonical ve hreflang etiketlerini sayfanın HTML’inde gördüğünde daha deterministik davranır. Eğer “translated status” yalnızca JS ile ekleniyorsa, canonical/hreflang etiketleri de JS ile sonradan ekleniyorsa uyumsuzluk riski artar. Bu tür durumlar şunlara yol açabilir: bir dil varyantının canonical’ı başka bir dil varyantına işaret eder ya da hreflang seti eksik/yanlış görünür.

Pratik hedef: Googlebot’un “ilk istek” sırasında gördüğü kaynak HTML’de canonical ve hreflang bulunmalı, dil kodları tutarlı olmalıdır. Ayrıca canonical/hreflang ile sayfanın gerçek içeriği (özellikle “primary text”) uyumlu olmalıdır. “Translated status” etiketini UI’da görmek kolaydır; ama SEO uyumu, etiketlerin hangi varyantı hangi içeriğe bağladığı ile doğrudan ilgilidir.

Uygulama önerileri: meta tags/HTTP headers (x-default dahil) ve uygulama şeması

Uygulama tarafında canonical ve hreflang’ı yalnızca front-end’de üretmek yerine, dil/endpoint bilgisine göre sunucu tarafında üretmenizi öneririm. Ayrıca HTTP header seviyesinde de kontrol mümkünse bunu değerlendirin. Canonical için <link rel="canonical">, hreflang için <link rel="alternate" hreflang="..."> kullanın.

Ek olarak x-default ekleyin: kullanıcı/arama botu dil-ülke tahmini yapamadığında veya varsayılan dil/akış sunulacaksa x-default doğru hedefi göstermelidir. Chat uygulamalarında x-default genellikle “default landing” gibi düşünülebilir; örneğin oda arşiv sayfasının varsayılan dili.

Uygulama şablonu (kontrol edilebilir yaklaşım):

1. Sayfa render edilirken request dilini belirleyin (örn. oda default dili, URL path/query dili, kullanıcı pref’i değil).
2. Canonical’ı “indexlenmesi hedeflenen dil varyant” URL’sine sabitleyin.
3. Hreflang setini o dil varyantlarının tamamını kapsayacak şekilde oluşturun (self-referencing dahil) ve x-default ekleyin.

İndeksleme kontrolü: robots/meta noindex, sayfa varyantları ve crawl bütçesi yaklaşımı

Chat uygulamalarında her varyantı indexlemek genellikle doğru değildir. “Translated status” yalnızca UI öğesi ise (çeviri ekranda gösteriliyor ama arama motoru açısından ayrı bir anlam taşımıyorsa), çeviri/alternatif dil sayfalarını noindex yapmayı düşünebilirsiniz. Böylece crawl bütçesi gereksiz çeviri kombinasyonlarıyla tükenmez.

Ancak noindex verirken hreflang/canonical uyumunu bozmayın. Noindex sayfalarda canonical sinyali yine de doğru kaynak URL’ye işaret etmelidir. Çünkü Google noindex olsa bile canonical üzerinden ilişkilendirme yapabilir ve kümeleme/benzerlik sinyallerini uygulayabilir.

Örnek karar matrisi tablosu (sayfa varyantı vs mesaj varyantı):

Durum	Örnek URL	Canonical	Hreflang	İndeksleme
Oda tamamı hedef dile göre sunuluyor	/chat/123/tr/	/chat/123/tr/	tr + diğer diller + x-default	index
Mesaj çevirisi sadece UI’da “translated status”	/chat/123/?lang=ui-tr	Oda default dil URL’si	opsiyonel; dil setiyle uyumlu olsun	noindex (çoğu durumda)

Yaygın hatalar: “translated status” yüzünden canonical/hreflang uyuşmazlığı

Beklenen hata #1: Canonical’ı kullanıcı seçimine göre dinamik değiştirmek. Örneğin kullanıcı arayüzünde dili tr’ye aldığında, aynı URL üzerinde canonical bir anda /chat/123/en/ yerine /chat/123/tr/ olmaya başlar. Googlebot birkaç farklı gezide farklı canonical görürse kümeleme zayıflar.

Beklenen hata #2: “Translated” etiketi URL’de/parametrede yansıtılıp indexlenebilir kopya üretmek. Mesaj kartında sadece UI etiketi olmalı; eğer çevrilmiş içerik gerçekten ayrı bir sayfa gibi ele alınacaksa o zaman ayrı URL üretin. Aksi durumda, “translated status” yüzünden aynı chat akışının yüzlerce varyantı oluşabilir.

Beklenen hata #3: JS render ile hreflang/ canonical üretip Googlebot’un ilk istekte görmesini beklemek. Google bazı durumlarda JS işlese de, deterministik uyumluluk için canonical/hreflang’ın ilk HTML’de bulunması genellikle en güvenli yaklaşımdır.

Senaryo örneği: Aynı mesajın “translated status” etiketi nedeniyle indekslenmesi istenmeyen durumlar Eğer çeviri sadece kullanıcı “Translate” butonuna bastığında açılıyorsa ve hedeflenen şey arama sonuçlarında “çevrilmiş mesaj” sayfalarının görünmemesi ise, bu varyantları noindex yapın. Ayrıca mesaj düzeyinde çeviri yalnızca UI öğesi olarak kalsın; çevrilmiş metni URL/parametreyle yeni bir indexlenebilir kimlik haline getirmeyin.

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

Yayın öncesi ve sonrası kontrolü “tek seferlik doğrulama” gibi görmeyin. Daha doğru yaklaşım, bunu tekrarlanabilir bir süreç olarak kurmaktır. Aşağıdaki doğrulama adımları ekipler arasında ortak bir dil üretir:

1. URL varyantlarını karşılaştırın: Aynı oda için dil path/query varyantlarında canonical’ın her sayfada doğru hedefe işaret ettiğini doğrulayın (ör. /chat/123?lang=tr ile /chat/123/tr/ modelinde hangisi tercihli? tutarlılık var mı?).
2. Hreflang setinin eksiksizliğini denetleyin: Her dil sayfasında self-referencing hreflang bulunuyor mu, x-default mevcut mu, yanlış dil kodları var mı?
3. İlk HTML doğrulaması yapın: Googlebot/renderer’ın gördüğü kaynakta canonical/hreflang bulunuyor mu; “translated status” ile içerik değişirken etiketler de uyumlu şekilde devam ediyor mu?

Ek olarak, Indexing davranışını gözlemek için GSC’de URL Denetimiyle farklı dil varyantlarını test edin. Aynı içerik kümesinde farklı dil sürümleri bekliyorsanız “kapsam” ve “indekslenen sayfalar” raporlarında dil varyantları görünmelidir.

Yayın sonrası izleme: GSC URL denetimi, kapsam raporları, indekslenen dil varyantları

Yayın sonrası hedefiniz sadece “etiketler doğru mu?”yu kanıtlamak değil; “etiketler doğru çalışıyor mu?”yu gerçekten görmek olmalı. Search Console’da URL Denetimiyle hem canonical hedef URL’yi hem de alternate dil URL’lerini doğrulayın. Ardından Kapsam (Coverage) raporunda “noindex” veya “alternatif olarak Google tarafından seçildi” gibi durumların dağılımını izleyin.

Mesaj/akış değişkenliği olan ürünlerde dikkat edilmesi gereken bir diğer sinyal, aynı odada farklı dil varyantlarının indekslenme oranıdır. Beklediğinizden çok daha fazla varyant indeksleniyorsa, “translated status” UI öğesinin bir şekilde indexlenebilir varyant üretmeye başladığını düşünün (özellikle parametreler, cache anahtarları veya edge yönlendirmeleri devreye girdiyse).

Çeviri/translated status için teknik şablon (gated-free checklist mantığı)

Bu bölüm, ekiplerin doğrudan kullanabileceği bir uygulama kontrol listesi yaklaşımıdır. İndirilebilir kontrol listesi gibi düşünün: her madde “geçti/geçmedi” olarak işaretlenebilir.

• Canonical: Dil/endpoint kuralı belirlenmiş mi? (ör. oda default dili mi, URL path/query mi?)
• Hreflang: tr, en-GB, en-US ve x-default seti doğru mu? Self-referencing var mı?
• Mesaj düzeyi: “Translated status” yalnızca UI ise indexlenebilir kimlik üretmiyor mu?
• Noindex politikası: Çeviri sadece kullanıcı isteğiyle açılıyorsa varyantları noindex’e alıyor musunuz?
• JS uyumu: canonical/hreflang ilk HTML’de bulunuyor mu?

Ek olarak, sohbet platformunuzda indeksleme davranışını etkileyen başka dinamik alanlar varsa, aynı prensipleri oraya da uyarlayın. Örneğin arama filtreleri gibi facet’ler de yanlış yapılandırılırsa duplicate/kanibalizasyon üretebilir; konuyla ilgili yaklaşımı Chat Odası Arama Filtresi Şehir/Ülke İndekslenir mi? (Facet/Filtre SEO Politikası Rehberi) yazısından çerçeve olarak kullanabilirsiniz.

Chat akışında sayfalama ve sonsuz kaydırma gibi gezinme davranışları da crawl bütçesini etkiler. “Translated status” ile ortaya çıkan varyantların tekrar tekrar taranmasını istemiyorsanız, gezinme stratejinizi de sağlamlaştırın: Chat Odalarında Sonsuz Kaydırma Yerine Sayfalama Nasıl Yapılır? SEO’yu Bozmadan Teknik Rehber ile tamamlayıcı bir okuma yapabilirsiniz.

FAQ: En sık sorulan karar noktaları

“Translated” etiketi URL’de mi olmalı, yoksa sadece ekranda bir UI etiketi mi kalmalı? Çoğu durumda yalnızca UI etiketi kalmalı. URL’de “translated status” üretmek, çeviriye bağlı duplicate varyantlar yaratır. Eğer gerçekten arama için ayrı bir dil içeriği sunuyorsanız URL bazlı dil varyantı yapın.

Çeviri sadece kullanıcı seçimine bağlıysa canonical nasıl belirlenir? Canonical’ı kullanıcı tercihiyle dinamik değiştirmeyin. Canonical’ı indekslenmesini istediğiniz “default source” ya da URL’deki dil hedefiyle sabitleyin. Kullanıcı seçimi yalnızca içerik görünümünü etkiliyorsa, noindex/etiket uyumu ile kontrol edin.

Aynı chat mesajı iki dilde de görünüyorsa hreflang nasıl yönetilir? Önce hangi dilin “primary” kabul edileceğine karar verin. Tek URL içinde iki dil birlikte gösteriliyorsa hreflang’ın faydası azalabilir. İndekslenecek dil varyantlarını ayrı URL’lere taşıyın; her varyantta self-referencing hreflang kullandığınızdan emin olun.

Parametre bazlı dil değişiminde canonical nasıl yazılır? Örneğin /chat/{id}?lang=tr modelinde canonical, tercih ettiğiniz dil parametresiyle uyumlu hedef URL’ye işaret etmelidir. Eğer path bazlı bir mimari de varsa, canonical’ı tek bir “tercih edilen URL mimarisine” standardize edin.

Google hreflang’ı nasıl doğrular; self-referencing şart mı? Self-referencing kritik bir pratik hedeftir. Her dil varyant sayfasında kendi hreflang setinizin içinde bulunmayan setler bazı durumlarda yanlış eşleşmelere yol açabilir. Ayrıca x-default ile varsayılan dil senaryosunu kapsayın.

Dinamik olarak yüklenen çeviriler indekslenir mi, canonical/hreflang uyuşmazsa ne olur? Dinamik yüklenen çeviriler her zaman erişilebilir/indekslenebilir olmayabilir. Uyuşmazlık olduğunda Google, sayfayı beklediğiniz dil kümesine koymayabilir; canonical hedefini farklı seçebilir ya da alternatif dil yerine başka sayfayı indeksleyebilir. Bu yüzden ilk HTML’de canonical/hreflang uyumunu sağlamalısınız.