WooCommerce mağazasına WPML kurulup çeviriler girildikten ve hreflang etiketleri üretildikten sonra kurulum "tamamdır" görünümü veriyor. Dil değiştirici çalışıyor, ürün sayfaları dil bazında ayrışmış, sitemap'te her URL'nin iki sürümü de var. Birkaç hafta sonra Search Console'da tablo değişiyor: Almanca sayfaların bir kısmı indexlenmemiş, Fransız kullanıcıların önemli bir bölümü İngilizce canonical'a düşüyor, bazı kategori sayfaları hreflang döngüsü hatası veriyor. Kurulumun görünürdeki düzeni ile tarayıcı davranışı arasındaki bu makas, WooCommerce çok dilli yapısının standart bir WordPress blogdan neden çok daha fazla katman barındırdığını gösteriyor.
Standart sayfa çevirisi WooCommerce için sadece başlangıç. Ürün slug'ları, kategori hiyerarşisi, varyant isimleri, schema çıktısı, çevrilmemiş ürünlerin canonical durumu — bunların her biri ayrı bir karar noktası. Eklenti bazı katmanları otomatik yönetiyor; bazıları için yapılandırma tamamen kullanıcıya bırakılıyor. Neyin nerede durduğunu anlamadan kurulum eksiksiz sayılamıyor.
WPML ve Polylang'ın WooCommerce üzerindeki eklenti mimarisi ve genel davranış farklılıkları için WordPress çok dilli SEO rehberinde ayrıntılı bir karşılaştırma var. Aşağıdakiler eklenti bağımsız kararları ve WooCommerce'e özgü yapısal sorunları ele alıyor.
Ürün URL'si ve slug çevirisi
WooCommerce varsayılan kurulumda ürün URL'lerini /product/blue-chair/ biçiminde oluşturuyor. Çok dilli yapıda bu URL'ye dil prefix'i ekleniyor: /fr/product/blue-chair/. Slug değişmiyor; sadece öne bir dil kodu geliyor. Bu teknik olarak çalışıyor; ama Fransız bir kullanıcının "chaise bleue" aramasında güçlü bir sinyal üretmiyor.
WPML'de slug çevirisi doğrudan ürün düzenleme panelinden etkinleştirilebiliyor. Polylang Pro'da da benzer bir yapılandırma mevcut. Aktif edildiğinde /fr/produit/chaise-bleue/ gibi tam yerelleştirilmiş URL'ler oluşturmak mümkün. Rekabetçi pazarlarda — özellikle yerel dildeki arama sorgusunun ağırlıklı olduğu Fransa, Almanya veya Japonya gibi ülkelerde — bu fark hem tıklanma oranını hem sayfa bağlamını etkiliyor. Çok dilli URL yapısı kararlarının ürün slug'ına kadar uzanması bu yüzden gerekiyor; sadece site genelinde bir kural belirleyip geçmek yetmiyor.
Kritik uyarı şu: Mağaza zaten indexlenmişse slug çevirisi aktifleştirmek tüm ürün URL'lerini değiştiriyor. Yüzlerce ürün için 301 yönlendirme planı hazırlanmadan bu adım atılırsa, eski URL'ler üzerindeki link birikimi ve indexleme geçmişi kaybolabiliyor. Yeni bir mağaza için baştan açmak, var olan bir mağazada sonradan açmaktan operasyonel olarak çok daha az riskli. Sonradan slug çevirisi eklemeye karar verilirse, önce küçük bir kategoriyle test edip yönlendirmelerin doğru çalıştığını doğrulamak, hata maliyetini önemli ölçüde düşürüyor.
Kategori hiyerarşisi ve dil tutarlılığı
WooCommerce kategorileri WordPress taksonomi sistemi üzerinde çalışıyor; ama çok dilli yapıda kategori ağacının her dil sürümünde eksiksiz karşılığı bulunması gerekiyor. Ana dilde "Mobilya > Oturma Grupları > Koltuklar" şeklinde üç kademeli bir hiyerarşi varsa, her dil sürümünde bu üç kademenin de çevrilmiş ve birbirine bağlı olması şart. Bir ara katman atlandığında hreflang zinciri kırılıyor; Google o dil sürümünü geçersiz işaretleyebiliyor.
Pratikte sık karşılaşılan bir yapı şu: Alman sürümünde ana kategori ve alt kategoriler çevrilmiş, ama aradaki bir kategori İngilizce bırakılmış. Bu durumda Almanca ürün sayfaları, İngilizce bir kategori URL'si üzerinden hiyerarşi kuruyor ve canonical zinciri tutarsızlaşıyor. Kategori slug'ları da bu kapsamda değerlendiriliyor: /de/kategorie/sofas/ mantıklı bir yerelleştirme; ama /de/category/sofas/ gibi İngilizce taksonomi adı bırakılmış URL'ler dil bağlamını zayıflatıyor. Küçük görünen bu ayrıntı, Almanca pazarda rekabet eden mağazalar için fark yaratıyor.
Tüm kategori ağacını aynı anda çevirmek büyük kataloglarda mümkün olmayabiliyor. Çok dilli içerik önceliklendirme mantığını kategori düzeyine uyarlamak bu durumda iş görüyor: hangi kategoriler hedef pazarda en fazla arama talebi görüyor, hangileri mağaza gelirinin büyük bölümünü üretiyor — o kategoriler önce tamamlanıyor ve hreflang setleri eksiksiz kapatılıyor. Yarım bırakılan kategoriler ise o dil sürümü için yayıma alınmıyor.
Ürün meta ve schema yerelleştirmesi
Ürün başlığı, kısa açıklama ve uzun açıklama çevirisi bir WooCommerce çok dilli kurulumunun en emek yoğun kısmı. Makine çevirisi taslak oluşturmak için işe yarıyor; ama yayına almadan önce editör geçişi gerekiyor. Sebebi saf SEO kaygısından öte: otomatik çeviri ürün açıklamalarında sıklıkla pazara özgü kullanım alışkanlıklarını ve güven sinyallerini kaçırıyor. Bir Alman alıcının beklediği teknik açıklama formatı ile İngilizce'nin kelimesi kelimesine çevirisi arasındaki fark, dönüşüm oranına doğrudan yansıyor. Yerelleştirme ile çeviri arasındaki ayrım ürün sayfalarında en somut biçimde burada görünür.
Schema tarafında WooCommerce varsayılan olarak Product şeması üretiyor. Eklentiyle birlikte dil sürümleri bu şemayı kendi URL'lerinde de çıkartıyor. Dikkat edilmesi gereken: offers bloğundaki priceCurrency değerinin her dil sürümünde doğru para birimine işaret etmesi gerekiyor. Mağaza tek para birimi kullanıyorsa sorun yok. Ama ülke bazında fiyat farklılaştırması yapılıyorsa — Avrupa'da Euro, Birleşik Krallık'ta sterlin gibi — her URL'nin doğru currency kodu üretip üretmediği ayrıca kontrol edilmeli. Çok dilli sitelerde schema yönetimi bu tip kontroller için sistematik bir çerçeve sunuyor.
Ürün görsellerinin alt metni çoğunlukla tek dilde kalıyor — ya boş bırakılıyor ya da İngilizce yükleniyor. WooCommerce bu alanı medya kütüphanesinden çekiyor ve medya kütüphanesi doğrudan çok dilli değil. WPML veya Polylang, görsel alternatif metinlerini dil bazında yönetmek için ek yapılandırma gerektiriyor. Adım atlandığında Almanca sayfada Almanca metin ama İngilizce görsel bağlamı oluşuyor; hem kullanıcı deneyimi hem tarayıcı bağlamı açısından tutarsız bir yapı.
Varyant, stok ve fiyat: dil katmanının görünmez etkileri
WooCommerce varyantları — renk, beden, malzeme, model — çok dilli yapıda ek bir katman gerektiriyor: attribute çevirisi. WPML, ürün attribute'larını ve term'lerini (yani "Kırmızı", "Mavi", "S", "XL" gibi değerleri) ayrı bir panelden çevirilebilir hale getiriyor. Çeviri yapılmazsa Fransız kullanıcı dropdown menüsünde İngilizce değerler görüyor. Bu teknik bir SEO hatası değil; ama dönüşüm üzerindeki etkisi doğrudan. Yerel dilde gezinen kullanıcı ürün detaylarını yabancı dilde okumak zorunda kalınca alışveriş akışı kesiliyor.
Daha kritik bir durum filtre ve parametre kombinasyonlarında ortaya çıkıyor. WooCommerce varyantlar için ayrı URL üretmiyor; ama bazı yapılandırmalarda ?color=red&size=M gibi parametre kombinasyonları bağımsız URL olarak indexlenebiliyor. Bu URL'lerin dil bazında canonical durumu kontrol edilmeden bırakılırsa, arama motoru yüzlerce parametreli URL ile karşılaşıyor ve tarama bütçesinin önemli bir bölümünü burada harcıyor. Parametre yönetimini eklentinin varsayılanına bırakmak yeterli değil; özellikle büyük kataloğa sahip ve çok sayıda filtre sunan mağazalarda bu durum incelenmeyi hak ediyor.
Çoklu para birimi eklentileri ayrı bir dikkat noktası. Bazı popüler eklentiler döviz dönüşümünü URL parametresi üzerinden yönetiyor. Bu parametrenin canonical işlenmediği durumda her para birimi ayrı bir URL sayılabiliyor. Hreflang etiketlerinin parametreli URL'leri mi yoksa temiz URL'leri mi gösterdiğini yayına geçmeden doğrulamak, sonradan ortaya çıkabilecek indeksleme karmaşasını baştan önlüyor.
Çevrilmemiş ürün sayfaları ve tarama bütçesi
Büyük kataloğa sahip mağazalarda tüm ürünleri aynı anda çevirmek nadiren mümkün oluyor. WooCommerce ve WPML veya Polylang kombinasyonunda çevrilmemiş ürünler için genellikle iki seçenek sunuluyor: orijinal dildeki sayfayı o dil URL'sinde göster ya da o dil sürümü için ürünü hiç yayımlama. İkinci seçenek daha temiz bir yapı üretiyor — çevrilmemiş ürün hreflang setine dahil edilmiyor ve arama motoru yanlış dil eşleştirmesiyle karşılaşmıyor.
Birinci seçeneği tercih eden bazı mağazalar farkında olmadan aynı ürün içeriğini iki dil URL'sinde sunuyor. Google bu durumu çoğunlukla yanlış hreflang sinyal olarak işaretliyor. Her iki durumda da o dilin arama sonuçlarındaki görünürlüğü olumsuz etkileniyor. Hangi ürünlerin hangi pazar için önce çevrileceğine karar verirken uluslararası anahtar kelime araştırması somut veri sağlıyor: hangi kategoride, hangi pazarda gerçek arama hacmi var — o ürünler önce tamamlanıyor, kalanlar o dil sürümünde henüz yayıma alınmıyor.
Beş dil ve beş yüz ürünün oluşturduğu URL uzayına varyant kombinasyonları ve filtre parametreleri eklendiğinde ortaya çıkan tarama yükü ciddi bir boyut kazanıyor. Çevrilmemiş ürünlerin arama motoruna sunulmaması bu yükü doğrudan azaltıyor ve Googlebot'un zamanını tamamlanmış, yerelleştirilmiş sayfalara ayırmasına imkân tanıyor. Tarama verimliliği büyük mağazalarda küçük değişikliklerle bile ölçülebilir biçimde iyileşebiliyor.
WooCommerce çok dilli kurulumu arayüzde kontrol altında göründüğünde bile her katman bağımsız doğrulama gerektiriyor. Slug çevirisi, kategori hiyerarşisi tamamlığı, varyant attribute çevirisi, çevrilmemiş ürünlerin yayım kararı — bunlardan herhangi biri atlandığında indexleme tutarsızlıkları ya da hreflang hataları kaçınılmaz oluyor. Her katmanın kendi sorun modu var ve bir katmandaki eksiklik diğerinin çıktısını da kirletiyor.
E-ticaret katalogları içerik sitelerine kıyasla çok daha fazla URL üretiyor; bu da her yapısal hatanın etkisini katlar. Yüzlerce ürün ve çok dilli sürümleri üzerinde tutarlı bir yapı kurmak emek gerektiriyor; ama alternatif — hataları mağaza canlıya geçtikten sonra tek tek düzeltmek — hem çok daha uzun sürüyor hem de bir süre için arama görünürlüğünü doğrudan etkiliyor.