WordPress'te çok dilli yapı kurmanın tek adımdan ibaret olduğuna dair yaygın bir yanılgı var: doğru eklentiyi kur, dilleri tanımla, çevirileri gir. Bundan sonrası kendi kendine döner. Oysa asıl kararlar tam bu noktada başlıyor. URL yapısı nasıl kurulacak, hreflang etiketleri nereye ve nasıl eklenecek, çevrilmemiş sayfalar nasıl yönetilecek — bu sorular çoğunlukla varsayılan eklenti ayarlarına terk ediliyor. Varsayılan ayarlar da her zaman SEO için en iyi tercih değil.
Piyasada bu işi üstlenen üç ana eklenti var: WPML, Polylang ve TranslatePress. Üçü de WordPress içeriğini dil bazında yönetilebilir hale getiriyor; ama mimari tercihleri, hreflang çıktısı ve çeviri iş akışları birbirinden önemli ölçüde ayrışıyor. Yanlış eklentiyle kurulan bir yapıyı sonradan düzeltmek — URL değişikliği, yönlendirme planı, içerik göçü — başlangıçta iki saatlik bir kurulum kararının bedelini aylar içinde ödemeye dönüşebiliyor.
Üç eklenti burada teknik kapasiteleri, SEO üretimi ve içerik yönetimi açısından karşılaştırılıyor. Çok dilli site kurulumunun temel ilkeleri platform ne olursa olsun geçerli olmaya devam ediyor; ama WordPress özelinde eklenti seçimi bu ilkelerin nasıl hayata geçirileceğini doğrudan belirliyor.
Üç eklenti, üç farklı mimari
WPML (WP Multilingual), WordPress çok dilli ekosisteminin en köklü çözümü. Ücretli; temel lisansta sayfalar, gönderiler ve özel içerik türleri dil bazında yönetilebiliyor. WooCommerce entegrasyonu, çeviri yönetim modülü ve gelişmiş sayfa oluşturucu desteği ayrı katmanlarda ve ek ücretle geliyor. Orta ve büyük ölçekli projeler, kurumsal siteler ve çeviri sürecini birden fazla kişiyle yönetmek isteyenler arasında fiili standart haline gelmiş durumda. Öte yandan ağır bir eklenti; veritabanı yapısını köklü biçimde değiştiriyor ve gerektiğinde kaldırması kurulumu kadar zahmetli.
Polylang daha hafif bir mimariyle çalışıyor. Temel işlevler — dil yönetimi, kategori ve etiket çevirisi, dil değiştirici widget — ücretsiz sürümde mevcut. Slug çevirisi ve WooCommerce desteği Polylang Pro ile geliyor. Veritabanı yükü WPML'e kıyasla belirgin biçimde düşük; bu, performans odaklı yapılandırmalarda bir avantaj. İki veya üç dil yönetecek küçük ekipler için fazlasıyla yeterli bir altyapı sunuyor; on iki dil ve büyük içerik hacmi için değil.
TranslatePress farklı bir deneyim sunuyor: çeviriyi WordPress arka panelinden değil, sayfanın doğrudan üzerinde yapıyorsunuz. Bir görsel çeviri katmanı gibi çalışıyor; ne gördüğünüzü çeviriyorsunuz. DeepL ve Google Translate entegrasyonuyla otomatik çeviri taslakları oluşturup üstüne insan düzeltmesi eklemek mümkün. Burada dikkat edilmesi gereken kritik bir nokta var: meta başlıkları, açıklamalar ve hreflang üretimi varsayılan eklentide eksik. Bu özellikler SEO Paketi adlı ayrı bir eklenti gerektiriyor ve kurulum sırasında kolayca gözden kaçıyor.
URL yapısı ve dil yönlendirmesi
Çok dilli URL seçenekleri üç eklentide de benzer görünüyor: alt dizin (/fr/), alt alan adı (fr.example.com) veya ayrı alan adı (example.fr). Ama eklentinin bu kararı nasıl uyguladığı, seçeneğin adından çok daha belirleyici. Bu yapıların SEO üzerindeki etkileri çok dilli URL yapısı rehberinde ayrıntılı ele alındığından burada eklentiye özgü davranış farklılıklarına odaklanıyoruz.
WPML üç yapıyı da tam destekliyor ve slug çevirisine izin veriyor. Yani /fr/contact/ yerine /fr/nous-contacter/ kullanmak mümkün. Bu özellik varsayılan olarak kapalı; "Dil URL'si" ayarlarından ayrıca etkinleştirmek gerekiyor. Fransız, Alman veya Japon kullanıcıların kendi dillerinde arama yaptığı bir pazar için URL'nin de o dilde oluşması hem kullanıcı deneyimi hem arama motoru sinyali açısından değer taşıyor. Özellikle rekabetçi pazarlarda bu fark küçümsenecek bir ayrıntı değil.
Polylang ücretsiz sürümde slug çevirisini desteklemiyor; bu özellik Pro'da geliyor. Alt dizin ve alt alan adı seçenekleri her iki sürümde mevcut; ayrı alan adı kullanmak ek yapılandırma gerektiriyor. Çoğu içerik odaklı site için bu sınırlama sorun yaratmıyor. Ama dil bazında tam yerelleştirilmiş URL'ler öncelikliyse bu Pro planına yatırım kararına bağlıyor.
TranslatePress'in URL yönetimi diğer ikisine kıyasla daha kısıtlı. Varsayılan yapıda dil prefixi URL'ye ekleniyor; özel slug çevirisi SEO Paketi gerektiriyor ve esneklik sınırlı. Basit blog ya da portfolyo sitelerinde bu fark hissedilmiyor; büyük içerik mimarisinde veya dil bazında farklı URL hiyerarşisi hedefleyen projelerde ileride köstek olabiliyor.
Otomatik dil yönlendirmesi üç eklentide de sunulan bir seçenek. Ziyaretçinin tarayıcı diline göre ilgili dile yönlendirme cazip görünüyor; ama Google botları bu yönlendirmelerle karşılaştığında içerikleri düzgün tarayamayabiliyor. Aynı URL'nin farklı koşullarda farklı içerik döndürmesi, özellikle tarama bütçesi sınırlı sitelerde ciddi sorunlara kapı aralıyor. Bu özelliği açmadan önce teknik riski değerlendirmek gerekiyor.
Hreflang üretimi ve güvenilirlik sınırları
WPML ve Polylang hreflang etiketlerini otomatik üretiyor. Bu çoğu kurulum için yeterince iyi çalışıyor — ama "çoğu" ifadesinin dışında kalan durumlar kritik olabiliyor.
Hreflang etiketinin çalışma mantığı doğru anlaşılmadan otomatik üretime güvenmek risk yaratıyor. İlk dikkat edilmesi gereken alan x-default değeri. Bu etiket, dil bilgisi belirsiz kullanıcılar için hangi URL'nin sunulacağını tanımlıyor. WPML'de x-default'u yapılandırma panelinden düzenleyebiliyorsunuz; Polylang'da ise bu değer varsayılan dile işaret ediyor ve müdahale sınırlı. Varsayılan diliniz İngilizce ama ana pazarınız Almanya ise bu ayarın elle kontrol edilmesi gerekiyor. x-default değerinin nasıl belirleneceği ayrı bir karar sürecini gerektiriyor ve çoğunlukla göz ardı ediliyor.
İkinci sorun alanı çevrilmemiş sayfalar. WPML, henüz çeviri yapılmamış bir dil için hreflang üretmiyor — doğru davranış bu. Polylang bazı yapılandırmalarda orijinal dildeki URL'yi diğer dil olarak da gösterebiliyor; bu durumda Google aynı sayfayı birden fazla dile yönelik okuyabiliyor ve hreflang setini geçersiz sayabiliyor. Hangi eklentiyi kullandığınızdan bağımsız olarak yeni bir dil eklediğinizde çevrilmemiş içeriklerin ne ürettiğini kontrol etmek gerekiyor.
Üçüncü risk sayfa oluşturucu uyumundan geliyor. Elementor, Divi veya Bricks Builder gibi araçlarla birlikte kullanılan sitelerde hreflang etiketlerinin <head> bölümünde doğru yere yazılıp yazılmadığını kontrol etmek gerekiyor. Bazı kombinasyonlarda etiketler <body>'e kayıyor ya da çift yazılıyor; her iki durum da Google'ın etiketi geçersiz saymasına yol açıyor.
Bu nedenle eklentinin ürettiği hreflang çıktısını kurulumun ardından ve büyük yapısal değişikliklerde doğrulamak iyi bir alışkanlık. Üretilen etiket setini bağımsız bir araçla karşılaştırmak, gözden kaçan eşleşme hatalarını ve eksik dil-bölge kombinasyonlarını görsel biçimde ortaya çıkarır. Özellikle beş veya daha fazla dil yönetilen sitelerde bu adımı atlamak ileride uzun sürebilecek bir hata avına dönüşebiliyor.
Çeviri iş akışı ve içerik yönetimi
Hangi eklentinin seçileceğini belirleyen etkenler arasında teknik özellikler kadar önemli bir başkası var: içerik nasıl çevrilecek ve bu süreç kimler tarafından yönetilecek.
WPML'in çeviri yönetim modülü ekip çalışmasına uygun kurulmuş. İçerikler çevirmenlere atanabiliyor, görev durumları takip ediliyor, XLIFF formatında çeviri dosyası dışarıya gönderilebiliyor ve geri alınabiliyor. Büyük sitelerde ya da profesyonel çeviri ajanslarıyla çalışan projelerde bu iş akışı ciddi zaman tasarrufu sağlıyor. Dezavantajı: bu modül temel lisansa dahil değil ve yapılandırması katmanlı. Tek kişilik bir sitenin buna ihtiyacı olmayabiliyor; on kişilik bir ekip için ise vazgeçilmez hale gelebiliyor.
Polylang'da çevirmen rolü tanımlanabiliyor ama görev yönetimi yok. Hangi sayfa çevrildi, hangisi güncellendi ama çevirisi henüz güncellenmedi — bunları takip etmek eklentinin dışında kalıyor ve büyük ölçüde manuel süreçlere bırakılıyor. İki dil ve küçük bir içerik hacmi için bu yeterli; birden fazla editörün düzenli içerik ürettiği yapılarda yetersiz kalıyor.
TranslatePress görsel çeviri arayüzüyle farklı bir konfor sunuyor. Sayfayı ziyaretçi gözüyle görüntüleyerek yan panelde çeviri yapılıyor; bir buton metninin ya da başlığın sayfada tam olarak nerede göründüğünü görürken çeviriyorsunuz. Bağlamsal hata bu sayede azalıyor. Makine çevirisi desteğiyle içerik taslakları hızla oluşturuluyor, ardından insan editörü müdahil oluyor. Ancak burada bir tuzak var: otomatik çeviri çıktısı çoğunlukla hedef pazarın arama niyetiyle örtüşmüyor. Yerelleştirme ile çeviri arasındaki fark tam burada somutlaşıyor; makine kelime karşılıkları üretiyor, yerel kullanıcının gerçek sorgu kalıplarını değil.
Eklenti geçişi ve büyüme maliyetleri
Mevcut ve aktif bir WordPress sitesine çok dilli eklenti eklemek sıfırdan başlamanın birkaç katı daha karmaşık. İndekslenmiş URL'lerin değişmemesi için yönlendirme planı hazırlamak gerekiyor; mevcut içeriklerin hangi dile atanacağına karar vermek gerekiyor; eklentinin tema ve sayfa oluşturucuyla uyumunu test etmek gerekiyor. Bu adımlar dikkatli geçilmezse tarama hataları, kopan hreflang zincirleri ve kırılmış iç bağlantılar bırakıyor geriye. Teknik SEO denetim listesi, bu tür geçiş sonrası kontrollerde referans noktası olarak işe yarıyor.
WPML'den Polylang'a ya da Polylang'dan TranslatePress'e geçiş teknik olarak mümkün; ama veri göçü araçları eksik ve çeviri eşleşmeleri büyük ölçüde elle aktarılmak zorunda kalıyor. Küçük siteler için bu birkaç günlük iş; yüzlerce sayfası ve birden fazla dili olan yapılarda gerçek bir proje. Dolayısıyla ilk eklenti seçimini sonraki bir ila iki yılın gereksinimlerini gözeterek yapmak, operasyonel maliyeti doğrudan etkiliyor. Geçişin kolaylığına güvenerek ilk tercihte ihmalkâr olmak riskli.
Dil sayısı da ölçek açısından belirleyici bir değişken. İki veya üç dil için üç eklenti de yönetilebilir. Beş, sekiz ya da on dile çıkıldığında WPML'in çeviri yönetim altyapısı fark yaratmaya başlıyor; Polylang ve TranslatePress'te tamamlanma durumu takibi giderek güçleşiyor, editörler hangi içeriklerin güncel olduğunu bulmak için eklentinin dışına çıkmak zorunda kalıyor. Büyüme senaryosu net görünüyorsa baştan WPML'i tercih etmek uzun vadede daha az sorun yaratıyor. Büyüme belirsizse, Polylang Pro iyi bir ara istasyon.
WPML, Polylang ve TranslatePress birbirinin yerine geçmeyen ama oldukça farklı profillere hizmet eden çözümler. Polylang bütçe kısıtlıysa ve site küçük ya da orta ölçekliyse sağlam bir başlangıç noktası. TranslatePress görsel çeviri deneyimini ve makine çevirisi entegrasyonunu önceliklendiren ekipler için uygun — SEO Paketi ihmal edilmediği sürece. WPML ise WooCommerce gerektiren projeler, çok sayıda dil ve çeviri ekibi yönetiminin söz konusu olduğu yapılar için ek maliyeti karşılayan seçenek.
Eklentiyi seçtikten sonra asıl iş başlıyor. URL yapısı doğru kurulmadan, hreflang üretimi doğrulanmadan ve çeviri kalitesi kontrol altına alınmadan teknik kapasite yüzeyde kalıyor. Bu üçünü birlikte planlamak, WordPress'i çok dilli SEO için gerçekten güçlü bir platforma dönüştürüyor.