DNS yeni sunucuyu gösteriyor; ancak ziyaretçiler farklı yönlendirmeler, eksik görseller ve zaman zaman 500 hataları görüyor. wp-adminyalnızca sağlayıcının geçici adresinden açılırken ödeme bildirimleri eski sunucuya gitmeye devam ediyor.
Taşıma sonrası bozulan bir sitede önce isteğe hangi sunucunun yanıt verdiğini ve ilk gerçek hatanın nerede oluştuğunu belirlemek gerekir. Bu bulgular, yeni sunucuyu düzeltmekle eski sunucuya dönmek arasındaki kararı yönlendirir.
Taşıma sonrası sitenin bozulması ne demektir?
Taşınan WordPress verileri yeni sunucunun ayarlarıyla uyuşmadığında site doğru çalışmaz. Sorun WordPress'e ulaşmadan önce DNS veya TLS'de; WordPress içinde yapılandırma, kayıtlı URL, dosya ya da veritabanında; çevresinde ise önbellek, e-posta, cron, webhook veya dış depolama hizmetinde çıkabilir.
- Yönlendirmeleri ve günlükleri yorumlamadan önce her isteğe hangi sunucunun yanıt verdiğini belirleyin.
- Ziyaretçi sayfalarını, yönetim panelini, arka plan görevlerini ve dış hizmetlerden gelen bildirimleri ayrı ayrı sınayın.
- Sorun çözülene kadar yeni kayıtları hangi sunucunun kabul edeceğine karar verin.
Gerçekçi bir WordPress örneği
Mobil bağlantı kullanan bir müşteri geçerli sertifikayla yeni sunucuya ulaşıyor, ancak ürün görselleri hâlâ eski yükleme dizinine bakıyor. Ofisteki yönetici, tarayıcıda kayıtlı bir yönlendirme nedeniyle eski sunucuya gidiyor. Ödeme sağlayıcısı da bildirimleri eski adrese göndermeyi sürdürüyor. Bunlar tek bir rastgele WordPress hatası değil; ayrı ayrı düzeltilmesi gereken medya yolu, önbelleğe alınmış yönlendirme ve güncellenmemiş bildirim adresi sorunlarıdır.
Neden önemlidir ve ne zaman müdahale edilmelidir?
Ziyaretçiler önemli bir işlemi tamamlayamıyorsa veya sipariş, hesap ve form kayıtları iki sunucuya birden dağılmaya başladıysa hemen inceleme yapın. Yalnızca görünümü etkileyen bir sorun çoğu zaman yeni sunucuda düzeltilebilir. Verilerin ikiye ayrılması durumunda ise hangi sunucunun ana kaynak olacağı gecikmeden belirlenmelidir. Yeni sunucu geçiş süresi içinde kararlı hâle gelmezse veritabanları daha fazla ayrışmadan trafik eski sunucuya döndürülmelidir.
Yeni başlayanlar için anlaşılır yol
- Yeni sunucunun günlüklerini ve ayarlarını saklayın. Yanıt veren IP adresini ve sunulan sertifikayı belirleyip eski sunucuyla karşılaştırın.
home,siteurl,wp-config.php, veritabanı bilgileri, tablo öneki, yeniden yazma kuralları ve etkin web kökünü taşıma notlarıyla karşılaştırın.- URL değişikliklerinde serileştirilmiş verileri bozmayan bir araç kullanın. Kalıcı bağlantı ayarlarını WordPress üzerinden yeniden kaydedin ve yalnızca ilgili önbellekleri temizleyin.
- Önce kanıtlanan tek sorunu düzeltin ve yeni bir tarayıcı oturumundan deneyin. DNS, veritabanı, izin ve eklenti değişikliklerini aynı anda yapmayın.
- Birden fazla ağdan sayfaları, medyayı,
wp-admin'i, girişi, REST API'yi, cron'u, e-postayı, formları, ödemeleri, webhook'ları, aramayı ve yönlendirmeleri sınayın.
İleri teknik inceleme
Alan adını birden fazla genel DNS çözümleyicisinden sorgulayın; IP adresini, sertifikayı, yanıt başlıklarını ve yönlendirme zincirini not edin. Başarısız her isteği yeni sunucudaki web ve PHP günlükleriyle eşleştirin. PHP sürümü ve uzantıları, dosya sahipliği, büyük-küçük harf duyarlılığı, proxy başlıkları, nesne önbelleği ve cron çalışmasını eski sunucuyla karşılaştırın.
- WordPress hata ayıklamayı yalnızca sorunu kaydetmek için açın; günlükleri dış erişime kapatın ve ekranda hata gösterimini işiniz bitince devre dışı bırakın.
- Alan adı veya dizin yapısı değiştiyse serileştirilmiş verileri doğru işleyen bir WordPress aracı kullanın.
- Webhook ve zamanlanmış işleri, aynı olayın iki sunucuda birden işlenmesini önleyecek şekilde sınayın.
Riskler, sık hatalar ve geri dönüş planı
- Yanlış yanıtın hangi sunucudan geldiğini bulmadan bütün önbellekleri gelişigüzel temizlemeyin.
- DNS, veritabanı, izin ve eklenti ayarlarını aynı anda değiştirmek hangi düzeltmenin işe yaradığını belirsizleştirir.
- İnceleme sırasında e-posta, cron veya ödeme bildirimlerini iki sunucuda birden etkin bırakmayın.
- Yeni site tüm kabul kontrollerini geçene kadar taşıma öncesi paketi ve eski sunucuyu koruyun.
Basit bir geri dönüş, yalnızca bir sunucu ana veri kaynağı olarak kaldığı sürece mümkündür. Yalnızca yeni sunucuda bulunan sipariş veya hesap kayıtları oluştuysa trafiği geri çevirmeden önce bu verileri saklayın ve eski siteyle nasıl birleştirileceğini planlayın.
AIOWS nasıl yardımcı olur?
AIOWS Yedekleme Yöneticisi
AIOWS Yedekleme Yöneticisi, yeni sunucuyu incelerken taşıma öncesinde doğrulanmış paketi hazır tutmanıza yardımcı olur. Bu paketle beklenen dosya ve veritabanı durumunu hedef sunucuyla karşılaştırabilir, taşınan kopyada eksik varsa ilgili WordPress bölümünü geri yükleyebilirsiniz.
DNS, sertifika, sunucu izinleri, e-posta yönlendirmesi ve dış hizmetlerin bildirim adresleri modülün kapsamı dışındadır; bunlar barındırma geçişinin ayrı parçalarıdır. Desteklenen bir geri yüklemeden sonra sorunun görüldüğü ziyaretçi sayfalarını, yönetim panelini, medyayı, cron görevlerini ve ödeme akışını yeniden sınayın.
Düzeltilen site belirlenen gözlem süresini tamamlamadan son çalışan paketin üzerine yazmayın. Geri dönüş gerekirse eski sunucu ve bu paket başlangıç noktası olur; yalnızca yeni sunucuda oluşan veriler ayrıca korunmalıdır.
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ş
- WordPress Taşıma Kontrol Listesi: Öncesi ve Sonrası
- Taşıma Sonrası WordPress URL Değiştirme: Güvenli Rehber
Sonuç ve önerilen yol
Önce isteğe hangi sunucunun yanıt verdiğini ve hatanın nerede çıktığını belirleyin. Kanıtlanan nedenleri tek tek düzeltip ilgili kullanıcı yolunu her adımda yeniden sınayın. Geçiş için ayrılan süre dolarsa ziyaretçileri ve yeni verileri iki sunucuya bölmek yerine önceden kararlaştırılan şekilde eski sunucuya dönün.
