Tek Dilli'den Çok Dilli Yapıya Geçiş: URL, Hreflang ve Yayın Öncesi Checklist

Tek dilli siteden çok dilli yapıya geçişi temsil eden editoryal blog görseli

Tek dilli bir siteyi çok dilli yapıya taşımak, sıfırdan çok dilli site kurmaktan farklı bir süreçtir. Ortada zaten var olan URL'ler, birikmekte olan sıralamalar, arama motorlarının öğrendiği site yapısı ve bazen yıllarca emek verilmiş içerik katmanları vardır. Tüm bunlar devreye girdiğinde geçiş, salt teknik bir kurulum değil; mevcut birikimi koruyarak yeni yapıyı üzerine inşa etme işi haline gelir.

Bu geçişin SEO'yu olumsuz etkilemesinin en temel nedeni aceledir. Yeni dil klasörleri henüz yarım haldeyken canlıya alınır, hreflang karşılıklı referanslar eksik kurulur, redirect planı yapılmadan URL yapısı değiştirilir. Bu hataların her biri ayrı ayrı onarılabilir ama hepsi bir arada gerçekleştiğinde tablonun toparlanması aylar alabilir.

İyi haber şu ki geçiş sürecinin kritik adımları önceden tanımlanabilir. Hangi kararın ne zaman verilmesi gerektiğini, hangi teknik bloğun önce kurulacağını ve yayından önce neyin doğrulanacağını bilmek, süreci tahmin edilebilir kılar. Aşağıdaki adımlar bu sırayla kurgulanmıştır.

Geçişe başlamadan önce netleşmesi gereken kararlar

Teknik kuruluma geçmeden önce cevaplanması gereken üç soru vardır. Hangisi pazara açılıyoruz? Bu sorunun yanıtı URL yapısını, hreflang scope'unu ve içerik önceliklendirmesini doğrudan etkiler. Tek bir ülke için Almanca mı açıyoruz, yoksa birden fazla ülkede birden fazla dil mi hedefliyoruz? İkisi arasındaki fark büyüktür.

İkinci soru: mevcut içerik gerçekten yerelleştirilebilir mi? Bazı sektörlerde ana dil içeriği hedef pazara aynen aktarılabilir; bazılarında ürün isimleri, fiyatlandırma mantığı, hatta kullanıcı beklentisi köklü biçimde farklıdır. Çeviri mi yapacaksınız, yerelleştirme mi? Bu karar içerik hacmini, üretim süresini ve dolayısıyla geçiş takvimini belirler.

Üçüncüsü: mevcut teknik altyapı çok dilli yapıyı kaldırabilir mi? Bazı CMS platformlarında çok dilli destek sonradan eklenen bir eklentiye sıkıştırılır ve URL yapısı üzerinde sınırlı kontrol sağlar. Platformun kısıtlarını geçişten önce görmek, yarı yolda sürprizle karşılaşmayı önler. Geçişe başlamadan mevcut sitenin teknik durumunu net görmek için bir site analiz aracıyla hız, indekslenme ve temel SEO sinyallerini gözden geçirmek, hangi sorunların çok dilli yapıya taşınmaması gerektiğini baştan ortaya koyar.

URL yapısı seçimi: geçiş sırasında verilmesi gereken en kritik karar

Alt dizin, alt domain ve ccTLD arasındaki seçim geçişten önce kesinleşmelidir. Çünkü bu karar sonradan değiştirildiğinde siteyi bir kez daha geçirmek anlamına gelir; yeni redirect planı, yeni sitemap, yeni hreflang haritası. Alt dizin ile alt domain arasındaki farkı ve her birinin pratikte nasıl davrandığını anlamak, bu kararı sağlam zemine oturtur.

Çoğu durumda alt dizin yapısı (/de/, /fr/, /es/) tercih edilir; çünkü mevcut domain otoritesi yeni dil versiyonlarına aktarılır, teknik yönetim tek çatı altında kalır. Alt domain yolu ise belirli durumlarda mantıklı olabilir: platform kısıtları bunu zorunlu kılıyorsa ya da dil sürümleri birbirinden çok farklı içerik yapısına sahipse.

Geçiş sırasında en sık yapılan hata URL yapısını içerik hazırlığından önce canlıya almaktır. Boş ya da yarım haldeki dil klasörleri arama motorlarının taramasına açılırsa, ince içerik sinyalleri oluşur. Doğrusu, dil klasörünü yalnızca o pazara ait içerik gerçekten hazır olduğunda yayına almaktır. Kademeli geçiş bu yüzden ani geçişten daha az risklidir.

Mevcut içeriğin geçiş haritası: ne tutulur, ne uyarlanır, ne yeniden yazılır

Tek dilli sitedeki her sayfa çok dilli yapıda eşdeğerine kavuşmak zorunda değildir. Özellikle büyük içerik katalogları söz konusu olduğunda önceliklendirme şarttır. Hangi sayfalar en çok organik trafik üretiyor? Hangi sayfalar dönüşüm hunisinin kritik noktalarında duruyor? Bu iki soru öncelik sırasını belirler.

İçerik türüne göre de ayrım yapmak gerekir. Ürün sayfaları, fiyatlandırma ve destek içerikleri genellikle yerelleştirme gerektirir; yalnızca dil değil, para birimi, ölçü birimi ve yerel referanslar da değişebilir. Blog içerikleri ise bazı durumlarda doğrudan çeviriyle işe yarar, bazılarında hedef pazarın arama niyetine göre yeniden yazılması gerekir. Yerelleştirme ile çeviri arasındaki ayrımı işin başında belirlemek, hem kaynak planlamasını hem de içerik kalitesini doğrudan etkiler.

Makine çevirisi bu noktada yaygın bir kısayol olarak öne çıkar. Hız açısından cazip görünür ama arama motorları kalitesiz çeviriden üretilen sayfaları düşük değerli içerik olarak işleyebilir. Geçiş sırasında makine çevirisini ham halde canlıya almak yerine, en azından yüksek öncelikli sayfaların insan gözünden geçirilmesi uzun vadede daha güvenli bir başlangıç noktası oluşturur.

Hreflang kurulumunda geçiş dönemine özgü hatalar

Hreflang kurulumu geçiş sürecinde normalden daha karmaşık bir hal alır. Çünkü ana dil sayfaları canlıda hâlâ çalışırken yeni dil sayfaları hazırlanmaktadır ve ikisi bir anda hreflang ilişkisiyle bağlanmaya çalışılır. Bu durumda en sık karşılaşılan sorun karşılıklı referans eksikliğidir: Türkçe sayfa Almanca versiyonuna işaret eder, ama Almanca sayfa henüz Türkçeye karşılıklı işaret etmez. Hreflang etiketinin nasıl çalıştığını ve karşılıklı referans zorunluluğunu anlamak, bu hatayı geçişin başında önler.

Geçiş sırasında hreflang'ı staging ortamında kurmak ve tüm dil çiftlerini orada doğrulamak en güvenli yoldur. Staging'de URL set'leri tam mı, canonical çatışması var mı, x-default tanımlı mı — bunların hepsi canlıya geçmeden önce kontrol edilmelidir. Canlı ortamda hreflang hataları hemen fark edilmeyebilir; ancak haftalar içinde belirli pazarlarda beklenen görünürlük artışı gelmediğinde sorunun kaynağını bulmak zorlaşır.

Bir de kapsam kararı vardır: x-default hangi sayfaya işaret edecek? Geçiş sırasında ana dil sayfası x-default olarak kalabilir ya da dil seçim sayfası tanımlanabilir. Bu karar önemsiz görünür ama coğrafi hedefleme belirsizliğinde arama motorunun hangi sürümü kime göstereceğini etkiler.

Redirect ve canonical planı: eski yapıdan yeni yapıya köprü

Eğer geçiş URL yapısını değiştiriyorsa — örneğin /urun/canta → /tr/urun/canta dönüşümü yapılıyorsa — 301 redirect planı olmadan geçiş ciddi sıralama kaybına yol açar. Mevcut sayfaların link birikimi ve sayfa otoritesi taşınmak isteniyor. Redirect zincirinden kaçınmak da bu noktada önemlidir: A → B → C yerine A doğrudan C'ye gitmelidir. Çok dilli yapıda 301 yönlendirme stratejisinin nasıl kurulacağını önceden planlamak, geçiş sonrası toparlanma süresini kısaltır.

Canonical etiketleri de geçişte güncellenmesi gereken kritik bir bileşendir. Eski URL yapısında tanımlanmış canonical'lar yeni URL'lere güncellenmezse çatışma oluşur: sayfa bir URL'yi canonical ilan ederken başka bir redirect zinciri farklı bir hedef gösterir. Arama motorları bu durumu çözümlemekte zorlanabilir ve tercih edilen sayfayı indekslemek yerine bekletme moduna geçebilir.

Redirect planını bir tablo olarak tutmak ve her satırda kaynak URL, hedef URL ve yönlendirme tipi bilgilerini netleştirmek en temiz yoldur. Bu tablo hem geliştirici ekibi için bir uygulama rehberi hem de yayın sonrası doğrulama için başvuru noktası işlevi görür.

Yayın öncesi doğrulama: geçişi onaylamadan önce kontrol noktaları

Yayından önce yapılması gereken kontroller iki katmanda okunabilir: teknik bütünlük ve içerik hazırlığı. Teknik bütünlük katmanında şunların tamamı hazır olmalıdır: tüm dil sürümleri için hreflang set'leri karşılıklı olarak doğru, canonical'lar güncel ve çatışmasız, sitemap yeni URL yapısını yansıtıyor ve gerekiyorsa dil bazlı sitemap dosyaları ayrı tanımlanmış. Robots.txt yeni klasörleri engellemiyor mu? Bu soru özellikle staging ortamından canlıya geçerken sıklıkla gözden kaçar.

İçerik hazırlığı katmanında ise şu soruyu sormak yeterlidir: canlıya alınacak dil versiyonunda kaç sayfa gerçekten hazır, kaçı eksik ya da çok kısa? Yarım haldeki sayfaları noindex ile etiketleyip içerik tamamlandığında açmak, ince içerik sorununu baştan engeller. Teknik SEO denetim listesini bir referans olarak kullanmak bu süreçte hızlı bir çapraz kontrol sağlar.

Google Search Console'a yeni dil versiyonlarını property olarak eklemek de geçiş gününün görevleri arasındadır. Hem dizine alınma sürecini izlemek hem de olası kapsama sorunlarını erken görmek için bu adım ertelenmemelidir. Yayından sonraki ilk iki hafta teknik sinyaller hızla okunabilir; hreflang hataları, yönlendirme sorunları ve indekslenme dışı kalan sayfalar bu pencerede fark edilir ve düzeltilebilir.

Kademeli geçiş neden ani geçişten daha güvenlidir?

Tüm dil sürümlerini aynı anda yayına almak yerine önce bir ya da iki dili test etmek, olası hataların etkisini sınırlar. İlk dil versiyonundaki teknik kurulum deneyimi sonraki dilleri daha hızlı ve daha az hatayla yayına almayı sağlar.

Tek dilli siteden çok dilli yapıya geçiş, doğru sıralandığında yönetilebilir bir süreçtir. Kararlar önceden verilmiş, teknik kurulum aşama aşama test edilmiş ve yayın öncesi kontrol listesi tamamlanmışsa geçiş günü sürpriz üretmez. Esas risk, bu adımların sırası bozulduğunda ya da biri atlandığında başlar.

İlk dil geçişinde kurulan yapı aynı zamanda sonraki diller için bir şablon işlevi görür. URL kararı alınmış, hreflang mantığı oturmuş, redirect süreci belgelenmiş bir yapıya ikinci dili eklemek birincisini eklemekten çok daha hızlıdır. Bu yüzden ilk geçişe yatırılan dikkat, uzun vadede katlanarak geri döner.

Geçiş sonrası ilk birkaç hafta sessiz geçebilir. Yeni dil sayfaları henüz taranmamıştır, sıralamalar oluşmamıştır. Bu bekleme döneminde teknik sinyalleri izlemek — indekslenme hızı, hreflang doğrulaması, yönlendirme tutarlılığı — erken müdahale fırsatı verir. Sıralama sonuçlarını değerlendirmek için ise genellikle birkaç ay beklemek gerekir.