Hosting

WordPress Site Taşıma Rehberi: Yeni Hostinge Adım Adım Geçiş

30 Nisan 2026 No comments yet
WordPress site taşıma rehberi: eski hostingten yeni hostinge migration süreci görsel anlatım

Kısa özet: WordPress site taşıma; mevcut hosting üzerinde çalışan bir siteyi tüm dosyaları, veritabanı içeriği, medya kütüphanesi, eklenti ayarları ve kullanıcı verileriyle birlikte yeni bir sunucuya, yeni bir hosting paketine veya yeni bir alan adına eksiksiz biçimde aktarma sürecidir. Bu rehberde manuel (FTP + phpMyAdmin), WP-CLI tabanlı ve eklenti tabanlı (All-in-One WP Migration, Duplicator, UpdraftPlus) yöntemleri adım adım göreceksiniz; ayrıca wp-config.php, .htaccess, DNS, SSL ve URL güncelleme aşamalarında sık karşılaşılan hataların çözümlerini bulacaksınız.

WordPress Site Taşıma Neden Önemlidir?

Bir WordPress sitesinin ömrü boyunca taşıma, kaçınılmaz bir bakım operasyonudur. Site büyüdükçe paylaşımlı hosting yeterli gelmemeye başlar ve VPS, bulut sunucu ya da yönetilen WordPress hosting çözümlerine geçiş kaçınılmaz hâle gelir. Bunun dışında alan adı değişikliği, yeni bir hosting şirketine geçiş, fiyat/performans optimizasyonu, sunucu lokasyonunu hedef kitleye yaklaştırma, PHP sürüm uyumluluğu, daha güçlü güvenlik önlemleri veya tamamen yeni bir altyapıya (Nginx, LiteSpeed, OpenLiteSpeed) geçiş gibi nedenler de site taşımayı gündeme getirir.

Doğru planlanmış bir taşıma; kesinti süresini sıfıra yakın tutar, SEO sıralamalarını korur, müşteri verilerini ve sipariş geçmişini kaybetmeden yeni sunucuya ulaştırır. Yanlış planlanmış bir taşıma ise; kırık linkler, eksik medya dosyaları, çalışmayan formlar, kaybolan WooCommerce siparişleri, indekslenmiş URL’lerin 404 hatasına dönmesi ve uzun süreli kesintilerle sonuçlanır. Bu yüzden taşımayı bir “dosya kopyalama” işi olarak değil; yedekleme, doğrulama, eşleştirme ve canlıya alma adımlarından oluşan bir proje olarak ele almak gerekir.

Taşıma Öncesi Hazırlık

İyi bir taşıma, dosya indirmeden önce başlar. Aşağıdaki hazırlık adımları olmadan başlayan taşımalar; eksik veri, uyumsuz PHP sürümü ya da “database connection error” gibi sorunlarla karşılaşmaya açıktır.

1. Hedef Hosting Ortamını Doğrulayın

Yeni hosting paketinin WordPress için gerekli minimum gereksinimleri karşıladığından emin olun. Bunun için kontrol etmeniz gerekenler şunlardır: PHP 8.1 veya daha yeni bir sürüm, MySQL 5.7+ ya da MariaDB 10.4+, en az 256 MB PHP bellek limiti, en az 512 MB toplam disk, mod_rewrite veya Nginx try_files desteği, SSL sertifikası kurulum imkânı, SSH ya da WP-CLI desteği (özellikle büyük sitelerde tercih edilir).

Eski hostingdeki PHP sürümünü php -v ile, WordPress’in kullandığı versiyonu ise WordPress yöneticisinden Araçlar → Site Sağlığı → Bilgi ekranından kontrol edebilirsiniz. Yeni sunucudaki PHP sürümü kesinlikle eskisinden düşük olmamalıdır; aksi takdirde bazı eklentiler “Fatal error: Uncaught Error” mesajıyla çöker.

2. Tam Yedek Alın

Taşımadan hemen önce mutlaka tam bir yedek (dosya + veritabanı) alın. Yedek almadan başlatılan hiçbir taşıma “güvenli” değildir. SSH erişiminiz varsa şu komutla tüm WordPress dizinini sıkıştırabilirsiniz:

cd ~/public_html
tar -czf wpneta-full-backup-$(date +%F).tar.gz     --exclude='wp-content/cache'     --exclude='wp-content/uploads/wp-staging'     .

Veritabanı dökümünü ise mysqldump ile alın:

mysqldump -u DB_KULLANICI -p   --single-transaction   --quick   --default-character-set=utf8mb4   DB_ADI > wpneta-db-$(date +%F).sql

--single-transaction bayrağı, InnoDB tablolarında dökümün tutarlı bir snapshot üzerinden alınmasını sağlar; --default-character-set=utf8mb4 ise Türkçe karakterlerin (ç, ş, ğ, ü, ö, İ) ve emoji içeriklerin bozulmadan aktarılması için gereklidir. Dökümün başına bakın; SET NAMES utf8mb4; satırını görmüyorsanız komutu yeniden çalıştırın.

3. Bakım Modu Açın ve Yazma İşlemlerini Dondurun

Taşıma sırasında siteye yeni yorum, sipariş veya kullanıcı kaydı düşmesini istemezsiniz; aksi halde yeni sunucu canlıya alındığında bu kayıtlar kaybolur. Bunu önlemenin en temiz yolu, kaynak siteye bir bakım modu kurmaktır. WP-CLI varsa tek satırda halledebilirsiniz:

wp maintenance-mode activate

WP-CLI yoksa eklentisiz çözüm için kök dizine boş bir .maintenance dosyası bırakabilir veya “WP Maintenance Mode”, “LightStart” gibi eklentileri kullanabilirsiniz. WooCommerce siteleri taşıyorsanız ek olarak WooCommerce → Ayarlar → Genel menüsünden mağazayı geçici olarak kapatmanız önerilir.

Manuel WordPress Site Taşıma (Klasik Yöntem)

Manuel yöntem; eklentiye bağımlı olmadan, hosting paneli, FTP ve phpMyAdmin (veya komut satırı) kullanarak yapılan en güvenilir yoldur. Tam kontrol sağlar ve büyük sitelerde eklenti tabanlı yöntemlere göre çok daha az hata üretir. Adımlar şu sırayla uygulanır.

1. Tüm Dosyaları İndirin

FTP istemcinizde (FileZilla, Cyberduck, WinSCP) eski sunucuya bağlanın ve public_html içindeki tüm WordPress dosyalarını yerel makineye indirin. Çok büyük sitelerde FTP yavaş kalacağından SSH erişimi varsa tar.gz arşivi alıp scp ile çekmek katlarca daha hızlıdır:

# Eski sunucuda
tar -czf /tmp/wpneta-files.tar.gz -C /home/USER/public_html .

# Yerel makinede
scp USER@eski-sunucu:/tmp/wpneta-files.tar.gz ./

Dikkat edilmesi gereken klasörler: wp-content/uploads (medya), wp-content/themes (özel temalar), wp-content/plugins (eklentiler), wp-content/mu-plugins (must-use eklentiler), wp-config.php ve gerekirse özelleştirilmiş .htaccess. Cache klasörleri (wp-content/cache, wp-content/wp-rocket-config) yeni sunucuda yeniden üretileceği için indirilmelerine gerek yoktur.

2. Veritabanını Dışa Aktarın

phpMyAdmin üzerinden veritabanını seçin, Dışa Aktar → Özel seçeneğini işaretleyin, çıktı biçimini SQL olarak bırakın ve “Add CREATE DATABASE statement” seçeneğini KAPATIN. Karakter setini utf8mb4 olarak seçtikten sonra dosyayı indirin. Daha hızlı ve güvenilir bir yol arıyorsanız komut satırından:

mysqldump -u kullanici -p   --single-transaction   --routines   --triggers   --default-character-set=utf8mb4   veritabani_adi | gzip > wpneta-db.sql.gz

--routines ve --triggers bayrakları, gelişmiş eklentilerin (örn. WooCommerce raporlama) kullandığı stored procedure ve trigger’ların da yedeklenmesini sağlar.

3. Yeni Hostinge Veritabanı Oluşturun

Yeni hosting panelinden (cPanel, Plesk, DirectAdmin, CyberPanel) yeni bir MySQL veritabanı, ayrı bir veritabanı kullanıcısı ve güçlü bir parola oluşturun. Kullanıcının veritabanı üzerinde ALL PRIVILEGES yetkisi olduğundan emin olun. Komut satırı tercih ediyorsanız:

CREATE DATABASE wpneta_new
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_520_ci;

CREATE USER 'wpneta_user'@'localhost'
  IDENTIFIED BY 'GUCLU_PAROLA_BURAYA';

GRANT ALL PRIVILEGES ON wpneta_new.*
  TO 'wpneta_user'@'localhost';

FLUSH PRIVILEGES;

4. Veritabanını İçe Aktarın

Veritabanı dökümünü yeni sunucuya yükleyin ve içe aktarın:

gunzip < wpneta-db.sql.gz | mysql -u wpneta_user -p wpneta_new

phpMyAdmin’in “Import” ekranındaki 50 MB sınırından dolayı büyük dökümler hata verirse, dosyayı önce sunucuya FTP ile yükleyip oradan içe aktarmak daha sağlıklıdır. Alternatif olarak BigDump betiğini kök dizine bırakıp parçalı içe aktarma yapabilirsiniz.

5. Dosyaları Yeni Sunucuya Yükleyin

FTP veya scp ile dosyaları yeni sunucudaki public_html dizinine taşıyın. SSH varsa arşivi sunucuda açmak çok daha hızlıdır:

cd ~/public_html
tar -xzf ~/wpneta-files.tar.gz
chown -R USER:USER .
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.php

Dosya izinleri yanlış ayarlanırsa “403 Forbidden”, “500 Internal Server Error” veya yöneticide “unable to write” mesajları alırsınız. WordPress için klasörler 755, dosyalar 644 ve wp-config.php en sıkı haliyle 600 olmalıdır.

6. wp-config.php Dosyasını Güncelleyin

Yeni sunucudaki wp-config.php içindeki veritabanı bilgilerini güncelleyin. Aynı zamanda hata kayıtlarını canlıda kapalı, log dosyasını ise dolu tutmak için aşağıdaki sabitleri ekleyin:

// Veritabanı ayarları
define( 'DB_NAME',     'wpneta_new' );
define( 'DB_USER',     'wpneta_user' );
define( 'DB_PASSWORD', 'GUCLU_PAROLA_BURAYA' );
define( 'DB_HOST',     'localhost' );
define( 'DB_CHARSET',  'utf8mb4' );
define( 'DB_COLLATE',  '' );

// Hata ayıklama (taşıma sonrası kapatın)
define( 'WP_DEBUG',         true );
define( 'WP_DEBUG_LOG',     true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Bellek limiti
define( 'WP_MEMORY_LIMIT',       '256M' );
define( 'WP_MAX_MEMORY_LIMIT',   '512M' );

// Doğrudan dosya güncellemeleri
define( 'FS_METHOD', 'direct' );

Eski wp-config.php‘deki AUTH_KEY, SECURE_AUTH_KEY gibi tuzları (salt) aynen taşıyın. Aksi halde tüm kullanıcıların oturumu kapanır ve giriş ekranına geri dönülür; bu, taşıma sonrası en sık karşılaşılan “neden çıkış oldum” şikâyetinin nedenidir.

WP-CLI ile Profesyonel Site Taşıma

WP-CLI; özellikle 1 GB üzeri medya kütüphanelerinde, 50.000+ yazılı içerikte veya WooCommerce mağazalarında manuel yöntemden çok daha hızlı ve hatasız sonuç verir. SSH erişimi olan her hostingde çalışır.

Eski Sunucuda Tam Paket Hazırlama

# 1) Eklentileri devre dışı bırak (cache temizliği için)
wp plugin deactivate --all

# 2) Veritabanı yedeği
wp db export wpneta-db.sql --add-drop-table

# 3) Tüm WP klasörünü sıkıştır
tar -czf wpneta-full.tar.gz     --exclude='wp-content/cache'     --exclude='wp-content/upgrade'     .

# 4) Eklentileri tekrar etkinleştir
wp plugin activate --all

Yeni Sunucuda Geri Yükleme

# Dosyaları aç
tar -xzf wpneta-full.tar.gz -C ~/public_html

# Veritabanını sil ve yeniden oluştur (yeni boş bir DB üzerinde)
wp db reset --yes

# Yedeği geri yükle
wp db import wpneta-db.sql

# URL ve domain değiştiyse search-replace ile güncelle
wp search-replace 'https://eski-domain.com' 'https://yeni-domain.com'   --all-tables   --skip-columns=guid   --report-changed-only

# Önbelleği ve nesne cache'i temizle
wp cache flush
wp transient delete --all
wp rewrite flush --hard

--skip-columns=guid kritik bir ayardır: WordPress, GUID alanını içerik tanımlayıcısı olarak kullanır ve değiştirilmesi RSS abonelerine yazıların yeniden yayınlandığı sinyalini verir. --all-tables; ACF, WooCommerce, Yoast SEO gibi özel tabloların da serileştirilmiş alanlar dahil güncellenmesini sağlar.

Eklenti Tabanlı Site Taşıma Yöntemleri

SSH erişiminiz yoksa veya teknik bilgi seviyeniz orta seviyeyse eklenti tabanlı taşıma çözümleri çok kolay bir alternatif sunar. En çok kullanılan üç eklentiyi ve sınırlarını bilmek önemlidir.

All-in-One WP Migration

En basit kurulumlu eklentidir. Eski sitede kurulup “Export” bölümünden tek bir .wpress dosyası üretir. Bu dosya yeni siteye temiz bir WordPress kurulumunun ardından “Import” menüsünden yüklenir. Ücretsiz sürümde varsayılan yükleme sınırı 512 MB‘dir; bu sınırı aşmak için “Unlimited Extension” premium uzantısı gerekir veya php.ini üzerinde upload_max_filesize, post_max_size ve memory_limit değerlerini elle artırmanız beklenir.

Duplicator

Duplicator iki dosya üretir: arşiv (archive.zip) ve yükleyici (installer.php). Bu iki dosyayı yeni hostingteki boş bir dizine yükledikten sonra https://yeni-domain.com/installer.php adresine giderek sihirbazı çalıştırırsınız. WP-CLI yetenekleri olmayan paylaşımlı hostinglerde, manuel taşımanın mantığını otomatikleştirdiği için en güvenilir alternatiflerden biridir.

UpdraftPlus Migrator

UpdraftPlus zaten yedekleme alanında en yaygın eklentidir; “Migrator” premium eklentisi, hâlihazırda alınmış bir UpdraftPlus yedeğini farklı bir domain’e ya da sunucuya doğrudan geri yükler ve URL güncellemelerini otomatik yapar. Düzenli yedek alıp yedekten taşıma yapmak isteyenler için pratiktir.

Domain ve URL Güncellemeleri

Aynı domainle taşıyorsanız bu adım gerekmez; ancak alan adı değişikliği yapıyorsanız (örneğin eskiDomain.com‘dan yeniDomain.com‘a) veya HTTP’den HTTPS’ye geçiyorsanız veritabanındaki tüm URL referanslarını güncellemeniz gerekir.

siteurl ve home Değerleri

UPDATE wp_options
   SET option_value = 'https://yeniDomain.com'
 WHERE option_name IN ('siteurl', 'home');

WP-CLI tercihinde:

wp option update siteurl 'https://yeniDomain.com'
wp option update home    'https://yeniDomain.com'

Serileştirilmiş Veriler İçin search-replace

Tema seçenekleri, widget içerikleri ve eklenti ayarları çoğunlukla PHP serialize() formatında saklanır. Düz UPDATE … REPLACE() kullanırsanız bu veriler bozulur ve “unserialize() error” mesajları alırsınız. Doğru yol WP-CLI’in search-replace komutudur:

wp search-replace 'http://eskiDomain.com' 'https://yeniDomain.com'   --all-tables   --skip-columns=guid   --precise   --recurse-objects   --report-changed-only

--precise ve --recurse-objects bayrakları; iç içe nesneler ve serileştirilmiş diziler içeren ACF alanları, Elementor sayfa verileri ve WooCommerce ürün metalarının doğru biçimde güncellenmesini sağlar. WP-CLI yoksa “Better Search Replace” eklentisi aynı işi grafik arayüzde yapar.

.htaccess ve Yönlendirmeler

Apache kullanan sunucularda WordPress, .htaccess üzerinden permalink kuralları yazar. Domain değişiyorsa eski siteden yeniye 301 yönlendirme şarttır; aksi takdirde Google’da indekslenmiş sayfalar kaybolur. Eski sunucuda kalan .htaccess dosyasına şu blok eklenir:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} ^(www.)?eskiDomain.com$ [NC]
  RewriteRule ^(.*)$ https://yeniDomain.com/$1 [R=301,L]
</IfModule>

Yeni sunucuda ise WordPress varsayılan permalink kurallarını Ayarlar → Kalıcı Bağlantılar → Değişiklikleri Kaydet diyerek yeniden ürettirin; alternatif olarak wp rewrite flush --hard komutu aynı işi yapar.

DNS ve SSL Geçişi

Yeni sunucu hazır ve site çalışır durumda görünüyor. Şimdi domain’i yeni sunucuya yönlendirmenin tam zamanı. Bu adım için iki yöntem vardır.

1. hosts Dosyasıyla Önizleme

DNS kayıtlarını değiştirmeden önce yerel makinenizde hosts dosyasına yeni sunucu IP’si ile birlikte domain’i ekleyerek siteyi sadece kendi tarayıcınızda yeni sunucudan açabilirsiniz. macOS / Linux’ta /etc/hosts, Windows’ta C:\Windows\System32\drivers\etc\hosts dosyasına şu satırı ekleyin:

123.123.123.123  yeniDomain.com www.yeniDomain.com

Böylece DNS yayılmasını beklemeden tüm sayfaları, formları, ödeme akışını ve admin paneli yeni sunucuda test edebilirsiniz. Test bittiğinde satırı kaldırmayı unutmayın.

2. DNS A Kaydını Değiştirin

Domain sağlayıcınızın panelinden A kaydını yeni sunucu IP’sine yönlendirin ve mümkünse TTL değerini birkaç saat öncesinden 300 saniye gibi düşük bir değere indirin. Bu, yayılma süresinin kısalmasını sağlar. AAAA, MX, TXT, SPF, DKIM gibi diğer kayıtları kontrol edin; özellikle e-posta servisi başka yerden veriliyorsa MX kayıtlarını kesinlikle değiştirmeyin.

3. SSL Sertifikası Kurulumu

Yeni sunucuda Let’s Encrypt veya hosting sağlayıcısının ücretsiz SSL servisini etkinleştirin. cPanel’de “SSL/TLS Status → Run AutoSSL”, Plesk’te “Let’s Encrypt”, CyberPanel’de “SSL → Issue SSL” bölümünü kullanın. SSL kurulumundan sonra HTTP isteklerinin HTTPS’e zorlanması için .htaccess‘e ekleyin:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

“Mixed Content” uyarısı alırsanız siteyi https://www.whynopadlock.com üzerinden tarayın ve hâlâ http:// ile çağrılan görsel/script bağlantılarını yukarıdaki search-replace komutuyla düzeltin.

Taşıma Sonrası Test Listesi (Kontrol Listesi)

Site canlıya alındıktan sonra aşağıdaki kontrol listesini sırayla uygulayın. Her madde bir gün sonra sürpriz hatalarla karşılaşmamak için kritiktir.

  • Anasayfa, kategori ve etiket sayfaları açılıyor mu?
  • Tek tek 5-10 yazıyı açın, görseller yükleniyor mu, iç bağlantılar çalışıyor mu?
  • Ayarlar → Kalıcı Bağlantılar‘a girip “Değişiklikleri Kaydet” deyin (rewrite kurallarını yenilemek için).
  • İletişim formu, abonelik formu ve giriş/kayıt akışını test edin.
  • WooCommerce sitesinde test sipariş atıp ödeme akışını sonuna kadar takip edin.
  • Yorum, arama ve dahili site arama sonuçlarını kontrol edin.
  • Araçlar → Site Sağlığı ekranında kritik uyarı olmadığını doğrulayın.
  • Google Search Console’da sitemap’i yeniden gönderin, URL Denetimi ile yeni sunucuyu test edin.
  • Cache eklentisini (WP Rocket, LiteSpeed Cache, W3 Total Cache) yeniden yapılandırın.
  • CDN kullanıyorsanız (Cloudflare, BunnyCDN) cache’i tamamen purgelayın.
  • SMTP eklentisini açıp test e-posta gönderin; e-posta üretimi yeni sunucuda çalışmalı.
  • SSL sertifikasının A veya A+ aldığını ssllabs.com/ssltest üzerinden doğrulayın.
  • WP Debug log’unu (wp-content/debug.log) açıp 24 saat boyunca takip edin.

Sık Karşılaşılan Sorunlar ve Çözümleri

Beyaz Ekran (WSOD)

Taşıma sonrası en sık görülen sorunlardan biridir. Genellikle PHP sürüm farkı, eksik PHP eklentisi (örn. php-mbstring, php-curl) veya bellek limiti yetersizliğinden kaynaklanır. wp-config.php üzerinde WP_DEBUG_LOG sabitini açıp wp-content/debug.log dosyasını okuyun. Bellek için:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Database Connection Error

“Error establishing a database connection” mesajı görüyorsanız wp-config.php‘deki DB_HOST, DB_USER, DB_PASSWORD ve DB_NAME değerlerini kontrol edin. Bazı hostinglerde DB_HOST localhost değil 127.0.0.1, mysql.server veya özel bir IP olabilir.

500 Internal Server Error

Yanlış izinler, hatalı .htaccess kuralları veya uyumsuz php.ini direktifleri 500 hatası üretir. .htaccess‘i geçici olarak yeniden adlandırın, sonra Ayarlar → Kalıcı Bağlantılar‘ı kaydederek WordPress’e yenisini ürettirin. Hâlâ çözülmüyorsa hosting sağlayıcısının PHP error log’unu inceleyin.

Permalink 404 Hataları

Anasayfa açılıyor ama yazılar 404 veriyorsa kalıcı bağlantı kuralları yenilenmemiş demektir. Ayarlar → Kalıcı Bağlantılar‘a girip “Değişiklikleri Kaydet” deyin veya WP-CLI ile:

wp rewrite flush --hard
wp option get permalink_structure

Mixed Content Uyarısı

HTTP’den HTTPS’ye geçişte tarayıcı bazı kaynakların hâlâ http:// ile yüklendiğini söylüyorsa, içerikteki sabit kodlanmış URL’leri wp search-replace ile güncelleyin ve tema dosyalarındaki http:// referanslarını https://‘a taşıyın. Hızlı çözüm için “Really Simple SSL” eklentisi de kullanılabilir, ancak uzun vadede içerikteki URL’leri kalıcı olarak güncellemek önerilir.

Eksik Görseller / Bozuk Medya Bağlantıları

Yeni sunucudaki wp-content/uploads klasörü tam taşınmadıysa görseller kırık çıkar. SSH üzerinden klasör boyutlarını karşılaştırın:

du -sh wp-content/uploads

Eski ve yeni sunucudaki çıktı yakın olmalı. Fark varsa eksik dosyaları rsync ile senkronize edin:

rsync -avz --progress   USER@eski-sunucu:public_html/wp-content/uploads/   ~/public_html/wp-content/uploads/

Performans ve Güvenlik İçin Taşıma Sonrası İyileştirmeler

Yeni sunucu temiz bir sayfa açar; bu, performans ve güvenlik kazanımları için harika bir fırsattır. Aşağıdaki adımları taşıma sonrası 24-48 saat içinde uygulayın.

  • OPcache’i etkinleştirin: opcache.enable=1, opcache.memory_consumption=256.
  • Yeni Object Cache eklentisi (Redis, Memcached) kurun; özellikle WooCommerce için ciddi hız farkı yaratır.
  • HTTP/2 ve gerekiyorsa HTTP/3’ü açın.
  • Brotli sıkıştırmayı etkinleştirin (LiteSpeed varsayılan, Nginx’te modül gerektirir).
  • Otomatik yedeklerin yeni sunucuda aktif olduğundan emin olun. Yedekleme rehberimizdeki kontrol listesini kullanabilirsiniz.
  • WP-Cron yerine sistem cron’una geçin: wp-config.php‘ye define( 'DISABLE_WP_CRON', true ); ekleyin ve sunucu cron’una wget -q -O - https://yeniDomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1 ekleyin.
  • Wordfence, Sucuri veya iThemes Security ile yeni sunucuda baştan tarama başlatın.
  • Tüm yönetici hesaplarına 2FA (iki adımlı doğrulama) zorunluluğu getirin.
  • Eski sunucudaki dosyaları en az 30 gün boyunca silmeyin; geri dönüş ihtimalinizi açık tutun.

Sıkça Sorulan Sorular (SSS)

WordPress site taşıma ne kadar sürer?

Site büyüklüğüne, hostingin hızına ve yöntemin teknik düzeyine bağlıdır. Ortalama 500 MB’lik bir blog manuel olarak 1-2 saatte, 10 GB’lık bir WooCommerce mağazası ise WP-CLI ile 4-6 saatte taşınır. DNS yayılması bazı bölgelerde 24 saate kadar uzayabilir; bu yüzden TTL değerini taşımadan bir gün önce 300’e indirin.

Taşıma sırasında SEO sıralamamı kaybeder miyim?

Aynı domainle taşıyorsanız doğru yapılan bir taşıma SEO’yu kesinlikle olumsuz etkilemez; aksine daha hızlı sunucu sayesinde Core Web Vitals skorları yükselir. Domain değiştiriyorsanız 301 yönlendirmeleri eksiksiz uygulamak ve yeni domain’i Google Search Console’a “Adres Değişikliği” aracıyla bildirmek şarttır.

Taşıma sırasında siteme erişimi nasıl kapatırım?

Bakım modu eklentisi (LightStart, WP Maintenance Mode) veya WP-CLI’in wp maintenance-mode activate komutu yeterlidir. Eklentisiz çözüm için kök dizine geçici bir maintenance.html bırakıp .htaccess‘te yönlendirme yapabilirsiniz; ancak bu yöntem yöneticinin de erişimini engelleyebilir, dikkatli kullanın.

WordPress taşıma için en iyi eklenti hangisidir?

Küçük ve orta ölçekli (≤512 MB) siteler için All-in-One WP Migration en kolay seçenektir. Daha büyük ve karmaşık WooCommerce/üyelik siteleri için Duplicator Pro daha güvenilirdir. Düzenli yedek alanlar için ise UpdraftPlus + Migrator kombosu pratiktir. SSH erişimi olan profesyoneller için altın standart hâlâ WP-CLI‘dır.

Taşıma sırasında veritabanı boyutum çok büyükse ne yapmalıyım?

1 GB’tan büyük veritabanlarında phpMyAdmin yetersiz kalır. mysqldump + gzip ile sıkıştırılmış aktarım yapın ve BigDump betiğini kullanın. Geçici tabloları (Yoast indexable, Action Scheduler logları, expired transient’lar) taşımadan önce temizleyerek boyutu çoğunlukla %30-50 azaltabilirsiniz: wp transient delete --all ve wp action-scheduler clean komutları başlangıç için iyi bir tercih olur.

Eski hostingi ne zaman iptal edebilirim?

DNS değişikliğinin tamamen yayılmasını ve yeni sunucuda 24-48 saat sorunsuz log üretildiğini gördükten sonra, eski hostingi en az 30 gün daha bekletin. Dünya genelinde DNS önbelleklerinden gelen istekler, eski sunucuda hâlâ yazılı içerik düşmesine neden olabilir. Bu süreci atladığınızda son birkaç gönderiyi kaybedebilirsiniz.

Kaynak Önerileri

Doğru planlanmış bir WordPress site taşıma operasyonu; site sahibine daha hızlı, daha güvenli ve daha ölçeklenebilir bir altyapı kazandırır. Yedeklemeyi atlamadan, URL güncellemelerini eksik bırakmadan ve taşıma sonrası testleri savsaklamadan ilerlerseniz; ziyaretçileriniz herhangi bir kesinti yaşamadan yeni sunucunuzun avantajlarından faydalanmaya başlar.

Related posts