Site Bakım İçin Kapalı Diyor: .maintenance Dosyası Takıldı

Panelden birkaç eklentiyi birden güncellemeye başladınız, sayfa dönerken internetiniz koptu ya da sekmeyi kapattınız; şimdi hem siteniz hem de /wp-admin adresi tek bir cümle gösteriyor: "Kısa süreliğine planlı bakım nedeniyle kapalı. Bir dakika içinde tekrar kontrol edin." İngilizce kurulumlarda aynı mesaj Briefly unavailable for scheduled maintenance. Check back in a minute biçiminde çıkar. Bir dakika beklediniz, on dakika beklediniz, hâlâ aynı ekran. WordPress bakımda takıldı diye arama yaptığınızda karşınıza çıkan Türkçe sayfaların çoğu "bakım modu eklentisi nasıl kurulur" konusunu anlatıyor — yani sizin yaşadığınız arızayla hiç ilgisi yok.

Bu yazıda önce bu mesajın nereden geldiğini, kim tarafından yazıldığını ve WordPress'in kendi kuralına göre neden on dakika sonra kendiliğinden kalkması gerektiğini anlatıyoruz. Ardından .maintenance dosyasını FTP'de, cPanel Dosya Yöneticisi'nde ve SSH'ta nasıl görünür yapıp sileceğinizi adım adım gösteriyoruz — çünkü bu dosya nokta ile başladığı için varsayılan ayarlarda hiçbir yerde görünmez ve kullanıcıların çoğu "dosya zaten yok" diyerek yanlış yola sapar. En sonda, hiçbir Türkçe kaynağın söylemediği kritik kısım var: dosyayı sildikten sonra iş bitmiyor, yarıda kalan güncellemeyi elle tamamlamanız gerekiyor. Aksi halde siteniz açılır ama bozuk bir eklenti klasörü ya da yarım yüklenmiş bir çekirdek dosyasıyla çalışmaya devam eder.

Bu Mesaj Nereden Geliyor ve Kim Yazıyor#

.maintenance dosyasını bir eklenti değil, WordPress'in kendisi oluşturur. Çekirdeği, temayı veya bir eklentiyi güncellemeye başladığınız anda WordPress site kök dizinine .maintenance adında tek satırlık bir PHP dosyası yazar. İçeriği tam olarak şudur:

<?php $upgrading = 1786512340; ?>

Bu sayı, güncellemenin başladığı andaki Unix zaman damgasıdır. WordPress her sayfa isteğinde bu dosyanın var olup olmadığına bakar; varsa içindeki $upgrading değerini okur ve şu anki zamandan çıkarır. Aradaki fark 10 dakikadan küçükse ziyaretçiye bakım mesajını gösterir, büyükse dosyayı yok sayıp siteyi normal şekilde açar. Amaç, güncelleme sırasında yarım dosyaların ziyaretçiye servis edilmesini önlemektir.

İşin mantığı buysa, "sitem günlerdir bakımda" nasıl mümkün oluyor? Çünkü güncelleme normal biterse WordPress dosyayı kendisi siler; bitmezse dosya diskte kalır. Ama sadece kalması yetmez — süre kuralı yüzünden on dakika sonra etkisi geçmesi gerekir. Kalıcı takılmanın gerçek nedenleri aşağıdaki tabloda:

Son iki satır önemlidir. WordPress, kök dizindeki .maintenance dosyası geçerliyken wp-content/maintenance.php adında bir dosya bulursa varsayılan sade mesaj yerine o dosyayı gösterir. Bazı hosting sağlayıcıları ve bakım eklentileri bu dosyayı bırakır. Gördüğünüz ekran logolu, tasarımlı bir "bakımdayız" sayfasıysa muhtemelen bir eklenti ayarıyla karşı karşıyasınız; bu durumda arıza değil, unutulmuş bir ayar söz konusudur ve WordPress bakım modu yazısındaki ayar ekranından kapatılır.

.maintenance Dosyası Tam Olarak Nerede#

Dosya, WordPress'in kök dizinindedir; yani wp-config.php, wp-load.php ve wp-admin klasörünün yanında. Paylaşımlı hostingte bu klasör genellikle şu yollardan biridir:

/home/kullanici/public_html/.maintenance
/home/kullanici/public_html/blog/.maintenance   # WordPress alt dizindeyse
/var/www/vhosts/alanadi.com/httpdocs/.maintenance

Doğru dizinde olduğunuzu anlamanın en kolay yolu, aynı klasörde wp-config.php dosyasını görmektir. Onu görmüyorsanız yanlış yerdesiniz. WordPress'i bir alt dizine kurduysanız (site.com/blog gibi) dosya kök dizinde değil, o alt dizinde olacaktır.

Gizli Dosyaları Görünür Yapmadan Bu Dosyayı Bulamazsınız#

Bu, Türkçe kaynaklarda hiç yazmayan ve en çok zaman kaybettiren adımdır: Linux'ta adı nokta ile başlayan dosyalar gizli kabul edilir ve hem cPanel Dosya Yöneticisi hem FileZilla hem de ls komutu bunları varsayılan olarak listelemez. "Kök dizine baktım, .maintenance diye bir dosya yok" diyen kullanıcıların büyük çoğunluğu aslında dosyaya bakamıyordur.

cPanel Dosya Yöneticisi'nde:

1. cPanel'e girin ve Dosyalar → Dosya Yöneticisi'ni açın.
2. Sağ üstteki Ayarlar (Settings) düğmesine basın.
3. Açılan kutuda Gizli Dosyaları Göster (dotfiles) seçeneğini işaretleyin ve kaydedin.
4. public_html dizinine gidin. Artık .htaccess, .user.ini ve varsa .maintenance listede görünür.

Bu ekranın diğer özellikleri ve dosya düzenleme adımları için cPanel dosya yöneticisi yazısına bakabilirsiniz.

FileZilla'da: Üst menüden Sunucu → Gizli dosyaları göstermeye zorla seçeneğini işaretleyin, sonra dizini yenileyin. Bu ayar bağlantı başına değil, program genelinde geçerlidir; bir kez açtığınızda sonraki bağlantılarda da açık kalır. WinSCP kullanıyorsanız aynı ayar Seçenekler → Panolar altında "Gizli dosyaları göster" olarak geçer.

SSH'ta: ls komutu gizli dosyaları göstermez, -a parametresi gerekir:

cd ~/public_html
ls -la | grep maintenance

Çıktıda şuna benzer bir satır görüyorsanız dosya oradadır:

-rw-r--r--  1 kullanici kullanici    30 Aug 11 14:22 .maintenance

Dosyayı Silme: Üç Yol#

Dosyayı bulduktan sonra silmek saniyeler sürer. Silme işlemi hiçbir veri kaybına yol açmaz; bu dosya sadece bir bayraktır, içinde site verisi yoktur.

SSH ile (en hızlı):

cd ~/public_html
rm -f .maintenance

cPanel Dosya Yöneticisi ile: Gizli dosyaları görünür yaptıktan sonra .maintenance satırına sağ tıklayın ve Sil'i seçin. cPanel dosyayı çöp kutusuna taşımayı önerirse "Dosyayı çöp kutusuna atmadan sil" seçeneğini işaretleyebilirsiniz.

FTP ile: Dosyaya sağ tıklayıp Sil deyin. Silme izniniz yoksa (nadiren olur) önce dosyanın adını .maintenance-eski yapmayı deneyin; WordPress adı tam olarak .maintenance olmayan bir dosyayı umursamaz, dolayısıyla yeniden adlandırmak silmekle aynı etkiyi verir.

Silme işleminden sonra sitenizi gizli pencerede açın. Normal pencerede açarsanız tarayıcı bakım ekranını önbellekten gösterebilir ve boşuna paniklersiniz.

Dosyayı Sildim Ama Site Hâlâ Bakımda Diyor#

Bu durumda sırayla dört şeyi kontrol edin; sorun neredeyse her zaman bu dördünden biridir.

1. Sunucu tarafı önbellek. LiteSpeed Cache, WP Rocket, Varnish veya Cloudflare gibi bir katman bakım ekranını statik olarak kaydetmiş olabilir. Panele giremediğiniz için eklenti üzerinden temizleyemezsiniz; bu yüzden wp-content/cache klasörünün içini FTP'den boşaltın. Cloudflare kullanıyorsanız panelinden Purge Everything yapın. Sunucuda LiteSpeed varsa wp-content/lscache klasörü de aynı şekilde boşaltılabilir.

2. wp-content/maintenance.php dosyası. Bu dosya varsa ve kök dizinde geçerli bir .maintenance yoksa zarar vermez; ama bazı eklentiler bu iki dosyayı birlikte bırakır. Klasörde maintenance.php görüyorsanız adını maintenance.php.yedek yapın ve tekrar deneyin.

3. Sunucu saati ileride. $upgrading değeri gelecekteki bir zamanı gösteriyorsa on dakika kuralı hiç dolmaz. Dosyayı zaten sildiğiniz için bu artık sorun değil, ama saat sapması varsa güncelleme tekrar denendiğinde aynı tuzağa düşersiniz. SSH'ınız varsa date komutuyla sunucu saatini kontrol edin.

4. Bakım modu eklentisi. Gördüğünüz ekran WordPress'in sade metin ekranı değil de tasarımlı bir sayfaysa bir eklenti devrededir. FTP'den /wp-content/plugins/ klasörüne girin, bakım/coming-soon ile ilgili eklentinin klasör adının sonuna -kapali ekleyin. WordPress klasörü bulamayınca eklentiyi otomatik pasife alır.

Bu adımlardan sonra hâlâ bakım mesajı değil de bambaşka bir hata görüyorsanız (beyaz ekran, "Sitenizde kritik bir hata oluştu" gibi) sorun bakım bayrağı değil, yarıda kalan güncellemenin bıraktığı hasardır — bir sonraki bölüm tam olarak bununla ilgili. Kritik hata ekranıyla karşılaştıysanız WordPress kritik hata oluştu yazısı sizi doğrudan hata kaydına yönlendirir.

Asıl İş Şimdi Başlıyor: Yarım Kalan Güncellemeyi Tamamlayın#

Dosyayı silmek siteyi açar ama güncellemeyi tamamlamaz. Bu, konuyla ilgili Türkçe içeriklerin tamamının atladığı noktadır ve atlandığında sonuç şudur: site çalışır görünür, birkaç gün sonra bir eklenti hiç yokmuş gibi davranmaya başlar veya panelde açıklanamayan hatalar çıkar. Aşağıdaki dört kontrolü sırayla yapın.

1. Veritabanı güncellemesini tetikleyin. Çekirdek güncellemesi yarıda kaldıysa dosyalar yeni, veritabanı şeması eski kalmış olabilir. Tarayıcıdan şu adresi açın:

https://alanadiniz.com/wp-admin/upgrade.php

WordPress gerekiyorsa "Veritabanı güncellemesi gerekli" der ve tek düğmeyle işi bitirir; gerek yoksa "Güncelleme gerekli değil" yazar. Her iki cevap da iyidir.

2. Yarım dosyaları temizleyin. WordPress güncelleme sırasında indirdiği paketleri wp-content/upgrade/ klasöründe geçici olarak açar. Güncelleme yarıda kalırsa bu klasörde artıklar kalır. Klasörün içindekileri silin, klasörün kendisini değil:

rm -rf ~/public_html/wp-content/upgrade/*

Aynı şekilde wp-content/plugins/ içinde upgrade-temp-backup ya da rastgele adlı geçici klasörler görürseniz onları da silebilirsiniz.

3. Eksik eklentiyi tespit edin. Güncelleme sırasında WordPress önce eski eklenti klasörünü siler, sonra yenisini açar. Tam bu iki adım arasında kesinti olursa eklenti klasörü diskte hiç kalmaz ve eklenti sessizce devre dışı kalır. Panele girip Eklentiler listesine bakın: güncellemeye çalıştığınız eklenti listede yoksa veya "pasif" görünüyorsa yeniden kurun. Hangi eklentinin etkilendiğini hatırlamıyorsanız listede sürüm numaralarına bakın; diğerleri güncellenmiş, biri eski sürümde kalmışsa suçlu odur.

4. Güncellemeleri tek tek tekrarlayın. Aynı hatayı yapmayın: toplu güncelleme yerine eklentileri birer birer güncelleyin ve her birinin bitmesini bekleyin. SSH erişiminiz varsa bu iş komut satırından hem daha hızlı hem de tarayıcı kopmasından etkilenmez:

wp core update
wp plugin update --all
wp theme update --all
wp core update-db

WP-CLI kullanımının ayrıntıları için WP-CLI kullanımı yazısına bakabilirsiniz. Komut satırından yapılan güncelleme, tarayıcı sekmesine bağlı olmadığı için tam olarak bu arızayı önler.

Bir Daha Yaşamamak İçin Alınacak Önlemler#

Bu arıza tamamen önlenebilir bir arızadır; alışkanlıklarınızda üç küçük değişiklik yeterlidir.

Güncellemeden önce yedek alın. Özellikle çekirdek güncellemelerinde dosya ve veritabanı yedeğini birlikte alın. Yedek varken yarım kalan bir güncelleme on dakikalık bir sorundur; yedek yokken bir günlük.

Toplu güncelleme yapmayın. Panelde tüm eklentileri seçip "Güncelle" demek pratik görünür ama tek bir kesinti hepsini birden riske atar. Beş eklentiyi tek tek güncellemek bir dakika fazla sürer, karşılığında arıza ihtimalini neredeyse sıfırlar.

Güncellemeyi sitenin sessiz olduğu saatte yapın. PHP işlem sınırlarına takılan veya zaman aşımına uğrayan güncellemeler, sunucunun yoğun olduğu saatlerde çok daha sık görülür.

Önce staging ortamında deneyin. Kritik bir e-ticaret sitesinde eklenti güncellemesini doğrudan canlıda yapmak gereksiz bir risktir. Kopya bir ortamda güncelleyip her şeyin çalıştığını gördükten sonra canlıya geçmek, hem bu arızayı hem de uyumsuzluk kaynaklı bozulmaları önler. Kurulumu için WordPress staging ortamı yazısına göz atın.

Güncelleme sırasında sekmeyi kapatmayın. Ekranda dönen daire varken sayfayı yenilemek, sekmeyi kapatmak veya "geri" tuşuna basmak bu arızanın bir numaralı sebebidir. İşlem bitene kadar bekleyin; uzun sürüyorsa bile bekleyin.

Sıkça Sorulan Sorular#

.maintenance dosyasını silmek siteme zarar verir mi#

Hayır, bu dosyayı silmek hiçbir veri kaybına yol açmaz. İçinde yalnızca güncellemenin başladığı ana ait bir zaman damgası bulunur; site içeriği, ayarlar veya eklenti verisi taşımaz. WordPress bu dosyayı normal bir güncelleme bittiğinde zaten kendisi siler, siz de aynı işi elle yapmış olursunuz. Silmenin tek sonucu, sitenin ziyaretçilere yeniden açılmasıdır.

Kök dizinde böyle bir dosya göremiyorum#

Büyük ihtimalle gizli dosyalar kapalı olduğu için göremiyorsunuz. Adı nokta ile başlayan dosyalar Linux'ta gizli sayılır ve cPanel Dosya Yöneticisi, FileZilla ile ls komutu bunları varsayılan olarak listelemez. cPanel'de Ayarlar ekranından "Gizli Dosyaları Göster", FileZilla'da Sunucu menüsünden "Gizli dosyaları göstermeye zorla" seçeneğini açın; SSH'ta ise ls -la komutunu kullanın. Ayrıca WordPress alt dizindeyse dosya kök dizinde değil, o alt dizindedir.

Sadece 10 dakika beklesem kendiliğinden düzelir mi#

Çoğu durumda evet, çünkü WordPress zaman damgası 10 dakikadan eskiyse bakım kontrolünü atlar ve siteyi açar. Ancak dosya diskte kalmaya devam eder ve bir sonraki güncelleme denemesinde yeniden tazelenerek aynı ekranı geri getirir. Ayrıca sayfa önbelleği bakım ekranını kaydetmişse süre dolsa bile ziyaretçi eski ekranı görmeye devam eder. Bu yüzden beklemek yerine dosyayı silmek hem kesin hem de kalıcı çözümdür.

Dosyayı sildim, site açıldı ama panelde eksik eklenti var#

Bu beklenen bir sonuçtur ve güncellemenin tam olarak hangi anda kesildiğini gösterir. WordPress bir eklentiyi güncellerken önce eski klasörü siler, sonra yeni sürümü açar; kesinti tam aradaysa eklenti klasörü diskte kalmaz ve eklenti listeden düşer. Çözüm, o eklentiyi panelden yeniden kurmaktır — ayarları veritabanında durduğu için kurulumdan sonra eski yapılandırmanız geri gelir. Kurulum öncesi wp-content/plugins klasöründe yarım kalmış geçici klasör varsa onu da silin.

Bakım mesajı ziyaretçilere çıkıyor ama ben panele girebiliyorum#

Bu, .maintenance dosyası kaynaklı arıza değildir; kurulu bir bakım modu ya da "yakında" eklentisi devrededir. WordPress'in kendi bakım ekranı yönetici dahil herkesi kapıda tutar, oysa eklentiler oturum açmış yöneticiyi geçirir. Eklentiler listesinden bakım/coming-soon ile ilgili eklentiyi bulup ayarından kapatmanız yeterlidir. Panele girebildiğiniz için bu işlem FTP gerektirmez.

Aynı hata güncelleme her denediğimde tekrarlıyor#

Bu durumda sorun bağlantı kopması değil, güncellemenin sunucu sınırlarına takılmasıdır. En sık görülen iki sebep PHP bellek limitinin yetersiz olması ve max_execution_time süresinin dolmasıdır; büyük bir eklenti paketi açılırken süre biterse işlem yarıda kesilir ve dosya geride kalır. Hosting panelinizden PHP bellek limitini yükseltip yürütme süresini artırın, ardından güncellemeyi komut satırından deneyin. Komut satırı güncellemesi web sunucusunun zaman sınırına tabi olmadığı için bu döngüyü kırar.

Güncelleme yarıda kaldıktan sonra dosyaları elle yüklesem olur mu#

Olur, ancak yalnızca doğru sürümü ve doğru klasörleri yüklerseniz. Çekirdek için WordPress'in resmi paketini indirip wp-admin ve wp-includes klasörlerini olduğu gibi değiştirmek, wp-content klasörüne ise dokunmamak gerekir; wp-config.php dosyası da asla üzerine yazılmamalıdır. Yükleme bittikten sonra mutlaka /wp-admin/upgrade.php adresini açarak veritabanı güncellemesini tetikleyin. Bu yöntem işe yarar ama panelden veya komut satırından yapılan normal güncellemeye göre hata payı yüksektir.

Sitem kapalıyken arama motoru sıralamam etkilenir mi#

Kısa süreli bir kapanma sıralamanızı kalıcı olarak etkilemez. WordPress bakım ekranını 503 Service Unavailable durum koduyla ve Retry-After başlığıyla sunar; bu, arama motorlarına "site geçici olarak kapalı, sonra tekrar gel" demenin standart yoludur ve sayfaların dizinden düşmesine yol açmaz. Riskli olan, kapalılığın günlerce sürmesidir. Bu yüzden arızayı fark ettiğiniz gün çözmek, SEO açısından da yeterlidir.

Kapanış#

"Kısa süreliğine bakım için kapalı" mesajı korkutucu görünse de arkasında tek satırlık bir dosya vardır: WordPress güncellemeye başlarken kök dizine .maintenance yazar, normalde bitince siler, kesinti olursa silemez. Çözüm bu dosyayı bulup silmektir; işin zor tarafı dosyayı bulmak, çünkü nokta ile başladığı için varsayılan ayarlarda hiçbir dosya yöneticisinde görünmez. Gizli dosyaları açtıktan sonra iş iki dakikalıktır.

Asıl önemli kısım, dosyayı sildikten sonra durmamaktır: /wp-admin/upgrade.php adresini açıp veritabanı güncellemesini tetikleyin, wp-content/upgrade klasörünü temizleyin, güncelleme sırasında düşen eklentiyi yeniden kurun ve kalan güncellemeleri tek tek tamamlayın. Bu adımları atlarsanız site açılır ama yarım bir kurulumla çalışmaya devam eder. Güncelleme, yedek ve izleme işlerini kendiniz takip etmek istemiyorsanız WordPress bakım hizmeti bu döngüyü sizin yerinize yürütür; güncellemelerin zaman aşımına uğramadığı, kaynak sınırlarının bol olduğu bir ortam arıyorsanız WordPress hosting paketleri bu iş için ayarlanmıştır. Böyle bir arızada kaybedilecek hiçbir şeyin olmaması için ise düzenli ve otomatik bir yedekleme planı en ucuz sigortadır.