Deneme sitesi geçici bir alt alan adından canlı alan adına taşındı. İki temel seçenek değiştirildiğinde ana sayfa doğru görünüyor; ancak görseller, sayfa oluşturucu düğmeleri, bileşenler, kanonik etiketler ve giriş çerezleri hâlâ geçici adresi kullanıyor.
Taşıma sonrasında yalnızca gerçekten değişmesi gereken URL'leri güncellemek, serileştirilmiş WordPress verisini korumak ve kolayca gözden kaçan bağlantıları denetlemek gerekir.
WordPress URL'lerini değiştirmek neleri kapsar?
URL değişikliği; sitenin genel adresini, WordPress dosyalarının bulunduğu adresi ve içerik, meta veri, bileşen ya da eklenti tablolarında saklanan mutlak bağlantıları etkileyebilir. homeziyaretçilerin kullandığı adresi, siteurlise WordPress kurulumunun bulunduğu yeri belirtir. Genellikle aynı olsalar da görevleri farklıdır.
Birçok WordPress değeri serileştirilmiş biçimde saklanır ve içindeki metnin uzunluğunu da kaydeder. Düz SQL değişikliği metni güncelleyip bu uzunluk bilgisini düzeltmezse değer okunamaz hâle gelebilir. DNS, TLS, proxy kuralları, sunucu yönlendirmeleri, önbellekler ve dış hizmetlerin geri çağrı adresleri veritabanı değişikliğinden ayrı ele alınmalıdır.
Gerçekçi bir WordPress örneği
Bir deneme sitesi preview.example.comadresinden canlı alan adına taşınıyor. homeve siteurldeğiştirildiğinde ana menü çalışıyor, ancak sayfa oluşturucu geçici adresi serileştirilmiş meta veride tutmaya devam ediyor. Görseller eski sunucudan yükleniyor, kanonik bağlantılar tarayıcıdaki adresle uyuşmuyor ve parola sıfırlama bağlantıları deneme sitesine gidiyor. Veritabanındaki bu değerler serileştirilmiş yapıyı koruyan bir araçla değiştirilirken e-posta hizmetinin geri çağrı adresi kendi ayarından güncellenmelidir.
Neden önemlidir ve URL'ler ne zaman değiştirilmelidir?
Alan adı, protokol, alt dizin veya kurulum yolu gerçekten değiştiyse kayıtlı URL'leri güncelleyin. Yalnızca DNS yeni sunucuya yönelmiş ve genel adres aynı kalmışsa veritabanının tamamında değişiklik yapmak gerekmez. Yönlendirme döngülerini ayrıca inceleyin; eski bir veritabanı değeri, ters proxy, web sunucusu, WordPress veya CDN ayrı ayrı yönlendirme üretebilir.
Yeni başlayanlar için anlaşılır yol
- Hedef veritabanını yedekleyin; eski ve yeni URL'yi, protokolü, dizin yolunu, tablo önekini, ağ kapsamını ve değişiklik dışında bırakılacak sütunları not edin.
- Önce
homevesiteurldeğerlerini doğrulayın.wp-config.phpiçindeki geçici tanımları yalnızca yönetim paneline yeniden erişmek için kullanın. - Serileştirilmiş verileri doğru işleyen bir araçla önce deneme çalışması yapın. Etkilenecek tabloları ve eşleşme sayılarını inceleyin; belgelenmiş özel bir durum yoksa GUID değerlerine dokunmadan yalnızca eski adresin tam eşleşmelerini değiştirin.
- Kayıtlı değerler ve sunucu yönlendirmeleri düzeldikten sonra ilgili WordPress, nesne, sayfa, tarayıcı ve CDN önbelleklerini temizleyin.
- Örnek sayfaları tarayın; medyayı, menüleri, sayfa oluşturucu içeriklerini, bileşenleri, REST API'yi, girişi, parola sıfırlamayı, kanonik bağlantıları, site haritasını, yönlendirmeleri, formları ve dış hizmetlerin geri çağrı adreslerini sınayın.
İleri teknik yöntem
WP-CLI search-replaceveya serileştirilmiş verileri anlayan başka bir araç kullanın. Deneme çalışmasıyla başlayın, tablo kapsamını sınırlayın, eşleşme sayılarını inceleyin ve komutu, hariç tutulanları, çıktıyı ve çıkış kodunu saklayın. Belgelenmiş özel bir gereksinim yoksa GUID değerlerini değiştirmeyin.
- Multisite kurulumlarında ağ tabloları, siteye özel tablolar, alan adı eşleme ve yükleme dizinleri ayrı ayrı planlanmalıdır.
- Eski protokol, alan adı, port ve dizin yolunu tam olarak arayın; çok genel metinler ilgisiz içerikleri veya e-posta adreslerini değiştirebilir.
- İşlemden sonra eski alan adını yeniden arayın ve kalan her eşleşmeyi otomatik silmek yerine ne olduğunu belirleyin.
Riskler, sık hatalar ve geri dönüş planı
- Düz SQL değişikliği tema ve eklentilerin serileştirilmiş ayarlarını bozabilir.
siteurldeğerinin yanlış ayarlanması yönetim paneline ve WordPress dosyalarına erişimi kesebilir.- GUID değerlerini gereksiz yere değiştirmek besleme okuyucularını ve diğer dış alıcıları etkileyebilir.
- Veriler ve yönlendirmeler düzelmeden önbelleği temizlemek asıl sorunu çözmez ve incelemeyi zorlaştırabilir.
Değişiklikten hemen önce hedef veritabanını yedekleyin ve deneme çalışmasındaki eşleşme sayılarını saklayın. Kontroller başarısız olursa bu veritabanı kopyasını geri yükleyin, yalnızca geri dönüşten etkilenen önbellekleri temizleyin ve eski-yeni URL kapsamını yeniden belirleyin.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, kayıtlı URL'ler veya ortama özgü ayarlar değiştirilmeden önce gereken desteklenen kurtarma noktasını oluşturabilir. Hedef veritabanını ve mevcut site durumuna dönmek için gerekli dosyaları kapsama alın; paketin nerede saklandığını doğrulayın.
URL değişikliği için serileştirilmiş WordPress verilerini doğru işleyen ayrı bir araç gerekir. Yedekleme Yöneticisi DNS'i, proxy kurallarını, sunucu yönlendirmelerini veya dış hizmetlerin geri çağrı adreslerini değiştirmez. Veritabanı işleminden sonra home, siteurl, medya, menüler, bileşenler, giriş, yönlendirmeler, kanonik bağlantılar, formlar ve geri çağrı adreslerini denetleyin.
Yeni alan adı bu testleri geçene kadar paketi saklayın. Değişiklik kayıtlı değerleri bozduysa veya erişimi kestiyse durumu daha da belirsizleştirecek ikinci bir geniş kapsamlı değişiklik yapmak yerine işlem öncesi veritabanını geri yükleyin.
AIOWS Yedekleme Yöneticisi'ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Site Taşıma: Yeni Sunucuya Güvenli Geçiş
- Taşıma Sonrası WordPress Sitesi Bozuldu: Çözüm Rehberi
- WordPress Taşıma Kontrol Listesi: Öncesi ve Sonrası
Sonuç ve önerilen yol
Önce hedef veritabanını yedekleyin ve homeile siteurldeğerlerini bilinçli olarak belirleyin. Deneme çalışmasıyla kapsamı kontrol ettikten sonra yalnızca eski adresin tam eşleşmelerini değiştirin. İlgili önbellekleri daha sonra temizleyin; görünen sayfalarla birlikte dış hizmetlerin geri çağrı adreslerini de sınayın. Kalan eşleşmeleri topluca silmeden önce ne olduklarını inceleyin.
