Eklentisiz Manuel WordPress Site Tasima Rehberi

WordPress sitenizi bir hostingten digerine tasimak icin hazir bir eklentiye ihtiyaciniz yok. Eklentiler pratik gorunse de; boyut sinirlari, zaman asimlari, kaynak tuketimi ve yarim kalan disa aktarmalar yuzunden kritik bir tasimada tam olarak isinize yaramadiklari an ortaya cikar. Manuel yontem ise sadece iki bileseni yerinden etmeye dayanir: dosyalar ve veritabani. Bu ikisini dogru sirayla tasir ve wp-config.php ile veritabanindaki adres kayitlarini duzeltirseniz siteniz yeni sunucuda birebir ayni sekilde acilir.

Bu rehber, uzun yillar Linux sunucu yoneten birinin bir musteriye anlatir gibi ilerliyor. Amac size sadece "sunu tikla, bunu yukle" demek degil; her adimin neden yapildigini, nerede takilabileceginizi ve serialize edilmis verinin neden dikkat isteyen bir konu oldugunu anlatmak. Sonunda hem tasimayi tamamlamis hem de bir daha herhangi bir siteyi gozunuz kapali tasiyabilecek zihinsel modeli kurmus olacaksiniz. Baslamadan once yeni hosting hesabinizin, bir FTP/SFTP erisiminizin ve her iki tarafta da phpMyAdmin (ya da eslenik bir arac) erisiminizin hazir oldugundan emin olun.

WordPress Sitesi Aslinda Nelerden Olusur#

Tasima islemine guvenle girmek icin once WordPress'in fiziksel olarak nelerden olustugunu netlestirelim. Bir WordPress kurulumu iki buyuk parcadan olusur ve bu iki parca birbirinden bagimsiz yerlerde durur.

Birincisi dosyalar. Bunlar sunucunuzun disk alaninda, genellikle public_html veya www klasoru altinda bulunur. Icinde WordPress cekirdegi (wp-admin, wp-includes), yapilandirma dosyasi (wp-config.php) ve en onemlisi tum ozel iceriginizi barindiran wp-content klasoru vardir. wp-content icinde temalariniz, eklentileriniz ve uploads altindaki tum gorsel/medya dosyalariniz yer alir.

Ikincisi veritabani. Yazilariniz, sayfalariniz, yorumlariniz, kullanicilariniz, tum ayarlariniz ve eklenti verileriniz dosyalarda degil MySQL/MariaDB veritabaninda tutulur. Yani wp-content klasorunu tasisaniz ama veritabanini tasimasaniz, karsiniza bos bir WordPress cikar. Ikisi bir arada tasindiginda site butunlesir.

Bu ayrimi kavradiginizda tasimanin neden "iki ayri is" oldugunu ve neden ikisinin de eksiksiz gecmesi gerektigini net gorursunuz. Butunlesik bir yaklasim icin ayrica WordPress yedekleme rehberimize goz atmanizi oneririm; iyi bir tasima zaten iyi bir yedegin uzerine kurulur.

Tasimadan Once Yapilacaklar ve Bakim Modu#

Aceleyle baslanan tasimalarin cogu, kacinilabilecek kucuk hatalar yuzunden yarim kalir. Bu yuzden fiili aktarima gecmeden once birkac hazirlik adimini geride birakalim.

Ilk olarak tam bir yedek alin. Manuel tasimanin guzel yani, zaten yedek alma sureciyle bire bir ayni olmasidir; dosyalari indirdiginizde ve veritabanini disa aktardiginizda elinizde otomatik olarak bir yedek olusur. Ancak yeni sunucuda bir sey ters giderse eski sitenizin hala ayakta oldugundan emin olun; DNS'i degistirene kadar eski hosting silinmemeli.

Ikinci olarak eski site uzerinde onbellek eklentilerini gecici olarak devre disi birakin. WP Super Cache, W3 Total Cache gibi araclar disk uzerinde statik dosyalar uretir ve bunlari tasimak sadece gereksiz veri yigini olusturur, hatta yeni sunucuda hatali yollara isaret edebilir. Onbellegi temizleyip eklentiyi kapatmak, tasinan veriyi hem kucultur hem sadelestirir.

Ucuncusu, veri tutarliligi icin siteyi bakim moduna almak. Tasima suresince kullanicilar yeni yorum, siparis veya form kaydi olustururlarsa, bu kayitlar eski veritabaninda kalir ve yeni sunucuya gecmez; boylece veri kaybi yasarsiniz. Basit bir bakim sayfasi icin kok dizine .maintenance adinda bir dosya birakabilirsiniz:

# Eski sunucuda kok dizinde calistirin
echo '<?php $upgrading = time(); ?>' > .maintenance

Bu dosya var oldugu surece WordPress otomatik olarak "kisa sureligine bakimda" ekrani gosterir. Tasima bittiginde silmeniz yeterlidir. Alternatif olarak sunucu duzeyinde bir yonlendirme de kurabilirsiniz. Genel bir bakis icin genel web sitesi tasima rehberimiz de WordPress disi sistemler icin ayni mantigi anlatir.

Dosyalari FTP ile Indirme#

Hazirliklar tamamlandiginda ilk somut adim, tum site dosyalarini eski sunucudan indirmektir. Bunun icin FileZilla, WinSCP ya da tercihinize gore herhangi bir SFTP istemcisi kullanabilirsiniz. Mumkunse duz FTP yerine sifreli SFTP tercih edin.

Baglanti bilgilerinizi hosting panelinizden alip istemciye girin ve kok dizine (public_html) gidin. Burada .htaccess gibi nokta ile baslayan gizli dosyalari da gorebildiginizden emin olun; FileZilla'da bunun icin "Sunucu > Gizli dosyalari zorla goster" secenegini isaretleyin. Ardindan tum dizini yerel bir klasore indirin.

# Linux/macOS uzerinde lftp ile toplu ve hizli indirme ornegi
lftp -u kullanici,parola sftp://eski-sunucu.example.com <<'EOF'
set sftp:auto-confirm yes
mirror --verbose --parallel=4 /home/site/public_html ./yedek-dosyalar
bye
EOF

Cok sayida kucuk dosya (ozellikle binlerce medya dosyasi) FTP uzerinden tek tek indiginde saatlerce surebilir. Bu durumda cok daha hizli bir alternatif, dosyalari sunucuda once sikistirip tek bir arsiv olarak indirmektir. SSH erisiminiz varsa:

# Sunucuda SSH ile: tum siteyi tek bir arsive topla
cd /home/site
tar -czf site-yedek.tar.gz public_html

Olusan site-yedek.tar.gz dosyasini FTP ile indirmek, binlerce ayri dosyayi indirmekten kat kat hizli ve guvenilirdir; yarida kesilme riski de dusuktur. SSH ve gelismis erisim isteyen senaryolar icin sunucu yonetimi hizmetimiz ya da tam kontrol saglayan bir VDS sunucu size bu esnekligi verir.

Indirme bittiginde yerel klasorunuzde wp-admin, wp-includes, wp-content, wp-config.php, index.php ve .htaccess gibi ogeleri gormeli, ozellikle wp-content/uploads altinda medyanizin eksiksiz oldugunu kontrol etmelisiniz.

Veritabanini phpMyAdmin ile Disa Aktarma#

Dosyalar elinizdeyken sira sitenizin beynine, yani veritabanina geliyor. Once hangi veritabaninin bu siteye ait oldugunu bulun. Bu bilgi wp-config.php icinde acikca yazar:

// wp-config.php icinden ilgili satirlar
define( 'DB_NAME', 'eski_site_db' );
define( 'DB_USER', 'eski_site_user' );
define( 'DB_PASSWORD', 'guclu-parola' );
define( 'DB_HOST', 'localhost' );

$table_prefix = 'wp_';

DB_NAME degeri disa aktaracaginiz veritabaninin adidir; $table_prefix ise tablolarin onunde bulunan ekidir (cogu kez wp_ ama guvenlik icin degistirilmis olabilir). Simdi eski hostingin phpMyAdmin arayuzune girin, sol taraftan bu veritabanini secin ve ust menuden Disa Aktar (Export) sekmesine gecin.

Buradan Ozel (Custom) yontemini secmenizi oneririm; cunku birkac ayari kontrol etmek isteyeceksiniz. Bicim olarak SQL kalsin. Onemli iki nokta var: "Add DROP TABLE" secenegini isaretlerseniz, iceri aktarirken ayni isimli tablolar once silinip yeniden olusturulur, bu da temiz bir baslangic saglar. Bir de karakter kodlamasinin utf8mb4 oldugundan emin olun; aksi halde Turkce karakterler bozulabilir.

Buyuk veritabanlarinda tarayici uzerinden export zaman asimina ugrayabilir. SSH erisiminiz varsa komut satiri her zaman daha guvenilirdir:

# Komut satirindan tek dosyaya guvenli disa aktarma
mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u eski_site_user -p eski_site_db > site-veritabani.sql

--single-transaction bayragi, disa aktarma sirasinda tablolarin kilitlenmesini onleyerek canli bir siteyi bile tutarli sekilde yedeklemenizi saglar. Elinizde .sql uzantili tek bir dosya olustugunda veritabani yaninizda demektir. Ileride bu adimi duzenli tekrarlamak isterseniz WordPress yedekleme rehberindeki otomasyon oneriler isinizi kolaylastirir.

Yeni Sunucuda Dosya ve Veritabani Iceri Aktarma#

Artik iki parca da elinizde: dosyalar ve .sql veritabani dokumu. Simdi bunlari yeni hostingte yerine yerlestirelim. Once yeni hosting hesabinizda bir veritabani ve veritabani kullanicisi olusturun. Cogu panelde bu birkac tik meselesidir; olusturduktan sonra kullaniciyi veritabanina tum yetkilerle atadiginizdan emin olun. Bu yeni bilgileri bir kenara not edin, birazdan lazim olacak.

Sonra dosyalari yukleyin. Eger arsiv olarak indirdiyseniz, yeni sunucuya arsivi yukleyip orada acmak en hizli yoldur:

# Yeni sunucuda SSH ile arsivi ac
cd ~/public_html
tar -xzf site-yedek.tar.gz --strip-components=1

--strip-components=1 parametresi, arsiv icindeki fazladan public_html klasor katmanini atlayarak dosyalari dogrudan kok dizine cikarir. SSH yoksa FTP ile dosyalari public_html icine yuklemeniz yeterli; sadece sabir isteyen bir islemdir.

Dosyalar yerindeyken veritabanini iceri aktaralim. Yeni hostingin phpMyAdmin arayuzunde az once olusturdugunuz bos veritabanini secin, Iceri Aktar (Import) sekmesine gecin ve .sql dosyanizi secip calistirin. Yine buyuk dosyalarda tarayici yetersiz kalabilir; komut satirindan iceri aktarmak daha saglamdir:

# Komut satirindan iceri aktarma
mysql -u yeni_site_user -p yeni_site_db < site-veritabani.sql

Iceri aktarma tamamlandiginda phpMyAdmin'de wp_options, wp_posts gibi tablolarin listelendigini gormelisiniz. Tablo sayisi ve isimleri eski sunucudakiyle ayni olmali. Bu noktada dosyalar ve veri yerinde ama site henuz calismaz; cunku wp-config.php hala eski veritabanina isaret ediyor.

wp-config.php Dosyasini Guncelleme#

Sitenin yeni veritabaniyla konusabilmesi icin wp-config.php dosyasini yeni baglanti bilgilerine gore duzenlemeniz gerekir. FTP ile bu dosyayi acin ve az once olusturdugunuz veritabani adi, kullanici adi ve parolayi girin:

// Yeni sunucuya gore guncellenmis wp-config.php
define( 'DB_NAME', 'yeni_site_db' );
define( 'DB_USER', 'yeni_site_user' );
define( 'DB_PASSWORD', 'yeni-guclu-parola' );
define( 'DB_HOST', 'localhost' );

Cogu paylasimli hostingte DB_HOST degeri localhost olarak calisir; ancak bazi saglayicilar farkli bir sunucu adi ya da soket yolu verir. Yeni hostingin belgelerinde bu bilgi acikca yazar. Yanlis DB_HOST, tasimalarda en sik karsilasilan "veritabani baglanti hatasi" (Error establishing a database connection) mesajinin bir numarali sebebidir.

Bu asamada guvenlik anahtarlarini (AUTH_KEY, SECURE_AUTH_KEY vb.) yenilemek de iyi bir aliskanliktir. WordPress bunlar icin resmi bir uretici sunar; yeni degerleri kopyalayip wp-config.php icindeki eski satirlarin yerine yapistirdiginizda tum eski oturumlar guvenli sekilde sonlanir. Ayni sekilde $table_prefix degerinin eski sitedekiyle birebir ayni oldugundan emin olun; farkli bir ek yazarsaniz WordPress tablolari bulamaz.

wp-config.php dogru bilgilerle guncellendiginde site teknik olarak yeni veritabanina baglanabilir hale gelir. Yine de site adresi konusunda bir dert daha var; onu bir sonraki bolumde cozecegiz.

siteurl ve home Degerlerini SQL ile Duzeltme#

WordPress, site adresini iki yerde saklar: wp_options tablosundaki siteurl ve home satirlarinda. Eger alan adiniz degismiyorsa (ornegin ornek.com yine ornek.com kalacaksa) ve sadece sunucu degistiyseniz, bu degerlere dokunmaniza gerek olmayabilir. Ancak gecici bir test alan adina, https'e ya da yeni bir alan adina geciyorsaniz bunlari duzeltmelisiniz.

Yeni sunucunun phpMyAdmin arayuzunde SQL sekmesine gecip su sorguyu calistirin (tablo ekinizin wp_ oldugunu varsayarak):

UPDATE wp_options SET option_value = 'https://ornek.com'
  WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://ornek.com'
  WHERE option_name = 'home';

Bu iki satir sitenin ana adresini duzeltir ve wp-admin paneline giris yapabilmenizi saglar. Panele girdikten sonra Ayarlar > Kalici Baglantilar (Permalinks) sayfasina gidip hicbir sey degistirmeden Kaydet demeniz, .htaccess kurallarinin yeni sunucuya gore tazelenmesini saglar; bu da "yazilara tiklayinca 404 hatasi" sorununun standart cozumudur.

Yalniz burada cok kritik bir uyari var. siteurl ve home disinda, veritabaninin derinliklerinde eski alan adiniz onlarca yerde gomulu olabilir: yazi iceriklerindeki resim adresleri, tema ayarlari, widget'lar ve eklenti verileri. Bunlari duzeltmek icin akla ilk gelen sey basit bir toplu bul-degistir sorgusudur:

-- DIKKAT: Bu yaklasim serialize verisini BOZABILIR
UPDATE wp_posts
  SET post_content = REPLACE(post_content, 'eski.com', 'yeni.com');

Bu sorgu duz metin icin calisir; ancak WordPress bircok ayari serialize edilmis (dizi yapisini metne cevrilmis) olarak saklar. Serialize veride her metnin uzunlugu bir sayi olarak yazilidir; ornegin s:8:"eski.com" kaydinda 8 karakter sayisidir. eski.com yerine daha uzun bir yenisite.com yazdiginizda uzunluk hala 8 gorunur, gercek ise 12'dir. Bu tutarsizlik o ayari tamamen okunamaz hale getirir ve genellikle widget'larin, tema seceneklerinin ya da eklenti yapilandirmalarinin kaybolmasiyla sonuclanir.

Bu tehlikeyi asmanin dogru yolu, uzunlugu kendisi yeniden hesaplayan bir arac kullanmaktir. En yaygin ikisi soyle karsilastirilabilir:

SSH erisiminiz varsa WP-CLI acik ara en temiz secimdir ve serialize veriyi eksiksiz korur:

# WP-CLI ile serialize-guvenli toplu adres degisimi
wp search-replace 'https://eski.com' 'https://yeni.com' \
  --all-tables --skip-columns=guid --dry-run

--dry-run bayragi hicbir sey degistirmeden kac kaydin etkilenecegini gosterir; sonucu inceleyip dogruladiktan sonra ayni komutu bu bayrak olmadan calistirirsiniz. --skip-columns=guid ise WordPress'in kalici tanimlayici olarak kullandigi guid alanina dokunmamanizi saglar; bu alan bilerek degistirilmez. WP-CLI kullanilamiyorsa "Search Replace DB" adli bilinen bir PHP betigini gecici olarak kok dizine yukleyip tarayicidan calistirabilir, isiniz bitince mutlaka silebilirsiniz.

Tasima Sonrasi Kontrol Listesi ve DNS Gecisi#

Site yeni sunucuda acilmaya basladiginda hemen "bitti" demeyin; birkac kontrol, ilerideki bas agrilarini onler. Once gorsellerin duzgun yuklendigini, ic sayfalarin acildigini ve yonetim panelinden bir yaziyi kaydedebildiginizi dogrulayin.

DNS henuz yeni sunucuya yonelmeden test yapmak icin bilgisayarinizin hosts dosyasini gecici olarak duzenleyebilirsiniz. Boylece sadece siz siteyi yeni sunucuda gorursunuz, ziyaretciler hala eski sunucudadir:

# /etc/hosts (Linux/macOS) veya C:\Windows\System32\drivers\etc\hosts
203.0.113.45   ornek.com
203.0.113.45   www.ornek.com

Buradaki IP adresini yeni hostinginizin size verdigi IP ile degistirin. Test tamamlandiginda bu iki satiri silmeyi unutmayin. Her sey yolundaysa artik gercek DNS gecisini yapabilirsiniz. Alan adi yoneticinizde (ya da alan adi panelinizde) A kaydini yeni IP'ye guncelleyin:

; Alan adi DNS bolgesi
ornek.com.      3600    IN    A       203.0.113.45
www.ornek.com.  3600    IN    A       203.0.113.45

DNS degisikliginin dunya genelinde yayilmasi (propagasyon) birkac saati bulabilir. Bu surecte hem eski hem yeni sunucu ayakta kalmali; cunku bazi ziyaretciler bir sure daha eskiye dusecektir. Iste tam da bu yuzden tasima sirasinda siteyi bakim moduna almak onemliydi: her iki sunucu da ayni anda yazma alsa bile, bakim modu sayesinde veri catallanmasi yasanmaz.

Son olarak yeni sunucuda SSL sertifikanizi kurun; cogu modern hosting Let's Encrypt sertifikasini otomatik saglar. Adres cubugunda kilit simgesini gordukten sonra karisik icerik (mixed content) uyarilari kaliyorsa, bunlar genellikle hala http ile baslayan eski medya baglantilaridir ve yukaridaki serialize-guvenli search-replace adimiyla temizlenir. Guvenlik katmanini guclendirmek isterseniz SSL ve WAF hizmetlerimiz devreye girer. DNS yonetimi ve kayit turlerini derinlemesine anlamak icin genel tasima rehberimiz de faydali olacaktir.

Sıkça Sorulan Sorular#

Manuel tasima sirasinda sitem ne kadar sure erisilemez kalir#

Dogru planlanmis bir manuel tasimada ziyaretcileriniz icin gorunur bir kesinti neredeyse sifira inebilir. Dosyalari ve veritabanini yeni sunucuya kopyalayip test ederken eski sunucu hala yayindadir; sadece DNS'i degistirdiginiz an gecis baslar. DNS propagasyonu tamamlanana kadar her iki sunucuyu da ayakta tutar ve tasima aninda siteyi bakim moduna alirsaniz, kullanicilar kesinti yerine yalnizca kisa bir bakim ekrani gorur.

siteurl degerini yanlislikla bozdum ve panele giremiyorum ne yapmaliyim#

Panele girisi engelleyen bu durumda cozum dosyalarda degil veritabanindadir. phpMyAdmin'e girip wp_options tablosundan siteurl ve home satirlarini dogru adrese geri guncelleyin; bu iki degeri duzelttiginizde panel erisiminiz aninda geri gelir. Ayrica gecici bir cozum olarak wp-config.php dosyasina define('WP_HOME','https://ornek.com'); ve define('WP_SITEURL','https://ornek.com'); satirlarini ekleyerek veritabanindaki degerleri gecersiz kilabilirsiniz.

Veritabanini disa aktarirken hangi karakter setini secmeliyim#

Turkce icerikli sitelerde her zaman utf8mb4 karakter setini kullanmalisiniz. Yanlis bir kodlama secildiginde Turkce harfler ve ozel karakterler yeni sunucuda soru isareti ya da bozuk sembollere donusur ve bunu geri almak zahmetlidir. Hem disa aktarma hem iceri aktarma adimlarinda ayni utf8mb4 ayarini kullanmaya ozen gosterin; komut satirinda --default-character-set=utf8mb4 bayragi bunu garantiler.

Toplu bul-degistir icin neden duz SQL sorgusu tehlikeli#

Duz bir REPLACE sorgusu tehlikelidir cunku WordPress bircok ayari serialize edilmis dizi olarak saklar ve bu yapida her metnin karakter uzunlugu ayrica kayitlidir. Adresi farkli uzunlukta bir metinle degistirdiginizde kayitli uzunluk artik gercek uzunlukla uyusmaz ve o ayar okunamaz hale gelir; sonucta widget'lar, tema secenekleri veya eklenti verileri kaybolur. Bu yuzden alan adi degisiminde WP-CLI search-replace gibi uzunlugu yeniden hesaplayan serialize-guvenli araclar kullanmalisiniz.

FTP cok yavas binlerce dosya varsa nasil hizlandirabilirim#

En etkili yol, dosyalari tek tek indirmek yerine sunucuda once bir arsiv haline getirmektir. SSH erisiminiz varsa tar -czf site.tar.gz public_html komutuyla tum siteyi tek dosyaya toplar, bu tek arsivi indirir ve yeni sunucuda acarsiniz; boylece binlerce kucuk dosyanin ayri ayri transferindeki yavaslik ve kesilme riski ortadan kalkar. SSH yoksa en azindan medya klasorunu parcalar halinde indirerek transferin yarida kesilme olasiligini azaltabilirsiniz.

wp-config dosyasindaki guvenlik anahtarlarini degistirmem gerekir mi#

Zorunlu degildir ama tasima sirasinda bu anahtarlari yenilemek guvenlik acisindan tavsiye edilir. AUTH_KEY ve benzeri anahtarlari degistirdiginizde tum eski oturumlar gecersiz olur, boylece varsa ele gecirilmis bir oturum de sonlanmis olur. WordPress'in resmi anahtar uretecinden yeni degerleri alip wp-config.php icindeki karsiliklarinin yerine yapistirmaniz yeterlidir; kullanicilarin yalnizca yeniden giris yapmasi gerekir, baska bir yan etkisi olmaz.

Kapanış#

Manuel WordPress tasima, ilk bakista teknik gorunse de aslinda net bir mantiga dayanir: dosyalari tasi, veritabanini tasi, baglanti ve adres bilgilerini duzelt. Bu uc adimi anladiginizda hicbir eklentiye bagli kalmadan, boyut sinirlarina takilmadan ve kaynak tuketimini kontrol ederek istediginiz siteyi guvenle goc ettirebilirsiniz. Serialize veriye saygili davranmak ve DNS gecisini sabirla yonetmek, sizi tasimadan sonraki en yaygin sorunlardan bastan korur.

Bu tasimayi sorunsuz tamamlamanin en buyuk parcasi, altindaki saglam hosting altyapisidir. Hizli ve WordPress'e ozel optimize edilmis bir ortam istiyorsaniz WordPress hosting paketlerimize, daha genel ihtiyaclar icin web hosting seceneklerimize; tam kontrol ve SSH esnekligi arayanlar icin ise VDS ve sunucu yonetimi hizmetlerimize goz atabilirsiniz. Tasimayi bizim ustlenmemizi isterseniz site tasima hizmetimiz tum bu adimlari sizin yerinize eksiksiz yurutur; duzenli guvenlik icin de yedekleme cozumlerimiz her zaman yaninizdadir.