Web Sitesi Bakım Maliyeti Nelerden Oluşur?

Kısa özet: Web sitesi bakım maliyeti yalnızca hosting ücretinden oluşmaz. Güvenlik güncellemeleri, framework ve paket güncellemeleri, yedekleme, geri yükleme testleri, uptime ve hata izleme, performans kontrolleri, SEO takibi, içerik desteği ve sürüm yükseltmeleri bakım kapsamının farklı parçalarıdır. Bir sitenin bugün çalışıyor olması, gelecekte güncellenmeden güvenli ve sorunsuz çalışmaya devam edeceği anlamına gelmez.

Kısa doğrudan cevap

Web sitesi bakım maliyeti temel olarak şu kalemlerden oluşur:

• Hosting, domain, SSL ve altyapı hizmetleri
• Güvenlik ve bağımlılık güncellemeleri
• Framework, CMS, tema ve eklenti bakımı
• Yedekleme ve geri yükleme testleri
• Uptime, hata ve performans izleme
• Kritik hata müdahalesi
• İçerik ve yönetim paneli desteği
• Teknik SEO kontrolleri
• Büyük sürüm yükseltmeleri ve teknik modernizasyon

“Site çalışıyor, neden bakım ücreti ödüyorum?” sorusunun cevabı şudur: Bakım hizmeti yalnızca bozuk bir siteyi onarmak için değil, sitenin bozulmasını, güvenlik açığı taşımasını, veri kaybetmesini ve işletme açısından kritik bir anda erişilemez hale gelmesini önlemek için alınır.

Web sitesi bakımı nedir?

Web sitesi bakımı; yayında bulunan bir web sitesinin güvenli, erişilebilir, güncel, ölçülebilir ve işlevsel kalması için düzenli olarak yürütülen teknik ve operasyonel çalışmalardır. Bakım yalnızca şu işlemlerden oluşmaz:

• Metin değiştirmek
• Görsel eklemek
• Bozuk bir butonu düzeltmek
• Site kapanınca yeniden açmak

Daha kapsamlı bir bakım süreci şunları içerir:

• Kullanılan yazılım sürümlerini takip etmek
• Güvenlik duyurularını kontrol etmek
• Bağımlılıkları güncellemek
• Güncellemeleri test etmek
• Site erişilebilirliğini izlemek
• Uygulama hatalarını takip etmek
• Yedek almak
• Yedeklerin geri yüklenebildiğini doğrulamak
• Performans gerilemelerini tespit etmek
• Arama motoru görünürlüğünü izlemek
• Form, ödeme ve entegrasyonları kontrol etmek
• Kritik durumda müdahale etmek
• Büyük sürüm geçişlerini planlamak

Web sitesinin türü değiştikçe bakım kapsamı da değişir. Beş sayfalık kurumsal tanıtım sitesiyle; üyelik, ödeme, rezervasyon, müşteri paneli veya çok dilli içerik bulunan bir platform aynı bakım planına sahip olmamalıdır.

“Site çalışıyor, neden bakım ücreti ödüyorum?”

Bu soru genellikle bakımın yalnızca arıza sonrası müdahale olarak değerlendirilmesinden kaynaklanır. Bir web sitesi bugün açılıyor olabilir. Ancak arka planda:

• Destek dışı bir framework kullanabilir.
• Güvenlik açığı bulunan bir paket çalıştırabilir.
• Yedekleme işlemleri başarısız olabilir.
• Form mesajları teslim edilmiyor olabilir.
• Mobil performansı gerilemiş olabilir.
• Analytics verileri kesilmiş olabilir.
• Arama motorlarının önemli sayfalara erişimi bozulmuş olabilir.
• SSL sertifikası veya domain süresi yaklaşmış olabilir.
• Ödeme ya da rezervasyon entegrasyonunda hata başlamış olabilir.

Bu sorunların önemli bir bölümü kullanıcı şikâyet edene kadar görünür hale gelmez. Bakım hizmetinin değeri, yalnızca kaç hata düzeltildiğiyle ölçülmemelidir. Şunlarla da ölçülmelidir:

• Kaç risk erken tespit edildi?
• Kaç güncelleme kontrollü biçimde uygulandı?
• Kaç kesinti kullanıcıya ulaşmadan çözüldü?
• Yedeklerin geri yüklenebilirliği doğrulandı mı?
• Kritik iş akışları düzenli test edildi mi?
• Destek dışı sürüme geçiş önceden planlandı mı?
• SEO ve performans kayıpları erken görüldü mü?

Bakımın başarılı olması, bazı dönemlerde işletmenin büyük bir sorun yaşamaması şeklinde görünür.

Hosting ile web sitesi bakımı aynı şey değildir

Hosting, web sitesinin dosyalarının ve uygulamasının çalıştığı altyapıyı sağlar. Web sitesi bakımı ise bu altyapının üzerinde çalışan uygulamanın, içeriğin, entegrasyonların ve işlevlerin yönetilmesini kapsar.

Hosting sağlayıcısı ne yapar?

Hizmete göre değişmekle birlikte hosting veya cloud sağlayıcısı şu alanlardan sorumlu olabilir:

• Fiziksel veri merkezi
• Sunucu donanımı
• Ağ altyapısı
• Sanallaştırma katmanı
• Bazı yönetilen servis güncellemeleri
• Platform erişilebilirliği

İşletme veya yazılım ekibi ne yapar?

• Uygulama kodu
• CMS ve eklentiler
• Kullanıcı yetkileri
• Veri güvenliği
• Uygulama yapılandırmaları
• Yedekleme politikası
• Entegrasyonlar
• Hata izleme
• Uygulama güncellemeleri
• Alan adı ve DNS yönetimi
• İş sürekliliği planı

AWS’nin paylaşılan sorumluluk modeli, cloud sağlayıcısının altyapının güvenliğinden; müşterinin ise kullandığı servise göre uygulama, veri, erişim ve yapılandırma gibi alanlardan sorumlu olduğunu açıklar. Yönetilen hosting kullanmak, web uygulamasının güncelleme ve bakım ihtiyacını ortadan kaldırmaz.

Basit örnek

Hosting sağlayıcısının sunucuları sorunsuz çalışıyor olabilir. Ancak web sitesindeki iletişim formu, artık çalışmayan bir e-posta API’si nedeniyle mesaj göndermiyorsa bu hosting arızası değildir. Benzer şekilde:

• WordPress eklentisinin çakışması
• Next.js paketinin destek dışı kalması
• Ödeme API’sinin değişmesi
• Analytics etiketinin bozulması
• Kullanıcı rolünün yanlış yapılandırılması

uygulama bakımı kapsamındadır.

Web sitesi bakım maliyetinin temel kalemleri

1. Hosting, domain, SSL ve altyapı maliyetleri

Web sitesinin yayında kalması için temel altyapı hizmetleri gerekir. Bunlar şunları içerebilir:

• Hosting veya cloud sunucusu
• Veri tabanı
• Dosya depolama
• CDN
• Alan adı
• SSL sertifikası
• Kurumsal e-posta
• DNS hizmetleri
• Yedekleme depolaması
• Log depolaması
• Güvenlik duvarı veya bot koruması
• E-posta, SMS veya üçüncü taraf API’leri

Hosting maliyetini neler etkiler?

• Trafik miktarı
• Dosya ve görsel boyutu
• Veri tabanı kullanımı
• Sunucu tarafında yapılan işlemler
• Kullanıcı sayısı
• Bölgesel dağıtım
• Yedekleme sıklığı
• Log saklama süresi
• Video ve dosya trafiği
• Ani trafik artışları
• Yüksek erişilebilirlik ihtiyacı
• Yönetilen veya self-hosted hizmet tercihi

Kurumsal bir tanıtım sitesiyle yoğun rezervasyon alan bir platform aynı altyapı maliyetine sahip değildir.

Altyapı faturası ile bakım ücreti ayrılmalıdır

Teklifte şu ayrım açıkça gösterilmelidir:

“Hosting dâhil bakım” ifadesi tek başına yeterli değildir. Hangi hizmetin, ne kadar kullanım limitine kadar dâhil olduğu belirtilmelidir.

2. Güvenlik güncellemeleri

Web sitesi zaman içinde yeni güvenlik açıklarından etkilenebilir. Risk yalnızca sitenin kendi kodundan kaynaklanmaz. Açıklar şu katmanlarda ortaya çıkabilir:

• CMS
• Framework
• Tema
• Eklenti
• JavaScript veya backend paketi
• Sunucu çalışma zamanı
• Veri tabanı
• İşletim sistemi
• Harici servis SDK’sı
• Yönetim paneli
• Kimlik doğrulama sistemi

CISA, güvenliği ürün yaşam döngüsünün ve yazılım üreticisinin sorumluluğunun parçası olarak değerlendirir. Bilinen güvenlik zayıflıklarının ve destek dışı bileşenlerin kullanılmaya devam edilmesini ürün güvenliği açısından önemli bir risk olarak tanımlar.

Güvenlik güncellemesi nasıl uygulanmalıdır?

Doğru süreç yalnızca “Update” butonuna basmak değildir.

• Güvenlik duyurusu incelenir.
• Etkilenen sürüm doğrulanır.
• Güncellemenin proje üzerindeki etkisi değerlendirilir.
• Yedek alınır.
• Güncelleme staging veya test ortamında uygulanır.
• Kritik iş akışları test edilir.
• Production güncellemesi yapılır.
• Hata ve performans sonuçları izlenir.
• Güncelleme raporlanır.

Kritik güvenlik güncellemeleri, normal aylık bakım takvimini beklemeden ele alınabilir.

Güvenlik bakımı neleri kapsayabilir?

• Güvenlik duyurularının takibi
• Zafiyet taraması
• CMS ve framework yamaları
• Paket güncellemeleri
• Kullanıcı yetkilerinin kontrolü
• Şüpheli girişlerin incelenmesi
• Secret ve API anahtarı kontrolü
• SSL ve güvenlik başlıkları
• Dosya yükleme kontrolleri
• Yönetim paneli erişimleri
• Güvenlik loglarının incelenmesi
• Acil olay müdahalesi

Bakım sözleşmesinde kritik güvenlik açığı tespit edildiğinde hangi süre içinde analiz ve müdahale yapılacağı belirtilmelidir.

3. Framework, CMS, tema ve paket güncellemeleri

Modern web siteleri çoğunlukla çok sayıda yazılım bileşeninden oluşur. Örneğin özel geliştirilmiş bir web uygulamasında:

• Frontend framework
• Backend framework
• UI paketleri
• Kimlik doğrulama kütüphanesi
• Form ve doğrulama paketleri
• Veri tabanı istemcisi
• E-posta SDK’sı
• Ödeme SDK’sı
• Görsel işleme kütüphanesi

bulunabilir. WordPress sitesinde ise:

• WordPress çekirdeği
• Tema
• Eklentiler
• PHP sürümü
• Veri tabanı
• Hosting yapılandırması

birlikte çalışır.

Otomatik güncelleme neden tek başına yeterli değildir?

Otomatik güncellemeler küçük ve düşük riskli değişikliklerde faydalı olabilir. Ancak güncelleme sonrasında:

• Tema görünümü bozulabilir.
• Form çalışmayabilir.
• Ödeme sayfası hata verebilir.
• Plugin çakışması oluşabilir.
• Eski özel kod uyumsuz kalabilir.
• Yönetim paneli davranışı değişebilir.
• Cache nedeniyle eski ve yeni dosyalar karışabilir.

WordPress, çekirdek, tema ve eklentilerin güncel tutulmasını; güncelleme öncesinde yedek alınmasını önerir. Plugin ve tema otomatik güncellemelerinde de düzenli yedekleme yapılması tavsiye edilir.

Özel yazılım paketleri nasıl takip edilir?

GitHub Dependabot gibi araçlar, bilinen güvenlik açığı bulunan veya eski kalan bağımlılıklar için otomatik güncelleme pull request’leri oluşturabilir. Ancak otomatik pull request’in oluşması, güncellemenin test edilip production’a güvenli biçimde alındığı anlamına gelmez. Teknik bakım şunları kapsamalıdır:

• Güncelleme bildirimini almak
• Breaking change kontrolü
• Kod uyumluluğu
• Otomatik test
• Manuel kritik akış testi
• Deployment
• Geri alma planı
• Production doğrulaması

4. Desteklenen sürümde kalma ve büyük sürüm yükseltmeleri

Her yazılım sürümü sonsuza kadar desteklenmez. Framework, CMS veya çalışma zamanı destek dışı kaldığında:

• Yeni güvenlik yamaları gelmeyebilir.
• Yeni hosting ortamlarıyla uyumsuzluk oluşabilir.
• Harici paketler eski sürümü bırakabilir.
• Geliştirici bulmak zorlaşabilir.
• Yeni özelliklerin eklenmesi pahalılaşabilir.
• Küçük bir güncelleme büyük migration projesine dönüşebilir.

Next.js’in destek politikası, production uygulamalarının Active LTS veya Maintenance LTS sürümünde çalıştırılmasını önerir. Active LTS düzenli özellik, hata, performans ve güvenlik güncellemeleri alırken Maintenance LTS daha sınırlı kritik hata ve güvenlik desteği alır. Destek dışı ana sürümlerde kalmak bakım riskini artırır.

Patch güncellemesi ile major sürüm geçişi aynı değildir

Bakım sözleşmesi “güncellemeler dâhil” diyorsa bunun hangi tür güncellemeleri kapsadığı belirtilmelidir. Aylık bakım ücreti, bir sitenin yıllarca güncellenmemiş büyük migration çalışmasını otomatik olarak kapsamayabilir.

5. Yedekleme ve geri yükleme testleri

Yedek almak bakımın temel parçalarından biridir. Ancak yalnızca “backup aktif” ifadesi yeterli değildir. Şu sorular cevaplanmalıdır:

• Hangi veriler yedekleniyor?
• Dosyalar ve veri tabanı birlikte mi?
• Ne sıklıkla yedek alınıyor?
• Kaç günlük kopya tutuluyor?
• Yedek aynı sunucuda mı?
• Farklı bölge veya sağlayıcıda kopya var mı?
• Yedekler şifreleniyor mu?
• Kim geri yükleyebilir?
• Son geri yükleme testi ne zaman yapıldı?
• Müşteri bazlı geri yükleme mümkün mü?
• Kurtarma ne kadar sürer?

AWS’nin dayanıklılık rehberleri, veri ve uygulama iş yükleri için backup, versioning, replication ve disaster recovery stratejisinin müşteri sorumlulukları arasında olduğunu belirtir. Backup ve restore, veri kaybı veya bozulmaya karşı temel kurtarma yaklaşımlarından biridir. WordPress de yedeklemenin düzenli bakım takviminin parçası olmasını önerir.

Yedek var ama çalışmıyor olabilir

Aşağıdaki durumlar yaşanabilir:

• Yedekleme görevi aylar önce hata vermiştir.
• Yalnızca dosyalar, veri tabanı olmadan alınmıştır.
• Dosya depolama alanı yedeğe dâhil değildir.
• Yedek bozulmuştur.
• Şifre veya erişim anahtarı kaybolmuştur.
• Yedek aynı sunucuda olduğu için sunucuyla birlikte kaybolmuştur.
• Geri yükleme süreci hiç test edilmemiştir.

Bu nedenle bakım hizmeti yalnızca yedek almak değil, belirli aralıklarla geri yükleme testini de kapsamalıdır.

RPO ve RTO nedir?

RPO — Recovery Point Objective: En fazla ne kadar veri kaybı kabul edilebilir? Örneğin RPO 24 saatse son bir güne ait veriler kaybedilebilir. RTO — Recovery Time Objective: Sistem ne kadar sürede yeniden çalışır hale gelmelidir? Kurumsal tanıtım sitesiyle sürekli sipariş alan e-ticaret sistemi aynı RPO ve RTO hedeflerine sahip olmamalıdır.

6. Uptime, hata ve performans izleme

Bir web sitesinin yalnızca ana sayfasının açılması, bütün sistemin çalıştığı anlamına gelmez. Şu bileşenler ayrı ayrı bozulabilir:

• İletişim formu
• Ödeme
• Rezervasyon
• Kullanıcı girişi
• E-posta gönderimi
• Dosya yükleme
• CRM entegrasyonu
• Yönetim paneli
• Arama
• Çok dilli sayfalar
• Webhook işlemleri

Uptime izleme

Uptime izleme, belirli URL’lerin düzenli aralıklarla kontrol edilmesini sağlar. Kontrol edilebilecekler:

• Site açılıyor mu?
• Doğru HTTP yanıtı dönüyor mu?
• SSL geçerli mi?
• Yanıt süresi arttı mı?
• Kritik API çalışıyor mu?
• Belirli metin veya bileşen sayfada bulunuyor mu?

Uygulama hata izleme

Hata izleme araçları yalnızca sitenin kapalı olup olmadığını değil, uygulama içinde oluşan hataları gösterir. Örneğin Sentry’nin hata detayları:

• Hata mesajı
• Oluşma sayısı
• Etkilenen kullanıcı sayısı
• İlgili işlem ve performans bağlamı

gibi bilgileri sunabilir. Böylece yalnızca “hata var” değil, hatanın kaç kullanıcıyı etkilediği de değerlendirilebilir.

Performans izleme

Performans zaman içinde gerileyebilir. Nedenleri:

• Yeni pazarlama script’i
• Büyük görseller
• Yeni fontlar
• Ağır bir chatbot
• Üçüncü taraf widget
• Veri tabanı büyümesi
• Cache yapılandırmasının bozulması
• Yeni paketler
• Hosting kaynaklarının yetersiz kalması

Google’ın Core Web Vitals metrikleri gerçek kullanıcı deneyiminde yükleme, etkileşim ve görsel kararlılığı ölçer. Google; iyi deneyim için LCP’nin 2,5 saniye içinde, INP’nin 200 milisaniyenin altında ve CLS’nin 0,1’in altında olmasını önerir. Performans kontrolü yalnızca proje yayınlanırken bir kez yapılmamalıdır. Yeni içerik, entegrasyon ve script’ler eklendikçe yeniden ölçülmelidir.

7. Kritik hata müdahalesi

Bakım sözleşmesinin önemli parçalarından biri, sorun ortaya çıktığında kimin ne kadar sürede müdahale edeceğidir.

Hatalar önem seviyesine göre ayrılmalıdır

Müdahale süresi ile çözüm süresi farklıdır

Müdahale süresi, ekibin sorunu incelemeye başlama süresidir. Çözüm süresi, hatanın tamamen giderilmesi için gereken süredir. Her hata için kesin çözüm süresi vaat etmek gerçekçi değildir. Sorunun üçüncü taraf servis, hosting, ödeme sağlayıcısı veya domain kaynaklı olması çözüm süresini etkileyebilir. Bakım sözleşmesinde şu alanlar açık olmalıdır:

• Destek saatleri
• Acil iletişim kanalı
• Önem seviyeleri
• İlk yanıt süresi
• Geçici çözüm yaklaşımı
• Hafta sonu ve mesai dışı destek
• Üçüncü taraf sorunlarında sorumluluk
• Olay sonrası rapor
• Dâhil olan teknik çalışma süresi

8. İçerik ve yönetim paneli desteği

Teknik bakım ile içerik desteği aynı hizmet olmayabilir. İçerik desteği şu işleri kapsayabilir:

• Metin değiştirme
• Görsel ekleme
• Yeni blog yazısı yayımlama
• Hizmet sayfası oluşturma
• Kampanya banner’ı değiştirme
• Ekip veya referans ekleme
• PDF güncelleme
• Çok dilli içerik girişi
• Form alanı değişikliği
• Menü düzenleme

İçerik bakım maliyetini neler etkiler?

• Aylık içerik sayısı
• Dil sayısı
• Görsel düzenleme ihtiyacı
• Yeni sayfa şablonu gerekip gerekmediği
• SEO metadata çalışması
• İçeriğin müşteri tarafından hazır sağlanması
• Onay ve revizyon süreci
• İçerik girişinin manuel veya otomatik olması

“Bakım paketine içerik güncellemesi dâhil” ifadesi şu bilgiler olmadan belirsizdir:

• Ayda kaç güncelleme?
• Yeni sayfa oluşturma dâhil mi?
• Tasarım çalışması dâhil mi?
• Metin yazımı dâhil mi?
• Çeviri dâhil mi?
• Görsel hazırlama dâhil mi?
• Revizyon sınırı var mı?

9. SEO kontrolleri

SEO bakımı yalnızca yeni blog yazısı yayımlamak değildir. Teknik ve içerik tarafında düzenli kontrol gerekir.

Teknik SEO bakım alanları

• Indexlenmeyen önemli sayfalar
• Yanlışlıkla indexlenen sayfalar
• 404 hataları
• Bozuk yönlendirmeler
• Canonical etiketleri
• XML sitemap
• Robots kuralları
• Structured data hataları
• Mobil görünüm
• Core Web Vitals
• JavaScript rendering sorunları
• Çok dilli hreflang yapısı
• İç bağlantılar
• Başlık ve metadata sorunları

Google Search Console; Google’ın siteyi nasıl taradığı, indexlediği ve arama sonuçlarında gösterdiği hakkında bilgi sağlar. Core Web Vitals raporu da gerçek kullanıcı verilerine dayalı performans değerlendirmesi sunar. Search Console ve Google Analytics verilerinin birlikte değerlendirilmesi, kullanıcıların siteyi nasıl keşfettiğini ve site içinde nasıl davrandığını daha kapsamlı biçimde anlamaya yardımcı olur.

SEO bakımı neleri garanti etmez?

SEO bakım hizmeti:

• İlk sıra garantisi vermez.
• Trafiğin her ay artacağını garanti etmez.
• Algoritma güncellemelerini kontrol edemez.
• Rakiplerin çalışmalarını durduramaz.
• Talep olmayan bir konuda arama hacmi oluşturamaz.

SEO bakımının amacı:

• Teknik görünürlük kayıplarını erken fark etmek
• Site değişikliklerinin etkisini izlemek
• İçerik fırsatlarını belirlemek
• Arama performansını düzenli geliştirmek
• Indexleme ve tarama sorunlarını çözmek

olmalıdır.

10. Form, ödeme ve entegrasyon testleri

Web sitesi dış sistemlere bağlıysa bakım kapsamı genişler. Örnek entegrasyonlar:

• CRM
• ERP
• Ödeme
• Rezervasyon
• E-posta
• SMS
• Harita
• Muhasebe
• Canlı destek
• Analitik
• Kargo
• Sosyal giriş
• Yapay zekâ servisleri

Bu servisler kendi API’lerini, erişim anahtarlarını, sürümlerini veya politikalarını değiştirebilir.

Düzenli test edilmesi gereken akışlar

• İletişim formu gönderiliyor mu?
• Form doğru e-posta adresine ulaşıyor mu?
• Spam filtreleri gerçek müşteriyi engelliyor mu?
• Ödeme tamamlanıyor mu?
• Başarısız ödeme doğru gösteriliyor mu?
• Rezervasyon kaydı yönetim paneline düşüyor mu?
• CRM kaydı oluşuyor mu?
• Kullanıcıya onay e-postası gidiyor mu?
• Analytics dönüşümü kaydediyor mu?
• Webhook tekrar gönderilirse aynı işlem iki kez oluşuyor mu?

Site açılıyor olsa bile bu akışlardan biri bozulmuş olabilir. Bu nedenle bakım planında yalnızca uptime değil, kritik kullanıcı senaryosu testleri de bulunmalıdır.

Bakım maliyetini hangi faktörler yükseltir?

1. Sitenin iş açısından kritik olması

Site yalnızca tanıtım amaçlıysa kesintinin etkisi sınırlı olabilir. Site üzerinden:

• Satış
• Rezervasyon
• Ödeme
• Kullanıcı girişi
• Operasyon
• Teklif
• Müşteri desteği

yürütülüyorsa daha hızlı müdahale ve kapsamlı izleme gerekir.

2. Kullanıcı ve işlem hacmi

Trafik ve işlem miktarı arttıkça:

• Log hacmi
• Veri tabanı büyüklüğü
• Yedekleme süresi
• İzleme ihtiyacı
• Performans optimizasyonu
• Destek talepleri

artabilir.

3. Teknoloji karmaşıklığı

• Birden fazla frontend
• Backend API
• Mobil uygulama
• Yönetim paneli
• Çoklu veri tabanı
• Çok sayıda entegrasyon
• Çoklu dil
• Müşteri rolleri
• Ödeme sistemi

bakım kapsamını büyütür.

4. Müdahale süresi beklentisi

Mesai saatlerinde bir iş günü içinde müdahale ile 7/24 acil destek aynı maliyete sahip değildir. Hızlı müdahale taahhüdü, ekibin belirli kapasiteyi işletme için ayırmasını gerektirir.

5. Test altyapısı

Güncellemelerin güvenli uygulanması için:

• Staging ortamı
• Otomatik testler
• Deployment sistemi
• Geri alma mekanizması
• Test verisi

gerekebilir. Test altyapısı bakım maliyetini artırabilir; fakat production güncelleme riskini azaltır.

6. Eski ve dokümansız sistemler

Bakım ekibi:

• Kaynak kodu anlamak
• Eksik erişimleri bulmak
• Eski paketleri analiz etmek
• Manuel deployment sürecini çözmek
• Dokümantasyon oluşturmak

için ek zaman harcayabilir. Daha önce bakım yapılmamış bir sistemi devralmak, düzenli bakılan bir sistemi yönetmekten daha maliyetli olabilir.

Web sitesi bakım fiyatlandırma modelleri

1. Sabit aylık bakım paketi

Her ay belirli hizmet kapsamı ve teknik süre sunulur. Uygun olduğu durumlar:

• Düzenli güncelleme ihtiyacı
• Kritik iş akışları
• Sürekli izleme
• Hızlı müdahale beklentisi
• İçerik ve SEO kontrolleri

Avantajları:

• Öngörülebilir bütçe
• Düzenli kontrol
• Sorun olmadan önce müdahale
• Sistemi tanıyan devamlı ekip

2. Kullanılan saat kadar ödeme

Yalnızca talep geldiğinde çalışma yapılır. Uygun olabilir:

• Basit ve düşük riskli siteler
• Çok seyrek güncelleme
• Kritik olmayan projeler
• İşletmenin teknik sorumlulukları kendisinin yönettiği durumlar

Riskleri:

• Düzenli güvenlik kontrolü yapılmayabilir.
• Sorun ortaya çıkana kadar bakım ertelenebilir.
• Acil durumda ekip kapasitesi bulunmayabilir.
• Sistemi her seferinde yeniden analiz etmek gerekebilir.

3. Hizmet seviyesi anlaşması

Kritik platformlarda:

• Uptime hedefi
• Müdahale süresi
• Destek saatleri
• Olay sınıfları
• İzleme kapsamı
• Yedekleme hedefleri

tanımlanır. Bu model daha yüksek operasyon kapasitesi gerektirir.

4. Karma model

• Sabit aylık bakım
• Belirli teknik çalışma kotası
• Kota dışı işlerde saatlik ücret
• Büyük sürüm ve yeni geliştirmelerde ayrı teklif

birlikte kullanılabilir. Birçok kurumsal proje için kapsamın anlaşılır kalmasını sağlayan model budur.

Bakım paketine neler dâhil olmalıdır?

Minimum teknik kapsam

• Uptime kontrolü
• SSL ve domain takibi
• Güvenlik güncelleme kontrolü
• CMS/framework/package kontrolü
• Düzenli yedekleme
• Temel geri yükleme doğrulaması
• Hata loglarının incelenmesi
• Kritik formların kontrolü
• Aylık bakım raporu
• Belirli müdahale süresi

Orta kapsam

Minimum kapsama ek olarak:

• Staging ortamı
• Güncellemelerin test edilmesi
• Performans kontrolü
• Search Console kontrolü
• Analytics doğrulaması
• Belirli içerik güncelleme kotası
• Entegrasyon kontrolleri
• Güvenlik taraması
• Aylık teknik toplantı

Kritik platform kapsamı

• 7/24 veya genişletilmiş izleme
• Kritik alarm sistemi
• Olay müdahale prosedürü
• Otomatik testler
• Deployment ve rollback
• Yüksek erişilebilirlik
• Düzenli restore testi
• RPO ve RTO hedefleri
• Performans kapasite takibi
• Ayrıntılı olay sonrası rapor
• Güvenlik ve erişim denetimi

Bakım paketine neler otomatik olarak dâhil değildir?

Sözleşmede özellikle belirtilmedikçe aşağıdakiler ayrı çalışma olabilir:

• Yeni sayfa tasarımı
• Yeni modül geliştirme
• Mobil uygulama geliştirme
• Büyük framework migration’ı
• Marka ve tasarım yenilemesi
• Yeni ödeme sistemi
• Yeni CRM veya ERP entegrasyonu
• SEO içerik üretimi
• Profesyonel metin yazımı
• Çoklu dil çevirisi
• Veri temizleme
• Sunucu taşıma
• Domain değişikliği
• Kapsamlı güvenlik testi
• Felaket sonrası yeniden geliştirme
• Üçüncü taraf lisansları

Bakım ve yeni geliştirme ayrımı sözleşmede açık yapılmazsa tarafların beklentileri farklılaşabilir.

Site türüne göre önerilen bakım düzeyi

Önerilen bakım takvimi

Bu bölüm InoviqLab tarafından sunulan örnek bir bakım planıdır. Her site için aynı sıklık zorunlu değildir.

Sürekli veya günlük

• Uptime
• Kritik hata
• SSL
• Ödeme ve temel servis alarmları
• Güvenlik alarmı
• Yedekleme görevi sonucu

Haftalık

• Form ve temel iş akışları
• Uygulama hata raporları
• Şüpheli kullanıcı hareketleri
• Başarısız entegrasyonlar
• Kritik paket uyarıları
• Disk ve kaynak kullanımı

Aylık

• CMS/framework/package güncellemeleri
• Search Console
• Core Web Vitals
• Analytics ve dönüşüm doğrulaması
• Yetki ve kullanıcı kontrolü
• Kırık bağlantılar
• İçerik ve metadata kontrolü
• Bakım raporu

Üç aylık

• Geri yükleme testi
• Performans karşılaştırması
• Kullanılmayan hesaplar
• Paket ve eklenti envanteri
• Maliyet optimizasyonu
• Yedekleme saklama politikası
• Güvenlik ve erişim gözden geçirmesi

Yıllık

• Major sürüm planı
• Hosting ve altyapı değerlendirmesi
• Domain ve hesap sahipliği kontrolü
• Felaket kurtarma senaryosu
• Tasarım ve erişilebilirlik değerlendirmesi
• Bakım sözleşmesi kapsam revizyonu

Bakım hizmeti alırken sorulması gereken sorular

• Hosting ücreti bakım ücretine dâhil mi?
• Hangi altyapı servisleri ayrıca faturalandırılıyor?
• Güncellemeler önce staging ortamında test ediliyor mu?
• Güvenlik güncellemelerine ne kadar sürede müdahale ediliyor?
• Major sürüm yükseltmeleri pakete dâhil mi?
• Yedekler nerede ve ne kadar süre saklanıyor?
• Geri yükleme testi yapılıyor mu?
• Uptime ve uygulama hataları izleniyor mu?
• Form, ödeme ve entegrasyonlar düzenli test ediliyor mu?
• Aylık kaç saat teknik destek bulunuyor?
• Kullanılmayan süre sonraki aya aktarılıyor mu?
• Mesai dışı destek var mı?
• İçerik güncellemeleri dâhil mi?
• SEO kontrolleri neleri kapsıyor?
• Aylık rapor veriliyor mu?
• Kaynak kod ve cloud hesapları kimin kontrolünde?
• Bakım sona erdiğinde devir süreci nasıl olacak?
• Kritik hatanın tanımı nedir?
• Müdahale ve çözüm süreleri nasıl ayrılıyor?
• Üçüncü taraf servis kesintilerinde nasıl destek veriliyor?

Yetersiz bakım hizmetini gösteren işaretler

• Güncellemeler test edilmeden production’a alınıyor.
• Yedek alındığı söyleniyor fakat restore testi yapılmıyor.
• Kaynak kod güncel repository’de tutulmuyor.
• Yapılan işlemler raporlanmıyor.
• Site yalnızca müşteri şikâyet ettiğinde kontrol ediliyor.
• Güvenlik duyuruları takip edilmiyor.
• Destek dışı framework yıllarca kullanılmaya devam ediliyor.
• Domain ve cloud hesapları ajansın kişisel hesabında tutuluyor.
• Kritik hatanın ne olduğu tanımlanmamış.
• Müdahale süresi bulunmuyor.
• Bakım ile yeni geliştirme ayrılmamış.
• Analytics ve Search Console erişimleri kontrol edilmiyor.
• Form ve ödeme akışları düzenli test edilmiyor.
• Production erişimleri sınırsız biçimde paylaşılıyor.

Web sitesi bakım kontrol listesi

Altyapı ve sahiplik

• Domain şirket hesabında mı?
• DNS erişimi işletmede mi?
• Hosting veya cloud hesabı işletmenin kontrolünde mi?
• SSL yenilemesi izleniyor mu?
• Kaynak kod repository’si güncel mi?
• Production erişimleri kayıt altında mı?
• Üçüncü taraf servislerin listesi var mı?

Güvenlik ve güncelleme

• Kullanılan CMS veya framework destekleniyor mu?
• Paket ve eklenti güncellemeleri takip ediliyor mu?
• Kritik güvenlik duyuruları için süreç var mı?
• Güncellemeler test ortamında deneniyor mu?
• Kullanıcı yetkileri düzenli kontrol ediliyor mu?
• Kullanılmayan hesaplar kapatılıyor mu?
• API anahtarları güvenli saklanıyor mu?

Yedekleme

• Veri tabanı yedekleniyor mu?
• Dosyalar yedekleniyor mu?
• Yedekler farklı bir ortamda tutuluyor mu?
• Saklama süresi belli mi?
• Son restore testi ne zaman yapıldı?
• RPO ve RTO hedefleri belirlendi mi?
• Yedekleme hataları için alarm var mı?

İzleme

• Site erişilebilirliği izleniyor mu?
• Uygulama hataları kaydediliyor mu?
• Kritik kullanıcı akışları test ediliyor mu?
• Ödeme ve form hataları izleniyor mu?
• Performans gerilemesi takip ediliyor mu?
• Kritik durumda kime alarm gidiyor?

SEO ve analitik

• Search Console düzenli kontrol ediliyor mu?
• Analytics veri topluyor mu?
• Dönüşümler doğru kaydediliyor mu?
• Sitemap güncel mi?
• 404 ve yönlendirmeler kontrol ediliyor mu?
• Core Web Vitals izleniyor mu?
• Yanlışlıkla noindex olan sayfalar kontrol ediliyor mu?

Destek ve sözleşme

• Bakım kapsamı yazılı mı?
• Müdahale süreleri belli mi?
• Mesai dışı destek tanımlı mı?
• Aylık teknik çalışma kotası belli mi?
• Yeni geliştirme ve bakım ayrılmış mı?
• Aylık rapor veriliyor mu?
• Sözleşme bittiğinde devir süreci tanımlı mı?

Kimler düzenli bakım hizmeti almalı?

• Web sitesinden müşteri talebi alan işletmeler
• Reklam kampanyası yürüten markalar
• E-ticaret ve rezervasyon platformları
• Kullanıcı hesabı bulunan siteler
• Müşteri veya bayi paneli kullanan şirketler
• Çok dilli içerik yayımlayan markalar
• Ödeme ve üçüncü taraf entegrasyonu kullananlar
• Organik trafik ve SEO yatırımı yapan işletmeler
• Sitedeki kesintinin gelir veya itibar kaybı oluşturduğu şirketler
• Siteyi yönetecek teknik ekibi bulunmayan işletmeler

Daha sınırlı bakım yeterli olabilecekler

• Çok seyrek değişen basit tanıtım siteleri
• Tamamen statik ve entegrasyonsuz sayfalar
• Teknik bakım sorumluluğunu şirket içinde yöneten ekipler
• Kısa süreli kampanya sayfaları
• Kullanıcı verisi veya kritik işlem barındırmayan projeler

Sınırlı bakım, bakım yapılmaması anlamına gelmez. En azından domain, SSL, hosting, güvenlik sürümleri ve yedekleme sorumlulukları tanımlanmalıdır.

InoviqLab değerlendirmesi

Bu bölüm InoviqLab’ın değerlendirmesidir; resmî ürün ve platform dokümanlarından ayrıdır. Web sitesi bakımında en sık görülen problem, bakım ücretinin “ay içinde kaç değişiklik yapıldı?” sorusuyla değerlendirilmesidir. Oysa bakımın önemli bölümü görünmeyen operasyonlardan oluşur:

• Güncelleme takibi
• Risk analizi
• Yedek doğrulama
• Alarm kontrolü
• Log inceleme
• Test
• Production doğrulaması
• Teknik raporlama

Bir ay içerisinde kullanıcıya yansıyan büyük bir arıza yaşanmaması, bakım ekibinin hiçbir şey yapmadığı anlamına gelmeyebilir. İkinci hata, hosting ile uygulama bakımının aynı hizmet olduğunun düşünülmesidir. Hosting sağlayıcısının altyapısı çalışırken sitenin:

• Formu
• Ödemesi
• E-posta sistemi
• Yönetim paneli
• SEO ayarları
• Uygulama kodu

bozulabilir. Üçüncü hata, güncellemelerin otomatik olarak ve testsiz uygulanmasıdır. Güncelleme yapmamak güvenlik ve uyumluluk riski oluşturur. Güncellemeyi test etmeden production’a almak ise iş sürekliliği riski oluşturur. Doğru bakım süreci bu iki riski dengelemelidir. Dördüncü hata, yedekleme ile felaket kurtarmanın aynı şey olduğunun düşünülmesidir. Yedek dosyasının bulunması, sitenin kısa sürede geri getirilebileceğini garanti etmez. Kurtarma için:

• Erişim
• Dokümantasyon
• Altyapı
• Deployment
• Veritabanı
• Domain
• Secret’lar
• Test edilmiş geri yükleme adımları

gerekir. Beşinci hata, major sürüm yükseltmelerinin yıllarca ertelenmesidir. Küçük güncellemeler düzenli yapılmadığında ileride:

• Birden fazla framework sürümü
• Eski çalışma zamanı
• Destek dışı paketler
• Değişmiş API’ler
• Uyumsuz özel kodlar

tek projede birikir. Bu durumda bakım maliyeti küçük ve düzenli güncellemelerden, büyük bir yeniden geliştirme maliyetine dönüşebilir. InoviqLab açısından sağlıklı web sitesi bakım modeli şu bileşenlerden oluşmalıdır:

• Sorumluluk ve sahiplik envanteri
• Düzenli otomatik izleme
• Güvenlik ve sürüm takibi
• Test ortamı
• Kontrollü güncelleme
• Yedekleme ve restore testi
• Kritik kullanıcı akışı kontrolü
• SEO ve analitik izleme
• Müdahale prosedürü
• Anlaşılır aylık raporlama

Sonuç

Web sitesi bakım maliyeti yalnızca hosting ücretinden oluşmaz. Gerçek bakım kapsamı şu alanları içerebilir:

• Hosting ve altyapı
• Güvenlik güncellemeleri
• CMS, framework ve paket bakımı
• Yedekleme ve geri yükleme
• Uptime ve hata izleme
• Performans kontrolü
• Kritik hata müdahalesi
• İçerik desteği
• Teknik SEO
• Entegrasyon testleri
• Büyük sürüm planlaması

“Site çalışıyor” ifadesi yalnızca o anda görünen sonucu anlatır. Bakım hizmeti ise sitenin:

• Yarın da çalışmasını
• Güvenlik açığı taşımamasını
• Verinin geri getirilebilmesini
• Kritik işlemlerin bozulmamasını
• Arama görünürlüğünün korunmasını
• Destek dışı teknolojide kalmamasını

sağlamaya yönelik düzenli bir süreçtir. Bakım teklifi karşılaştırılırken yalnızca aylık fiyata değil şu sorulara bakılmalıdır:

• Hangi hizmetler dâhil?
• Hangi sıklıkla kontrol yapılıyor?
• Güncellemeler nasıl test ediliyor?
• Yedekler geri yüklenebiliyor mu?
• Kritik durumda ne kadar sürede müdahale ediliyor?
• Major sürüm geçişleri nasıl yönetiliyor?
• Yapılan çalışmalar nasıl raporlanıyor?

En düşük aylık bakım ücreti, her zaman en düşük toplam risk veya en düşük uzun vadeli maliyet anlamına gelmez.