Chat Sitelerinde Otomatik Çeviri (Mikro Çeviri) ile Oluşan Duplicate Content’i Engelleme Rehberi: Hreflang + Slug Stratejisi

Çok dilli chat platformlarında otomatik çeviri özelliği büyümeyi hızlandırır; ancak teknik SEO tarafında yeni ve çoğu zaman gözden kaçan bir risk de doğurur. Özellikle chat sitelerinde otomatik çeviri (mikro çeviri) ile duplicate content oluşmasını nasıl engellersiniz sorusu, sadece “canonical yazdık” yaklaşımına sığmaz. URL üretimi, indekslenebilirlik, render akışı ve çeviri çıktısının stabilitesi aynı anda düşünülmelidir.

Mikro çeviri (chat odası/mesaj bazlı otomatik çeviri), kullanıcı aynı sohbeti farklı dillerde okumaya başladığında farkında olmadan çok sayıda benzer ama indekslenebilir varyant üretebilir. Bu varyantlar arama motorları için “aynı içerik farklı URL’lerde” gibi algılanır; böylece duplicate content sinyalleri güçlenir. Hatta yanlış dil varyantının SERP’te görünmesi gibi istenmeyen sonuçlar bile ortaya çıkabilir.

1) Sorun Tanımı: Mikro çeviri nedir, duplicate nasıl oluşur?

Mikro çeviri, genellikle oda içindeki mesajların (bazen oda başlığının da) kullanıcının diline göre anlık çevrilmesidir. Uygulama “UI katmanında çeviri gösteriyoruz” dese bile, mimari kurguda bir hata varsa çeviri sonuçları URL/slug veya sayfa varyantı üretmeye başlayabilir. Sonuç da nettir: Aynı oda, farklı dil varyantlarında çok sayıda indekslenebilir sayfaya dönüşür.

Duplicate oluşumunun en yaygın sebeplerinden biri chat’in dinamik yapısıdır: aynı mesaj seti farklı dillerde render edilir; fakat URL veya HTML çıktısı botların gözünde indekslenebilir hale gelir. Böylece arama motorları şu senaryoları ayrı sayfalar sanır: dil kodu farklıdır, slug jitter (benzer ama farklı string) vardır, çeviri model çıktısı farklıdır ya da zaman damgası eklenmiş URL’ler görülür.

2) Duplicate Varyant Haritası: Olası URL ve içerik varyantları

Duplicate riskini yönetmenin en pratik yolu şudur: “Hangi varyantlar gerçekten indekslenebilir oluyor?” sorusunu baştan netleştirmek. Aşağıdaki harita, mikro çeviri sırasında sık karşılaşılan varyantları bir “risk katalogu” gibi düşünmenize yardımcı olur.

Varyant türü	Örnek URL/çıktı	Duplicate riski	SEO kontrolü
Dil için ayrı slug	/oda-123/tr/sohbet-arkadaslar	Orta-Yüksek (hreflang doğru değilse)	Hreflang + canonical + sitemap disiplini
Model/çeviri çıktısı farkı	Çeviri text’i farklı (aynı mesaja dayalı)	Yüksek (zamanla değişirse)	Stabil çeviri önbellek anahtarı + noindex/no-follow
Zaman damgası/variant ID	/oda-123/tr/sohbet-arkadaslar?ts=171234	Çok Yüksek	Parametreyi url’den çıkarmak veya noindex
Slug jitter	/oda-123/tr/sohbet-arkadaslar-9f2a	Çok Yüksek	Slug’ı deterministik üretmek, jitter’a izin verme

Bu harita aslında “hreflang yazacağım” planını tamamlar. Çünkü hreflang yalnızca neyin neyle eşleştiğini doğru söylemenizi sağlar. Ama mikro çeviri sayfaları her kullanıcı için URL üretiyor ya da çeviri çıktısı HTML’i değiştiriyorsa, duplicate sinyalini tek başına “hreflang var” diyerek azaltmak her zaman mümkün olmaz.

3) Hreflang Prensipleri: Hangi varyantlar hreflang ile eşlenmeli? x-default stratejisi

Hreflang, farklı dil sürümleri arasında “bu sayfa hangi dil varyantı” ilişkisini daha net hale getirir. Mikro çeviri bağlamında kritik nokta şudur: Hreflang, gerçek dil sürümleri için doğru çalışır; “mesaj bazlı anlık mikro çeviri” için ise çoğu zaman uygun değildir.

Bir oda arşivi sayfası (ya da oda başlığı + özet gibi nispeten sabit içerikler) gerçekten “dil sürümü” olarak tasarlanabiliyorsa, o zaman hreflang ile eşleyin. Ancak mesaj seviyesinde her kullanıcı etkileşiminde üretilen çeviri çıktısı URL’e taşınıyorsa, bu varyantları hreflang kapsamına almak genellikle doğru değildir.

Uygulamada x-default kullanımı da atlanmamalı. x-default, arama motorunun “hangi dile bakacağını anlayamadığı” durumda en mantıklı varsayılan davranışı hedefler.

• Hreflang: Oda arşivi / dil sürümü olarak tasarlanmış sabit sayfalar arasında
• x-default: Kaynağın “asıl dil sürümü” veya default dil (ör. platform ana dili) için
• Hreflang dışı: URL üretmeden sadece UI’da gösterilen mikro çeviri (indexlenmeyecek varyantlar)

4) Slug/Dil URL Tasarımı: Aynı oda için dil farkını nerede göstermeli, hangi durumda göstermemeli?

Slug stratejisi, duplicate riskinin merkezinde yer alır. Mikro çeviriyle oluşan varyantları iki parçaya ayırın: (1) “aynı oda arşivinin dil sürümü” ve (2) “mesajların kullanıcı dilinde UI’da gösterilen mikro çeviri.” Bu ayrım net yapılmazsa, aynı oda farklı kullanıcılar için farklı çeviri varyantlarını URL’ye taşıyıp sayfayı çoğaltmaya başlar.

Örnek 1: Aynı oda için /tr/... ve /en/... slug’ları; hreflang eşleşme tablosu

Diyelim ki oda slug’ı “oda-arkadaslik” ve asıl içerik dili Türkçe olsun.

Sayfa	Hreflang	Eşlenen diğer varyantlar
/oda-arkadaslik/tr/	hreflang="tr"	/oda-arkadaslik/en/ ve x-default
/oda-arkadaslik/en/	hreflang="en"	/oda-arkadaslik/tr/ ve x-default
/oda-arkadaslik/ (default)	hreflang="x-default"	/oda-arkadaslik/tr/ (asıl dil) işaret eder

Buradaki kritik şart şu: Bu iki sayfa “aynı oda arşivinin” gerçek dil sürümleri olmalı. Mesaj bazlı mikro çeviri bu URL’leri çoğaltmamalıdır.

5) Otomatik Çeviri Akışında Indekslenebilirlik Kontrolü: SSR/Prerender, bot filtreleri, noindex/robots ayrımı

Mikro çeviri çoğu zaman anlık çalıştığı için sayfayı dinamikleştirir. SEO hedefiniz şuna odaklanmalı: indekslenebilir HTML’i yalnızca “kataloglanması gereken” sayfalarda üretmek; mikro çeviri varyantlarında ise indekslenmeyi kapatmak.

Bu yüzden render stratejisini katmanlayın. Oda arşivi gibi indexlenmesi gereken sayfalar için SSR/Prerender kullanın. Mesaj seviyesinde mikro çeviri için ise kullanıcı cihazında çalışacak şekilde UI’da gösterin. Botlar tarafında da net bir karar verin: bazı botları “UI’daki çeviri”ye yönlendirmek gereksiz indeks üretimini tetikleyebilir.

Pratik ayrım:

• Asıl sayfalar (indexlenir): oda arşivi, sabit özet, dil sürümü (SSR/Prerender)
• Mikro çeviri (indexlenmez): mesaj seviyesi çeviri (client-side render veya SSR sonrası noindex fragment yaklaşımı)
• Bot filtreleri: render pipeline’da “bot user-agent + çeviri üretme” gibi aşırı üretim davranışlarından kaçının

6) Canonical Tasarımı: Mikro çeviri varyantlarında canonical nasıl kurulur (ve ne zaman noindex yerine geçmez)?

Canonical, “arama motoru hangi URL’i tercih etmeli?” sorusunun cevabıdır. Ancak mikro çeviri senaryosunda canonical yazmak tek başına yeterli olmayabilir; çünkü bazı varyantlar hiç üretilmemelidir. Eğer mikro çeviri sayfaları gerçekten indekslenebilecek şekilde ortaya çıkıyorsa, canonical’ı doğru kaynak URL’e işaret edecek biçimde kurgulamak gerekir. Fakat URL/HTML çoğalması yüksek seviyedeyse noindex çoğu durumda daha etkili bir çözümdür.

Kural önerisi: Mesaj seviyesinde kullanıcı diline göre üretilen çeviri çıktısı HTML’de yer alıyorsa ve bu sayfalar URL ile temsil ediliyorsa, çoğu senaryoda canonical yerine noindex (gerekirse nofollow) daha güvenlidir.

Öte yandan oda arşivi gibi iki dil sürümü gerçek olarak ayrılıyorsa, canonical’ı karşılıklı ya da doğru kaynak dil sürümüne yönlendirebilirsiniz. Bu noktada hreflang + canonical çakışmamalı: biri “dil eşleşmesi”ni anlatmalı, diğeri “tercih edilen sürümü” belirlemelidir.

7) Query/Parametre ve Oturum Etkileri: Dil/çeviri anahtarları query string’e dönerse ne yapılmalı?

Dil parametresi query string’e kaçtığında (ör. ?lang=tr), URL’ler kolayca çoğalır. Özellikle chat odalarında oturum bilgisi, çeviri anahtarı, zaman damgası veya “variant ID” gibi alanlar query parametrelerle ekleniyorsa, arama motoru bunları farklı sayfalar gibi görebilir.

Örnek 3: Dil parametresi query string olduğunda canonical/noindex karar örneği

Şöyle bir URL düşünün: /oda-arkadaslik/?lang=tr. Eğer bu sayfa “oda arşivinin indexlenir dil sürümü” değil de kullanıcıya anlık mikro çeviri deneyimi sunuyorsa, en sağlıklı seçenekler genelde şunlardır:

• noindex (sayfa sadece UI varyantıysa)
• Varyantın canonical’ını indekslenir dil sürümüne yönlendirmek (örn. /oda-arkadaslik/tr/)
• Query string’e bağlı içerik farkı büyükse canonical yerine noindex’ı öne almak

Query string kullanımı kaçınılmazsa, parametrelerin “page identity” üretmemesi için dili yalnızca client-side davranışı etkileyen bir tercihe indirgeyin. Sunucu tarafı içerik/HTML farkını büyütüyorsa duplicate riskiniz de artar.

8) Çeviri çıktı stabilitesi: Aynı mesajın tekrar çevrilmesinde deterministik anahtar/önbellek yaklaşımı

Mikro çeviri duplicate’ini tetikleyen en sinsi sebeplerden biri çeviri çıktısının zamanla değişmesidir. Model güncellemeleri, farklı servis rotaları veya rastgelelik ayarları (temperature/seed benzeri) aynı mesaj için farklı Türkçe/İngilizce sonuç üretebilir.

Örnek 5: Çeviri çıktısının zamanla değişmesi (model farklılığı) durumunda “stabil çeviri” önbellek anahtarı kurgusu

Çözüm, “aynı mesaj + aynı hedef dil + aynı çeviri sürümü” için deterministik bir sonuç üretmektir. Önizleme anında değişebilir olsa bile, indexlenebilecek içerik kategorilerinde olan çevirileri stabil tutun. Örneğin şu önbellek anahtarı yaklaşımı:

• Mesaj kimliği (message_id) + hedef dil (tr/en) + çeviri sürümü (model_version/service_build) + kaynak metin hash
• Sonuç: Model değişse bile, geçmişte üretilmiş “indexlenebilir çeviri” sabit kalır

Böylece arama motorunun gördüğü içerik “aynı URL’de zamanla bambaşka metin” davranışı sergilemez. Bu da duplicate ve “içerik değişkenliği” sinyallerini azaltır.

9) Segmentasyon: Oda bazlı index ile mikro-çeviri sayfalarının nasıl ayrılacağı (sitemap ve index sitemap segmentasyonu)

Oda arşivi index’i ile mikro çeviri variantlarını net bir ayrım ile yönetin. Mikro çevirinin asıl amacı kullanıcı deneyimidir; bu yüzden sitemap’e girmemelidir. Aksi halde crawl bütçenizi boşa harcarsınız ve duplicate sinyali daha da büyür.

Örnek 4: Oda arşivi sitemap’inde yalnızca ‘asıl dil sürümleri’ yayımlanması; mikro çeviri segmentinin sitemap dışında bırakılması

Örneğin şu iki kategoriye bölün:

• asıl_dil_arşivi: /oda-arkadaslik/tr/ ve /oda-arkadaslik/en/ (sadece “gerçek dil sürümü” sayfaları)
• mikro_çeviri_mesaj: mesaj seviyesinde UI’da gösterilen çeviri (sitemap yok)

Bunun sitemap index/segmentasyon karşılığı şudur: index sitemap dosyaları yalnızca indexlenir sayfa kümelerini içermelidir. Mikro çeviri sayfalarını segmentasyonun tamamen dışında bırakın.

10) Uygulama Adımları: 0-1 kurulum planı (veri modeli, URL şeması, hreflang üretimi, cache)

Aşağıdaki plan, “uçtan uca” mimariyi kurmanıza yardımcı olur: veri modelinden URL şemasına, hreflang üretiminden cache kararlarına kadar.

1. Veri modelini ayırın: “Oda arşivi dil sürümü” ile “mesaj mikro çeviri” ayrı kaynak türleri olsun. Mesaj mikro çeviri indexlenmez.
2. URL şemanızı sabitleyin: Oda arşivi dil sürümlerini deterministik path ile yönetin (örn. /{room-slug}/{lang}/). Mikro çeviriyi URL’e bağlamayın.
3. Hreflang üretimini sadece dil sürümleri için yapın: mesaj mikro çeviri varyantlarını hreflang kapsamına dahil etmeyin.
4. Çeviri önbelleği kurgulayın: mesaj çeviri çıktısı için stabil önbellek anahtarı kullanın (message_id + target_lang + translation_version).
5. Render ve robot davranışını belirleyin: SSR/Prerender ile indexlenir sayfayı üretin; mikro çeviri için noindex/robots mantığını uygulayın.

Bu adımların pratik sonucu şudur: arama motoru yalnızca sizin kontrol ettiğiniz “asıl dil sürümleri”ni görür; mikro çeviri ise uygulamanın kullanıcı arayüzünde kalır. Böylece SEO hedeflediğiniz büyüme, kontrolsüz bir duplicate içerik üretim hattına dönüşmez.

11) Risk Kontrolü ve İzleme: Search Console raporları, index kapsamı, duplicate sinyalleri, log analizi

Planı kurduktan sonra asıl soru şudur: “Gerçek dünyada arama motoru ne görüyor?” Bu sorunun cevabı için hem Search Console hem de sunucu/log seviyesinde doğrulama yapmanız gerekir.

Kontrol hedefleri: indeks kapsamında beklenmedik dil/query varyantlarının görünmemesi, “Aynı içeriğe sahip sayfalar” uyarısının artmaması ve tarama israfının düşmesi. Log analiziyle botların hangi URL’lere eriştiğini görür, mikro çevirinin gerçekten URL üzerinden crawl edilip edilmediğini anlarsınız.

Bu doğrulamayı küçük bir ölçüm döngüsü gibi düşünün: değişiklik sonrası 1-2 crawl periyodunda davranışın stabilize olup olmadığını izleyin. Stabil değilse canonical/noindex veya sitemap disiplini tekrar gözden geçirilmelidir.

12) Yaygın hatalar: Mikro çeviriyi yanlış indekslemek ve duplicate sinyali üretmek

Mikro çeviri projelerinde en sık yapılan hata, “canonical yazdık, gerisi otomatik düzelir” varsayımıdır. Ancak URL/HTML çoğalması yüksekse canonical bile arama motorunun taradığı binlerce varyantı kontrol etmeye yetmez. Duplicate sinyalinin büyümesine tek başına engel olamaz.

• Slug jitter (çeviri sonucu farklı oldukça slug değiştirmeniz): indekslenir varyantlarda duplicate büyür.
• Mesaj mikro çeviriyi URL’e bağlamak: her kullanıcı dil tercihi için yeni sayfa üretir ve crawl bütçesini boşa harcar.
• Hreflang’ı yanlış eşlemek: dil sürümleri yerine mikro çeviri varyantlarına hreflang yazmak “yanlış dil seçimi” ve gereksiz eşleşmeler doğurur.
• Parametreleri bırakmak: ?lang=tr gibi query string’ler içerik kimliğine dönüştüğünde duplicate riskini artırır.

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

Bu bölümde uygulayabileceğiniz bir kontrol listesi veriyorum. Buradaki amaç basit: sistem gerçekten “duplicate üretmeyen” davranışa geçiyor mu, bunu kanıtlamak.

1. URL örneklemesi yapın: aynı odada farklı kullanıcı dillerinde test edin. Arama motoru benzeri request ile (headless) URL sayısını çıkarın. Mikro çeviri için beklenmedik yeni URL üretiyor musunuz?
2. Indexlenebilirlik sinyallerini doğrulayın: micro çeviri varyantlarında noindex / robots ayrımını ve canonical’ı kontrol edin. Oda arşivi dil sürümlerinde hreflang/canonical tutarlı mı?
3. Sitemap segmentasyonunu kontrol edin: sitemap.xml ve index sitemap’lerinde mikro çeviri sayfaları hiç görünmüyor mu? Oda arşivi dil sürümleri doğru mu?
4. Search Console raporlarını karşılaştırın: “Aynı içeriğe sahip sayfalar” uyarısı artıyor mu? URL bazlı index kapsamı, beklediğiniz dil sürümü sayısına yaklaşıyor mu?

İsterseniz mimariyi benzer yaklaşımlarla pekiştirmek için şu konulara da bakabilirsiniz: Dinamik Chat Oda Sayfalarında SSR ile İndekslenebilirlik: Kontrol Listesi, Mimari Seçimler ve Bot-Safe HTML Stratejisi ve Sohbet Odalarında Tarih-Saat URL’siz “Zaman Tabanlı” İndeksleme: Query’siz Slug Tasarımı ve SEO Kontrolleri. Bu iki yazı, mikro çeviri kadar “dinamik veri” kaynaklı indeksleme risklerini daha sistematik ele almanıza yardımcı olur.

Ek Örnekler: Mikro çeviriyi URL üretmeden sadece UI’da tutma

Örnek 2: Mikro çeviri mesaj seviyesi çıktının URL üretmeden sadece UI katmanında gösterilmesi (indexlenmeyecek varyant)

Bu yaklaşımda oda arşivi tek bir URL ile temsil edilir. Dil sürümü ayrımı yalnızca oda arşivinin kendisi için yapılır. Mesaj çevirisi ise mesaj bileşeninde uygulanır: botlar bir sayfayı indekslerken, mesaj metninin çevrilmiş hali DOM’da yer alsa bile sayfaya “yeni URL kimliği” eklenmez. Böylece indekslenebilir tek kimlik oda arşividir; mikro çeviri ise içerik varyasyonu olarak kalır.

Bu yöntemin SEO kazancı net: duplicate URL patlaması ciddi şekilde azalır. Kullanıcı deneyimi ise aynı kalır; çeviri yine de kullanıcı dilinde görünür.

Sık Sorulan Sorular (SSS)

Mikro çeviri için ayrı URL üretmeli miyim, yoksa sadece UI’da mı göstermeliyim?
Genellikle ayrı URL üretmek duplicate riskini artırır. Mikro çeviri mesaj seviyesi ise çoğu senaryoda UI katmanında gösterildiğinde daha güvenli olur; asıl dil sürümleri (oda arşivi gibi) için ayrı URL bırakın.

Hreflang tag’larını otomatik üretirken en çok hangi eşleştirme hataları duplicate yaratır?
Dilin yanlış eşlenmesi (tr sayfasını en ile bağlamak), x-default’ı rastgele bir varyanta yönlendirmek ve mesaj mikro çeviri varyantlarına hreflang yazmak en yaygın hatalardır. Hreflang üretimini yalnızca indexlenir dil sürümlerine bağlayın.

Çeviri çıktısı değişiyorsa (model sürümü/servis güncellemesi) canonical/noindex nasıl yönetilir?
Geçmişte “indexlenebilir” olarak görünen içerikler stabil kalmalı. Bunun için stabil çeviri önbellek anahtarı kullanın. Eğer sayfa zamanla farklı metin gösterecekse ve URL kimliği değişmiyorsa bile noindex tercih edilebilir.

Dil parametresi query string kullanmak ne zaman kabul edilebilir, ne zaman sorun çıkarır?
Eğer query string yalnızca client-side bir görünüm tercihi ise (sunucuda içerik kimliği değiştirmiyorsa) kabul edilebilir. Sunucu tarafı içerik/HTML farkı büyürse ve kullanıcılar farklı query’lerle farklı sayfalar görmeye başlarsa sorun çıkar.

Sitemap’te hangi varyantlar yer almalı; mikro-çeviri sayfalarını nasıl dışarıda tutarım?
Sitemap’te yalnızca indexlenmesi gereken asıl dil sürümleri (ör. oda arşivi dil path’leri) olmalı. Mikro çeviri mesaj seviyesini segmentasyonun dışında tutun. Sitemap index kullanıyorsanız mikro çeviri kümelerini ayrı segment olarak asla üretmeyin.

Search Console’da ‘Aynı içeriğe sahip sayfalar’ uyarısını nasıl yorumlamalıyım?
Bu uyarı, canonical/hreflang/sitemap uyumsuzluğuna işaret edebilir. Ayrıca çeviri çıktısı değişkenliği veya parametreli varyantların crawl edilmesi de tetikleyebilir. Log + URL örneklemesi ile hangi varyantların indexlenmeye çalıştığını bulun ve düzeltin.

14) Sonuç: Mikro çeviriyle duplicate’i engellemek için uçtan uca mimari

Chat sitelerinde otomatik çeviri (mikro çeviri) kullanıcılar için güçlü bir i18n özelliğidir; ancak SEO açısından kontrolsüz URL/slug üretimi ve indekslenebilir varyant oluşumu duplicate içerik riskini büyütür. Çözüm; hreflang + slug tasarımını sadece “etiketler” olarak değil, URL kimliği, render stratejisi, sitemap segmentasyonu ve çeviri stabilitesi şeklinde bir bütün olarak kurmaktır.

Doğru mimari kurulduğunda arama motoru yalnızca asıl dil sürümlerini keşfeder; mikro çeviri ise uygulamanın kullanıcı deneyiminde kalır. Böylece hem büyümeyi destekler hem de “duplicate content oluşmasını nasıl engellersiniz” sorusunu kalıcı bir tasarımla yanıtlamış olursunuz.