Bir güncelleme sonrası bozulan sitede elinizde yalnız yazıları içeren XML dosyası varsa tema, eklenti ve yüklenen görseller eksik kalabilir. Tersine, sadece site klasörünü indirdiyseniz yazıların ve ayarların bulunduğu veritabanı elinizde olmayabilir. İki parçayı aynı yedek setinde tutmak bu karışıklığı önler.
Aşağıdaki adımlar kendi hostinginizde çalışan WordPress içindir. WordPress.com kullanıyorsanız geri yükleme, hesabınızdaki plana ve hizmete bağlıdır; WordPress.com'un kendi geri yükleme ekranını izleyin. Barındırma modellerinin ayrımını WordPress temel rehberinde bulabilirsiniz.
WordPress Yedeğinde Neler Bulunmalı?
Tüm sütunlar için tabloyu yana kaydırın. Klavyeyle tabloya odaklanıp ok tuşlarını kullanabilirsiniz.
| Parça | Neyi saklar? | Tek başına neden yetmez? |
|---|---|---|
| Veritabanı yedeği, çoğunlukla SQL | Yazılar, sayfalar, yorumlar, kullanıcı kayıtları ve birçok ayar | Yüklenen görsellerin ve tema dosyalarının kendisi burada bulunmaz. |
| Site dosyaları | WordPress dosyaları, tema, eklenti, uploads ve yapılandırma | Veritabanı genellikle başka yerde tutulur; klasörü indirmek onu indirmek değildir. |
| Kurtarma notu | Tarih, site, sürümler, yedek yöntemi ve geri dönüş adımları | Hangi paketin hangi veritabanıyla eşleştiğini bilmeniz gerekir. |
WordPress'in yedekleme açıklaması dosya ve veritabanını ayrı parçalar olarak ele alır. Örneğin site-2026-10-22 adlı bir yedek klasöründe files.zip, database.sql ve kısa bir kurtarma notu birlikte durabilir. Bunları ziyaretçilerin erişebildiği web klasörüne koymayın; SQL ve yapılandırma dosyaları özel bilgiler içerebilir.
Araçlar → Dışa Aktar Tam Site Yedeği mi?
Hayır. WordPress yönetimindeki Araçlar → Dışa Aktar, içerik taşımaya yarayan WXR/XML dosyası oluşturur. Ekranda “Tüm içerik” yazması, bütün tema ve eklenti dosyalarının da pakete girdiği anlamına gelmez. Medya kayıtları veya adresleri bulunabilir; görsel dosyalarının tamamının yerel kopyası yerine geçmez.
XML dosyasını başka kurulumdaki içe aktarıcıyla kullanabilirsiniz; ancak tam kurtarma için bu ekranın içerik kapsamını dosya ve SQL yedeğinden ayrı düşünün. Tek bir yazının önceki sürümüne dönmek de WordPress revizyonlarının işidir; bütün siteyi geri yüklemek zorunda olmayabilirsiniz.
Hosting, Eklenti veya Elle Yedek: Hangisini Seçmeli?
Tüm sütunlar için tabloyu yana kaydırın. Klavyeyle tabloya odaklanıp ok tuşlarını kullanabilirsiniz.
| Yol | Uygun olduğu durum | Önce sorulacak soru |
|---|---|---|
| Hosting yedeği | Panelden yönetilen, sağlayıcının geri dönüş sunduğu site | Dosya ve veritabanı birlikte mi, kaç gün saklanıyor, indirme ve ayrı ortama geri dönüş var mı? |
| Yedekleme eklentisi | WordPress içinden zamanlama ve başka depoya kopya isteyen site | Tam yedek, uzaktaki depoya gönderim ve geri yükleme seçtiğim sürümde var mı? |
| Dosya + SQL ile elle | Sunucu erişimi olan ve parçaları kendisi yönetecek kullanıcı | Doğru site klasörü ile doğru veritabanını eşleştirdiğimden emin miyim? |
Bir eklentinin ZIP dosyası başka eklentide açılmayabilir; özel uzantılı paketler kendi geri yükleme aracını gerektirebilir. Dosya adını değiştirmek paketi uyumlu hâle getirmez. Sağlayıcının “günlük yedek” ifadesini de ücretsiz veya anında geri yükleme garantisi olarak okumayın. Hosting karşılaştırmasındaki yedek ve geri dönüş ölçütleri satın alma sırasında sorulacak soruları açıklar.
Elle WordPress Yedeği Nasıl Alınır?
- Siteyi ve zamanı belirleyin. Hosting hesabında hangi klasörün hangi siteye ait olduğunu doğrulayın. Büyük güncelleme öncesinde yeni bir yedek alın.
- Değişiklikleri tutarlı bir noktada yakalayın. Dosya kopyalanırken tema değiştirmek veya mağazaya yeni sipariş gelmesi iki parçanın zamanını ayrıştırabilir. Aktif sitelerde sağlayıcının tutarlı yedek yöntemini veya planlanmış bakım aralığını kullanın.
- Dosyaları indirin. Site diziniyle birlikte wp-content, uploads, tema ve eklentileri alın. wp-config.php ve varsa .htaccess gibi gizli dosyaları atlamayın; WordPress dosya listesiyle karşılaştırın.
- Doğru veritabanını dışa aktarın. wp-config.php içindeki veritabanı adını kontrol edin; bilgileri paylaşmayın. phpMyAdmin veya sağlayıcının aracıyla ilgili veritabanının tablolarını SQL olarak alın. Resmî veritabanı yedekleme adımları kullanılan araca göre yolu açıklar.
- İndirme tamamlandı mı bakın. Boş veya yarım dosyayı başarılı yedek saymayın. Arşivin açıldığını, SQL dosyasının bulunduğunu ve tarihlerinin uyduğunu kontrol edin.
- Ayrı kopya saklayın. Hosting hesabı erişilemez olduğunda da ulaşabileceğiniz, erişimi sınırlı başka bir konumda yedek bulundurun.
Geri Yüklemeyi Önce Ayrı Ortamda Deneyin
- Hedefi ayırın. Boş bir test klasörü ve ayrı veritabanı hazırlayın. Testin canlı veritabanına bağlanmadığını doğrulayın. İnternete açık bir staging alanını girişle koruyun; noindex tek başına erişim koruması değildir.
- Dosyaları yerleştirin. Yedek arşivini test dizinine açın. Canlı dizinin üzerine yanlışlıkla yazmadığınızdan emin olun.
- SQL'i boş test veritabanına aktarın. Var olan müşteri verilerinin üzerine içe aktarma yapmayın. Tablo ön eki ile yapılandırmanın eşleştiğini kontrol edin.
- Test bağlantısını ayarlayın. wp-config.php içinde test veritabanını kullanın. Adres değişmişse site adreslerini ve içerikteki eski adresleri serileştirilmiş veriyi koruyan bir yöntemle değiştirin; önce kuru çalıştırma yapın. WP-CLI search-replace belgesi seçenekleri anlatır.
- Dış işlemleri durdurun. Test kopyasının gerçek müşteriye e-posta, ödeme isteği veya webhook göndermesine izin vermeyin. Entegrasyonları test değerleriyle veya kapalı olarak değerlendirin.
- Sonucu içerikten kontrol edin. Ana sayfa açılıyor diye bitirmeyin: bir yazı, bir sayfa, görsel, menü ve ilgili formu ayrı kontrol edin. Test edilen ve edilmemiş işlevleri not alın.
Gerçek Deneme: Ayrı WordPress Kurulumunda Ne Geri Geldi?
22 Ekim 2026'da yerel bilgisayarda WordPress 7.1.3, PHP 8.2.12 ve MariaDB 10.4.32 ile küçük bir test sitesi kuruldu. İki örnek yazı, bir kontrol sayfası, yüklenen bir görsel ve basit bir test teması eklendi. Dosyalar ZIP, veritabanı SQL olarak alındı; ikinci klasöre ve ayrı veritabanına geri yüklendi. WP-CLI ile yalnız bu test kopyasında adres eşlemesi yapıldı.
Sürüm bilgileri denemenin kaydıdır, üretim ortamı önerisi değildir. Yeni hosting seçerken WordPress'in güncel sunucu gereksinimlerini esas alın. Testte canlı site, müşteri verisi veya ödeme hesabı kullanılmadı.
Tüm sütunlar için tabloyu yana kaydırın. Klavyeyle tabloya odaklanıp ok tuşlarını kullanabilirsiniz.
| Kontrol | Sonuç | Neyi kanıtlar? |
|---|---|---|
| İki örnek yazı ve kontrol sayfası | Kayıtlar ve başlıklar geri geldi; yazılar tarayıcıda açıldı. | Örnek içerik bu yedekten okunabiliyor. |
| Yüklenen görsel | SHA-256 dosya özeti aynı; tarayıcıda görüntülendi. | Kontrol edilen dosyanın baytları korundu. |
| Tema dosyası ve etkin tema | Dosya özeti aynı; Restore Lab teması etkin. | Örnek tema geri geldi ve kullanılıyor. |
| Site adı, açıklama ve hedef adresi | Beklenen değerler okundu; adres ayrı test dizinine gidiyor. | Seçilen ayarlar ve ortam ayrımı doğrulandı. |
Bu deneme herhangi bir hosting firmasının kurtarma süresini veya bütün eklentilerin uyumunu ölçmez. Sipariş, abonelik, SMTP ve üçüncü taraf entegrasyonları test edilmedi. Kendi sitenizde bunlar varsa geri dönüş kontrol listesine ayrıca ekleyin.
Geri Yükleme Sonrası Sorun Varsa
- Veritabanına bağlanılamıyor: Test veritabanı adı, kullanıcı yetkisi ve bağlantı ayarlarını kontrol edin; canlı bağlantıya dönerek sorunu örtmeyin.
- Görseller eksik: uploads klasörünü, dosya izinlerini ve görsel URL'sini inceleyin. XML'deki medya adresi dosyanın kendisi değildir.
- Eski siteye yönleniyor: home/siteurl, önbellek ve eski URL kayıtlarını kontrol edin. Serileştirilmiş ayarlarda gelişigüzel metin değiştirmeyin.
- Sayfalar 404 veriyor: Kalıcı bağlantı ve sunucu yönlendirme kurallarını karşılaştırın. Ana sayfanın açılması diğer yolların da çalıştığını göstermez.
- Yeni siparişler kayboldu: Eski veritabanı, yedekten sonra oluşan kayıtları içermeyebilir. Canlı mağazanın tamamını eski noktaya döndürmeden önce bu kayıtların nasıl korunacağını planlayın.
Yedeği Bir Rutine Dönüştürün
İki ayda bir değişen tanıtım sitesiyle gün boyu sipariş alan mağazanın aynı yedek aralığına ihtiyacı yoktur. Önce “en fazla ne kadar yeni veriyi kaybetmeyi göze alabilirim?” sorusunu cevaplayın. Ona göre otomatik sıklık, saklama süresi ve ayrıca güncelleme öncesi kopya belirleyin; zaman zaman ayrı ortamda geri dönüşü tekrarlayın.
Son çalışan yedeğin tarihini, nerede saklandığını ve kimin geri yükleyebildiğini yazılı tutun. Yedek, zayıf parolayı veya güncel olmayan eklentiyi düzeltmez; hesap ve cihaz güvenliği kontrolleriyle birlikte yürütülmelidir.
WordPress sitenizi yenilerken yedek, test ortamı ve yayına geçiş sorumluluklarını da baştan netleştirmek istiyorsanız, web tasarım çalışmasını bu teslim koşullarıyla birlikte planlayabiliriz. Böylece yalnız çalışan bir görünüm değil, sonrasında yönetebileceğiniz bir site teslimi hedefleriz.
