Site Taşırken Kesinti Olur mu? Kesintisiz Taşıma Nasıl Yapılır

Hosting değiştirmeye karar verdiniz ama aklınızda tek bir soru dönüyor: site taşırken kesinti olur mu? Özellikle satış yapan bir siteniz varsa, "birkaç saat kapalı kalır" cümlesi doğrudan ciroya dokunduğu için taşımayı aylarca erteleyenler görüyorum. İyi haber şu: doğru sırayla yapılan bir taşımada ziyaretçi tarafında sıfır kesinti mümkündür. Kötü haber ise, internetteki "yedek al, yükle, DNS'i değiştir" üçlemesiyle yapılan taşımalarda kesintinin neredeyse garanti olması.

Bu yazıda taşımanın nerede kırıldığını ve nasıl kırılmadan yapılacağını anlatıyorum: TTL'i geçişten 24-48 saat önce düşürmenin neden pazarlık konusu olmadığı, yeni sunucuyu DNS'e hiç dokunmadan gerçek alan adıyla test etme yöntemi, geçiş anındaki doğru sıralama, propagasyon boyunca iki sunucuya birden düşen sipariş ve form kayıtlarının ne olacağı ve asıl kesinti riskinin aslında web değil e-posta tarafında olduğu. Sonunda taşıma sonrası ilk 72 saat için somut bir kontrol listesi var.

Kısa Cevap: Kesinti Zorunlu Değil, Ama Varsayılan Sonuç Kesintidir#

Site taşırken kesinti olması teknik bir zorunluluk değildir; planlama eksikliğinin sonucudur. Ziyaretçi açısından kesinti, "alan adının işaret ettiği sunucuda site yok" anına denir. Bu anı ortadan kaldırmanın yolu basittir: DNS değişmeden önce siteyi yeni sunucuda tam çalışır hâle getirmek. Böylece DNS değiştiğinde ziyaretçi eski sunucudan yeni sunucuya geçerken arada boşluk kalmaz; her iki sunucu da aynı siteyi servis ediyor olur.

Kesintinin ortaya çıktığı klasik senaryo şudur: dosyalar yeni sunucuya yüklenir, DNS hemen değiştirilir, sonra "veritabanını da aktaralım" denir. DNS bazı kullanıcılar için 5 dakikada güncellendiği için, o kullanıcılar veritabanı henüz aktarılmamış bir siteye düşer ve veritabanı bağlantı hatası görür. Yani kesintiyi yaratan şey taşımanın kendisi değil, adımların sırasıdır.

Kesinti Nereden Gelir: Taşımanın Üç Riskli Anı#

Yıllardır gördüğüm taşıma sorunlarının neredeyse tamamı şu üç andan birinde çıkıyor.

1. Geçiş anı (DNS değişimi). DNS değiştiğinde dünyadaki tüm çözümleyiciler aynı anda yeni adresi öğrenmez. Eski kaydın TTL süresi dolana kadar eski adresi vermeye devam ederler. Bu ara döneme propagasyon denir ve süresi tamamen eski TTL değerine bağlıdır. TTL'i düşürmeden yaptığınız bir geçişte kullanıcıların bir kısmı 24 saat, bazı ağlarda 48 saat boyunca eski sunucuyu görmeye devam eder.

2. İçerik uyumsuzluğu. Yeni sunucuda PHP sürümü farklıdır, bir eklenti çalışmaz, dosya izinleri yanlıştır, .htaccess taşınmamıştır. Site açılır ama bozuk açılır — bu da ziyaretçi için kesintiden farksızdır. Taşınması kolayca unutulan parçalar genelde şunlardır: gizli dosyalar (.htaccess, .env), cron görevleri, e-posta hesapları, SSL sertifikaları ve veritabanı kullanıcı yetkileri.

3. Çift yazma (split-brain). Propagasyon süresince bazı ziyaretçiler eski, bazıları yeni sunucuya düşer. İki sunucu da yazma alıyorsa (sipariş, üyelik, yorum, form) veriniz iki ayrı veritabanına bölünür. Bu, taşımanın en sinsi hatasıdır; genelde taşımadan bir hafta sonra "bir siparişim kayıp" şikâyetiyle fark edilir.

Adım 1: Taşımadan 24-48 Saat Önce TTL'i Düşürün#

TTL (Time To Live), bir DNS kaydının ara çözümleyicilerde ne kadar süre önbellekte tutulacağını söyler. Varsayılan değerler genelde 3600 (1 saat) ile 86400 (24 saat) arasındadır. TTL 86400 ise, kaydı değiştirdiğiniz anda dünyadaki bazı çözümleyiciler eski değeri 24 saat daha dağıtmaya devam eder.

Bu yüzden taşımanın ilk adımı dosya kopyalamak değil, TTL düşürmektir. Mevcut TTL'i görmek için:

dig alanadiniz.com A +noall +answer

Örnek çıktı:

alanadiniz.com.   86400   IN   A   198.51.100.10

Ortadaki 86400 TTL'dir; yani 24 saat. Şimdi DNS panelinizden (alan adı sağlayıcısı ya da Cloudflare gibi bir DNS servisi) taşınacak tüm kayıtların TTL'ini 300 saniyeye (5 dakika) çekin:

Kritik nokta: TTL düşürme işleminin kendisi de eski TTL kadar sürer. TTL 86400 iken TTL'i 300'e indirdiğinizde, bu yeni değerin her yere ulaşması yine 24 saat alır. Bu yüzden TTL düşürmeyi geçişten en az 24, güvenli olmak için 48 saat önce yapmanız gerekir. TTL'in nasıl çalıştığını ve hangi değerin ne anlama geldiğini TTL nedir yazısında ayrıntılı anlattık.

Geçiş tamamlanıp her şey oturduktan sonra TTL'i eski değerine geri çıkarın; 300 saniyelik TTL kalıcı olarak kalırsa çözümleyiciler sürekli sorgu yapar ve alan adı sağlayıcınızın DNS'i gereksiz yük alır.

Adım 2: Yeni Sunucuda Siteyi hosts Dosyasıyla Test Edin#

Taşımanın en değerli adımı budur ve Türkçe rehberlerde neredeyse hiç geçmez: DNS'e hiç dokunmadan, kendi bilgisayarınızda alan adını yeni sunucuya yönlendirip siteyi gerçek adresiyle test edebilirsiniz.

Bunu bilgisayarınızın hosts dosyası sağlar. Dosya yolu:

• Windows: C:\Windows\System32\drivers\etc\hosts (Not Defteri'ni yönetici olarak açın)
• macOS / Linux: /etc/hosts

Dosyanın sonuna yeni sunucunun IP'sini ekleyin:

203.0.113.25   alanadiniz.com
203.0.113.25   www.alanadiniz.com

Kaydettikten sonra DNS önbelleğini temizleyin:

ipconfig /flushdns

Artık sizin bilgisayarınız alanadiniz.com adresini yeni sunucuya çözer, dünyanın geri kalanı hâlâ eski sunucuyu görür. Böylece siteyi geçici bir test adresiyle değil, gerçek alan adıyla test edersiniz. Bu fark önemlidir: geçici adreslerde WordPress yönlendirmeleri, mutlak URL'ler, SSL ve çerezler farklı davranır, dolayısıyla geçici adreste sorunsuz görünen site gerçek alan adında bozuk çıkabilir. Yöntemin ayrıntıları ve sık yapılan hatalar için hosts dosyası ile site test etme yazısına bakın.

Bu aşamada test etmeniz gereken maddeler:

1. Ana sayfa, kategori, ürün/yazı detay sayfaları açılıyor mu.
2. Yönetim paneline giriş yapılabiliyor mu.
3. İletişim formu ve sipariş akışı hata veriyor mu.
4. Görseller, CSS ve JS dosyaları yükleniyor mu (tarayıcı konsolunda 404 var mı).
5. .htaccess yönlendirmeleri ve kalıcı bağlantılar çalışıyor mu.
6. PHP sürümü uyumlu mu, hata günlüğünde uyarı var mı.
7. Yeni sunucuda SSL sertifikası kurulu mu.

SSL'i geçişten önce kurun. Yeni sunucuda sertifika yoksa, DNS geçtiği anda ziyaretçiler "bağlantınız gizli değil" uyarısı görür ki bu ziyaretçi gözünde tam bir kesintidir. Alan adı henüz eski sunucuyu gösterirken HTTP-01 doğrulaması yapılamayabilir; bu durumda DNS-01 doğrulamasıyla sertifika alabilir ya da DNS geçişinden hemen sonra otomatik sertifika mekanizmasını tetikleyebilirsiniz.

Adım 3: Geçiş Anı — Doğru Sıralama ve Yazma Kilidi#

Testler temizse geçişe hazırsınız. Sıralama şu ve bu sıra pazarlığa açık değil:

1. Trafiğin en düşük olduğu saati seçin. Analitikten gerçek veriye bakın; çoğu Türkiye sitesinde bu aralık gece 02:00-05:00'tir.
2. Siteyi eski sunucuda yazmaya kapatın. E-ticaret ya da üyelik sitesiyseniz bakım moduna alın veya sipariş almayı geçici olarak durdurun. Sadece okuma yapan tanıtım sitelerinde bu adım gereksizdir.
3. Son senkronizasyonu yapın. Dosyalarda ve veritabanında geçen sürede biriken değişiklikleri aktarın:

# Dosyalar: sadece değişenleri gönderir
rsync -avz --delete /home/kullanici/public_html/ \
  [email protected]:/home/kullanici/public_html/

# Veritabanı: son bir kez tam yedek
mysqldump -u db_kullanici -p --single-transaction --quick veritabani > son.sql

4. Yeni sunucuda son kontrolü hosts üzerinden tekrar yapın. Son senkronizasyondan sonra bir şeyin bozulmadığından emin olun.
5. DNS kayıtlarını değiştirin. A kaydını (ve gerekiyorsa www, mail, MX kayıtlarını) yeni IP'ye çevirin. TTL'i 300'e indirdiyseniz beş dakika içinde büyük çoğunluk geçer.
6. Eski sunucuyu KAPATMAYIN. En az 7-14 gün ayakta tutun; geç kalmış çözümleyiciler bir süre daha oraya gider.
7. Yazma kilidini kaldırın. DNS'in oturduğunu doğruladıktan sonra bakım modunu kapatın.

Nameserver'ı değiştirerek geçiş yapıyorsanız süreç biraz farklı işler; nameserver değişikliğinin neden A kaydı değişikliğinden daha yavaş ve daha riskli olduğunu nameserver değişince site kapanır mı yazısında anlattık. Kısaca: mümkünse taşıma sırasında nameserver'a dokunmayın, sadece A kaydını değiştirin; nameserver taşımasını her şey oturduktan sonra ayrı bir işlem olarak yapın.

Propagasyon Sırasında Ne Olur: İki Sunucuya Birden Düşen Siparişler#

Bu, mevcut Türkçe içeriğin tamamen atladığı ve gerçek hayatta en pahalıya patlayan konu.

DNS değiştikten sonra, TTL süresince bazı ziyaretçiler hâlâ eski sunucuya gider. Eğer siteniz veri yazıyorsa — sipariş, üyelik kaydı, yorum, iletişim formu, bülten aboneliği — eski sunucuya düşen ziyaretçilerin yazdığı veriler eski veritabanına yazılır ve yeni sunucuya asla gelmez. Site açık görünür, hiçbir hata mesajı çıkmaz, ama veri sessizce ikiye bölünür.

Bunu önlemenin üç yolu var, riskinize göre seçin:

Yol 1 — Eski sunucuyu okunur hâle getirin (en güvenlisi). Geçiş anında eski sunucuda siteyi bakım moduna alın ya da ödeme/kayıt akışını kapatın. TTL 300 ise bu pencere yalnızca birkaç dakikadır ve gerçek anlamda "kesinti" sayılmaz; kullanıcı sadece bakım sayfası görür.

Yol 2 — Eski sunucudan yeniye yönlendirin. Eski sunucunun .htaccess dosyasına, gelen tüm trafiği yeni sunucunun IP'sine ya da geçici bir alt alan adına gönderen bir kural koyabilirsiniz:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?alanadiniz\.com$ [NC]
RewriteRule ^(.*)$ https://yeni.alanadiniz.com/$1 [R=302,L]

Bu yöntem statik siteler için pratiktir; ancak e-ticarette ödeme akışını bozabileceği için dikkatli test edin.

Yol 3 — Geçiş sonrası fark aktarımı. Eski sunucuda propagasyon boyunca biriken kayıtları (yeni siparişler, yeni üyeler, yeni formlar) sonradan yeni veritabanına aktarın. Bunun için geçiş anını not edin ve o zaman damgasından sonraki kayıtları çekin:

SELECT * FROM wp_posts
WHERE post_date > '2026-08-11 03:00:00'
ORDER BY post_date;

Bu yöntem işe yarar ama elle iştir ve otomatik artan kimlik (auto increment) çakışmalarına dikkat etmek gerekir. Mümkünse Yol 1'i tercih edin.

E-posta Tarafı: Asıl Kesinti Riski Burada#

Web sitesinin kesintisiz taşınması nispeten kolay; e-posta taşımasında kesinti riski çok daha yüksektir çünkü burada kaybolan şey bir sayfa görüntülemesi değil, gelen bir müşteri mesajıdır.

Riskler şunlar:

• MX kaydı değiştiğinde gönderen sunucular bir süre eski sunucuya teslim etmeye devam eder. O mesajlar eski sunucunun posta kutusuna düşer ve yeni sunucuda görünmez.
• Yeni sunucuda posta hesapları açılmadan MX değiştirilirse, gelen mesajlar "böyle bir kullanıcı yok" hatasıyla geri döner. Bu, geri döndürülemez bir kayıptır.
• Eski posta kutularındaki mevcut mesajlar otomatik taşınmaz. IMAP üzerinden ayrıca aktarılmaları gerekir.

Doğru sıralama:

1. Yeni sunucuda tüm posta hesaplarını, aynı adreslerle ve aynı kotalarla açın.
2. Mevcut mesajları IMAP senkronizasyonuyla yeni sunucuya aktarın. Süreci e-postaları yeni sunucuya taşıma yazısında anlattık.
3. MX kaydının TTL'ini de 300'e indirin (web kayıtlarıyla birlikte, 48 saat önce).
4. MX'i değiştirin.
5. Eski posta sunucusunu en az 14 gün açık bırakın ve son gelen mesajları da yeni sunucuya aktarın.
6. SPF ve DKIM kayıtlarını yeni sunucuya göre güncelleyin; unutulursa giden mailler spam klasörüne düşmeye başlar.

Taşıma Sonrası İlk 72 Saat Kontrol Listesi#

Taşıma bittikten sonra "site açılıyor" demek yeterli değil. Şu kontrolleri sırayla yapın:

İlk saat:

# Alan adı yeni IP'yi mi gösteriyor
dig +short alanadiniz.com A
dig +short www.alanadiniz.com A
dig +short alanadiniz.com MX

# HTTP durum kodu ve yönlendirme zinciri
curl -I -L https://alanadiniz.com

# SSL sertifikası doğru mu ve hangi sunucudan geliyor
curl -vI https://alanadiniz.com 2>&1 | grep -Ei "subject|issuer|HTTP/"

İlk gün:

• Yönetim paneline giriş, içerik ekleme, medya yükleme testi.
• İletişim formundan gerçek bir mesaj gönderin ve ulaştığını doğrulayın.
• E-ticaret sitesiyseniz gerçek bir test siparişi geçin, ödeme sağlayıcısının geri dönüş (callback) adresine yeni sunucudan erişildiğini kontrol edin.
• Sunucudan bir e-posta gönderin ve spam klasörüne düşmediğini doğrulayın.
• Sunucu hata günlüklerine bakın; taşıma sonrası eksik dosya ve izin hataları burada görünür.

İlk 72 saat:

• Arama konsolunda tarama hatalarını izleyin.
• Eski sunucunun erişim günlüğüne bakın: hâlâ trafik alıyorsa propagasyon bitmemiştir, sunucuyu kapatmayın.
• Yeni sunucunun kaynak kullanımına bakın. Paylaşımlı bir pakete taşındıysanız, panelin kaynak kullanımı ekranından CPU, bellek ve eşzamanlı süreç limitlerine ne kadar yaklaştığınızı kontrol edin; limitin sürekli dolması 508 hatalarına yol açar.
• TTL değerlerini eski, normal seviyelerine geri çıkarın.

Sıkça Sorulan Sorular#

Site taşırken gerçekten hiç kesinti olmadan taşınabilir mi#

Evet, doğru sırayla yapıldığında ziyaretçi tarafında hiç kesinti olmaz. Bunun tek şartı, DNS kayıtları değiştirilmeden önce sitenin yeni sunucuda tam çalışır durumda olmasıdır. Böylece geçiş anında hem eski hem yeni sunucu aynı siteyi servis eder ve ziyaretçi hangisine düşerse düşsün çalışan bir sayfa görür. Kesinti, ancak DNS önce değiştirilip taşıma sonradan yapıldığında ortaya çıkar.

DNS propagasyonu ne kadar sürer#

Propagasyon süresini belirleyen tek şey, değişiklikten önceki TTL değeridir. TTL 86400 ise bazı çözümleyiciler 24 saate kadar eski adresi vermeye devam eder; TTL 300'e indirilmişse geçişin büyük kısmı beş dakika içinde tamamlanır. Bu yüzden TTL'in geçişten en az 24-48 saat önce düşürülmesi gerekir, çünkü TTL değişikliğinin kendisi de eski TTL kadar sürede yayılır. "Propagasyon 48 saat sürer" ifadesi bir doğa kanunu değil, yüksek TTL bırakmanın sonucudur.

Taşıma sırasında gelen siparişler kaybolur mu#

Kaybolabilir, ve bu taşımanın en sık gözden kaçan riskidir. Propagasyon süresince bazı ziyaretçiler eski sunucuya düşer ve orada verdikleri siparişler eski veritabanına yazılır; yeni sunucuya kendiliğinden aktarılmaz. Bunu önlemenin en güvenli yolu, geçiş anında eski sunucuda sipariş alımını kısa süreliğine kapatmaktır. TTL 300 saniyeye indirilmişse bu pencere yalnızca birkaç dakika sürer ve pratikte kayıp riski ortadan kalkar.

Eski hosting hesabını ne zaman kapatmalıyım#

Eski hesabı taşımadan sonra en az 7-14 gün açık tutun, e-posta da taşıdıysanız 14 günden erken kapatmayın. Bu sürede geç güncellenen çözümleyiciler hâlâ eski sunucuya trafik gönderiyor olabilir ve eski sunucu kapalıysa o ziyaretçiler hata sayfası görür. Eski sunucunun erişim günlüğünü kontrol edip trafiğin sıfıra düştüğünü gördüğünüzde kapatmak en doğru zamanlamadır. Kapatmadan önce mutlaka son bir tam yedek alın ve bu yedeği kendi bilgisayarınızda ya da ayrı bir depolamada saklayın.

Nameserver mı değiştirmeliyim yoksa A kaydı mı#

Kesintisiz taşıma hedefliyorsanız yalnızca A kaydını değiştirmek daha güvenlidir. A kaydı değişikliği tek bir kaydı etkiler ve TTL'i siz kontrol edersiniz; nameserver değişikliği ise tüm DNS bölgesini bir sağlayıcıdan diğerine devreder ve üst seviye alan adı sunucularındaki TTL'i siz belirleyemezsiniz. Ayrıca nameserver değiştirdiğinizde yeni sağlayıcıda tüm kayıtları (MX, TXT, SPF, alt alan adları) eksiksiz yeniden oluşturmanız gerekir; bir kaydı unutmak e-postanın tamamen kesilmesine yol açabilir. Nameserver taşımasını, site taşıması oturduktan sonra ayrı bir iş olarak yapın.

Cloudflare kullanıyorsam taşıma daha mı kolay olur#

Evet, belirgin biçimde kolaylaşır. Trafik Cloudflare üzerinden aktığı için ziyaretçilerin çözdüğü IP değişmez; siz yalnızca Cloudflare panelindeki A kaydını yeni sunucunun IP'sine çevirirsiniz ve bu değişiklik neredeyse anında etkili olur. Yani klasik anlamda bir propagasyon beklemezsiniz. Buna karşılık MX kayıtları Cloudflare üzerinden geçmediği için e-posta tarafındaki TTL ve sıralama kuralları aynen geçerlidir. Geçişten sonra Cloudflare önbelleğini temizlemeyi de unutmayın.

Taşımadan sonra sitede eski içerik görünüyorsa ne yapmalıyım#

Önce bunun gerçekten eski sunucudan mı geldiğini doğrulayın: dig +short alanadiniz.com A komutuyla alan adının hangi IP'yi gösterdiğine bakın. IP yeniyse sorun sunucuda değil önbellektedir; tarayıcı önbelleğini, varsa CDN önbelleğini ve sitedeki önbellek eklentisinin önbelleğini temizleyin. IP hâlâ eski görünüyorsa propagasyon devam ediyor demektir ve TTL süresinin dolmasını beklemeniz gerekir. Kendi bilgisayarınızda hosts dosyasına test için satır eklediyseniz, o satırı silmeyi de unutmayın.

Kapanış#

Site taşırken kesinti olup olmayacağını belirleyen şey sunucunun kalitesi değil, adımların sırasıdır. Özetle formül şu: geçişten 24-48 saat önce tüm ilgili kayıtların TTL'ini 300'e indirin, siteyi yeni sunucuya taşıyıp SSL dahil her şeyi hazırlayın, hosts dosyasıyla gerçek alan adı üzerinden test edin, düşük trafikli bir saatte eski sunucuda yazmayı kısa süreliğine durdurup son senkronizasyonu yapın, ardından DNS'i çevirin ve eski sunucuyu en az bir-iki hafta açık bırakın. E-posta tarafında ise hesapları önce açmak, mesajları IMAP ile aktarmak ve MX'i en son değiştirmek zorunludur.

Bu adımları kendiniz yürütmek istemiyorsanız taşımayı planlamadan son kontrol listesine kadar üstlenen site taşıma hizmetine bakabilirsiniz. Taşıyacağınız hedefi henüz seçmediyseniz, sitenizin trafiğine ve kaynak ihtiyacına göre hosting paketleri ya da kendi yapılandırmanızı kurmak isterseniz VDS paketleri arasından seçim yapabilir; taşıma öncesinde ve sonrasında elinizde her zaman geri dönebileceğiniz bir kopya bulunması için de yedekleme çözümünü devreye almayı ihmal etmeyin.