Bakım Modu Sayfası Nasıl Olmalı? 503 Kodu, Retry-After ve Kullanıcı Mesajı

Talha Aslan ve ekibi olarak yıllardır site yenileme, sunucu taşıma ve büyük güncelleme işlerinde bu ekranı kuruyoruz. Gördüğümüz en yaygın sorun şu: sayfa güzel görünüyor, ancak sunucu arka planda 200 kodu döndürüyor. Dolayısıyla Google, bakım ekranını sitenin gerçek içeriği sanabiliyor. Bu rehberde teknik tarafı, metin tarafını ve tasarım tarafını birlikte ele alıyoruz. Genel 503 hatasının nedenlerini merak ediyorsanız 503 Service Unavailable hatası rehberimize bakabilirsiniz; burada yalnız planlı bakımı konuşuyoruz.

Bakım modu sayfası neden 200 yerine 503 kodu döndürmeli?

HTTP durum kodu, sunucunun her isteğe eklediği kısa bir etikettir. 200 "her şey yolunda, içerik bu" anlamına gelir. 503 ise "hizmet şu an geçici olarak kullanılamıyor" der. Bakım ekranınız 200 ile dönerse arama motoru o ekranı sayfanın yeni hali olarak değerlendirebilir. Böylece ürün sayfanızın başlığı yerine "Kısa bir aradayız" gibi bir metin dizine girebilir.

Google, geçici kapanışlar için 503 kodunu açıkça öneriyor. Google Search Central'ın çevrimiçi işletmeyi duraklatma rehberi, acil ve kısa kapanışlar için 503 hata sayfasını ve statik HTML kullanmayı tavsiye ediyor. Üstelik 5xx kodları Googlebot'a tarama hızını geçici olarak düşürmesini de söyler; yani sunucunuz bakım sırasında gereksiz yük almaz.

• 200 ile bakım ekranı: Arama motoru geçici metni kalıcı içerik sanabilir.
• 302 ile bakım sayfasına yönlendirme: Tüm adresler tek bir sayfaya akar ve sinyal karışır.
• 404 ile bakım ekranı: Sayfanın artık olmadığını söyler, bu da yanlış bir mesajdır.
• 503 ile bakım ekranı: Geçici durumu doğru anlatır ve önerilen yoldur.

Retry-After başlığı ne işe yarar?

Retry-After, sunucunun 503 yanıtına eklediği ve "şu kadar sonra tekrar dene" diyen bir HTTP başlığıdır. MDN'nin Retry-After belgesine göre başlık iki biçimde yazılabilir: saniye cinsinden bir bekleme süresi ya da kesin bir tarih ve saat. Ayrıca MDN, Googlebot gibi bazı tarayıcıların bu başlığa uyduğunu belirtiyor.

Pratikte iki seçeneğiniz var:

1. Saniye değeri: Bakım süresini tahmin edebiliyorsanız örneğin 3600 yazarsınız; bu bir saat demektir.
2. Tarih değeri: Bitiş saatini biliyorsanız GMT biçiminde kesin bir zaman verirsiniz.
3. Gerçekçi tahmin: Süreyi biraz geniş tutarsınız, çünkü tarayıcının erken dönüp yine 503 görmesi bir yarar sağlamaz.

Öte yandan Retry-After bir söz değildir. Google rehberi de bu başlıkta "en iyi tahmininizi" vermenizi istiyor. Dolayısıyla süre uzarsa değeri güncelleyin; eski bir tarih bırakmayın.

Bakım ne kadar sürerse bakım modu sayfası risk yaratır?

Kısa cevap: birkaç saat ile bir iki gün arası genellikle güvenli bölgedir, daha uzun süre ise risklidir. Google'ın tarama hızını azaltma belgesi 500, 503 ve 429 kodlarının bir iki günden uzun kullanılmasını önermiyor. Aynı belge, Googlebot aynı adreste bu kodları birkaç gün boyunca görürse adresin dizinden düşebileceğini de söylüyor.

Ayrıca işletmeyi duraklatma rehberi, siteyi tamamen kapatmayı "en fazla birkaç gün" için düşünülmesi gereken uç bir önlem olarak tanımlıyor. Rehbere göre uzun bir kapanıştan sonra eski görünürlüğe dönmek belirgin biçimde zorlaşıyor. Bunun yanında site 503 döndürdüğü sürece Google başlıkları, açıklamaları ve yapılandırılmış veriyi yenileyemiyor.

Bizim saha tecrübemiz de aynı yönde, ancak bunu bir garanti olarak değil bir başlangıç ölçüsü olarak okuyun. Bakımı saatlerle ölçebiliyorsanız 503 doğru araçtır. Günlerle ölçüyorsanız siteyi kapatmak yerine kısmi bakım planlamanız daha güvenli olur. Tarama davranışını daha geniş görmek için Googlebot neden daha az tarar yazımızı okuyabilirsiniz.

robots.txt dosyası bakım sırasında neden 503 vermemeli?

Bu, en sık atlanan ayrıntıdır. Birçok bakım eklentisi ya da sunucu kuralı, istisnasız her adrese 503 döndürür. Böylece robots.txt dosyası da 503 alır. Google'ın işletmeyi duraklatma rehberi bunu açıkça yasaklıyor: robots.txt için 503 döndürmek tüm taramayı engeller.

Peki neden? Google'ın robots.txt belirtimine göre robots.txt 5xx hatası verdiğinde Google ilk 12 saat boyunca siteyi taramayı bırakır ve yalnız robots.txt dosyasını yeniden almayı dener. Sonraki 30 gün içinde son geçerli kopyayı kullanır. Yani kısa bir bakım bile robots.txt yüzünden tarama tarafında gereğinden uzun bir boşluk açabilir.

Bu nedenle bakım kuralınıza şu istisnaları ekleyin:

• robots.txt dosyası normal biçimde 200 ile dönsün.
• Site haritası dosyalarını kapatmanız gerekmiyorsa açık bırakın.
• Bakım sayfasının kullandığı stil dosyası, logo ve yazı tipi 200 ile yüklensin; aksi halde ekran bozuk görünür.
• Sizin ekibinizin IP adresi bakım kuralının dışında kalsın, böylece testleri canlı ortamda yapabilirsiniz.

Bakım modu sayfasında kullanıcıya hangi mesaj verilmeli?

İyi bir mesaj dört soruya kısa cevap verir: ne oluyor, neden oluyor, ne zaman bitecek ve şimdi ne yapabilirim. Ziyaretçi bu dört cevabı birkaç saniyede bulmalı. Uzun bir özür metni ya da teknik bir açıklama burada işe yaramaz.

Örnek bir kurgu şöyle olabilir:

1. Başlık: "Sitemizi güncelliyoruz" gibi durumu söyleyen tek bir cümle.
2. Açıklama: Bir iki cümleyle neden kapalı olduğunuz; örneğin ödeme altyapısını yeniliyoruz.
3. Süre: Tahmini bitiş saati ve saat dilimi.
4. Alternatif: Telefon, e-posta ya da mağaza adresi gibi açık kalan kanal.
5. Güvence: Mevcut siparişlerin ya da randevuların etkilenip etkilenmediği.

Ayrıca tonu marka sesinize uydurun, ama şaka yapmadan önce iki kez düşünün. Siparişi takılan bir müşteri için esprili bir hata ekranı sinir bozucu olabilir. Kısacası net, sakin ve saygılı bir dil her sektörde güvenli seçimdir.

Metni yazdıktan sonra sesli okuyun. Okurken takıldığınız her cümle, ziyaretçinin de takılacağı bir yerdir. Teknik terimleri, sürüm numaralarını ve iç ekip dilini metinden çıkarın. Ziyaretçi "veritabanı göçü" kelimesini değil, ne zaman alışverişe devam edebileceğini merak eder. Bu yüzden her cümleyi okurun sorusuna göre süzün.

Süre bilgisini bakım modu sayfasında nasıl yazmalısınız?

Süre bilgisi, ziyaretçinin geri dönüp dönmeyeceğini belirler. "Yakında döneceğiz" ifadesi hiçbir şey söylemez. Buna karşılık "Bugün saat 14.00'te tekrar açığız (Türkiye saati)" cümlesi okura plan yapma imkânı verir.

Süreyi yazarken şu noktalara dikkat edin:

• Saat dilimini mutlaka belirtin; yurt dışından gelen ziyaretçi için bu önemlidir.
• Kesin saat veremiyorsanız bir aralık verin, örneğin "13.00 ile 15.00 arasında".
• Sayfadaki saat ile Retry-After değeri birbirini tutsun.
• Süre uzarsa metni hemen güncelleyin; geçmiş bir saat okura güven vermez.

Öte yandan geri sayım sayacı cazip görünse de dikkatli olun. Sayaç sıfıra indiğinde site hâlâ kapalıysa ziyaretçi bunu bir hata olarak görür. Bu yüzden sayaç yerine sade bir saat bilgisi çoğu durumda daha dürüsttür. Sayaç kullanacaksanız sıfıra inince metni "Son kontrolleri yapıyoruz" gibi bir cümleye çeviren bir davranış ekleyin.

Alternatif iletişim kanalları sayfada nasıl sunulur?

Bakım sırasında bile işiniz devam eder. Bu yüzden ziyaretçinin acil ihtiyacını karşılayacak bir yol bırakmanız gerekir. Örneğin bir klinik için randevu telefonu, bir e-ticaret sitesi için müşteri hizmetleri e-postası, bir restoran için sipariş hattı bu işi görür.

Kanalları sunarken şunlara dikkat edin:

• Telefon numarasını tıklanabilir bağlantı olarak verin, mobilde tek dokunuşla arama yapılsın.
• E-posta adresini düz metin olarak da gösterin; bazı kullanıcılar kopyalamak ister.
• Sosyal medya hesaplarınızda bakım duyurusu varsa ona bağlantı verin.
• Çalışan kanalın saatlerini yazın; gece arayan biri boşluğa düşmesin.

Ayrıca bakım sayfasından kapalı olan iletişim formuna bağlantı vermeyin. Bu, ziyaretçiyi ikinci bir hata ekranına gönderir. Benzer şekilde canlı sohbet aracı bakım altyapısıyla birlikte kapanıyorsa onu sayfada göstermeyin.

Bakım modu sayfası nasıl tasarlanmalı?

Bakım ekranı, sitenin geri kalanından bağımsız çalışmalıdır. Google rehberi de bu yüzden statik HTML öneriyor. Veritabanına, içerik yönetim sistemine ya da ağır betiklere bağlı bir sayfa, tam da bakım sırasında bozulabilir. Dolayısıyla tek bir HTML dosyası, gömülü küçük bir stil bloğu ve hafif bir logo yeterlidir.

Tasarım tarafında önerimiz şunlar:

• Marka tutarlılığı: Logo, renk ve yazı tipi sitenizle aynı olsun; ziyaretçi doğru yerde olduğunu anlasın.
• Tek odak: Ekranda tek bir başlık, kısa bir açıklama ve iletişim bilgisi bulunsun.
• Hafiflik: Büyük görsel, video ve dış kaynaktan yüklenen dosya kullanmayın.
• Mobil öncelik: Ziyaretçilerin önemli bir kısmı telefondan gelir; metin küçük ekranda rahat okunmalı.

Bunu sitenizde biz kurarız: bakım ekranını markanıza uygun tasarlıyor ve sunucu kuralıyla birlikte test ediyoruz. Kapsam ve fiyat için web tasarım hizmetimiz üzerinden teklif isteyebilirsiniz.

Bakım ekranı erişilebilir mi, herkes okuyabiliyor mu?

Erişilebilirlik bakım sayfasında da geçerlidir. Ekran okuyucu kullanan bir ziyaretçi de neyin olduğunu ve ne zaman biteceğini öğrenmelidir. Bu nedenle mesajı görselin içine gömmeyin; metni gerçek HTML metni olarak yazın.

Kısa bir erişilebilirlik kontrolü şöyle olabilir:

• Sayfanın dil özniteliği doğru olsun, böylece ekran okuyucu metni doğru telaffuz eder.
• Başlık hiyerarşisi tek bir ana başlıkla başlasın.
• Metin ile arka plan arasında yeterli kontrast bulunsun; W3C'nin WCAG yönergeleri bu konuda ölçüt verir.
• Logo için anlamlı bir alternatif metin yazın.
• Telefon ve e-posta bağlantılarının metni ne yaptığını söylesin, "buraya tıklayın" gibi belirsiz ifadeler kullanmayın.

Ayrıca otomatik yenilenen sayfalara dikkat edin. Her birkaç saniyede kendini yenileyen bir bakım ekranı, ekran okuyucu kullanıcısının metni baştan dinlemesine neden olur. Yenileme gerekiyorsa aralığı uzun tutun ya da ziyaretçiye bırakın.

Tam kapanış mı, kısmi bakım mı daha doğru?

Her bakım tüm siteyi kapatmayı gerektirmez. Çoğu zaman yalnız bir bölümü kapatmak yeterlidir. Örneğin ödeme sistemini güncelliyorsanız ürün sayfalarını açık tutup yalnız sepeti geçici olarak devre dışı bırakabilirsiniz. Google'ın işletmeyi duraklatma rehberi de siteyi tamamen kapatmak yerine işlevi sınırlamayı öneriyor.

Tablodan da anlaşılacağı gibi, en iyi bakım modu sayfası çoğu zaman hiç görünmeyen sayfadır. Böylece hem ziyaretçi hem tarayıcı kesintiden en az etkilenir.

E-ticaret sitesinde bakım nasıl planlanır?

E-ticarette bakımın bedeli daha yüksektir, çünkü kapalı geçen her saat kaçan sipariş demektir. Bu yüzden zamanlamayı verinize göre seçin. Analitik panelinizde trafiğin en düşük olduğu saatleri bulun ve bakımı o pencereye koyun.

Örnek senaryo: Bir giyim mağazası ödeme sağlayıcısını değiştirecek. Ekip, ürün ve kategori sayfalarını açık bırakıyor, yalnız sepet ve ödeme adımını kapatıyor. Sepet sayfasında kısa bir bilgi kutusu, ödemenin hangi saatte açılacağını ve müşteri hizmetleri numarasını gösteriyor. Böylece ziyaretçi ürünlere göz atmaya ve favori listesine eklemeye devam ediyor.

Ayrıca reklam tarafını unutmayın. Reklamlarınız tamamen kapalı bir siteye trafik gönderirse bütçe boşa gider ve hedef sayfa hataları oluşabilir. Dolayısıyla tam kapanış planlıyorsanız reklam kampanyalarını aynı pencerede duraklatmayı planınıza ekleyin. Kampanya ayarlarının ayrıntısı için reklam platformunun resmi yardım sayfasını kontrol edin.

Bunun yanında açık siparişleri olan müşterileri de düşünün. Kargo takibi ya da sipariş durumu sayfası bakım sırasında kapanıyorsa bakım ekranında bunu açıkça söyleyin. Örneğin "Mevcut siparişleriniz etkilenmiyor, kargo bilgisi e-posta ile gelmeye devam ediyor" gibi bir cümle, müşteri hizmetlerine gelen soru sayısını azaltır. Ayrıca bakım saatini kampanya dönemlerine denk getirmemeye özen gösterin.

Bakım öncesinde ziyaretçiye nasıl haber vermelisiniz?

En iyi bakım mesajı, bakım başlamadan önce gelen mesajdır. Düzenli müşterileriniz varsa onları önceden bilgilendirmek, bakım ekranıyla karşılaşma şokunu azaltır. Üstelik bu, şeffaf bir marka algısı oluşturur.

1. Birkaç gün önce: Sitenin üst kısmına ince bir duyuru şeridi koyun ve tarihi yazın.
2. Bir gün önce: Üyelerinize ya da bülten abonelerinize kısa bir e-posta gönderin.
3. Bakım günü: Sosyal medya hesaplarınızda kısa bir paylaşım yapın.
4. Bakım bitince: Duyuru şeridini kaldırın ve gerekiyorsa "yenilendik" mesajı verin.

Öte yandan duyuruyu abartmayın. Küçük bir güncelleme için tüm müşterilere e-posta göndermek gereksiz endişe yaratabilir. Kısacası iletişimin büyüklüğü, kesintinin büyüklüğüyle orantılı olsun.

Hangi hatalar bakım modu sayfasını işe yaramaz hale getirir?

Sahada en sık gördüğümüz hatalar teknik değil, gözden kaçan küçük ayrıntılardır. Aşağıdaki liste, kendi kontrolünüzü yaparken başlangıç noktası olabilir.

• Yanlış durum kodu: Ekran güzel ama sunucu 200 döndürüyor.
• Robots.txt da kapalı: Bakım kuralı istisnasız her adrese 503 veriyor.
• Süresiz mesaj: "Yakında döneceğiz" yazıyor, saat yok.
• Unutulan bakım: İş bitti ama bakım eklentisi açık kaldı.
• Bozuk görünüm: Stil dosyası da bakım kuralına takıldı, sayfa düz metin olarak açılıyor.
• Yönetici bile giremiyor: İstisna kuralı yok, ekip testi canlı ortamda yapamıyor.

Bu hataların çoğunu tek bir kontrolle yakalarsınız: bakımı açtıktan sonra farklı bir ağdan siteyi ziyaret edin ve tarayıcının geliştirici araçlarında yanıt kodunu kontrol edin. Ayrıca robots.txt adresini ayrı olarak açın. Böylece hem insan hem tarayıcı gözünden sayfayı görmüş olursunuz.

Uzun süreli bakım veya kapanışta ne yapmalısınız?

Bakım bir iki günü aşacaksa 503 artık doğru araç değildir. Bu durumda siteyi açık tutup işlevi sınırlamak daha güvenli olur. Örneğin bir mağaza, sipariş almayı durdurup ürün sayfalarına "şu an sipariş almıyoruz" bilgisini ekleyebilir. Böylece sayfalar 200 ile döner ve dizinde kalmaya devam eder.

Uzun kapanış için şu adımları değerlendirin:

• Sepeti ve ödeme adımını kapatın, ama içerik sayfalarını açık bırakın.
• Her sayfanın üstüne durumu ve tahmini dönüş tarihini anlatan bir bilgi şeridi ekleyin.
• Google İşletme Profili kullanıyorsanız çalışma saatlerinizi ve geçici kapanış durumunuzu oradan güncelleyin.
• Yapılandırılmış verideki stok veya etkinlik bilgisi gerçeği yansıtsın.

Ayrıca tasarım yenileme gibi uzun işleri canlı sitede yapmayın. Hazırlık ortamında çalışıp hazır olunca kısa bir geçişle yayına almak, uzun bir bakım ekranından her zaman daha iyidir. Taşıma sürecinin ayrıntıları için hosting değiştirme ve site taşıma kontrol listemize göz atabilirsiniz.

Bakım bittikten sonra neleri kontrol etmelisiniz?

Bakımı kapatmak işin sonu değildir. Asıl risk, bakım sonrasında fark edilmeyen sorunlardır. Bu yüzden siteyi yeniden açar açmaz kısa bir kontrol turu yapın.

1. Ana sayfa, kategori ve ürün sayfaları 200 kodu ile dönüyor mu?
2. Robots.txt ve site haritası doğru içerikle açılıyor mu?
3. Önbellek temizlendi mi; ziyaretçi hâlâ bakım ekranını görüyor mu?
4. Formlar, sepet ve ödeme adımı uçtan uca çalışıyor mu?
5. Search Console'da tarama hataları ya da sunucu hatası artışı var mı?

Önbellek maddesi özellikle önemlidir. Bazı içerik dağıtım ağları ve önbellek eklentileri bakım ekranını saklayabilir. Böylece siz siteyi açtığınız halde bazı ziyaretçiler bir süre daha bakım sayfasını görür. Ayrıca bakım sırasında yanlışlıkla boş içerikle dönen sayfalar, soft 404 sorununa yol açabilir; bunu da kontrol listenize ekleyin.

Bakım modu sayfası tarama bütçesini etkiler mi?

Kısa bir 503 tarama bütçesini kalıcı olarak etkilemez, ama geçici bir yavaşlama yaratır. Google'ın ağ hataları belgesine göre 5xx yanıtları tarayıcıların taramayı geçici olarak yavaşlatmasına neden olur. Sunucu yeniden 2xx yanıt vermeye başlayınca Google tarama hızını kademeli olarak artırır.

Yani küçük ve orta ölçekli bir site için birkaç saatlik planlı bakım genellikle sorun yaratmaz. Öte yandan on binlerce sayfası olan bir haber sitesi ya da büyük bir mağaza için toparlanma süresi daha belirgin olabilir. Bu tür sitelerde bakımı kısa tutmak ve mümkünse kısmi bakımı tercih etmek daha mantıklıdır.

Tarama bütçesinin hangi sitelerde gerçekten önemli olduğunu tarama bütçesi rehberimizde ayrıntılı anlattık. Kendi sitenizin ölçeğini bilmek, bakım planınızı da şekillendirir. Kısacası büyük siteler bakım süresine küçük sitelerden daha duyarlıdır.

Örnek senaryo: Bir hizmet sitesinde planlı bakım nasıl yürür?

Örnek senaryo: Bir mimarlık ofisi, sitesini yeni bir sunucuya taşıyacak. Ekip, trafiğin en düşük olduğu pazar sabahını seçiyor. İki gün önce sitenin üstüne "Pazar 08.00 ile 10.00 arası bakım" duyurusu ekliyor.

Bakım sabahı ekip, sunucu kuralıyla tüm sayfalara 503 ve iki saatlik Retry-After değeri veriyor. Robots.txt ve bakım sayfasının stil dosyası istisna listesinde kalıyor. Ekranda ofisin logosu, "Sitemizi yeni sunucuya taşıyoruz" başlığı, bitiş saati ve ofis telefonu var.

Taşıma bir saat erken bitiyor. Ekip bakım kuralını kaldırıyor, önbelleği temizliyor ve kontrol listesini adım adım uyguluyor. Ardından Search Console'da birkaç gün boyunca tarama istatistiklerini izliyor. Bu senaryo bir örnek kurgudur; ancak adımların sırası çoğu planlı bakım için geçerlidir.

Bakım eklentisi mi, sunucu kuralı mı tercih etmelisiniz?

İki yolun da yeri var. Bakım eklentisi, içerik yönetim sisteminin içinden çalışır ve kurulumu kolaydır. Ancak eklenti sistemin kendisine bağlıdır; bakım tam da o sistemi güncellerken yapılıyorsa eklenti de devre dışı kalabilir. Sunucu kuralı ise içerik yönetim sisteminden önce devreye girer, bu yüzden altyapı işlerinde daha güvenilirdir.

Seçim yaparken şu soruları sorun:

• Bakım sırasında içerik yönetim sistemi çalışmaya devam edecek mi?
• Eklenti hangi durum kodunu döndürüyor ve Retry-After başlığı ekleyebiliyor mu?
• Robots.txt ve stil dosyaları için istisna tanımlayabiliyor musunuz?
• Ekibinizin IP adresini bakım ekranının dışında tutabiliyor musunuz?

Örneğin küçük bir eklenti güncellemesi için eklenti tabanlı bakım yeterli olabilir. Öte yandan sunucu taşıma, veritabanı yenileme ya da PHP sürümü değişikliği gibi işlerde sunucu kuralı daha sağlam bir seçimdir. Hangi yolu seçerseniz seçin, bakımı açtıktan sonra yanıt kodunu kendiniz kontrol edin. Kısacası aracın ne vaat ettiğine değil, sunucunun gerçekte ne döndürdüğüne bakın.

Çok dilli bir sitede bakım ekranı nasıl hazırlanır?

Çok dilli sitelerde bakım ekranı da ziyaretçinin dilinde konuşmalıdır. İngilizce içerik arayan biri Türkçe bir bakım ekranı görürse ne olduğunu anlamayabilir. Bu yüzden her dil sürümü için ayrı bir bakım metni hazırlayın ya da tek sayfada dilleri kısa bloklar halinde sıralayın.

Pratik önerilerimiz şunlar:

• Her dil bloğunun kendi dil özniteliği olsun, böylece ekran okuyucular doğru telaffuz eder.
• Saat bilgisini her dilde o dilin okurunun anlayacağı biçimde yazın ve saat dilimini ekleyin.
• İletişim kanalları dile göre değişiyorsa her blokta doğru numarayı verin.
• Metni makine çevirisine bırakmayın; kısa olduğu için doğru çeviriyi elle hazırlamak kolaydır.

Ayrıca alt klasör ya da alt alan adı yapınıza göre bakım kuralını planlayın. Örneğin yalnız bir dil sürümünü güncelliyorsanız diğer dilleri açık bırakabilirsiniz. Böylece kesintinin etkisi yalnız ilgili kitleyle sınırlı kalır. Dolayısıyla çok dilli sitede kısmi bakım, tam kapanıştan çoğu zaman daha akıllıca bir seçimdir.

Bakım modu sayfası kontrol listesi nasıl görünür?

Bakımdan önce aşağıdaki listeyi tek tek işaretleyin. Liste kısa görünse de her madde sahada karşılaştığımız bir sorunu önler.

• Bakım ekranı 503 durum kodu ile dönüyor.
• Retry-After başlığı gerçekçi bir süre ya da tarih içeriyor.
• Robots.txt 200 ile dönüyor ve bakım kuralının dışında.
• Sayfa statik HTML; veritabanına bağlı değil.
• Mesaj ne olduğunu, ne zaman biteceğini ve nasıl ulaşılacağını söylüyor.
• Saat dilimi yazılı ve sayfadaki saat Retry-After ile uyumlu.
• Telefon ve e-posta bağlantıları mobilde çalışıyor.
• Kontrast, dil özniteliği ve başlık yapısı erişilebilir.
• Ekip IP adresi istisna listesinde.
• Bakım sonrası kontrol ve önbellek temizliği planlandı.

Bu listeyi düzenli bakım rutininizin bir parçası yapabilirsiniz. Aylık bakımda neleri kontrol ettiğimizi web sitesi bakımı rehberimizde anlattık.

Bakım ekranını kendiniz mi kurmalısınız, ekip desteği mi almalısınız?

Basit bir site için bakım eklentisi ve doğru ayarlar çoğu zaman yeterlidir. Ancak eklentinin hangi durum kodunu döndürdüğünü ve robots.txt dosyasını istisna tutup tutmadığını mutlaka kontrol edin. Bazı eklentiler bu ayarları varsayılan olarak kapalı getirebilir; güncel davranış için eklentinin kendi belgelerine bakın.

Öte yandan sunucu taşıma, altyapı değişikliği ya da çok dilli bir sitede bakım gibi işler daha fazla planlama ister. Bu tür projelerde bakım ekranı, işin yalnız görünen kısmıdır. Asıl iş; zamanlama, yedek, geri dönüş planı ve bakım sonrası testtir.

Siteniz için bakım ekranını, sunucu kuralını ve geçiş planını birlikte kurmamızı isterseniz web tasarım hizmeti sayfamızdan proje ayrıntılarınızı paylaşarak teklif alabilirsiniz. Böylece bakım günü sürprizlerle değil, kontrol listesiyle geçer.