Web Sitesi Taşıma Kontrol Listesi: Hosting Değiştirirken Kesintiyi Azaltma

Son Güncelleme: Eylül 2026

Web sitesi taşıma, dosyaları yeni bir sunucuya kopyalamaktan ibaret değildir. Veritabanı tutarlılığı, e-posta hesapları, alan adı kayıtları ve SSL yapılandırması birlikte ele alınmadığında kısa bir hosting değişikliği bile veri kaybına veya erişim sorunlarına dönüşebilir. Bu rehber, hosting taşıma kontrol listesi oluşturarak geçişi planlamak, yeni ortamı yayına almadan sınamak ve gerektiğinde eski ortama dönebilmek isteyen site sahipleri içindir.

İçindekiler

• Taşımanın Kapsamını Belirleyin
• Envanter ve Yedek Hazırlayın
• Yeni Hosting Ortamını Hazırlayın
• Dosyaları ve Veritabanını Taşıyın
• E-posta Sürekliliğini Planlayın
• DNS Geçişini Yönetin
• SSL ve Güvenlik Kontrollerini Yapın
• Yayın Öncesi Testleri Tamamlayın
• Yayına Alma ve Geri Dönüş Planı
• Özet Kontrol Listesi
• Sıkça Sorulan Sorular
• Sonuç

Taşımanın Kapsamını Belirleyin

İlk karar, yalnızca web sitesinin mi yoksa alan adı, DNS yönetimi ve e-postanın da mı taşınacağıdır. Bunlar birbirine bağlı görünse de farklı hizmetler olabilir. Örneğin web sitesi yeni bir hosting hesabına taşınırken alan adı aynı kayıt kuruluşunda, e-posta ise mevcut sağlayıcıda kalabilir. Bu senaryoda yalnızca web trafiğine ilişkin kayıtların değiştirilmesi gerekir; tüm DNS bölgesini yeniden oluşturmak gereksiz risk doğurabilir.

Taşıma kapsamı için bir sorumlu ve bakım penceresi belirleyin. İçerik editörleri, mağaza yöneticileri ve geliştiriciler geçiş zamanını bilmeli; değişikliklerin hangi anda durdurulacağı önceden kararlaştırılmalıdır. Özellikle sipariş alan bir sitede son dakikaya kadar işlem kabul edip saatler önce alınmış veritabanı yedeğini yüklemek, aradaki siparişleri kaybettirebilir.

• Basit tanıtım sitesi: Dosyalar ve birkaç form kontrolü çoğu zaman geçişin merkezindedir.
• İçerik sitesi: Yazılar, medya dosyaları, kullanıcı hesapları ve zamanlanmış yayınlar birlikte değerlendirilir.
• E-ticaret sitesi: Siparişler, stok değişimleri, ödeme bildirimleri ve işlem kayıtları için ayrı bir eşitleme planı gerekir.

Envanter ve Yedek Hazırlayın

Taşıma öncesinde mevcut ortamın envanterini çıkarın. Alan adlarını, alt alan adlarını, kullanılan uygulamaları, veritabanlarını, çalışma zamanı sürümlerini, zamanlanmış görevleri, yönlendirmeleri, sertifikaları ve e-posta hesaplarını kaydedin. Uygulamanın yüklenen dosyaları hangi dizinde tuttuğunu ve yapılandırma değerlerini nereden okuduğunu da not edin. Bir WordPress kurulumu için veritabanı ve medya klasörü birlikte taşınmalıdır; yalnızca uygulama dosyalarının kopyalanması yeterli değildir.

Ardından tam yedek alın: site dosyaları, veritabanı, gerekiyorsa e-posta verileri ve kritik yapılandırmalar ayrı ayrı korunmalıdır. Yedeği yalnızca taşınacak eski sunucuda bırakmayın. Bağımsız bir konumda saklamak, eski hesabın erişilemez hâle gelmesi durumunda kurtarma şansını artırır. Yedek arşivinin oluştuğunu görmekle yetinmeyin; içeriğini açabildiğinizi ve veritabanı dışa aktarımının okunabildiğini kontrol edin.

Kurtarma noktası, geri döndüğünüzde kabul edebileceğiniz veri kaybının sınırıdır. Değişmeyen bir kurumsal sitede önceki gecenin yedeği yeterli olabilir; sürekli sipariş alan bir mağazada ise geçişten hemen önce yeni bir veritabanı kopyası veya son değişiklikleri eşitleme yöntemi gerekir. Bu karar teknik ekip kadar iş süreçlerinin sorumlularını da ilgilendirir.

Yeni Hosting Ortamını Hazırlayın

Yeni ortamı alan adı yönlendirmesinden önce kurun. Uygulamanın ihtiyaç duyduğu çalışma zamanı, veritabanı, disk alanı ve erişim izinleri mevcut olmalıdır. Paylaşımlı hostingten sanal sunucuya geçiliyorsa web sunucusu ve işletim sistemi bakımının kimde olduğu da netleştirilmelidir. Daha fazla kaynak sunan bir paket, uygulama uyumsuzluklarını tek başına çözmez.

Mevcut ortamla yeni ortamı şu başlıklarda karşılaştırın:

Yeni altyapıyı seçerken yalnızca başlangıç kapasitesine bakmayın. Dosya sayısı, veritabanı büyümesi, beklenen eşzamanlı ziyaretçi ve yönetim sorumluluğu da önemlidir. Küçük bir site için Linux Hosting uygun olabilir; özel yapılandırma isteyen uygulamalarda Sanal Sunucu seçenekleri ayrıca değerlendirilebilir.

Dosyaları ve Veritabanını Taşıyın

Dosyaları aktarırken gizli yapılandırmaları, kullanıcı yüklemelerini ve uygulamanın yazdığı dizinleri atlamayın. Dosya sahipliği ile izinler yeni ortamda farklı olabilir; bu nedenle kopyalama tamamlandıktan sonra uygulamanın hem okuma hem de gerekli alanlara yazma işlemlerini deneyin. Yapılandırma dosyalarındaki eski veritabanı adresi veya kullanıcı bilgileri de güncellenmelidir.

Veritabanı geçişinde dışa aktarma ile içe aktarma işlemlerini tek bir süreç olarak düşünün. Tabloların oluşması, verilerin eksiksiz taşındığını kanıtlamaz. Kayıt sayılarını karşılaştırın; Türkçe karakterler, tarih alanları ve büyük metinler içeren örnek kayıtları açın. Uygulamanın önbelleği eski bağlantı bilgilerini tutuyorsa uygun yöntemle temizleyin. Canlı sistemde yazma işlemleri sürerken alınan kopyanın hangi ana ait olduğunu mutlaka kaydedin.

Örneğin günde birkaç kez güncellenen bir blogda ilk dosya ve veritabanı kopyası geçişten önce hazırlanabilir. Yayına alma anında yeni yazılar durdurulur, son değişiklikler yeniden aktarılır ve ardından yeni ortam etkinleştirilir. Sipariş alan bir mağazada ise bakım modu (geçici işlem durdurma), son veritabanı eşitlemesi ve ödeme akışının sınanması daha dikkatli koordine edilmelidir.

E-posta Sürekliliğini Planlayın

Web sitesi taşınırken e-posta hizmetinin nerede çalıştığını doğrulayın. E-posta eski sağlayıcıda kalacaksa web sitesiyle ilgili adres kayıtlarını değiştirirken posta yönlendirme kayıtlarına dokunmamak gerekebilir. E-posta da taşınacaksa hesaplar, posta kutuları, yönlendirmeler ve uygulamaların kullandığı gönderim bilgileri yeni tarafta önceden hazırlanmalıdır.

DNS kayıtlarını değiştirmeden önce mevcut MX, SPF, DKIM ve DMARC yapılandırmasını envantere ekleyin. Bu kayıtların işlevleri farklıdır: MX gelen postanın nereye ulaşacağını belirler; diğerleri gönderici doğrulaması ve alan adı politikasında rol oynar. Kayıtları düşünmeden silmek, web sitesi açılıyor olsa bile e-posta teslimatını etkileyebilir.

Taşıma sonrasında hem dışarıdan gelen hem de dışarıya giden örnek mesajları sınayın. İletişim formu, parola sıfırlama ve sipariş bildirimi gibi otomatik iletileri ayrıca kontrol edin. Eski posta hizmetini hemen kapatmamak, geçiş sırasında eski hedefe ulaşabilecek mesajları incelemek için zaman sağlar. Posta kutusu içerikleri de taşınıyorsa taşıma sonrasında klasörleri ve yakın tarihli iletileri karşılaştırın.

DNS Geçişini Yönetin

DNS geçişi, ziyaretçilerin yeni sunucuya yönelmeye başladığı aşamadır. Önce mevcut kayıtların bir kopyasını alın ve gerçekten hangi kaydın değişeceğini belirleyin. Alan adının kök adresi ile www alt alan adı farklı kayıtlarla yönetiliyor olabilir. Kullanılmayan eski kaydı değiştirmek, beklenen yönlendirmeyi sağlamaz.

Planlanan geçişten önce ilgili kayıtların TTL değeri (önbellekte tutulma süresi) uygun biçimde azaltılabilir. Bu işlem, değişikliğin her kullanıcıya aynı anda ulaşacağını garanti etmez; daha önce önbelleğe alınmış yanıtlar ve farklı çözümleyiciler nedeniyle bir süre iki ortam da trafik alabilir. Bu yüzden eski sunucuyu DNS değişikliğinden hemen sonra kapatmayın. Yeni içerik üretilen uygulamalarda iki sunucuya eşzamanlı yazılmasının nasıl önleneceğini de planlayın.

Ad sunucularını tamamen değiştirmek, yalnızca web adresi kaydını güncellemekten daha kapsamlıdır. Böyle bir işlem yapılacaksa e-posta, alan adı doğrulaması ve kullanılan diğer servislerin kayıtları yeni DNS bölgesinde önceden oluşturulmalıdır. Geçiş anında hangi ekibin hangi kayıtları değiştireceğini yazılı hâle getirmek, aceleyle yapılan eksik düzenlemeleri azaltır.

SSL ve Güvenlik Kontrollerini Yapın

Yeni sunucuda SSL sertifikası çalışır durumda olmadan ziyaretçileri yönlendirmeyin. Alan adı ve kullanılan alt alan adlarının sertifika kapsamına girdiğini, sertifika zincirinin doğru sunulduğunu ve HTTPS bağlantısında tarayıcı uyarısı oluşmadığını kontrol edin. Sertifika yönetimi konusunda ek hizmet gerekiyorsa Corelux SSL Sertifikası seçeneklerini inceleyebilirsiniz.

Taşınan uygulamada eski sunucuya ait gizli bilgileri olduğu gibi bırakmak yerine erişim kapsamını gözden geçirin. Veritabanı kullanıcıları, yönetici hesapları ve harici servis anahtarları gerçekten gerekli izinlerle sınırlandırılmalıdır. Yapılandırma dosyalarının ziyaretçilere açılmadığından ve yedek arşivlerinin web üzerinden erişilebilir bir konuma bırakılmadığından emin olun.

Güvenlik kontrolü yalnızca sertifikayla bitmez. Yönetim paneline giriş, dosya yükleme, yönlendirmeler ve hata sayfaları beklenen biçimde davranmalıdır. Geçiş sırasında geçici olarak açılan test erişimlerini iş bitince kaldırın. Yeni ortamın düzenli yedekleme planı varsa ilk yedeğin alındığını ve geri yükleme yönteminin bilindiğini doğrulayın.

Yayın Öncesi Testleri Tamamlayın

Yeni ortamı mümkünse genel DNS değişikliğinden önce, geçici test adresi veya yerel ad çözümlemesi üzerinden inceleyin. Test sırasında gördüğünüz sayfanın gerçekten yeni sunucudan geldiğini doğrulayın; tarayıcı önbelleği eski sayfayı gösteriyor olabilir. Sadece ana sayfanın açılması yeterli değildir: işlevsel akışlar, yazma işlemleri ve harici bağlantılar birlikte sınanmalıdır.

• Gezinme: Ana sayfa, iç sayfalar, görseller ve kalıcı bağlantıları açın.
• İşlemler: Form gönderimi, hesap girişi, dosya yükleme ve arama işlevini deneyin.
• Ticari akış: Sepet, ödeme yönlendirmesi ve bildirimleri uygun bir test senaryosuyla kontrol edin.
• Arka plan: Zamanlanmış görevlerin ve iş kuyruklarının beklenen sonucu ürettiğini inceleyin.
• Gözlem: Uygulama hata kayıtları, yanıt süreleri ve kaynak kullanımını eski ortamla karşılaştırın.

Testleri yalnızca site yöneticisi hesabıyla yapmayın. Oturumu kapalı bir ziyaretçinin gördüğü sayfalar ile yetkili kullanıcının yaptığı işlemler farklı olabilir. Örneğin katalog sayfası sorunsuz açılırken giriş sonrası profil ekranı eski bir dosya yoluna başvurabilir. Bulunan hataları önem sırasına göre ayırın; ödeme veya oturum açma gibi kritik sorunlar çözülmeden trafiği yeni ortama taşımayın.

Yayına Alma ve Geri Dönüş Planı

Geçiş günü için kısa bir yayına alma sırası yazın: içerik değişikliklerini durdurma, son yedeği alma, son verileri eşitleme, yeni ortamı doğrulama, DNS kaydını değiştirme ve temel akışları yeniden test etme. Her adımın tamamlandığını bir sorumlunun işaretlemesi, özellikle birden fazla kişinin çalıştığı taşımalarda karışıklığı azaltır.

Geri dönüş planı, yalnızca eski DNS adresini yeniden yazmaktan ibaret değildir. Yeni ortamda geçiş sonrasında sipariş veya kullanıcı kaydı oluştuysa eski ortama dönüldüğünde bu verilerin ne olacağını belirlemelisiniz. Dönüş kararını tetikleyecek koşulları önceden tanımlayın: örneğin ödeme işlemlerinin çalışmaması, yaygın oturum hatası veya giderilemeyen veritabanı tutarsızlığı. Eski ortamı erişilebilir tutmak, sorunu incelerken seçeneklerinizi korur.

Yayına aldıktan sonra tek bir kontrolle süreci kapatmayın. Farklı ağlardan erişimi, gelen e-postaları ve uygulama kayıtlarını izleyin. Geçiş tamamlandığında eski sunucunun ne zaman kapatılacağına; yedeklerin, geçici test hesaplarının ve eski erişim izinlerinin nasıl temizleneceğine karar verin. Bu son adım, gereksiz maliyet ve unutulmuş erişim noktalarını önlemek için de önemlidir.

Özet Kontrol Listesi

Aşağıdaki listeyi kendi uygulamanıza göre genişletebilirsiniz. Her madde için bir sorumlu ve doğrulama yöntemi eklemek, listeyi yalnızca hatırlatıcı olmaktan çıkarıp uygulanabilir bir geçiş planına dönüştürür.

1. Kapsam: Web, e-posta, DNS ve alan adı yönetiminin hangilerinin değişeceğini yazın.
2. Envanter: Uygulama gereksinimlerini, hesapları, görevleri ve mevcut DNS kayıtlarını kaydedin.
3. Yedek: Dosya ve veritabanı kopyalarını bağımsız bir konumda doğrulayın.
4. Kurulum: Yeni ortamın kaynaklarını, izinlerini ve bağlantılarını hazırlayın.
5. Aktarım: Dosyaları ve verileri taşıyıp önemli kayıtları karşılaştırın.
6. Test: HTTPS, sayfalar, giriş, formlar, e-posta ve kritik işlemleri deneyin.
7. Geçiş: Son değişiklikleri eşitleyip gerekli DNS kayıtlarını güncelleyin.
8. İzleme: İki ortamı geçiş süresince gözlemleyin ve geri dönüş seçeneğini koruyun.
9. Kapanış: Yeni yedekleme düzenini doğrulayıp geçici erişimleri kaldırın.

Sıkça Sorulan Sorular

Sonuç

Başarılı bir web sitesi taşıma işleminin temeli, önceden hazırlanmış envanter, doğrulanmış yedek, sınanmış yeni ortam ve açık bir geri dönüş planıdır. Dosya aktarımını, veritabanı eşitlemesini, e-posta sürekliliğini ve DNS değişikliğini ayrı görevler olarak yönetmek; kesintiyi ve veri kaybı riskini azaltmaya yardımcı olur. İhtiyacınıza uygun altyapıyı değerlendirirken Corelux Hosting, Sanal Sunucu ve Yedekleme Hizmeti seçeneklerini inceleyebilir, taşıma planınızı sitenizin iş yüküne göre şekillendirebilirsiniz.