Web sitesi taşırken veri kaybı ve kesinti riski nasıl azaltılır?

Web sitesi taşırken asıl risk, kopyalama sırasında gelen sipariş ve mesajların eski sunucuda kalmasıdır. Alan adı yeni sunucuya yönlendirildikten sonra da bazı ziyaretçiler bir süre eski siteye ulaşabilir. İki yerde biriken veriyi sonradan birleştirmek, bir yedeği geri yüklemekten çok daha zordur.

Riski küçültmek için yedeği geri yüklemeyi önceden deneyin ve yeni sunucuyu kimse görmeden test edin. Son gelen sipariş ve mesajları kısa bir duraklama sırasında aktarın. Alan adını yeni sunucuya yönlendiren DNS ayarını en son değiştirin. Bu yazıda web sitesi taşıma adımlarını WordPress üzerinden anlatıyorum, mantık başka sistemlerde de aynı.

Bu yöntemde site kısa bir süre sipariş ve form almaz, bazı ziyaretçiler de siteye ulaşamayabilir. Bu yüzden size “sıfır kesinti” sözü vermiyorum. Canlı satışınız ya da yoğun form trafiğiniz varsa geçişin sorumlusunu, yeni kayıtların gideceği sunucuyu ve geri dönüş planını baştan yazın.

Web sitesi taşıma üç ayrı iş olabilir

“Siteyi taşıyoruz” cümlesi üç farklı işi anlatabilir. Farkı görmek için iki terimi bilmeniz yeter. DNS, alan adınızı yazan ziyaretçiyi doğru sunucuya götüren bir adres defteri gibidir. Nameserver ise bu defterin hangi şirkette tutulduğunu gösterir.

Defterdeki bir satırı (DNS kaydını) değiştirmek, defteri başka şirkete taşımaktan ayrı bir iştir. Hangi işi yaptığınızı baştan netleştirin:

• Hosting değişimi: Dosyalar ve veritabanı başka sunucuya gider, alan adı aynı kalır.
• Alan adı ya da adres değişimi: Ziyaretçinin gördüğü alan adı ya da sayfa adresleri değişir, SEO geçişi de gerekir.
• Kayıt kuruluşu transferi: Alan adını yönettiğiniz şirket değişir. Transfer sırasında alan adının kalan süresini, yönetim yetkilerini ve nameserver ayarlarını koruyun. Hosting değiştirirken bu transfer gerekmez.

Yalnız hosting değişiyorsa site adresine dokunmayın. WordPress’in taşıma belgesi de bu iki durumu ayırır. Adres aynıysa dosyalar ve veritabanı taşınır. Adres değişiyorsa eski adresin geçtiği yerler ayrıca düzeltilir.

İkisini birden yapacaksanız önce siteyi yeni sunucuda aynı adresle doğrulayın. Adres değişikliğini mümkünse başka bir güne bırakın. İkisi aynı gün yapılırsa, sorun çıktığında taşımadan mı adres değişikliğinden mi geldiğini ayırmak zorlaşır.

Taşımadan önce neyin nerede olduğunu listeleyin

Geliştiricinize ya da hosting firmanıza önce şunları sorun. Terimleri bilmeniz gerekmez, soruları olduğu gibi iletebilirsiniz:

• Yeni sunucu sitenizin teknik ihtiyaçlarını karşılıyor mu (PHP ve veritabanı sürümü, disk alanı, PHP uzantıları, zamanlanmış görevler)? Trafiğinizi kaldırır mı?
• Hosting paneli, dosya aktarımı, veritabanı, DNS ve sertifika erişimleri kimde? Alan adı ile hosting ayrı şirketlerdeyse hangi panelde kim değişiklik yapacak?

WordPress’te tema, eklenti ve görseller dosyalarda durur. Yazılar, kullanıcılar, ayarlar, form kayıtları ve siparişler ise veritabanındadır. Bazı form eklentileri mesajı yalnız e-postayla gönderir, bazıları veritabanına da kaydeder. Yönetim panelinde gelen form mesajlarını listeleyen bir bölüm varsa sizinki kaydediyor demektir.

Siteye bağlı dış hizmetleri de listeleyin:

• Ödeme sistemi
• CRM (müşteri takip programı)
• SMTP (sitenin e-postalarını gönderen servis)
• CDN (sitenizi ziyaretçiye yakın sunuculardan hızlı sunan hizmet)
• Webhook’lar ve otomatik görevler

Webhook, bir sistemin diğerine otomatik haber göndermesidir. Örneğin ödeme sağlayıcısı sitenize “ödeme alındı” bilgisini böyle iletir. Ana sayfa açılsa bile bu hizmetleri taşımadan sonra tek tek deneyin.

Tema yenileme, eklenti güncellemesi ya da adres yapısı değişikliğini mümkünse geçişten sonraya bırakın. Geçişten önce şunları not edin, taşımadan sonra bu listeyle karşılaştıracaksınız:

• Önemli sayfaların adresleri
• Örnek bir formun nereye ulaştığı
• Son siparişlerin numarası ve durumu, son form kaydının numarası
• Şu an bozuk olan bağlantılar

E-posta ayrı bir plan ister

Taşıma sırasında e-postanız kesilmesin diye önce DNS panelindeki bütün kayıtların bir kopyasını alın. Sonra info@ gibi adreslerinizin eski hostingde mi, ayrı bir sağlayıcıda mı olduğunu öğrenin. Şu üç şey birbirinden ayrıdır:

• DNS’teki e-posta kayıtları. MX kaydı postanın nereye gideceğini söyler. SPF, DKIM ve DMARC ise e-postanın gerçekten sizden geldiğini doğrulamaya yarar.
• Posta kutularındaki eski mesajlar.
• Sitenin form e-postalarını gönderen SMTP ayarı.

E-posta aynı sağlayıcıda kalıyorsa MX kaydına ve SPF, DKIM, DMARC kayıtlarına dokunmayın. Bunlar DNS’te genellikle TXT kaydı olarak durur. Nameserver da değişiyorsa bu kayıtları geçişten önce yeni DNS paneline ekleyin.

Sağlayıcı da değişiyorsa posta kutularını ayrıca taşıyın, çünkü DNS kaydı eski mesajları taşımaz. Taşıdıktan sonra eski ve yeni kutudaki mesaj sayısını karşılaştırın. Gelen ve giden postayı, sitenin SMTP ayarını da deneyin.

Taşımadan sonra formu kendiniz doldurup deneyin. Ekranda “mesajınız gönderildi” yazsa bile mesaj kimseye ulaşmamış olabilir.

Yedeği alın ve geri yüklemeyi deneyin

Yedeğe ancak geri yüklemeyi denedikten sonra güvenin. Dosyaları ve veritabanını aynı anda yedekleyin, geri yüklerken ikisine birden ihtiyacınız olur. Yedeğin yanına tarihini, hangi sunucudan alındığını, veritabanının adını ve neleri içerdiğini yazın. Bir kopyasını canlı sunucunun dışında, erişimi sınırlı bir yerde tutun.

Yedeği herkese kapalı bir test ortamına (staging) kurun. Yönetim girişini, içerikleri ve görselleri, sayfa adreslerini, kullanıcı yetkilerini ve formlar gibi temel işlevleri deneyin. Geliştiricinizden bu kopyada e-posta gönderimini ve ödemeyi kapatmasını, kopyayı arama motorlarından gizlemesini isteyin.

Kişisel veri içeren yedeği herkese açık bir klasörde bırakmayın. Gerekirse test kopyasındaki kişisel verileri gizleyin (maskeleme).

Bu deneme iki soruyu cevaplar: Geri dönebilir miyiz, dönersek ne kadar eski veriye döneriz? Dün geceki yedek bugünkü siparişleri içermez. Sitenize her gün sipariş ya da randevu geliyorsa son kopyayı geçişe olabildiğince yakın almanız gerekir. Seyrek güncellenen bir sitede bu kadar acele gerekmez.

Taşımadan sonra da düzenli yedek ve izleme isterseniz WordPress bakım hizmeti sayfasına bakabilirsiniz.

Yeni sunucuyu DNS’i değiştirmeden test edin

Kopya yeni sunucuya kurulunca geliştiriciniz veritabanı bağlantısını (wp-config.php), dosya izinlerini, görsel yollarını, sunucu kurallarını ve kalıcı bağlantıları (sayfa adresi ayarlarını) kontrol eder.

Alan adı aynı kalacaksa geliştiriciniz sizin bilgisayarınızdaki hosts dosyasına küçük bir satır ekler. Böylece siteyi gerçek adresiyle yeni sunucuda yalnız siz görürsünüz. Test bitince geliştiricinizden bu satırı kaldırmasını isteyin.

Test ayrı bir alt alan adındaysa (deneme.siteniz.com gibi) adresler ona göre değişir ve canlıya geçerken yeniden düzeltilir. Bu kopyayı şifreyle koruyun, çünkü arama motorlarına yol gösteren robots.txt dosyası özel sayfaları gizlemez.

Gerekirse arama motorlarına “bu sayfayı listene ekleme” diyen noindex etiketini de ekleyin. Canlıya geçince şifreyi ve noindex’i kaldırın.

Sitenin https ile güvenli açılmasını SSL sertifikası sağlar. Sertifikayı gerçek alan adıyla, yeni sunucuda deneyin. Siteyi alan adı yerine sunucunun numarasıyla (IP adresi) açarak yapılan test yanıltıcı olabilir.

İç sayfaları, görselleri, PDF’leri, aramayı, mobil görünümü ve formun nereye ulaştığını da deneyin. Canlı bir ödeme ya da form testi yaparsanız o işlemi not edin ki gerçek siparişlerle karışmasın. Test sırasında yeni sunucunun gerçek müşterilere e-posta ya da bildirim göndermediğinden emin olun.

Asıl risk, iki sitenin aynı anda kayıt alması

Diyelim ki bir diş kliniğinin sitesinde randevu formu var. Pazartesi yedek alındı, çarşamba yeni sunucu hazır. Pazartesi yedeğiyle yeni siteyi açarsanız aradaki randevular eski sunucuda kalır.

DNS geçerken iki site de randevu alıyorsa yeni randevular iki ayrı veritabanına düşer. Birini ötekinin üzerine yüklerseniz bir kısmı silinir.

Küçük ve orta ölçekli bir sitede izlenecek yol şu:

1. İlk kopyayı yeni sunucuya kurup test edin. Eski site bu sırada çalışmaya devam etsin.
2. Ziyaretçinin az olduğu bir saat seçin, müşterilerinize ve çalışanlarınıza önceden haber verin. Siteye veri bırakan her şeyi listeleyin: yazı, yorum, form, sipariş, ödeme bildirimi, otomatik işler. Bakım ekranı yalnız ziyaretçinin gördüğü sayfayı gizler, arka plandaki webhook’lar gelmeye devam edebilir.
3. Eski sitede yeni kayıt alınmasını kısa süre durdurun. Buna yazma dondurma (freeze) denir. Bunun için örneğin formu, sepeti ve üye kaydını geçici olarak kapatabilirsiniz. Durduramıyorsanız bütün kayıtları tek bir sunucuya yönlendirin.
4. Arka planda sırada bekleyen işler (ödeme onayı, e-posta gönderimi gibi) bitince son kopyayı alın. Son sipariş numarasını, güncelleme saatini ve kayıt sayılarını not edin.
5. İlk kopyadan sonra değişen dosya ve veriyi, yani son farkı yeni sunucuya aktarın. Geliştiriciniz ya her şeyi baştan yükler ya da yalnız değişen kısmı aktarıp kontrol eder. Testte oluşan deneme kayıtları gerçek veriye karışmasın.
6. Yeni sunucudaki son kayıtları ve ödeme sağlayıcısındaki işlemleri eski siteyle karşılaştırın. Her şey tutuyorsa yeni siteyi kayıt almaya açın.
7. Alan adının DNS ayarını yeni sunucuya çevirin, nasıl yapılacağını aşağıda anlatıyorum. Eski site bu sırada da kayıt almasın. Oraya düşen ziyaretçi “bakımdayız, birazdan tekrar deneyin” mesajı ya da planlı bir yönlendirme görsün.

Hiç kesinti istemiyorsanız bunu DNS ayarlarıyla sağlayamazsınız. Bütün kayıtları tek bir veritabanına gönderen, ayrıca tasarlanmış bir altyapı gerekir. Bunu geliştiricinizle ayrı bir iş olarak planlayın. E-ticaret siteniz varsa geç gelen ödeme bildirimlerini, tamamlanmamış ödemeleri ve aynı siparişin iki kez işlenme ihtimalini de geliştiricinizle ayrıca konuşun.

DNS’i en son ve kontrollü değiştirin

Yeni sunucu hazır olmadan DNS’e dokunmayın. Şu anki A, AAAA ve CNAME kayıtlarını (sitenin hangi sunucuda açılacağını söyleyen kayıtlar) ve gerekiyorsa nameserver bilgisini not edin.

TTL, DNS kaydınızın ara sunucularda (örneğin internet sağlayıcınızın DNS sunucusunda) ne kadar süre hatırlanacağını belirler. Düşük TTL, yeni adresin daha çabuk yayılmasını sağlar. Kayıt tipiniz izin veriyorsa TTL’yi geçişten önce, en az şu anki TTL süresi kadar erken düşürün. Son dakika düşürürseniz ara sunucular eski süre dolana kadar eski kaydı kullanır.

Cloudflare’in TTL açıklamasına göre, trafiği Cloudflare üzerinden geçen (proxy’li) kayıtlarda TTL “Auto” kalır ve değiştirilemez. Yalnız DNS olarak çalışan (DNS-only) kayıtlarda TTL ayarlanabilir.

Trafiğiniz böyle bir CDN proxy’si üzerinden geçiyorsa ziyaretçinin gördüğü IP adresi bu hizmete aittir. Asıl sunucunuzun (origin) adresi arkada kalır. Sunucu değiştirirken yeni adresi bu hizmetin panelinde güncellemeniz gerekir.

Değişiklikten sonra siteyi hem ofis internetinden hem telefonunuzun mobil verisinden açın. Sertifika uyarısı çıkıp çıkmadığına bakın. Geliştiricinizden iki sunucunun loglarını (erişim ve hata günlükleri) izlemesini isteyin.

DNS değişikliğinin herkese ulaşması için kesin bir süre söylenemez. Bu yüzden eski hostingi takvime bakıp kapatmayın. Önce kalan trafiği, geciken işleri, form ve ödeme bildirimlerini kontrol edin.

Adres değişiyorsa SEO geçişini de yapın

Yalnız hosting değiştiyse ve adresler aynı kaldıysa sayfaları yönlendirmeniz gerekmez. Google’ın hosting değişikliği sayfası bu durumda yeni altyapıyı önce test etmeyi ve iki sunucunun trafiğini izlemeyi önerir. Sayfa ayrıca, Google’ın siteyi taramasını (sayfaları okumasını) geçici olarak engellediyseniz bu engeli kaldırmanızı söyler.

Adres değişiyorsa her önemli eski sayfayı en yakın yeni karşılığıyla eşleştirin. Bunun için eski ve yeni adresleri yan yana yazdığınız bir liste hazırlayın. Geliştiriciniz bu listeye göre sunucuda 301 ya da 308 kalıcı yönlendirmesi kurar. Böylece eski adres doğrudan kendi yeni sayfasına gider.

Örneğin bir muhasebe bürosunun eski “şirket kuruluşu” sayfası, ana sayfaya değil yeni sitedeki aynı sayfaya gitmeli.

Yeni sayfanın canonical etiketi (asıl adresi arama motorlarına söyleyen etiket) kendi adresini göstermeli. İç bağlantılar, görsel ve dosya yolları, varsa dil sürümleri ve site haritası (sayfalarınızın arama motorları için hazırlanmış listesi) da yeni adreslere uymalı.

Veritabanındaki eski adreslerin nasıl değiştirileceğini geliştiricinize sorun. Düz SQL REPLACE komutuyla körlemesine yapılan toplu değişiklik, WordPress’in özel biçimde saklanan (serileştirilmiş) ayarlarını bozabilir. Geliştiriciniz bu işi önce yedek üzerinde, bu veriyi koruyan bir araçla yapmalı.

Search Console, Google’ın site sahiplerine sunduğu paneldir. Google’ın adres değişikliği sayfası uygun durumlarda buradaki adres değişikliği aracını önerir. Bu araç alan adı ya da alt alan adı değişikliği içindir, hosting değişikliğinde kullanılmaz.

Adres değiştikten sonra sıralama ve tarama bir süre dalgalanabilir. Sıralamanın aynen korunacağını kimse garanti edemez. Google’ın aynı sayfası yeni site haritası göndermeyi ve yönlendirmeleri test etmeyi de önerir. Yönlendirmeleri uzun süre yerinde tutun.

Canlıya aldıktan sonra kontrol edilecekler

Geçişi bitti saymadan önce gerçek alan adında şunlara bakın:

• Sayfalar ve görseller açılıyor mu, yönetim paneline girebiliyor musunuz? 404 (sayfa bulunamadı), 500 (sunucu hatası), karışık içerik (güvenli sayfada güvensiz bağlantıyla yüklenen görsel ya da dosya) ya da sertifika uyarısı var mı?
• Form kaydı hem veritabanında hem posta kutusunda görünüyor mu? Sipariş, ödeme bildirimi ve müşteri e-postası baştan sona çalışıyor mu?
• Son siparişin ve son form kaydının numarası eski siteyle tutuyor mu? Görsel sayısı aynı mı?
• CDN ve önbellek yeni sunucuyu gösteriyor mu?
• Eski sunucunun loglarında hâlâ form ya da sipariş denemesi görünüyor mu?
• Test için eklenen şifre ve noindex kaldırıldı mı, robots.txt siteyi engelliyor mu? Canonical etiketleri ve site haritası doğru adresleri gösteriyor mu?

Geri dönüş planını geçişten önce yazın

Geçişten önce şu soruların cevabını yazın:

• Hangi sorun çıkarsa geri döneriz (örneğin ödeme bildirimleri siteye ulaşmıyorsa)?
• Kararı kim verir?
• Son sağlam yedek nerede?
• Geri dönüşü kim yapar?

DNS’i eski sunucuya çevirmek tek başına geri dönüş değildir. Yeni siteye sipariş ya da form geldiyse eski veritabanını olduğu gibi açmak bunları kaybettirebilir.

Önce yeni sitede kayıt alınmasını durdurun. İki sunucuya gelen sipariş ve mesajların listesini çıkarın, ödeme sağlayıcısındaki işlemlerle karşılaştırın. Sonra eski sunucuya kontrollü biçimde mi döneceğinize, yoksa yeni sitedeki sorunu mu düzelteceğinize karar verin. Yeni sitenin sorunsuz çalıştığından emin olana kadar eski sunucuyu ve yedekleri silmeyin.

Sık sorulan sorular

Taşıma sırasında siteyi kapatmak şart mı?

Hayır, her site için şart değil. Form ya da sipariş almayan, yalnız bilgi veren bir sitede siteyi kapatmak genellikle gerekmez. Sipariş ve form alan sitede ise bütün kayıtlar tek bir sunucuya gitmeli. Bunu sağlayamıyorsanız kısa, planlı bir duraklama belirsiz veri kaybından daha güvenlidir.

Taşıma ne kadar sürer?

Sitenize göre değişir, tek bir süre söylemek doğru olmaz. Dosya ve veritabanının boyutu, taşıma sırasında gelen yeni veri, DNS değişikliğinin yayılması, testlerin kapsamı ve bağlı dış hizmetler (ödeme, e-posta gibi) süreyi etkiler. Yalnız kopyalama süresine bakmayın. Test ve gözlem için, gerekirse geri dönüş için de zaman ayırın.

Taşımayı birlikte planlamak isterseniz WordPress site taşıma hizmeti sayfasından sitenizi anlatabilirsiniz.