Hosting Değiştirirken DNS ve Domain Taşıma Kontrol Listesi

Hosting değiştirirken neden detaylı bir DNS ve domain planı şart?

Hosting firmanızı değiştirmek performans, maliyet ya da destek kalitesi açısından çok doğru bir karar olabilir. Ancak DNS ve domain tarafını doğru planlamazsanız bu geçiş süreci; açılmayan siteler, çalışmayan e‑postalar ve SEO kaybıyla sonuçlanabilir. Özellikle canlı bir e‑ticaret sitesi, SaaS ürünü veya yoğun trafikli blog işletiyorsanız, birkaç dakikalık kesinti bile doğrudan gelir kaybı ve itibar zedelenmesine dönüşebilir.

Örneğin yeni sunucu hazırlanmış olsa bile DNS ve domain planı son dakikaya bırakılırsa TTL düşürme atlanabilir, MX kayıtları taşınmayabilir, SPF ve DKIM ayarları gözden kaçabilir. DNS önbellekleri nedeniyle istekler geçici olarak eski ve yeni sunucuya dağılabilir; eksik e‑posta kayıtları ise teslimat ve kimlik doğrulama sorunlarına yol açabilir.

Bu yazıda, hosting firması değiştirirken DNS ve domain taşıma sürecini adım adım planlayabileceğiniz kapsamlı bir kontrol listesi hazırladık. Amacımız; kesintiyi ve riski azaltmak, geçiş akışını önceden planlamak. Yazıyı, teknik ekibinizle beraber kullanabileceğiniz bir runbook gibi düşünebilirsiniz.

1. Adım: Mevcut durumu haritalandırın ve görünmeyen riskleri çıkarın

İyi bir taşıma planının ilk şartı, bugün neye sahip olduğunuzu tam olarak bilmektir. Gözden kaçmış tek bir DNS kaydı ya da unutulan bir alt alan adı bile kesintiye yol açabilir.

1.1. Alan adı ve DNS envanteri çıkarın

Aşağıdaki sorulara net yanıtlar veremiyorsanız önce envanteri tamamlamalısınız:

• Hangi alan adları taşımanın parçası olacak? (com, net, com.tr vb.)
• Bu domainlere bağlı hangi alt alan adları var? (www, api, panel, mail, cdn vb.)
• Mevcut DNS sağlayıcınız kim? (domain kayıt firması, önceki hosting sağlayıcı ya da ayrı bir DNS hizmeti)
• Hangi DNS kayıtları tanımlı? A, AAAA, CNAME, MX, TXT, SRV, CAA vb.
• Hangi kayıtlar kritik işlevler için kullanılıyor? (web sitesi, e‑posta, API, entegrasyonlar, üçüncü parti servisler)

DNS kayıt türleri konusunda emin değilseniz, DNS kayıtları A’dan Z’ye rehberimizi mutlaka gözden geçirmenizi öneririz. Böylece taşıma sırasında hangi kaydı neden değiştirdiğinizi çok daha bilinçli yönetebilirsiniz.

1.2. E‑posta altyapısını özellikle ayırın

Web sitesinin birkaç dakika kapanmasının tolere edilebildiği bir işletmede bile, e‑postaların kaybolması ya da saatlerce teslim edilememesi daha büyük sorun yaratabilir. Bu yüzden:

• Hangi alan adlarının MX kayıtları eski hostinge işaret ediyor, netleştirin.
• SPF, DKIM ve DMARC kayıtlarını listeleyin.
• Webmail, POP3/IMAP ve SMTP bağlantı ayarlarını not edin.

Özellikle e‑posta taşıma tarafını derinlemesine görmek isterseniz, e‑posta altyapısını taşırken kesinti yaşamamak için hazırladığımız rehbere göz atabilirsiniz.

1.3. Teknik ve iş önceliklerini belirleyin

Her proje için kritik bileşenler farklıdır. Örneğin:

• Bir içerik sitesi için SEO ve cache süreleri kritik olabilir.
• Bir e‑ticaret sitesi için sepet ve ödeme akışının kesintisizliği önceliklidir.
• Bir SaaS ürünü için API ve veritabanı bağlantı sürekliliği kritiktir.

Taşıma planını bu önceliklere göre tasarlarsanız, hangi sistem için ne kadar risk alabileceğinizi baştan netleştirmiş olursunuz.

2. Adım: Yeni hosting altyapısını paralel hazırlayın

DNS değişikliklerine dokunmadan önce, yeni hosting ortamının mümkün olduğunca hazır hale gelmesi gerekir. İster paylaşımlı hosting, ister VPS, ister dedicated ya da colocation kullanın, mantık aynıdır: Önce yeni ortamı hazırlayın, sonra trafiği taşıyın.

2.1. Yeni sunucuyu yapılandırın

• PHP sürümünü, veritabanı motorunu ve sürümünü uygulamayla uyumlu, güvenlik desteği devam eden seçeneklerden belirleyin. Eski ortam destek dışıysa aynı sürümü kopyalamak yerine uyumluluk testleriyle yükseltmeyi planlayın.
• Gerekli eklenti ve modülleri kurun (örneğin PHP eklentileri, cache modülleri, web sunucusu ayarları).
• SSL sertifikası için temel hazırlığı yapın. Let’s Encrypt ya da kurumsal SSL hangi modeli kullanacaksanız planlayın.
• Güvenlik tarafında temel sertleştirme adımlarını uygulayın (SSH ayarları, firewall, panel güvenliği). Paylaşımlı hostingte erişiminiz dışındaki sunucu ayarları için sağlayıcının sorumluluğunu netleştirin.

Paylaşımlı hostingden VPS altyapısına yükseliyorsanız, performans ve kaynak planlaması açısından paylaşımlı hostingden VPS’e sorunsuz geçiş rehberimizden de yararlanabilirsiniz.

2.2. Web dosyalarını ve veritabanlarını yeni ortama kopyalayın

Bu aşamada henüz DNS’i değiştirmeden, sitenin ilk kopyasını yeni sunucuya alırsınız. Canlı sistemde yazma işlemleri sürüyorsa bu kopya zamanla geride kalır; geçiş öncesi son dosya ve veritabanı eşitlemesini, gerekirse kısa bir yazma duraklatmasını planlayın. Yeni kopyadaki zamanlanmış görevlerin, ödeme işlemlerinin ve e‑posta gönderimlerinin üretimdeki işlemleri tekrar tetiklemesini önleyin:

• Eski hostingte tam dosya yedeği alın (public_html, uygulama dizini, yapılandırma dosyaları).
• Veritabanlarını SQL dump olarak dışa aktarın.
• Yeni sunucuda veritabanı oluşturup dump dosyalarını içe aktarın.
• Gerekliyse yapılandırma dosyalarında (örneğin WordPress wp-config.php, Laravel .env) veritabanı bağlantı ayarlarını güncelleyin.

cPanel kullanıyorsanız, cPanel’de tüm siteyi yedekleme ve geri yükleme rehberimiz bu adımları pratikleştirmenize yardımcı olur.

2.3. Panelden panele otomatik taşıma imkanı varsa kullanın

Eski ve yeni sunucuda cPanel kullanılıyor ve hedef ortamda gerekli WHM transfer araçlarına erişiminiz varsa panel üzerinden aktarımı değerlendirebilirsiniz. Aktarım kapsamını ve uyumluluğu önceden kontrol edin; eksiksiz bir kopya oluştuğunu varsaymayın. Bu durumda:

• Eski sunucunun root ya da transfer için yetkili hesabına erişim alın.
• WHM üstünden hesap transferini başlatın.
• Oluşan hesaplar üzerinde örnek site ve e‑posta kutularını test edin.

Bu senaryo için, cPanel’den cPanel’e canlı taşıma rehberimizde sıfıra yakın kesinti için TTL ve incremental rsync stratejilerini detaylı anlattık.

3. Adım: DNS stratejisi ve TTL planı olmadan hamle yapmayın

DNS tarafı, taşımanın kaderini belirleyen en kritik katmandır. Yanlış zamanda yapılan küçük bir değişiklik, saatlerce sürecek sorunlara dönüşebilir. Buradaki ana kavram, TTL değeridir.

3.1. TTL nedir ve neden düşürmelisiniz?

TTL, bir DNS kaydının önbellekte yeniden sorgulanmadan kullanılabileceği süreyi saniye cinsinden belirtir. Örneğin TTL’i 14400 olan eski bir A kaydını değişiklikten hemen önce önbelleğe alan bir çözümleyici, bu yanıtı yaklaşık 4 saat daha kullanabilir. Bu süre, değişikliğin tüm istemcilere ulaşacağı kesin bir küresel sınır değildir.

Hosting değişimi öncesinde hedefiniz şu olmalıdır:

• Kritik kayıtların TTL değerlerini geçici olarak ciddi şekilde düşürmek (örneğin 14400 yerine 300 ya da 120 saniye).
• Geçiş tamamlandıktan ve her şey stabil olduktan sonra TTL değerlerini tekrar yükseltmek.

DNS yayılımının nasıl çalıştığını ve neden farklı süreler alabildiğini anlamak için DNS yayılım süresi rehberimize bakabilirsiniz.

3.2. Kesintiyi azaltmak için örnek TTL zaman çizelgesi

Aşağıdaki akış örnek bir plandır; süreleri mevcut TTL değerlerine ve DNS sağlayıcınızın desteklediği değerlere göre uyarlayın:

• Örneğin taşıma gününden 48–72 saat önce: Değişecek A, AAAA, MX ve kritik CNAME kayıtlarının TTL değerlerini, sağlayıcınız destekliyorsa 300 veya 120 saniyeye düşürün. Düşürme, önbellekteki eski yanıtların süresini kısaltmaz; kayıtları değiştirmeden önce en az önceki TTL kadar zaman bırakın. Önceki TTL daha uzunsa hazırlığa daha erken başlayın.
• Taşıma gününe kadar: Bu kayıtları değiştirmeyin, sadece yeni sunucu hazırlığına odaklanın.
• Taşıma anında: A, AAAA ve gerekiyorsa MX kayıtlarını yeni sunucuya işaret edecek şekilde güncelleyin.
• Her şeyin stabil olduğundan emin olduktan sonra: TTL değerlerini yeniden daha yüksek bir değere alın (örneğin 3600 veya 7200).

Bu konuyu daha detaylı teknik örneklerle görmek istiyorsanız, zero‑downtime taşıma için TTL stratejileri yazımız tam olarak bu sorunu ele alıyor.

3.3. Nameserver mı değiştireceksiniz, yoksa yalnızca ilgili DNS kayıtlarını mı?

Hosting firması değiştirirken iki temel yaklaşımınız var:

1. Mevcut DNS sağlayıcısını koruyup sadece A ve ilgili kayıtları yeni IP’ye yönlendirmek.
2. Nameserver’ları yeni DNS sağlayıcısına yönlendirip tüm kayıt yönetimini oraya taşımak.

Risk açısından bakarsak, adım adım ilerlemek genellikle daha güvenlidir. Örneğin ilk adımda yalnızca web trafiği için kullanılan A ve varsa AAAA kayıtlarını yeni ortamın ilgili IP adreslerine yönlendirip, nameserver değişikliğini daha sonra ayrı bir bakıma bırakabilirsiniz. Böylece aynı gün hem hosting hem DNS sağlayıcısını değiştirmemiş olursunuz. Değiştireceğiniz adres kayıtlarının posta veya diğer hizmetler tarafından da kullanılıp kullanılmadığını kontrol edin; örneğin MX hedefi kök alan adıysa kök alanın A/AAAA değişikliği posta teslimatını da etkileyebilir. Posta kutuları yerinde kalsa bile web sitesinin gönderim kaynağı değişiyorsa SPF/DKIM yetkilendirmelerini ayrıca gözden geçirin. Mevcut DNS hizmeti eski hosting paketine bağlıysa, paketi iptal ettikten sonra da devam edip etmeyeceğini önceden doğrulayın.

Nameserver değişecekse tüm gerekli kayıtları yeni yetkili DNS sunucularında önceden hazırlayıp yanıtlarını kontrol edin. DNSSEC etkin alan adlarında üst bölgedeki DS kaydı ile yeni sağlayıcının imzalama anahtarlarının uyumunu ayrıca planlayın. Eski DS kaydı önbellekteyken uyumsuz anahtarlarla yanıt veren sunuculara geçmek, doğrulayan çözümleyicilerde SERVFAIL hatasına yol açabilir. A/AAAA TTL değerlerini düşürmek, üst bölgedeki DS ve NS/delegasyon önbellek sürelerini kısaltmaz.

DNSSEC geçiş sırasını her iki DNS sağlayıcısıyla ve kayıt kuruluşuyla netleştirin. Örneğin Cloudflare’ın geçiş rehberi, gerekli desteğin bulunduğu ortamlarda çoklu imzalayıcı (multi-signer) yolunu; bu desteğin bulunmadığı durumda ise geçici olarak DNSSEC koruması olmadan geçişi tarif eder. İkinci yolda önce kayıt kuruluşu üzerinden üst bölgedeki DS kaydı kaldırılır; eski DNS imzalamaya devam ederken önceki DS TTL süresinin dolması beklenir. Ardından nameserver değiştirilir, eski delegasyon önbelleklerinin süresi dolduktan sonra yeni imzalama doğrulanır ve eşleşen yeni DS yayımlanır. Bunu her sağlayıcıda aynı araçlarla veya sabit sürelerle uygulanabilen bir işlem saymayın; mevcut TTL değerlerini ve yetkili DNS yanıtlarını esas alın.

4. Adım: Web sitesi ve uygulamaları yeni sunucuda test edin

DNS’i çevirmeden önce mutlaka yeni ortamda kapsamlı test yapmalısınız. Bunun için üretim domainini kullanmak zorunda değilsiniz.

4.1. Hosts dosyasıyla lokal yönlendirme

Bilgisayarınızdaki hosts dosyasını kullanarak, sadece kendi makinenizden giden istekleri yeni IP’ye yönlendirebilirsiniz. Böylece gerçek domain adıyla, DNS’i küresel olarak değiştirmeden test imkanı bulursunuz.

• Hosts dosyasına yeni sunucu IP’si ve alan adını ekleyin.
• Tarayıcı önbelleğini temizleyin.
• Siteyi son kullanıcı gözüyle gezerek formlar, ödeme adımları, giriş‑çıkış gibi kritik akışları test edin. Ödeme testlerinde sağlayıcının test modunu kullanın; test ortamının gerçek e‑posta, sipariş veya webhook işlemleri başlatmasını önleyin.

4.2. Özel alt alan adıyla staging ortamı

Alternatif olarak staging ya da test alt alanı tanımlayabilirsiniz. Örneğin staging.ornekalanadi.com gibi bir subdomaini doğrudan yeni sunucuya yönlendirip, taşıma öncesinde burada test yapabilirsiniz. Bu model, özellikle devam eden geliştirmeleriniz varsa çok işe yarar. Üretim verisi içeren staging ortamına erişimi kimlik doğrulamayla sınırlandırın; yalnızca robots.txt ile engellemek erişim koruması sağlamaz. Yayına geçmeden önce gerçek alan adıyla HTTPS, yönlendirme ve oturum akışlarını da test edin.

4.3. Performans ve log kontrolleri

Yeni sunucuya geçtiğinizde sadece sitenin açılması yeterli değildir. Aşağıdakileri de kontrol edin:

• PHP hata loglarında uyarı ya da kritik hata var mı?
• Veritabanı bağlantı süreleri ve sorgu performansı kabul edilebilir seviyede mi?
• Önbellekleme (page cache, object cache) düzgün çalışıyor mu?

Daha teknik performans optimizasyonu ihtiyaçlarınız varsa, DCHost blogumuzdaki WordPress, Laravel ve veritabanı odaklı performans rehberlerinden yararlanabilirsiniz.

5. Adım: DNS cutover – trafiği yeni sunucuya çevirme anı

DNS cutover, gerçek kullanıcı trafiğini yeni sunucuya yönlendiren DNS değişikliğidir. Önbellekler farklı zamanlarda yenilendiği için tüm kullanıcılar aynı anda yeni sunucuya geçmez.

5.1. Geçiş öncesi kontrol listesi

DNS kayıtlarını değiştirmeden hemen önce aşağıdakileri kontrol edin:

• Yeni sunucudaki site içeriği güncel mi ve son verilerle senkronize mi?
• Veritabanı son kez senkronize edildi mi? Son kopyalama sırasında eski ortamda yeni yazmaları durdurun veya veri kaybını önleyen bir replikasyon ve yazma devri planı uygulayın; dosya yüklemelerini ve arka plan görevlerini de bu plana dahil edin.
• SSL sertifikası yeni sunucuda düzgün tanımlı mı ve tarayıcıda güvenli olarak görünüyor mu?
• E‑posta için gerekli MX, SPF, DKIM ve mevcut DMARC kayıtları korunuyor mu? E‑posta hizmeti değişiyorsa gerekli yetkilendirmeler gönderim başlamadan hazır mı?
• Nameserver değişecekse yeni yetkili sunuculardaki kayıtlar kontrol edildi mi ve 3.3’teki DNSSEC/DS geçiş önkoşulları karşılandı mı?
• Geri dönüşü tetikleyecek hata ölçütleri ve sorumlular belirlendi mi? Eski DNS değerlerini saklayın; yeni ortamda oluşan verileri kaybetmeden geri dönme yöntemini planlayın. Yalnızca DNS’i eski IP’ye çevirmek yeni yazmaları geri taşımaz; nameserver geri dönüşünde DS/anahtar uyumunu da yeniden değerlendirin.

5.2. A ve AAAA kayıtlarını yeni IP’ye güncelleyin

İlk adım olarak genellikle sadece A ve varsa AAAA kayıtları güncellenir:

• www alt alanı A kaydı kullanıyorsa bunu yeni sunucunun IPv4 adresine çevirin; CNAME kullanıyorsa hedefinin yeni ortama çözümlendiğini kontrol edin.
• Kök alan adınızın (example.com) A kaydını da yeni IPv4 adresine çevirin.
• Mevcut AAAA kayıtlarını yeni sunucunun çalışan IPv6 adreslerine yönlendirin. Yeni ortam IPv6 sunmuyorsa eski sunucuya işaret eden AAAA kayıtlarını geçiş planı kapsamında kaldırın ve önbellek sürelerini hesaba katın.

Düşük TTL, eski yüksek TTL ile önbelleğe alınmış yanıtların süresi dolacak kadar önceden uygulanmışsa, kayıt değişiklikleri kısa sürede görülmeye başlayabilir. Bu, tüm kullanıcılar için birkaç dakikada geçiş garantisi değildir.

5.3. E‑posta MX, SPF ve DKIM ayarlarını senkron tutun

Web trafiğiyle birlikte e‑posta altyapısını da taşıyorsanız, yeni posta kutularını ve ilk içerik eşitlemesini önceden hazırlayın. SPF ve DKIM yetkilendirmelerini yeni sunucudan gönderime başlamadan önce yayımlayın; MX değişikliğini planlanan bakım penceresinde yapın. Eski sunucuya ulaşan iletiler için son eşitleme ve erişim planı oluşturun:

• MX kayıtlarını yeni e‑posta sunucularına işaret edecek şekilde düzenleyin.
• Mevcut tek SPF politikasını, yeni gönderim kaynağını uygun SPF mekanizmalarıyla yetkilendirecek şekilde güncelleyin; çıplak hostname eklemeyin veya ikinci bir SPF kaydı oluşturmayın. DNS sorgusu gerektiren terimler için 10 sınırını hesaba katın; eski kaynağı gönderimi bitene kadar yetkili tutun.
• DKIM için yeni sunucunun kullandığı selector altında public key kaydını yayımlayın. Eski imzalı iletilerin doğrulanması hâlâ gerekebileceğinden önceki selector kaydını hemen silmeyin.

SPF, DKIM ve DMARC tarafını sıfırdan kurgulamanız gerekiyorsa, SPF, DKIM ve DMARC rehberimiz size teknik olarak adım adım yol gösterecektir.

5.4. Eski sunucuyu hemen kapatmayın

DNS önbellekleri farklı zamanlarda yenilenebileceği için eski sunucuya bir süre daha trafik gelebilir. Bu yüzden:

• Eski sunucuyu en az 24–48 saat daha yayında tutmayı planlayın; kapatma kararını yalnızca bu süreye değil, önceki TTL değerlerine ve trafik gözlemlerine de dayandırın.
• Kritik uygulamalarda iki bağımsız veritabanını eşzamanlı yazmaya açmayın. Geçişte tek bir yetkili yazma noktası kullanın; eski ortama gelen yazma isteklerini bu noktaya aktarın veya eski ortamı salt okunur/bakım modunda tutun. Replikasyon kullanıyorsanız yönünü ve yazma devrini önceden planlayın.
• Logları takip ederek eski sunucuya hâlâ trafik gelip gelmediğini gözlemleyin.
• Eski sunucuyu kapatmadan veya hosting paketini iptal etmeden önce yetkili DNS’in ve kullanılan posta hizmetinin bu sunucuya ya da pakete bağlı olup olmadığını kontrol edin. Web trafiğinin taşınmış olması DNS hizmetinin artık gereksiz olduğu anlamına gelmez. DNS aynı sağlayıcıda kalacaksa hizmetin devamını doğrulayın; taşınacaksa kayıtların, delegasyonun ve varsa DNSSEC/DS geçişinin tamamlandığını kontrol etmeden eski yetkili DNS’i sonlandırmayın.

Bu yaklaşım, özellikle yavaş DNS cache güncelleyen ağlar ya da kurumsal proxy’ler yüzünden oluşabilecek sorunları büyük ölçüde azaltır.

6. Adım: Domain transferini ne zaman yapmalısınız?

Hosting firması değiştirirken domaini de başka bir kayıt kuruluşuna taşımak isteyebilirsiniz. Ancak aynı anda hem hosting hem domain transferi yapmak karmaşıklığı artırır.

6.1. Domain transferini hosting taşımasından ayırmak genellikle daha güvenli

Değişiklikleri birbirinden ayırarak riski azaltabilecek bir senaryo şudur:

1. Önce hosting taşınır ve DNS kayıtları yeni sunucuya yönlendirilir.
2. Her şeyin stabil olduğundan emin olunur.
3. Domain transferi için ayrıca bir bakım penceresi planlanır.

Bu sırada nameserver’lar sabit tutulabilir, sadece domainin kayıt kuruluşu değişir. Böylece bir saat içinde hem nameserver hem kayıt kuruluşu hem de hosting firması değişmiyor olur.

6.2. Domain transferi öncesi dikkat edilmesi gerekenler

Taşıma öncesi mutlaka şu kontrolleri yapın:

• Alan adının transfer uygunluğunu ve geçerli kilit veya bekleme koşullarını kayıt kuruluşundan doğruladınız mı? Kaldırılabilir transfer kilidini, transferi başlatmaya hazır olduğunuzda kaldırın.
• Kayıt kuruluşundaki alan adı iletişim e‑posta adresiniz erişilebilir ve doğru mu?
• Alan adı uzantınızın transfer süreci gerektiriyorsa EPP/transfer kodunu aldınız mı?
• Domain süresi bitiş tarihi çok yakın mı? (Transfer öncesi yenilemek mantıklı olabilir.)

Adım adım domain transfer sürecini merak ediyorsanız, alan adı transferi nasıl yapılır rehberimizde süreci sakin ve detaylı şekilde anlattık.

6.3. Domain transferi e‑postayı etkiler mi?

Domain transferi tek başına e‑posta taşıması değildir. Nameserver’lar ve e‑postayla ilgili DNS kayıtları korunur, mevcut DNS ve posta hizmetleri de devam ederse e‑posta hizmetinizin etkilenmesi beklenmez. Ancak:

• Eski kayıt kuruluşunun sağladığı DNS hizmetinin transfer sonrasında devam edip etmeyeceğini doğrulayın. DNS hizmeti de değişecekse tüm kayıtları yeni yetkili DNS sunucularında önceden hazırlayıp kontrol edin; yalnızca yeni panelde görünmeleri yeterli değildir.
• Taşıma esnasında nameserver değiştirecekseniz e‑posta kesintisi riskini azaltmak için TTL ve paralel yayın planına delegasyon önbelleklerini de dahil edin. DNSSEC etkinse 3.3’teki DS/anahtar uyumu ve geçiş sırasını uygulamadan nameserver değiştirmeyin; web kayıtlarının düşük TTL değeri bu kontrollerin yerine geçmez.

Bu konu için ayrıca, alan adı taşırken e‑posta kesintisini önlemek rehberimizi de inceleyebilirsiniz.

7. Adım: SEO, SSL ve güvenlik için son kontroller

Taşıma tamamlandığında siteniz açılıyor olabilir, ancak SEO ve güvenlik tarafında yapmanız gereken son dokunuşlar vardır.

7.1. SSL ve HTTPS kontrolleri

• Yeni sunucuda SSL sertifikası doğru alan adlarını kapsıyor mu?
• HTTP’den HTTPS’e 301 yönlendirmeleri düzgün çalışıyor mu?
• Mixed content uyarılarına yol açan HTTP içerikler kaldı mı?

HTTPS geçişi ve 301 yönlendirmeleri konusunda derinlemesine bilgi için, HTTP’den HTTPS’e geçiş rehberimizi inceleyebilirsiniz.

7.2. robots.txt, sitemap ve SEO sinyalleri

Taşıma sonrası arama motorlarının sitenizi sorunsuz taramaya devam etmesi gerekir:

• robots.txt dosyanız yeni sunucuda doğru konumda ve doğru içerikte mi?
• sitemap.xml dosyanız güncel ve erişilebilir mi?
• Önemli sayfalarda beklenmedik 404, 500 gibi durum kodları oluşuyor mu?

Bu kontrolleri otomatize etmek için log analizi ve uptime izleme araçlarını da devreye alabilirsiniz.

7.3. Güvenlik ve yedekleme stratejisini güncelleyin

Yeni sunucuya geçtikten sonra güvenlik ve yedekleme politikalarınızı da yeni altyapınıza göre güncellemelisiniz:

• Güncel firewall ve brute‑force koruma ayarlarını uygulayın.
• Otomatik yedekleme planını yeni sunucuda aktifleştirin.
• Yedekleri üretim sunucusundan bağımsız, farklı bir lokasyonda saklayın; object storage kullanıyorsanız onun da bu ayrımı sağladığını doğrulayın. Yeni ortamda bir geri yükleme denemesiyle yedeklerin kullanılabilirliğini kontrol edin.

3‑2‑1 yedekleme stratejisini nasıl kurabileceğinizi merak ediyorsanız, DCHost blogumuzda bu konuda detaylı bir rehber bulabilirsiniz.

8. Adım: Hosting firması değiştirirken özet kontrol listesi

Tüm yazıyı uygulamada hızlı kullanabilmeniz için, kritik adımları kompakt bir kontrol listesi halinde toparlayalım.

8.1. Taşıma öncesi hazırlık

• Tüm domain ve alt alan adlarının listesini çıkarın.
• Mevcut DNS sağlayıcınızı ve tüm kayıtları (A, AAAA, CNAME, MX, TXT, SRV, CAA) export edin veya manuel kaydedin.
• E‑posta altyapısını ayrı başlık olarak planlayın (MX, SPF, DKIM, webmail, IMAP/SMTP ayarları).
• Domain transferi de yapacaksanız, bunu hosting taşımasından ayrıştırın.

8.2. Yeni sunucuyu hazırlama

• DCHost üzerinde ihtiyaçlarınıza uygun hosting, VPS ya da dedicated sunucu planını netleştirin.
• Gerekli yazılım sürümlerini (PHP, veritabanı vb.) uygulamayla uyumlu ve güvenlik desteği devam eden sürümlerden seçin; eski ortam destek dışıysa aynı sürümü kopyalamak yerine uyumluluk testleriyle yükseltmeyi planlayın.
• Web dosyalarını ve veritabanlarını yeni ortama aktarın.
• cPanel kullanıyorsanız, panelden panele otomatik transfer imkanlarını değerlendirin.

8.3. DNS ve TTL planı

• Örneğin taşıma gününden 48–72 saat önce kritik kayıtların TTL değerlerini, DNS sağlayıcınız destekliyorsa 300 saniyeye düşürün; geçişten önce eski TTL süresinin dolmasına zaman bırakın. Önceki TTL daha uzunsa hazırlığa daha erken başlayın.
• Nameserver değiştirmeden sadece A/AAAA ve ilgili kayıtlarla geçiş mi, yoksa nameserver taşıması mı yapacağınıza karar verin. Nameserver değişecekse kayıtları yeni yetkili sunucularda önceden hazırlayıp kontrol edin.
• DNSSEC etkinse üst bölgedeki DS kaydı ile yeni imzalama anahtarlarının uyumunu ve 3.3’teki geçiş sırasını sağlayıcılarla netleştirin. DS ve NS/delegasyon önbellekleri için ayrıca süre planlayın; A/AAAA TTL düşürme bunları kısaltmaz.
• Web cutover’ını belirli bir bakım penceresinde planlayın; nameserver ve domain transferini gerektiğinde ayrı aşamalara ayırın. DNSSEC hazırlıklarını tek bir kısa pencereye sıkıştırmayın.

8.4. Taşıma ve cutover

• Yeni sunucuyu hosts dosyası ya da staging alt alanıyla test edin; yayından önce gerçek alan adıyla HTTPS ve kritik akışları da doğrulayın.
• Son içerik ve veritabanı senkronizasyonundan önce eski ortamda kullanıcı işlemleri ve arka plan görevleri dahil veri yazımını durdurun ya da doğrulanmış bir replikasyon planı uygulayın. Geçiş sırasında yazmaların tek yetkili ortamda toplanmasını sağlayın.
• A kayıtlarını yeni IPv4 adreslerine yönlendirin. Varsa AAAA kayıtlarını çalışan yeni IPv6 adreslerine yönlendirin; yeni ortam IPv6 sunmuyorsa eski hedefe giden AAAA kayıtlarını önbellek sürelerini hesaba katarak kaldırın. www bir CNAME kullanıyorsa hedefini kontrol edin. E‑posta hizmeti de taşınıyorsa MX kayıtlarını yeni hizmetin belirttiği posta sunucusu adlarına güncelleyin; MX hedefi IP adresi değildir.
• SPF, DKIM ve diğer TXT kayıtlarını yeni hizmetin gereksinimleriyle karşılaştırın; yalnızca gerekli değişiklikleri yapın. Yeni gönderim kaynağını kullanmadan önce SPF ve DKIM yetkilendirmelerini yayımlayın. Posta hizmeti yerinde kalıyorsa gerekli MX, posta sunucusu adres ve kimlik doğrulama kayıtlarını koruyun; değiştirdiğiniz web adreslerine bağımlılıklarını kontrol edin. Web sitesinin gönderim kaynağı değişiyorsa posta kutuları taşınmasa bile yetkilendirme güncellemesi gerekebilir.
• Eski sunucuyu en az 24–48 saat daha erişilebilir tutmayı planlayın; kapatma kararını eski TTL süreleri ve trafik loglarıyla doğrulayın. Veri tutarlılığı planı yoksa eski ortamda yeniden yazma kabul etmeyin.
• Eski hosting paketini iptal etmeden önce pakete bağlı yetkili DNS ve posta hizmetlerinin devamını veya tamamlanmış geçişini doğrulayın. Web trafiğinin bitmesini DNS hizmetini sonlandırmak için yeterli saymayın.
• Geri dönüş gerekirse yeni ortamda oluşan verileri koruyan yazma devri planını uygulayın; nameserver geri dönüşünde DNSSEC/DS uyumunu da kontrol edin.

8.5. Taşıma sonrası kontroller

• Önemli sayfalar, formlar ve ödeme akışlarını canlı ortamda test edin.
• SSL, HTTPS yönlendirmeleri ve mixed content hatalarını kontrol edin.
• robots.txt ve sitemap.xml dosyalarının erişilebilir olduğundan emin olun.
• Logları takip edip 4xx ve 5xx hata oranlarını izleyin.
• Her şey stabil olduğunda TTL değerlerini yeniden yükseltin.

Hosting değişiminde kesintiyi azaltan plan nasıl görünür?

Doğru planlandığında hosting firması değiştirmek, son kullanıcının fark etmeyeceği kadar pürüzsüz bir süreç olabilir. Önerilen plan şu sırayı izler: Önce ayrıntılı DNS ve domain envanteri çıkarılıyor, ardından yeni sunucu paralel olarak hazırlanıyor, TTL stratejisiyle desteklenen kontrollü bir DNS cutover yapılıyor ve son olarak SEO ile güvenlik kontrolleri tamamlanıyor.

Paylaşımlı hosting, VPS, dedicated sunucu ya da colocation kullanırken bu kontrol listesini, erişim yetkilerinize ve yönetim sorumluluklarınıza göre uyarlayarak bir runbook için başlangıç noktası olarak kullanabilirsiniz. Dış desteğe ihtiyaç duyarsanız DNS değişiklikleri, domain transferi ve sunucu taşıması için sorumluları, erişim yetkilerini ve destek kapsamını geçişten önce netleştirin.

Taşıma süresi veri hacmine, uygulamanın yazma trafiğine ve DNS önbelleklerine bağlıdır; birkaç saatle sınırlı olacağı varsayılmamalıdır. Kontrol listesini ekibinizle paylaşın ve bakım penceresini son senkronizasyon, doğrulama ve gerekirse geri dönüş için yeterli zaman ayırarak belirleyin.