Başarılı site taşıması, dosyaları kopyalamaktan daha fazlasıdır. Yeni ortamın doğrulanması, değişen verinin eşitlenmesi ve sorun halinde nasıl geri dönüleceğinin belirlenmesi gerekir.
Taşınan bileşenleri tek tek listeleyin
Web dosyaları, veritabanı, yüklenen medya, zamanlanmış görevler, kuyruk çalışanları, ortam değişkenleri, TLS sertifikası ve e-posta ayrı bileşenlerdir. Alan adı kaydı ve DNS başka bir sağlayıcıda olabilir. İlk iş, her bileşenin bugün nerede çalıştığını ve yeni ortamda kimin sorumlu olduğunu yazmaktır.
Uygulamanın sürüm ve eklenti gereksinimlerini de kaydedin. Yeni sunucuda daha yeni bir PHP veya veritabanı sürümü bulunması otomatik uyumluluk anlamına gelmez. Taşıma ile büyük sürüm yükseltmesini aynı anda yapmak sorun kaynağını ayırmayı zorlaştırabilir. Zorunlu değilse değişiklikleri ayrı doğrulama adımları olarak planlayın.
Geri yüklenebilir yedek alın
Dosya arşivi ve veritabanı dışa aktarımı aynı uygulama durumunu temsil etmeli. Sürekli sipariş veya içerik alan sistemlerde bağımsız zamanlarda alınmış kopyalar tutarsız olabilir. Uygulamanın desteklediği tutarlı yedek yöntemini kullanın, arşivin açıldığını ve veritabanının test ortamına yüklenebildiğini doğrulayın.
Yedeği yalnızca taşınacak sunucuda bırakmayın. Şifreli ve erişimi kontrollü başka bir konumda kopyası olsun. Geri yükleme komutları, gerekli sürümler ve anahtar erişimi de plana dahil edilmelidir. Yedekleme ve geri dönüş rehberi test ölçütlerini ayrıntılandırır.
DNS değişmeden yeni ortamı test edin
Uygulamayı yeni sunucuya kurun ve alan adını yeni IP’ye yerel olarak eşleyerek veya kontrollü bir test alan adıyla inceleyin. Test alan adı kullanıldığında canonical, mutlak bağlantı, çerez alanı ve ödeme geri dönüş adresleri farklı davranabilir. Bu farkları test notuna yazın; geçici adresin arama motorlarında indekslenmesini önleyin.
- Ana sayfa, kategori ve derin içerik adresleri açılıyor mu?
- Formlar, dosya yükleme ve arama işlemleri çalışıyor mu?
- Gerekli uzantılar, dosya izinleri ve zamanlanmış işler hazır mı?
- E-posta gönderimi ve harici API bağlantıları doğrulandı mı?
- Yönlendirmeler ve HTTPS doğru alan adına gidiyor mu?
Test ortamından gerçek müşterilere bildirim veya fatura gitmesini önleyin. Kuyrukları ve zamanlanmış görevleri canlıya geçişe kadar kontrollü tutun. Aynı görevin eski ve yeni sunucuda birlikte çalışması çift gönderim veya çift işlem oluşturabilir.
Değişen veriyi nasıl eşitleyeceksiniz?
Sadece okunan bir yayın sitesiyle sürekli sipariş alan bir mağazanın geçişi farklıdır. Yayın sitesinde kısa bir editör duraklaması yeterli olabilir. İşlemsel sistemde son veritabanı kopyası, yeni yüklenen dosyalar ve geçiş sırasında gelen işlemler için açık bir yöntem gerekir.
Basit bir taşımada kontrollü bakım penceresi açıp yazma işlemlerini durdurmak, son kopyayı almak ve yeni sistemde doğruladıktan sonra trafiği açmak uygulanabilir. Kesintisiz taşıma gerekiyorsa replikasyon ve veri tutarlılığı tasarımı daha kapsamlı uzmanlık ister. İki sunucuda eşzamanlı yazma açıp sonra dosyaları birleştirmeyi geri dönüş planı sanmayın.
DNS ve e-posta geçişi
DNS rehberindeki gibi A, AAAA, www ve diğer alt alan adlarını envantere alın. TTL ayarını geçişten önce planlayın. Nameserver değişecekse yeni bölgede tüm kayıtlar hazır olmalı; yalnızca web kaydını kopyalamak e-posta ve doğrulama kayıtlarını kaybettirebilir.
Geçişten sonra bazı ziyaretçiler önbellek nedeniyle eski sunucuya ulaşabilir. Eski ortamı hemen kapatmayın; ancak veri yazma davranışını planınıza uygun tutun. E-posta hizmeti de taşınıyorsa kutuların son eşitlemesi, gönderim kimlik doğrulaması ve dış teslim testleri ayrıca yapılmalıdır.
SEO açısından neler değişir?
Yalnızca hosting değişiyorsa URL’lerin değişmesi gerekmez. Aynı yollar, başlıklar, canonical ve içerik korunabiliyorsa gereksiz yönlendirme eklemeyin. Alan adı veya URL mimarisi de değişiyorsa eski-yeni URL haritasını ayrıca hazırlayın.
Geçici noindex işaretinin canlıya taşınması, robots.txt’nin tüm siteyi engellemesi ve eski test alan adına canonical verilmesi sık kontrol edilmesi gereken risklerdir. Yeni sunucuda 404 sayfasının gerçek 404 verdiğini ve sitemap’in canlı adresleri içerdiğini test edin. Yalnızca ana sayfanın açılması SEO taşımasının tamamlandığını göstermez.
Geri dönüş koşulunu önceden belirleyin
| Sorun | Karar örneği |
|---|---|
| Kritik form veya ödeme çalışmıyor | Yeni işlem alımını durdurup sorunu giderin veya veri uzlaştırmalı geri dönüş yapın. |
| Eski ve yeni sistemde farklı yeni kayıtlar var | Kör veritabanı üzerine yazmayın; kayıtları uzlaştırın. |
| Yalnızca bazı görseller eksik | Eksik dosya ve yol sorununu ölçerek sınırlı düzeltin. |
DNS’yi eski IP’ye çevirmek, yeni sunucuda oluşan veriyi geri taşımaz. Geri dönüş planında son değişikliklerin nasıl korunacağı açık olmalı. Geçiş tamamlandıktan sonra hata kayıtlarını, formları ve yedek işlerini yeniden kontrol edin; eski ortamı kapatma kararını gözlem ve veri eşitliğiyle verin.
Kaynaklar ve ek okuma
Platform belgeleri giriş gerektirebilir; arayüz ve özellikler sürüme göre değişebilir. Örnekler, ayrıca belirtilmedikçe temsili senaryolardır.
Bir düzeltme öneriniz mi var? Sayfa bağlantısıyla bildirin. · Kaynak ve yayın yaklaşımı