Web Sitesi Bakım Sözleşmesi: 2026'da Neleri Kapsamalı?
Eksiksiz bir web bakım sözleşmesi altı alanı kapsar: teknik güncellemeler, test edilmiş yedekler, güvenlik, 7/24 izleme, rakamlarla tanımlanmış SLA'lara dayalı destek ve sözleşme sonunda devir-iade maddesi. Yazılı yanıt süreleri (çevrimdışı bir site için 1 saat), kodunuzun mülkiyetini ve sözleşme bitiminde erişimlerin ücretsiz iadesini talep edin. Bu maddeler yoksa imzalamayın.
Bir web bakım sözleşmesi altı alanı net biçimde kapsamalıdır: teknik güncellemeler, yedeklemeler, güvenlik, izleme, garantili sürelere (SLA) bağlı destek ve sözleşme sonunda devir-iade. Bu altı noktadan herhangi birinde muğlak kalan bir sözleşme, KOBİ'nizi kötü sürprizlere açık bırakır: başvurulacak mercisi olmadan çevrimdışı kalan bir site, kaybolan veriler ya da erişimlerinizi rehin tutan bir hizmet sağlayıcı.
OptionWeb'in kurucusu Julien Daniel, her yıl Belçikalı müşterilerin getirdiği onlarca bakım sözleşmesini inceliyor. Tablo hep aynı: uyuşmazlıkların çoğu fiyattan değil, eksik maddelerden doğuyor. Bu rehber size eksiksiz bir okuma çerçevesi sunuyor: bir sözleşmenin içermesi gerekenler, talep edilecek süreler, dikkat edilecek tuzaklar ve imzadan önce adım adım uygulanacak bir kontrol listesi.
1. 2026'da bir web bakım sözleşmesi neleri kapsamalı?
Ciddi bir web bakım sözleşmesi üç hizmet ailesini kapsar: önleyici bakım (güncellemeler, yedeklemeler, izleme), düzeltici bakım (hata ve arızaların giderilmesi) ve destek (taleplerinize yanıt, küçük değişiklikler). Her aile somut çıktılarla ve bir sıklıkla tanımlanmalıdır: “aylık güncelleme” bir taahhüttür; “düzenli takip” değildir.
- Önleyici bakım — CMS, eklenti ve bağımlılık güncellemeleri; otomatik ve test edilmiş yedeklemeler; SSL sertifikasının yenilenmesi; erişilebilirlik ve performans izleme.
- Düzeltici bakım — Hataların giderilmesi, arıza sonrası sitenin yeniden yayına alınması, saldırı sonrası temizlik, yedekten geri yükleme. SLA'lar (garantili süreler) asıl anlamını burada kazanır.
- Destek ve küçük geliştirmeler — İçerik değişiklikleri, yeni bir sayfa ekleme, sorularınızın yanıtlanması. Sözleşme, dâhil edilen hacmi (aylık saat veya talep sayısı) ve bunun ötesindeki ücreti belirtir.
- Kesişen yükümlülükler — Gizlilik, alt yüklenici olarak GDPR uyumluluğu (28. madde), dönemsel raporlama ve sözleşme sonunda devir-iade maddesi.
Kapsam genellikle görsel yenileme, büyük geliştirmeler ve SEO çalışmalarını dışarıda bırakır. Bu normaldir: bu hizmetler ayrı tekliflerin konusudur. Normal olmayan ise, arıza sonrası yeniden yayına almayı veya yedekten geri yüklemeyi dışlayan bir sözleşmedir: bu iki hizmet, bakımın ta kendisidir.
2. Bakımsız bir site neden risk hâline gelir?
Bakımsız bir site birkaç yıl içinde değil, birkaç ay içinde savunmasız hâle gelir. CMS'ler ve eklentileri sürekli güvenlik yamaları yayımlar; bu yamaları uygulamamak, botların otomatik olarak istismar ettiği, kamuya açık şekilde belgelenmiş kapıları açık bırakmak demektir.
Rakamlar açık. Patchstack, 2024 yılında WordPress ekosisteminde 7.000'den fazla yeni güvenlik açığı kaydetti; bunların ezici çoğunluğu üçüncü taraf eklentilerdeydi. Sucuri'nin yıllık raporlarına göre, incelenen saldırıya uğramış her 10 siteden yaklaşık 9'u, enfeksiyon anında güncel olmayan bir CMS üzerinde çalışıyordu. Ziyaretçi tarafında ise Google, mobil kullanıcıların %53'ünün 3 saniyeden uzun sürede yüklenen bir sayfayı terk ettiğini ölçtü: performansı düşen bir site, daha çökmeden ciro kaybettirir.
Risk aynı zamanda hukukidir. Veri toplayan bir site (iletişim formu, bülten, e-ticaret) zaman içinde GDPR ile uyumlu kalmalıdır: güncel çerez kütüphaneleri, doğru yasal metinler, belgelenmiş alt yükleniciler. Yama uygulanmamış bir siteden kaynaklanan veri sızıntısı, ziyaretçiyi değil şirketi sorumlu kılar. Bu konuyu 2026'da bir web sitesinin GDPR uyumluluğu rehberimizde ayrıntılı olarak ele alıyoruz.
3. İyi bir sözleşmede hangi maddeler bulunmalı?
Koruyucu bir sözleşmeyi göstermelik bir sözleşmeden ayıran sekiz madde vardır: ayrıntılı kapsam, rakamlarla tanımlanmış SLA'lar, saklama süresi belirtilmiş yedeklemeler, güvenlik, fikrî mülkiyet, devir-iade, süre ve fesih, sorumluluk. Aşağıdaki tablo, her maddenin neden kritik olduğunu ve sizi harekete geçirmesi gereken tehlike sinyalini özetliyor.
| Madde | Neden kritik | Tehlike sinyali |
|---|---|---|
| Hizmet kapsamı | Neyin dâhil, neyin hariç ve neyin ek ücrete tabi olduğunu tanımlar. Gelecekteki her uyuşmazlığın temelidir. | Muğlak ifadeler: “düzenli takip”, “genel bakım” — ne sıklık var ne somut çıktı. |
| SLA (garantili süreler) | Yazılı bir süre yoksa “ilgileniyoruz” cevabı, sitenin bir hafta çevrimdışı kalması anlamına gelebilir. | Rakamla belirtilmiş hiçbir süre yok ya da erişilemeyen bir site için “iş günü” cinsinden süreler. |
| Yedeklemeler | Saldırı, insan hatası ve sunucu arızasına karşı tek gerçek koruma. | Sıklık belirtilmemiş, geri yükleme testinden hiç söz edilmiyor, yedekler siteyle aynı sunucuda tutuluyor. |
| Güvenlik ve güncellemeler | Uygulanmayan yamalar, KOBİ sitelerinin saldırıya uğramasının bir numaralı nedenidir. | “Müşterinin talebi üzerine” güncelleme: işleyişi tersine çeviren bir yaklaşım. |
| Fikrî mülkiyet | Sitenizle, kodunuzla ve içeriklerinizle ayrılıp ayrılamayacağınızı belirler. | Mülkiyet konusunda tam sessizlik ya da devir yerine yalnızca kullanım lisansı. |
| Devir-iade | Sözleşme sonunda erişimlerin, kodun ve verilerin iadesini güvence altına alır. | Maddenin hiç olmaması ya da iadenin caydırıcı bir ücrete bağlanması. |
| Süre ve fesih | Taahhüdü ve çıkışı çerçeveler. Esneklik, hizmet sağlayıcının kendine güveninin işaretidir. | Otomatik yenilenen 24-36 aylık taahhüt ve 6 aylık fesih bildirim süresi. |
| Sorumluluk ve sigorta | Veri kaybı veya uzun süreli kesinti hâlinde kimin neyi ödeyeceğini belirtir. | Hizmet sağlayıcıyı kusur hâlinde bile her türlü sorumluluktan muaf tutan madde. |
İyi yazılmış bir madde doğrulanabilirdir: bir rakam, bir sıklık veya bir çıktı içerir. “Günlük yedekleme, 30 gün saklama, üç ayda bir geri yükleme testi” bir maddedir. “Düzenli yedeklemeler” ise broşür cümlesidir.
Kod ve erişimlerin mülkiyeti: en çok ihmal edilen nokta
Belçika'da olduğu gibi Fransa'da da bir sitenin kodu telif hakkıyla korunur: yazılı bir devir olmadan kod, geliştiricinin mülkiyetinde kalır. Bakım sözleşmesi bu nedenle en azından şunlara sahip olduğunuzu veya olacağınızı güvence altına almalıdır: sitenin yönetici erişimleri, barındırma erişimleri, alan adının sizin adınıza yönetimi (kayıtlı sahibi hizmet sağlayıcı değil siz olmalısınız) ve kod ile veritabanının kullanılabilir bir kopyası. Alan adınızı kendi adına kaydeden bir hizmet sağlayıcı, ayrılık gününde size pahalıya mal olacak bir bağımlılık yaratır.
4. SLA nedir ve hangi süreler talep edilmeli?
SLA (Service Level Agreement, yani hizmet seviyesi anlaşması), hizmet sağlayıcının iki ayrı süre üzerine verdiği yazılı taahhüttür: yanıt süresi (talebinizin ne zaman ele alınacağı) ve çözüm süresi (sorunun ne zaman giderileceği). Ciddi bir SLA olayları önceliğe göre sınıflandırır; çünkü çevrimdışı bir site ile bir yazım hatası aynı aciliyeti gerektirmez.
Standart sınıflandırma üç öncelik seviyesi kullanır. P1, engelleyici bir olayı ifade eder: erişilemeyen site, saldırı, e-ticarette çalışmayan ödeme. P2, önemli ama geçici çözümü olan bir olayı ifade eder: bozuk form, hata veren önemli bir sayfa. P3 küçük talepleri kapsar: kozmetik hata, soru, küçük değişiklik.
| Öncelik | Somut örnek | Talep edilecek yanıt süresi | Makul çözüm süresi |
|---|---|---|---|
| P1 — Kritik | Çevrimdışı site, saldırı, bozuk ödeme akışı | 1 saat (mesai saatleri içinde); 7/24 seçeneği varsa mesai dışında en fazla 4 saat | 4-8 saat |
| P2 — Önemli | Çalışmayan iletişim formu, 500 hatası veren ürün sayfası | 4 iş saati | 1-2 iş günü |
| P3 — Küçük | Görüntüleme hatası, değişiklik talebi, soru | 1 iş günü | 3-5 iş günü |
Her şeyi değiştiren üç ayrıntıyı kontrol edin. Bir: süreler mesai saatlerine göre mi, takvim saatlerine göre mi işliyor? “8 iş saati içinde” taahhüt eden bir P1 SLA'sı, cuma 18.00'deki bir arızanın pazartesiye kalabileceği anlamına gelir. İki: SLA'ya uyulmazsa ne oluyor? Yaptırım (alacak dekontu, kısmi iade) yoksa SLA, sonuçsuz bir vaatten ibarettir. Üç: kanal önemlidir: ancak bilinmedik bir platformda kayıt açıldıktan sonra işlemeye başlayan bir SLA, e-posta veya telefonla tetiklenen bir SLA'dan zayıftır.
5. Yedekler, güncellemeler, izleme: asgari güvenceler neler?
2026'da bir bakım sözleşmesinin asgari teknik güvenceleri şunlardır: 30 gün saklamalı, site dışında tutulan günlük yedekleme; 7 gün içinde (kritik açıklar için 24-48 saat) uygulanan güvenlik güncellemeleri; otomatik uyarılı erişilebilirlik izleme. Bu tabanın altında, sizi korumayan bir sözleşmeye para ödüyorsunuz demektir.
Yedeklemeler: 3-2-1 kuralı
Bir yedek ancak geri yüklenebiliyorsa değerlidir. 3-2-1 kuralı hâlâ referanstır: verilerin üç kopyası, iki farklı ortamda ve bir kopya üretim sunucusunun dışında. Siteyle aynı sunucuda saklanan bir yedek, disk arızası veya fidye yazılımı durumunda siteyle birlikte yok olur.
- Faaliyete uygun sıklık — Tanıtım sitesi için günlük; kaybedilen her siparişin bir müşteri uyuşmazlığına dönüştüğü e-ticaret için günde birkaç kez.
- Sözleşmede belirtilen saklama süresi — En az 30 gün. Sessiz bir saldırı, enfeksiyondan haftalar sonra fark edilebilir: öncesine dönebilmeniz gerekir.
- Geri yükleme testleri — Sözleşme dönemsel testler (en az üç ayda bir) öngörmelidir. Hiç test edilmemiş bir yedek, güvence değil varsayımdır.
- Müşterinin alabileceği kopya — Basit bir taleple, fahiş ücretler olmadan sitenizin ve verilerinizin kullanılabilir bir kopyasını alabilmelisiniz.
Güncellemeler ve güvenlik: korumayı sıklık sağlar
Sözleşme, güvenlik güncellemeleri (hızla, aktif olarak istismar edilen kritik bir açık için 24-48 saat içinde uygulanmalı) ile işlevsel güncellemeleri (planlanabilir) birbirinden ayırmalıdır. Ayrıca her güncellemenin ardından bir test yapılacağını da belirtmelidir: kimse fark etmeden siteyi bozan bir güncelleme, hiç güncelleme yapılmamasından daha kötüdür. Temel unsurları da ekleyin: otomatik yenilenen SSL sertifikası, site bir CMS üzerindeyse uygulama güvenlik duvarı ve dönemsel güvenlik açığı taraması.
İzleme: arızayı kim fark ediyor, siz mi hizmet sağlayıcı mı?
Erişilebilirlik izleme, siteyi kısa aralıklarla (1 ila 5 dakika) kontrol eder ve hizmet sağlayıcıyı otomatik olarak uyarır. Bu, doğrulaması kolay bir ciddiyet göstergesidir: uyarıyı kimin, ne kadar sürede aldığını sorun. Yanıt “bir sorun görürseniz bize haber verin” ise izleme diye bir şey yok demektir: izleme sizsiniz. İyi bir sözleşme dönemsel bir rapor da içerir: gerçekleşen erişilebilirlik, uygulanan güncellemeler, alınan yedekler, ele alınan olaylar.
6. Tuzaklı bir bakım sözleşmesinin tehlike sinyalleri neler?
Tuzaklı sözleşmelerin ortak bir mekanizması vardır: ayrılmayı maliyetli ya da teknik olarak imkânsız kılan bir bağımlılık yaratmak. Nereye bakacağınızı bilirseniz, tehlike sinyalleri on dakikalık bir okumada fark edilir.
- Hizmet sağlayıcı adına kayıtlı alan adı — Kendi web adresinizin sahibi artık siz değilsiniz. Bir anlaşmazlık hâlinde hizmet sağlayıcı, çevrim içi varlığınızı kelimenin tam anlamıyla kapatabilir.
- Hiçbir yönetici erişimi verilmemesi — “Güvenliğiniz için erişimleri biz tutuyoruz”: teknik rehin almanın klasik cümlesi. Erişimleriniz size aittir.
- Otomatik yenilemeli uzun taahhüt — 3 ila 6 aylık fesih bildirimiyle otomatik yenilenen 24 veya 36 ay: sözleşme, çıkış penceresini kaçırmanız için tasarlanmıştır.
- SLA yok ya da yaptırımsız — Rakamla tanımlanmış süreler yerine “elimizden geleni yaparız”. Uzayan bir arızada elinizde hiçbir sözleşmesel koz kalmaz.
- Sözleşmeyi içi boş bırakan istisnalar — Saldırı hariç, geri yükleme ek ücretli, “dış kaynaklı” olaylar kapsam dışı: ödediğiniz şeyden geriye hiçbir şey kalmaz.
- Paket dışı işlerde belirsiz ücretlendirme — Paketi aşan işler için yazılı saat ücreti yok: her talep bir pazarlığa, her fatura bir sürprize dönüşür.
- Kapalı tescilli teknoloji — Dışa aktarılamayan şirket içi bir araçla kurulmuş site: ayrılırken sıfırdan başlarsınız. Neyin, hangi formatta geri alınabileceğini her zaman sorun.
Tek başına bir tehlike sinyali pazarlık konusu yapılabilir: imzadan önce maddenin değiştirilmesini isteyin. Üç veya daha fazla tehlike sinyali ise bir ticari stratejiye işaret eder: hizmet sağlayıcınızı değiştirin. Belçika pazarı, kilitli bir sözleşmeye imza atmamanızı sağlayacak kadar çok ciddi alternatif sunuyor.
7. İmzalamadan önce bir sözleşme nasıl incelenir?
Her bakım sözleşmesini, sırasıyla uygulanan on maddelik bir kontrol listesiyle inceleyin. Her nokta, sözleşmenin kendisinde yazılı bir yanıt gerektirir: ne kadar güven verici olursa olsun sözlü bir yanıtın, olay gününde hiçbir değeri yoktur. 30 dakikalık dikkatli bir okuma ayırın; bu, web projenizin en iyi yatırımıdır.
- Dâhil olanları listeleyin: her hizmetin doğrulanabilir bir sıklığı ve çıktısı var mı (aylık güncelleme, üç aylık rapor, günlük yedekleme)?
- Hariç olanları listeleyin: olay sonrası yeniden yayına alma ve yedekten geri yükleme gerçekten dâhil mi? Saldırı hariçse sözleşme gerçekte neyi kapsıyor?
- SLA'ları kontrol edin: önceliğe göre (P1/P2/P3) rakamla tanımlanmış yanıt ve çözüm süreleri, mesai mi takvim saatleri mi, aşım hâlinde yaptırımlar.
- Yedeklemeleri kontrol edin: sıklık, saklama süresi (en az 30 gün), site dışı depolama, geri yükleme testleri ve kopya alma hakkınız.
- Mülkiyeti kontrol edin: alan adı sizin adınıza mı, yönetici erişimleri elinizde mi, kodun devri veya kopyası var mı, veritabanı geri alınabilir mi?
- Devir-iade maddesini arayın: eksiksiz iade, uygulama süresi, maliyet (ücretsiz veya makul götürü bedel), kullanılabilir format.
- Süre ve çıkışı inceleyin: başlangıç taahhüdü (ilk iş birliğinde en fazla 12 ay), fesih bildirimi (1-3 ay), otomatik yenileme koşulları.
- GDPR ayağını denetleyin: verilerinize erişen hizmet sağlayıcı, 28. madde anlamında veri işleyendir; sözleşmeye bir veri işleme sözleşmesi eşlik etmelidir.
- Paket dışını netleştirin: yazılı saat ücreti, belirli bir eşiğin üzerinde zorunlu teklif ve kullanılmayan dâhil saatlerin akıbeti (devredilebilir mi, yanar mı).
- Bir müşteri referansı isteyin: mevcut bir müşteriyle beş dakikalık bir telefon görüşmesi, on sayfalık sözleşmeden daha çok şey anlatır.
Bütçe tarafında şunu bilmeniz yeterli: bir KOBİ sitesi için ciddi bir bakım, kapsama ve teknolojiye göre çoğunlukla ayda 40 ila 150 € arasındadır; e-ticarette bu rakam daha yukarı çıkar. Site türüne göre ayrıntılı fiyat aralıkları ve bunların neleri içermesi gerektiği için 2026'da bir web sitesinin bakım maliyeti rehberimize bakın: bu makale sözleşmenin fiyatına değil, içeriğine odaklanıyor.
Son bir saha tavsiyesi: sözleşmenin imzalı sürümünü, eklerini ve kapsamı tarihleyip arşivleyin. SPF Économie'nin Dijital Olgunluk Barometresi'ne göre Belçika'daki her 10 KOBİ'den 8'inden fazlasının bir web sitesi var; yazılı sözleşme olmadan bir olay yaşayanlar, ticari vaatlerin mahkemede ileri sürülemeyeceğini iş işten geçtikten sonra fark ediyor.
Bir bakım sözleşmesi idari bir formalite değildir: siteniz çöktüğü gün 4 saatte mi yoksa 4 günde mi yeniden yayında olacağınıza karar veren belgedir. Kendi sözleşmenizi bu rehber eşliğinde yeniden okuyun. İkinci bir görüş isterseniz OptionWeb, mevcut sözleşmenizi inceler veya 24 saat içinde size bir bakım teklifi sunar: contact@optionweb.dev veya +32 491 14 01 01; Charleroi, Namur, Liège, Mons veya Bruxelles'de yüz yüze görüşme mümkündür.
Read next
2026'da Web Sitesi Bakım Maliyeti (Belçika Fiyatları)
2026'da Belçika'da bir web sitesinin bakımı ne kadar tutar? Karmaşıklığa göre ayda 50-400 € hesaplayın. Detaylı paketler, ajans ve freelancer karşılaştırması.
Web erişilebilirliği ve European Accessibility Act 2025: WCAG 2.2 rehberi
European Accessibility Act 28 Haziran 2025'te yürürlüğe girdi. Hangi şirketler kapsama giriyor, hangi WCAG 2.2 ve 2.4 yükümlülükleri var ve 2026'da bir KOBİ sitesi nasıl denetlenip düzeltilir.
