Çok dilli sitelerde URL kararı çoğu zaman son aşamada konuşulur. Oysa tam tersi çok daha sağlıklı. URL yapısı sadece bir adres değil; dil sürümlerinin nasıl ayrıştığını, içeriklerin nasıl eşleştiğini ve kullanıcıların dil değiştirirken nereden nereye geçtiğini belirleyen bir omurga.
Rastgele seçilmiş klasör adları mı var? Tutarsız slug mantığı? Bir dilde yerelleştirilmiş ama diğer dilde çevrilmemiş adresler? Bunlar büyüdükçe bakım kabusu yaratır.
Küçük sitede tolere edersiniz. Yüzlerce sayfa olunca görünürlük ve ekip verimi çöker.
URL neden sadece teknik ayrıntı değildir?
Kullanıcı arama sonucunda URL'yi görür. Paylaşım yapan ekip adresi kopyalar. Analitik tarafı desen üzerinden rapor çıkarır. Geliştirici yönlendirmeleri bu mantığa göre yazar.
URL, sitenin görünen omurgası.
Çok dilli yapılarda bu omurga net değilse içerik operasyonu gevşer, ekip kafa karışır, kullanıcı yanlış sayfaya düşer. Ayrı dil sürümleri için farklı adres kullanmak temel ilke. Aynı URL üzerinde dinamik dil değiştirme mi? Çerez bazlı çıktı mı? Yalnızca açılır menü ile içerik çevirmek mi? Hiçbiri net sinyal üretmez.
Önce adres düzeni kurulur, sonra tasarım ayrıntıları eklenir. Uluslararası SEO çerçevesi ile bakıldığında URL yapısı, pazarlara açılmanın ilk somut teknik izi sayılabilir.
Dil kodu, ülke kodu ve slug dili nasıl seçilir?
İlk karar: adres içinde dil kodunu nasıl göstereceksiniz? En yaygın yaklaşım dil ya da dil-bölge kodlarını üst klasör olarak kullanmak: /tr/, /en/, /en-gb/ gibi. Hem taranabilir hem raporlanabilir.
İkinci karar slug dili. Pek çok ekip tüm dillerde İngilizce slug kullanarak sadelik sağlamaya çalışır. Mümkün; fakat her zaman en iyi kullanıcı deneyimi anlamına gelmez. Yerelleştirilmiş slug daha doğal okuma sunar. Ana ölçüt tutarlılık. Bir bölümde yerel dil kullanıp diğer bölümde rastgele İngilizceye dönmek karmaşa yaratır.
/tr/cok-dilli-site-nasil-kurulur
/en/how-to-build-a-multilingual-site
/de/mehrsprachige-website-aufbauen
Bu örnekte yapı okunabilir, eşleşebilir ve ekip tarafından yönetilebilir görünür. Karışıklık ne zaman başlar? Aynı kümeyi bazen çevrilmiş bazen çevrilmemiş sluglarla kurmaya çalışınca.
Yerel karakterler, UTF-8 ve okunabilirlik dengesi
Türkçe, Almanca, Fransızca ya da Arapça içeriklerde adres içindeki karakter kullanımı sık tartışılır. Teknik olarak güncel web standartları ve arama motorları yerel karakterleri işler. Ama kullanıcı paylaşımı? CMS yapısı? Log takibi? Ekip alışkanlıkları? Bunlar da göz önüne alınmalı.
Her projede aynı tercih rahat çalışmaz.
Türkçe'de ç, ğ, ı, ö, ş, ü gibi karakterleri slug içinde korumak teorik olarak mümkün olsa da bazı ekipler ASCII normalizasyonunu tercih eder. Önemli olan bir kural belirleyip tüm sitede aynı biçimde uygulamak. Kararın kendisinden çok tutarlılık etkili.
Kullanıcı tarafında okunabilirlik her zaman öncelikli. Uzun parametre dizileri mi var? Anlamsız sayı blokları mı? Dili belirsiz adres yapıları mı? Hiçbiri çok dilli görünürlüğe katkı sunmaz. Adres, içerik başlığının kaba ama anlaşılır bir izdüşümü olmalı.
Klasör düzeni ve içerik eşleştirme nasıl korunur?
Adres yapısında en sık bozulan alan derin sayfalar. Ana sayfada düzenli görünen yapı, kategori ve makale düzeyine inildiğinde dağılabilir.
Örnek mi? Türkçe blog yazıları /tr/blog/ altında iken İngilizce sürüm doğrudan /en/resources/ altında kurgulanıyor. Her zaman yanlış değil; ama eşleşme tablosu kurulmamışsa bakım zorlaşır, hreflang karışır, ekip şaşırır.
Kategori mantığı ve içerik tipleri daha başta sınıflandırılmalı. Ürün, blog, destek, yasal metin, iletişim, kampanya gibi başlıklar için tek şablonlu düzen kurmak ileride hız kazandırır. Kurulum yazısında anlatılan matris yaklaşımı adres tarafında da işe yarar.
İçerik eşleşmesi kaybolduğunda hreflang, canonical ve dil geçişi de bozulur. Adres standardı yalnız SEO ekibinin değil, içerik ve geliştirme ekibinin ortak sözlüğü olmalı.
Yönlendirme, canonical ve eski yapıdan geçiş planı
Mevcut bir siteyi çok dilli yapıya taşıyorsanız asıl risk geçiş döneminde. Eski adresler yeni dil klasörlerine yönlendirilecek, canonical ilişkileri güncellenecek ve iç bağlantılar yeni düzene göre yeniden yazılacak. Eğer bu geçiş parça parça yapılırsa yönlendirme zincirleri ve yanlış canonical atamaları hızla çoğalır.
Sağlıklı yaklaşım? Önce adres haritasını çıkarın.
Eski adresin yeni karşılığını net belirleyin. Ardından iç linkler, sitemap ve alternatif dil bağlantıları aynı planda güncelleyin. Sadece yönlendirme yazıp iç linkleri eski halde bırakmak, sitenin kendi içinde çelişkili kalmasına yol açar.
Özellikle dil seçici eklenirken otomatik ana sayfa yönlendirmelerine dikkat edin. Kullanıcı aynı içeriğin farklı dil sürümüne geçmek isterken bir anda kök sayfaya düşmemeli. Bu konu yönlendirme hataları yazısında daha ayrıntılı biçimde ele alınıyor.
İyi ve zayıf URL örnekleri
- İyi:
/tr/hreflang-nedir— kısa, okunabilir, dil sürümünü açık gösteriyor - İyi:
/en/multilingual-seo— içerik tipi ve dil net - Zayıf:
/page?id=17&lang=tr— okunabilirlik ve paylaşım kalitesi düşük - Zayıf:
/en/tr/de/blogpost-final-new— yapı mantığı belirsiz
İyi adres her zaman en kısa adres değil. En tutarlı, en anlaşılır ve en kolay sürdürülebilir adres daha değerli.
Kısa görünen ama ekip içinde sürekli açıklama isteyen yapı mı var? Pratikte iyi yapı değil.
Çok dilli sitelerde adres kararı tek başına başarı getirmez. Ama kötü adres kararı neredeyse her iyi işi yavaşlatır, ekibi yorar, kullanıcıyı şaşırtır. Erken verilmiş, belgelenmiş ve ekipçe benimsenmiş bir adres standardı ciddi avantaj sağlar.
Filtre sayfaları ve parametreler nasıl ele alınmalı?
Çok dilli yapılarda temel kategori ve içerik sayfaları düzenli kurgulansa bile filtre sayfaları yapıyı sessizce karmaşıklaştırabilir. Özellikle e-ticaret veya büyük kataloglu projelerde dil sürümleri üzerine eklenen parametreler, birbirine çok benzeyen adres kümeleri üretir.
Tarama bütçesi zorlanır. Raporlama karışır.
Filtre mantığı ile temel adres standardı birbirinden kopuk düşünülmemeli. Hangi parametre indekslenebilir? Hangisi yalnız kullanıcı deneyimi için kalacak? Hangi kombinasyon canonical ile sadeleştirilecek? Bu sorular baştan yanıtlanmalı. Aksi halde temiz görünen adres sistemi, derin katmanlarda hızla bulanıklaşır.
Blog ve rehber içeriklerinde bu sorun daha az görünür; fakat kategori ve listeleme sayfalarında belirginleşir. Çok dilli adres düzeni yalnız editorial sayfaları değil, tüm üretim mantığını kapsamalı.
Yerel slug kararı ekip içinde nasıl standardize edilir?
Yerel slug kullanımı tartışılırken çoğu ekip asıl soruyu atlar: Bu kararı kim verecek ve nasıl belgeye dökecek?
Bir editör yerel dilde daha doğal slug önerirken geliştirici ASCII standardını tercih edebilir. SEO uzmanı da kısa ve açıklayıcı yapıyı isteyebilir. Bu istekler çeliştiğinde sayfa sayfa farklı uygulamalar ortaya çıkar.
Çözüm? Küçük ama zorunlu bir slug rehberi oluşturun. Karakter normalizasyonu, stop-word yaklaşımı, sayı ve tarih kullanımı, kategori slug mantığı ve eski slug değişim süreci bu belgede yer almalı. Rehber kısa olabilir; ama bağlayıcı olmalı. Çünkü çok dilli sitelerde tutarsız slug, zamanla içerik eşleştirmesini de bozar.
İyi standardizasyon yaratıcılığı öldürmez. Yalnızca ekiplerin aynı dilde konuşmasını sağlar. Adres tarafında bu, beklenenden çok daha değerli bir avantaj.