Hosting Taşıma: Ziyaretçi Kayıp Etmeden Adım Adım Geçiş

Hosting taşıma, yalnızca dosyaları aktarmak değildir. DNS zamanlaması, yönlendirmeler, TLS (SSL) sertifikası süreleri, önbellek (cache) davranışı ve veri tabanı ölçeği doğru planlanmazsa ziyaretçiler geçici hata sayfaları görür. Bu rehberde web sitenizi ziyaretçi kaybetmeden yeni sunucuya taşımanız için ölçülebilir, kontrol listeli bir süreç izleyeceksiniz: taşıma öncesi hazırlık, paralel test, kesinti penceresi, DNS geçişi ve doğrulama.

Aşağıdaki adımlar özellikle WordPress, OpenCart ve custom uygulamalarda aynı mantıkla uygulanır; farklılıklar varsa belirtilecektir.

1) Taşıma stratejisini seçin: “paralel çalışma” + “kontrollü kesinti”

Ziyaretçi kaybetmenin en yaygın nedeni, sitenin yeni sunucuda hazır olmadan DNS’i değiştirmektir. Bunun yerine iki fazlı bir plan uygulayın.

Faz 1: Yeni ortamı hazırlayın ve aynı içeriği servis edin

Yeni hosting/VDS ortamında siteyi kurun (dosyalar + veritabanı).
Aynı domain için TLS sertifikasını hazır edin.
Ön belleği devre dışı bırakın ya da yeni ortamda temizleyin (WordPress’te cache plugin, sunucu seviyesinde opcache/redis vb.).
Siteyi sadece siz değil, başkaları da görebilsin diye geçici erişim yöntemi belirleyin.

Faz 2: DNS ve yönlendirmeleri kontrollü şekilde değiştirin

DNS değişiminden sonra arama motorları ve kullanıcılar farklı zamanlarda yeni hedefi görecektir.
Bu süreyi yönetmek için TTL ve yönlendirme zincirini doğru kurmalısınız.

Net hedef: DNS geçişi sırasında 404/500 hatası üretmeden, kullanıcıların otomatik olarak doğru içeriğe ulaşmasını sağlamak.

2) Taşıma öncesi ölçüm: hangi değerleri “hedef” yapacaksınız?

Taşıma sonrası sorun tespiti için önce mevcut durumu netleştirin.

Aşağıdaki verileri kaydedin:

Ana sayfa ve 5-10 kritik sayfanın yüklenme süresi (ör. 3 deneme ortalaması)
HTTP durum kodları dağılımı (200/301/302/403/404/500)
Site içi arama ve ödeme/forma giden akışlar (OpenCart/WordPress formlar)
WordPress ise: wp-content boyutu, veritabanı boyutu, eklenti listesi
Uygulama ise: environment (API base URL, DB host), dosya yükleme boyutu limitleri

SEO için kritik: indekslenebilir URL listesi

Google Search Console’da mevcut performans raporunuzdaki “en çok tıklanan URL”leri listeleyin.
Robots.txt ve sitemap.xml’in yeni ortamda aynı davranacağını doğrulayın.

Bu veriler sayesinde taşıma sonrası “hata var mı yok mu” sorusunu sübjektif yerine sayısal cevaplayabilirsiniz.

3) Teknik hazırlık: dosya + veritabanı + TLS + aynı yapı

Ziyaretçi kaybetmeden geçiş için dört bileşeni birlikte ele alın: dosyalar, veritabanı, TLS (SSL), yönlendirmeler.

Dosyaları taşıma

WordPress/OpenCart gibi sistemlerde dosyaların tamamını kopyalayın.
wp-config.php / config.php / environment dosyaları gibi DB bağlantı ayarlarının yeni ortam için değiştiğinden emin olun.
Büyük sitelerde rsync benzeri yöntemler avantaj sağlar; amaç tutarlı kopya yapmaktır.

Veritabanını taşıma

DB’yi export/import yaparken karakter seti ve collation uyuşmazlıklarına dikkat edin.
Taşıma öncesi DB yedek (backup) alın.
En kritik tabloları test edin: kullanıcı oturumu tabloları, sipariş tabloları, yorum tablosu.

TLS (SSL) hazırlığı: geçişte güvenlik uyarısı üretmeyin

Yeni ortamda sertifikayı domain için hazır edin.
Sertifika aracı (Let's Encrypt vb.) kurulumunda DNS doğrulaması kullanıyorsanız, DNS geçişiyle aynı ana denk getirmemeye dikkat edin.
Geçiş sırasında sertifika yoksa kullanıcılar tarayıcıda uyarı görecektir; bu doğrudan ziyaret kaybı üretir.

Yönlendirmeler ve URL yapısı

Eski sitedeki permalink yapısı (WordPress) birebir korunmalıdır.
OpenCart’ta admin/SEO ayarları ve rewrite kuralları aynı olmalı.

En sık sorun: “yönlendirme zinciri”

Yanlış yapılandırma örnekleri: - 301 yerine 302 kullanımı (arama motoru sinyalini zayıflatır) - Gereksiz bir path eklenmesi (ör. /blog iki kez görünür) - HTTP→HTTPS→HTTP döngüsü

Bunları geçiş öncesi test edin.

4) Paralel test: DNS değiştirmeden önce doğrulama yapın

DNS’i değiştirmeden de yeni ortamı doğrulamak mümkündür.

Geçici test yöntemleri

Hosts dosyası ile domain’i yeni IP’ye yönlendirmek (lokal test)
Yeni sunucuda geçici bir alt domain kullanmak (ör. staging.domain.com)
Yeni sunucunun IP’si üzerinden test (TLS için sertifika doğrulamasına dikkat)

Test kontrol listesi

Her kritik sayfa için tarayıcıda görüntü (CSS/JS/CORS konsol hataları yok)
Formlar ve ödeme akışı (istekler doğru endpoint’e gidiyor mu)
Admin panel / API endpointleri (401/403 hataları doğru mu)
Resimler ve dosya yüklemeleri (403/404 yok)
Sitemap.xml ve robots.txt (doğru domain ve doğru protokol)

Cache ve oturum (session) testleri

Yeni ortamda cache davranışı farklıysa içerik eski kalabilir.
Oturum çerezleri (cookie) domain bazlı olduğundan, taşıma sonrası “oturum çıkması” normaldir; fakat hata sayfası üretmemelidir.

5) DNS geçiş planı: TTL, kesinti penceresi ve hedef doğrulama

DNS geçişi sırasında kullanıcıların bir kısmı eski, bir kısmı yeni sunucuya gidebilir. Bu yüzden TTL ve geçiş sonrası doğrulama kritik.

TTL’yi düşürün: geçiş zamanını kısaltın

DNS yöneticinizde domain için TTL değerini geçişten 24-48 saat önce düşürün.
Amaç: DNS güncellemesinin yayılma süresini kısaltmak.

Örnek kural: - Önceden yüksek TTL varsa (ör. 1 gün) geçiş sonrası kullanıcıların bir kısmı uzun süre eski sunucuyu görür. - Düşük TTL (ör. 300-600 saniye) ile yayılma daha hızlı tamamlanır.

Ne zaman DNS değiştirilmeli?

Trafiğinizin en düşük olduğu saat dilimini seçin.
Aynı anda büyük veri aktarımı yapmayın.
Geçiş sırasında siz test için hazır olun (Sunucu logları ve uygulama logları açık).

A kaydı / CNAME zinciri ve yönlendirme kararları

IP bazlı A kaydı değiştiriyorsanız: yeni sunucunun web servisinin hemen hazır olduğundan emin olun.
CNAME kullanıyorsanız: hedef kayıt gecikmelerini kontrol edin.

Yönlendirme stratejisi

Eski sunucuda (taşıma sonrası) en az birkaç gün 301 ile yeni URL’ye yönlendirin.
Statik içerikler için de aynı yaklaşımı uygulayın; “resim 404” sorunu sık görülür.

6) Taşıma sonrası doğrulama: 24 saatlik “hata avı”

DNS değişiminden sonra her şey otomatik olarak düzelmez. Kontrol etmeniz gereken alanlar vardır.

İlk 1-2 saat: gözlemlenecek sinyaller

4xx/5xx hataları (özellikle 404 ve 500)
TLS uyarıları (sertifika hatası)
Erişilebilirlik (ana sayfa ve kritik sayfalar)
Sunucu kaynakları (CPU/RAM disk; ani yükseliş var mı)

İlk 24 saat: kök neden analizi için loglar

Web sunucusu erişim logları: yönlendirme doğru mu?
Uygulama logları: veritabanı bağlantı hatası, dosya yolu (path) hatası, environment değişikliği
CDN/WAF kullanıyorsanız: kural tetikleniyor mu?

Search Console ve indeks sinyali

Sitemap.xml yeni ortamda doğru mu?
robots.txt engellemesi yok mu?
Search Console’da tarama/indeks hatası raporlarını kontrol edin.

Performans doğrulaması: “taşındı ama yavaşladı” senaryosu

Yeni sunucuda cache açılmaması veya yanlış PHP ayarları yavaşlık yaratır.
Aynı sayfada ölçüm yapın: ör. ana sayfa için TTFB ve toplam süre kıyaslayın.

Sık yapılan hatalar (ve net çözümleri)

Sertifikayı geç hazırlamak: Geçiş sonrası tarayıcı uyarısı üretir. Çözüm: yeni ortamda sertifika hazır olsun.
TTL’yi düşürmemek: Yayılma uzar, bazı kullanıcılar eski yerde kalır. Çözüm: geçiş öncesi TTL düşür.
Permalink/URL kuralı değişikliği: SEO sinyali kaybı ve 404 artışı. Çözüm: aynı URL yapısını koru.
Önbellek/OPcache karışması: Eski içerik görünür. Çözüm: yeni ortam cache temizliği ve doğru cache kurgusu.
Giden bağlantıların (internal link) değişmemesi: Yeni domain/protokol uyumsuzsa karışık içerik oluşur. Çözüm: HTTP/HTTPS tutarlılığını sağlayın.

Sonuç: Ziyaretçi kaybını sıfıra yaklaştıran aksiyon planı

Hosting taşıma sürecinde ziyaretçi kaybını azaltan kritik yaklaşım şudur: paralel hazırlık + TTL kontrollü DNS + geçişte 301 yönlendirme + 24 saat doğrulama. İlk adım olarak mevcut URL listesini (Search Console) çıkarın, TTL düşürmeyi planlayın ve yeni ortamı önce staging/hosts ile doğrulayın. DNS değişimini sadece yeni ortam hazır olduktan sonra yapın; geçişten sonra da loglardan hataları hızlıca yakalayın.

İsterseniz bir sonraki adım olarak taşıdığınız platformu (WordPress, OpenCart, custom), mevcut ve yeni hosting türünü (web hosting/VPS/VDS) ve domain DNS sağlayıcınızı yazın; size bu rehbere uygun net bir zaman çizelgesi (geçiş günü saat planı) çıkarabilirim.