WordPress Bakım ve Güncelleme Otomasyonu Rehberi

WordPress, dünyadaki web sitelerinin büyük bir bölümünü çalıştıran esnek bir sistemdir; bu esnekliğin bedeli ise sürekli bakımdır. Çekirdek, temalar ve eklentiler düzenli olarak güncellenir ve her güncelleme hem bir güvenlik kazancı hem de küçük bir bozulma riski taşır. Bu rehber, bakım işlerini hangi ölçüde otomatikleştirebileceğinizi, nerede insan kontrolünün şart olduğunu ve güvenli bir güncelleme akışının nasıl kurulacağını anlatıyor.

WordPress bakımı neleri kapsar?

"Bakım" çoğu zaman yalnızca güncelleme düğmesine basmak olarak düşünülür. Oysa düzenli bir bakım rutini en az şu kalemleri içerir:

• Çekirdek güncellemeleri: küçük sürümler (güvenlik ve hata düzeltmeleri) ve büyük sürümler (yeni özellikler).
• Eklenti ve tema güncellemeleri: en sık bozulma kaynağı burasıdır.
• PHP sürümü takibi: barındırma tarafında eski PHP sürümleri hem güvenlik hem performans sorunu yaratır.
• Veritabanı temizliği: eski revizyonlar, süresi geçmiş geçici veriler (transient), spam yorumlar.
• Yedekleme ve geri yükleme testi.
• Güvenlik kontrolleri: kullanıcı listesi, dosya bütünlüğü, kötü amaçlı yazılım taraması.
• Performans ve hata kayıtları: PHP hata günlüğü, yavaş sorgular, kırık bağlantılar.

Bu kalemlerin bir kısmı tamamen otomatik yürütülebilir, bir kısmı ise otomasyonla hazırlanıp insan onayıyla tamamlanmalıdır.

WordPress'in kendi otomatik güncelleme mekanizması

WordPress 3.7 sürümünden beri arka planda otomatik güncelleme yapabilir. Varsayılan olarak çekirdeğin küçük sürümleri (örneğin 6.6.1'den 6.6.2'ye) kendiliğinden kurulur. WordPress 5.5 ile birlikte eklenti ve temalar için de yönetim panelinden tek tek otomatik güncelleme açılabilir hale geldi. Davranış, wp-config.php içindeki sabitlerle ve filtrelerle ince ayarlanabilir:

// Yalnızca küçük çekirdek güncellemeleri (varsayılan davranış)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Tüm otomatik güncellemeleri kapatmak (önerilmez)
// define( 'AUTOMATIC_UPDATER_DISABLED', true );

Ayrıntılı seçenekler için WordPress'in otomatik arka plan güncellemeleri belgesine bakabilirsiniz. Önemli bir not: WordPress'in arka plan güncellemeleri, siteye trafik geldikçe tetiklenen WP-Cron üzerinden çalışır. Çok az ziyaret alan sitelerde güncellemeler gecikebilir; bu yüzden ciddi kurulumlarda WP-Cron'u gerçek bir sunucu cron görevine bağlamak iyi bir pratiktir.

Hangi güncelleme otomatik, hangisi kontrollü olmalı?

Güvenli bir güncelleme akışı

Birden fazla siteyi yönetirken aşağıdaki akış, hem hızlı hem de geri alınabilir bir güncelleme düzeni sağlar:

1. Yedek al. Güncellemeden hemen önce dosyalar ve veritabanı yedeklenmeli. Gece alınan yedek, gün içinde eklenen siparişleri veya form kayıtlarını içermeyebilir.
2. Değişiklik notlarını oku. Özellikle büyük sürümlerde eklentinin değişiklik günlüğüne göz atmak, "bu sürüm PHP 8.1 gerektirir" gibi kritik bilgileri önceden yakalar.
3. Test ortamında dene. Canlı sitenin kopyası (staging) üzerinde güncellemeyi uygula, ana sayfayı, iletişim formunu, sepet ve ödeme adımlarını kontrol et.
4. Kademeli yay. Aynı eklentiyi kullanan çok sayıda siteniz varsa önce düşük riskli birkaç sitede uygula.
5. Otomatik görsel ve işlevsel kontrol. Güncelleme sonrası ana sayfanın HTTP durum kodunu, belirli bir metnin hâlâ sayfada olup olmadığını ve PHP hata günlüğünü kontrol eden basit bir betik büyük bir güvence sağlar.
6. Kayıt tut. Hangi sitede hangi eklentinin hangi sürümden hangi sürüme geçtiğini not edin. Bir sorun çıktığında ilk bakılacak yer burasıdır.

WP-CLI ile bakım otomasyonu

Komut satırı aracı WP-CLI, WordPress bakımını betiklerle otomatikleştirmenin en yaygın yoludur. Aşağıda sık kullanılan komutlardan oluşan örnek bir bakım betiği var:

#!/bin/bash
SITE=/var/www/ornek-site
cd "$SITE" || exit 1

wp db export "/yedek/$(date +%F)-db.sql"     # veritabanı yedeği
wp core verify-checksums                      # çekirdek dosyaları değişmiş mi?
wp plugin verify-checksums --all              # eklenti dosyaları (wordpress.org kaynaklıysa)
wp core update --minor                        # yalnızca küçük çekirdek sürümü
wp plugin update --all --minor                # eklentilerde yalnızca küçük sürümler
wp transient delete --expired                 # süresi geçmiş geçici veriler
wp cache flush

STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://ornek-site.com/)
[ "$STATUS" != "200" ] && echo "UYARI: ana sayfa $STATUS döndü"

Bu betik tek başına mükemmel değildir; örneğin bir eklentinin sürüm numaralandırması anlamsal sürümlemeye uymuyorsa "küçük sürüm" ayrımı beklediğiniz gibi çalışmayabilir. Yine de her gece çalışan ve sonucu bir e-posta veya mesaj kanalına gönderen bu tür bir betik, sitelerin büyük çoğunluğunu güncel tutmaya yeter.

Çoklu site yönetim araçlarıyla bakım

Komut satırı yerine arayüz tercih edenler için MainWP, ManageWP ve InfiniteWP gibi araçlar, tüm sitelerdeki bekleyen güncellemeleri tek listede gösterir ve seçili olanları toplu uygular. Bu araçların çoğu güncelleme öncesi yedek, güncelleme sonrası görsel karşılaştırma (önceki ve sonraki ekran görüntüsünü kıyaslama) ve güvenlik taraması gibi eklentiler sunar. Hangi yaklaşımın size uygun olduğunu tek panelden site yönetimi yazımızda karşılaştırdık.

Veritabanı ve performans bakımı

Zamanla büyüyen bir WordPress veritabanı, site yavaşlamasının sessiz nedenlerinden biridir. Düzenli olarak yapılabilecek otomatik işler:

• Revizyon sınırı: define( 'WP_POST_REVISIONS', 10 ); ile her yazı için saklanan revizyon sayısını sınırlamak.
• Süresi geçmiş transient'leri silmek: özellikle bazı eklentiler bu tabloyu hızla şişirir.
• Otomatik yüklenen seçenekleri izlemek: wp_options tablosunda "autoload" olarak işaretli büyük kayıtlar her sayfa yüklemesinde belleğe alınır. Kaldırılmış eklentilerden kalan kayıtlar burada birikebilir.
• Spam ve çöp kutusundaki yorumları temizlemek.
• Eylem zamanlayıcı tabloları: e-ticaret eklentilerinin kullandığı zamanlanmış görev tabloları tamamlanmış kayıtlarla büyüyebilir; eski kayıtların temizlenmesi gerekir.

Bu işlemlerin hepsi geri dönüşü olmayan silme içerir. Bu nedenle otomasyon, her zaman bir veritabanı yedeğinden sonra çalışmalıdır.

Bakım sırasında ziyaretçi deneyimi

WordPress bir güncellemeyi uygularken kısa bir süre için site kökünde .maintenance dosyası oluşturur ve ziyaretçilere "Bakım nedeniyle kısa bir süre hizmet veremiyoruz" mesajı gösterir. Güncelleme yarıda kesilirse bu dosya kalabilir ve site bakım modunda takılı kalır. Otomasyon betiklerine, güncelleme sonrasında bu dosyanın hâlâ var olup olmadığını kontrol eden bir adım eklemek, bu klasik sorunu dakikalar içinde yakalamanızı sağlar.

Önerilen bakım takvimi

Kullanılmayan eklentiler: en ucuz güvenlik önlemi

Devre dışı bırakılmış ama silinmemiş eklentiler, sunucuda dosya olarak durmaya devam eder ve bazı açıklar eklenti etkin olmasa bile istismar edilebilir. Ayrıca güncelleme listesinde gereksiz kalabalık yaratırlar. Kullanılmayan her eklentiyi ve aktif tema dışındaki temaları (bir varsayılan tema yedek olarak kalabilir) silmek, bakım yükünü ve saldırı yüzeyini aynı anda azaltır. Kapsamlı bir güvenlik kontrol listesi için yedekleme ve güvenlik rehberimize göz atabilirsiniz.

Bakımı belgelemek ve raporlamak

Özellikle müşteri sitelerini yönetiyorsanız, yapılan bakımın görünür olması gerekir. Aylık kısa bir rapor; yapılan güncellemeleri, alınan yedekleri, izleme sonuçlarını ve varsa çözülen sorunları listeler. Bu rapor hem müşteriye verilen hizmetin somut kanıtıdır hem de ileride bir sorun çıktığında geriye dönük iz sürmeyi kolaylaştırır. Raporlamayı müşteri ilişkisi açısından ajanslar için müşteri sitesi yönetimi yazısında ele aldık.

Sonuç

WordPress bakımının amacı "hiçbir şey bozulmasın" değil, "bir şey bozulduğunda hızla fark edilsin ve geri alınabilsin"dir. Küçük güncellemeleri otomatiğe bırakın, büyük değişiklikleri test edin, her işlemden önce yedek alın ve sonuçları kayıt altında tutun. Bu dört alışkanlık, onlarca siteyi tek kişinin bile rahatça yönetebileceği bir düzene dönüştürür.

Sık sorulan sorular

Tüm eklentiler için otomatik güncellemeyi açmak güvenli mi?

Basit ve tek amaçlı eklentiler için genellikle evet. Sayfa oluşturucular, e-ticaret ve üyelik eklentileri gibi sitenin işleyişini doğrudan etkileyen eklentilerde ise önce test edip sonra güncellemek daha güvenlidir.

Site bakım modunda takılı kaldı, ne yapmalıyım?

Site kök dizinindeki .maintenance dosyasını silmek genellikle sorunu çözer. Ardından yarıda kalan güncellemeyi yeniden çalıştırıp sitenin düzgün çalıştığını kontrol edin.

WP-CLI kullanmak için ne gerekir?

Sunucuya SSH erişimi ve PHP'nin komut satırından çalışabilmesi yeterlidir. Pek çok barındırma firması WP-CLI'yi önceden kurulu olarak sunar; paylaşımlı barındırmada SSH erişimi olup olmadığını sağlayıcınıza sorabilirsiniz.

İlgili rehberler

• GüvenlikWeb Sitesi Yedekleme ve Güvenlik Kontrol Listesi
• YönetimBirden Fazla Web Sitesini Tek Panelden Yönetmek
• BakımWeb Sitesi Bakım Maliyeti Neleri Kapsar