- Konu sahibi
- #1
WordPress alan adı değişikliğinde tutarlılığı sağlamak için yalnızca Ayarlar ekranındaki site adresini değiştirmek yeterli değildir. Veritabanındaki yazı bağlantıları, görsel yolları, menü kayıtları, widget ayarları ve eklenti seçenekleri de eski alan adından yeni alan adına dönüştürülmelidir. Bu işlemden önce dosya ve veritabanı yedeği alınmalı; değişiklik sonrasında kalıcı bağlantılar, medya dosyaları, yönlendirmeler ve HTTPS durumu kontrol edilmelidir.
Aşağıdaki örnekte eski alan adı
Örnek standart tek site içindir. Aynı veritabanında başka siteler varsa --all-tables tüm tabloları değiştirir; burada yalnız bu kurulumun prefix’ini kapsayan --all-tables-with-prefix kullanılır, yine tablo listesini denetleyin. Multisite ve domaine bağlı özel eklentiler ayrıca planlanmalıdır. Trafiğin veri yazdığı işlemleri taşıma anında durdurup tutarlı yedek alın.
WordPress alan adını birden fazla yerde kullanır:
Bu nedenle veritabanında basit bir
Komutun deneme çıktısında hiç kayıt bulunmaması her zaman hata anlamına gelmez; içerik zaten yeni alan adını kullanıyor olabilir. Buna karşılık komut hata verirse işlemi tekrar tekrar çalıştırmak yerine hata mesajını ve yedeği inceleyin. Özellikle veritabanı bağlantısı, tablo öneki, yetki veya WP-CLI'nin doğru WordPress kurulumunu bulamaması kontrol edilmelidir.
Alan adı değişikliğinde farklı içerik türleri farklı sorunlar doğurur:
Yeni alan adı HTTPS kullanıyorsa, eski HTTP kaynaklarının sayfada kalması tarayıcı tarafından engellenebilir. Bu durumda yalnız ana bağlantıyı değil, içerik ve tema ayarlarında kalan HTTP kaynaklarını da kontrol edin. Ancak her HTTP metnini körlemesine HTTPS ile değiştirmek yerine, gerçekten yeni alan adına ait kaynakları ayırın.
Sadece site adresini değiştirmek: Bu işlem veritabanındaki içerik ve eklenti kayıtlarını kendiliğinden düzeltmez.
Serileştirilmiş veriyi SQL ile parçalamak: Serileştirilmiş metinlerin bayt uzunlukları değiştiğinde bazı widget, tema veya eklenti ayarları bozulabilir. Serileştirme uyumlu araç kullanın.
Yedeği işlemden sonra almak: Hatalı bir değişiklikten geri dönebilmek için yedek, arama-değiştirme işleminden önce alınmalıdır.
Eski alan adını hemen kaldırmak: Yönlendirme kurulmadan eski alan adını kapatmak, eski bağlantıların ve bazı doğrulama süreçlerinin çalışmamasına yol açabilir.
Arama-değiştirmeyi sınırsız çalıştırmak: Alan adının parçası başka bir metinde geçiyorsa beklenmeyen değişiklik yapılabilir. Önce deneme modu, ardından kapsamı kontrol edilmiş tek bir işlem kullanın.
Önce WordPress adresinin (siteurl) çekirdek dosyalarının, site adresinin (home) ziyaretçiye sunulan ön yüzün doğru yeni konumunu gösterdiğini kontrol edin. Alt dizinli kurulumda bunların yollarının aynı olması zorunlu değildir; WP_HOME/WP_SITEURL sabitlerini de inceleyin. Ardından önbelleği temizleyin; sunucu, CDN ve HTTPS yönlendirmelerinin birbirini tekrar tekrar yönlendirmediğini inceleyin.
Görselin içerikteki yolu, tema CSS'i veya eklenti ayarı eski alan adını taşıyor olabilir. Sayfanın kaynak ve ağ isteklerinde eski alan adını arayın; yalnız ilgili kayıtları serileştirme uyumlu araçla düzeltin ve CDN önbelleğini temizleyin.
Genellikle amaç, eski alan adını çalışan içerik ve ayarlardan kaldırırken eski ziyaretçileri yeni adrese yönlendirmektir. Bu nedenle veritabanı temizliği ile sunucu yönlendirmesi ayrı işlemler olarak ele alınmalı; eski alan adının yönlendirme için gerekli olduğu sürece erişilebilir kalması sağlanmalıdır.
Aşağıdaki örnekte eski alan adı
https://eski.example.com, yeni alan adı ise https://yeni.example.com kabul edilmiştir. Gerçek alan adlarınızı bunlarla değiştirmelisiniz.Örnek standart tek site içindir. Aynı veritabanında başka siteler varsa --all-tables tüm tabloları değiştirir; burada yalnız bu kurulumun prefix’ini kapsayan --all-tables-with-prefix kullanılır, yine tablo listesini denetleyin. Multisite ve domaine bağlı özel eklentiler ayrıca planlanmalıdır. Trafiğin veri yazdığı işlemleri taşıma anında durdurup tutarlı yedek alın.
Değişiklik mantığı
WordPress alan adını birden fazla yerde kullanır:
- wp_options tablosunda site adresi ve WordPress adresi bulunur.
- Yazı ve sayfa içeriklerinde eski alan adına ait bağlantılar yer alabilir.
- Görsel URL'leri, menüler, widget'lar ve eklenti ayarları veritabanında tutulabilir.
- Bazı PHP dizileri serileştirilmiş biçimde saklanır. Bu alanlarda düz metinle yapılan kontrolsüz değişiklik, veri yapısını bozabilir.
- Önbellekler, CDN ayarları, robots.txt, sitemap ve SSL yönlendirmeleri de yeni alan adıyla uyumlu olmalıdır.
Bu nedenle veritabanında basit bir
UPDATE ... REPLACE() sorgusu çalıştırmak güvenli bir genel çözüm değildir. Serileştirilmiş verileri tanıyan bir WordPress aracı kullanılmalıdır.Uygulanabilir işlem sırası
- Tam yedek alın. Dosyaları ve veritabanını ayrı ayrı saklayın. Yedeğin gerçekten geri yüklenebilir olduğunu kontrol etmeden eski kopyayı silmeyin.
- Yeni alan adını sunucuya bağlayın. DNS kaydı, barındırma yapılandırması ve SSL sertifikası hazır olmadan WordPress adresini değiştirmeyin. Önce yeni alan adının aynı WordPress dosyalarına ve veritabanına ulaştığını doğrulayın.
- Veritabanındaki alan adını serileştirme uyumlu araçla değiştirin. WP-CLI erişiminiz varsa WordPress kök dizininde şu komutla önce deneme yapın:
Deneme çıktısı değiştirilecek kayıtları gösteriyorsa aynı komutuKod:wp search-replace 'https://eski.example.com' 'https://yeni.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run--dry-runseçeneği olmadan çalıştırın.--skip-columns=guidseçeneği, yazıların özgün kimlik değerlerini gereksiz yere değiştirmemek içindir. WP-CLI yoksa, serileştirilmiş verileri destekleyen güvenilir bir taşıma aracı kullanın; doğrudan SQL ile toplu değiştirme yapmayın. - WordPress adreslerini doğrulayın. Yönetim panelinde WordPress adresi ve site adresinin yeni alan adını gösterdiğini kontrol edin. Panel açılmıyorsa bu değerler geçici olarak yapılandırma dosyasından sabitlenebilir; ancak aynı ayarı iki farklı yerde çelişkili bırakmayın.
- Kalıcı bağlantıları yeniden kaydedin. Yönetim panelindeki kalıcı bağlantılar ekranını açıp ayarları değiştirmeden kaydedin. Bu işlem yeniden yazma kurallarının yenilenmesine yardımcı olur.
- Eski alan adından kalıcı yönlendirme kurun. Eski alan adını tamamen kapatmak yerine, aynı yol yapısını koruyarak yeni alan adına kalıcı yönlendirme yapın. Böylece eski bağlantılardan gelen ziyaretçiler ve daha önce paylaşılmış URL'ler boşa düşmez.
- Kontrol listesiyle test edin. Ana sayfayı, bir yazıyı, bir sayfayı, görsel içeren bir içeriği, iletişim formunu, yönetici girişini, arama özelliğini ve sitemap dosyasını test edin. Tarayıcı geliştirici araçlarında eski alan adına giden istekleri de arayın.
- Önbellekleri temizleyin. WordPress önbelleği, sunucu önbelleği, CDN ve tarayıcı önbelleği ayrı katmanlardır. Eski HTML veya eski JavaScript yükleniyorsa ilgili katmanı temizleyip testi tekrarlayın.
Komutun deneme çıktısında hiç kayıt bulunmaması her zaman hata anlamına gelmez; içerik zaten yeni alan adını kullanıyor olabilir. Buna karşılık komut hata verirse işlemi tekrar tekrar çalıştırmak yerine hata mesajını ve yedeği inceleyin. Özellikle veritabanı bağlantısı, tablo öneki, yetki veya WP-CLI'nin doğru WordPress kurulumunu bulamaması kontrol edilmelidir.
Hangi veriyi nasıl kontrol etmeli?
Alan adı değişikliğinde farklı içerik türleri farklı sorunlar doğurur:
| Kontrol alanı | Olası belirti | Uygulanacak işlem |
|---|---|---|
| Site ve WordPress adresi | Yönetim paneli yanlış adrese gider | Yeni alan adıyla eşleştiğini doğrula |
| Yazı ve sayfa içerikleri | Bağlantılar eski alan adına gider | Serileştirme uyumlu aramayla değiştir |
| Medya ve tema ayarları | Görseller veya stiller yüklenmez | Medya yollarını, tema ayarlarını ve karma içerik uyarılarını incele |
| Kalıcı bağlantılar | Sayfalar 404 döndürür | Yeniden yazma kurallarını kaydet ve sunucu yönlendirmesini kontrol et |
Yeni alan adı HTTPS kullanıyorsa, eski HTTP kaynaklarının sayfada kalması tarayıcı tarafından engellenebilir. Bu durumda yalnız ana bağlantıyı değil, içerik ve tema ayarlarında kalan HTTP kaynaklarını da kontrol edin. Ancak her HTTP metnini körlemesine HTTPS ile değiştirmek yerine, gerçekten yeni alan adına ait kaynakları ayırın.
Sık yapılan hatalar
Sadece site adresini değiştirmek: Bu işlem veritabanındaki içerik ve eklenti kayıtlarını kendiliğinden düzeltmez.
Serileştirilmiş veriyi SQL ile parçalamak: Serileştirilmiş metinlerin bayt uzunlukları değiştiğinde bazı widget, tema veya eklenti ayarları bozulabilir. Serileştirme uyumlu araç kullanın.
Yedeği işlemden sonra almak: Hatalı bir değişiklikten geri dönebilmek için yedek, arama-değiştirme işleminden önce alınmalıdır.
Eski alan adını hemen kaldırmak: Yönlendirme kurulmadan eski alan adını kapatmak, eski bağlantıların ve bazı doğrulama süreçlerinin çalışmamasına yol açabilir.
Arama-değiştirmeyi sınırsız çalıştırmak: Alan adının parçası başka bir metinde geçiyorsa beklenmeyen değişiklik yapılabilir. Önce deneme modu, ardından kapsamı kontrol edilmiş tek bir işlem kullanın.
Kaynaklar
Sık sorulan sorular
Alan adı değişikliğinden sonra giriş sayfası sürekli yönlendiriyorsa ne yapılmalı?
Önce WordPress adresinin (siteurl) çekirdek dosyalarının, site adresinin (home) ziyaretçiye sunulan ön yüzün doğru yeni konumunu gösterdiğini kontrol edin. Alt dizinli kurulumda bunların yollarının aynı olması zorunlu değildir; WP_HOME/WP_SITEURL sabitlerini de inceleyin. Ardından önbelleği temizleyin; sunucu, CDN ve HTTPS yönlendirmelerinin birbirini tekrar tekrar yönlendirmediğini inceleyin.
Değişiklikten sonra bazı görseller neden hâlâ görünmez?
Görselin içerikteki yolu, tema CSS'i veya eklenti ayarı eski alan adını taşıyor olabilir. Sayfanın kaynak ve ağ isteklerinde eski alan adını arayın; yalnız ilgili kayıtları serileştirme uyumlu araçla düzeltin ve CDN önbelleğini temizleyin.
Eski alan adını veritabanından tamamen silmek gerekir mi?
Genellikle amaç, eski alan adını çalışan içerik ve ayarlardan kaldırırken eski ziyaretçileri yeni adrese yönlendirmektir. Bu nedenle veritabanı temizliği ile sunucu yönlendirmesi ayrı işlemler olarak ele alınmalı; eski alan adının yönlendirme için gerekli olduğu sürece erişilebilir kalması sağlanmalıdır.
