Sohbet Siteleri İçin Çok Dilli Hreflang ve URL/Slug Yönetimi Rehberi (Doğru Yapılandırma + Kontrol Listesi)

Sohbet sitesi gibi sürekli yeni sayfalar üreten, kullanıcı etkileşimiyle büyüyen platformlarda uluslararası SEO, klasik blog sitelerine göre çok daha hassas çalışır. Özellikle “sohbet sitesi için çok dilli (hreflang) slug yönetimi nasıl yapılır” sorusu, sadece etiket eklemekten ibaret değildir. Asıl mesele; doğru URL/slug mimarisini kurmak, canonical stratejisini netleştirmek, dinamik sayfaların çevrilmesini doğru tasarlamak ve SPA/SSR davranışlarını baştan bu mimariye uyarlamaktır.

Bu rehberde sohbet sitenizin oda/kanal sayfaları, arama sayfaları, kullanıcı profilleri ve gerçek zamanlı uygulama akışları için dil hedeflerine uygun bir hreflang + URL/slug sistemi kurmayı adım adım göreceksiniz. Hedefimiz; yanlış dil gösterimini, indeksleme hatalarını, canonical/duplicate riskini azaltmak ve büyüme ekibinizin sürdürülebilir şekilde yeni varyantlar ekleyebilmesini sağlamak.

Kapsam: Sohbet sitelerinde çok dilli SEO neden farklıdır?

Sohbet sitelerinde içerik yapısı çoğu zaman “tekil makale” mantığından çıkar. Bunun yerine oda sayfaları, kanal sayfaları, kullanıcı profilleri, mesaj akışları ve arama sonuçları gibi farklı türlerde sayfalar oluşur. Bu sayfaların bir kısmı dinamik üretilir, bazıları parameterize olur, bazıları da içerik zamanla değişir. Dolayısıyla hreflang ve slug yönetimi yalnızca yayın tarihi olan sabit sayfalar için değil; üretim mekanizması olan sayfalar için de baştan tasarlanmalıdır.

Bir diğer önemli fark, kullanıcı üretimi (UGC) içeriktir. Aynı “oda” iki dilde de var olabilir ya da tek bir oda deneyimi içinde farklı diller tercih edilebilir. Sohbetin gerçek zamanlı doğası (WebSocket, client-side routing) arama motorlarının hangi URL’i “asıl” olarak görmesi gerektiğini etkileyebilir. Bu yüzden dil/ülke hedefleri ile URL yapısı, teknik uygulama (SSR/CSR) ve yönlendirme kuralları aynı stratejinin parçaları olmalıdır.

Terminoloji: hreflang, dil-ülke vs dil, canonical, x-default, slug/URL yapısı

hreflang, arama motorlarına bir sayfanın hangi dil/ülke varyantlarına sahip olduğunu anlatır. Örneğin “tr-TR” ile “en-US” bir sayfanın farklı kullanıcı segmentleri için karşılık geldiğini belirtir. Buradaki en kritik nokta, her bir varyantın eksiksiz listelenmesi ve tutarlı canonical referanslarıyla çelişmemesidir.

Canonical, arama motoruna “benzer/tekrarlı içerikte asıl URL hangisi?” sorusunun cevabını verir. İki dil varyantı arasında yanlış canonical kullanırsanız arama motoru sizi tek dile “toplayabilir” ve diğer dillerin görünürlüğü düşebilir. Bu yüzden canonical ile hreflang ilişkisinin tasarımı şarttır.

x-default ise “hangi dil/ülke eşleşmesi yoksa varsayılan” varyantı belirtir. Sohbet sitelerinde özellikle dil seçimi kullanıcı davranışına bağlıysa (ör. otomatik dil algılama) x-default kritik hale gelebilir.

Slug/URL yapısı ise dil varyantlarını URL’de nasıl yansıttığınızı belirler: /tr/, /en/ klasörleri mi kullanacaksınız, yoksa alt alan adı (subdomain) mı; hatta parametre mi? Bu seçim hreflang doğruluğu ve yönetilebilirlik üzerinde doğrudan etkilidir.

URL mimarisi seçenekleri: /tr/, alt alan adı, parametre; artı/eksi analizi

Çok dilli sohbet sitelerinde en yaygın üç yaklaşım vardır: (1) klasör bazlı yol yapısı (/tr/, /en/), (2) alt alan adı (tr.example.com gibi) ve (3) query parametresi/parametrik dil (ör. ?lang=tr). Her birinin SEO etkileri, geliştirme maliyeti ve cache davranışı farklıdır; “ne kadar kolay yönetiliyor” kadar “botlar bunu nasıl görüyor” kısmı da önemlidir.

Klasör bazlı yapı (ör. /tr/oda/istanbul) yönetimi kolaydır; hreflang üretimi ve sitemap tasarımı daha nettir. Arama motoru açısından da daha pratik bir sinyal sağlar. Ancak sohbet sitelerinde çok sayıda dinamik parametre varsa (oda ID, kategori, arama kelimesi gibi), slug tasarımının disiplin gerektirdiği unutulmamalıdır.

Alt alan adı yaklaşımı bazı ekiplerde “dil izolasyonu” sağlar; fakat altyapı, sertifika, analytics ve içerik replikasyonu karmaşıklığı artırabilir. hreflang yine gerekli olur ve cross-domain canonical/hreflang çakışmaları dikkat ister.

Parametre bazlı dil ise (ör. /oda/istanbul?lang=tr) doğru canonical kurulmazsa duplicate senaryolarını büyütür. Ayrıca crawl budget yönetimi ve log analizinde daha fazla varyant görülebilir. Eğer kesinlikle query string kullanmanız gerekiyorsa canonical ve hreflang disiplininin çok daha sıkı uygulanması gerekir.

Slug yönetimi prensipleri: çeviri mi transliterasyon mu, tutarlılık, özel karakterler

Slug üretiminde iki yaygın karar vardır: çevrilebilir (ör. “istanbul” yerine dil bazlı karşılıkları) veya transliterasyon (harf/okunuşu koruma). Sohbet odaları gibi kullanıcı alışkanlığı yüksek sayfalarda transliterasyon çoğu zaman daha tutarlı olur. Çünkü aynı oda ID mantığıyla ilerlediğinizde URL’de anlam kayması veya karşılık bulma sorunları azalır.

Öte yandan, “sohbet-odasi” gibi kelime öbeklerinde çeviri yapmak kullanıcı beklentisini artırabilir. Burada önemli olan, çeviri yapılacak alanları net tanımlamak ve tüm varyantlarda aynı kuralı uygulamaktır. Örneğin sabit kelime parçaları çevrilecek (chat-room, sohbet-odasi), ama “oda kimliği” tamamen aynı kalacaksa (oda ID), eşleştirme çok daha kolay ilerler.

Özel karakter kullanımı da kritiktir. Türkçe karakterler (ğ, ı, ö, ü, ş, ç) bazı altyapılarda otomatik normalize edilirken bazı durumlarda çift dönüşüm yaratabilir. SEO açısından en sorunsuz yaklaşım, slug’larda ASCII uyumlu karakter seti kullanmaktır (ör. “sohbet-odasi” yerine uyumlu bir eş). Boşluk kullanmayın, tire/underscore standardını bir kez belirleyin ve tüm dillerde tutarlı kalın.

Hreflang tasarımı: dil/ülke kombinasyonları, x-default ve eksiksiz liste

hreflang tasarımında “dil/ülke kombinasyonları” kararını erken vermelisiniz. Örneğin tr-TR ile tr aynı anlama gelmez. “tr” genel bir dil hedefidir; “tr-TR” belirli ülke/dil varyantını temsil eder. Sohbet sitenizde hedef ülkeler nettir ve lokal içerik/detay varsa (ör. ödeme, yasal metinler, yerel topluluk kuralları) tr-TR tercih edilebilir.

Dil/ülke varyantlarınız büyüyebilir. Bu yüzden hreflang üretimini manuel yapmayın; oda/kanal slug’larınızın üretim mantığıyla entegre bir “varyant eşleştirme tablosu” ya da otomatik üretim kuralı oluşturun. En kritik hedef: Her varyant kendi varyantlarını referanslayan complete set ile listelensin. Eksik liste, yanlış dil gösterimi ve bazen de indeksleme tutarsızlığı yaratabilir.

Sohbet sitelerinde x-default, çoğu zaman “dil tespit edilemeyen” ya da “otomatik yönlendirme yapılsa bile arama motoru bir eş bulamazsa” devreye girer. Dil seçici UI’niz varsa ve bazı kullanıcılar özel dil paketleri görüyorsa x-default genellikle global/ana sürüme (ör. /en/ ya da varsayılan dil) oturtulur.

Örnek URL/slug planı: /tr/sohbet-odasi/… ↔ /en/chat-room/… (eşleştirme tablosu mantığı)

Dinamik sayfalarda en iyi uygulama, URL’de hem anlaşılır bir slug hem de içerik eşleştirmesini sağlayan bir kimlik mantığı kurmaktır. Örneğin aynı oda için farklı dilde görünen kelimeleri ayrı slug’larda kullanırken, oda kimliği dil bağımsız tutulabilir.

Bu yaklaşımı şöyle düşünün: aynı oda için TR tarafında “sohbet-odasi”, EN tarafında “chat-room” kullanıyorsunuz; oda kimliği ise ID veya sabit bir “roomKey” ile eşleşiyor. Böylece ekipler URL’de görünen kelime kısmını serbestçe çevirebilir, fakat aynı odanın karşılığını bozmadan devam edebilir.

Örnek:

/tr/sohbet-odasi/istanbul-odasi-12345
/en/chat-room/istanbul-room-12345

Burada “12345” sabit kalsın ki sunucu tarafında doğru oda verisini getirebilesiniz; “istanbul-odasi” kelime kısmı dile göre çevrilsin/transliterasyonla yeniden üretilsin. Aynı içerik karşılıklarını sistematik kurmak için “slug eşleştirme tablosu” mantığı kullanın: her roomKey için trSlug ve enSlug alanlarını tutun.

roomKey (dil bağımsız)	tr-TR URL/slug	en-US URL/slug	en-GB URL/slug
istanbul-12345	/tr/sohbet-odasi/istanbul-odasi-12345	/en/chat-room/istanbul-room-12345	/en-gb/chat-room/istanbul-room-12345
ankara-67890	/tr/sohbet-odasi/ankara-odasi-67890	/en/chat-room/ankara-room-67890	/en-gb/chat-room/ankara-room-67890

Örnek hreflang bloğu: tr-TR, en-US, en-GB + x-default

Aşağıdaki örnek, aynı oda sayfasının dil varyantlarının eksiksiz listelendiği bir şablonu temsil eder. Not: Burada URL’leriniz domain yapınıza göre (klasör/alt alan adı) değişir; mantık aynıdır.

<link rel="alternate" hreflang="tr-TR" href="https://example.com/tr/sohbet-odasi/istanbul-odasi-12345" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en/chat-room/istanbul-room-12345" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/chat-room/istanbul-room-12345" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/chat-room/istanbul-room-12345" />

Burada x-default örnek olarak EN varyantını gösteriyor. Sizde “varsayılan dil” farklıysa onu yansıtın. Ayrıca her varyant sayfasında bu setin bulunduğundan emin olun: tr-TR sayfası kendi hreflang setini (diğer dilleri de içererek) döndürmeli, EN sayfası da tr-TR’yi içermelidir.

Canonical ve hreflang etkileşimi: yanlış canonical duplicate/dil kırılması yaratır

Sık görülen senaryo şudur: hreflang doğru görünür ama canonical tek bir dile işaret eder. Örneğin TR sayfasında canonical “/en/…” olarak dönüyorsa arama motoru dil varyantlarının hepsini tek kaynağa toplayabilir. Sonuç olarak TR varyantları indekslenmez ya da TR aramalarında düşük görünürlük alırsınız.

Örnek canonical senaryosu: TR sayfası için şu üretiliyorsa:

<link rel="canonical" href="https://example.com/en/chat-room/istanbul-room-12345" />

Bu durumda TR sayfası “asıl” değil “kopya” gibi algılanabilir. Doğru çözüm: Her varyantın canonical’i kendi dil sürümüne işaret etmelidir (ya da açık kurala bağlı şekilde, varyant düzeyinde canonical tekilleştirme yapıyorsanız bunun hreflang setiyle uyumlu olması gerekir). Basit kural: sayfa dil/ülke varyantı ise canonical de o varyantın kendisi olmalıdır.

Dinamik sayfalar için strateji: oda/kanal sayfaları, arama sonuçları, kullanıcı profilleri (hangi sayfalar çevrilmeli?)

Sohbet sitelerinde “dinamik sayfa” kavramı kritik bir ayrımdır. Oda/kanal sayfaları genellikle kalıcı hedef sayfalardır ve SEO değeri taşır. Bu yüzden dil varyantlarını çevirmek ve hreflang ile eşlemek çoğu zaman doğrudur. Buna karşın arama sonuçları ve bazı filtre sayfaları sonsuz kombinasyon üretebilir; her varyantı dil bazında çevirmek crawl budget’ı patlatır.

Genel strateji olarak: İçerik kalıcıysa (oda adı, kanal teması, topluluk bilgisi) hreflang + çevrilmiş slug düşünün. Parametreli veya sınırsız varyant üretiyorsa (arama, gelişmiş filtreler, sonsuz scroll) ya dil varyantlarını sınırlayın ya da canonical/robots ve preroender/SSR stratejisiyle kontrollü görünürlük sağlayın. Buradaki amaç “her şeyi çevirmek” değil, doğru sayfaların doğru sinyallerle keşfedilmesini sağlamak.

Kullanıcı profilleri konusunda ise karar, ürün hedefinize bağlıdır. Profil sayfaları toplulukla büyürse ve dil/ülke deneyimi belirginse (ör. yerel kullanıcı açıklamaları, bio çevirisi), hreflang mantıklı olabilir. Ancak kullanıcı bio’su tek dilde üretilecekse ve çeviri yoksa “her dilde aynı profil” duplicate riskini artırır. Bu durumda yalnızca bir dilde indexlemek ve diğer dillerde x-default/alternatif stratejisi düşünmek gerekebilir.

Dinamik sayfa örneği: “/tr/oda/istanbul” ↔ “/en/room/istanbul” (oda ID ile dil bağımsız slug üretimi)

Dinamik sayfada en büyük pratik zorluk, oda adının dile göre değişmesi ama aynı odanın bulunabilir kalmasıdır. Bunun için oda ID (roomId) veya dil bağımsız “roomKey” üzerinden bir slug üretim pipeline’ı kurun.

Örnek eşleştirme:

/tr/oda/istanbul-odasi-12345
/en/room/istanbul-room-12345

Burada “12345” sabit. Dil değiştirdiğinizde oda adını çeviriyor veya translitere ediyorsunuz; slug’ın isim kısmı yeniden üretiliyor. Böylece aynı oda, farklı dillerde doğru karşılıkla indeksleniyor. Bu yaklaşım ayrıca ekiplerin yeni odalar eklerken “hangi URL oluşacak?” sorusunu daha deterministik yanıtlamasına yardım eder.

SPA/SSR ve yönlendirme: client-side routing, 301/302 etkileri, Accept-Language

Çok dilli sohbet sitelerinde SPA (client-side rendering) sık görülür: dil değişimi URL’yi değiştirmeden veya sadece client-side routing ile yapıldığında arama motoru doğru varyantı bulamayabilir. SEO açısından ana risk, arama motorunun initial response’ta hreflang setini görememesidir. Bu yüzden “ekranda doğru görünüyor” testi tek başına yetmez.

Bu nedenle SEO uyumu için iki yaklaşım öne çıkar: (1) SSR (server-side rendering) ile her dil varyantının ilk yanıtında doğru HTML hreflang/canonical üretmek ve (2) dil tespiti/reste yönlendirmelerinde server-side redirect kullanmak. Client-side (302 ile değil de JS ile) yönlendirme, crawler’ın “doğru URL”i keşfetmesini zorlaştırabilir.

Accept-Language ile dil algılama yapıyorsanız, bunun URL/slug stratejinizi bozmadığından emin olun. Kullanıcı tr ortamındaysa /tr/… sayfasına yönlendirin, ama bu yönlendirmeyi HTTP seviyesinde yapın. Ürün tarafında “kullanıcı dil tercihi” bir çerezde tutuluyorsa, çerezin varlığını arama motoru botları için de ele alın; yoksa botlar x-default’a saplanabilir.

SPA örneği gereği: client-side dil değişiminde SEO için yalnızca URL’yi değiştirmek yetmez; değişen URL için server tarafında doğru hreflang seti ve metrikleri döndürmeniz gerekir. Pratikte çoğu ekip, dil URL’i değiştiğinde server’ın dil paketini yüklemesini ve ilk HTML’de hreflang/canonical üretmesini tercih eder.

Sitemap ve hreflang doğrulaması: dil bazlı sitemap, tek sitemap içinde alternatifler, hata türleri

Sitemap, hreflang’ın “keşfi hızlandıran” yardımcı aracıdır. Dil varyantlarının sitemap’te görünür olması, botların doğru URL’leri bulmasını kolaylaştırır. İki yaygın yaklaşım vardır: dil bazlı sitemap dosyaları (sitemap-tr.xml, sitemap-en.xml gibi) veya tek bir sitemap içinde alternatif URL’leri birlikte göstermek.

Dil bazlı sitemap genellikle daha yönetilebilirdir. Ayrıca crawl budget planlama ve log analizinde daha net bir ayrım sunar. Tek sitemap ise altyapısı basit takımlarda tercih edilebilir; ancak set büyürse ve dinamik sayfalar çoksa “gereksiz varyantları sitemap’e yığmama” disiplinini daha zorlaştırır.

Hata türleri arasında şunlar sık görülür: sitemap’te sadece tr URL’lerinin olması ve hreflang setinde en-GB gibi URL’lerin referanslanması; sitemap’ten kaldırılan ama hreflang’ta duran URL’ler; ya da yanlış dil kodlarıyla (ör. en_us yerine en-US) üretilen hreflang. Bu yüzden sitemap/hreflang uyumu düzenli olarak test edilmelidir.

Uygulama adımları (adım adım doğrulama): hedef diller → URL planı → hreflang → canonical → test

Bu işi proje sürecine bağlamak, sonraki büyümeleri de kontrol eder. Aşağıdaki akış, sohbet sitenizin dinamik sayfalarıyla uyumlu şekilde ilerlemek için uygundur. Ekibin ritmini de korur: herkes aynı sırayla ilerler ve sürpriz hata azalır.

1. (1) Hedef dillerin envanteri: tr-TR, en-US, en-GB gibi dil/ülke kombinasyonlarını netleştirin; hangi sayfa türlerinin (oda/kanal/profil) çevrileceğini belirleyin.
2. (2) URL planı: /tr/ ve /en/ gibi klasör yapısı mı kullanacaksınız, yoksa alt alan adı mı? Dinamik oda sayfasında sabit ID (roomKey) + dil bazlı slug kuralını yazın.
3. (3) Hreflang üretimi: Her varyant sayfasında eksiksiz alternate seti döndürün; x-default kuralını ekleyin.
4. (4) Canonical üretimi: Her dil varyantı için canonical’i o dil varyantına işaret edecek şekilde kurun; query string ve redirect senaryolarında canonical çakışmasını önleyin.
5. (5) Test: crawler/caching etkilerini kontrol edin; Search Console ve loglar üzerinden botların hangi URL’leri gördüğünü doğrulayın.

Yaygın hatalar: hreflang çakışmaları, eksik dil, yanlış ülke kodu ve x-default eksikliği

En sık görülen sorunlardan biri hreflang çakışmasıdır. Örneğin tr-TR sayfasında en-US var ama en-US sayfasında tr-TR yoksa arama motoru varyantlar arasında tutarsız davranabilir. Sohbet sitelerinde bu durum, “bazı sayfalar SSR, bazıları CSR” gibi farklı render stratejileri yüzünden de oluşabilir.

Bir diğer hata yanlış ülke kodu kullanımıdır. “en-US” yerine “en-us” gibi hatalar veya iki farklı kodlamanın aynı dil varyantına bağlanması hreflang’ın anlamını kaybettirebilir. Aynı şekilde x-default eklemeyi unutmak, özellikle Accept-Language yönlendirmesi yaptığınız durumlarda botların beklenmeyen varyanta düşmesine sebep olabilir.

Self-referential (kendi kendini referanslamayan veya yanlış set döndüren) durumlar da risklidir. Örneğin oda sayfasında hreflang doğru sanılıp canonical tekilleştirme nedeniyle dil varyantı tek dile düşebilir. Bu nedenle canonical-hreflang birlikte ele alınmalıdır.

Nasıl kontrol edilir? Yayına almadan önce adım adım doğrulama (kontrol listesi)

hreflang/URL/slug stratejisinin çalıştığını doğrulamak için aşağıdaki kontrol listesi pratikte işe yarar. Arama motoru davranışı gecikmeli olabilir; bu yüzden hem statik doğrulama hem canlı gözlem kullanın.

1. Sayfa bazlı doğrulama: Her dil varyantının HTML’inde hreflang ve canonical etiketlerini sayfa kaynağından inceleyin; set eksik mi, URL’ler doğru mu?
2. Hreflang tutarlılık testi: Aynı oda için tr-TR → en-US ↔ en-GB gibi karşılıklı referansların “tam set” olduğundan emin olun. Kod üretimi yapan şablonlarda kaç varyant geçtiğini kontrol edin.
3. Search Console / tarama gözlemi: URL Denetimi ile “canonical seçimi”nin sizin istediğiniz varyanta oturup oturmadığını kontrol edin; ayrıca loglarda botların hangi URL’i çağırdığını görün.
4. Redirect ve SPA senaryosu: Dil değişimi bir HTTP redirect mi, yoksa JS ile mi? Dil tespitinde Accept-Language botları hedef dil klasörüne doğru yönlendiriyor mu?

Yayına almadan önce teknik kontrol listesi (sohbet sitesi özel)

Sohbet sitelerinde “yayına alındı” sonrası en çok bozulan kısım URL üretim pipeline’ıdır. Oda/kanal oluşturma süreçlerinde çeviri/slug üretimi gecikmeli veya hatalı başlıyorsa, hreflang seti yanlış URL’lere bağlanabilir. Bu yüzden ekiplerle birlikte bir “yayın öncesi” kontrol günü planlayın.

• Oda/kanal sayfası şablonu: SSR ile ilk yüklemede hreflang ve canonical üretiliyor mu?
• Dinamik slug üretim kuralı: roomKey sabit mi, dil bazlı slug çevirisi deterministik mi?
• Indexleme kısıtları: arama sonuçları/filtre sayfaları için robots/canonical davranışı tanımlı mı?
• Sitemap: dil varyantları içeride mi, çıkmış URL’ler hreflang’da kalıyor mu?
• Çerez/dil tercihi: botlar için nasıl davranıyor? x-default’a düşüş oranı ölçülüyor mu?

Örnek: Yanlış canonical yüzünden dil varyantlarının tek dile düşmesi ve doğru çözüm

Diyelim ki TR oda sayfanız doğru hreflang setini döndürüyor ama canonical üretimi “varsayılan dil” mantığıyla EN URL’sini basıyor. Bu durumda Google, TR sayfasını “alternatif değil kopya” gibi değerlendirebilir. Özellikle sohbet sitelerinde içerik benzerliği yüksek olduğundan (oda ID aynı, mesajlar geçişken) canonical yanlışlığı daha görünür hale gelir.

Çözüm: canonical üretimini dil varyantı farkındalığıyla güncelleyin. Eğer URL dil klasörü değişiyorsa canonical de o dile göre güncellenmeli. Ek olarak 301/302 yönlendirmeler varsa, redirect sonrası gelen HTML’de canonical tekrar kontrol edilmelidir. Bu tür hataları azaltmak için sohbet sitenizde parametreli URL/canonical stratejisinin nasıl kurulduğunu da gözden geçirmenizi öneririm: Chat Sitelerinde Parametreli URL’ler (Query String) İçin Canonical Nasıl Ayarlanır? | SEO Rehberi.

Benzer konularda derinleşme: crawl, log ve dinamik görünürlük

hreflang/slug yönetimi tek başına yeterli olmayabilir; sohbet siteleri çok sayıda dinamik URL ürettiği için crawl davranışı da belirleyici olur. Bu nedenle dil varyantlarının indexlenip indexlenmediğini doğrulamak için server log analizi veya crawler gözlemleri yapmak iyi bir tamamlayıcıdır.

Özellikle “hangi sayfalar Google/Bot tarıyor?” sorusunun cevabı, hreflang’ın pratikte çalışıp çalışmadığını gösterir. Bu bakış açısıyla şu rehber yardımcı olabilir: Sohbet Sitesi SEO İçin Server Log Analizi: Hangi Sayfalar Google/Bot Tarıyor? (Adım Adım Rehber).

Dinamik içerik ve kullanıcı akışında yeni sayfalar oluşurken, duplicate riskini de kontrol etmek gerekir. Eğer oda adı/slug varyantları (ör. aynı oda için farklı yazımlar) üretmeyi bırakamıyorsanız, SEO sinyalleri dağılabilir. Bunun için: Sohbet Odalarında Duplicate Content Nasıl Önlenir? (Oda Adı/Slug Varyasyonları İçin SEO Rehberi) önerilir.

FAQ: Sohbet sitelerinde çok dilli hreflang ve slug yönetimi

Hreflang’da dil mi ülke mi kullanmalıyım? (tr-TR vs tr) nasıl karar verilir?

Hedeflediğiniz kullanıcı deneyimi “ülke bazında” farklılaşıyorsa (mevzuat, yerel kullanım, tarih/para formatı, içerik tonu) dil-ülke kombinasyonu daha iyi sinyal verir. Sadece genel dil aynıysa “tr” gibi dil hedefi yeterli olabilir. Sohbet sitelerinde topluluk dilinin ülkeden çok konuşur yapıya dayandığı durumlarda dil hedefi kullanmak daha doğru sonuç verebilir.

x-default ne zaman gerekir, sohbet sitelerinde hangi sayfalara konur?

x-default, dil/ülke eşleşmesi olmayan kullanıcılar için varsayılanı belirtir. Dil seçici ve otomatik tespit (Accept-Language) kullanıyorsanız, botlar eşleşme bulamadığında doğru ana sürüme gitmeleri için x-default eklemek faydalıdır. Genelde “ana dil veya varsayılan landing” sayfalarına yönlendirilir; tüm varyant setlerinde aynı mantığı korumak önemlidir.

Slug’ları birebir çevirmeli miyim yoksa transliterasyon mu yapmalıyım?

Oda/kanal sayfalarında kimliği sabit tutmak kadar “anlamlı ve bulunabilir” slug üretmek de önemlidir. Tam çeviri bazı dillerde daha doğal olabilir, transliterasyon ise tutarlılığı artırır. Pratikte hibrit yaklaşım sık kullanılır: sabit kelime parçalarını çevir, kimliği taşıyan kısmı (roomKey/ID) sabit bırak, gerekiyorsa transliterasyonla URL uzunluğunu kontrol et.

Dinamik oda/kanal sayfalarında hreflang nasıl yönetilir?

Dinamik sayfada hreflang üretimi oda/roomKey ile entegre olmalı. Her dile göre üretilen URL’ler için alternate set otomatik basılmalı ve her varyant kendi canonical’iyle tutarlı olmalıdır. Ayrıca arama sonuçları veya filtre sayfalarında varyant patlamasını engellemek için indeksleme kurallarını netleştirin.

Kullanıcı dil tercihi (Accept-Language) SEO’yu nasıl etkiler, yönlendirme yapmalı mıyım?

Accept-Language doğru çalışırsa kullanıcıyı doğru dil sayfasına götürür; yanlış çalışırsa botların yanlış varyanta düşmesine yol açabilir. SEO uyumu için yönlendirmeyi mümkünse server-side yapın. Ayrıca bot trafiği için de davranışı ölçün; gerekirse x-default’a düşüş oranlarını loglardan inceleyin.

Sitemap’te dil varyantlarını nasıl göstermeliyim?

Genellikle her dil için ayrı sitemap veya tek sitemap içinde tüm dil URL’leri yer alır. Kritik olan: sitemap’e eklenen URL’ler hreflang setiyle uyumlu olmalı ve kaldırılan URL’ler hreflang’da kalmamalı. Dinamik sayfalarda indekslenecek seti sınırlamak crawl bütçesini korur.

Hreflang hatalarını nasıl tespit ederim? (Search Console / loglar / crawler testleri)

Search Console’daki URL Denetimi ile canonical/hreflang görünürlüğünü inceleyin. Ardından server loglarda botların hangi dil varyantına gittiğini gözlemleyin. Ek olarak crawler testleriyle farklı dil/ülke UA veya Accept-Language senaryolarında doğru HTML’in döndüğünü doğrulayın.

Canonical ile hreflang çakışırsa ne olur, nasıl düzeltilir?

Canonical çakışması, dil varyantlarının tek dile “toplanmasına” neden olabilir; bu da TR/en gibi varyantların arama sonuçlarında görünmemesine yol açar. Düzeltme için her varyantın canonical’inin kendi URL’ine işaret ettiğini doğrulayın ve redirect sonrası üretilen HTML’i tekrar kontrol edin. Ardından hreflang setinin eksiksiz olduğundan emin olun.

Kapanış: Sohbet sitenizde hreflang + slug yönetimi nasıl kalıcı avantaj olur?

Çok dilli sohbet sitelerinde hreflang ve slug yönetimi, indeksleme kalitesini ve doğru dil gösterimini doğrudan etkiler. Doğru URL mimarisi (klasör/alt alan adı), deterministik slug üretimi (oda ID + dil bazlı slug), eksiksiz hreflang seti ve canonical tutarlılığı bir araya geldiğinde duplicate riskleri azalır.

En önemlisi, bu stratejiyi “sadece etiket eklemek” olarak değil; dinamik sayfalar, SPA/SSR davranışı, yönlendirme ve sitemap keşfiyle bütünleşik bir sistem olarak kurmaktır. Böyle yaptığınızda ekipleriniz yeni dil varyantları eklerken aynı kuralları tekrarlar, hataları erken yakalar ve uzun vadeli büyüme hedeflerine daha güvenle yürür.