WordPress Bakım Modu Nasıl Açılır?

WordPress bakım modunu açmanın pratik yolu, kurulum dizininde .maintenance dosyası oluşturmak veya WP-CLI ile wp maintenance-mode activate komutunu çalıştırmaktır. İşlem tamamlandığında modu açıkça kapatın, 503 yanıtını doğrulayın ve cache katmanlarını kontrol edin; aksi hâlde site güncel olsa bile ziyaretçiler bakım ekranı görebilir.

WordPress bakım modu ne zaman kullanılmalı?

WordPress bakım modu, güncelleme veya taşıma sırasında ziyaretçiye sitenin geçici olarak kullanılamadığını bildirir. Kısa işlemlerde WordPress’in yerleşik .maintenance mekanizması yeterlidir. Daha uzun çalışmalarda HTTP 503 Service Unavailable yanıtı, açık bir bilgilendirme sayfası ve yöneticiler için kontrollü erişim birlikte planlanmalıdır.

Bakım modunu açmadan önce işlemin tahmini süresini ve geri dönüş yolunu belirleyin. Bir eklenti güncellemesi birkaç saniyede bitebilir; veritabanı taşıması veya tema değişikliği dakikalar sürebilir. Aynı yöntemi her senaryoda kullanmak, ziyaretçiye boş bir sayfa gösterebilir ya da bakım ekranının gereğinden uzun kalmasına neden olabilir.

WordPress bakım modu nasıl açılır?

En hızlı yöntem, WordPress kurulum dizininde .maintenance adlı dosya oluşturmaktır. WordPress bu dosyayı algıladığında yerleşik bakım ekranını gösterir. Dosya WordPress’in kök dizininde bulunmalıdır; VPS kurulumlarında bu dizin çoğunlukla /var/www/html, bazı hosting hesaplarında ise public_html olur.

Önce doğru dizini ve WordPress kurulumunu doğrulayın:

cd /var/www/html
wp core is-installed
pwd
ls -la wp-config.php

wp core is-installed komutu başarılı dönüyorsa WP-CLI doğru WordPress dizininde çalışıyor demektir. wp-config.php dosyasının listelenmesi de kontrolü destekler; tek başına kesin kanıt sayılmaz.

WP-CLI kuruluysa bakım modunu şu şekilde açabilirsiniz:

wp maintenance-mode activate
wp maintenance-mode status

Durum çıktısında bakım modunun etkin olduğu ve oluşturulma zamanı görünür. WP-CLI kullanılamıyorsa dosya yöntemi uygulanabilir:

cd /var/www/html
printf '<?php $upgrading = time(); ?>' > .maintenance
chmod 644 .maintenance
ls -l .maintenance

PHP satırı, WordPress’in beklediği bakım dosyası biçimidir. Dosya sahipliğini mevcut WordPress dosyalarıyla karşılaştırın; dosyayı chmod 777 ile yazılabilir hâle getirmek izin sorununu çözmez, gereksiz erişim açar.

Bakım tamamlandığında modu kapatmak için WP-CLI komutunu tercih edin:

wp maintenance-mode deactivate
wp maintenance-mode status

Dosya yöntemi kullanıldıysa:

rm -f /var/www/html/.maintenance
test ! -e /var/www/html/.maintenance && echo 'Bakım modu kapalı'

Silme komutundan önce pwd ve hostname çıktısını kontrol edin. Yanlış sunucuda işlem yapmak, bakım ekranından çok daha pahalı bir hata çıkarabilir.

Kontrol noktası – Bakım dosyasını oluşturmadan önce WordPress kök dizinini wp core is-installed ile doğrulayın.

Bakım modu hangi yöntemle açılmalı?

Yöntem, işlemin niteliğine göre seçilmelidir. WordPress çekirdeğinin kendi mekanizması küçük ve kısa bakım pencereleri için yeterlidir. Yönetim panelinden kullanılabilen bakım eklentileri özel mesaj, geri sayım veya yetkili kullanıcı istisnası gerektiğinde iş görür. Sunucu düzeyindeki Nginx ya da CDN kuralları, WordPress cevap vermese bile bakım sayfası gösterebilir.

Bakım eklentisi kurmak yalnızca bir düğmeye basmaktan ibaret değildir. Eklenti etkinleştirilmeden önce mevcut cache katmanlarını, güvenlik eklentilerini ve CDN davranışını inceleyin. Cloudflare veya başka bir reverse proxy eski bakım sayfasını önbellekte tutarsa, bakım sona erdiği hâlde ziyaretçiler aynı ekranı görmeye devam edebilir.

Özel bakım sayfası kullanılacaksa yanıt kodu genellikle 503 Service Unavailable olmalıdır. 200 OK yanıtı, arama motorlarına sayfanın normal ve kalıcı içerik olduğu izlenimini verebilir. HTTP 503 yanıtına tahmini bitiş zamanını belirten Retry-After başlığı eklenebilir; süre kesin değilse başlığı kullanmamak daha güvenlidir.

Siteyi yalnızca yöneticinin görmesini sağlamak da dikkat ister. WordPress oturumu olmayan ziyaretçiyle, aynı sunucudaki izleme servisi veya ödeme webhook’u aynı kurallara tabi tutulmamalıdır.

Kontrol noktası – Kısa işlemlerde WP-CLI veya .maintenance, özel erişim kuralları gereken uzun işlemlerde sunucu ya da CDN katmanını seçin.

WordPress bakım modu açılmadan önce neler kontrol edilmeli?

Bakım modunun kendisi basittir; hazırlık kısmı değildir. Güncelleme başlamadan önce tam dosya ve veritabanı yedeği alın. VPS üzerindeki snapshot hızlı geri dönüş sağlayabilir, fakat tek başına yedekleme stratejisi değildir. Ayrıntılar için VPS Snapshot Nedir? Anlık Yedekleme Rehberi başlıklı içeriğe bakabilirsiniz.

Veritabanı yedeğinin üretildiğini ve okunabilir bir dosya oluşturduğunu kontrol edin:

wp db export /var/backups/wordpress-$(date +%F-%H%M).sql
ls -lh /var/backups/wordpress-*.sql
head -n 5 /var/backups/wordpress-2026-10-04-0300.sql

Dosya adındaki tarih yalnızca örnektir; gerçek dosya adını ls çıktısından doğrulayın. head komutu dosyanın boş olup olmadığını hızlıca gösterir, tam geri dönüş testi yapmaz. İçeri aktarma provası staging ortamında gerçekleştirilmelidir.

Güncelleme öncesinde etkin eklentileri ve sürümleri kaydetmek geri dönüşü kolaylaştırır:

wp core version
wp plugin list --status=active --format=table
wp theme list --status=active --format=table
php -v

PHP sürümüyle eklenti ve tema uyumluluğunu ayrıca kontrol edin. Bakım modu PHP uyumsuzluğunu düzeltmez; yalnızca güncelleme sırasında ziyaretçiye ara ekran gösterir.

Dosya yükleme veya medya iş akışı değişecekse WordPress Dosya Yükleme Limiti Nasıl Artırılır? içeriğindeki PHP ve web sunucusu katmanlarını birlikte değerlendirme yaklaşımı işinize yarayabilir. Bakım planına Nginx, PHP-FPM ve veritabanı servislerini de dahil edin.

Bakım ekranı ziyaretçilere nasıl gösterilir?

Yerleşik bakım ekranı temel bir mesaj verir ve tasarım üzerinde sınırlı kontrol sunar. Birkaç saniyelik eklenti veya çekirdek güncellemesinde bu ekran yeterlidir. Daha uzun bakımda ziyaretçiye ne olduğunu, ne zaman yeniden denemesi gerektiğini ve varsa destek kanalını açıklayan sade bir sayfa gösterin.

WordPress’in bakım dosyası güncelleme sırasında geçici olarak oluşturulur. Çekirdek, dosyadaki zaman bilgisini kullanır ve dosyanın yaklaşık 10 dakikadan uzun süre kalmasını eski bir bakım durumu olarak değerlendirebilir. Bu davranış uzun bakım planlamak için güvenilir bir zamanlayıcı değildir; işlem bittiğinde dosyayı açıkça kaldırın.

Bakım ekranı görünmüyorsa tarayıcı cache’ini, CDN cache’ini ve reverse proxy yanıtını ayrı ayrı kontrol edin:

curl -I https://example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

İlk komut yanıt başlıklarını, ikinci komut yalnızca HTTP durum kodunu gösterir. Özel bakım tasarımında beklenen kod 503‘tür. 200 dönüyorsa WordPress’e ulaşmadan önce başka bir katmanın yanıt verdiği veya bakım kuralının yanlış yazıldığı düşünülebilir.

Nginx yapılandırması değiştirilecekse önce sözdizimi testi yapın:

sudo nginx -t
sudo systemctl reload nginx

reload çalışan işçileri hemen sonlandırmadan yapılandırmayı yeniler. Yine de bakım kuralının kapsamını, yönetici erişimini ve sağlık kontrolünü test edin. Nginx kurulumu ve temel yapılandırma ayrıntıları için Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma Rehberi ilgili bir başvuru noktasıdır.

Kontrol noktası – Bakım ekranını normal tarayıcıda, gizli pencerede ve curl -I ile doğrulayın.

Yönetici erişimi nasıl korunur?

Bakım modu açıkken sitenin davranışını test etmek gerekebilir. Yerleşik .maintenance mekanizması çoğu durumda ziyaretçiye ve yöneticiye aynı ekranı gösterir; tema veya eklenti geliştiren ekipler bu nedenle staging ortamını tercih etmelidir. Canlı sitede istisna gerekiyorsa IP allowlist, HTTP Basic Authentication veya uygulama içi bakım eklentisi kullanılabilir.

IP adresine dayalı istisnalar, mobil bağlantılarda ve değişken IP kullanan ofislerde sorun çıkarabilir. Ayrıca IP kontrolü kimlik doğrulamasının yerini tutmaz. Yönetim panelini doğrudan internete açmak yerine VPN veya ek bir kimlik doğrulama katmanı değerlendirin.

Özel bakım sayfasında aşağıdaki yolların davranışını ayrı test edin:

• Site ana sayfası ve birkaç içerik URL’si
• /wp-admin/ ve giriş ekranı
• REST API uç noktaları
• Ödeme, form ve webhook adresleri
• Uptime Kuma veya benzeri sağlık kontrolü URL’si

İzleme sistemi yalnızca HTTP 200 bekliyorsa bakım sırasında alarm üretebilir. Alarmı tamamen kapatmak yerine bakım penceresine özel bir plan tanımlayın. Sağlık kontrolünü silmek, gerçek bir kesintiyi görünmez hâle getirebilir.

Yeni davranışı canlıya almadan önce staging ortamında deneyin. Özellikleri kademeli açma yaklaşımı için Feature Flag Nedir? Güvenli Yayına Alma Rehberi başlığındaki prensipler WordPress bakım senaryolarında da kullanılabilir: değişikliği küçük bir kullanıcı grubuyla sınayın, logları izleyin ve geri dönüş komutunu hazır tutun.

Bakım modu kapanmıyorsa ne yapılır?

WordPress güncellemesi yarıda kesildiğinde .maintenance dosyası kalabilir. Ziyaretçiler sürekli “Briefly unavailable for scheduled maintenance” benzeri bir ekran görür. İlk kontrol, dosyanın gerçekten WordPress kök dizininde olup olmadığıdır:

cd /var/www/html
pwd
find . -maxdepth 1 -name '.maintenance' -ls
wp maintenance-mode status

Dosya bulunuyor ve devam eden bir güncelleme yoksa kaldırılabilir:

rm -f .maintenance
wp core verify-checksums

wp core verify-checksums çekirdek dosyalarındaki beklenmeyen değişiklikleri araştırır. Komut başarısız olursa dosyaları hemen üzerine yazmayın; bazı güvenlik veya özelleştirme işlemleri çekirdek dosyalarını değiştirmiş olabilir.

Dosya silindikten sonra bakım ekranı görünmeye devam ederse şu katmanları sırayla inceleyin:

1. WordPress kök dizininde ikinci bir .maintenance dosyası olup olmadığını kontrol edin.
2. PHP-FPM ve Nginx loglarında yeni hata olup olmadığını inceleyin.
3. CDN ve reverse proxy cache’ini temizleyin.
4. Bakım eklentisinin hâlâ etkin veya bozuk olup olmadığını kontrol edin.
5. Farklı ağdan ve farklı bir HTTP istemcisinden test yapın.

Log okumadan PHP-FPM’i veya tüm sunucuyu yeniden başlatmak asıl hatayı gizleyebilir. Önce journalctl, Nginx hata logu ve WordPress debug logunu karşılaştırın; yalnızca gerekli servisi yeniden yükleyin.

Kontrol noktası – Bakım ekranı kalırsa önce .maintenance, ardından cache ve uygulama loglarını kontrol edin; sunucuyu son çare olarak yeniden başlatın.

Bakım modu SEO ve güvenlik açısından sorun çıkarır mı?

Kısa süreli ve doğru yapılandırılmış bakım, tek başına SEO sorunu oluşturmaz. Arama motoru botlarına geçici durumun bildirilebilmesi için 503 yanıtı önemlidir. Uzun süre 200 dönen boş bir bakım sayfası, içeriğin geçici mi kalıcı mı olduğunu belirsizleştirir.

Bakım sayfasında yönetim parolası, veritabanı bilgisi, sunucu yolu veya ayrıntılı hata çıktısı göstermeyin. PHP hata raporlamasını canlı sitede ziyaretçiye açık bırakmak da bilgi sızıntısı yaratabilir. Hata ayrıntılarını loga yazın, kullanıcıya kısa ve anlaşılır bir mesaj gösterin.

Bakım sırasında güvenlik eklentisini devre dışı bırakmak zorunda kalırsanız işlem biter bitmez etkinlik durumunu kontrol edin. Güncelleme sonrasında dosya izinlerini, sahipliği, cron görevlerini ve kritik form akışlarını da test edin. Ana sayfanın açılması tek başına yeterli değildir.

Bakım penceresi sonunda temel doğrulama için şu komutlar kullanılabilir:

wp maintenance-mode status
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' https://example.com/
wp cron event list --due-now
wp plugin list --update=available

Güncelleme listesinde öğe kalması her zaman hata değildir; hedeflenen eklentilerin sürümlerini ayrıca doğrulayın. wp cron event list --due-now çıktısı, bakım sırasında biriken zamanlanmış görevleri görmeye yardımcı olur.

Bakım bittiğinde izleme alarmının normale döndüğünü, form gönderiminin çalıştığını ve giriş yapılabildiğini doğrulayın. Küçük bir kontrol, gece yarısı yapılan acele bir düzeltmeden daha ucuzdur.

Bakım Modunu Açmadan Önce Şunları Kontrol Edin

• WordPress kök dizinini ve hostname bilgisini doğrulayın.
• Dosya ve veritabanı yedeği alıp yedeğin boyutunu kontrol edin.
• Etkin eklenti, tema, WordPress ve PHP sürümlerini kaydedin.
• Bakım yöntemini ve tahmini işlem süresini belirleyin.
• Yönetici, webhook ve sağlık kontrolü erişimlerini test edin.
• Bakım yanıtının 503 döndürdüğünü curl ile doğrulayın.
• İş bitince bakım modunu kapatıp ana sayfa ve formları kontrol edin.

Sık Sorulan Sorular

Kaynaklar

• WP-CLI – maintenance-mode — developer.wordpress.org
• WordPress Developer Resources – wp_maintenance — developer.wordpress.org
• MDN – 503 Service Unavailable — developer.mozilla.org
• nginx Documentation — nginx.org