Safer Moves için WordPress Taşıma Vaka İncelemesi
9 Ağustos 2026 tarihinde yayınlandı
Bir WordPress taşıma vaka incelemesi, “siteleri bu hafta sonu taşıyalım” şeklindeki neşeli plan ile her alan adının yeniden doğru şekilde hizmet verdiği an arasında neler olduğunu gösterdiğinde en faydalı olur. İşte taşımaların ününü kazandığı kısım burasıdır. Dosyalar, veritabanları, DNS, SSL sertifikaları, e-posta ayarları, cron işlerini, önbellekleme ve eklenti davranışlarının hepsinin söyleyecek bir şeyi olabilir.
Bu örnek, 18 WordPress web sitesini kalabalık bir paylaşımlı barındırma ortamından yönetilen bir Linux sunucusuna taşıyan küçük bir dijital ajansı takip ediyor. Hedefleri açıktı: sayfa hızını artırmak, her müşteriye daha net hesap sınırları sağlamak, tekrar eden destek taleplerini azaltmak ve her güncellemeyi küçük bir üretim olayı gibi ele almayı bırakmak.
Sonuç sihir değildi. Yapılandırılmış bir taşınma, en yoğun siteler için kısa bir bakım penceresi ve yayına alındıktan sonra sunucuyu yönetmek için daha iyi bir yöntemdi.
Başlangıç noktası: 18 site, fazlasıyla çok taviz
Ajans zaman içinde kademeli olarak büyümüştü. Yeni müşteri siteleri aynı barındırma hesabına ekleniyordu; çoğu zaman son sefer işe yarayan kurulum kopyalanıyor, ayrıntılar ise sonra düzeltiliyordu. Tanıdıktı, ama artık rahat değildi.
Bir e-ticaret sitesindeki trafik artışı, ilgisiz tanıtım sitelerini etkileyebilirdi. Hazırlık kopyaları çeşitli yerlerde bulunuyordu. Yedekler vardı, ancak kimse tam olarak ihtiyaç duyulan siteyi hangi yedeğin geri yükleyeceğini güvenle söyleyemiyordu. Ajansın ayrıca CPU, bellek ve disk kullanımına dair görünürlüğü sınırlıydı; bu nedenle yavaş bir web sitesini teşhis etmek genellikle tahminle başlıyordu.
Barındırma sağlayıcısı bir taşıma hizmeti sunuyordu, ancak ajans kendi takvimine göre ilerlemek ve sonrasında hesapların, erişimin ve yedeklerin nasıl çalışacağı üzerinde kontrolü elinde tutmak istiyordu. Bu gereksinim önemliydi. Bir taşıma yalnızca bir siteyi başka bir sunucuya aktarmakla ilgili değildir. En başta sürtüşme yaratan kurulum kararlarını tekrar etmeyi bırakmak için bir fırsattır.
WordPress taşıma vaka incelemesi: taşıma planı
Ajans işi üç gruba ayırdı: düşük trafikli pazarlama siteleri, içerik ağırlıklı yayıncı siteleri ve kısa bir kesintinin bile gerçek paraya mal olabileceği e-ticaret veya potansiyel müşteri oluşturma siteleri. Bu sınıflandırma, taşıma sırasını ve gereken kontrol düzeyini belirledi.
Herhangi bir şeyi kopyalamadan önce ekip, her alan adı için bir envanter oluşturdu. Buna WordPress sürümü, PHP sürümü, veritabanı boyutu, disk kullanımı, etkin eklentiler, DNS kayıtları, SSL durumu, zamanlanmış görevler, e-posta bağımlılıkları ve ödeme ağ geçitleri veya form araçları gibi harici hizmetler dahildi. Bu göz alıcı bir iş değildi, ancak DNS değiştikten sonra eski ama gerekli bir yapılandırmanın fark edilmesi gibi klasik sorunu önledi.
Ayrıca başarı kriterleri de belirlediler. Bir taşıma ancak ana sayfa, temel açılış sayfaları, iletişim formları, wp-admin erişimi, medya kütüphanesi, zamanlanmış görevler, HTTPS yönlendirmeleri ve hata günlükleri kontrol edildiğinde tamamlanmış sayılacaktı. E-ticaret siteleri için kontrol listesine test siparişleri, işlemsel e-postalar, hesap girişi ve stok güncellemeleri de dahildi.
Hedef kurulumun seçilmesi
Yeni sunucu, her siteyi tek bir paylaşımlı sistem kullanıcısı altında toplamak yerine her müşteri için ayrı hesaplar kullanıyordu. Bu, yalıtımı iyileştirdi ve diğer müşteri ortamlarını açığa çıkarmadan erişim devretmeyi kolaylaştırdı.
Ajans bir kontrol paneli seçti çünkü günlük operasyonların hem geliştiriciler hem de hesap yöneticileri için pratik kalması gerekiyordu. FASTPANEL ile web siteleri oluşturabiliyor, veritabanlarını ve SSL sertifikalarını yönetebiliyor, ayrı hesapları düzenleyebiliyor ve sunucu kaynak kullanımını tek bir yerden izleyebiliyorlardı. Bu, teknik muhakeme ihtiyacını ortadan kaldırmadı, ancak bağlantısız araçlar arasında gereksiz yere arama yapmanın büyük kısmını ortadan kaldırdı.
İlk etapta PHP sürümünü her mevcut siteyle uyumlu tuttular. Taşıma sırasında PHP'yi yükseltmek mantıklı olabilir, ancak iki büyük değişikliği birleştirmek sorun gidermeyi zorlaştırır. Ekip önce taşımaya, sonra stabilizasyon sağlamaya ve eklenti uyumluluğunu doğruladıktan sonra yükseltmeleri planlamaya karar verdi.
Eski sorunları kopyalamadan dosyaları ve veritabanlarını kopyalamak
Ekip her site için hedef web sitesini ve veritabanını oluşturdu, ardından WordPress dosyalarını aktardı ve bir veritabanı dışa aktarımını içe aktardı. Yapılandırma dosyasındaki veritabanı kimlik bilgilerini güncellediler ve ortama özgü değerleri dikkatle değiştirdiler.
Başlıca teknik risk dosya aktarımı değildi. URL işleme kısmıydı. Geçici bir hedef adresten taşınan bir site, arama ve değiştirme işlemi dikkatsizce yapılırsa yanlış bağlantılar, yönlendirmeler veya serileştirilmiş veriler geliştirebilir. Ekip, WordPress veri yapılarına saygı gösteren bir taşıma yöntemi kulland ı; ardından yeni ana sayfanın her şeyin çalıştığının kanıtı olduğunu varsaymak yerine sayfa kaynağını, iç bağlantıları, görselleri ve eklenti ayarlarını kontrol etti.
Ayrıca taşınmaması gerekenleri de gözden geçirdiler. Eski önbellek klasörleri, kullanılmayan yedek arşivleri, geliştirme günlükleri ve terk edilmiş eklentiler, yeni ortama fayda sağlamadan depolama kullanımını artırıyordu. Bunların kaldırılması karmaşayı azalttı, ancak ancak ayrı bir yedeğin doğrulanmasından sonra. Temizlik yapmak faydalıdır. Bir geri yükleme noktanız olmadan önce temizlik yapmak, alet çantası kuşanmış iyimserliktir.
Asıl işi DNS yapmadan önce test etmek
Taşınan her site, herkese açık DNS kayıtları değişmeden önce hedef sunucuda test edildi. Ajans, ziyaretçiler eski ana bilgisayarı kullanmaya devam ederken iç test kullanıcıları için sitenin yeni ortama çözümlendiğini doğrulamak amacıyla geçici bir erişim yöntemi kullandı.
Bu aşama, yayına alındıktan sonra fark edilmesi tatsız olacak dört sorunu ortaya çıkardı. Bir sitede sayfa oluşturucu ayarında sabit kodlanmış bir URL vardı. Bir diğeri eski ana bilgisayara bağlı bir posta yapılandırmasına dayanıyordu. Bir üyelik eklentisinin arka plan görev zamanlamasının geri yüklenmesi gerekiyordu. Bir e-ticaret sitesinde yalnızca eski sunucu adresini tanıyan bir ödeme ağ geçidi geri çağırım ayarı vardı.
Bu sorunların hiçbiri felaket niteliğinde değildi. Yayın öncesi testin amacı da budur. İyi bir taşıma süreci, sürprizleri müşteriler görmeden önce ele alınabilecek destek kayıtlarına dönüştürür.
Ajans formları yalnızca web sitesindeki yeşil bir başarı mesajıyla değil, gerçek alıcı gelen kutularını kullanarak test etti. SSL sertifikalarını ve zorunlu HTTPS yönlendirmelerini kontrol etti. Ön yüzde görünmeyen uyarılar için sunucu ve uygulama günlüklerini inceledi. Ekip, en büyük siteler için eksik aktarımları yakalamak amacıyla veritabanı tablo boyutlarının ve uploads dizinlerinin bir örneğini kaynak sunucuyla karşılaştırdı.
DNS geçişi ve kısa bakım penceresi
Düşük trafikli siteler için ajans, test onayından sonra normal çalışma saatlerinde DNS'i değiştirdi. E-ticaret siteleri için daha düşük trafikli bir akşam penceresi seçti ve son bir veritabanı dışa aktarımını alırken bakım modunu kısa süreliğine etkinleştirdi.
Bu son veritabanı adımı, dinamik web siteleri için önemlidir. Dosyalar daha seyrek değişir, ancak siparişler, form girdileri, kullanıcı kayıtları ve yorumlar veritabanına her an yazılabilir. İlk kopyalama birkaç saat önce tamamlandıysa son bir veritabanı eşitlemesi, bu yeni kayıtların geride kalmasını önler.
Ekip, mümkün olan yerlerde geçişten önce DNS time-to-live değerlerini düşürdü. Buna rağmen, DNS yayılımı her yerde aynı anda devreye giren bir anahtar olmadığından bazı ziyaretçilerin kısa süreliğine eski sunucuya ulaşmasını bekledi. Eski barındırma hesabı, güvenlik ağı olarak birkaç gün daha etkin kaldı, ancak çakışan değişiklikler oluşmaması için kontrollü bir duruma alındı.
Hiçbir sitede uzun süreli kesinti yaşanmadı. Yayına alındıktan sonra iki web sitesinde küçük önbellekleme sorunları görüldü ve bir iletişim formunda SMTP ayarı gerekti. Ajans, işin DNS değiştiğinde bittiğini varsaymak yerine izleme sorumluluklarını atadığı için bunların hepsi ilk saat içinde giderildi.
Taşınmadan sonra ne değişti
Anında görülen iyileşme görünürlüktü. Ajans, müşterilerin bir sitenin yavaş hissettirdiğini bildirmesini beklemek yerine kaynak etkinliğini görebiliyor ve örüntüleri inceleyebiliyordu. Ayrı hesaplar ayrıca hangi sitenin kaynak tükettiğini belirlemeyi ve daha az geçici çözümle müşteri erişimini yönetmeyi kolaylaştırdı.
Taşıma, operasyonel bir gerçeği ortaya çıkardı: performans iyileştirmeleri yalnızca yeni sunucudan gelmiyordu. Bunlar, güncelliğini yitirmiş PHP ayarlarının düzeltilmesinden, terk edilmiş eklentilerin kaldırılmasından, önbellek davranışının gözden geçirilmesinden ve yüksek talepli sitelere diğer tüm projelerle rekabet etmeden çalışabilecekleri alan sağlanmasından kaynaklandı.
Ajans destek rutinini de değiştirdi. Artık her yeni müşteri web sitesi, ilk günden itibaren belgelenmiş bir hesap, yedekleme politikası, güncelleme süreci ve taşıma kontrol listesi alıyor. Bu tutarlılık, herhangi bir tek komut veya eklentiden daha fazla zaman kazandırır.
Kendi taşınmanıza taşımanız gereken dersler
İlk olarak, tüm WordPress sitelerini aynı şekilde ele almayın. Beş sayfalık yerel bir işletme sitesi ile sipariş işleyen bir mağaza farklı geçiş planlarına ihtiyaç duyar. Site ne kadar dinamikse son veritabanı değişikliklerini ve testi o kadar dikkatli yönetmeniz gerekir.
İkinci olarak, bir yedek yalnızca geri yüklenebildiğinde faydalıdır. Taşıma gününden önce yedekleri doğrulayın, bir geri dönüş seçeneğini hazır bulundurun ve bir şeyler ters giderse geri alma kararını kimin verebileceğini önceden belirleyin. Net bir geri alma kararı, gece yarısında doğaçlanan bir karardan daha sakindir.
Üçüncü olarak, açık bir neden olmadıkça ilgisiz yükseltmeleri taşımanın içine yığmaktan kaçının. Yeni sunucu, yeni PHP sürümü, yeni tema ve yeni önbellekleme katmanı birlikte çalışabilir, ancak aynı zamanda bir sorunun olası nedenlerini de çoğaltır. Önce taşıyın. Yeni ortam kararlı hale geldikten sonra bilinçli şekilde iyileştirin.
Son olarak, geçişten sonraki işler için plan yapın. Kaynakları izleyin, günlükleri inceleyin, iş açısından kritik eylemleri test edin ve trafik ile verilerin doğru davrandığından emin olana kadar eski ortamı erişilebilir tutun. Başarılı bir taşıma, bir alan adının yeni bir IP adresini göstermeye başladığı an değildir. Ekibinizin siteyi öncekinden daha fazla güvenle yönetebildiği andır.
En iyi sonraki adım basittir: taşıma tarihini seçmeden önce envanteri oluşturun. Her sitenin neye bağlı olduğunu öğrendiğinizde taşınma, geç saatlerde oynanan bir tahmin oyunu yerine yönetilebilir bir projeye dönüşür.