Web sitesi bakım hizmeti, yalnızca metin veya görsel değiştirmek değildir. Sağlıklı bir bakım kapsamı; yazılım güncellemelerini, güvenlik kontrollerini, yedekleme ve geri dönüşü, form ve iletişim akışlarını, performansı, alan adı ve SSL takibini, ölçüm etiketlerini ve yapılan işlemlerin raporlanmasını birlikte ele alır. İşletme için asıl soru ‘bakım var mı?’ değil, hangi risklerin kim tarafından, ne sıklıkla ve hangi geri dönüş planıyla yönetildiğidir.
Bakım sözleşmesi hazırlanırken site türü, kullanılan yazılım, trafik ve satış önemi, üçüncü taraf entegrasyonlar ve içerik güncelleme sıklığı değerlendirilmelidir. Bir kurumsal tanıtım sitesiyle yoğun sipariş alan bir e-ticaret sitesinin bakım ihtiyacı aynı değildir. Bu rehber hukuki ya da siber güvenlik danışmanlığının yerine geçmez; teklif kapsamını karşılaştırmak isteyen işletmeler için uygulanabilir bir kontrol çerçevesi sunar.
1. Yazılım ve güvenlik güncellemeleri
İçerik yönetim sistemi, eklentiler, sunucu paketleri ve özel yazılım bağımlılıkları zaman içinde güncellenir. Bakım kapsamında hangi bileşenlerin izlendiği, güncellemenin önce test ortamında denenip denenmediği ve sorun çıkarsa kimin geri dönüş yaptığı yazılı olmalıdır. Her yeni sürümü aynı gün kurmak da güncellemeleri belirsiz süre ertelemek de tek başına doğru yaklaşım değildir; risk, uyumluluk ve işletme etkisi birlikte değerlendirilir.
Güvenlik kontrolü yalnız ‘site açılıyor’ testinden ibaret değildir. Yönetici hesapları, yetkiler, oturum açma hareketleri, güvenlik günlükleri, başarısız girişler, bilinen açıklar ve gereksiz bileşenler düzenli gözden geçirilmelidir. NIST Siber Güvenlik Çerçevesi 2.0, riski yönetme sürecini Govern, Identify, Protect, Detect, Respond ve Recover işlevleriyle ele alır. Küçük bir web sitesi bakım planı bu çerçevenin tamamını uygulamak zorunda değildir; ancak koruma, tespit, müdahale ve kurtarma sorumluluklarını görünür kılması iyi bir başlangıçtır.
2. Yedekleme ile geri yükleme aynı şey değildir
Yedek alınması tek başına yeterli değildir. Yedeğin nerede tutulduğu, kaç sürüm saklandığı, veritabanı ile medya dosyalarının birlikte kapsanıp kapsanmadığı, erişimin kimde olduğu ve geri yükleme testinin ne zaman yapıldığı bilinmelidir. Aynı sunucuda tutulan tek kopya, sunucu arızasında veya hesap erişimi kaybında beklenen korumayı sağlamayabilir.
Bakım teklifinde geri dönüş hedefi açıkça konuşulmalıdır: Son sağlam yedeğe kim karar verecek? Form kayıtları, siparişler veya içerik değişiklikleri geri dönüş sırasında nasıl korunacak? Geri yükleme sonrasında alan adı, SSL, formlar, e-posta gönderimi ve ölçüm etiketleri yeniden kontrol edilecek mi? Bu sorular, ‘günlük yedek’ ifadesinden daha değerlidir.
3. Form, telefon, WhatsApp ve satış akışı kontrolleri
Bir web sitesi teknik olarak açık görünürken müşteri kazanım akışı bozulmuş olabilir. İletişim formu hata verebilir, bildirim e-postası spam klasörüne düşebilir, telefon bağlantısı yanlış numaraya gidebilir veya WhatsApp mesajı eski metni kullanabilir. Bu nedenle bakım kontrolü gerçek bir kullanıcı gibi form gönderimini, hata mesajlarını, teşekkür ekranını ve bildirim teslimini kapsamalıdır.
Ölçüm tarafında da yalnız etiketin sayfada bulunması yeterli değildir. Form başarısı, telefon ve WhatsApp tıklamaları doğru olay adıyla, kişisel veri taşımadan ve çift sayım oluşturmadan izlenmelidir. Reklam platformundaki bir tıklama dönüşümü gerçek iletişim veya satış olarak kabul edilmemeli; satış takibindeki sonuçla ayrıca doğrulanmalıdır.
4. Hız ve sayfa deneyimi nasıl izlenir?
Bakım sırasında yeni görseller, üçüncü taraf kodları ve içerik bileşenleri sayfa deneyimini değiştirebilir. Bu nedenle temel şablonlar ve önemli açılış sayfaları hem laboratuvar araçlarıyla hem mümkünse gerçek kullanıcı verileriyle izlenmelidir. web.dev Core Web Vitals araç akışı, laboratuvar ölçümlerinin tanılama; saha verilerinin ise gerçek kullanıcı deneyimini değerlendirme rolünü açıklar. Tek bir test sonucu başarı veya başarısızlık hükmü değildir.
Bakım kapsamında hangi sayfaların örneklem olarak ölçüleceği, görsel boyutları, önbellek, JavaScript yükü, LCP, INP ve CLS gibi göstergelerin nasıl yorumlanacağı belirtilmelidir. Amaç puan peşinde koşmak değil; kullanıcıların ana içeriği görebilmesini, sayfayla etkileşebilmesini ve arayüzün beklenmedik biçimde kaymamasını sağlamaktır.
5. Planlı bakım ve kesinti yönetimi
Yayın veya altyapı değişikliği sırasında kısa bir kesinti gerekiyorsa kullanıcı ve arama motoru etkisi önceden planlanmalıdır. Google’ın siteyi geçici olarak duraklatma rehberi, mümkün olduğunda siteyi çevrim içi tutup yalnız gerekli işlevi sınırlandırmayı önerir. Kısa süreli tam kesintide uygun 503 yanıtı ve Retry-After başlığı kullanılabilir; uzun süreli 503, tarama ve indeksleme açısından risk oluşturabilir.
Bakım penceresi; başlangıç ve bitiş saati, sorumlu kişi, geri dönüş koşulu ve canlı doğrulama listesiyle yürütülmelidir. Değişiklik bittikten sonra yalnız ana sayfa değil, önemli hizmet sayfaları, form, medya, canonical, sitemap ve yönlendirmeler de kontrol edilir.
6. İçerik, alan adı, SSL ve üçüncü taraf hizmetler
Bakım kapsamının içerik güncellemesi içerip içermediği açık olmalıdır. Metin ve görsel değişikliği, yeni sayfa tasarımı, kampanya landing page’i veya özel geliştirme çoğu zaman rutin bakımdan ayrı iştir. Aynı şekilde alan adı yenilemesi, SSL sertifikası, e-posta hizmeti, CDN, ödeme altyapısı ve lisanslı eklentilerin ücret ve yenileme sorumluluğu taraflar arasında yazılı paylaşılmalıdır.
Üçüncü taraf hizmette yaşanan kesinti tamamen bakım sağlayıcısının kontrolünde olmayabilir. Buna rağmen izleme, bildirim, geçici çözüm ve servis sağlayıcıyla iletişim sorumluluğu tanımlanabilir. Böylece işletme ‘sorun kimde?’ tartışması yerine uygulanacak adımı bilir.
İFİ Yazılım uygulama notu
İFİ Yazılım’da bakım değerlendirmesini yalnız sürüm güncellemesi olarak ele almıyoruz. Önce sitenin işletme için değerli eylemlerini belirliyor; form, telefon, WhatsApp, randevu veya satış akışındaki kritik noktaları çıkarıyoruz. Ardından yedek, güvenlik, yayın, performans ve ölçüm kontrollerini bu akışlara göre önceliklendiriyoruz. Bir değişiklikten önce hedef kayıt ve geri dönüş yolu; değişiklikten sonra canlı URL, medya, form ve ölçüm davranışı doğrulanıyor.
Yeni veya yenilenecek bir sitede bakım sorumluluklarını geliştirme aşamasında belirlemek, yayın sonrasında belirsizliği azaltır. Web Tasarım ve Geliştirme hizmeti kapsamında altyapı, yönetilebilir içerik, ölçüm ve yayın sonrası destek ihtiyacı birlikte değerlendirilir.
Bakım teklifi alırken sorulacak 12 soru
- Hangi yazılım, eklenti ve sunucu bileşenleri izleniyor?
- Güncellemeler önce nerede ve nasıl test ediliyor?
- Yedekler hangi sıklıkta, nerede ve kaç sürüm tutuluyor?
- Geri yükleme testi ve sorumlusu kim?
- Güvenlik olayı nasıl tespit edilip bildiriliyor?
- Form, e-posta, telefon ve WhatsApp kontrolleri dahil mi?
- Performans hangi sayfalarda ve hangi verilerle izleniyor?
- İçerik değişikliği ile yeni geliştirme nasıl ayrılıyor?
- Alan adı, SSL, lisans ve üçüncü taraf ücretlerinden kim sorumlu?
- Planlı kesinti ve geri dönüş prosedürü nedir?
- Yapılan işlemler hangi raporla paylaşılacak?
- Acil destek kanalı ve yanıt kapsamı nedir?
Bu sorulara verilen açık yanıtlar, farklı teklifleri yalnız fiyatla değil kapsam, risk ve sorumluluk bakımından karşılaştırmanızı sağlar. Bakımın sonucu her ay görünür bir tasarım değişikliği olmayabilir; önemli olan sitenin kritik işlevlerinin izlenmesi, sorunların kayıt altına alınması ve gerektiğinde kontrollü biçimde geri dönebilecek bir çalışma düzenidir.
