Web Tasarım
Web Sitesi Bakım Paketi Neleri Kapsar?
Web sitesi bakımında destek, kod garantisi, güncelleme, yedek ve küçük içerik işlerini ayırın; dahil/hariç kapsamı örneklerle karşılaştırın.
Web Tasarım
Web sitesi bakımında destek, kod garantisi, güncelleme, yedek ve küçük içerik işlerini ayırın; dahil/hariç kapsamı örneklerle karşılaştırın.
Web sitesi bakım paketi; güncellemeleri, yedekleri, kritik işlevlerin kontrolünü ve sözleşmede belirtilen küçük düzenlemeleri düzenli bir çalışma planında toplar. Amacı sitenin yayından sonraki işleyişini takip etmektir. Yeni bir tasarım, büyük entegrasyon veya sınırsız içerik üretimi bakım paketine otomatik dahil değildir.
Bakım hizmetini karşılaştırırken yalnızca aylık ücrete bakmayın. Hangi işlemlerin yapılacağı, destek kanalının nasıl çalışacağı ve bir sorun olduğunda kimin hangi adımı üstleneceği açık olmalıdır.
| Hizmet | Temel amacı | Teklifte netleştirilmesi gereken |
|---|---|---|
| Teknik destek | Sitenin kullanımı ve teknik sorunlarda yardım | Kanal, saatler, kapsam ve süre |
| Kod garantisi | Teslim edilen yazılımdan kaynaklanan hata/bozukluğu düzeltmek | Hangi teslimi kapsadığı, dönem ve kapsam dışı durumlar |
| Düzenli bakım | Güncelleme, yedek, kontrol ve kararlaştırılmış küçük işler | İş listesi, sıklık, çalışma sınırı ve rapor |
| Yeni geliştirme | Yeni sayfa, modül veya farklı iş akışı üretmek | Ayrı kapsam, süre ve bedel |
Koçyiğit Yazılım'ın teknik özellikler sayfasında 6 ay teknik destek ve 6 ay kod garantisi yer alır; aylık bakım ve teknik destek ise +2.500 TL/ay olarak ayrıca listelenir. Bu bilgiler 11 Ekim 2026 tarihinde kontrol edilmiştir. Projenizde bu hizmetlerin başlangıç/bitiş tarihi ve iş listesi yazılı teklifte belirtilmelidir.
Altı ay kod garantisi, o dönemde istenen her yeni özelliğin ücretsiz yapılacağı anlamına gelmez. Bakımın ne zaman başlayacağı da otomatik olarak altı ay sonrasına bırakılmış sayılmaz. Örneğin düzenli yedek ve kontrol işi ilk yayından itibaren ayrıca planlanabilir. Ücretsiz ve ücretli dönemlerin kapsamını aynı tabloda karşılaştırın.
| Kontrol | Ne amaçla yapılır? | İşin tamamlandığı nasıl anlaşılır? |
|---|---|---|
| Yazılım ve bağımlılıklar | Gerekli güncellemeleri değerlendirmek | Uygulanan sürüm ve sonrasında yapılan testler kaydedilir |
| Yedekleme | Kod, dosya ve veriyi geri alınabilir tutmak | Son başarılı yedek ve geri yükleme kontrolü görülür |
| Form ve bildirim | Taleplerin doğru kişiye ulaştığını doğrulamak | Deneme gönderimi ve bildirim sonucu kontrol edilir |
| Kritik satın alma/randevu akışı | Ana işlemlerin çalışmasını izlemek | İlgili test adımları kayda geçer |
| Erişilebilirlik ve hata | Sitenin ve önemli sayfaların çalışmasını takip etmek | Tespit edilen hata ve müdahale notu tutulur |
| Performans | Görsel veya değişikliklerin siteyi yavaşlatmasını fark etmek | Aynı koşullarla karşılaştırılan ölçümler değerlendirilir |
| Alan adı, SSL ve lisanslar | Süre bitimini kaçırmamak | Yenileme tarihi ve sorumlusu envanterde bulunur |
Sıklık projenin riskine göre seçilmelidir. Ayda bir güncellenen bir tanıtım sitesiyle her gün sipariş alan mağazanın veri kaybına toleransı aynı değildir. “Her iş her ay yapılır” gibi tek bir takvim yerine yedek, güncelleme, kritik akış testi ve rapor sıklıkları ayrı yazılmalıdır.
Aşağıdaki tablo bir sınıflandırma örneğidir; bütün projeler için otomatik ücretsiz iş taahhüdü değildir. İşin hangi kategoriye girdiği sözleşmedeki teslim ve bakım listesiyle karşılaştırılır.
| Talep | Genellikle nasıl ele alınır? | Kapsam kontrolü |
|---|---|---|
| Hazır telefon numarasını değiştirmek | Küçük içerik düzenlemesi | Dahil değişiklik hakkı ve ilgili alan kontrol edilir |
| Var olan alana hazır görsel/metin yerleştirmek | Küçük içerik düzenlemesi | Adet, süre ve tasarım etkisi incelenir |
| Yeni bir hizmet sayfası tasarlamak | Yeni geliştirme veya içerik işi | Şablon kullanımı ve yeni üretim ayrı tanımlanır |
| Yeni randevu veya üyelik sistemi istemek | Yeni geliştirme | Veri, panel, entegrasyon ve test kapsamı çıkarılır |
| Daha önce çalışan formun hata vermesi | Teknik sorun incelemesi | Yazılım, servis, hesap veya erişim nedeni belirlenir |
| Ödeme sağlayıcısının API değişikliğine uyum | Ön inceleme gerektiren iş | Bağımlılık, sözleşme ve değişiklik büyüklüğü değerlendirilir |
| Yeni makale/fotoğraf üretimi | İçerik üretimi | Bakımda açıkça yer almıyorsa ayrıca fiyatlanır |
Bir işin kısa sürmesi onun mutlaka ücretsiz olduğu anlamına gelmez. Aynı şekilde hata bildiriminin incelenmesi de her durumda yeni geliştirme değildir. Sağlıklı süreçte önce neden ve kapsam anlaşılır, sonra gerekiyorsa ek iş teklifi verilir.
Bu sorunun tek bir standart cevabı yoktur. Koçyiğit'in herkese açık sayfasında aylık 2.500 TL bedel yer alırken saat/talep sınırı belirtilmiyor. Bu nedenle sınırsız destek veya belirli saat hakkı varsaymayın; kendi teklifinizde açıkça yazılmasını isteyin.
Çalışma saatle sınırlanıyorsa inceleme, test ve uygulamanın süreye dahil olup olmadığını öğrenin. Taleple sınırlanıyorsa bir talebin tanımını isteyin: tek bir metin değişikliği ile on sayfadaki içerik yenilemesi aynı talep sayılır mı? Kullanılmayan hakkın sonraki aya devredip devretmediği ve aşımın nasıl ücretlendirildiği de net olmalıdır.
İlk yanıt, ekibin talebinizi aldığını ve değerlendirdiğini bildirmesidir. Çözüm süresi, sorunun düzeltilip kontrolünün tamamlanmasıdır. Dış sağlayıcıya bağlı bir sorun, yazılım ekibinin doğrudan kontrol ettiği bir hatayla aynı sürede çözülemeyebilir.
| Durum | Talepte bulunması gereken bilgi | Öncelik değerlendirmesi |
|---|---|---|
| Site tamamen açılmıyor | URL, başlangıç zamanı, görülen hata | Ana hizmet kesintisi |
| Ödeme/form tamamlanmıyor | İşlem adımı, cihaz, hata, hassas bilgi içermeyen ekran görüntüsü | İş kaybına neden olan kritik akış |
| Belirli sayfada görsel bozuk | Sayfa ve beklenen görünüm | Etkiye göre planlı düzeltme |
| Yeni kampanya içeriği | Hazır metin/görsel ve istenen tarih | Planlı içerik işi |
Destek saatleri, tatil günleri, acil bildirim kanalı ve yanıt hedefi sözleşmede yer almalıdır. Gerçek hizmet planında bulunmayan “7/24” veya “bir saatte kesin çözüm” ifadesini paket açıklamasına eklemek, müşterinin yanlış beklenti kurmasına neden olur.
Yedek dosyasının oluşması ilk adımdır. Eksiksiz olması, okunabilmesi ve siteyi çalışır duruma getirebilmesi ayrıca kontrol edilmelidir. Kodun Git'te bulunması, veritabanı ve yüklenen görsellerin de yedeklendiği anlamına gelmez.
WordPress'in resmi yedekleme rehberi tipik WordPress sitesinde dosyalar ve veritabanının birlikte ele alınması gerektiğini açıklıyor. Özel yazılımda da hangi parçaların geri yükleme için gerektiği sistemin yapısına göre belirlenmelidir.
Bakım teklifinde şu beş cevap bulunmalı: hangi veriler yedekleniyor, ne sıklıkla, nerede tutuluyor, kaç gün/sürüm saklanıyor ve geri yükleme nasıl deneniyor? Ana sunucu bozulduğunda aynı sunucudaki tek kopyaya erişemeyebilirsiniz; saklama yerlerinin riski ayrıca düşünülmelidir.
Saatlik sipariş alan mağazada günlük yedek, son yedekten sonra oluşan siparişleri içermeyebilir. Yedek planını kabul edilebilir veri kaybıyla ilişkilendirin. Geri yükleme sırasında yeni siparişlerin nasıl korunacağı da operasyonun bir parçasıdır. “Yedek var” cümlesi bütün veri kaybının önlendiği garantisi değildir.
Rapor; yapılan işleri, açık sorunları ve sonraki adımı anlaşılır biçimde göstermelidir. Sadece “bakım yapıldı” ifadesi hangi işlemin uygulandığını anlatmaz.
| Rapor alanı | Örnek kayıt biçimi |
|---|---|
| Dönem ve kapsam | Hangi site, hangi tarih aralığı, hangi paket |
| Yapılan işler | Güncelleme, içerik değişikliği, kritik akış testleri |
| Yedek bilgisi | Son başarılı kopya, saklama yeri türü, kontrol sonucu |
| Açık konular | Bekleyen müşteri onayı, dış sağlayıcı sorunu, ek geliştirme |
| Sonraki adım | İş, sorumlu ve planlanan tarih |
Raporun içinde parola, API anahtarı veya müşteri kişisel verisi bulunmamalıdır. Teknik ayrıntı, müşterinin yapılan işi ve takip edilmesi gereken riski anlamasına yardımcı olduğu ölçüde eklenmelidir.
Hangi site ve modüller kapsama dahil? Alan adı/hosting bedeli bakımın içinde mi? İçerik değişikliğinin sınırı ne? Yedek ve geri yükleme işi dahil mi? Dış servis kesintilerinde kim takip yapacak? Yeni işlerin onayı nasıl alınacak? Ayrılınca erişim ve yedekler nasıl teslim edilecek?
Bu soruları proje briefine ve teklif ekine yazabilirsiniz. Genel site kapsamını karşılaştırmak için web sitesi fiyatları sayfasını kullanın.
Hayır. Güncelleme, yedekleme ve kontroller riski yönetmeye yardımcı olur; bütün saldırı, kesinti veya veri kaybını kesin olarak önlediği söylenemez.
Panel, içerik düzenleme işini kolaylaştırır. Sunucu, yazılım, yedek ve entegrasyon sorumluluğunu kendiliğinden ortadan kaldırmaz. Bu işler içeride bir ekip veya dış hizmetle yürütülebilir.
Hangi veriyi, hangi dönem için tuttuğunu ve nasıl geri verdiğini kontrol edin. Geri yükleme talebinin süresi ve ücreti de önemli olabilir. Kapsamı bilinmeyen bir yedeği tüm sistemin geri dönüş planı saymayın.
Hazır bir yazının panele girilmesi ile yeni içerik araştırıp yazılması farklıdır. Pakette içerik üretimi açıkça listelenmediyse dahil olduğunu varsaymayın.
Risk ve iş yükü farklı olduğu için kapsam da farklı olabilir. Az değişen tanıtım sitesinde içerik yükü düşük olabilir; domain, SSL, form ve yedek sorumluluğu yine belirlenmelidir.
Sözleşmedeki kod/veri/yedek, erişim ve lisans teslimlerini isteyin. Site teslim kontrol listesi devir sırasında kullanılabilir.
Site adresinizi, kullanılan paneli, önemli işlemleri ve beklediğiniz içerik desteğini paylaşın. Web tasarım hizmeti kapsamında yeni proje ve mevcut site ihtiyacınızı değerlendirebilir; bakım teklifini açık iş listesiyle isteyebilirsiniz.