WordPress Güncelleme Sonrası Site Bozuldu: İlk 10 Dakikada Yapılacaklar ve Geri Alma

WordPress Bakım Modunda Kaldı: .maintenance Dosyası Nasıl Silinir?

WordPress bakım modunda kaldı ise sitenin kök dizinindeki .maintenance dosyası silinerek mesaj kaldırılır. WordPress güncelleme sırasında bu dosyayı oluşturur ve ziyaretçilere “Briefly unavailable for scheduled maintenance. Please check back in a minute.” mesajını gösterir; güncelleme düzgün biterse dosya kendiliğinden kalkar. WordPress belgeleri, mesaj güncellemeden sonra da duruyorsa FTP ile bağlanıp .maintenance dosyasının silinmesini önerir.

Dosya, wp-config.php ile aynı klasörde bulunur ve adı nokta ile başladığı için bazı dosya yöneticilerinde gizli görünür. Hosting panelinin dosya yöneticisinde “gizli dosyaları göster” seçeneği açılmadan dosya listede çıkmayabilir.

Dosya silindikten sonra mesaj kalkar ama yarım kalan güncelleme tamamlanmış olmaz. Panelde ilgili eklentinin veya çekirdeğin sürümü kontrol edilir; güncelleme yarım kaldıysa yeniden çalıştırılır. Aynı mesaj her güncellemede tekrarlıyorsa sunucu bağlantısı, zaman aşımı ya da dosya izinleri ayrıca incelenir.

Eklenti Güncellemesi Siteyi Bozdu: Panele Girmeden Nasıl Devre Dışı Bırakılır?

Panele girilemiyorsa eklenti, FTP veya hosting dosya yöneticisiyle klasör adı değiştirilerek devre dışı bırakılır. WordPress, klasör adını bulamadığı eklentiyi yüklemez; dosyalar silinmediği için ayarlar da yerinde kalır.

WordPress belgelerindeki iki yol şöyledir:

• Tek eklenti: wp-content/plugins altındaki şüpheli eklentinin klasör adı değiştirilir (örneğin sonuna “-kapali” eklenir).
• Tüm eklentiler: wp-content/plugins klasörünün adı plugins_old yapılır; bu işlem tüm eklentileri aynı anda devre dışı bırakır.
• Tema: wp-content/themes altındaki etkin temanın klasör adı değiştirilir; WordPress uygun bir varsayılan temaya döner.

Tüm eklentiler kapatıldıysa site açıldıktan sonra klasörün eski adı geri verilir ve eklentiler panelden tek tek etkinleştirilir. Siteyi yeniden bozan eklenti, suçlu eklentidir. Sayfa oluşturucu kapatıldığında sayfaların düz metin görünmesi normaldir; eklenti açıldığında tasarım geri gelir.

WordPress Güncellemeyi Geri Alma: Yedekten Dönüş mü, Önceki Sürüm mü?

WordPress güncellemeyi geri alma için iki yol vardır: güncelleme öncesi alınan yedeğe tam dönüş ya da yalnızca sorunlu eklentinin önceki sürümünün yüklenmesi. Hangisinin seçileceği, bozulmanın kaç bileşeni etkilediğine ve yedeğin ne kadar güncel olduğuna bağlıdır.

Yedekten dönüş

WordPress’in yedekleme belgesi, sitenin dosyalar ve veritabanı olmak üzere iki parçadan oluştuğunu, ikisinin de yedeklenmesi gerektiğini ve her yükseltmeden önce yedek alınmasını önerir. Geri yüklemede önce dosyalar, ardından veritabanı yüklenir. Yedekten sonra eklenen sipariş, form kaydı ve yazılar yedeğe dönüldüğünde kaybolabilir; e-ticaret sitelerinde bu ayrıca hesaba katılır. Yedeğin nasıl alınacağı ve nerede saklanacağı WordPress yedekleme rehberinde anlatılır.

Eklentinin önceki sürümü

WordPress.org eklenti dizinindeki bir eklentinin sayfasında, yan kutunun altındaki “Gelişmiş görünüm” bağlantısı açılır. “Gelişmiş seçenekler” başlığı altındaki “Önceki sürümler” kısmında sürüm seçilip indirilebilir. Dizin bu alan için açık bir uyarı da gösterir: önceki sürümler güvenli veya kararlı olmayabilir ve yayındaki sitelerde kullanılması tavsiye edilmez. Eski sürüm geçici bir köprüdür; eklenti geliştiricisi düzeltme yayımladığında güncel sürüme geçilir.

Çekirdek için durum farklıdır: WordPress’in yükseltme belgesi, çekirdeği eski sürüme döndürmenin güvenlik riskleri ve veritabanı sorunları nedeniyle genellikle önerilmediğini yazar. Zorunlu kalınırsa wp-config.php dışındaki WordPress dosyaları silinir, yedek dosyalar ve veritabanı yedeği geri yüklenir.

Tasarım Kaydıysa: Elementor ve Önbellek Nasıl Temizlenir?

Site açılıyor ama tasarım bozuk görünüyorsa sorun çoğu zaman koddan değil, eski stil dosyalarının önbellekte kalmasından kaynaklanır. Bu durumda geri alma yapılmadan önce önbellek katmanları sırayla temizlenir.

Elementor kullanılan sitelerde Elementor › Araçlar ekranındaki “Clear Files & Data” (eski sürümlerde “Regenerate CSS & Data”) düğmesi stil dosyalarını yeniden oluşturur. Ardından şu katmanlar kontrol edilir:

• Önbellek eklentisinin (LiteSpeed Cache, WP Rocket vb.) tüm önbelleği temizleme seçeneği
• Hosting firmasının sunucu önbelleği
• Kullanılıyorsa Cloudflare gibi bir CDN’in önbelleği
• CSS ve JavaScript birleştirme/küçültme ayarları; güncellemeden sonra bu ayarlar geçici olarak kapatılıp denenir
• Tarayıcı önbelleği; gizli pencere bu katmanı devre dışı bırakır

Temizlikten sonra tasarım düzeliyorsa kalıcı bir hata yoktur. Düzelmiyorsa sayfa oluşturucunun ya da onunla birlikte çalışan eklentilerin sürüm uyumu incelenir.

Rastgele Güncelleme mi, Hazırlık Ortamında Test mi?

Güncellemenin canlı sitede değil, sitenin bir kopyası olan hazırlık (staging) ortamında denenmesi, bozulmayı ziyaretçi görmeden yakalar. Birçok hosting firması panelinden tek tıkla hazırlık kopyası oluşturma imkânı sunar; WordPress 5.5 ile gelen WP_ENVIRONMENT_TYPE ayarı da bir kurulumun “staging” olarak işaretlenmesini sağlar.

Hazırlık ortamında sorun çıkmayan güncelleme canlıya aynı sırayla uygulanır. Kopyanın arama motorlarına kapalı tutulması ve canlı siteyle karışmaması için adresinin ayrı olması gerekir.

Otomatik Güncellemeler Nasıl Yönetilir?

Otomatik güncellemeler tamamen kapatılmak yerine bileşen bazında yönetilir: güvenlik açısından kritik ve sorunsuz eklentiler açık bırakılır, siteyi derinden etkileyenler elle ve testle güncellenir. WordPress’in eklenti ve tema otomatik güncelleme belgesine göre bu ayar WordPress 5.5’ten beri eklenti ekranındaki “Automatic update” sütunundan ve tema penceresindeki bağlantıdan tek tek açılıp kapatılabilir.

Aynı belgeye göre WordPress otomatik güncellemeleri varsayılan olarak günde iki kez çalıştırır ve başarılı ya da başarısız denemeler için yöneticiye e-posta gönderir. Çekirdek tarafında yükseltme belgesi, WordPress 5.6’dan sonraki yeni kurulumlarda küçük ve büyük çekirdek sürümlerinin varsayılan olarak otomatik güncellendiğini yazar. wp-config.php’deki WP_AUTO_UPDATE_CORE sabiti ‘minor’ değeriyle yalnızca küçük sürümlere izin verecek şekilde ayarlanabilir.

WordPress 6.6 ile gelen bir koruma da bilinmelidir. Çekirdek ekibinin geri alma duyurusuna göre bir eklentinin otomatik güncellemesi ana sayfada PHP ölümcül hatasına yol açarsa önceki sürüm geri yüklenir ve yöneticiye e-posta gider. Bu koruma yalnızca eklentilerin otomatik güncellemesini kapsar; tasarım kaymasını ya da ölümcül hata üretmeyen bozulmaları yakalamaz.

Güncelleme Öncesi Kontrol Listesi

Güncelleme kaynaklı arızaların büyük kısmı, güncellemeden önce birkaç dakikalık kontrolle önlenebilir. Bakım sürecimizde her güncelleme turundan önce şu liste izlenir:

1. Dosyalar ve veritabanı yedeklenir, yedeğin açılabildiği kontrol edilir.
2. Güncellenecek eklentilerin sürüm notları okunur; büyük sürüm atlamaları ayrıca işaretlenir.
3. Eklenti sayfalarındaki “Tested up to” ve “PHP version” bilgisi sunucudaki sürümlerle karşılaştırılır.
4. Ana temada doğrudan kod değişikliği olup olmadığına bakılır; varsa alt temaya taşınır.
5. Güncellemeler mümkünse hazırlık ortamında, değilse ziyaretin düşük olduğu saatte yapılır.
6. Güncellemeler toplu değil, gruplar halinde yapılır; her gruptan sonra site kontrol edilir.
7. Ana sayfa, iletişim formu, sepet ve ödeme gibi kritik sayfalar test edilir.
8. Önbellek temizlenir ve sonuç gizli pencerede yeniden kontrol edilir.

Yükseltme belgesi, çekirdek elle yükseltilirken eklentilerin önceden devre dışı bırakılmasını da önerir. Panelden yapılan olağan güncellemelerde bu adım şart değildir; asıl koruma, yedek ve aşamalı ilerlemedir.

Arıza anında sık yapılan hatalar ve doğru yöntem

Güncelleme arızasında en çok zarar, sorunu çözmek için yapılan aceleci müdahalelerden gelir. Sık görülen hatalar ve doğru karşılıkları şöyledir:

• Eklentiyi panelden silmek: Silme işlemi bazı eklentilerde ayarları da kaldırır; doğru yol, önce devre dışı bırakmak ya da klasör adını değiştirmektir.
• Yedeksiz geri alma denemesi: Bozuk hal yedeklenmeden yapılan her deneme, geri dönülecek noktayı ortadan kaldırır.
• Bilinmeyen sitelerden eski sürüm indirmek: Önceki sürüm yalnızca eklentinin resmi sayfasından veya geliştiricinin hesabından alınır; değiştirilmiş dosyalar zararlı kod taşıyabilir.
• Otomatik güncellemeleri tamamen kapatıp unutmak: Güncellenmeyen eklentiler zamanla güvenlik açığına dönüşür.
• Hepsini aynı anda güncellemek: Sorun çıktığında hangi güncellemenin sorumlu olduğu anlaşılamaz.

Güncellemeden sonra sitede tanınmayan yönlendirmeler, yeni yönetici hesapları ya da garip dosyalar görülüyorsa sorun uyumsuzluk değil, güvenlik ihlali olabilir. Bu durumda geri alma yerine hacklenmiş site kurtarma süreci gerekir.

WordPress Güncelleme Sonrası Site Bozulduysa Ne Zaman Uzmana Başvurulmalı?

Güncellemeden sonra bozulan sitede sorun 30 dakika içinde tek bir eklenti veya önbellek temizliğiyle çözülmüyorsa uzman desteği zaman kazandırır. Özellikle şu durumlarda müdahale sistemli yürütülmelidir: güncel yedek yoksa, e-ticaret sitesinde sipariş akışı durduysa, hata günlüğü okunamıyorsa ya da sorun PHP sürümü değişikliğiyle birlikte çıktıysa.

Tek seferlik arızalarda WordPress problem çözme hizmetiyle sorun teşhis edilip giderilir. Güncellemelerin düzenli, yedekli ve testli yapılması isteniyorsa yıllık WordPress bakım ve güncelleme hizmeti bu işi sürekli hale getirir. WordPress bakım hizmeti, sitenin büyüklüğüne ve kapsamına göre aylık 500–2.000 TL arasındadır.

Bakım düzeninde her güncelleme turu öncesinde yedek alınır, sonrasında kritik sayfalar kontrol edilir ve yapılan işlemler kayıt altına alınır. Böylece bir sonraki arızada hangi güncellemenin ne zaman yapıldığı tahmin edilmez, kayıttan okunur.