Yedeği Geri Yükledim Ama Site Açılmıyor: Sık Nedenler ve Çözüm

Yedeği geri yükledim ama site açılmıyor — bu cümle, destek ekiplerinin en gergin saatlerinde duyduğu cümledir. Panel "Geri yükleme başarıyla tamamlandı" yazmıştır, dosyalar yerindedir, veritabanı içeri alınmıştır; ama tarayıcıda ya bembeyaz bir sayfa, ya "Veritabanı bağlantısı kurulamadı", ya da hiç beklemediğiniz eski bir içerik durmaktadır. Sorun neredeyse hiçbir zaman "yedek bozuk" değildir. Sorun, yedeğin alındığı ortamla geri yüklendiği ortamın birbirinden farklı olmasıdır ve bu fark üç yerde toplanır: veritabanının içindeki adres kayıtları, dosya sistemi izinleri, PHP çalışma ortamı.

Bu yazı, geri yükleme sonrası hata ayıklamayı sırayla anlatıyor. Rehberlerin çoğu "işlem tamamlandı" ekranında biter; oysa gerçek iş tam ondan sonra başlar. Aşağıda önce belirtiye göre daralttığımız bir tanı akışı var: beyaz ekran, veritabanı hatası, yönlendirme döngüsü, eski içerik ve kısmi geri yükleme. Her başlıkta neye bakacağınızı, hangi komutu çalıştıracağınızı ve hangi çıktının ne anlama geldiğini yazdım. Sonunda da belirtiden nedene giden bir hızlı tanı tablosu ve bir dahaki sefere aynı yere düşmemek için geri yüklemeyi doğru sırayla yapmanın yolu var.

Geri Yükleme Bitti Ama Site Açılmıyor: Önce Neyi Doğrulamalısınız#

İlk yapılacak şey, hatanın nerede oluştuğunu ayırmaktır: tarayıcıda mı, DNS'te mi, web sunucusunda mı, uygulamada mı. Bunu ayırmadan yapılan her müdahale kör atıştır ve çoğu zaman durumu kötüleştirir.

Sırasıyla şunları doğrulayın:

1. Tarayıcı önbelleğini devre dışı bırakın. Gizli sekmede açın veya Ctrl + F5 yapın. Geri yükleme sonrası gördüğünüz "eski içerik" vakalarının önemli bir kısmı, sadece tarayıcı önbelleğidir.
2. Sitenin gerçekten bu sunucuya baktığından emin olun. Alan adı hâlâ eski sunucuyu gösteriyor olabilir. Bunu ping veya dig ile doğrulayın; IP beklediğiniz IP değilse geri yüklediğiniz sunucuyu zaten görmüyorsunuz demektir. Bu durumda alan adına dokunmadan test etmek için hosts dosyası ile site test etme yöntemini kullanın.
3. HTTP durum kodunu okuyun. Beyaz ekranla 500 hatası aynı şey değildir; ikisi tamamen farklı yerlere bakmanızı gerektirir.

curl -I -L https://siteadresiniz.com

Bu komutun döndürdüğü ilk satır tanının yarısıdır. HTTP/2 200 gördüğünüz hâlde sayfa boşsa sorun PHP tarafındadır. 500 görüyorsanız sunucu isteği işlerken çuvallamıştır. 301/302 zinciri sonsuz dönüyorsa yönlendirme kuralları veya site adresi ayarı bozuktur. 403 görüyorsanız izin sorununa bakacaksınız.

Bir de dosyaların gerçekten yerinde olduğunu gözle görün. cPanel Dosya Yöneticisi'nde ya da SSH ile:

ls -la /home/kullanici/public_html | head -20

index.php yoksa, wp-config.php yoksa ya da dizin bomboşsa geri yükleme hiç çalışmamıştır; hata ayıklamaya değil, geri yüklemeyi tekrarlamaya bakacaksınız.

Beyaz Ekran Görüyorsanız: PHP Hata Kaydını Açın#

Beyaz ekran, PHP'nin ölümcül bir hata verip hata mesajını ekrana basmaması demektir. Yani hata vardır, sadece size gösterilmiyordur. Yapılacak tek doğru şey onu görünür kılmaktır.

WordPress kullanıyorsanız wp-config.php içinde şu satırları bulun ve şöyle değiştirin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Bu ayar hatayı ekrana basmaz, wp-content/debug.log dosyasına yazar — canlı sitede doğru olan da budur. Sayfayı bir kez yenileyin, sonra kaydı okuyun:

tail -n 50 wp-content/debug.log

WordPress dışı bir uygulamada ya da hiç hata dosyası oluşmuyorsa, sunucunun kendi hata kaydına bakın. cPanel'de bu Ölçümler → Hatalar ekranıdır; SSH'niz varsa:

tail -n 100 ~/logs/siteadresiniz.com.error.log
tail -n 100 /var/log/nginx/error.log

Bu noktada gördüğünüz satır genelde çok açıklayıcıdır. En sık karşılaştığım üç kalıp şudur:

• PHP Fatal error: Uncaught Error: Call to undefined function ... → PHP eklentisi (mbstring, imagick, intl gibi) yeni sunucuda kurulu değil.
• PHP Fatal error: Allowed memory size of ... exhausted → bellek limiti yetersiz; ayrıntı için allowed memory size exhausted hatası yazısına bakın.
• syntax error, unexpected ... → PHP sürümü farkı. Yedek PHP 7.4 ortamından geldi, sunucu PHP 8.x çalıştırıyor.

Hata kaydını okumadan yapılan her deneme zaman kaybıdır. cPanel hata kayıtları ekranını nasıl okuyacağınızı bilmiyorsanız önce onu öğrenin; bu tek beceri destek taleplerinin yarısını kendi başınıza kapatmanızı sağlar.

"Veritabanı Bağlantı Hatası" Alıyorsanız#

Bu hata neredeyse her zaman yapılandırma dosyasındaki bağlantı bilgilerinin yeni sunucuda geçerli olmamasından kaynaklanır. Dosyaları geri yüklediniz, wp-config.php de eski sunucunun veritabanı adını, kullanıcısını ve şifresini taşıyor.

Kontrol listesi:

1. Veritabanı adı gerçekten var mı. Paylaşımlı hostinglerde veritabanı adları hesap ön ekiyle oluşur ve bu ön ek sunucudan sunucuya değişir. Eski hesapta eskihesap_wp, yeni hesapta yenihesap_wp olur. wp-config.php içindeki DB_NAME hâlâ eskisini yazıyorsa bağlantı kurulmaz.
2. Kullanıcı veritabanına atanmış mı. Kullanıcıyı oluşturmak yetmez; cPanel'de MySQL Veritabanları → Veritabanına Kullanıcı Ekle adımından kullanıcıyı veritabanına eklemeniz ve ALL PRIVILEGES vermeniz gerekir. Bu adım en sık atlanan adımdır.
3. DB_HOST değeri doğru mu. Çoğu paylaşımlı hostingte localhost doğrudur; bazı yapılandırmalarda 127.0.0.1 ya da ayrı bir veritabanı sunucusu adı gerekir.

Bağlantıyı uygulamadan bağımsız test edin:

mysql -u kullanici_adi -p -h localhost veritabani_adi -e "SHOW TABLES;" | head

Komut tablo listesi döndürüyorsa bağlantı sağlamdır ve sorun uygulamanın yapılandırma dosyasındadır. ERROR 1045 (28000): Access denied alıyorsanız kullanıcı/şifre ya da yetki hatalıdır; ERROR 1049 alıyorsanız o isimde veritabanı yoktur.

Tablolar listeleniyor ama boşsa veya sadece birkaç tablo varsa, veritabanı dökümü eksik aktarılmıştır. Bu genelde büyük .sql dosyasının phpMyAdmin yükleme limitine takılmasından olur — dökümü komut satırından almanın ve geri yüklemenin doğru yolu için veritabanı yedekten geri yükleme yazısındaki adımları izleyin.

Eski İçerik veya Yanlış Alan Adı Görünüyorsa: Adres Kayıtları#

Site açılıyor ama başka bir alan adına yönlendiriyorsa, tasarım kayıpsa ya da yönetim paneline giremiyorsanız neden neredeyse kesindir: veritabanının içinde site adresi hâlâ eski alan adını yazıyordur.

Bu, Türkçe kaynaklarda en çok atlanan konudur. Yedek başka bir alan adıyla ya da geçici bir test adresiyle alındıysa (site.gecici-alan.com gibi), o adres veritabanına gömülüdür. WordPress'te iki alan tutar:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl','home');

Doğru değere şöyle çekersiniz:

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

Ama iş burada bitmez. İçeriğin, menülerin ve görsel yollarının içinde de eski adres gömülü kalır. Bunu düzeltmenin yanlış yolu, .sql dosyasında düz metin arayıp değiştirmektir: WordPress bazı ayarları PHP serialize biçiminde saklar ve o biçim dizelerin karakter uzunluğunu da içinde tutar. Adresi metin olarak değiştirdiğinizde uzunluk bilgisi bozulur, o ayar tamamen okunamaz hâle gelir ve tema ayarlarınız sıfırlanır. Doğru yol, uzunluk bilgisini de düzelten bir arama-değiştirme aracı ya da WP-CLI kullanmaktır:

wp search-replace 'https://eski-adres.com' 'https://siteadresiniz.com' --skip-columns=guid --dry-run

--dry-run ile önce kaç satırın etkileneceğini görün, doğruysa bayrağı kaldırıp tekrar çalıştırın. --skip-columns=guid önemlidir; guid sütunu içerik tanımlayıcısıdır ve değiştirilmemesi gerekir. Konunun tamamı için site taşıma sonrası URL değiştirme yazısına bakın.

Yönetim paneline hiç giremiyorsanız wp-config.php içine geçici olarak şu iki satırı ekleyip paneli açabilirsiniz; giriş yaptıktan sonra satırları silin:

define( 'WP_HOME', 'https://siteadresiniz.com' );
define( 'WP_SITEURL', 'https://siteadresiniz.com' );

Dosya İzinleri ve Sahiplik Bozulduysa#

403 hatası, "beyaz ekran ama hata kaydı da boş" durumu ve "yükleme yapamıyorum" şikâyeti çoğunlukla tek bir kaynaktan gelir: dosyaların sahibi yanlıştır.

Yedek başka bir sunucuda root ile açıldıysa ya da arşiv tar ile sahiplik bilgisi korunarak çıkarıldıysa, dosyalar sizin hesabınıza değil başka bir kullanıcıya ait olur. Web sunucusu o dosyaları okuyamaz. Kontrol:

ls -la /home/kullanici/public_html | head
stat -c '%U:%G %a %n' /home/kullanici/public_html/index.php

Çıktıda kullanıcı adınız yerine root ya da bir sayı (ör. 1004) görüyorsanız sahiplik bozuktur. Root erişiminiz varsa düzeltme:

chown -R kullanici:kullanici /home/kullanici/public_html

Sonra izinleri standart değerlere çekin — dizinler 755, dosyalar 644:

find /home/kullanici/public_html -type d -exec chmod 755 {} \;
find /home/kullanici/public_html -type f -exec chmod 644 {} \;
chmod 600 /home/kullanici/public_html/wp-config.php

777 vermeyin. "Çalışsın diye" verilen 777 izinleri, paylaşımlı sunucularda başka hesaplardan dosyanızın yazılabilir olması demektir ve pek çok sunucu yapılandırması 777 dizinlerde PHP çalıştırmayı zaten reddeder — yani sorunu çözmez, yenisini ekler. Ayrıntı için linux dosya izinleri ve wordpress dosya izinleri yazılarına bakın.

PHP Sürümü Farkından Kaynaklanan Bozulmalar#

Yedek eski bir PHP sürümünden geldiyse, geri yükleme teknik olarak başarılı olur ama uygulama açılmaz. Bu en sinsi vakadır çünkü hiçbir şey "eksik" değildir.

Belirtiler tipiktir: syntax error, unexpected ':', Cannot use "..." as ..., Deprecated: Function ... is deprecated yığını ve ardından ölümcül hata. Tanı için sunucunun hangi sürümü çalıştırdığını görün:

php -v

cPanel'de bunu Yazılım → PHP Sürümünü Seç ekranından hesap bazında değiştirebilirsiniz. Geçici çözüm, yedeğin geldiği sürüme dönmektir; kalıcı çözüm, uygulamayı ve eklentileri güncelleyip yeni sürüme taşımaktır. İkisinin arasındaki geçişi nasıl yöneteceğinizi php sürümü yükseltince site bozuldu yazısında adım adım anlattık.

Aynı ekranda eklentileri de kontrol edin. Yedek imagick, soap, intl veya zip eklentisi kurulu bir sunucudan geldiyse ve yeni sunucuda bunlar kapalıysa, uygulamanın o özelliği kullandığı her sayfa ölümcül hata verir — ana sayfa açılırken yönetim paneli açılmaz gibi tuhaf bir tablo çıkar.

.htaccess, Yönlendirme Döngüsü ve 500 Hatası#

500 hatası alıyorsanız ilk şüpheli .htaccess dosyasıdır. Yedek Apache çalıştıran bir sunucudan geldi ama yeni sunucu farklı modüllerle yapılandırılmışsa, dosyadaki bir direktif tanınmaz ve tüm istek 500'e düşer.

Test yöntemi basittir: dosyayı geçici olarak devre dışı bırakın.

mv .htaccess htaccess.yedek

Site açılıyorsa suçlu bulunmuştur. Şimdi temiz bir dosyayla başlayın; WordPress için standart blok şudur:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Eski dosyadaki özel kuralları tek tek geri ekleyip her eklemede siteyi test edin. Sonsuz yönlendirme (ERR_TOO_MANY_REDIRECTS) görüyorsanız, genelde iki kural birbiriyle çakışıyordur: biri HTTP'yi HTTPS'e yolluyordur, diğeri www ile www olmayanı sürekli birbirine çeviriyordur. Ayrıntı için htaccess yönlendirme yazısına bakın.

Sunucu nginx çalıştırıyorsa .htaccess hiç okunmaz; kurallar sunucu yapılandırmasında olmalıdır. Yedeği paylaşımlı hostingten VDS'e taşıdıysanız bu ayrımı bilmemek, saatlerce boşuna .htaccess kurcalamanıza neden olur.

Kısmi Geri Yükleme Tuzağı: Dosya Var, Veritabanı Yok#

Panelden "Geri Yükle" düğmesine basmak her zaman her şeyi geri yüklemez. cPanel'in yedek arayüzünde ana dizin yedeği, veritabanı yedeği ve e-posta yedeği ayrı ayrı geri yüklenir. Yalnızca dosyaları geri yükleyip veritabanını atlarsanız, tarayıcıda gördüğünüz şey "yeni dosyalar + eski veritabanı" karışımıdır ve bu, tamamen bozuk bir siteden daha kötüdür çünkü hata vermez, sadece yanlış davranır.

Aynı tuzak ters yönde de kurulur: veritabanı geri yüklenir ama wp-content/uploads klasörü eski hâlinde kalır; içerik listelenir, görseller kırık çıkar.

Doğrulama için üç şeyi karşılaştırın:

Üç değer birbirini tutmuyorsa geri yükleme kısmidir; eksik parçayı ayrıca geri yükleyin. Panelden yedek almanın ve geri yüklemenin tam akışı için cPanel yedekleme yazısı sırayı gösteriyor.

Belirtiye Göre Hızlı Tanı Tablosu#

Aşağıdaki tablo, geri yükleme sonrası gelen taleplerin büyük kısmını kapsıyor. Belirtiden başlayıp doğrudan doğru yere gidin.

Geri Yüklemeyi Bir Dahaki Sefere Doğru Yapmak#

Yukarıdaki hataların çoğu, geri yükleme sırasını değiştirerek baştan önlenebilir. Yıllardır işe yarayan sıra şudur:

1. Önce mevcut durumu yedekleyin. Bozuk da olsa, geri yüklemeden önceki hâli bir kenara alın. Geri yükleme tek yönlü bir kapıdır; ikinci denemeniz olmayabilir.
2. Yedeği canlıya değil, ara bir adrese açın. Alt alan adı ya da geçici test adresi kullanın, alan adına dokunmayın. Böylece site açılmasa bile ziyaretçi bunu görmez.
3. Dosya ve veritabanını birlikte geri yükleyin. İkisi aynı ana ait olmalı. Farklı zamanlardan gelen dosya ve veritabanı en zor teşhis edilen bozukluğu üretir.
4. Bağlantı bilgilerini geri yüklemeden sonra düzeltin. wp-config.php içindeki üç değeri (ad, kullanıcı, şifre) yeni sunucuya göre yazın.
5. Adres kayıtlarını WP-CLI ile düzeltin. Metin bazlı değiştirme yapmayın.
6. İzin ve sahipliği baştan uygulayın. 755/644, wp-config.php için 600.
7. PHP sürümünü yedeğin geldiği sürüme çekin, sonra kademeli yükseltin.
8. Test edin, sonra alan adını yönlendirin. hosts dosyası ile site test etme bunun için vardır.

Bu sıra dışında bir konu daha var ve genelde geç fark ediliyor: yedeğin kendisinin düzenli olarak test edilmesi. Hiç geri yüklenmemiş bir yedek, yedek değildir — sadece bir dosyadır. Yılda birkaç kez, canlıya dokunmadan bir test ortamına açıp gerçekten açılıp açılmadığını görün. Ne sıklıkta ve hangi kapsamda yedek tutmanız gerektiğini ne sıklıkta yedek alınmalı yazısında ayrıntılandırdık.

Sıkça Sorulan Sorular#

Yedeği geri yükledim, site beyaz ekran veriyor, ilk ne yapmalıyım#

İlk yapılacak şey PHP hata kaydını açmaktır, çünkü beyaz ekran "hata yok" değil "hata gizli" demektir. WordPress'te wp-config.php içine WP_DEBUG ve WP_DEBUG_LOG satırlarını ekleyip WP_DEBUG_DISPLAY değerini kapalı bırakın; sayfayı yenileyin ve wp-content/debug.log dosyasını okuyun. Orada göreceğiniz tek satır, eksik PHP eklentisi mi, bellek limiti mi, sürüm uyumsuzluğu mu olduğunu doğrudan söyler. Hata kaydını okumadan eklenti silmek veya dosya değiştirmek durumu genellikle kötüleştirir.

Geri yükleme sonrası veritabanı bağlantı hatası neden çıkıyor#

Bu hata neredeyse her zaman yapılandırma dosyasındaki veritabanı adı, kullanıcı adı veya şifrenin yeni sunucuda geçerli olmamasından kaynaklanır. Paylaşımlı hostingte veritabanı ve kullanıcı adları hesap ön ekiyle oluşturulur ve bu ön ek sunucu değiştiğinde değişir, dolayısıyla yedekten gelen eski değerler artık hiçbir şeye karşılık gelmez. Yeni veritabanını ve kullanıcıyı oluşturduktan sonra kullanıcıyı veritabanına atamayı ve tüm yetkileri vermeyi unutmayın. Bağlantıyı uygulamadan bağımsız olarak komut satırından mysql ile test etmek, sorunun yapılandırmada mı yetkilerde mi olduğunu tek adımda ayırır.

Yedekten döndükten sonra site eski alan adına yönlendiriyor, nasıl düzeltirim#

Veritabanının içindeki site adresi kayıtları hâlâ eski alan adını gösteriyordur. WordPress'te bu değerler wp_options tablosundaki siteurl ve home satırlarıdır; ikisini yeni adresle güncellemeniz gerekir. Ancak yalnızca bu iki satırı düzeltmek yetmez, çünkü içerik ve ayarların içine de eski adres gömülüdür. Bunları düzeltmek için .sql dosyasında düz metin arama-değiştirme yapmayın; serialize edilmiş ayarların uzunluk bilgisi bozulur ve tema ayarlarınız kaybolur. WP-CLI'nin search-replace komutunu önce --dry-run ile çalıştırın.

Geri yüklenen dosyalar 403 hatası veriyor, sebebi ne#

Dosyaların sahibi ya da izinleri yanlıştır. Arşiv root kullanıcısıyla açıldığında veya sahiplik bilgisi korunarak çıkarıldığında dosyalar hesabınıza ait olmaz ve web sunucusu onları okuyamaz. ls -la çıktısında kullanıcı adınız yerine root veya sayısal bir kimlik görüyorsanız durum budur. Root erişiminiz varsa chown -R kullanici:kullanici ile sahipliği düzeltip dizinlere 755, dosyalara 644 verin. Sorunu 777 vererek çözmeye çalışmayın; çoğu sunucu yapılandırması 777 izinli dizinlerde PHP çalıştırmayı zaten reddeder.

Yedek eski PHP sürümünden geldiyse ne olur#

Uygulama açılmaz ve genellikle sözdizimi hatası veya "undefined function" hatası verir. PHP sürümleri arasında kaldırılan fonksiyonlar ve değişen sözdizimi kuralları vardır; eski sürümde sorunsuz çalışan bir eklenti yeni sürümde ölümcül hata üretebilir. Doğru yaklaşım, önce hesabın PHP sürümünü yedeğin geldiği sürüme çekip siteyi ayağa kaldırmak, sonra uygulamayı ve eklentileri güncelleyerek kademeli olarak yeni sürüme geçmektir. Aynı ekranda imagick, intl, soap gibi eklentilerin de açık olduğunu doğrulayın; eksik bir eklenti sitenin sadece bir bölümünü bozar ve teşhisi zorlaştırır.

Dosyalar geri geldi ama görseller kırık görünüyor, nedeni nedir#

İki olasılık var: ya yükleme klasörü geri yüklenmemiştir, ya da görsel yolları hâlâ eski alan adını gösteriyordur. İlkini du -sh wp-content/uploads çıktısının beklediğiniz boyutta olup olmadığına bakarak anlarsınız; klasör boş ya da çok küçükse geri yükleme kısmi kalmıştır. İkincisini kırık bir görsele sağ tıklayıp adresini incelemek doğrular; adres eski alan adını içeriyorsa arama-değiştirme adımı eksiktir. Kısmi geri yükleme, panelde dosya ve veritabanının ayrı ayrı geri yüklenmesi gerektiği için sık yaşanır.

Geri yüklemeyi geri alabilir miyim#

Yalnızca geri yüklemeden önce mevcut durumun bir yedeğini aldıysanız geri alabilirsiniz. Geri yükleme işlemi hedef dizindeki ve veritabanındaki verinin üzerine yazar; panelin "geri al" düğmesi yoktur. Bu yüzden bozuk bir siteyi bile geri yüklemeden önce yedeklemek, tavsiye değil kuraldır. Ayrıca hosting sağlayıcısının sunucu tarafında tuttuğu otomatik yedekler olabilir; kendi yedeğinizle iş bozulduysa destek üzerinden o kopyayı isteyebilirsiniz.

Yedeğin sağlam olduğunu geri yüklemeden nasıl anlarım#

Arşivi açıp içeriğini listelemek ve veritabanı dökümünün son satırını okumak iki hızlı kontroldür. tar -tzf yedek.tar.gz | head komutu arşivin okunabilir olduğunu ve beklediğiniz dizin yapısını içerdiğini gösterir. Veritabanı dökümünde ise dosyanın sonunda tamamlanma satırının bulunması, dökümün yarıda kesilmediğini kanıtlar; yarım kalmış dökümlerde bu satır olmaz. Yine de kesin doğrulama, yedeği canlıya dokunmayan bir test adresine açıp gerçekten çalıştığını görmektir.

Kapanış#

Geri yükleme sonrası açılmayan bir sitenin arkasında neredeyse her zaman ortam farkı vardır: veritabanındaki adres kayıtları, dosya sahipliği ve izinler, PHP sürümü ve eklentileri, .htaccess uyumu. Belirtiden nedene giden sırayı takip ederseniz — önce HTTP durum kodunu okuyun, sonra hata kaydını açın, sonra veritabanı bağlantısını uygulamadan bağımsız test edin — vakaların büyük çoğunluğu yarım saat içinde kapanır. Kör deneme yapmak yerine tek bir hata satırını okumak, bu işte en çok zaman kazandıran alışkanlıktır.

Bu döngüyü hiç yaşamamanın yolu, yedeğin alınma ve geri yüklenme sürecini kendi kendine işleyen bir düzene bağlamaktır. Yedeklerin sunucu dışında, düzenli ve test edilmiş biçimde tutulmasını devretmek istiyorsanız yedekleme hizmetimiz bu işi üstlenir. Siteyi başka bir sunucuya taşırken bu yazıdaki hataların hiçbirini yaşamak istemiyorsanız site taşıma hizmetiyle aktarımı biz yapabiliriz. WordPress tarafında sürüm, eklenti ve izin bakımını düzenli olarak yürütmek için WordPress bakım paketine, sunucu tarafındaki yapılandırma ve izin işlerini devretmek içinse sunucu yönetimi hizmetine bakabilirsiniz.