WordPress Güncelleme Sonrası Site Bozulduysa Ne Yapılmalı? (Kurtarma Rehberi)

WordPress çekirdek, tema veya eklenti güncellemelerinin ardından web sitesinin erişilemez hale gelmesi ya da görsel olarak bozulması, sistem bileşenleri arasındaki kod uyumsuzluklarından kaynaklanır. Kontrolsüz yapılan art arda müdahaleler veri kaybı riskini artırabilir. Doğru ve metodik adımlar izlendiğinde, bozulmuş bir WordPress sitesi hiçbir veri kaybı yaşanmadan eski kararlı haline getirilebilir.

Bu rehber, güncellemeler sonrası karşılaşılan kritik hataların kaynaklarını tespit etme, yönetici paneline erişim olmadan sistemi ayağa kaldırma ve gelecekteki arızaları önleyici altyapı adımlarını kapsar.

Güncelleme Sonrası Sık Karşılaşılan Hatalar ve Nedenleri

WordPress ekosisteminde çekirdek yazılım, eklentiler, aktif tema ve sunucu altyapısı (PHP/MySQL) birbiriyle bağımlı çalışır. Bileşenlerden birinin güncellenmesi, güncellenmeyen diğer yapıda çakışmalara (conflict) yol açar.

Doğrudan Tema Müdahaleleri ve Kod Kayıpları

Ana temanın (parent theme) functions.php veya style.css dosyalarına doğrudan eklenen özel kodlar, tema güncellendiğinde yeni dosyalarla ezilerek silinir. Bu tür özelleştirmelerin korunması için güncellemeden bağımsız çalışan bir Alt Tema (Child Theme) kullanımı zorunludur.

PHP Sürüm Uyumsuzlukları

Güncellenen modern bir eklenti, sunucunuzda çalışan eski bir PHP sürümünü desteklemeyebilir. WordPress.org standartlarına göre sunucularda en az PHP 8.2 veya PHP 8.3 çalıştırılması önerilir. Süresi dolmuş PHP 7.4 gibi sürümler hem güvenlik açığı yaratır hem de yeni eklenti yapılarıyla fatal hataya sebep olur.

İlk 10 Dakikada Uygulanacak Acil Durum Protokolü

Kriz anında panikle işlem yapmak yerine durumu izole etmek gerekir:

1. Zamanı ve Değişikliği Kaydedin: Hangi bileşenin saat kaçta güncellendiğini listeleyin. Otomatik bildirim e-postalarını kontrol edin.

2. Sorunun Kapsamını Belirleyin: Hata tüm sitede mi, sadece yönetim panelinde mi yoksa tek bir sayfada mı mevcut?

3. Önbellek Etkisini Eleyin: Siteyi gizli sekmeden veya farklı bir ağ bağlantısı üzerinden kontrol ederek yerel önbellek durumunu doğrulayın.

4. Mevcut Durumun Yedeğini Alın: Hatalı da olsa sitenin dosyalarını ve veritabanını o anki haliyle dışa aktarın.

5. Geçmiş Yedeği Kontrol Edin: Hosting panelinizde (cPanel/Plesk) güncelleme öncesine ait otomatik yedek bulunup bulunmadığını teyit edin.

6. Müdahaleleri Durdurun: Rastgele eklenti silme veya yeniden güncelleme denemelerini askıya alın.

Bakım Modu Takılması: .maintenance Dosyasını Silme

WordPress, güncelleme esnasında kök dizine geçici bir .maintenance dosyası oluşturur. İşlem internet kesintisi veya zaman aşımı nedeniyle yarıda kalırsa bu dosya silinemez ve ziyaretçiler “Briefly unavailable for scheduled maintenance. Please check back in a minute.” uyarısı ile karşılaşır.

.maintenance Dosyası Nasıl Silinir?

1. FTP (FileZilla vb.) veya Hosting Dosya Yöneticisi ile sunucuya bağlanın.

2. wp-config.php dosyasının bulunduğu ana dizine (public_html veya httpdocs) gidin.

3. Dosya yöneticisinde “Gizli Dosyaları Göster” seçeneğini aktif hale getirin.

4. Kök dizindeki .maintenance dosyasını bulun ve silin.

Önemli: Dosya silindikten sonra site açılır ancak yarıda kalan güncelleme tamamlanmış sayılmaz. Yönetim panelinden ilgili güncellemenin yeniden başlatılması gerekir.

Yönetim Paneline Erişilemiyorsa Eklentileri Devre Dışı Bırakma

Hata nedeniyle /wp-admin paneline girilemiyorsa, eklentiler FTP veya cPanel üzerinden dosya adı değiştirilerek pasife çekilebilir. WordPress, klasör adı eşleşmeyen eklentileri otomatik olarak devre dışı bırakır.

FTP/Dosya Yöneticisi Adımları

• Tekil Eklenti Pasifleştirme: wp-content/plugins/ dizinine gidin. Şüphelendiğiniz eklenti klasörünün adını değiştirin (Örn: elementor -> elementor-pasif).

• Tüm Eklentileri Aynı Anda Kapatma: Doğrudan wp-content/plugins klasörünün adını plugins_old yapın.

• Tema Değiştirme: Etkin temanın klasör adını değiştirdiğinizde WordPress otomatik olarak varsayılan bir temaya (Twenty Twenty-Four vb.) geçiş yapar.

Siteye erişim sağlandıktan sonra klasör isimleri eski haline getirilir ve eklentiler panel üzerinden tek tek açılarak hataya neden olan spesifik modül tespit edilir.

Hata Kaynağını WP_DEBUG ile Tespit Etme

Ekrandaki genel hata mesajları sorunun kaynağını göstermez. Tam hatayı ve hataya yol açan dosya yolunu görmek için WordPress hata günlüğünü (debug log) aktifleştirmek gerekir.

wp-config.php dosyasında yer alan define('WP_DEBUG', false); satırını bularak aşağıdaki kod bloğu ile değiştirin:

// WordPress Hata Hata Ayıklama Modu
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Bu ayar sonrasında oluşan tüm PHP hataları wp-content/debug.log dosyasına yazılır. Log dosyasındaki /wp-content/plugins/eklenti-adi/... hatası, hangi eklentinin çökme yarattığını kesin olarak gösterir.

WordPress Sürüm Geri Alma (Rollback) Stratejileri

Sorun çıkaran bileşeni eski sürümüne döndürmek için iki temel yaklaşım bulunur:

                  ┌────────────────────────────────────────┐
                  │ WordPress Güncelleme Arızası Tespit Edildi │
                  └──────────────────┬─────────────────────┘
                                     │
                     ┌───────────────┴───────────────┐
                     ▼                               ▼
        [Eklenti / Tema Kaynaklı]          [Sistem Geneli / Çekirdek]
                     │                               │
                     ▼                               ▼
       • Eklenti Eski Sürümünü Yükle    • Tam Sistem Yedeğini Geri Yükle
       • Sürüm Düşürme Eklentisi Kullan  • Dosya ve Veritabanı Senkronize Et

1. Eklentiyi Önceki Sürüme Döndürme

WordPress.org üzerindeki eklenti sayfasında yer alan “Gelişmiş Görünüm” (Advanced View) bölümünden eklentinin eski stabil sürümlerine ait .zip dosyaları indirilebilir. İndirilen eski sürüm, mevcut eklentinin üzerine kurulabilir.

2. Tam Sistem Yedeğinden Dönüş

Tüm siteyi kapsayan bozulmalarda en güvenli yol veritabanı ve dosya yapısını birlikte yedekten geri yüklemektir. Sadece dosyaları yükleyip veritabanını eski bırakmak veri tutarsızlıklarına ve uyum hatalarına yol açabilir.

Önbellek ve Sayfa Oluşturucu (Elementor) Bozulmalarını Çözme

Kod hatası olmadığı halde sayfa yapısı kayıyorsa sorun genellikle CSS/JS önbellek katmanlarındaki uyuşmazlıktır. Güncelleme sonrası sıralı temizlik yapılmalıdır:

1. Sayfa Oluşturucu CSS Senkronizasyonu: Elementor kullanılıyorsa, Elementor > Araçlar > Dosya ve Verileri Yeniden Oluştur (Regenerate Files & Data) adımı uygulanmalıdır.

2. Önbellek Eklentileri: LiteSpeed Cache, WP Rocket veya WP Super Cache üzerindeki tüm önbellek birikimi temizlenmelidir.

3. Sunucu ve CDN Önbelleği: Cloudflare veya sunucu tarafındaki (Varnish/Nginx) önbellek boşaltılmalıdır.

4. Tarayıcı Önbelleği: Ctrl + F5 veya gizli sekme üzerinden kontrol edilmelidir.

Canlı Sütun Güncellemesi vs. Staging (Hazırlık) Testi

Güncellemeleri doğrudan çalışan canlı sitede yapmak kesinti ve veri kaybı riskini yükseltir. Profesyonel altyapılarda değişiklikler öncelikle test ortamında denenir.

Güvenli Güncelleme Yönetimi ve Kontrol Listesi

Sistemik arızaları önlemek için güncellemeler öncesinde standart bir kontrol prosedürü uygulanmalıdır.

Güncelleme Öncesi Kontrol Listesi

• [ ] Tam site yedeği (Dosyalar + Veritabanı) alındı mı?

• [ ] Güncellenecek eklentilerin sürüm notları (Changelog) okundu mu?

• [ ] Eklentilerin gerektirdiği minimum PHP sürümü ile sunucu PHP sürümü uyuşuyor mu?

• [ ] Ana temada doğrudan kod değişikliği olup olmadığı doğrulandı mı? (Alt tema kontrolü)

• [ ] Güncelleme zamanlaması trafiğin en düşük olduğu saate planlandı mı?

• [ ] Toplu güncelleme yerine gruplar halinde (önce yardımcı eklentiler, sonra ana eklentiler) ilerleniyor mu?

Sık Yapılan Hatalar ve Doğru Yaklaşımlar

• Hata: Sorun çıkaran eklentiyi hemen panellerden tamamen silmek.

  Doğru Yaklaşım: Eklentiyi silmek veritabanındaki yapılandırma ayarlarını da silebilir. Önce sadece pasife çekilmelidir.

• Hata: Güvenilmeyen üçüncü taraf sitelerden eski sürüm .zip dosyası indirmek.

  Doğru Yaklaşım: Sürüm düşürme işlemlerinde yalnızca resmi WordPress.org dizini veya geliştiricinin kendi doğrulandığı kaynaklar kullanılmalıdır.

• Hata: Güvenlik kaygısıyla tüm otomatik güncellemeleri kapatıp sistemi takipsiz bırakmak.

  Doğru Yaklaşım: Çekirdek güvenlik güncellemeleri açık tutulmalı, kritik işlevsel eklentiler ise manuel ve kontrollü şekilde güncellenmelidir.

Ne Zaman Profesyonel Destek Alınmalı?

Aşağıdaki durumlarda müdahalenin uzman ekiplerce yapılması veri kaybını engeller:

1. Güncelleme öncesine ait çalışan bir yedek bulunmuyorsa,

2. WooCommerce veya üyelik altyapılı sitelerde anlık veri akışı varken sistem çöktüyse,

3. WP_DEBUG_LOG dosyası okunarak hatanın kaynağı izole edilemiyorsa,

4. PHP sürüm yükseltme sonrası çok sayıda eklenti zincirleme hata veriyorsa.

Sistemik çökme durumlarında bilinçsiz müdahaleler yerine veri tabanı bütünlüğünü koruyacak izole kurtarma senaryolarının uygulanması gerekir.