WordPress Sitesi Taşıma Rehberi: Hosting Geçişi (2026)

WordPress sitesi taşıma işlemi, ilk kez yapan site sahipleri için en gerilimli teknik görevlerden biridir; yanlış bir adım DNS kesintisine, veri kaybına veya SEO sıralamalarının düşmesine yol açabilir. Bu rehberde WordPress sitesi taşıma sürecini hazırlıktan DNS geçişine, eklenti tabanlı otomatik yöntemlerden manuel cPanel/phpMyAdmin yöntemine kadar adım adım ele alıyoruz. Hedef, kesinti ve veri kaybı riskini azaltmaktır; sıfır kesinti veya sıralama garantisi verilemez.

WordPress Sitesi Taşıma Öncesi Hazırlık

Taşıma işlemine başlamadan önce yapılacak hazırlık, sürecin geri kalanından çok daha önemli. Aceleyle başlanan bir taşıma, genellikle eksik dosya veya bozuk veritabanı tablosuyla sonuçlanıyor. Hazırlık aşamasına ayrılan yarım saatlik bir zaman, taşıma sonrası ortaya çıkabilecek saatlerce süren hata ayıklama sürecinden çok daha değerli.

Taşıma Öncesi Kontrol Listesi

• Mevcut sitenin tam yedeğini alın (dosyalar + veritabanı) ve yedeği indirip başka bir konumda saklayın.
• Yeni hosting hesabınızda PHP sürümünün, bellek limitinin ve eklenti gereksinimlerinin eski hostingle uyumlu olduğunu doğrulayın.
• Aktif eklenti ve tema listesini not alın; taşıma sonrası hangi eklentilerin eksik kaldığını hızla tespit edebilmek için.
• DNS kayıtlarınızın (A/AAAA, CNAME, MX, TXT ve varsa CAA) mevcut değerlerini kaydedin; geçiş sonrası karşılaştırma için gerekecek.
• Ziyaretçi trafiğinin görece düşük olduğu bir saat dilimini taşıma için planlayın.

Yedekleme adımını atlamayın; daha önce ele aldığımız cPanel üzerinden yedekleme ve geri yükleme rehberi, bu aşamada referans olarak kullanılabilir.

Yöntem 1: Eklenti ile Otomatik Taşıma

Teknik bilgisi sınırlı site sahipleri için en pratik yol, özel bir taşıma eklentisi kullanmak. 2026 itibarıyla piyasada öne çıkan seçenekler ve temel farkları şöyle:

Kampanyalı ilk yıl fiyatını yenileme fiyatıyla karıştırmayın. Satın almadan önce araçların güncel ürün belgelerini ve kendi sitenizin boyutunu kontrol edin.

Eklenti ile Taşıma Adımları

1. Kaynak sitenizde seçtiğiniz taşıma eklentisini kurun ve etkinleştirin.
2. Aracın kendi taşıma akışını izleyin; bazıları paket üretir, bazıları hedef sunucuya doğrudan aktarır.
3. Hedef kurulumu aracın belgesine göre hazırlayın; Duplicator installer gibi yöntemler ayrı kurulum akışı kullanır.
4. İçe aktarma (import) sihirbazını çalıştırarak paketi yükleyin; çoğu eklenti bu aşamada eski/yeni alan adı URL değişimini otomatik yapar.
5. İçe aktarma tamamlandıktan sonra siteyi geçici bir test alan adı veya hosts dosyası düzenlemesiyle DNS değişmeden önce test edin.

Hangi Eklentiyi Seçmeli? Kısa Değerlendirme

Migrate Guru, harici sunucular üzerinden işlem yaptığı için kaynak sunucunuzun kaynaklarını yormuyor; bu, paylaşımlı hostingde CPU/bellek limiti aşımı riskini azaltıyor. Ancak ayda yalnızca 5 farklı site taşımasına izin veriyor, bu nedenle sık sık müşteri sitesi taşıyan ajanslar için sınırlayıcı olabilir. Duplicator, iki adımlı (paket oluşturma + kurulum) yaklaşımıyla özellikle manuel kontrolü seven kullanıcılar arasında popüler; Pro sürümdeki sunucudan sunucuya aktarım özelliği, DNS değişmeden önce hedef sunucuda doğrudan içe aktarma yapılmasını sağlıyor.

WPvivid, taşımanın yanı sıra düzenli zamanlanmış yedekleme ve staging ortamı oluşturma gibi ek özellikler sunduğu için “tek eklentiyle çok iş” arayan kullanıcılara uygun. All-in-One WP Migration, arayüz sadeliğiyle öne çıkıyor ancak ücretsiz sürümdeki yükleme boyutu sınırı, büyük medya kütüphanesine sahip siteler için genişletme eklentisi satın almayı gerektirebiliyor. WP Migrate ise geliştirici odaklı bir araç; push-pull senkronizasyonu ve WP-CLI entegrasyonu sayesinde staging-production iş akışlarını otomatikleştirmek isteyen ekipler için en esnek seçenek.

WooCommerce ve Büyük Veritabanlı Siteleri Taşırken Dikkat Edilmesi Gerekenler

WooCommerce çalıştıran bir mağazayı taşırken sipariş, ürün varyasyonu ve müşteri verisi içeren tablolar genellikle standart bir blogdan çok daha büyük oluyor. Bu durumda birkaç ek önlem işe yarıyor:

• Taşıma işlemini düşük sipariş trafiğinin olduğu bir saat diliminde (örneğin gece geç saatler) planlayın.
• Taşıma sırasında verilen yeni siparişlerin kaybolmaması için, mümkünse siteyi kısa süreliğine “bakım modu”na alarak son bir senkronizasyon yapın.
• Ödeme ağ geçidi (payment gateway) API anahtarlarının yeni sunucuda doğru şekilde tanımlandığından emin olun; bu bilgiler bazen wp-config.php dışında ayrı bir yapılandırma dosyasında tutulur.
• Büyük ürün görseli kütüphaneleri için dosya aktarımını sıkıştırılmış arşiv (zip/tar.gz) olarak yapmak, binlerce küçük dosyayı tek tek FTP ile taşımaktan çok daha hızlı ve güvenilir.

Veritabanı boyutu birkaç gigabaytı aştığında phpMyAdmin’in web arayüzü zaman aşımına uğrayabilir. Bu durumda SSH erişimi üzerinden mysqldump kullanmak veya hosting panelinizin sunduğu komut satırı araçlarını tercih etmek daha güvenilir bir yol.

Downtime’ı Minimuma İndirme: Mavi-Yeşil Geçiş Yaklaşımı

DNS değişiminde eski ve yeni sunucuya eşzamanlı trafik gelebilir. TTL’yi önceden düşürmek beklemeyi azaltabilir; yayılımı anında bitirmez. Dinamik sitelerde iki bağımsız veritabanına sipariş veya yorum yazılmasını önleyin: yazmaları geçici durdurma, kontrollü son senkronizasyon veya ortak veri katmanı planlayın. Eski sunucuyu açık tutmak tek başına veri tutarlılığı sağlamaz.

DNS değişikliğinin ne kadar yayıldığını görmek için whatsmydns.net gibi bağımsız DNS kontrol araçlarını kullanabilirsiniz; bu araçlar dünya genelindeki farklı DNS sunucularının hâlâ eski mi yeni mi IP adresini döndürdüğünü gösteriyor.

Farklı Hosting Türleri Arasında Taşıma

Taşıdığınız hosting türü, sürecin karmaşıklığını doğrudan etkiliyor. Paylaşımlı hostingden yönetilen (managed) WordPress hostingine geçişte genellikle sağlayıcı özel bir taşıma aracı sunar ve süreç büyük ölçüde otomatikleşir. Paylaşımlı hostingden VPS veya bulut sunucuya geçişte ise sunucu yapılandırmasını (PHP-FPM, web sunucusu, güvenlik duvarı) sıfırdan kurmanız gerekebilir; bu nedenle bu geçiş türü daha fazla teknik bilgi gerektiriyor. Hangi hosting türünün ihtiyaçlarınıza uygun olduğuna karar vermeden önce hosting türleri karşılaştırma rehberimizi incelemeniz, taşıma sonrası tekrar hosting değiştirme ihtiyacını önleyebilir.

Yöntem 2: Manuel Taşıma (cPanel, phpMyAdmin, wp-config.php)

Eklenti kullanmadan, tam kontrol isteyen kullanıcılar veya büyük siteler için manuel taşıma daha güvenilir olabilir. Bu yöntem üç ana adımdan oluşuyor: veritabanını dışa aktarma, dosyaları taşıma ve bağlantı bilgilerini güncelleme.

Veritabanını Dışa Aktarma

phpMyAdmin üzerinden dışa aktarma yapabileceğiniz gibi, SSH erişiminiz varsa komut satırından da hızlıca alabilirsiniz:

# Veritabanını dışa aktarma (SSH erişimi olan kullanıcılar için)
mysqldump -u kullanici_adi -p veritabani_adi > site_yedek.sql

# Sıkıştırarak aktarma (büyük siteler için önerilir)
mysqldump -u kullanici_adi -p veritabani_adi | gzip > site_yedek.sql.gz

Dosyaları Taşıma ve wp-config.php Güncelleme

Tüm site dosyalarını ve veritabanını taşıyın; wp-content yanında wp-config.php, gizli dosyalar, özel kök dizini dosyaları ve sunucu kurallarını envantere alın. Yeni WordPress çekirdeği kurulacaksa sürüm uyumunu doğrulayın. Aktarımda SFTP veya güvenli panel kullanın. Dosyalar yeni sunucuda yerine oturduktan sonra wp-config.php dosyasındaki veritabanı bağlantı bilgilerini güncelleyin:

define( 'DB_NAME', 'yeni_veritabani_adi' );
define( 'DB_USER', 'yeni_kullanici_adi' );
define( 'DB_PASSWORD', 'yeni_sifre' );
define( 'DB_HOST', 'localhost' ); // hosting sağlayıcınız farklı bir değer isteyebilir

Alan adı değişmiyorsa (yalnızca hosting değişiyorsa) URL değişimi gerekmez. Ancak alan adı da değişiyorsa, veritabanındaki URL referanslarını manuel olarak tek tek değiştirmek yerine WP-CLI ile toplu değiştirme yapmak çok daha güvenli:

# Önce yedek alın ve hedef WordPress dizininde önizleyin
wp search-replace 'https://eski-alan-adi.com' 'https://yeni-alan-adi.com' --all-tables-with-prefix --skip-columns=guid --dry-run

# Önizleme onaylandıktan sonra uygulayın
wp search-replace 'https://eski-alan-adi.com' 'https://yeni-alan-adi.com' --all-tables-with-prefix --skip-columns=guid

Resmi WP-CLI dokümantasyonu, search-replace komutunun tüm parametrelerini ve serileştirilmiş veri (serialized data) ile çalışırken dikkat edilmesi gerekenleri detaylı olarak açıklıyor; serileştirilmiş alanları manuel metin editörüyle değiştirmek veritabanını bozabileceğinden bu komutun kullanılması önemle tavsiye ediliyor.

Dosya İzinleri ve .htaccess Kontrolü

Manuel taşımada sıkça atlanan bir adım, dosya ve dizin izinlerinin yeni sunucuda doğru ayarlanması. Yanlış izinler hem güvenlik açığı hem de “500 Internal Server Error” gibi hatalara yol açabiliyor. Genel kabul gören standart değerler şöyle:

# Dizinler için önerilen izin
find /home/kullanici/public_html -type d -exec chmod 755 {} \;

# Dosyalar için önerilen izin
find /home/kullanici/public_html -type f -exec chmod 644 {} \;

# wp-config.php için daha kısıtlayıcı izin (önerilir)
chmod 600 /home/kullanici/public_html/wp-config.php

.htaccess dosyasını da taşımayı unutmayın; bu dosya genellikle özel URL yapılandırmaları, yönlendirmeler ve bazı güvenlik kuralları içerir. Dosya gizli (hidden) olduğu için FTP istemcinizde “gizli dosyaları göster” seçeneğini açmanız gerekebilir. Eğer dosya eksik taşınırsa, siteniz açılsa bile yazı sayfalarında “404 Not Found” hatası almanız olası; bu durumda WordPress panelinden Ayarlar > Bağlantı Yapısı sayfasını açıp “Kaydet” butonuna basarak .htaccess dosyasını yeniden oluşturabilirsiniz.

WordPress Multisite Taşırken Ekstra Adımlar

Bir multisite ağını taşımak, tekil bir WordPress kurulumuna göre birkaç ekstra dikkat gerektiriyor. Alt alan adı (subdomain) tabanlı bir ağ kullanıyorsanız her bir alt site için DNS kaydının (genellikle wildcard A kaydı şeklinde, örn. *.siteniz.com) yeni sunucuya doğru yönlendirildiğinden emin olmanız gerekiyor. Alt dizin (subdirectory) tabanlı ağlarda ise bu ek DNS adımı gerekmez, ancak veritabanındaki her bir alt site için ayrı tablo setlerinin (wp_2_posts, wp_3_posts gibi) eksiksiz taşındığını kontrol etmek kritik. WP-CLI’nin wp search-replace komutu multisite kurulumlarında --network parametresiyle tüm ağ genelinde çalıştırılabiliyor, bu da tek tek her alt siteyi elle güncelleme zahmetini ortadan kaldırıyor.

DNS ve SSL Geçişi Nasıl Yapılır?

DNS Kayıtlarını Güncelleme

Yeni hosting hesabınızın verdiği A kaydı (IP adresi) veya name server bilgilerini alan adı sağlayıcınızın panelinden güncelleyin. DNS değişikliklerinin küresel olarak yayılması (propagation) birkaç dakikadan 48 saate kadar sürebilir; bu süre boyunca bazı ziyaretçiler eski sunucuyu, bazıları yeni sunucuyu görebilir. Bu geçiş penceresinde veri yazımlarını tek kaynakta toplamak ve son senkronizasyonu planlamak gerekir.

SSL Sertifikası Kurulumu

Yeni hostingde siteyi yayına almadan önce SSL sertifikasının aktif olduğundan emin olun; aksi halde ziyaretçiler güvenlik uyarısıyla karşılaşabilir. Çoğu güncel hosting sağlayıcısı Let’s Encrypt ile ücretsiz otomatik SSL kurulumu sunuyor. SSL kurulumu sonrası bağlantı hatası alırsanız SSL Handshake Failed hatası ve çözüm yollarına dair rehberimize göz atabilirsiniz.

Taşıma Sonrası Test ve Doğrulama

1. Ana sayfa, kategori sayfaları ve en az birkaç yazı/ürün sayfasının doğru yüklendiğini kontrol edin.
2. İletişim formu, arama kutusu ve giriş sayfası gibi etkileşimli öğeleri test edin.
3. Google Search Console’da site haritanızı yeniden gönderin ve dizine ekleme durumunu izleyin.
4. 301 yönlendirmelerinin (varsa URL yapısı değiştiyse) doğru çalıştığını kontrol edin.
5. Sayfa yükleme hızını yeni sunucuda ölçün; Core Web Vitals metriklerinin taşıma öncesine kıyasla kötüleşmediğinden emin olun.
6. E-posta gönderim ayarlarını (SMTP) yeniden yapılandırın; hosting değişimi genellikle e-posta teslim sorunlarına yol açar.

Sık Yapılan Hatalar

• DNS TTL değerini taşımadan önce düşürmemek: Taşımadan birkaç gün önce DNS TTL (time to live) süresini kısaltmak, geçiş sırasındaki propagation süresini kısaltır.
• Eski hosting hesabını hemen kapatmak: DNS propagation tamamlanana kadar eski hesabı en az birkaç gün aktif tutmak, kesinti riskini azaltır.
• wp-content/uploads dizinini eksik taşımak: Büyük medya kütüphaneleri FTP aktarımında zaman aşımına uğrayabilir; sıkıştırılmış arşiv olarak taşımak daha güvenilir.
• robots.txt veya noindex ayarlarını kontrol etmemek: Test ortamındaki “arama motorlarından gizle” ayarının yanlışlıkla canlı sitede de aktif kalması, ciddi bir SEO kaybına yol açabilir.
• Dosya izinlerini (permissions) kontrol etmemek: Yanlış dosya izinleri, taşıma sonrası beyaz sayfa hatası veya eklenti çalışmama sorunlarına neden olabilir.
• Cron görevlerini (WP-Cron) yeniden yapılandırmamak: Zamanlanmış yedekleme veya bülten gönderimi gibi görevler, eski sunucudaki sistem cron ayarına bağlıysa yeni sunucuda yeniden tanımlanması gerekir.
• Taşıma sonrası şifreleri değiştirmemek: Eski hosting hesabına erişimi olan üçüncü taraflar varsa, taşıma sonrası veritabanı ve yönetici parolalarını yenilemek iyi bir güvenlik alışkanlığıdır; bu konuda güvenlik sertleştirme kontrol listemiz yol gösterici olabilir.

Taşıma Sırasında SEO Kaybını Önleme

Hosting değişimi tek başına arama motoru sıralamalarını etkilememeli; sorunlar genellikle taşıma sırasında yapılan hatalardan kaynaklanıyor. Alan adı değişmiyorsa ve site aynı URL yapısında kalıyorsa risk düşük. Ancak URL yapısı değişiyorsa (örneğin http’ten https’e geçiş, www’li/www’siz değişim veya kategori yapısının farklılaşması), eski URL’lerden yeni URL’lere 301 yönlendirmesi kurulması şart; aksi halde arama motorları eski sayfaları “bulunamadı” olarak işaretleyip indeksten düşürebilir.

Taşıma tamamlandıktan sonra Google Search Console’da Sayfa dizine ekleme raporunu birkaç hafta boyunca takip etmek, olası tarama hatalarını erken fark etmenizi sağlıyor. Sayfa hızında gözle görülür bir yavaşlama fark ederseniz, bunun taşıma değil önbellekleme veya sunucu yapılandırma farkından kaynaklanıp kaynaklanmadığını ayırt etmek için taşıma öncesi ve sonrası PageSpeed ölçümlerini karşılaştırmanız faydalı olur.

Hangi Yöntem Kime Uygun?

Küçük ve orta ölçekli bloglar için Migrate Guru veya All-in-One WP Migration gibi eklenti tabanlı çözümler, teknik bilgi gerektirmeden hızlı sonuç veriyor. Ajans veya çok sayıda müşteri sitesi yöneten ekipler için WP Migrate’in push-pull ve WP-CLI entegrasyonu, tekrarlanabilir ve otomatikleştirilebilir bir iş akışı sunduğu için daha uygun. Büyük, yüksek trafikli veya özel sunucu yapılandırmasına sahip siteler içinse manuel cPanel/phpMyAdmin yöntemi, sürecin her adımını kontrol etme imkanı sağladığından tercih edilebilir; ancak bu yöntem SQL ve sunucu yönetimi konusunda temel bilgi gerektiriyor.

Sonuç

Bu rehberde WordPress sitesi taşıma sürecini hazırlıktan doğrulamaya kadar uçtan uca ele aldık. Süreç, doğru hazırlık ve doğru araç seçimiyle çoğu site sahibi için birkaç saat içinde tamamlanabilecek bir işlem. Kritik nokta, taşımadan önce eksiksiz bir yedek almak, DNS ve SSL geçişini planlı yürütmek ve taşıma sonrası doğrulama adımlarını atlamamak. Bu adımlara sadık kalındığında hem veri kaybı hem de SEO sıralaması kaybı riski büyük ölçüde azalıyor. Emin olmadığınız bir adımda acele etmek yerine, gerekirse taşımayı bir sonraki güne erteleyip yeniden test etmek, uzun vadede çok daha az baş ağrısına yol açar.

Sık Sorulan Sorular

WordPress sitesi taşıma işlemi ne kadar sürer?

Site boyutuna ve yönteme göre değişir; küçük bir blog eklenti ile 30-60 dakikada taşınabilirken, DNS propagation süreci ayrıca birkaç saatten 48 saate kadar sürebilir. Büyük veritabanlı e-ticaret siteleri için dosya aktarımı ve doğrulama adımları toplamda yarım günü bulabilir.

Taşıma sırasında sitem geçici olarak kapanır mı?

Kesinti ihtimali sıfır değildir. Statik içerik DNS geçişinde erişilebilir kalabilir; mağaza ve üyelik sitelerinde veri tutarlılığı için kısa yazma duraklaması gerekebilir. Geçiş ve geri dönüş planını önceden hazırlayın.

Ücretsiz bir taşıma eklentisi yeterli mi, yoksa ücretli sürüm mü almalıyım?

Küçük siteler için ücretsiz sürümler genellikle yeterli. Büyük medya kütüphanesine sahip siteler, multisite kurulumlar veya sunucudan sunucuya doğrudan aktarım isteyen kullanıcılar için ücretli sürümler zaman kazandırabilir.

Alan adımı da değiştiriyorsam nelere dikkat etmeliyim?

Veritabanındaki tüm URL referanslarını WP-CLI search-replace komutuyla güncellemeniz, eski alan adından yeni alan adına 301 yönlendirme kurmanız ve Google Search Console’da adres değişikliğini bildirmeniz gerekir.

Taşıma sonrası site yavaşlarsa ne yapmalıyım?

Öncelikle yeni hostingin PHP sürümünü ve kaynak limitlerini kontrol edin, ardından önbellekleme ve CDN ayarlarınızın yeni sunucuda doğru yapılandırıldığından emin olun. Sorun devam ederse hosting sağlayıcınızın destek ekibinden sunucu seviyesinde bir kaynak kısıtlaması olup olmadığını teyit etmesini isteyebilirsiniz.

Dosya izinleri notu: 755/644 ve wp-config.php için 600 her hosting mimarisinde uygun değildir. Dosya sahibini ve PHP’nin çalışma kullanıcısını doğrulayın; paylaşılan dizinlerde toplu chmod uygulamayın. .htaccess Apache/LiteSpeed ortamıyla ilgilidir; Nginx kuralları ayrıca taşınmalıdır.

Resmi kaynaklar: WordPress taşıma belgesi ve WP-CLI search-replace kapsamı.