Çoğu WordPress kullanıcısı güncellemeleri erteler, çünkü bir güncellemenin siteyi bozma ihtimali gerçek. Sorun şu ki ertelemenin maliyeti, o riskten çok daha büyük. Bu rehber bir soru cevap listesi değil, uçtan uca bir güncelleme akışı: durum tespitinden yedeğe, uygulamadan doğrulamaya, bir şeyler bozulursa geri dönüşten sonraki güncellemeyi otomatikleştirmeye kadar altı somut adımda ilerliyor, aralarına gerçek bir örnek senaryo da serpiştirdik.
Güncelleme riski sayılarla ne kadar büyük?
WordPress çekirdeği 2026 itibarıyla yılda üç büyük sürüm yayınlıyor, yaklaşık her dört ayda bir; WordPress.org'un kendi proje duyurusuna göre bu takvim, projenin bir yıl boyunca denediği tek büyük sürümlü modelden sonra geri getirildi. Buna eklenti ve tema geliştiricilerinin tamamen bağımsız sürüm takvimleri de ekleniyor. Elli siteli bir portföyde, her sitede on beş aktif eklenti varsa ve her eklenti ayda ortalama bir güncelleme bildirimi gönderiyorsa, haftada yüzlerce bekleyen güncelleme birikmesi sıra dışı bir durum değil, olağan bir durum. Mesele güncellemelerin hızı değil hacmi: elle takip edilebilecek sayının çoktan üstüne çıkılmış oluyor.
Bu hacmin bedelini gösteren rakam Sucuri'nin 2023 Hacked Website & Malware Threat Report raporundan geliyor: incelenen hacklenmiş CMS sitelerinin yüzde 39,1'i, saldırı anında güncel olmayan bir yazılım çalıştırıyordu. Aynı raporda, temizlenen sitelerin yüzde 13,97'sinde müdahale sırasında hâlâ bilinen bir açığı olan bir eklenti ya da tema tespit edildi. Yani güncel olmamak, bir sitenin hacklenmesinin tek nedeni olmasa da saldırganların en kolay bulduğu, en az çaba isteyen giriş noktalarından biri olmaya devam ediyor.
Zaman baskısını gösteren rakam ise Patchstack'in 2026 State of WordPress Security raporundan geliyor: bir güvenlik açığı kamuya duyurulduktan sonra kitlesel istismara kadar geçen ağırlıklı medyan süre sadece beş saat. Patchstack'in canlı takip ettiği CVE-2026-87902 örneğinde, WordPress 7.1.2 yaması yayınlandıktan yaklaşık iki saat sonra saldırganlar siteleri taramaya başlamış, üç saat kırk beş dakika sonra da diske dosya yazmayı denemişler. Bir güncellemeyi bir hafta ertelemek kağıt üzerinde küçük bir gecikme gibi görünse de pratikte istismar penceresinin tamamını açık bırakmak anlamına geliyor.
Adım 1: Güncelleme öncesi durum tespiti
Güncelle düğmesine basmadan önce üç şeye bakın. Birincisi değişiklik notları: eklenti veya temanın güncelleme ekranında ya da geliştiricinin kendi sitesinde yayınlanan sürüm notları, bunun sadece bir hata düzeltmesi mi, yoksa veritabanı yapısını, bir REST API uç noktasını veya bir ayarın varsayılan değerini değiştiren yapısal bir değişiklik mi olduğunu söyler. İkincisi uyumluluk bilgisi: eklentinin "test edildiği son WordPress sürümü" alanı çalıştırdığınız sürümün bir iki adım gerisindeyse, güncellemeyi hemen değil, diğer kullanıcıların destek forumunda bıraktığı ilk geri bildirimleri görecek kadar bekleyip uygulamak daha güvenli.
Üçüncüsü mevcut durumun kaydı: güncellemeden hemen önce hata günlüğüne (error log) bir göz atıp hangi uyarıların zaten orada olduğunu not edin. Bu adımı atlarsanız, güncelleme sonrası günlükte gördüğünüz her satırın güncellemeden mi yoksa önceden var olan bir sorundan mı geldiğini ayırt edemezsiniz ve zamanınızın çoğu yanlış bir sebep aramakla geçer. Son olarak, kurulu ama artık kullanılmayan eklentileri bu aşamada tamamen silin; güncellenmesi gereken fakat hiç kullanılmayan bir eklenti, size hiçbir fayda sağlamadan sadece saldırı yüzeyini büyütür.
Bir de sunucu tarafını unutmayın. Eklentinin gerektirdiği minimum PHP sürümü, sizin hosting paketinizde çalışan PHP sürümünden yüksekse, güncelleme sonrası site beyaz ekran verebilir; bu tür bir uyumsuzluk çoğu zaman eklentiden değil, hosting panelindeki eski bir PHP sürümünden kaynaklanır. Aynı şekilde bellek limiti (memory_limit) düşük bir hosting planında çalışıyorsanız, büyük bir eklenti güncellemesi kurulum sırasında zaman aşımına uğrayabilir. Bu iki bilgiyi, eklentinin gereksinimler sekmesinden ve hosting panelinizin PHP bilgi sayfasından bir dakikada karşılaştırabilirsiniz.
Adım 2: Güncelleme öncesi yedek alın
Durum tespiti bittikten sonra sırada yedek var ve bu adımın güncelleme akışının kendiliğinden çalışan bir parçası olması gerekiyor, hatırlanması gereken ayrı bir görev değil. Yedek iki parçadan oluşmalı: dosyalar (eklenti, tema, yüklenen medya) ve veritabanı (içerik, ayarlar, kullanıcı verisi). Sadece birini almak, güncelleme geri alınamaz hâle geldiğinde eksik bir geri dönüş noktasıyla baş başa kalmak demek.
Yedeği aldıktan sonra tek bir şeyi doğrulayın: yedek dosyası gerçekten oluştu mu, boyutu makul mü, tarihi az önceki işlemle uyuşuyor mu? Bir yedeğin "başlatıldığını" görmek, tamamlandığını görmekle aynı şey değil; yarım kalmış bir yedek dosyası, ihtiyaç anında sizi hiç yedek almamış kadar savunmasız bırakır. Yedeği sunucudan bağımsız bir yerde (offsite) tutmak da bu adımın parçası, çünkü sorun sunucu seviyesinde çıkarsa yedeğin sunucuda kalması hiçbir işe yaramaz.
Adım 3: Güncellemeyi uygulayın
Bekleyen on beş güncellemenin hepsini tek seferde uygulamayın. Sırayı şöyle kurun: önce düşük riskli çekirdek küçük sürüm yamaları (ör. 6.7.1 → 6.7.2), sonra eklentileri tek tek, aralarına birkaç dakika kontrol payı bırakarak; büyük sürüm güncellemelerini (ör. 6.7 → 6.8) ise Adım 1'de zaten okuduğunuz değişiklik notlarıyla birlikte, ayrı ve trafiğin düşük olduğu bir saatte uygulayın. Bu sıralamanın amacı basit: bir şey bozulduğunda, hangi güncellemenin bozduğunu dakikalar içinde bulabilmek. On iki eklentiyi aynı anda güncelleyip sonra sorunu ararsanız, o arama tek başına saatler sürebilir.
Örnek senaryo: bir form eklentisi güncellemesi
Diyelim ki sitenizde kullanılan bir iletişim formu eklentisi güncelleme bildirimi gönderdi. Değişiklik notlarında "form gönderimlerinin işlendiği REST API uç noktası yeniden yapılandırıldı" yazıyor; Adım 1'deki durum tespiti bu notu size gösteriyor ve bunun sıradan bir hata düzeltmesi olmadığını anlıyorsunuz. Adım 2'deki yedeği aldıktan sonra, gece yarısına yakın düşük trafikli bir saatte güncellemeyi tek başına uyguluyorsunuz.
Güncelleme sonrası sitenin ana sayfası sorunsuz açılıyor, ama formu bizzat test ettiğinizde gönderim düğmesine basıldığında hiçbir şey olmadığını görüyorsunuz. Sebep, eklentinin yeni REST uç noktasının, sitede çalışan bir önbellekleme eklentisinin eski kural setiyle çakışması. Sadece ana sayfaya bakıp "site açılıyor, sorun yok" deseydiniz bu bozulmayı günler sonra, bir müşteri şikayet edene kadar fark etmezdiniz. Adım 2'de aldığınız yedeği tek adımda geri yükleyip siteyi eski, çalışan haline döndürüyorsunuz; ardından eklentinin destek forumunda aynı REST çakışmasını bildiren başka kullanıcılar buluyorsunuz. Geliştiricinin önerdiği geçici çözümü (önbellekleme eklentisinin ilgili uç noktayı istisna listesine alması) uygulayıp güncellemeyi bir kez daha, bu sefer başarıyla uyguluyorsunuz.
Adım 4: Siteyi doğrulayın
Doğrulama, ana sayfanın açılıp açılmadığına bakmaktan ibaret değil. Sitenin gerçekten para ya da veri kazandıran akışını test edin: bir e-ticaret sitesinde sepete ekleme ve ödeme adımı, bir hizmet sitesinde iletişim formu, bir üyelik sitesinde giriş ve panel erişimi. Yukarıdaki senaryoda olduğu gibi, tam da bu adım atlandığı için bozulmalar günlerce fark edilmeden kalıyor. Buna ek olarak tarayıcı konsolunu ve sunucu hata günlüğünü kontrol edin; sayfa görsel olarak sorunsuz görünse bile arka planda PHP uyarısı veya JavaScript hatası birikmeye başlamış olabilir.
Bu kontrolü güncellemeden sonraki ilk on beş, yirmi dakika içinde yapın, ertesi güne bırakmayın. Bir önbellekleme eklentiniz varsa sayfa önbelleğini temizlemeyi unutmayın; aksi halde eski, önbelleğe alınmış bir sürümü görüp her şeyin yolunda olduğunu düşünebilirsiniz, oysa canlı sürüm bambaşka bir hata veriyor olabilir.
Adım 5: Bir şeyler bozulursa, geri dönüş
Önce panik yapmayın: Adım 2'de aldığınız bir yedeğiniz varsa, tek yapmanız gereken o yedeği geri yüklemek ve sitenizi güncelleme öncesi çalışan haline anında döndürmek. Taze bir yedek yoksa, son güncellenen eklenti ya da temayı manuel olarak bir önceki sürüme döndürmeyi deneyin; WordPress.org'daki eklenti sayfalarının çoğunda "önceki sürümler" (advanced view) bölümünden geçmiş sürümlerin zip dosyasına ulaşabilirsiniz.
Kaynağı bulamıyorsanız eklentileri tek tek devre dışı bırakıp siteyi her adımda kontrol eden bir izolasyon yöntemi kullanın: yarısını kapatıp sorun devam ediyorsa diğer yarıya bakın, sorun bulunana kadar bu ikiye bölmeyi tekrarlayın. Sorunu bulup düzelttikten (ya da geri aldıktan) sonra son adım, ne olduğunu bir yere not etmek: hangi eklenti, hangi sürüm, hangi çakışma. Bu not, aynı eklentinin bir sonraki güncellemesinde Adım 1'i çok daha hızlı geçmenizi sağlar.
İzolasyon yöntemi de sonuç vermiyorsa, yani sorun tek bir eklentiye değil de çekirdek dosyalara, veritabanı yapısına veya sunucu yapılandırmasına dayanıyorsa, bu noktada hosting sağlayıcınızın destek ekibine veya eklenti geliştiricisine yazmaktan çekinmeyin; sunucu seviyesindeki bir kayıt dosyasına sizden çok daha hızlı erişebilirler. Bu aşamada siteyi bozuk hâlde bırakıp beklemeyin, en azından bakım modu (maintenance mode) açarak ziyaretçilerin hatalı bir sayfayla karşılaşmasını önleyin; destek ekibinden yanıt gelene kadar bu, itibarınızı koruyan basit ama etkili bir ara adım.
Adım 6: Süreci otomatikleştirin
Yukarıdaki beş adımı tek bir site için elle uygulamak yönetilebilir; yirmi, elli site için imkansıza yakın. Otomasyonun riskli tarafı "hepsini otomatik uygula, hiç kontrol etme" yaklaşımı; doğru model bunun yerine Adım 2, 4 ve 5'i otomatikleştirip Adım 1 ve 3'teki insan kararını (büyük sürüm mü, değişiklik notunda yapısal bir şey var mı) yerinde bırakmak. Yani: güncelleme öncesi otomatik yedek zorunlu kılınır, güncelleme uygulanır, sistem birkaç kritik sayfayı ve temel bir işlevi otomatik olarak kontrol eder, bir sorun tespit ederse otomatik olarak yedeğe geri döner ve size bildirim gönderir. Büyük sürüm güncellemelerini ise otomasyonun dışında tutup, Adım 1'deki gibi elle gözden geçirmeye devam etmek mantıklı, çünkü riskin büyük kısmı zaten oradan geliyor.
Hangi eklentinin tam otomasyona uygun olduğuna karar verirken basit bir ayrım işe yarar: sitenin çekirdek işlevine (ödeme, form, üyelik girişi) doğrudan dokunmayan, geçmişte hiç büyük çaplı bozulma yaratmamış eklentileri tam otomatik akışa bırakabilirsiniz. Ödeme sağlayıcısı, önbellekleme sistemi veya form eklentisi gibi kritik bileşenleri ise yarı otomatik tutup, güncelleme uygulanır uygulanmaz size bildirim gönderen ama son onayı sizde bırakan bir akışla yönetmek daha güvenli. Zamanla, hangi eklentinin güvenle otomatikleştirilebileceğine dair bu liste kendiliğinden oturur.
Kaynaklar
- Sucuri, 2023 Hacked Website & Malware Threat Report
- Patchstack, State of WordPress Security in 2026 ve CVE-2026-87902 istismar zaman çizelgesi
- WordPress.org, A New Cadence for WordPress Core
Bu altı adımı her site için elle kurmak yerine, Watch Your WP güncelleme öncesi otomatik yedek alıp sorun durumunda tek tıkla geri dönebilen bir akışı tüm siteleriniz için tek panelden çalıştırır.
Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn