301 yönlendirmesi, tek dilli bir sitede nispeten basit bir karardır: eski URL kalıcı olarak yenisine aktarılır, link değeri büyük ölçüde korunur. Çok dilli bir sitede ise bu karar anında daha fazla boyut kazanır. Yönlendirilen URL'nin hreflang kümesindeki yeri, x-default değeriyle ilişkisi, zincirin kaç adım uzadığı ve hangi dil sürümlerini etkilediği — bunların hepsi ayrı ayrı değerlendirilmesi gereken noktalardır.
Sorun çoğunlukla yapısal değişimlerde değil, küçük kararların birikmesinde ortaya çıkar. Bir dil sürümü kaldırıldığında redirect hedefinin nereye kurulacağı, birkaç ay içinde tekrar değişen bir URL için zincirin nasıl uzayacağı ya da sunucu katmanında yapılan dil tespitinin 301 kuralıyla çakışması — bunlar tek başına yönetilebilir görünen ama birleşince ciddi tarama maliyeti ve sinyal kaybı üreten hatalardır.
301 stratejisini çok dilli bağlamda ele almak, yönlendirmenin yalnızca kaynak URL'den hedef URL'ye teknik bir geçiş olduğunu değil; aynı zamanda dil kümesinin bütünlüğünü, link otoritesinin dağılımını ve Googlebot'un farklı dil sürümlerine ulaşma biçimini etkileyen bir karar olduğunu kabul etmek anlamına gelir.
Çok dilli mimaride 301'in üstlendiği farklı roller
Tek dilli sitede 301 kullanım senaryoları sınırlıdır: silinmiş içerik, yeniden adlandırılmış URL, domain değişikliği. Çok dilli bir sitede bu liste büyür ve her senaryo farklı bir yönlendirme kararını zorunlu kılar.
İlk senaryo URL yapısı değişikliğidir. Alt dizin yapısından subdomain'e geçiş, dil kodunun URL'de taşındığı yerin değişmesi ya da slug'ların yerelleştirilmesi — bu değişikliklerin her biri onlarca ya da yüzlerce URL için bir redirect tablosu gerektirir. Bu tablonun dil bazında ayrı tutulması, hem hata takibini hem de hreflang güncellemesini kolaylaştırır.
İkinci senaryo dil sürümünün silinmesidir. Bir dil artık desteklenmeyecekse, o dil altındaki URL'lerin nereye yönleneceği kararı verilmeden bu sürümün kaldırılması 404'lerin birikmesine ve link değeri kaybına yol açar. Üçüncü senaryo içerik birleştirmesidir: iki farklı URL tek bir sayfada toplandığında, eski URL'lerin eşleştirilmesi ve hreflang kümesinin güncellenmesi eş zamanlı yürütülmelidir.
Son olarak platform göçleri sırasında URL şemalarının değişmesi vardır. Bir CMS değişikliği ya da yeni bir e-ticaret altyapısına geçiş sırasında dil URL'lerinin eski yapıdan yeniye birebir eşleştirilmesi, "tüm eski URL'leri ana sayfaya yönlendir" çözümüne kıyasla önemli ölçüde daha fazla link değeri ve organik görünürlük korur. Bu sürecin ayrıntıları için çok dilli site taşıma rehberine başvurulabilir.
Hreflang etiketi olan bir URL yönlendirildiğinde ne olur?
Bu, pratikte en çok karıştırılan noktalardan biridir. Hreflang kümesinde hedef olarak işaret edilen bir URL 301 ile başka bir URL'ye yönlendirilirse, Google bu yönlendirmeyi takip eder — ancak bunun küme içinde nasıl yorumlandığı garanti değildir.
Teknik olarak bakıldığında: Google, yönlendirilen URL'yi bir süre hreflang hedefi olarak işlemeye devam edebilir. Yönlendirmenin hedefindeki yeni URL'yi otomatik olarak küme üyesi olarak kabul etmez. Bu durum, eski URL'nin hreflang etiketlerinde hâlâ referans verilmesi durumunda bir tutarsızlık üretir ve zamanla kümenin çözümlenmesini güçleştirir.
Doğru sıra şudur: 301 uygulanmadan önce ya da en kısa sürede, o dil sürümünü işaret eden tüm hreflang etiketleri güncellenir. Hangi sayfaların bu URL'ye referans verdiği bilinmiyorsa, bir tarama aracıyla hreflang kaynakları tespit edilmeli ve toplu güncelleme planlanmalıdır. Yönlendirme ve etiket güncellemesini "önce redirect, sonra etiket" sırasıyla değil; mümkünse eş zamanlı ya da "önce etiket, sonra redirect" sırasıyla yapmak daha güvenlidir.
Bir hreflang kümesi, her dil sürümünün diğerini karşılıklı olarak işaret etmesini gerektirir. Bir URL yönlendirildiğinde bu karşılıklı referans zinciri kırılmış olur. Kırık etiketler, hreflang etiketinin temel çalışma mantığına aykırıdır ve arama motorunun kümeyi doğru yorumlamasını engeller.
Dil sürümü kaldırıldığında redirect hedefi nasıl belirlenir?
Bir dil sürümünü kalıcı olarak kaldırmak, o sürüm altındaki tüm URL'ler için bir yönlendirme kararı gerektirir. İki ana seçenek vardır ve her ikisinin farklı avantajları ile risk alanları bulunur.
Birinci seçenek: aynı içeriğin başka bir dil sürümüne yönlendirmek. Örneğin Katalanca sürüm kaldırılacaksa /ca/urun-sayfasi → /es/pagina-producto şeklinde bir yönlendirme kurulabilir. Bu yaklaşım, kullanıcının içerikle ilgili bir alternatife ulaşmasını sağlar; ancak dil uyumsuzluğu yaratır. Google'ın bu yönlendirmeyi içerik eşdeğeri olarak yorumlamayabileceği de göz önünde bulundurulmalıdır.
İkinci seçenek: ana sayfaya ya da o dildeki en üst düzey kategoriye yönlendirmek. Daha temiz bir sinyal üretir; "bu sayfa artık bu dilde mevcut değil" mesajını doğrudan iletir. Dezavantajı, belirli bir sayfayı arayan kullanıcıyı ya da botu doğrudan hedef içeriğe götürmemesidir. Hangi seçeneğin tercih edileceği büyük ölçüde o dil sürümünün trafik geçmişine ve silinmesinin nedenine bağlıdır.
Pratikte en yaygın hata şudur: kaldırılan dil sürümü 301 yerine 404 olarak bırakılır. Hem 410 (Gone) hem de iyi kurulmuş bir 301, Googlebot'un bu URL'leri tekrar tekrar taramasını önler. 404 bırakan siteler ise bu URL'leri tarama bütçesinden boşa harcamaya devam eder. Kaldırılan dil sürümünün sitemap'ten çıkarılması ve o sürümü işaret eden hreflang etiketlerinin silinmesi de aynı adımın parçasıdır; bunlar atlanırsa teknik tutarsızlık devam eder.
Zincir yönlendirme neden çok dilli ölçekte daha büyük risk taşır?
Tek dilli bir sitede A → B zinciri yönetilebilir bir sorundur. Çok dilli bir sitede aynı zincir çoğalır: A_en → B_en, A_de → B_de, A_fr → B_fr şeklinde her dil sürümü için ayrı bir zincir oluşur. Eğer B sürümleri de sonradan C'ye yönlendirildiyse, her dil için iki adımlı bir zincir anlamına gelir. Beş dilli bir sitede bu, on ayrı redirect adımı demektir.
Google, çok adımlı yönlendirmeleri takip eder; ancak zincir uzadıkça link değeri transferinin eksiksiz gerçekleşip gerçekleşmediği konusundaki belirsizlik artar. Çok dilli sitelerde bu belirsizlik her dil sürümü için ayrı ayrı geçerlidir ve toplam etkisi sınırlı bir siteye kıyasla çok daha büyüktür.
Pratik kural şudur: aynı URL için iki yönlendirme biriktiğinde — örneğin migration sırasında eski bir redirect üstüne yeni bir URL değişikliği eklendiğinde — zincir kısaltılmalı ve A doğrudan C'ye yönlendirilmelidir. Bunu her dil sürümü için ayrı ayrı yapmak zahmetli görünebilir; ancak bu bakım adımının atlanması, zamanla tarama verimliliğini ve link otoritesini etkiler. Otomatik yönlendirme kaynaklı sorunların izlenmesiyle bu zincir tespiti paralel yürütülmelidir.
x-default URL'si değiştiğinde yönlendirme ve etiket kararları
x-default, coğrafi ya da dil eşleşmesi olmayan kullanıcılar için belirlenen yedek URL'dir. Çoğu durumda bu URL site genelindeki İngilizce sürüm ya da bir dil seçim sayfasıdır. x-default değerinin ne anlama geldiği konusunda netlik olmadan bu yönlendirme kararını vermek güçleşir.
x-default olarak kullanılan URL değiştiğinde iki şey aynı anda güncellenmelidir: önce 301 yönlendirmesi kurulur, ardından tüm sayfaların hreflang kümesindeki hreflang="x-default" etiketi yeni URL'yi işaret edecek şekilde değiştirilir. Sıralamayı tersine çevirmek — önce etiketi güncelleyip redirect'i sonraya bırakmak — kısa bir süre için kullanıcıları var olmayan bir URL'ye yönlendiren kırık bir referans üretebilir.
Büyük sitelerde x-default etiketi yüzlerce sayfada bulunabilir. Bu etiketlerin şablon veya CMS düzeyinde merkezi olarak yönetilmediği durumlarda, eski x-default URL'si onlarca sayfada kalmaya devam eder ve yönlendirme ile hreflang arasında kalıcı bir tutarsızlık üretir. Bu tutarsızlığı tespit etmenin en hızlı yolu, hreflang etiketlerini tarama aracıyla toplu çekmek ve x-default değerlerini ayrı bir listede gruplandırmaktır.
Bir de şu durum var: x-default URL'si bazen dil seçim sayfası değil, doğrudan bir içerik sayfasıdır. Bu URL kaldırıldığında ya da yeniden adlandırıldığında, redirect hedefinin de x-default rolünü üstlenecek nitelikte bir sayfa olması gerekir. Rastgele seçilen bir dil sürümüne yönlendirilen x-default, kullanıcı deneyimi açısından beklenmedik sonuçlar üretebilir.
Hangi katmanda yönetilmeli: sunucu, CDN, CMS
301 yönlendirmelerinin nerede tanımlandığı, çok dilli sitelerde özellikle önemlidir. Her katmanın farklı avantajları ve sınırlılıkları vardır.
Sunucu katmanı (Nginx, Apache .htaccess) en hızlı tepkiyi verir çünkü yönlendirme CMS veya uygulama katmanına ulaşmadan gerçekleşir. Büyük hacimli URL değişikliklerini sunucu kuralları üzerinden yönetmek operasyonel açıdan verimlidir. Ancak kurallar büyüdükçe yönetimi zorlaşır ve bir dil sürümü için yazılan kural başka bir dil sürümünün URL'siyle çakışabilir. Kural sırası hatalı yazıldığında beklenmedik yönlendirmeler oluşabilir; bu nedenle büyük kural setlerinin düzenli olarak gözden geçirilmesi gerekir.
CDN düzeyinde yönlendirme (Cloudflare, Fastly vb.) giderek yaygınlaşıyor. Coğrafi dağılım ve düşük gecikme süresi avantaj sağlar; ancak yapılandırmanın teknik ekip dışındaki kişiler tarafından yönetilmesi güçtür. Büyük çok dilli e-ticaret sitelerinde CDN düzeyindeki redirect kurallarının CMS redirect tablosundakilerle çakışması, sık karşılaşılan sorun kaynaklarından biridir.
CMS düzeyinde yönetim daha az teknik bilgi gerektirir; içerik ekibinin kendi yetki alanında kalır. Ancak ölçek arttıkça yetersiz kalır: yüzlerce URL'yi CMS arayüzü üzerinden takip etmek hem yavaştır hem de hata payı yüksektir. Sunucu tarafı yönlendirmelerin SEO üzerindeki etkisini kavramayan ekipler, zaman zaman CMS redirect'ini sunucu kuralının üstüne yazar ve iki katmanlı bir zincir üretir.
Tercih edilebilir yaklaşım şudur: sık değişmeyen, kalıcı nitelikteki yönlendirmeler sunucu ya da CDN katmanında tutulur; içerik bazlı, sık güncellenen yönlendirmeler CMS düzeyinde yönetilir. Bu ayrım, her iki dünyanın avantajlarından yararlanırken katmanlar arası çakışma riskini minimize eder.
Çok dilli sitelerde 301 stratejisi, her dil sürümünü bağımsız bir varlık olarak değil; birbiriyle ilişkili bir küme içindeki bileşen olarak ele almak gerektirir. Bir URL'yi yönlendirmek, o dil sürümünün hreflang kümesiyle ilişkisini ve diğer sürümlerle olan bağlantısını otomatik olarak güncellemez. Bu güncelleme, yönlendirme kararıyla birlikte ayrıca planlanmalıdır.
Teknik SEO denetimlerinde çok dilli redirect'lerin ayrı bir kontrol kalemi olarak incelenmesi, zincir birikimini ve hreflang tutarsızlıklarını erkenden tespit etmenin en sistematik yoludur. Taşıma dönemlerinde yoğunlaşan bu incelemenin, site kararlı bir şekilde yayında olduğu süreçlerde de düzenli aralıklarla tekrarlanması faydalıdır.
301 kararlarını sonradan düzeltmek mümkündür; ancak zincirlerin kısaltılması, etiketlerin temizlenmesi ve tutarsızlıkların giderilmesi her seferinde ek zaman ve dikkat ister. Başlangıçta yapılan doğru bir kararın değeri, özellikle dil sayısı arttıkça katlanır.