Wix ve Shopify’dan WordPress’e Geçiş Planı

Neden Hazır Site Kurucudan WordPress’e Geçmek Mantıklı?

Wix ve Shopify gibi platformlar, hosting ile site yönetiminin önemli bir bölümünü birlikte sunar. İhtiyaç duyduğunuz tasarım, entegrasyon, veri erişimi veya maliyet yapısı mevcut pakete uymadığında WordPress’e geçiş değerlendirilebilir. Önce gerçekten hangi özelliğe ihtiyaç duyduğunuzu belirleyin; platform değiştirmek tek başına daha hızlı veya daha ucuz bir site sağlamaz.

Kendi hosting’inizde çalışan WordPress, uygulama dosyaları ve veritabanı üzerinde daha fazla erişim sağlar. Tema, eklenti ve sunucu ayarlarının kapsamı yine lisanslara, hizmet planına ve yetkilerinize bağlıdır. Bakım, yedekleme ve güvenlik sorumluluklarını da planlamalısınız. Sağlam bir taşıma planı kesinti ve SEO kaybı riskini azaltır; sıralamaların değişmeyeceğini garanti etmez. Özellikle ürün, müşteri ve sipariş verilerinin nasıl aktarılacağını baştan netleştirin.

Bu rehberde, hazır site kuruculardan WordPress’e geçişi; hosting seçimi, DNS-SSL ayarları, 301 yönlendirmeler, içerik/ürün taşıma ve test süreci dahil uçtan uca adım adım anlatacağız. Amacımız, geçişi sadece “site taşıma” değil, sürdürülebilir ve performanslı bir WordPress mimarisine geçiş olarak kurgulamanıza yardımcı olmak.

Geçiş Öncesi Hazırlık: Envanter ve Strateji

Mevcut Sitenizin Detaylı Envanterini Çıkarın

Başarılı bir migration’ın ilk adımı, neye sahip olduğunuzu net görmek. Hazır site kurucudaki mevcut yapınızı mutlaka envanterleyin:

• Sayfalar, blog yazıları, kategori ve etiketler: URL, başlık, içerik, tarih ve önem derecesi.
• Ürünler, varyantlar, SKU’lar, konuma göre stoklar, koleksiyonlar ve görseller.
• Müşteri kayıtları, hesap açılışı, siparişler, ödeme/iadeler, indirimler, hediye kartları ve abonelikler.
• Formlar, arama, ödeme, kargo, vergi, CRM/ERP ve pazaryeri entegrasyonları.
• Analytics ve Search Console’daki trafik alan URL’ler, dış bağlantılı sayfalar, PDF ve diğer dosyalar.
• Alan adı, yetkili DNS, e-posta hizmeti, erişimler ve eski sistemin ne kadar açık kalması gerektiği.

En çok trafik veya dış bağlantı alan URL’leri önce inceleyin; envanteri bunlarla sınırlamayın. Taşınacak içeriklerin karşılığını WordPress’te hazırlayın. İçerik aynı adreste kalıyorsa yönlendirme gerekmez; değişen adreslerin ilgili son hedefe gitmesi gerekir.

Hedefleri ve KPI’ları Netleştirin

Geçiş sadece “WordPress’e taşınalım” diye yapılmamalı. Net hedefler belirleyin:

• Organik trafiği korumak (ve orta vadede artırmak)
• Core Web Vitals metriklerini iyileştirmek
• Form dönüşüm oranlarını artırmak
• E-ticaret tarafında sepet, ödeme, upsell senaryolarını geliştirmek

Bu hedefler, tema seçiminden sunucu kapasitesine kadar vereceğiniz pek çok kararı etkileyecek.

Zamanlama ve Bakım Penceresi Planı

Geçiş için sorumlu kişiyi, kontrol noktalarını ve işlemi durduracak hata koşullarını önceden belirleyin. Ödeme alınamaması, sipariş/stok tutarsızlığı, temel içerik eksikliği veya yaygın HTTPS/5xx hatası, canlıya almayı ertelemek ya da geri dönüşü değerlendirmek için somut nedenlerdir. Sipariş ve diğer yazma işlemlerinin ne zaman durdurulup hangi sistemde yeniden açılacağını da plana ekleyin:

• Analytics üzerinden en düşük trafik saatlerini belirleyin.
• Değiştireceğiniz DNS kayıtlarının TTL değerlerini, geçişten en az mevcut TTL süresi kadar önce düşürün. TTL’yi düşürmek, önceden önbelleğe alınmış yanıtların süresini kısaltmaz. Bu konuda Zero-Downtime taşıma için TTL stratejileri rehberimiz adım adım yol gösteriyor.
• Geçiş öncesi ve sonrası için performans ve SEO metriklerini not alın; böylece migration’ın etkisini ölçebilirsiniz.

WordPress İçin Doğru Hosting Altyapısını Seçmek

Paylaşımlı Hosting mi, VPS mi?

Hazır site kurucudan WordPress’e geçtiğinizde altyapı sorumluluğu size geçer. Bu noktada ilk büyük karar: paylaşımlı hosting mi, VPS mi?

• Paylaşımlı hosting: Trafiği düşük kurumsal siteler, portföy siteleri ve küçük bloglar için maliyet-etkin ve yönetimi kolay bir seçenek.
• VPS (Sanal Sunucu): Orta–yüksek trafikli bloglar, WooCommerce mağazaları ve özelleştirilmiş uygulamalar için değerlendirilebilir. Uygunluk, iş yüküne ve paketin kaynak sınırlarına bağlıdır; VPS etiketi tek başına daha yüksek performans sağlamaz. Sunucu üzerinde daha fazla kontrol, özellikle yönetilmeyen hizmetlerde daha fazla bakım ve güvenlik sorumluluğu da getirir.

Karar verirken; aylık ortalama trafik, beklenen büyüme, eklenti sayısı, içerik hacmi ve eşzamanlı ziyaretçi hedeflerini dikkate alın. Bu konuda daha derinlemesine okumak isterseniz, paylaşımlı hosting mi VPS mi karşılaştırma rehberimize mutlaka göz atın.

Managed WordPress mi, Klasik Hosting mi?

Teknik detaylarla uğraşmak istemeyenler için Managed WordPress hosting oldukça konforlu bir seçenek. Sunucu güncellemeleri, güvenlik sertleştirme, yedekler ve temel optimizasyonların hangilerinin hizmete dahil olduğunu paket kapsamında kontrol edin. Paylaşımlı hosting’de sunucu yönetimi genellikle sağlayıcıdadır; yönetilmeyen VPS’te ise sunucu bakımı da size aittir. WordPress, tema ve eklenti bakımının kime ait olduğunu ayrıca netleştirin.

Yönetilen ve yönetilmeyen VPS rehberimiz sorumlulukları karşılaştırır. DCHost paylaşımlı hosting, VPS veya dedicated seçeneklerini değerlendirirken WordPress bakımı, yedek geri yükleme, e-posta ve taşıma desteğinin kendi planınızda neleri kapsadığını doğrulayın. Colocation düşünüyorsanız hizmetin mevcut olup olmadığını ve donanım yönetimini ayrıca netleştirin.

Performans ve Core Web Vitals

Hazır site kuruculardan WordPress’e geçişin en büyük fırsatlarından biri, sunucu tarafı optimizasyon yapabilme özgürlüğüdür. PHP versiyonu, HTTP/2–HTTP/3, OPcache, Redis, MySQL/MariaDB ayarları gibi bileşenlerde erişebileceğiniz seçenekler, hosting paketine ve yönetim yetkilerinize bağlıdır; paylaşımlı veya yönetilen hosting’de bazı ayarlar yalnızca sağlayıcı tarafından değiştirilebilir.

Google’ın Core Web Vitals metrikleri LCP, INP ve CLS’dir. TTFB bu kümeye dahil değildir; sunucu yanıt süresini izlemek ve özellikle LCP sorunlarını incelemek için yararlıdır. Hosting altyapısı önemli olsa da INP ve CLS için tema, JavaScript ve sayfa düzeni de değerlendirilmelidir. Bu konuda TTFB, LCP ve CLS’yi sunucu tarafında iyileştirme rehberimiz ve WordPress için sunucu tarafı optimizasyon makalemiz size detaylı bir yol haritası sunar.

Wix, Shopify vb. Platformlardan Verileri Çıkarmak

Sayfa ve Blog İçeriklerini Alma

Wix’in tasarımını ve uygulamasını bir dosya paketi olarak indirip başka hostta çalıştırmak mümkün değildir; Wix sitesi kendi altyapısına bağlıdır. WordPress’te tasarımı ve işlevleri yeniden kurar, erişebildiğiniz içerikleri aktarırsınız. Shopify’da da ürün CSV’si sayfaları, blogu, temayı ve uygulama ayarlarını kapsayan tam bir WordPress aktarımı değildir. Kaynakları envanterle karşılaştırarak ilerleyin:

1. URL, başlık ve içerik türü listesini tarama, site haritası, platform kayıtları ve analiz verileriyle tamamlayın.
2. Desteklenen dışa aktarma veya RSS varsa önce kapsamını kontrol edin. Wix blog RSS’ini tam arşiv dışa aktarımı saymayın; kapsamı sınırlı olduğundan eksik yazıları, tam metni, tarihleri, yazarları ve medyayı ayrıca tamamlayın.
3. Statik sayfaları WordPress’te yeniden oluşturun; menüleri, formları ve diğer işlevleri yeniden yapılandırın. Tema ve uygulama paketlerinin WordPress eklentisi gibi çalışacağını varsaymayın.

Burada önemli olan nokta, URL yapısını şimdilik değiştirmemek. Önce eski URL’lere karşılık gelecek WordPress sayfalarını oluşturun, sonrasında gerekiyorsa URL sadeleştirmeyi 301 yönlendirmelerle birlikte planlayın.

Ürünler ve E-Ticaret Verileri

Shopify veya benzeri bir e-ticaret odaklı hazır kurucudan geçiyorsanız, ürün verileri kritik. Genel yol haritası şöyle olur:

• Shopify ürün CSV’sini dışa aktarın; orijinal kopyayı saklayın. Ürün ve varyant satırlarını birbirinden koparacak gelişigüzel sıralamalar yapmayın.
• Birden çok konum için stok kullanıyorsanız envanter dışa aktarımını ayrıca alın; ürün CSV’sinin tüm konum stoklarını taşıdığını varsaymayın. Koleksiyonları WooCommerce kategori/etiketlerine bilinçli olarak eşleyin.
• CSV alanlarını seçtiğiniz WooCommerce içe aktarıcısının şemasına dönüştürün. Önce küçük bir örnekle SKU, ana ürün–varyasyon bağı, fiyat, vergi ve stokları kontrol edin. Tekrar çalıştırmanın aynı ürünü çoğaltmadığını doğrulayın.
• Ürün görselleri CSV’nin içinde değildir; erişilebilir görsel adreslerinden indirilip yeni medyaya atanmalıdır. Eski medya erişimini bu doğrulama bitmeden kapatmayın.
• Kargo, vergi, para birimi, ödeme ve entegrasyon ayarlarını canlıya almadan yapılandırın. SEO alanları ve görsel alt metinleri içe aktarıcınızda desteklenmiyorsa ayrı aktarın.

Müşteri ve sipariş verileri ürün CSV’sinden ayrı ele alınmalıdır. Shopify’dan müşteri ve sipariş dışa aktarımları alınabilir; WooCommerce’e uygun bir araçla alan, kimlik ve ilişki eşlemesi gerekir. Mevcut giriş bilgilerinin taşınacağını varsaymayın; hesap etkinleştirme veya parola belirleme akışını hazırlayın. Tarihsel siparişler taşınacaksa ödeme, iade, kargo ve müşteri ilişkilerini kontrol edin; salt müşteri kaydı sipariş geçmişi değildir. Taşınmayan geçmişi erişimi sınırlı bir arşivde saklayabilirsiniz; açık siparişler, iadeler ve stok yükümlülükleri için hangi sistemin esas alınacağı yine belirli olmalıdır. Ödeme belirteçleri, abonelikler ve hediye kartları için ayrıca desteklenen geçiş yöntemi gerekir.

Görseller ve Dosyalar

Hazır site kurucular genellikle görselleri kendi CDN’leri üzerinden sunar. WordPress’e geçerken:

• Tüm görselleri klasör yapısıyla birlikte indirmeye çalışın. Eski görsel URL’lerini yeni ortam URL’leriyle eşleştirin; içeriklerdeki görsel bağlantılarını güncelleyip eski CDN’ye bağımlı kalmadıklarını kontrol edin.
• WordPress ortam kütüphanesine yüklerken mümkünse boyut ve format optimizasyonu yapın (WebP/AVIF gibi modern formatlara geçiş için de bu iyi bir fırsat). Bu konuda WebP/AVIF’i kırmadan sunma rehberimiz size yardımcı olabilir.
• PDF, doküman, özel dosyalar için eski URL → yeni URL eşlemesini not alın; kontrol ettiğiniz eski URL’leri 301 haritasına ekleyin. Platformun alan adındaki CDN URL’lerinde yönlendirme yetkiniz olmayabilir; bu dosyalara sitenizden verilen bağlantıları yeni adreslerle güncelleyin.

WordPress Kurulumu ve Temel Yapılandırma

WordPress Kurulumu

Hosting paketinizde WordPress için tek tıkla kurulum varsa işiniz kolay; yoksa klasik yöntemle kurulum yapabilirsiniz:

1. Hosting’in kurulu WordPress/WooCommerce sürümleriyle uyumlu, güvenlik desteği süren PHP ve veritabanı sürümlerini sunduğunu doğrulayın.
2. Yeni ortamda veritabanı ve ona yetkili kullanıcı oluşturun.
3. WordPress’i resmi kaynaktan edinip SFTP gibi şifreli aktarım kullanın; wp-config.php içinde bu ortamın veritabanı bilgilerini tanımlayın.
4. Kurulumu erişimi sınırlandırılmış bir test adresinde veya doğru sunucuya hedeflenen alan adıyla tamamlayın. Örnek test adresi staging.example.com gerçek adresiniz değildir.
5. Yönetici hesabını güçlü parola ve uygun ek doğrulamayla koruyun; test ortamının gerçek müşterilere bildirim, ödeme veya stok güncellemesi göndermesini engelleyin.

Temel Ayarlar ve Kalıcı Bağlantılar

Kurulum biter bitmez şu adımları atlamayın:

• Ayarlar > Genel bölümünde site adı, kısa açıklama ve URL/WordPress adresini kontrol edin.
• Ayarlar > Kalıcı Bağlantılar kısmında mümkün olduğunca mevcut tam URL yollarını koruyun; değişmesi gereken yolları son hedeflerine 301 ile eşleyin. Yalnızca yazı veya ürün slug’ının aynı olması tam adresi korumaz.
• Site dilini, saat dilimini ve tarih/saat formatını doğru ayarlayın.

SSL ve HTTPS Zorunluluğu

HTTPS’i yeni sunucuda, kullanılacak kök alan adı ve www gibi adları kapsayan geçerli bir sertifikayla doğrulayın. DNS henüz eski platformu gösterirken sertifika hazırlamak için desteklenen DNS-01 doğrulaması veya CA’nın isteğini doğru doğrulama noktasına ulaştıran bir düzen gerekir; yerel hosts dosyası CA’nın çözümlemesini değiştirmez. Let’s Encrypt HTTP-01 kullanılıyorsa genel port 80 ve challenge yolu erişilebilir olmalı; yayımlanmış IPv6 da doğru çalışmalıdır. Sertifika ve yenileme desteğini planınızdan doğrulayın. SSL sertifikası rehberimiz temel bilgileri, SSL hata rehberimiz ise kapsam, zincir ve mixed content kontrollerini açıklar.

Güvenlik ve Yedekleme Temelleri

Hazır kurucularda güvenlik büyük oranda platform tarafından yönetilir. WordPress’te ise:

• Düzenli dosya ve veritabanı yedekleri alın. Bunun için WordPress yedekleme stratejileri rehberimizi kullanabilirsiniz.
• Güçlü parolalar ve mümkünse 2FA kullanın.
• Dosya izinleri, XML-RPC, wp-login koruması gibi detaylar için WordPress güvenlik sertleştirme kontrol listemiz yol gösterir.

SEO Kaybı Riskini Azaltmak İçin Teknik Plan

URL Haritası (Redirect Map) Oluşturma

SEO kaybının önemli nedenlerinden biri, eski URL’lerin yeni sitede karşılığının olmaması veya yanlış yönlendirilmesidir. Bu yüzden:

1. Hazır site kurucudaki tüm URL’leri (sayfa, blog yazısı, ürün, kategori, etiket, dosya) bir listeye dökün.
2. WordPress tarafında taşınan her içerik için bir hedef URL belirleyin (mümkünse mevcut URL’yi koruyun). Kaldırılan ve ilgili bir karşılığı bulunmayan içerikleri ilgisiz sayfalara yönlendirmeyin; bunlar için 404 veya 410 yanıtını planlayın.
3. Eski URL → yeni URL eşlemesini tek bir tabloya yazın. Bu tablo, 301 yönlendirme planınız olacak.

Alan adı değiştiriyorsanız konu biraz daha hassas hale geliyor. Alan adı değiştirirken SEO kaybetmemek makalemizde bu süreci ayrı bir perspektiften detaylandırdık; mutlaka göz atın.

301 Yönlendirmeleri Doğru Kurmak

Hazır site kuruculardan dönen siteler bazen karmaşık URL yapıları kullanır. 301 yönlendirme kurarken:

• Kontrol ettiğiniz ve gerçekten değişen eski URL’leri, aynı ihtiyacı karşılayan son hedefe tek adımda yönlendirin. Kendi kendine yönlendirme veya zincir oluşturmayın.
• Genel kural kullanacaksanız bütün eşlemelerin aynı dönüşüme uyduğunu doğrulayın; değişmeyen /blog/ adreslerine sırf geçiş var diye wildcard eklemeyin.
• Apache .htaccess veya Nginx ayarları, gerçek sunucu mimarisi ve yetkileriniz uygunsa kullanılabilir. WordPress kurallarıyla çakışmayı, tam yol eşlemesini, sorgu parametrelerini ve son durum kodunu test edin.
• Sunucu ayarına erişiminiz yoksa uyumlu yönlendirme eklentisi kullanılabilir. Platforma ait alt alan adı veya CDN adreslerini yeni hosttan yönetemezsiniz; eski sağlayıcının sunduğu imkânları ayrıca kontrol edin.

HTTP durum kodlarının SEO etkisini ve 301–302–404 farklarını net anlamak için HTTP durum kodları ve SEO rehberimize göz atabilirsiniz.

Meta Veriler, Yapısal Veri ve İç Linkler

Hazır site kurucudan geçerken sadece URL’leri değil, SEO meta verilerini de taşımak önemli:

• Başlık, meta description ve ana başlıkları yeni sayfanın gerçek içeriğiyle tutarlı biçimde aktarın; taşıma sırasında gereksiz kapsamlı içerik değişikliklerini ayrı bir aşamada değerlendirin.
• Canonical, hreflang ve site haritasını hedefteki doğru, erişilebilir URL’lere göre güncelleyin.
• Ürün, makale veya SSS yapısal verisini görünen güncel içerikle eşleştirin; eski fiyat/stok veya metinde olmayan yanıt taşımayın. Yapısal veri, zengin sonuç garantisi değildir.
• İç bağlantıları doğrudan son adreslere taşıyın; görseller, PDF’ler ve önemli indirmeler dahil tüm hedefleri kontrol edin.

Alan Adı, DNS ve Kesinti Riskini Azaltma

Alan Adı Nerede Yönetiliyor?

Alan adı kaydı ve DNS yönetimi hazır site kurucu üzerinden veya ayrı sağlayıcılarda olabilir. Önce şunu netleştirin:

• Alan adınız hangi registrar üzerinde kayıtlı?
• DNS kayıtlarını şu anda kim yönetiyor? (hazır kurucu, registrar, ayrı bir DNS hizmeti vb.)

Alan adını tamamen başka bir yere transfer etmek istiyorsanız, süreci adım adım anlattığımız alan adı transferi rehberimize göz atabilirsiniz.

Nameserver’ları mı, Yalnızca Web DNS Kayıtlarını mı Değiştirmeli?

WordPress’e geçerken iki ana senaryo var:

• Mevcut DNS’i koruma: Yetkili DNS sağlayıcısında yalnızca gerekli web A/AAAA ve www kayıtlarını güncelleyin. E-posta başka yerde kalacaksa MX, SPF, DKIM ve DMARC kayıtlarını koruyun. AAAA’yı ancak yeni IPv6 yolu ve HTTPS çalışıyorsa yayımlayın.
• DNS sağlayıcısını değiştirme: Yeni yetkili DNS bölgesini önce hazırlayın; web, e-posta, CAA, SRV ve doğrulama kayıtlarını karşılaştırın. Kullanacağınız gerçek nameserver adlarını sağlayıcıdan alın; web IP’sini nameserver yerine yazmayın.

DNSSEC açıksa sağlayıcıların desteklediği koordineli anahtar geçişini uygulayın. Bu yoksa eski DS kaydını kaldırıp üst bölgede silindiğini ve önceki DS TTL’sinin dolduğunu doğrulayın; bu sırada eski bölge imzalı kalsın. Sonra nameserver değiştirin. Yeni DS’yi yayımlamadan önce eski NS/delegasyon kayıtlarının önceki TTL sürelerinin dolmasını bekleyin; yeni delegasyonu ve yeni sağlayıcıdaki imzalı bölgeyi doğrulayın. Yalnızca yeni yetkili sunucudan doğru yanıt almak, eski delegasyonun önbelleklerden kalktığını göstermez. Bu yol geçici olarak DNSSEC korumasını kaldırır. Sadece A/AAAA değişikliği DNSSEC’i kapatmayı gerektirmez. Alan adı transferi de web taşımak için zorunlu değildir.

Hangi stratejinin daha doğru olduğuna karar verirken, Cloudflare DNS mi, hosting DNS’i mi? En doğru nameserver stratejisi makalemizden faydalanabilirsiniz.

Geçiş Anı: Canlıya Alma ve Test

WordPress’i örneğin staging.example.com gibi ayrı bir test adresinde hazırlayıp erişimi kimlik doğrulamasıyla sınırlayın. Gerçek ödeme, müşteri e-postası ve stok entegrasyonlarının testten tetiklenmesini önleyin. Canlı alan adıyla son kontrol için yeni sunucuda o adın site eşlemesini kurun; yerel hosts eşlemesi veya Host/TLS SNI adını koruyan eşdeğer hedefleme kullanın. Böylece yalnızca test cihazınız yeni sunucuya gider. Ödeme sağlayıcısının geri çağrıları gibi dış istekleri, desteklenen test uç noktalarında ayrıca doğrulayın; yerel hedefleme onları yeni sunucuya göndermez. Geçerli canlı alan adı sertifikası, yukarıdaki desteklenen CA doğrulamasıyla ayrıca hazırlanmış olmalıdır; geçici URL değiştirmek bu önkoşulları karşılamaz.

1. Dosya ve veritabanı yedeğini alın; geçici URL’leri canlı adreslere, serileştirilmiş veriyi koruyan bir araçla önce önizleyip sonra dönüştürün. Canonical, iç bağlantı ve yönlendirmeleri yeni sunucuya hedeflenmiş canlı adla test edin.
2. İçerik değişikliklerini ve sipariş alımını planlanan sürede durdurun. Satış kanalları, ödeme bildirimleri, iadeler ve stok entegrasyonları dahil devam eden yazmaları kontrol altına alın; gelen olayları kaybetmeden kaydedin.
3. Son veri farkını alın. Sipariş/ödeme kimlikleriyle mükerrer işlemleri ayıklayın, açık sipariş ve stokları uzlaştırın. Sipariş aktarımının yeniden ödeme, e-posta veya stok düşümü başlatmadığını doğrulayın.
4. Ödeme, form, yönlendirme, HTTPS, e-posta ve veri kontrolleri başarısızsa DNS’i değiştirmeyin. Başarılıysa yalnızca hazırladığınız web kayıtlarını veya delegasyonu yayımlayın.
5. Canlı ortamdan test erişim engeli ve noindex gibi geçici işaretleri kaldırın; ayrı staging ortamı kapalı kalsın. Ödeme ve diğer üretim entegrasyonlarını doğru ortamda etkinleştirin.
6. Yeni sistemin kontrolleri geçince yazmaları yalnızca seçilen esas sistemde açın. Eski platforma giden kullanıcılar aynı anda bağımsız sipariş verememeli; DNS önbelleği iki sistemi senkronize etmez.
7. Eski hizmeti, geri dönüş hazırlığını ve medya erişimini geçiş tamamlanana kadar koruyun. Alan adı değiştiyse eski alan adında geçerli HTTPS ile yönlendirmeleri sürdürün.

Başarısız Geçişte Geri Dönüş

Geri dönüş kararı veren kişi, önceden belirlenen hata ölçütlerine göre işlemi durdurur. Önce her iki ortamın yazmalarını güvenli biçimde duraklatıp yeni verinin ve bekleyen ödeme/entegrasyon olaylarının kopyasını alın. Yeni sitede işlem oluştuysa eski veritabanını körlemesine geri yüklemeyin veya yalnızca DNS’i ters çevirmeyin. Sipariş, ödeme, iade ve stok farklarını desteklenen aktarım ya da kontrollü kayıtlarla eski esas sistemde uzlaştırın; mümkün değilse bakım sürsün.

Eski sitenin içerik, HTTPS, ödeme ve veri tutarlılığı doğrulandıktan sonra gerekli web DNS kayıtlarını geri alın. DNS sağlayıcısı değişmişse NS/DS geri dönüşü ayrıca güvenli bir plan gerektirir; eski DS’yi gelişigüzel yayımlamayın. Önbellekler nedeniyle iki hedef izlenmeye devam eder. Yazmaları yalnızca doğrulanan esas sistemde yeniden açın; kopya sipariş ve stok düşümü olmadığını izleyin.

Örnek Senaryo: Küçük Bir E-Ticaret Sitesinin Shopify’dan WordPress’e Geçişi

Varsayımsal bir butik giyim mağazası düşünelim: Shopify’dan WooCommerce’e geçerek blog ve mağaza işlevlerini aynı WordPress yapısında yönetmek istiyor. Aşağıdaki plan bir müşteri sonucu veya maliyet tasarrufu vaadi değildir:

• URL, içerik, ürün, müşteri, sipariş ve entegrasyon envanteri çıkarılır; beklenen iş yüküne göre hosting seçilir.
• Ürün ve konum stok dışa aktarımları alınır; küçük örnekle WooCommerce alan, varyant ve medya eşlemesi denenir. Sonra tam aktarım sonuçları karşılaştırılır.
• Sayfa, blog, tasarım ve gerekli mağaza işlevleri yeniden kurulur; değişen URL’lerin 301 eşlemeleri hazırlanır.
• Staging’de dışa giden gerçek işlem ve bildirimler kapalı tutularak ödeme, vergi, kargo, hesap ve e-posta akışları denenir.
• Canlı alan adı yeni sunucuya yerel olarak hedeflenir; sertifika önceden doğrulanıp URL dönüşümü ve yönlendirmeler kontrol edilir.
• Yazmalar duraklatılır, son sipariş/ödeme/stok farkı uzlaştırılır. Kontrollerden sonra DNS geçişi yapılır ve yalnızca yeni esas sistemde sipariş açılır.
• Geri dönüş gerekirse yeni işlemler korunup eski sistemle uzlaştırılmadan yazmalar eski platformda yeniden başlatılmaz.

Bu varsayımsal geçişin hedefi, organik trafik kaybı riskini azaltmak ve performansı iyileştirmektir; bunlar garanti edilen sonuçlar değildir. Geçiş öncesi ve sonrası trafik, dönüşüm ve hız ölçümleri karşılaştırılarak sonuç değerlendirilmelidir.

Taşıma Sonrası Kontrol Listesi

SEO ve İndeksleme Kontrolleri

DNS geçişi ve 301’ler devreye girdikten sonra şu adımları mutlaka uygulayın:

• Google Search Console’da yeni site haritasını (sitemap.xml) gönderin.
• “URL Denetleme” ile kritik sayfaları tek tek test edin.
• 404 hata sayfalarını izleyin; beklenmedik 404’lerde eksik içeriği geri yükleyin veya ilgili yeni karşılığa 301 yönlendirmesi ekleyin. Karşılığı olmayan kaldırılmış içerikleri ilgisiz sayfalara yönlendirmeyin.
• robots.txt dosyanızın canlı ortamda arama motorlarını engellemediğinden emin olun (staging’den kalan Disallow: / gibi hatalardan kaçının). İndekslenmesi gereken canlı sayfalarda test ortamından kalan noindex işaretlerini ve erişim kısıtlarını da kaldırın; ayrı test ortamı kapalı kalsın.

Performans ve Güvenlik

Taşıma sonrası ilk günlerde siteyi yakından izlemek önemli:

• PageSpeed Insights veya WebPageTest ile sayfa deneyimini inceleyin; Core Web Vitals olan LCP, INP ve CLS’yi, yardımcı sunucu yanıt ölçümü TTFB’den ayrı değerlendirin.
• CPU, RAM, disk I/O ve PHP/veritabanı yükünü gerçek trafik altında izleyin; plan değişikliğini bu verilerle değerlendirin.
• WooCommerce sepet, ödeme, hesap ve kişiselleştirilmiş oturumlarını bütün tam sayfa/CDN önbelleklerinden uygun biçimde dışlayıp ayrı oturumlarla kontrol edin.
• Dosya ve veritabanı yedeklerini ayrı yerde saklayın; sıklık ve saklama süresini kaybedilebilecek veri miktarına göre seçin. Geri yüklemeyi izole ortamda deneyin; güncellemeleri staging ve geri dönüş planıyla yürütün.

Eğer çok daha gelişmiş bir yedekleme ve felaket kurtarma senaryosu kurmak istiyorsanız, blogumuzdaki 3-2-1 yedekleme stratejisi ve S3 uyumlu depolama makaleleri de işinize yarayacaktır.

Kullanıcı Deneyimi ve Dönüşüm Optimizasyonu

WordPress’e geçişi sadece teknik bir taşıma olarak görmek yerine, kullanıcı deneyimini iyileştirmek için de fırsat olarak kullanın:

• Eski siteyle karşılaştırmalı ısı haritaları ve kullanıcı oturum kayıtları üzerinden dönüşüm darboğazlarını araştırın; kayıt araçlarında kişisel verileri ve ödeme alanlarını maskeleyin, gerekli kullanıcı izinlerini alın.
• Form adımlarını sadeleştirin, ödeme süreçlerini kısaltın.
• Mobil deneyimi özellikle yakından test edin; menü, arama, filtreler ve buton yerleşimleri mobilde kritik.

Sık Yapılan Hatalar ve Kaçınma Yolları

• 301 haritası olmadan domain ve DNS’i çevirme: URL eşlemesini tamamlamadan DNS değişikliğine geçmek, eski bağlantıların boşa düşmesine neden olabilir. Önce URL eşlemesini ve yönlendirmeleri hazırlayın, sonra DNS’i değiştirin.
• Staging ortamını indekslenebilir bırakma: Geçiş öncesi kurduğunuz test alanı arama motorları tarafından indekslenirse, test URL’leri arama sonuçlarında görünebilir. Staging erişimini kimlik doğrulamayla kısıtlayın. Herkese açık kalması gerekiyorsa noindex kullanın; robots.txt ile taramayı engellemenin tek başına indekslemeyi önlemediğini ve noindex’in görülmesini engelleyebileceğini unutmayın.
• Sadece ana sayfaya yönlendiren 301’ler: Tüm eski URL’leri ana sayfaya yönlendirmek kullanıcıyı alakasız içeriğe götürebilir ve SEO sinyallerinin aktarılmasını sağlamayabilir. Eşdeğer veya gerçekten ilgili içeriklere yönlendirme yapın; uygun karşılığı olmayan kaldırılmış sayfalar için 404 veya 410 yanıtı kullanın.
• Yetersiz sunucu seçimi: Özellikle WooCommerce gibi dinamik sitelerde yetersiz kaynak, geçiş sonrası “site yavaşladı” algısına neden olur. Kapasite planlamasını gerçekçi yapın.
• Yedek almadan işe başlamak: Eski platformun izin verdiği veri dışa aktarımlarını ve içerik kopyalarını saklayın; bunların tam, geri yüklenebilir bir site yedeğiyle aynı olmadığını dikkate alın. Yeni WordPress kurulumunun veritabanı ve dosyalarının tam yedeğini almadan büyük değişiklikler yapmayın.

Sonuç: WordPress’e Geçiş, Bir İyileştirme Fırsatı

Wix, Shopify gibi hazır site kuruculardan WordPress’e geçiş, doğru planlanmadığında riskli görünebilir; ama aslında bu süreç, projenizi bir üst seviyeye taşıma fırsatıdır. Kendi alan adınızı ve WordPress hosting’inizi yönetmek, SEO, performans, güvenlik ve entegrasyonları projenizin ihtiyaçlarına göre düzenlemede daha fazla esneklik sağlar; kontrol düzeyi hosting planınızın sunduğu erişim ve kaynaklarla sınırlıdır.

Bu rehberde; envanter çıkarma, doğru DCHost altyapısını seçme, veri ve içerik taşıma, DNS ve SSL yönetimi, 301 yönlendirmeler ve taşıma sonrası kontroller dahil uçtan uca bir yol haritası sunduk. Her projenin kendine özgü detayları olduğundan, geçiş planını sitenizin veri yapısına, entegrasyonlarına ve kesinti toleransına göre uyarlayın.

DCHost hizmetlerini değerlendirirken mevcut platformunuzu, veri hacmini, entegrasyonları ve gerekli kesinti penceresini paylaşarak hosting ve destek kapsamını netleştirin. Hazırlanan envanter, URL haritası ve geri dönüş planı, sorumlulukları belirlemek ve taşımanın tamamlandığını doğrulamak için kullanılabilir.