Bir WordPress sitesini güncellerken çekirdek, tema ve eklentilerin aynı anda dosya değiştirmesi, ziyaretçinin yarım yüklenmiş bir sayfa görmesine yol açabilir. Bakım modu tam da bu kısa pencerede devreye girer; siteyi geçici olarak kapatıp arka planda işin bitmesini bekletir. Bu mekanizmanın nasıl çalıştığını ve güncelleme akışını nasıl kontrol altında tutacağınızı adım adım ele alalım.

Bakım Modu Tam Olarak Ne Yapar?

WordPress, bir güncelleme başlattığında kök dizinine geçici bir .maintenance dosyası yazar. Bu dosyanın içinde basit bir PHP zaman damgası bulunur ve wp-includes/load.php içindeki wp_maintenance() fonksiyonu her istek geldiğinde bu damgayı kontrol eder. İşlem bittiğinde dosya otomatik silinir ve site normale döner. Ziyaretçi bu sırada "Çok kısa bir süreliğine planlı bakım için kapalıyız" mesajını alır ve sunucu 503 Service Unavailable başlığı döndürür; bu, arama motorlarının durumu kalıcı bir hata sanmaması açısından önemlidir.

Damga, dosyanın yazıldığı andan itibaren yaklaşık on saniyelik bir tolerans tanır. Yani normal bir güncelleme akışında ziyaretçinin bu ekranı görme olasılığı oldukça düşüktür; çünkü dosya işin başında oluşturulup işin sonunda kaldırılır. Asıl risk, sürecin yarıda kesilmesi durumunda ortaya çıkar ve bu konuyu birazdan ayrıntılı ele alacağız.

Manuel Bakım Modu ile Otomatik Bakım Modu Farkı

İki tür bakım modunu birbirinden ayırmak gerekir. Çekirdek güncellemesi sırasında WordPress'in kendi yarattığı geçici mod genellikle birkaç saniye sürer. Planlı işler için ise bilinçli olarak elinizle açtığınız bir bakım sayfası vardır; tema değiştirirken, büyük bir migrasyon yaparken veya veritabanı taşırken bunu tercih edersiniz.

ÖzellikOtomatik (çekirdek)Manuel (planlı)
TetikleyenGüncelleme süreciYönetici / eklenti
SüreSaniyelerSizin belirlediğiniz kadar
ÖzelleştirmeYokTam (logo, mesaj, e-posta formu)
HTTP başlığı503503 (doğru kurguda)
KapsamTüm siteİstenirse yöneticiye açık

Kendi Bakım Sayfanızı Oluşturmak

Eklentisiz, hafif bir çözüm istiyorsanız wp-content dizinine bir maintenance.php dosyası bırakmanız yeterli. WordPress bu dosyayı varsayılan bakım ekranı yerine otomatik olarak gösterir. Doğru başlığı göndermeyi de unutmayın:

<?php
http_response_code(503);
header('Retry-After: 3600');
header('Content-Type: text/html; charset=utf-8');
?>
<!doctype html>
<html lang="tr"><head><meta charset="utf-8">
<title>Bakım Çalışması</title></head>
<body style="font-family:sans-serif;text-align:center;padding:80px">
  <h1>Kısa bir bakımdayız</h1>
  <p>Sitemiz birazdan tekrar yayında olacak. Anlayışınız için teşekkürler.</p>
</body></html>

Bu yöntem, eklenti yükü olmadan kontrolün tamamen sizde kalmasını sağlar. Paylaşımlı bir ortamda çalışıyorsanız ve dosya izinleri konusunda emin değilseniz, panel üzerinden yönetilen bir WordPress hosting paketi bu tür müdahaleleri dosya yöneticisinden çok daha güvenli hale getirir. Eklenti tarafını tercih edenler için ekosistemde Elementor, SeedProd ya da WP Maintenance gibi araçlar geri sayım, abone formu ve marka uyumlu tasarım gibi ekstralar sunar; ancak unutulmaması gereken nokta, eklenti aktifken sitenin yine de PHP ve veritabanını çalıştırdığıdır. maintenance.php yaklaşımı ise sunucuyu neredeyse hiç yormadan tek bir statik yanıt döndürdüğü için ağır bakım pencerelerinde daha hafif kalır.

Takılı Kalan Bakım Modundan Kurtulmak

En sık karşılaşılan sorun, güncelleme yarıda kesildiğinde .maintenance dosyasının silinmeden kalması ve sitenin sonsuza dek bakım ekranında donmasıdır. Çözüm oldukça basittir:

  • FTP veya dosya yöneticisi: Kök dizindeki gizli .maintenance dosyasını silin.
  • SSH erişiminiz varsa: Aşağıdaki komutla tek satırda halledin.
  • Önbellek temizliği: CDN veya sayfa önbelleği kullanıyorsanız bakım ekranı cache'e takılmış olabilir, mutlaka purge edin.
# Sitenin kök dizininde
rm -f .maintenance

# WP-CLI kuruluysa, takılan güncellemeleri de toparlamak için
wp core update-db
wp cache flush

WP-CLI ile Güncellemeleri Yönetmek

Komut satırından çalışmak, özellikle birden fazla siteyi yönettiğiniz durumlarda zaman kazandırır. WP-CLI ile çekirdek, eklenti ve temaları tek tek veya toplu güncelleyebilir, hatta güncelleme öncesi kontrol yapabilirsiniz:

# Mevcut sürümü ve bekleyen güncellemeleri gör
wp core check-update
wp plugin list --update=available

# Önce yedek mantığıyla veritabanını dışa al
wp db export yedek-$(date +%F).sql

# Sonra güncelle
wp plugin update --all
wp core update

Her güncelleme öncesi wp db export ile alınan bir döküm, işler ters gittiğinde geri dönüş için en hızlı sigortadır.

Sağlıklı Bir Güncelleme Stratejisi

Otomatik güncellemeler rahatlık sağlar ama her senaryoya uymaz. Çoğu durumda küçük güvenlik yamalarını otomatiğe bırakmak, büyük sürüm atlamalarını ise elle yapmak en dengeli yaklaşımdır. wp-config.php içinden davranışı şu sabitlerle yönlendirebilirsiniz:

// Sadece minör (güvenlik) güncellemeleri otomatik
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Tüm otomatik güncellemeleri kapatmak isterseniz
// define( 'AUTOMATIC_UPDATER_DISABLED', true );
  • Önce staging: Kritik siteleri canlıda değil, bir deneme kopyasında güncelleyip test edin.
  • Uyumluluk: Yeni çekirdek sürümünün PHP sürümünüzle uyumunu kontrol edin; eski bir PHP'de yeni WordPress beklenmedik hatalar verebilir.
  • Sıralama: Genel kural olarak önce çekirdek, sonra tema, en son eklentiler güncellenir.
  • Zamanlama: Trafiğin düşük olduğu saatleri seçin; gece yarısı yapılan bir bakım, gündüz yapılana göre çok daha az ziyaretçiyi etkiler.

Bogahost Önerisi: Büyük sürüm geçişlerini canlı siteye uygulamadan önce mutlaka bir staging kopyası oluşturun. Günlük otomatik yedek alan bir altyapıda çalışmak, hatalı bir eklenti güncellemesinden dakikalar içinde geri dönmenizi sağlar & gece yarısı panik yaşamanızı önler.

Bakım Penceresini SEO ve Ziyaretçi Açısından Yönetmek

Uzun süren bakımlar arama motorlarını tedirgin edebilir. Doğru kurguda gönderilen 503 başlığı ve Retry-After değeri, botlara "site geçici olarak kapalı, sonra tekrar gel" mesajını verir; böylece sayfalarınız dizinden düşmez. Ziyaretçiye ise tahmini süreyi, alternatif iletişim kanalını ve mümkünse bir e-posta bırakma formunu sunmak, kapalı bir kapıdan çok daha iyi bir deneyim yaratır. Genel amaçlı bir projeyi taşıyorsanız ve kaynaklarınızı esnek tutmak istiyorsanız, ölçeklenebilir bir web hosting planı bakım sırasında oluşan ani yük değişimlerini daha rahat karşılar.

Özetle

Bakım modu, güncelleme sürecinin görünmeyen ama kritik bir parçasıdır. Doğru HTTP başlıkları, planlı bir güncelleme sırası, güncelleme öncesi veritabanı dökümü ve takılma anında .maintenance dosyasını silme refleksi bir araya geldiğinde, sitenizi hem güvende hem de kesintisize yakın tutarsınız. Düzenli yedek ve staging alışkanlığı edindiğinizde güncelleme, korkulan bir iş olmaktan çıkıp rutin bir bakım adımına dönüşür.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
hosting SEO WordPress WP-CLI Bakım Modu Güncelleme wp-config Staging
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar