WordPress Çok Dilli Site Nasıl Yapılır?

Mevcut Türkçe sayfalarınızın adreslerini değiştirmeden İngilizce içerik yayımlayabilirsiniz. WordPress çok dilli site kurulumu için önce yedekli bir staging kopyası hazırlayın, uygun bir dil eklentisi seçin ve çeviri eşlerini bağlayın. Türkçe kökte, İngilizce /en/ altında kalabilir; yayına geçmeden menüleri, dil seçiciyi, karşılıklı hreflang işaretlerini ve her sayfanın kendi canonical adresini doğrulayın.

İkinci dili açmadan önce mevcut siteyi koruyun

İngilizce içerik yayımlarken çalışan Türkçe adresleri değiştirmeniz gerekmez. WordPress çok dilli site hazırlığında hedefiniz, https://example.com/hakkimizda/ adresini koruyup İngilizce karşılığını https://example.com/en/about/ altında sunmak olsun. Türkçe varsayılan kalacak; URL’lerde Türkçe dil kodu görünmeyecek. Önce envanter.

Varsayımsal staging ortamı Ubuntu Server 24.04 LTS, Nginx 1.24, PHP 8.3-FPM, MariaDB 10.11, WordPress 6.8.3, WP-CLI 2.12 ve Polylang 3.7 serisini temel alır. Bunlar güncellik iddiası değildir; güvenlik güncellemelerini ve uyumluluğu resmi kaynaklardan doğrulayın, doğruladığınız yama sürümlerini bütün örneklerde aynı tutun. Ayrılan 2 vCPU, 4 GB RAM ve 40 GB disk performans garantisi sağlamaz.

Klasik temalı, tek siteli kurulumda sayfa ve yazı URL’lerini, menü konumlarını, form alanlarını, doğrulama mesajlarını, e-posta bildirimlerini ve tema metinlerini kaydedin. Her kayda içerik sorumlusu ve çeviri durumu ekleyin. Yalnızca sayfa gövdesini çevirmek yeterli değildir – İngilizce formun Türkçe hata vermesi kolayca gözden kaçar.

Staging kopyasını geçerli HTTPS üzerinden, Nginx katmanında HTTP Basic Authentication veya VPN ile erişime kapatın. WordPress’teki arama motorlarının indekslemesini engelleme seçeneğini de işaretleyin; bu ayar erişim kontrolünün yerine geçmez. Kimlik doğrulaması olmadan sayfaların açılmadığını kontrol edin. Kopyanın gerçek alıcılara e-posta göndermesini durdurun.

WordPress’in yedekleme dokümantasyonu, tam geri dönüş için veritabanı ve dosyaların birlikte saklanmasını önerir. Aşağıdaki örnekte sudo yetkili deploy hesabının dosya sahipliği WP-CLI çalıştırmaya uygundur; wp root olarak çalıştırılmaz. Başlamadan boş alanı kontrol edin; düzenlemeleri, yüklemeleri ve zamanlanmış yazma işlemlerini durdurun. --single-transaction, dosyalarla veritabanını tek başına aynı ana sabitlemez.

(
set -eu
umask 077
sudo install -d -m 700 -o deploy -g "$(id -gn)" /srv/backups/example.com
backup=$(mktemp -d /srv/backups/example.com/pre-language.XXXXXXXX)
cd /var/www/example.com/public
wp db export "$backup/database.sql" --single-transaction
tar -czf "$backup/files.tar.gz" -C /var/www/example.com public
cd "$backup"
sha256sum database.sql files.tar.gz > SHA256SUMS
sha256sum -c SHA256SUMS
tar -tzf files.tar.gz > /dev/null
printf 'Yedek dizini: %s\n' "$backup"
)

Komutlar web kökü dışında, erişimi sınırlandırılmış benzersiz bir dizine SQL dökümü ve dosya arşivi yazar. Başarılı çalışmada sağlama kontrolünden iki dosya için OK beklenir; arşiv listelemesi sessiz tamamlanır. Bu kontroller geri yükleme kanıtı değildir. /etc/nginx/sites-available/example.com yapılandırmasını ve gerekli servis ayarlarını ayrıca saklayın.

VPS snapshot hızlı geri dönüş noktası sağlayabilir; aynı altyapıdaki kopya bağımsız yedek sayılmaz. Yedeği ayrı depoya aktarın. Dosyaları izole bir ortama açıp SQL’i ayrı veritabanına yükleyin; yönetici girişini, medyayı ve mevcut Türkçe adresleri doğrulamadan ikinci dili etkinleştirmeyin.

Polylang, WPML veya TranslatePress: seçim neye bağlı?

İngilizce metni kimin güncelleyeceği belli değilse eklenti seçimi tek başına sorunu çözmez. Editörlerin iki dili ayrı ayrı hazırladığı bir WordPress çok dilli site ile otomatik çeviriye dayanan katalog farklı iş akışları gerektirir. Önce süreci belirleyin. Eklentiyi de çeviriyi hazırlayan, onaylayan ve güncel tutan kişilerin çalışma biçimine göre değerlendirin.

Polylang, dil sürümlerini ayrı WordPress içerikleri olarak düzenleyip birbirine bağlayan editoryal akışa uygundur. WordPress.org üzerindeki resmi Polylang açıklaması, ücretsiz sürümde yazıların, sayfaların, kategorilerin, etiketlerin ve menülerin çok dilli yönetilebildiğini belirtir; içerik çoğaltma ve URL tabanlarını çevirme gibi özellikleri Pro kapsamında listeler. İngilizce sayfaya about kısa adını vermek, kategori gibi ortak URL tabanlarını çevirmek değildir. Yalnızca farklı sayfa kısa adları kullanmak için Pro gerektiğini varsaymayın.

WPML, çeviri görevlerini ve çevirmen rollerini merkezi yönetmek isteyen ekiplerin değerlendirebileceği bir seçenektir. TranslatePress ise ziyaretçinin gördüğü sayfa üzerinden görsel çeviri düzenlemeye odaklanır. Ayrım arayüzden ibaret değildir: ayrı içerik kayıtlarıyla çalışmak ile görüntülenen metinleri çevirmek, güncelleme ve taşıma süreçlerini farklılaştırır. Tema değiştiğinde veya bir eklenti dinamik metin ürettiğinde çevirilerin nasıl yönetileceğini kontrol edin.

Sağlanan kaynaklar WPML ve TranslatePress’in resmi belgelerini içermediğinden bu iki ürünün güncel paket sınırları burada doğrulanmış değildir. Seçimden önce üretici belgelerinde ücretsiz ve ücretli özellikleri, site lisansı sayısını, yenileme koşullarını ve otomatik çeviri kotalarını doğrulayın. Otomatik çeviride sağlayıcı hesabı, API anahtarı veya kredi gereksinimi kullanılan entegrasyona bağlıdır; metinlerin hangi üçüncü tarafa gönderildiğini de inceleyin. Lisans bedeli ile çeviri hizmetinin kullanım bedelini aynı kalem saymayın.

Ortak varsayımsal staging ortamında WordPress 6.8.3, klasik tema ve Polylang 3.7 serisiyle ilerleme gerekçesi sadedir: Türkçe kaynak içerikle İngilizce karşılığını ayrı düzenlemek yeterlidir. WooCommerce ve Multisite kapsam dışındadır. Manuel çeviri harici çeviri API’si gerektirmez; seçim hız üstünlüğüne dayanmaz. Bu sürümler güncellik iddiası taşımaz. Kurulumdan önce güvenlik yamalarını ve uyumluluğu resmi kaynaklardan doğrulayın; doğrulanan yama sürümlerini bütün örneklerde sabit tutun.

Taşınabilirlikte metin kadar dil eşleşmelerini, menüleri ve eklentiye özgü kayıtları da değerlendirin. Standart WordPress dışa aktarımının hepsini taşıdığını varsaymayın; hedef sistemde aktarım provası yapın. Eklentileri ayrı staging kopyalarında karşılaştırın, aynı sitede birden fazla çok dillilik eklentisini birlikte etkinleştirmeyin.

Türkçe kökte, İngilizce /en/ altında

İkinci dili eklemek, mevcut Türkçe adresleri taşımayı gerektirmez. Adresler kalsın. Bu varsayımsal staging ortamında https://example.com/hakkimizda/ korunur; İngilizce karşılığı https://example.com/en/about/ olur. WordPress çok dilli site düzeninde alt dizin seçimi, iki dili aynı alan adı, sertifika ve WordPress kurulumu altında yönetmenizi sağlar. /en/ yalnızca URL önekidir; diskte böyle bir klasör oluşturmayın.

Polylang’ın WordPress.org açıklamasına göre diller alt dizin, alt alan adı veya ayrı alan adlarıyla yayımlanabilir. Alt alan adında DNS kayıtları, sertifika kapsamı ve Nginx sunucu adı eşlemesi ayrıca düzenlenir. Ayrı alan adlarında kayıt ve yenileme takibi de eklenir; bu model ayrı WordPress kurulumlarını zorunlu kılmaz. Alt dizin kararı, başlangıçta bu işletim yükünü azaltır.

Dil ataması URL ayarından önce gelir

WordPress 6.8.3 ve Polylang 3.7 serisi referansında, Diller menüsünden Türkçe ve İngilizceyi ekleyin; kodları tr ve en olarak bırakın. Türkçeyi varsayılan seçin. Mevcut içeriklere dil atama adımında Türkçeyi uygulayın; yazıların, sayfaların ve kategorilerin dilsiz kalmadığını kontrol edin. İngilizce sayfayı Türkçe sayfanın çevirisiyle ilişkilendirip kısa adını about yapın.

Polylang URL ayarlarında dilin dizinden belirlenmesini seçin, varsayılan dil kodunu gizleyin ve /language/ önekini kaldıran seçeneği etkinleştirin. Ayarlar → Kalıcı Bağlantılar ekranında mevcut Türkçe bağlantı yapısını değiştirmeden kaydedin. Örnekte okunabilir kalıcı bağlantılar kullanılır; mevcut adresleri sırf örneğe benzetmek için değiştirmeyin.

Nginx isteği WordPress’e ulaştırmalı

/etc/nginx/sites-available/example.com dosyasının mevcut HTTPS sunucu bloğundaki location / kuralını aşağıdaki gibi düzenleyin; ikinci kopyasını eklemeyin. Web kökü /var/www/example.com/public, PHP işleyicisinin soketi /run/php/php8.3-fpm.sock olarak kalır. Bu parça mevcut sunucu yapılandırmasının tamamının yerine geçmez.

location / {
    try_files $uri $uri/ /index.php?$args;
}

Kural, dosya veya dizin bulunmadığında isteği sorgu parametreleriyle WordPress’e aktarır; dili Nginx değil, Polylang çözümler. Ardından deploy hesabıyla yapılandırmayı sınayın:

sudo nginx -t && sudo systemctl reload nginx

Başarılı testte syntax is ok ve test is successful mesajları beklenir. && sayesinde yeniden yükleme yalnızca test başarılıysa çalışır; başarısızlıkta önce bildirilen hatayı düzeltin. Bu mesajlar sayfa eşleşmesini doğrulamaz.

Google Search Central, dil sürümlerinin ayrı URL’lerle belirtilmesini açıklar. Bu düzende tarayıcı dili algılamasını kapalı bırakın: Türkçe adresi açan ziyaretçiyi zorunlu olarak İngilizceye yönlendirmeyin; dil değiştirmeyi ziyaretçinin seçimine bırakın.

Çeviri yalnızca yazı gövdesinden ibaret değil

İngilizce metnin üzerinde “Hakkımızda” başlığı, altında Türkçe düğmeler varsa çeviri henüz bitmemiştir. Gövde yetmez. WordPress.org’daki Polylang açıklaması; sayfalar, kategoriler, menüler ve medya bilgilerinin farklı dillerde yönetilebildiğini belirtir. Bu destek, eklentinin bütün metinleri kendiliğinden çevirdiği anlamına gelmez.

Varsayımsal staging ortamındaki WordPress 6.8.3 ve Polylang 3.7 serisinde Sayfalar ekranından Hakkımızda sayfasını açın. Dilini Türkçe olarak doğrulayın; çeviriler alanındaki İngilizce ekleme simgesiyle karşılığını oluşturun. Başlığı “About”, URL kısaltmasını about yapıp İngilizce içeriği girin. About sayfası zaten varsa kopyasını üretmeyin; dilinin İngilizce olduğunu kontrol ederek çeviriler alanından mevcut sayfayı seçin. Benzer başlıklar, iki sayfayı çeviri eşi yapmaz.

İngilizce sayfa yayımlandığında beklenen eşleşme https://example.com/hakkimizda/ ile https://example.com/en/about/ adresleridir. Türkçe varsayılan dil kodu gizli kalır. Bunlar dokümantasyon adresleridir; gerçek erişim beklenmez ve burada denenmiş bir sonuç aktarılmaz. Düzenleme ekranlarında karşılıklı çeviri bağlantılarının göründüğünü doğrulayın.

Gövdenin dışında kalan kontrol noktaları

• Başlık ve URL kısaltması: Her ikisini ayrı inceleyin. İngilizce sayfada Türkçe başlık ya da kopya oluşturulmasından kaynaklanan sayısal ek kalmamalıdır.
• Kategoriler: Kullanılan kategorilerin İngilizce karşılıklarını oluşturup eşleştirin. Kategori adı ve kısaltması da çevrilecek alanlardır; yazının İngilizce kategoriyi kullandığını doğrulayın.
• Menüler: Klasik temada her dil için menü hazırlayıp ilgili dilin tema konumuna atayın. Özel bağlantıların etiketlerini ve hedeflerini ayrıca düzenleyin.
• Ana sayfa: Statik ana sayfanın İngilizce karşılığını oluşturup bağlayın. Kök adresin Türkçe, /en/ yolunun İngilizce ana sayfayı göstermesini kontrol edin.
• Görsel alternatif metinleri: Medya çevirisi etkinse ilgili dilde düzenleyin. İçeriğe önceden eklenmiş görsel bloklarının alternatif metinlerini de inceleyin; medya kaydındaki değişikliğin bloğa yansıdığını varsaymayın.
• Desteklenen tema dizgileri: Polylang’ın dizgi çevirisi ekranına kaydedilmiş ifadeleri çevirin. Temaya sabit yazılmış metinler otomatik görünmez; tema çeviri dosyaları veya geliştirici müdahalesi gerekebilir.

Menüdeki dil seçicinin ana sayfaya yönlendirme seçeneğini kapatın. Beklenen davranış, Hakkımızda üzerindeki İngilizce seçiminin About sayfasına gitmesidir. Bu örnekte çevirisi olmayan içerikler için ilgili dili gizleme seçeneğini etkinleştirin; ziyaretçiye mevcut olmayan bir karşılık sunulmasın. Bu ayar yalnızca seçicinin davranışını belirler, eksik çeviriyi oluşturmaz.

Makine çevirisi kullanırsanız yayımlamadan önce insan kontrolünden geçirin. Özellikle hizmet koşullarını, fiyatlandırma ifadelerini ve düğme metinlerini hedef sayfayla birlikte okuyun; “Başvur” düğmesinin yanlış dildeki forma açılması da düzeltilmesi gereken bir çeviri eksikliğidir.

hreflang ve canonical aynı işi yapmaz

İngilizce sayfanın canonical adresini Türkçeye çevirmek, dil eşleştirmesi değildir. Amaç farklıdır. hreflang dil alternatiflerini, canonical ise aynı veya çok benzer içerikler arasında tercih edilen URL’yi bildirir. Google Search Central’ın canonical belgesine göre bu tercih kesin bir talimat değil, sinyaldir. İki etiketi birbirinin yerine kullanmak, arama motoruna sayfalar arasındaki ilişkiyi yanlış anlatabilir.

Varsayımsal staging ortamındaki https://example.com/hakkimizda/ ve https://example.com/en/about/ çifti için her sayfa kendi adresini canonical göstermelidir. İngilizce sayfa Türkçeye canonical vermemelidir; ana içeriğin çevirisi, yalnızca farklı adreste yayımlanmış bir kopya değildir. WordPress çok dilli site yapılandırmasında bu iki adres, birbirinin dil alternatifi olarak kalır.

Google’ın yerelleştirilmiş sayfalar belgesi, her sürümün hem kendisini hem diğer dil sürümlerini belirtmesini ister. Türkçe sayfadaki tr kendine referans verir, en İngilizceye bağlanır; İngilizce sayfada da aynı alternatifler bulunur. Bağlantılar karşılıklı değilse işaretlemeler yok sayılabilir. Hedefleri protokol ve alan adı içeren tam URL olarak belirtin.

Aşağıdaki HTML, iki sayfanın head alanında beklenen etiketleri gösteren varsayımsal örnektir; test edilmiş çıktı veya temaya elle eklenecek kod değildir. Her sayfada canonical değişir, dil alternatifleri aynı kalır:

<!-- https://example.com/hakkimizda/ sayfasının head alanı -->
<link rel="canonical" href="https://example.com/hakkimizda/">
<link rel="alternate" hreflang="tr" href="https://example.com/hakkimizda/">
<link rel="alternate" hreflang="en" href="https://example.com/en/about/">

<!-- https://example.com/en/about/ sayfasının head alanı -->
<link rel="canonical" href="https://example.com/en/about/">
<link rel="alternate" hreflang="tr" href="https://example.com/hakkimizda/">
<link rel="alternate" hreflang="en" href="https://example.com/en/about/">

WordPress yerel ayarlarını hreflang kodlarıyla karıştırmayın: tr_TR ve en_US değerlerini doğrudan buraya taşımayın. Google, ISO 639-1 dil kodlarını ve gerektiğinde tireyle eklenen ISO 3166-1 Alpha-2 bölge kodlarını kullanır. Ülke hedeflemesi olmayan bu ortamda tr ve en yeterlidir. Türkçenin URL kodunun gizlenmesi bu kuralı değiştirmez.

Polylang’ın WordPress.org açıklaması hreflang üretimini desteklediğini belirtir. SEO eklentisi de kullanıyorsanız her iki sayfanın kaynağında yinelenen hreflang etiketlerini ve birden fazla canonical bildirimini kontrol edin. Özellikle İngilizce kaynaktaki canonical hedefini okuyun; otomatik üretim, doğru yapılandırma garantisi değildir. Çakışma varsa temaya yeni etiket eklemek yerine üretim sorumluluğunu ilgili bileşenlerin ayarlarından düzenleyin.

x-default isteğe bağlıdır; Google bunu listelenen dillerle eşleşmeyen kullanıcılar için yedek URL belirtmekte kullanır. Bu örnekte gerekli değildir. Google, HTML ve XML site haritasını alternatif hreflang yöntemleri olarak kabul eder. Site haritasında dil alternatiflerinin bulunacağını varsaymayın; kullanılan entegrasyona göre doğrulayın. İki yöntem birlikte kullanılıyorsa aynı sayfa eşleşmelerini bildirdiklerini kontrol edin.

Yayımlamadan önce iki dili de sınayın

Türkçe sayfa açılırken İngilizce karşılığı yanlış adrese yönlenebilir. Görünüş yetmez. WordPress çok dilli site kontrolünde HTTP yanıtını, HTML kaynağını ve tarayıcıdaki davranışı birlikte değerlendirin; denetimi yönetici oturumu kapalıyken de tekrarlayın. Özellikle dil değiştirirken adres çubuğunu izleyin: doğru görünen başlık, doğru çeviri eşleşmesini tek başına kanıtlamaz.

Aşağıdaki örnek, varsayımsal staging ortamında deploy hesabı içindir; çalıştırılmış bir test değildir. 192.0.2.10 dokümantasyon adresine gerçek erişim beklenmez. Gerçek kurulumda test bağlantısına staging korumasından izin verilmelidir. --resolve, DNS’i değiştirmeden belirtilen IP’ye doğru HTTPS sunucu adıyla bağlanır; sertifika doğrulamasını kapatmaz.

(
  kontrol_dizini=$(mktemp -d) || exit 1
  trap 'rm -rf -- "$kontrol_dizini"' EXIT

  for yol in /hakkimizda/ /en/about/; do
    printf '\nAdres: https://example.com%s\n' "$yol"
    curl --silent --show-error --location --max-redirs 5 \
      --connect-timeout 10 --max-time 30 \
      --resolve example.com:443:192.0.2.10 \
      --dump-header "$kontrol_dizini/headers" \
      --output "$kontrol_dizini/page.html" \
      --write-out 'HTTP=%{http_code} yonlendirme=%{num_redirects} hedef=%{url_effective}\n' \
      "https://example.com$yol" || continue

    grep -Ei '^(HTTP/|Location:|X-Robots-Tag:)' "$kontrol_dizini/headers"
    tr '\n' ' ' < "$kontrol_dizini/page.html" \
      | grep -oEi '<(link|meta)[^>]*>' \
      | grep -Ei 'canonical|alternate|robots'
  done
)

wp --path=/var/www/example.com/public option get blog_public

Varsayımsal beklenti: İki HTTPS adresinde HTTP=200, yonlendirme=0 ve istenen URL ile aynı hedef görülmesidir. --location yönlendirmeleri izler; başlık dökümü ara durumları ve Location değerlerini gösterir. Beklenmeyen 301 yönlendirme zincirlerini inceleyin. 401 veya 403 alırsanız önce erişim korumasını değerlendirin; bunlar tek başına çeviri hatası değildir.

Google Search Central’ın canonical belgesine göre ana içeriği çevrilmiş sayfalar sırf çeviri oldukları için kopya sayılmaz. Bu eşleşmede her canonical kendi sayfasını göstermelidir. Google’ın yerelleştirilmiş sayfalar belgesi, her dil sürümünün kendisini ve diğer sürümleri karşılıklı listelemesini ister: iki sayfada da tr için https://example.com/hakkimizda/, en için https://example.com/en/about/ beklenir. Etiket süzmesi yalnızca ön kontroldür; eksik görünen çıktıyı sayfa kaynağından doğrulayın.

Tarayıcıda dil seçicinin ana sayfaya değil eşleşen çeviriye götürdüğünü sınayın. Mobil menüyü iki dilde açın; aramada ilgili dilde bilinen bir içeriği bulun. Boş ve hatalı form gönderimlerinin uyarılarını, başarılı gönderimin onayını okuyun. Var olmayan kök ve /en/ adreslerinde uygun dilde hata metniyle gerçek 404 yanıtı bekleyin.

Ayrı staging ortamının korumasını bırakın; yayına alınan sitedeki erişim kısıtını ve noindex ayarlarını kaldırın. Oturumsuz isteği tekrarlayın. Yayında blog_public için 1 beklenir; ayrıca HTML robots etiketinde ve X-Robots-Tag başlığında noindex bulunmadığını doğrulayın. Ayarın doğru görünmesi, dışarıdan erişimin de açık olduğunu göstermez.

Başlangıçta tam sayfa önbelleği yoktur. Sonradan eklerseniz iki URL’yi dönüşümlü ve tekrarlı açın; önbellek ısındığında içerik dilinin, canonical adresinin ve dil seçici hedeflerinin birbirine karışmadığını yeniden sınayın.

Yeni içerik geldiğinde dil eşleşmeleri nasıl korunur?

Türkçe sayfadaki tek bir fiyat, tarih veya hizmet koşulu değişikliği, İngilizce karşılığı hâlâ yayındayken onu eski bilgiye dönüştürebilir. Bağlantı yetmez. Varsayımsal staging ortamında her içerik çifti için kaynak değişiklik tarihini, çeviri sorumlusunu ve son dil onayını kaydedin. Türkçe metin değiştiğinde İngilizce karşılığını editoryal takip listenizde yeniden incelemeye alın; Polylang’ın bu onay sürecini kendiliğinden yönettiğini varsaymayın.

Polylang’ın WordPress.org açıklaması, içeriklere dil atanmasını ve çevirilerin birbirine bağlanmasını desteklediğini belirtir. Bu bağlantıyı editoryal takiple tamamlayın: çevirisi bulunmayan, kaynak değişikliği nedeniyle inceleme bekleyen ve yayına hazır içerikleri ayrı durumlarda izleyin. Haftalık kontrolde yeni yazıları, sayfaları ve çevrilmesi gereken taksonomi terimlerini listeyle karşılaştırın. Her kayıtta iki içerik kimliği ile hedef URL’leri tutun; benzer başlıklar yanlış eşleşmeleri gizleyebilir. Ortak bir takip tablosu yeterlidir, ayrıca iş akışı eklentisi kurmanız şart değildir.

Her dil için ayrı onay isteyin. Türkçe metnin onaylanması İngilizce metnin hazır olduğu anlamına gelmez; başlık, gövde, menü bağlantıları ve ilgili dilde görünen diğer metinler ayrıca incelenmelidir. Kaynak değişikliği anlamı etkiliyorsa çeviri sorumlusu farkı değerlendirmeden kaydı kapatmayın. Eksik İngilizce karşılığı Türkçe sayfayla doldurup tamamlanmış çeviri gibi göstermeyin. Onay kaydına incelenen kaynak revizyonunu ekleyin; önceki onayı değişmiş metne otomatik taşımayın.

WordPress, klasik tema ve Polylang güncellemelerini aynı staging ortamında, ayrı adımlarla değerlendirin. Referans taban WordPress 6.8.3 ve Polylang 3.7 serisidir; bunlar en güncel sürüm iddiası taşımaz. Uygulama öncesinde güvenlik güncellemelerini ve uyumluluğu resmi kaynaklardan doğrulayın, seçilen yama sürümlerini bütün örneklerde aynı tutun. Her güncellemeden sonra düzenleme, çeviri bağlantısı ve dil değiştirici akışlarını yeniden kontrol edin.

WordPress’in yedekleme dokümanı, tam geri dönüş için veritabanıyla dosyaların birlikte gerekli olduğunu açıklar. Değişiklik öncesinde tutarlı bir yedek kümesi oluşturup /srv/backups/example.com altında saklayın. İkisini aynı yedekleme noktasına döndürerek içeriklerin ve dil eşleşmelerinin korunduğunu doğrulamadan güncellemeyi onaylamayın.

Yayın kapısını somutlaştırın: https://example.com/hakkimizda/ ile https://example.com/en/about/ eşleşmeli, dil değiştirici doğru karşılığa gitmeli ve hedefler beklenen içeriği sunmalıdır. Google Search Central’ın yerelleştirilmiş sayfa yönergesi, hreflang bağlantılarının sayfanın kendisini ve diğer dil sürümlerini kapsamasını, karşılıklı olmasını ister. Yeni içeriği, ilgili dilin onayı alınmadan ve dil eşleşmesi ile URL kontrolleri tamamlanmadan yayımlamayın.

Yayımlamadan önce iki dili de sınayın

• Veritabanı ve dosya yedeğini aynı geri dönüş noktasından alın; ayrı ortamda birlikte geri yükleyin.
• WordPress, PHP, tema ve dil eklentisinin güvenlik güncellemelerini ve sürüm uyumluluğunu resmi kaynaklardan doğrulayın.
• Mevcut içeriklere Türkçe atayın; Türkçe URL'lerin korunduğunu ve İngilizce sayfaların /en/ altında açıldığını denetleyin.
• Çeviri çiftlerini bağlayın; menüleri, ana sayfayı, görsel alternatif metinlerini ve form mesajlarını iki dilde kontrol edin.
• Her dil sayfasının kendine canonical verdiğini, hreflang bağlantılarının karşılıklı olduğunu ve çelişen etiket bulunmadığını doğrulayın.
• HTTP durumlarını, yönlendirme zincirlerini, dil seçiciyi, mobil menüyü, aramayı ve bulunamayan sayfaları sınayın.
• Yayın ortamındaki erişim kısıtlarını ve noindex ayarlarını kontrol edin; sonraki içeriklerde dil eşleşmesi ve URL denetimini yayın onayına bağlayın.

Sık Sorulan Sorular

Kaynaklar

• WordPress.org – Polylang özellikleri ve kurulum açıklamaları — wordpress.org
• WordPress Dokümantasyonu – Veritabanı ve dosya yedekleme — wordpress.org
• Google Search Central – Yerelleştirilmiş sayfalar ve hreflang — developers.google.com
• Google Search Central – Canonical URL belirleme — developers.google.com