Temel çıkarım: bir WordPress taşıması, adımlar yanlış sırada gerçekleştiğinde kesintiye neden olur — yeni site doğrulanmadan DNS değiştirilir, veya veritabanı zaten dışa aktarıldıktan sonra eski sitede içerik değişir. İşi yeni ortamda paralel olarak yapmak, geçişten önce tamamen test etmek ve DNS TTL'ini önceden düşürmek, geçişi ziyaretçilere görünmez kılan şeydir.
Taşımalar Neden Genellikle Kesintiye Neden Olur
Bir WordPress sitesini taşımanın varsayılan, plansız yolu — veritabanını dışa aktar, dosyaları kopyala, DNS'i yeni sunucuya yönlendir, sonra bozulanı düzeltmeye başla — sitenin ya tamamen çöktüğü ya da yarı taşınmış, bozuk bir sürümü sunduğu bir pencere yaratır. Bu sıradaki her adım canlı sitenin kendisinde gerçekleşir, bu yüzden herhangi bir hata ziyaretçilere anında görünür.
Sıfır kesintili taşıma, sırayı tersine çevirerek bunu çözer: eskisi dokunulmadan trafiğe hizmet vermeye devam ederken yeni ortamı oluştur ve tamamen doğrula, ve sadece her şey çalışır durumda doğrulandıktan sonra geçiş yap. Taşıma işi hiçbir zaman doğrudan canlı sitede gerçekleşmediği için canlı site hiçbir zaman ara, bozuk bir durumda kalmaz.
Taşıma Öncesi Kontrol Listesi
- Mevcut sitenin dosyalarının ve veritabanının tam bir yedeğini al, mevcut hosting hesabının dışında bir yerde saklanmış olarak.
- Planlanan geçişten en az 24-48 saat önce, domain'in A kaydındaki DNS TTL'ini 300 saniyeye (5 dakika) düşür — bunu önceden zamanlamanın neden önemli olduğuna dair teknik detaya aşağıda bak.
- Aktif eklentileri ve temaları envanterle, sürümleri not et, çünkü yeni ortamın PHP sürümü ve eklenti gereksinimleriyle eşleşmesi gerekiyor.
- Yeni host'un tamamen kurulduğunu doğrula — WordPress kurulu, taşınan dosyaları ve veritabanını almaya hazır, ama henüz domain'e herkese açık şekilde bağlı değil.
Adım 1: Başlamadan Önce DNS TTL'ini Düşür
DNS TTL (yaşam süresi), internetteki çözümleyicilerin bir domain'in mevcut IP adresini tekrar kontrol etmeden önce ne kadar süre önbelleğe aldığını kontrol eder. Birkaç saatlik (bazen 24 veya daha fazla) tipik bir varsayılan TTL, DNS yeni sunucuya işaret edecek şekilde güncellendikten sonra bile, ziyaretçilerin önemli bir kısmının çözümleyicilerinin önbelleğe alınmış kopyası süresi dolana kadar eski sunucuya erişmeye devam ettiği anlamına gelir. Cloudflare'in DNS TTL üzerine kendi açıklaması bu mekanizmayı daha teknik derinlikte ele alıyor.
TTL'i gerçek geçişten bir veya iki gün önce 300 saniyeye düşürmek, DNS değiştiğinde yayılma gecikmesinin saatler yerine dakikalar olması anlamına gelir — gerçekten düşük kesintili bir geçiş için en etkili tek hazırlık adımı.
Adım 2: Yeni Ortamı Paralel Olarak Kur
WordPress'i yeni host'ta canlı siteden tamamen bağımsız olarak kur — aynı PHP sürümü, aynı gerekli eklentiler, içerik almaya hazır ama henüz herkese görünür şekilde canlı domain'e bağlı değil. "Sıfır kesinti"yi mümkün kılan adım bu: tüm kurulum işi henüz kimsenin ziyaret etmediği bir altyapıda gerçekleşir.
Adım 3: Dosyaları ve Veritabanını Taşı
Duplicator veya All-in-One WP Migration eklentisi gibi araçlar, sitenin dosyalarını ve veritabanını tek bir aktarılabilir arşive paketler, temiz bir veritabanı dışa/içe aktarımının teknik detaylarını halleder. Sık taşıma yapan ajanslar için, yönetilen hosting platformlarına yerleşik bir host-to-host taşıma aracı (Kinsta, WP Engine ve diğerleri bunu sunuyor) genellikle süreci daha az manuel işle halleder.
Burada kaçınılması gereken belirli bir teknik tuzak: domain'i eski URL'den yeniye güncellemek için veritabanında düz bir bul-değiştir çalıştırma. WordPress, birçok widget, bazı eklenti ayarları ve tema seçenekleri tarafından kullanılan serialize edilmiş PHP verisini, gömülü bir karakter uzunluğu ön eki olan string'ler olarak saklar. Basit bir metin değiştirme, o ön eki güncellemeden string'in uzunluğunu değiştirir, veriyi sessizce bozar. WP-CLI'nin search-replace komutu serialize edilmiş veriyi doğru şekilde ele almak için özel olarak yapılmıştır ve tam olarak bu adım için standart araçtır.
Adım 4: Kendi Hosts Dosyanı Kullanarak Yeni Siteyi Test Et
Herkese açık DNS'e dokunmadan önce, domain'i yeni sunucunun IP adresine yönlendirmek için kendi bilgisayarının yerel hosts dosyasını düzenle — bu sadece senin makineni etkiler, başka hiçbir ziyaretçi etkilenmeden gerçek domain adını kullanarak yeni siteye göz atmana (giriş, ödeme, iletişim formları ve domain'in eşleşmesine bağlı başka her şeyi test etmek dahil) izin verir. Bu, taşıma sorunlarını herkese açık hale gelmeden önce yakalayan adımdır.
Adım 5: Taşıma Penceresinde Yapılan İçerik Değişikliklerini Uzlaştır
Canlı site, veritabanı dışa aktarıldıktan sonra yorumlar, siparişler veya form gönderimleri almaya devam ettiyse, bu içerik eski sitede var ama yenisinde yok. Çoğu tanıtım sitesi için bu pencere görmezden gelinecek kadar küçüktür; işlemsel herhangi bir şey için (e-ticaret, üyelik içeriği), taşıma penceresi sırasında oluşturulan yeni kayıtları dışa aktar ve geçişten önce yeni veritabanına içe aktar.
Adım 6: DNS'i Geçiş Yap
Yeni site hosts dosyası yöntemiyle tam olarak test edildikten ve herhangi bir içerik boşluğu uzlaştırıldıktan sonra, domain'in DNS A kaydını yeni sunucuya işaret edecek şekilde güncelle. TTL önceden düşürüldüğü için, çoğu ziyaretçi saatler yerine dakikalar içinde yeni sunucuya çözümlenir.
Adım 7: Geçişten Sonra Doğrula ve İzle
- Yeni sunucuda domain için SSL'in aktif olduğunu doğrula, çünkü eksik veya yanlış yapılandırılmış bir sertifika HTTPS erişimini anında bozar.
- Veritabanında veya tema dosyalarında kalan herhangi bir sabit kodlu http:// URL'inin neden olduğu karma içerik uyarılarını kontrol et.
- Taşıma bir URL yapısı değişikliği içeriyorsa yönlendirmelerin hâlâ çalıştığını doğrula, ve sonraki günlerde tarama hatalarında bir artış için Google Search Console'u kontrol et.
- Önceden çalışan URL'lerde 404'ler için sunucu loglarını izle, bu genellikle kaçırılan bir dosyaya veya eksik bir search-replace'e işaret eder.
Bir Bakışta Taşıma Zaman Çizelgesi
| Aşama | Zamanlama | Anahtar Eylemler |
|---|---|---|
| Taşıma öncesi | 24-48 saat önce | DNS TTL'ini düşür, yedek al, yeni host'un hazır olduğunu doğrula |
| Paralel kurulum | Geçişten önce | Yeni ortamı kur, dosyaları/veritabanını uygun bir araçla taşı |
| Doğrulama | Geçişten önce | Gerçek domain'i kullanarak yerel hosts dosyası üzerinden test et |
| Geçiş | Taşıma günü | Herhangi bir içerik boşluğunu uzlaştır, DNS'i değiştir |
| Taşıma sonrası | İlk 48-72 saat | SSL'i doğrula, karma içeriği kontrol et, logları ve Search Console'u izle |
Yaygın Taşıma Hataları
- DNS TTL düşürme adımını atlamak, geçiş yayılmasını eski TTL'nin ne olarak ayarlandığının insafına bırakmak.
- Veritabanında serialization'ı bilen bir araç (WP-CLI'nin search-replace'i gibi) yerine düz bir bul-değiştir çalıştırmak, widget ve tema ayarlarını sessizce bozmak.
- Yeni siteyi test etmeden DNS'i değiştirmek, bozuk bir eklentiyi veya eksik bir dosyayı ancak ziyaretçiler ona ulaşmaya başladıktan sonra keşfetmek.
- Taşıma penceresinde oluşturulan içeriği unutmak, dışa aktarımdan sonra eski sitede kalan yorumları, siparişleri veya gönderimleri kaybetmek.
- Geçişten önce yeni sunucuda SSL'i doğrulamamak, DNS değiştiği anda görünür bir sertifika uyarısına neden olmak.
Bir Müşteriye İlerleme Gösterirken Yardım Alınacak Zaman
Bir müşterinin sitesini taşıyan ajanslar, genellikle gerçek geçişten önce onay için paralel yeni ortamı göstermeye ihtiyaç duyar — hosting kimlik bilgilerini devretmeden veya teknik olmayan bir müşterinin takip etmesi için kafa karıştırıcı bir hosts dosyası çözümü olmadan. Erdo Client Preview veya Erdo Draft Links gibi bir araç, müşteriye yeni siteyi doğrudan incelemesi için basit bir bağlantı verir, bu da WordPress staging rehberimizde ele alınan test alışkanlıklarıyla ve hedef host'un kendisini değerlendirmek için daha geniş WordPress hız ve hosting rehberimizle doğal olarak eşleşir.
Özetle
Kısacası, sıfır kesintili bir WordPress taşıması sıralamaya bağlıdır: DNS TTL'ini önceden iyi düşür, yeni ortamı herkese açık DNS yerine kendi hosts dosyanı kullanarak paralel olarak kur ve tamamen test et, herhangi bir URL güncellemesi için serialization'ı bilen bir araç kullan, ve sadece her şey çalışır durumda doğrulandıktan sonra DNS'i değiştir. Bu sırayı takip et ve canlı site hiçbir zaman ara, bozuk bir durumda kalmaz — ziyaretçiler, yeni sunucu zaten hazır olduğu doğrulandıktan sonra sadece ona çözümlenir.