Site taşımaları her zaman risklidir. Domain değişikliği, URL yapısının yeniden kurulması veya platform geçişi — bunların her biri tek dilli bir sitede bile dikkatli yönetilmezse ciddi sıralama kayıplarına yol açar. Çok dilli bir siteyi taşımak bu riski katlar: her dil sürümü için ayrı bir URL kümesi vardır, her kümenin ayrı redirect eşleştirmesi gerekir ve hreflang yapısının geçiş döneminde tutarlılığını koruması zorunludur.
Tek dilli bir taşımada yönetilen değişken sayısı bellidir: eski URL, yeni URL, redirect kodu, canonical güncelleme. Beş dil sürümüyle çalışan bir sitede aynı sayfa için yönetilmesi gereken değişken sayısı beşe çıkar; üstelik bu değişkenler birbirinden bağımsız değildir — hreflang kümeleri dil sürümlerini birbirine bağladığı için bir sürümdeki hata diğerlerini de etkiler. Bu karmaşıklığı önceden haritalamayanlar, taşıma tamamlandıktan haftalar sonra kayıpların nedenini anlamaya çalışır.
Planlama bu nedenle teknik çalışmanın kendisinden daha az önemli değildir. Redirect tablosu hazırlamak, hreflang geçişini aşamalandırmak ve doğrulama protokolünü önceden tanımlamak — bunlar taşıma günü değil, taşıma öncesinde yapılır. Ne kadar erken başlanırsa yayın günü sürprizlerle karşılaşma ihtimali o kadar azalır.
Tek dilli taşıma ile çok dilli taşımanın farkı nedir?
Tek dilli bir site taşımasında URL eşleştirme genellikle bire bir ilişkidir: eski adres yeni adrese yönlendirilir, liste kapatılır. Çok dilli taşımada bu ilişki çarpanlıdır. /products/shoes sayfası taşınıyorsa, aynı içeriğin /tr/urunler/ayakkabılar, /de/produkte/schuhe ve /fr/produits/chaussures karşılıklarının da taşınması gerekir. Her birinin yeni adresle eşleştirilmesi, her birinin redirect'inin doğru çalışması ve hreflang kümesinin yeni URL'leri yansıtacak şekilde güncellenmesi ayrı ayrı kontrol edilmesi gereken adımlardır.
Buna ek olarak, URL yapısı kararı taşıma sırasında sıkça revize edilir. Eski yapıda subdomain kullanılmış olabilir — tr.example.com, de.example.com — yeni yapıda alt dizin tercih ediliyor: example.com/tr/, example.com/de/. Bu yapısal değişim URL sayısını ikiye katlar: hem subdomain'den gelen eski URL'ler hem alt dizine giden yeni URL'ler eşleştirilmeli, hem de bu geçişin canonical ve hreflang katmanına yansıması koordine edilmelidir. Alt dizin ile subdomain arasındaki SEO farkları taşıma öncesinde değerlendirilmezse, taşıma yalnızca teknik bir operasyon değil aynı zamanda yapısal bir karar revizesi haline gelir — ve bu iki şeyi aynı anda yönetmek hata riskini artırır.
Çok dilli taşımayı en fazla zorlaştıran şey ise bağımlılık zinciridir. Türkçe sürüm için URL değişikliği yapıldığında, Türkçe sayfanın hreflang kümesindeki diğer diller de güncelleme bekler. Almanca sürümün hreflang etiketi hâlâ eski Türkçe URL'yi işaret ediyorsa karşılıklı referans bozulur; Google kümenin bütünlüğüne güvenemez. Bu domino etkisi, değişikliklerin eş zamanlı ve koordineli uygulanmasını zorunlu kılar.
URL envanteri: dil sürümleri için eşleşme tablosu
Taşıma öncesinde yapılacak en kritik hazırlık, tüm dil sürümlerinin URL envanterinin çıkarılmasıdır. Bu envanter yalnızca mevcut URL'lerin listesi değildir; her URL'nin hangi dil ve bölge sürümüne ait olduğunu, hangi hreflang kümesine dahil olduğunu ve taşımadan sonra hangi yeni adresle eşleşeceğini gösteren bir tablodur.
Pratikte bu tablo genellikle bir elektronik tabloda tutulur ve her satır bir URL'yi temsil eder. Sütunlar şunları içerir: mevcut URL, dil/bölge kodu, hreflang kümesi kimliği, yeni URL, redirect türü ve doğrulama durumu. Hreflang kümesi kimliği özellikle önemlidir: aynı içeriğin tüm dil sürümleri aynı küme kimliğiyle etiketlenir; bu sayede bir sürümde güncelleme yapıldığında diğer sürümlerin ne beklendiği görülür.
Envanter oluştururken sıkça karşılaşılan sorun, tüm URL'lerin bilinmemesidir. Eski sitede otomatik oluşturulmuş sayfalalar, filtre URL'leri veya dinamik parametreli adresler envanteri beklenenden büyük çıkarabilir. Tarama araçlarıyla yapılan kapsamlı bir crawl ve sitemap karşılaştırması bu farkı ortaya koyar. Bilinmeyen URL'leri içeren bir taşımada redirect tablosu eksik kalır; bu eksik, taşıma sonrasında kırık bağlantılar ve indeksleme kayıpları olarak geri döner.
Redirect zinciri ve tarama bütçesi: çok dilli ölçekte maliyet
Redirect'lerin teknik kalitesi çok dilli taşımalarda özellikle kritiktir. Temel kural basittir: her eski URL doğrudan yeni URL'ye 301 ile yönlendirilmeli, araya başka bir yönlendirme girmemelidir. Ama pratikte bu temizlik korunmaz; özellikle eski yapıda zaten redirect'ler varsa yeni taşıma üstüne eklenerek zincir oluşturur.
Redirect zinciri — A → B → C şeklinde iki veya daha fazla adımdan oluşan yönlendirme — her dil sürümü için ayrı bir sorun kaynağıdır. Googlebot zinciri takip eder ama her adım tarama bütçesinden pay alır. 5 dil sürümü ve 1.000 sayfa içeren bir sitede tüm dil sürümlerinde iki adımlı redirect zincirleri varsa, Googlebot her etkin tarama için iki kat daha fazla istek yapmak zorunda kalır. Uluslararası sitemap üzerinden doğrudan erişim sağlansa bile bu zincir tarama verimliliğini düşürür.
Redirect tablosunu hazırlarken her kaynak URL için son hedef doğrudan tanımlanmalıdır. Eski yapıda /tr/urunler/ → /tr/kategori/ → /tr/ayakkabilar/ şeklinde bir zincir varsa, yeni URL'ye geçişte bu zincir temizlenmeli ve doğrudan /tr/ayakkabilar/ → yeni adres şeklinde tek adıma indirilmelidir. Her redirect katmanını ayrı ayrı düzeltmek yerine taşıma anında sıfırlamak, uzun vadede hem tarama hem de link equity aktarımı açısından çok daha temiz bir başlangıç sağlar.
Geçiş döneminde hreflang nasıl kurulmalı?
Taşıma anında hreflang yönetimi iki farklı senaryodan birinde gerçekleşir: tüm dil sürümleri eş zamanlı taşınıyor ya da kademeli geçiş uygulanıyor. Her iki durumda da hreflang'ın tutarlılığını korumanın yolu farklıdır.
Eş zamanlı taşımada tüm URL'ler aynı anda yeni adreslerine taşınır, redirect'ler aktif edilir ve hreflang etiketleri yeni URL'lerle birlikte güncellenir. Bu yaklaşımın avantajı nettir: geçiş döneminde karma bir durum oluşmaz — ya tamamen eski yapı ya da tamamen yeni yapı çalışır. Dezavantajı, hata marjının geniş olmasıdır. Binlerce URL için eş zamanlı güncelleme yapıldığında küçük bir yapılandırma hatası büyük bir alanı etkiler; geri dönüş planı önceden hazırlanmış olmazsa müdahale gecikir.
Kademeli geçişte dil sürümleri sırayla taşınır — önce İngilizce, ardından Almanca, sonra diğerleri. Bu süreçte bir sorun ortaya çıkar: geçiş döneminde hreflang kümesi karma bir durumda kalır. İngilizce sayfalar yeni URL'lerde, Almanca sayfalar hâlâ eski URL'lerde. Hreflang'ın karşılıklı referans kuralı gereği, İngilizce sayfanın Almanca alternatifini eski URL üzerinden işaret etmesi gerekir — aksi hâlde küme bütünlüğü bozulur. Bu geçici uyumsuzluk kabul edilebilirdir; ama süre uzadıkça Google'ın küme hakkında güven oluşturması da gecikmeler. Kademeli geçiş mümkün olduğunca kısa tutulmalıdır: iki haftayı aşan geçiş dönemleri hreflang tutarsızlığını kalıcı bir sorun haline getirebilir.
Her iki senaryoda da taşıma öncesinde XML sitemap güncellemesi planlanmalıdır. Yeni URL'ler aktif edildiği anda sitemap'in de yeni adresleri yansıtması, Googlebot'un yeni yapıyı hızla keşfetmesi için en doğrudan sinyaldir. Teknik SEO denetim listesinde sitemap güncellemesi her zaman taşıma günü kontrol edilmesi gereken ilk maddeler arasındadır.
Kademeli mi, tam geçiş mi: dil sürümleri için taşıma sırası
Hangi dil sürümünün önce taşınacağı sorusu çoğu zaman teknik değil stratejik bir yanıt ister. Ama teknik kısıtlar da belirleyicidir.
Organik trafik hacmi açısından en büyük dil sürümünü en sona bırakmak, risk yönetimi açısından mantıklı görünebilir — ama bu yaklaşım hreflang bağımlılığı nedeniyle çoğu durumda tersine çalışır. Ana dil sürümü taşınmadan diğer sürümlerin hreflang kümeleri tamamlanmaz; küçük sürümlerin taşınması, büyük sürümün gecikmesi nedeniyle onların da karma bir durumda kalmasına yol açar.
Daha işlevsel bir sıralama mantığı içerik bağımsızlığını esas alır: hreflang kümelerinde birbirine en az bağımlı sürümler önce taşınır. Eğer bazı dil sürümleri yalnızca iki veya üç dille küme oluşturuyorsa, bu kümelerin tamamını bir arada taşımak mümkündür; ana dile bağımlı büyük kümeler ise ayrı bir yayın dalgasında ele alınabilir. Bu yaklaşım her dil sürümünü izole etmez; küme bazlı yönetim hem hreflang tutarlılığını hem de geri dönüş planının uygulanabilirliğini korur.
Büyük e-ticaret sitelerinde ürün sayfaları, kategori sayfaları ve içerik sayfaları farklı taşıma dalgalarında ele alınabilir. Ürün sayfaları en büyük URL kitlesini oluşturursa önce kategori sayfaları taşınıp doğrulanabilir; ürün sayfaları ikinci dalgada gelir. Bu aşamalandırma URL başına düşen hata riskini azaltır ve her dalgadan sonra doğrulama penceresi açar.
Taşıma sonrası doğrulama: neyin ne zaman kontrol edilmesi gerekiyor?
Taşıma yayınlandıktan sonra doğrulama üç aşamada yapılır: ilk 24–48 saat, birinci hafta ve birinci ay.
İlk 24–48 saat içinde öncelik redirect'lerin çalışıp çalışmadığıdır. Örnekleme yöntemiyle her dil sürümünden temsili URL'ler test edilir; 301 dönüp dönmediği, hedefin doğru olup olmadığı ve zincir oluşup oluşmadığı kontrol edilir. Aynı anda Search Console'da crawl hatalarının artıp artmadığına bakılır — 404 ve 500 hatalarında ani artış bir yapılandırma sorununa işaret eder. Hreflang kümelerinin kaynak kodunda doğru yazılıp yazılmadığı da bu aşamada örnekleme yöntemiyle kontrol edilir.
Birinci haftada odak indeksleme hızıdır. Google yeni URL'leri ne kadar hızlı keşsedip indekslemeye başladığı, Search Console'daki kapsam raporundan izlenir. Eski URL'lerin indeksten düşmesi redirect'lerin tanınmasının işaretidir; bu süreç birkaç gün ile birkaç hafta arasında değişebilir. Hreflang hata raporlarında geçiş dönemine özgü tutarsızlıklar bu haftada görünür hale gelir; karşılıklı referans hataları ve x-default eksiklikleri erken müdahale gerektiren sinyal olarak öne çıkar.
Birinci ayda sıralama performansı değerlendirilir. Taşıma sonrası geçici sıralama dalgalanmaları normaldir; birkaç hafta içinde istikrar beklenir. Dalgalanma devam ediyorsa ya redirect'lerde sorun vardır ya da hreflang kümelerinde henüz fark edilmemiş tutarsızlıklar bulunmaktadır. Bu noktada kapsamlı bir hreflang denetimi — her dil sürümü için küme bütünlüğünün URL bazında doğrulanması — taşıma kalitesini ölçmenin en güvenilir yoludur.
Çok dilli site taşıması, iyi planlandığında tahmin edilebilir bir operasyondur. Kötü planlandığında ise her dil sürümü ayrı bir sorun kaynağı haline gelir ve sorunlar birbirini tetikler. URL envanteri, redirect tablosu ve hreflang geçiş stratejisi — bu üç hazırlık taşıma günü değil taşıma öncesinde tamamlanmalıdır.
Taşımayı tamamladıktan sonra doğrulama sürecini kısaltmak cazip görünebilir; ama birinci hafta ve birinci ay kontrolleri atlandığında, sessiz kalan sorunlar organik trafikte aylarca süren düşüşlere dönüşebilir. Çok dilli bir yapıda bu düşüş tek bir pazarla sınırlı kalmaz — bir dil sürümündeki hata, hreflang bağlantısı üzerinden tüm kümeyi etkiler. Doğrulama protokolünü planlama aşamasında tasarlamak, taşıma sonrası müdahale maliyetini önemli ölçüde azaltır.