Yeni bir dil eklemek, ilk çok dilli kurulumdan farklı bir risk profili taşır. Sıfırdan başlayan bir projede hreflang kümesi, URL yapısı ve canonical mantığı henüz indekslenmemiş bir zemin üzerine kurulur; hata payı vardır ama sonuçları görece izole kalır. Mevcut, trafik alan ve zaten indekslenmiş bir siteye yeni bir dil eklerken durum değişir: elinizde çalışan bir sistem vardır ve bu sistemin tüm dil sürümlerinde aynı anda değişiklik yapmanız gerekir. Yeni dilin hreflang kümesine dahil edilmesi, sadece yeni sayfaları etkilemez; sitedeki her mevcut sayfanın <head> bölümü veya sitemap girişi güncellenmek zorundadır.
Bu güncelleme genellikle iki şekilde ihmal edilir. Birincisi, yeni dil sayfaları yayına alınır ama eski sayfalara karşılıklı referans eklenmez; bu durumda yeni dil kendi hreflang setini doğru kursa da eski sayfalar ondan habersiz kalır ve no return tag hatası üretir. İkincisi, çeviri süreci tamamlanmadan hreflang etiketleri tüm sayfalara toptan eklenir; henüz çevrilmemiş sayfalar için var olmayan URL'lere işaret eden kırık bağlantılar oluşur. İkisi de aynı kökten gelir: yeni dil ekleme, tek seferlik bir yayın değil, kapsamı ve sırası önceden planlanmış bir geçiş sürecidir.
Aşağıdaki sıra, bu geçişi kararların doğru zamanda verildiği, mevcut yapının bozulmadığı ve doğrulamanın atlanmadığı bir akışa oturtmak için kullanılabilir.
Yeni dil eklenmeden önce hangi kararlar zaten netleşmiş olmalı?
İlk adım kod yazmadan önce gelir. Dil kodu seçimi bunlardan biridir: yeni pazar tek bir ülkeye özgü değilse de gibi sade bir dil kodu yeterli olabilir, ama İngilizce gibi birden fazla ülke varyantı barındıran bir dil ekleniyorsa en-US, en-GB gibi bölge kodu gerekip gerekmediği netleşmelidir. Bu ayrım dil ve bölge kodu seçiminin BCP 47 mantığı ile aynı çerçevede değerlendirilir; sonradan kod değiştirmek, zaten yayınlanmış bir hreflang kümesini yeniden yazmak anlamına gelir.
İkinci karar URL yapısıdır. Mevcut dil sürümleri alt dizin kullanıyorsa (/en/, /de/) yeni dilin de aynı örüntüyü izlemesi zorunludur; URL yapısı burada iki ayrı mantığı aynı sitede barındırmamalıdır. Farklı bir yapı seçmek, tek sitede iki ayrı URL mantığı çalıştırmak demektir ve bu durum hem geliştirme tarafında hem de hreflang üretim kodunda özel durum işlemesi gerektirir. Alt domain veya farklı ccTLD gibi köklü bir değişiklik isteniyorsa bu, yeni dil ekleme kapsamının dışına çıkar ve ayrı bir migrasyon projesi olarak ele alınmalıdır.
Üçüncü karar kapsamdır: yeni dil tüm site için mi açılacak, yoksa önce belirli bir bölüm için pilot mu yapılacak? Büyük kataloglara veya yüzlerce sayfaya sahip sitelerde tüm içeriği aynı anda çevirmek nadiren gerçekçidir. Pilot kapsam seçimi, sonraki adımdaki önceliklendirmeyi doğrudan belirler.
Yeni dilin başlangıç kapsamı: hangi sayfalar önce çevrilir?
Yeni bir dil eklerken en sık yapılan hata, çeviri sırasını rastgele veya alfabetik ilerletmektir. Oysa öncelik, hangi sayfaların önce çevrilmesi gerektiğine dair genel öncelik mantığıyla aynı ilkeleri izler: yeni pazarda arama hacmi taşıyan sayfalar, dönüşüm yolundaki kritik sayfalar (ürün, fiyatlandırma, iletişim) ve sitenin ana giriş noktaları önce ele alınır. Blog arşivinin tamamını ilk günde çevirmeye çalışmak, kaynağı yanlış yere harcamaktır.
Kapsam kısmi kaldığı sürece hreflang üretimi de kısmi olmalıdır. Henüz çevrilmemiş bir sayfa için yeni dile ait bir hreflang girişi eklenmemelidir; bu, var olmayan bir URL'ye işaret eden bir etiket üretir ve Google bu tür kırık referansları hreflang kümesinin güvenilirliğini değerlendirirken not eder. Doğru model, her sayfa için o sayfanın gerçekten hangi dillerde mevcut olduğunu kaynağında (CMS alanı, içerik koleksiyonu, veri tabanı bayrağı) takip etmek ve hreflang setini bu kayda göre üretmektir. Sayfa çevrildiğinde otomatik olarak sete girer, çevrilmediği sürece dışarıda kalır.
Yeni dil için ilk yayın dalgasına girecek sayfalar belirlenirken şu kontrol sırası izlenebilir:
- Ana sayfa ve üst seviye kategori sayfaları
- Yeni pazarda gerçek arama talebi olan ürün veya hizmet sayfaları
- Dönüşüm için kritik statik sayfalar: iletişim, fiyatlandırma, hakkında
- Yasal ve güven sinyali taşıyan sayfalar: gizlilik politikası, kullanım şartları
- Geri kalan içerik, trafik ve talep verisine göre kademeli olarak eklenir
Kısmi kapsamla başlamak, hreflang setinin her aşamada tutarlı kalmasını kolaylaştırır; tüm siteyi bir gecede çevirip yayınlamak yerine, her dalga kendi içinde doğrulanabilir küçük bir birim olarak ele alınır.
Mevcut hreflang kümesi yeni dille nasıl genişletilir?
Bu adım, sürecin en fazla ihmal edilen kısmıdır çünkü dikkat neredeyse her zaman yeni sayfalara odaklanır, eski sayfalar unutulur. Yeni dil eklendiğinde, o dilde bir karşılığı bulunan her mevcut sayfanın hreflang kümesine yeni bir giriş eklenmesi gerekir. Türkçe ve İngilizce sürümü olan bir sayfaya Almanca eklendiğinde, hem Almanca sayfa Türkçe ve İngilizce'ye işaret etmeli hem de Türkçe ve İngilizce sayfalar geriye dönüp Almanca'ya işaret etmelidir. Karşılıklı referans kuralı yeni dil için de aynı sıkılıkta geçerlidir.
Statik HTML ile çalışan sitelerde bu, önceden yayınlanmış her dosyanın elle veya toplu bir betikle güncellenmesi anlamına gelir. Sayfa sayısı arttıkça bu güncelleme elle yönetilemez hale gelir; merkezi bir veri kaynağından (örneğin bu sitedeki articles.json benzeri bir yapı) hreflang bloğunun otomatik üretilmesi, her yeni dil eklendiğinde tek bir noktadan güncelleme yapmayı sağlar. Merkezi kaynak yoksa, yeni dil eklenen her seferde tüm mevcut sayfalar manuel bir tarama listesine girer.
x-default değeri de bu aşamada yeniden değerlendirilmelidir. x-default'un hangi URL'yi göstermesi gerektiği genellikle değişmez; site için varsayılan dil sabit kaldığı sürece x-default o dilin URL'sinde sabitlenir. Ancak bazı projelerde yeni dil, kaynak dilin yerini almak üzere ekleniyorsa (örneğin İngilizce artık ana dil olacaksa) x-default da bu değişikliğe göre yeniden atanmalıdır; bu nadir ama gözden kaçtığında büyük etkisi olan bir karardır.
URL yapısı ve routing: yeni dil mevcut sisteme nasıl entegre olur?
Routing katmanı, kullanılan platforma göre farklı davranır ama ortak bir soru her zaman sorulmalıdır: yeni dil eklendiğinde, mevcut dillerin URL davranışı bozuluyor mu? Bazı CMS ve framework'lerde yeni bir locale eklemek, varsayılan dilin URL önekini de değiştirebilir (örneğin önek almayan varsayılan dil, yeni dil eklenince otomatik olarak önek almaya başlayabilir). Bu tür bir değişiklik, mevcut ve indekslenmiş URL'lerin aniden 404 vermesine veya yeni bir adrese taşınmasına yol açar; bu durumda yönlendirme planı yeni dil ekleme projesinin kapsamına dahil edilmek zorundadır.
Dil değiştirici (language switcher) bileşeni de bu aşamada güncellenir. Yeni dil menüye eklendiğinde, bileşenin her sayfada gerçekten var olan çevirilere göre bağlantı üretip üretmediği kontrol edilmelidir. Sabit bir dil listesi menüye kodlanmışsa ve bu liste henüz çevirisi olmayan sayfalarda da görünüyorsa, kullanıcı tıkladığında 404 ile karşılaşır; bu, kısmi kapsamla ilerleyen projelerde sık görülen bir kullanıcı deneyimi hatasıdır ve dolaylı olarak sinyal kalitesini de etkiler.
Sitemap, robots.txt ve canonical: yeni dil eklenince neler güncellenir?
Sitemap, hreflang kümesiyle aynı mantıkla genişler. Sitemap içinde hreflang ilişkilerinin taşındığı bir yapı kullanılıyorsa, yeni dilin URL'leri hem kendi giriş olarak hem de mevcut girişlerin alternate listesine eklenmelidir. Sitemap tek dilli URL listesi olarak tutuluyorsa, yeni dilin sayfalarını ayrı bir blok halinde eklemek yeterlidir; lastmod değerleri gerçek yayın tarihini yansıtır.
robots.txt yapılandırması genellikle yeni dil eklenince değişmez, çünkü kurallar dil öneki bazlı değil yol örüntüsü bazlı yazılmışsa yeni dil otomatik olarak aynı kurallara tabi olur. Ancak dil bazlı özel bir disallow kuralı varsa (örneğin belirli bir dilin yönetici veya önizleme yollarını engelleyen bir kural), bu kuralın yeni dil için de tekrarlanıp tekrarlanmayacağı kontrol edilmelidir.
Canonical kararı en sabit kalan katmandır: self-referencing canonical kuralı yeni dil için de aynı şekilde uygulanır, yeni dilin her sayfası kendi URL'sini canonical olarak gösterir. Buradaki risk canonical'ın kendisinde değil, canonical ile hreflang setinin birbirini doğrulayıp doğrulamadığındadır; hreflang setinde referans verilen bir URL, o sayfanın kendi canonical'ıyla eşleşmiyorsa çelişki oluşur ve bu çelişki genellikle yeni dil ekleme sürecinde acele edilen kod değişikliklerinden kaynaklanır.
Yayın öncesi ve sonrası doğrulama sırası
Yeni dil canlıya çıkmadan önce, en azından temsili bir örneklem üzerinde şu kontroller yapılmalıdır: yeni dilin sayfalarında hreflang seti eksiksiz mi, mevcut dillerin sayfalarında yeni dile referans gerçekten eklenmiş mi, canonical ve hreflang birbiriyle çelişmiyor mu, sitemap yeni URL'leri kapsıyor mu. Bu kontrol adımları hreflang hatalarının sistematik tespiti için izlenen protokolle aynıdır, tek farkı burada kontrolün odağı yalnızca yeni eklenen dile ve onun karşılıklı referanslarına daralmıştır.
Yayın sonrasında beklenen zaman çizelgesi gerçekçi kurulmalıdır. Yeni dilin sayfaları Google tarafından keşfedilip taranması, ardından indekslenmesi günler sürebilir; bu normal bir gecikmedir, hata değildir. Bu dönemde hangi dil versiyonunun indekslendiğini, hangisinin henüz indekslenmediğini görmek için Search Console'un Kapsam raporu ve site: operatörü birlikte kullanılır. İlk iki-üç hafta boyunca yeni dilin indeksleme oranı düzenli izlenmeli; oran beklenenden düşükse önce hreflang karşılıklı referansı, sonra sitemap kapsamı, sonra içerik kalitesi eşiği sırasıyla kontrol edilir.
Yeni dil eklemek tek seferlik bir teknik görev değildir; mevcut sistemin her katmanını (hreflang, sitemap, routing, canonical) aynı anda bir adım genişletme işlemidir. Sıra doğru kurulduğunda genişleme mevcut dil sürümlerinin performansını bozmadan ilerler; sıra atlandığında ise sorun yeni dilin kendi sayfalarında değil, ona hazırlıksız bırakılan eski sayfalarda ortaya çıkar.