Web Siteleri Güvenli Şekilde Nasıl Taşınır
21 Haziran 2026'da yayımlandı
Güvenli bir web sitesi geçişi, herhangi bir dosya taşınmadan önce başlar. Web sitelerini güvenli şekilde nasıl taşıyacağınızı bilmek istiyorsanız, ilk iş verileri kopyalamak değil, bilinmeyenleri azaltmaktır. Mevcut stack'i kontrol eder, gereksiz değişiklikleri dondurur, yedeklerin gerçekten geri yüklenebildiğini doğrular ve DNS'e dokunmadan önce bir geri alma yolu oluştururuz. Birçok ekibin atladığı kısım budur ve sonrasında günlükler aynı hikâyeyi anlatır.
Geçişler sıkıcı nedenlerle başarısız olur. Unutulmuş bir cron job eski veritabanına yazmaya devam eder. SSL hazır olmadan DNS yeni yere alınır. Yönlendirme kuralları yarım yamalak kopyalanır. Önbellek, yeni sitenin bir kişiye sorunsuz, herkese bozuk görünmesine neden olur. Bunların hiçbiri dramatik değildir, ama pahalıdır. Güvenli bir geçiş çoğunlukla disiplinli sıralamadan ibarettir.
Kesinti sürprizleri olmadan web siteleri güvenli şekilde nasıl taşınır
En temiz geçişler bir envanterle başlar. Tam olarak neyin taşındığını, taşıma sırasında neyin değişebileceğini ve sunucu dışında hangi bağımlılıkların bulunduğunu bilmeniz gerekir. Bu; web sitesi dosyaları, veritabanları, medya depolama, SSL sertifikaları, DNS zonları, zamanlanmış görevler, e-posta yönlendirme, API entegrasyonları, ödeme callback'leri ve güvenlik duvarı kuralları anlamına gelir. Site bir CDN, harici görsel depolama, object cache veya üçüncü taraf arama kullanıyorsa bunları da dahil edin.
Ekiplerin küçük tuzakları bulduğu yer burasıdır. Bir WooCommerce mağazası, eski IP'ye işaret eden bir ödeme webhook'una bağlı olabilir. Bir SaaS uygulamasının ikinci bir makinede arka plan worker'ları olabilir. Bir pazarlama sitesi basit olabilir, ancak iletişim formu sunucu hostname'iyle kısıtlanmış bir SMTP servisi üzerinden gönderim yapıyor olabilir. Güvenli geçişler nadiren ana sayfayla ilgilidir. Asıl mesele uç noktalardır.
Herhangi bir şey taşımadan önce, ne tür bir geçiş yaptığınıza karar verin. Bir VPS'den diğerine bire bir geçiş, bir risk seviyesidir. Paylaşımlı hosting'den yönetilen VPS'e geçmek, kontrol panellerini değiştirmek, PHP'yi yükseltmek ve web sunucusunu aynı anda Apache'den Nginx'e taşımak bambaşka bir durumdur. Birden fazla değişikliği aynı anda yapabilirsiniz, ancak her ek değişken sorun gidermeyi yavaşlatır. Mümkünse altyapı değişikliklerini uygulama değişikliklerinden ayırın.
Önceden test ettiğiniz yedeklerle başlayın
Her sağlayıcı yedeklerin mevcut olduğunu söyler. Bu güzel, ancak bir yedek yalnızca temiz şekilde ve kurtarma hedefiniz için yeterince hızlı geri yüklenebiliyorsa işe yarar. Geçişten hemen önce dosyaların ve veritabanlarının yeni bir yedeğini oluşturun. Kaynak ortamın dışında da bir kopya saklayın; böylece tek bir platformun o gün sorunsuz çalışmasına bel bağlamazsınız.
Site gelir açısından önemliyse, staging ortamında bir test geri yüklemesi gerçekleştirin. Geri yüklenen siteyi açın, veritabanı bağlantısını doğrulayın, dosya izinlerini kontrol edin ve medyanın yüklendiğinden emin olun. Tüm uygulamayı test edemiyorsanız, en azından yedek arşivinin eksiksiz olduğunu ve veritabanı dökümünün okunabildiğini doğrulayın. Bu gösterişli bir iş değildir, ancak muhasebeye dün geceki siparişlerin neden ormanda kaybolduğunu açıklamak da değildir.
Geçiş penceresi sırasında değişiklikleri dondurun
Geçiş sırasında içerik düzenlemeleri, eklenti kurulumları ve kod dağıtımları split-brain sorunları oluşturur. Bir sistem güncellenir, diğeri güncellenmez ve artık kimse hangi sürümün gerçek olduğundan emin değildir. Kısa bir değişiklik dondurma süresi belirleyin. İçeriği yoğun veya işlem odaklı sitelerde, son senkronizasyon sırasında bakım modunu kullanın ya da kritik bölümleri salt okunur duruma alın.
E-ticaret, rezervasyonlar veya kullanıcı tarafından oluşturulan içerik için delta sync planlayın. Dosyaların ve verilerin büyük bölümünü önceden kopyalayın, ardından son dakika değişikliklerini yakalamak için cutover penceresinde son bir senkronizasyon yapın. Bu, veri sapması riskine girmeden kesinti süresini düşük tutar.
Cutover'dan önce hedef ortamı oluşturun
Yaygın bir hata, hedef sunucuyu daha sonra yapılandırılabilecek boş bir kutu gibi görmektir. Güvenli geçiş bunun tersine işler. Geçişten önce hedef ortam hazır olmalıdır: işletim sistemi yamalanmış, web stack kurulmuş, PHP sürümü doğrulanmış, veritabanı ayarlanmış, SSL hazırlanmış, yedekler zamanlanmış ve izleme etkinleştirilmiş olmalıdır.
Önce uygulama gereksinimlerini eşleştirin, ardından dikkatli şekilde iyileştirin. Eski site PHP 7.4 üzerinde çalışıyorsa ve uygulama PHP 8.2 için sertifikalı değilse, geçiş günü cesaret gösterme anı değildir. Kararlılık doğrulandıktan sonra modernize edebilirsiniz. Önce sakinlik, sonra optimizasyon.
İzinler ve sahiplik ekstra dikkat gerektirir. “Site taşındı ama yüklemeler başarısız oluyor” türü birçok olay, yalnızca yanlış kullanıcı/grup sahipliği veya eksik yazılabilir yollar nedeniyle yaşanır. Ayrıca cron job'ları, queue worker'ları ve zamanlanmış görevleri gözden geçirin. Önemli arka plan işlemleri bir saat önce sessizce durmuşken site sorunsuz yükleniyor olabilir.
Bir hosts dosyası veya geçici URL kullanarak test edin
Site yeni sunucuda kontrol edilmeden canlı DNS'i yönlendirmeyin. Uygulamayı özel olarak test etmek için bir hosts dosyası override'ı veya geçici bir önizleme domain'i kullanın. Önemli sayfalarda gezinin, formları gönderin, admin olarak oturum açın, uygunsa test siparişi verin ve e-posta gönderimini doğrulayın. Görselleri, aramayı, API'leri, admin işlemlerini ve oturumlar ya da önbellekleme ile bağlantılı her şeyi kontrol edin.
Görsel kontrollerin ötesine bakın. Hata günlüklerini, web sunucusu günlüklerini, PHP-FPM durumunu, veritabanı yavaş sorgularını ve disk kullanımını inceleyin. Yönlendirmelerin beklendiği gibi çalıştığını doğrulayın. Canonical URL'lerin, robots kurallarının ve ortam değişkenlerinin doğru olduğundan emin olun. Bir production sitesini, üzerinde hâlâ staging noindex header'ı varken taşımak şaşırtıcı derecede kolaydır. Arama motorları, olabilecek en kötü anlarda itaatkârdır.
DNS, TTL ve cutover planlaması
Web sitelerini güvenli şekilde nasıl taşıyacağınızı öğreniyorsanız, hazırlığın karşılığını verdiği yer DNS'tir. İlgili DNS kayıtlarında TTL değerini geçiş penceresinden epey önce, ideal olarak 24 ila 48 saat öncesinden düşürün. Bu, siteyi yeni sunucuya geçirdiğinizde resolver'ların daha hızlı yenilenmesine yardımcı olur. Anında küresel yayılımı garanti etmez, ancak kullanıcıların eski konuma erişebileceği süreyi azaltır.
Cutover sırasında yalnızca gerekli olanı güncelleyin. Genellikle bu A kaydı, belki AAAA ve e-posta da taşınıyorsa bazen e-posta ile ilgili kayıtlar anlamına gelir. Açık bir neden olmadıkça web sitesi geçişini e-posta geçişiyle karıştırmamaya dikkat edin. Bunları birleştirmek etki alanını büyütür. En güzel geçiş çoğu zaman daha az şeyi değiştiren geçiştir.
Güvenli bir örtüşme süresi boyunca eski sunucuyu açık tutun. DNS değişikliğinden sonra bile bazı kullanıcılar ve botlar bir süre eski host'a ulaşmaya devam eder. Bu süre boyunca her iki sistemdeki erişim günlüklerini izleyin. Eski sunucu hâlâ anlamlı trafik alıyorsa, onu erişilebilir tutun ve mümkünse veri kaybetmemek için yazma etkinliğini dikkatli şekilde yönlendirin.
Önbellekleme ve SSL sorunlarına dikkat edin
CDN önbellekleri, uygulama önbellekleri ve yerel tarayıcı önbelleği geçişten sonra sorunları gizleyebilir. Gereken yerlerde temizleyin. Tam sayfa önbelleği kullanılıyorsa, son senkronizasyondan ve DNS cutover'ından sonra temizleyin. Varsa CDN origin'in güncellendiğini doğrulayın.
SSL geçişten önce hazır olmalıdır, sonra değil. Sertifikaları yeni ortama kurun, tam zinciri doğrulayın ve HTTP'den HTTPS'e davranışı test edin. Sabit kodlanmış asset URL'leri hâlâ eski domain'e veya protokole işaret ediyorsa mixed-content uyarıları görünebilir. Bunlar küçük ayrıntılardır, ancak kullanıcılar kilit simgesini sizin dikkatli planlamanızdan daha hızlı fark eder.
Yönlendirmeler, SEO ve uygulama bütünlüğü
Domain aynı kalıyorsa SEO riski daha düşüktür, ancak teknik kontroller yine de önemlidir. HTTP'den HTTPS'e, www'den non-www'ye veya tersine yönlendirmelerin ve eski yol eşlemelerinin tam olarak beklendiği gibi davrandığından emin olun. Domain değişiyorsa 301 yönlendirmelerini kapsamlı şekilde kullanın ve canonical tag'leri, site haritalarını ve dahili referansları güncelleyin.
Mümkünse redirect chain'lerle yayına çıkmayın. Bunlar işleri yavaşlatır ve indeksleme karmaşası yaratır. Site bunlara dayanıyorsa özel hata sayfalarını, robots.txt'yi, XML sitemap üretimini ve structured data'yı da kontrol edin. Geçiş yalnızca “site yükleniyor” demek değildir. “Site normal ve uç koşullar altında doğru davranıyor” demektir.
Dinamik uygulamalarda, kimlik doğrulamayı, oturumları ve izinleri gerçek kullanıcı rolleriyle test edin. Cookie scope, oturum depolama veya proxy header'ları nedeniyle müşteri girişi başarısız olurken admin çalışabilir. Bu, özellikle load balancer'ların veya reverse proxy'lerin arkasında yaygındır.
Geri alma planı geçişin bir parçasıdır
Bir geçiş ancak geri döndürme mümkünse güvenlidir. Geri alma koşullarını önceden tanımlayın. Örneğin: sürekli 5xx hataları, ödeme tamamlama hatası, bozuk giriş, ciddi performans gerilemesi veya veri uyumsuzluğu. Ayrıca geri alma kararını kimin vereceğini ve cutover sonrasında gözlem penceresinin ne kadar süreceğini tanımlayın.
Geri alma, stres altında yürütülebilecek kadar basit olmalıdır. Bu genellikle eski ortamı bozmadan tutmak, mümkünse eski veritabanı durumunu korumak ve DNS'i veya trafik yönlendirmesini hızlıca geri almak anlamına gelir. Yeni ortamda yazma işlemleri gerçekleştiyse, veri uzlaştırması için bir politikaya ihtiyacınız vardır. Bu nedenle işlem odaklı web siteleri son geçiş sırasında ekstra özen gerektirir.
İlk 24 saat boyunca sıkı izleyin
Cutover sonrasında çalışma süresini, yanıt süresini, CPU'yu, belleği, disk I/O'yu, veritabanı yükünü, SSL geçerliliğini, kuyruk derinliğini ve yedekleme işlerini izleyin. Kullanıcıya görünen sinyalleri de izleyin: sipariş akışı, iletişim formları, giriş başarısı ve hata raporları. Bir geçiş onuncu dakikada iyi görünebilir ve üçüncü saatte zamanlanmış işler devreye girdiğinde veya önbellek süresi dolduğunda başarısız olabilir.
Yönetilen desteğin değerini gösterdiği yer burasıdır. İyi izleme, müşteriler alarm sisteminiz hâline gelmeden önce kaynak sıçramalarını, başarısız servisleri ve sertifika sorunlarını yakalar. Şirket içinde operasyon derinliği olmayan ekipler için bu sakin operasyon katmanı, bir hosting planındaki başka bir onay kutusundan daha önemlidir.
Daha güvenli geçişler için pratik bir kural
Sonunda fırsat buldunuz diye her şeyi değiştirmeyin. Önce taşıyın, sonra kararlı hâle getirin, üçüncü olarak iyileştirin. Kâğıt üzerinde daha yavaş gibi hissettirse bile bu sıra zaman kazandırır. Web sitelerini güvenli şekilde nasıl taşıyacağınız konusunda yardıma ihtiyacınız varsa, doğru hosting ortağı yalnızca sunucunun kendisiyle değil; yedekler, izleme, geri alma planlaması ve ancak gece yarısından sonra ortaya çıkan tuhaf küçük uç durumlarla da yardımcı olabilmelidir.
İyi bir geçiş neredeyse olaysız hissettirir. Hedef budur. Sessiz günlükler, kararlı trafik, çalışan formlar, gizemli cron felaketlerinin olmaması ve DNS geçişinden sonra uyuyabilen bir ekip. kodu.cloud'da genellikle hedeflediğimiz standart budur - gösterişli değil, sadece kontrol altında.
Andres Saar Müşteri Destek Mühendisi