Wix'te çok dilli bir mağaza veya kurumsal site kurmak, kod yazmadan dakikalar içinde ikinci bir dil versiyonu açabilmek anlamına geliyor. Bu hız, platformun en güçlü satış argümanı. Ama aynı otomasyon, teknik SEO tarafında geliştiricinin normalde elle kontrol ettiği birkaç kritik noktayı da platformun kendi mantığına devrediyor.
Sorun burada başlıyor. Wix Multilingual, hreflang etiketlerini kendi başına üretiyor ve bu üretim sürecine müdahale alanı sınırlı. URL yapısı, canonical davranışı ve dil geçişlerinin crawl edilebilirliği büyük ölçüde platformun varsayılan kararlarına bağlı kalıyor. Bu, birçok senaryoda sorun çıkarmıyor; ama katalog büyüdüğünde veya pazar sayısı arttığında görünmeyen kısıtlar öne çıkıyor.
Wix'in çok dilli mimarisi bazı katmanları kendi başına kapatıyor, bazılarını kapatamıyor. Boşluk kaldığında Velo ile yama üretmek mümkün; ama yama, platformun varsayılanının yerini tutacak bir altyapı değil.
Wix Multilingual dil versiyonlarını nasıl üretiyor?
Wix Multilingual, kaynak dildeki her sayfayı otomatik olarak kopyalayıp çeviri katmanına bağlıyor. Editördeki dil değiştirme menüsü, aslında arka planda ayrı bir URL kümesi oluşturuyor; siz sayfa yapısını bir kez tasarlıyorsunuz, platform bunu her dil için tekrar üretiyor. Yapısal tutarlılık burada bir avantaj: kategori hiyerarşisi, navigasyon ve şablon her dil versiyonunda birebir aynı kalıyor.
Ancak bu otomasyonun bir maliyeti var. Sayfa yapısını dil bazında farklılaştırmak, örneğin bir pazarda ekstra bir bölüm eklemek veya farklı bir CTA göstermek, editör düzeyinde mümkün olsa da, bu değişiklik dil versiyonları arasında senkron bir yapıyı bozuyor ve platformun hreflang eşleştirmesi bu durumda beklenmedik biçimde davranabiliyor. Wix'in dokümantasyonu bu senaryoyu açıkça uyarmıyor; deneyerek öğrenilen bir sınır.
Çeviri kaynağı da önemli bir ayrım noktası. Otomatik çeviri motoruyla üretilen içerik ile elle girilen çeviri arasında Wix'in kendi arayüzünde görsel bir fark yok; ikisi de aynı sayfa yapısında görünüyor. Bu, editoryal kalite kontrolünü zorlaştırıyor çünkü hangi sayfaların gözden geçirilmiş, hangilerinin ham çeviri olarak kaldığını takip etmek manuel bir sürece dönüşüyor.
Bu takip sorununu büyüten bir başka etken, çeviri durumunun sayfa listesinde görünür bir statü olarak sunulmaması. WordPress'te WPML gibi eklentiler her sayfanın çeviri yüzdesini panelde gösterirken, Wix'te bu bilgi dolaylı; her sayfayı tek tek açıp kontrol etmek gerekiyor. Elli sayfalık bir kataloğa on dil eklendiğinde bu, pratikte yüzlerce manuel kontrol noktası anlamına geliyor. Ekipler genellikle bu kontrolü atlıyor ve yayına giden çeviri kalitesi fark edilmeden düşük kalıyor.
Hreflang üretimi otomatik, ama ne kadar güvenilir?
Wix, dil versiyonu yayına alındığı anda hreflang etiketlerini kendiliğinden HTML head'e ekliyor. Bu, manuel hreflang yönetiminin getirdiği en yaygın hatayı, karşılıklı referans eksikliğini, büyük ölçüde ortadan kaldırıyor. Bir dil versiyonu var olduğu sürece diğer tüm versiyonlar birbirini işaretliyor.
Ancak burada bir gecikme sorunu var. Yeni bir dil versiyonu yayınlandığında veya bir sayfa güncellendiğinde, hreflang setinin tüm sayfalara yansıması anında gerçekleşmiyor. Yayın sonrası birkaç saat içinde eski ve yeni hreflang kümesinin karışık göründüğü durumlar bildiriliyor. Search Console'da bu, geçici "no return tag" uyarıları olarak ortaya çıkabiliyor; genellikle kendiliğinden düzeliyor, ama no return tag hatasının kalıcı olduğu senaryolarda geçerli olan kontrol adımları burada da işe yarıyor.
Daha ciddi bir sınır: x-default değeri. Wix, birincil dil versiyonunu otomatik olarak x-default atıyor ve bu atamayı değiştirmenin arayüzde doğrudan bir yolu yok. Kaynak dil pazarlama açısından ideal karşılama sayfası olmayabilir; örneğin bir marka Türkçe kaynak dilden başlamış ama asıl büyüme İngilizce pazarında gerçekleşiyorsa, x-default'un hangi versiyona gitmesi gerektiği konusunda platform tercih hakkı bırakmıyor.
Sayfa silindiğinde veya çevirisi kaldırıldığında hreflang setinin güncellenmesi de otomatik, ancak bu güncelleme sitemap'e yansımadan önce bir gecikme yaşayabiliyor. Büyük katalogda bu, geçici olarak ölü URL'lere işaret eden hreflang girdileri anlamına geliyor.
Bir başka gözden kaçan nokta, bölüm bazlı içerik bloklarının hreflang kapsamının dışında kalması. Wix'te bazı sayfa öğeleri (özellikle uygulama market entegrasyonlarıyla eklenen widget'lar) kendi içerik yönetimini platformdan bağımsız yürütüyor. Bu widget'ların ürettiği metin, sayfanın ana hreflang setine dahil olmuyor; arama motoru sayfanın gövdesini bir dilde, widget içeriğini başka bir dilde görebiliyor. Bu, özellikle üçüncü parti yorum, değerlendirme veya rezervasyon uygulamalarında karşılaşılan bir sorun ve platform seviyesinde bir çözümü yok; widget seçerken çok dilli desteği olup olmadığını ayrıca sorgulamak gerekiyor.
URL yapısında seçim özgürlüğü ne kadar geniş?
Wix, dil versiyonları için üç format sunuyor: alt dizin (/tr/, /en/), subdomain (tr.site.com) veya parametre tabanlı yapı. Kurulum sırasında bu seçim yapılıyor ve sonradan değiştirmek yeni bir migrasyon süreci gerektiriyor; platform bu geçişi otomatikleştirmiyor.
Alt dizin yapısı SEO açısından genellikle daha güçlü kabul ediliyor çünkü otorite tek alan adında birikiyor. Ancak Wix'in alt dizin implementasyonunda dil kodu her zaman ISO standardına birebir uymuyor; bazı bölgesel varyantlar (örneğin pt-br yerine sadece pt) platformun kendi kısaltma mantığına göre atanıyor. Bu, dil ve bölge kodu ayrımının önemli olduğu pazarlarda ek bir kontrol gerektiriyor.
Slug çevirisi de kısmi. Sayfa URL'sinin son parçası çevrilebiliyor, ancak kategori üstü klasör yapısı (örneğin /urunler/ kelimesinin kendisi) çoğu paket seviyesinde çevrilemiyor; sabit kalıyor. Bu, tam yerelleştirilmiş bir URL bekleyen pazarlarda okunabilirlik açısından bir eksiklik oluşturuyor, ama hreflang ve canonical mantığını bozmuyor; sadece kullanıcı deneyimi sınırlı kalıyor.
Dil seçici bileşeninin konumu da SEO'yu dolaylı etkiliyor. Wix'in varsayılan dil seçicisi genellikle sayfa üst bandında sabit bir dropdown olarak geliyor ve bu bileşen tüm sayfalarda otomatik yerleşiyor. Görünürde bir sorun değil, ama seçicinin ürettiği linklerin rel="alternate" olmadan düz metin linki gibi davranması, tarama motorunun bu geçişleri hreflang setinden bağımsız bir sinyal olarak okumasına yol açabiliyor. Pratikte bu, çoğunlukla hreflang'ı geçersiz kılmıyor, ama dil seçici tasarımının SEO'ya etkisini değerlendiren bir denetimde bu detayın ayrıca not edilmesi gerekiyor.
SEO panelinde dil bazlı meta ve canonical kısıtları
Wix SEO paneli, her dil versiyonu için ayrı başlık ve açıklama girmeye izin veriyor; bu kısım beklendiği gibi çalışıyor. Sorun, canonical etiketinin davranışında. Varsayılan olarak her dil versiyonu kendini canonical gösteriyor, bu doğru bir başlangıç noktası. Ancak bir sayfa henüz çevrilmemişse ve kaynak dildeki içerik gösteriliyorsa, bazı Wix şablonlarında bu geçici sayfa kaynak URL'yi canonical yapmak yerine kendini canonical gösterebiliyor; bu durumda arama motoru aynı içeriği iki farklı URL'de yetkili sayabiliyor.
Yapısal veri tarafında da benzer bir sınır var. Wix'in otomatik ürettiği schema çıktısı (ürün, makale, organizasyon) dil versiyonuna göre alan bazında yerelleşiyor, ama inLanguage değeri her zaman doğru atanmıyor; bazı şablon güncellemelerinde bu alanın kaynak dilde sabit kaldığı bildiriliyor. Büyük bir SEO riski değil, ama denetim sırasında gözden kaçan bir detay.
Robots.txt ve sitemap üretimi tamamen platform kontrolünde; manuel düzenleme imkanı yok. Bu, dil bazlı taramayı kısıtlamak isteyen (örneğin bir dil versiyonunu geçici olarak noindex yapmak isteyen) sitelerde ayrı bir çözüm gerektiriyor; sayfa düzeyinde noindex meta etiketi eklenebiliyor ama toplu bir dil versiyonu kapatma seçeneği arayüzde yok.
Sitemap'in kendisi de dil versiyonlarını tek bir dosyada mı yoksa ayrı dosyalarda mı sunacağı konusunda seçim hakkı bırakmıyor; Wix bunu otomatik belirliyor ve ölçek büyüdüğünde bu tek dosya yapısı büyük kataloglarda beklenen boyut sınırlarına yaklaşabiliyor. Uluslararası sitemap hazırlarken önerilen segmentasyon esnekliği burada platformun kararına bağlı kalıyor; geliştirici müdahale edemiyor.
Velo ve özel kod ile açık bırakılan boşluklar doldurulabilir mi?
Wix'in geliştirici katmanı Velo, header koduna özel script enjekte etmeye izin veriyor. Bu, platformun otomatik ürettiği hreflang setini tamamlamak veya düzeltmek için sınırlı bir kapı açıyor. Örneğin x-default değerinin platform tarafından yanlış atandığı durumlarda, sayfa yükleme sırasında JavaScript ile ek bir link rel="alternate" etiketi enjekte etmek teknik olarak mümkün; ancak bu, statik HTML head'de değil DOM'da oluştuğu için Googlebot'un render aşamasına kadar görünmüyor. Yüksek trafikli sayfalarda risk kabul edilebilir seviyede, ama toplu bir düzeltme stratejisi olarak güvenilir değil.
Canonical düzeltmesi için de benzer bir yol var. Velo ile sayfa yüklenmeden önce canonical URL'yi programatik olarak set etmek mümkün, fakat bu müdahale her sayfa şablonuna ayrı ayrı uygulanmalı ve Wix'in kendi otomatik canonical mantığıyla çakışma riski taşıyor. Pratikte bu yöntem, birkaç kritik sayfada nokta atışı düzeltme için kullanılabilir; site genelinde bir SEO altyapısı kurmak için değil.
Header koduna özel meta etiket ekleme de mümkün ama Wix'in kendi ürettiği meta etiketleriyle çakıştığında hangisinin öncelikli olacağı garanti edilmiyor; bazı durumlarda tarayıcı ilk gördüğü etiketi, bazı durumlarda sonuncusunu işliyor. Bu tutarsızlık, özel kod çözümlerini "dene ve gözle doğrula" seviyesinde tutuyor.
Velo üzerinden Wix Data koleksiyonlarını kullanarak dil bazlı özel alanlar oluşturmak, meta içerik tarafında biraz daha güvenilir sonuç veriyor. Örneğin schema markup'ın inLanguage alanını platformun otomatik değerine güvenmek yerine, her sayfa için bir veri koleksiyonundan çekip dinamik olarak enjekte etmek mümkün. Bu yaklaşım, tek seferlik bir kurulum gerektirse de sonrasında ölçeklenebilir bir çözüm sunuyor; onlarca sayfaya tek tek dokunmak yerine koleksiyon güncellenerek tüm sayfalar aynı anda düzeltiliyor. Ancak bu, Velo'ya ve temel veritabanı mantığına aşinalık gerektiriyor; kod yazmadan platform kullanmak isteyen ekipler için pratik bir seçenek olmuyor.
Wix ne zaman yetersiz kalır: geçiş kararının eşiği
Küçük ölçekli, iki veya üç dil versiyonu olan bir site için Wix Multilingual'in otomatik hreflang üretimi, manuel hataların önüne geçtiği için aslında güvenli bir başlangıç noktası sunuyor. Sorun ölçekle birlikte büyüyor: dil sayısı beşi geçtiğinde, pazar bazlı içerik farklılaşması gerektiğinde veya canonical/x-default üzerinde ince ayar ihtiyacı doğduğunda platformun esneklik sınırı belirginleşiyor.
E-ticaret kataloglarında bu eşik daha erken geliyor. Ürün varyantı, stok durumu ve fiyat bilgisinin dil versiyonları arasında bağımsız davranması gerektiği senaryolarda, WooCommerce'in ürün ve kategori yönetiminde sunduğu granüler kontrol, Wix'in şablon tabanlı çoğaltma mantığıyla kıyaslandığında daha fazla karar alanı bırakıyor.
Ajans veya freelancer tarafında sık görülen bir hata, müşteriyi Wix'te tutmanın kolaylığına bakarak teknik SEO kısıtlarını göz ardı etmek. Küçük bir yerel işletme için bu risk kabul edilebilir; iki dilde birkaç sayfa yönetmek platformun sınırlarını zorlamıyor. Ama uluslararası büyüme hedefleyen bir marka için erken aşamada platform seçimini gözden geçirmemek, birkaç yıl sonra tüm site mimarisini yeniden kurmak anlamına gelebiliyor. Hreflang hatalarının sistematik olarak tespit edildiği bir denetim sürecinde, platform kısıtından kaynaklanan hataların düzeltilemez olduğu fark edildiğinde bu karar zaten gecikmiş oluyor.
Karar noktası basit bir soruya indirgenebilir: SEO ekibinin hreflang, canonical veya URL yapısı üzerinde platformun varsayılanının dışına çıkması gereken bir ihtiyacı var mı? Cevap hayırsa Wix'in otomasyonu zaman kazandırıyor. Cevap evetse, Velo üzerinden yama çözümleri üretmek yerine, büyüme planının bu kısıtları önceden hesaba katan bir platforma taşınmayı içerip içermediğini değerlendirmek gerekiyor.
Bu değerlendirme çoğu zaman erken yapılmıyor; site büyüdükten, dil sayısı arttıktan sonra fark ediliyor. Platform seçimini pazar stratejisinden önce değil, pazar stratejisiyle birlikte gözden geçirmek, sonradan taşıma maliyetini önemli ölçüde düşürüyor.
Taşıma kararı verildiğinde asıl zorluk, yeni platformun kod tarafı değil, mevcut hreflang ve indeksleme geçmişinin korunması. Wix'ten ayrılan bir site, eski URL yapısını yeni platformda birebir koruyabiliyorsa geçiş nispeten sorunsuz oluyor; ancak URL şeması değişiyorsa (alt dizinden subdomain'e veya tam tersi), her dil versiyonu için ayrı bir yönlendirme haritası çıkarmak gerekiyor. Bu haritanın eksik veya yanlış kurulduğu taşımalarda, geçiş sonrası birkaç ay boyunca dil versiyonlarının indeks kaybı yaşadığı görülüyor. Kayıp genellikle geri dönüşü zaman alan bir süreç: eski görünürlük seviyesine ulaşmak üç ile altı ay arasında sürebiliyor.