WordPress bakım hizmeti seçerken “güncellemeler yapılır” veya “site takip edilir” gibi kısa ifadeler yeterli bilgi vermez. Aynı isimle sunulan iki paket farklı sorumlulukları kapsayabilir. Karşılaştırmayı anlamlı kılmak için hangi işlemin ne sıklıkla yapılacağını, sonucunun nasıl doğrulanacağını ve sorun çıktığında kimin neyi üstleneceğini öğrenmek gerekir.
Bu rehber bir hizmet teklifi değildir; bakım kapsamını değerlendirmek için kullanılabilecek bir çerçevedir. Bir içerik blogunun ihtiyaçları, ödeme alan mağazadan farklı olabilir. Önce sitenizin önemli işlevlerini ve kesinti durumunda etkilenen süreçleri yazın; ardından paketin bu ihtiyaçları karşılayıp karşılamadığına bakın.
Sitenizin bakım ihtiyacını tanımlayın
Yayın sıklığı, kullanıcı kaydı, ödeme, rezervasyon ve dış sistem bağlantıları bakım yükünü etkiler. Ayda bir yazı eklenen tanıtım sitesinde veri değişimi sınırlıyken, sipariş alan sitede her saat yeni kayıt oluşabilir. Yedek sıklığı ve müdahale beklentisi bu farkı yansıtmalıdır.
Önemli sayfaları ve işlemleri listeleyin: iletişim formu, ürün seçimi, ödeme, şifre yenileme, üyelik içeriği veya dosya indirme. Her biri için “çalışıyor” sonucunun nasıl anlaşılacağını belirleyin. Örneğin form sayfasının açılması ile gönderilen mesajın alıcıya ulaşması ayrı kontrollerdir.
Temel kapsamı somutlaştırın
| Başlık | Sorulacak somut soru |
|---|---|
| Yedekleme | Dosyalar ve veritabanı hangi sıklıkta, nerede saklanıyor? |
| Güncelleme | Uyumluluk nasıl inceleniyor, sorun çıkarsa geri dönüş nasıl yapılıyor? |
| İşlev testi | Hangi form, ödeme ve hesap işlemleri gerçekten deneniyor? |
| İzleme | Hangi sorunlar algılanıyor ve bildirim kime gidiyor? |
| Raporlama | Yapılan iş, sonuç ve açık kalan konu nasıl kaydediliyor? |
Paket açıklamasında olmayan bir işlemin dahil olduğunu varsaymayın. İçerik girişi, yeni sayfa tasarımı, özel geliştirme, ücretli eklenti lisansı ve hosting taşıma ayrı kapsamlar olabilir. Bunları sözleşme veya teklif içinde açık biçimde ayırmak sonradan yaşanacak belirsizliği azaltır.
Yedek sayısından çok geri dönüşü değerlendirin
Yedeğin hangi bileşenleri kapsadığı, nerede tutulduğu ve ne kadar süre saklandığı önemlidir. Site dosyaları ile veritabanı birlikte düşünülmelidir. Aynı sunucuda duran tek kopya, bazı altyapı sorunlarında asıl siteyle birlikte erişilemez olabilir. Yedeğe erişim ve indirme imkanını da öğrenin.
Geri yükleme testinin yapılıp yapılmadığını sorun. “Günlük yedek var” ifadesi geri dönüş süresini veya son siparişlerin korunacağını anlatmaz. Mağazada eski veritabanına dönülecekse yeni siparişlerin nasıl ele alınacağı ayrı bir plan gerektirir. WordPress yedekleme rehberi kapsamı değerlendirmek için temel bilgiler sunar.
Güncelleme sürecinin sonucuna bakın
Otomatik güncelleme bir araçtır; bakımın tamamı değildir. Kritik bileşenler için test ortamı, geçiş notu kontrolü ve geri alma yöntemi bulunmalıdır. Güncellemeden sonra yalnız yönetim panelindeki sürüm numarasına bakmak yerine ilgili işlevin denenmesini isteyin.
Her sitenin bağımlılıkları farklı olduğundan tek bir evrensel güncelleme sırası beklemeyin. Önemli olan, sağlayıcının sitenin kullandığı tema, eklenti ve PHP ortamını tanımasıdır. Özel kod veya eski entegrasyon varsa bunların güncelleme uyumluluğunun kimin sorumluluğunda olduğunu netleştirin.
Yanıt süresi ile çözüm süresini ayırın
Bir talebin alındığının bildirilmesi ile sorunun çözülmesi aynı şey değildir. Mesai saatleri, hafta sonu kapsamı, acil durum tanımı ve iletişim kanalı açık olmalıdır. Üçüncü taraf ödeme veya hosting arızalarında bakım sağlayıcısının çözüm yetkisi sınırlı olabilir; bu durumda koordinasyon sorumluluğu belirlenmelidir.
“Sınırsız destek” gibi ifadelerde hangi işlerin kapsam dışı olduğunu özellikle okuyun. Küçük bir metin değişikliği ile yeni üyelik sistemi geliştirmek aynı iş yüküne sahip değildir. Dahil süre, ek işin fiyatlandırma yöntemi ve onay süreci biliniyorsa kapsam daha kolay yönetilir.
Anlaşılır bir bakım raporu isteyin
İyi bir rapor araç çıktılarından oluşan uzun bir dosya olmak zorunda değildir. Yapılan değişiklikleri, denenmiş işlevleri, gözlenen sonuçları ve açık kalan işleri anlaşılır biçimde göstermelidir. Hız ölçümü varsa hangi sayfanın hangi koşullarda ölçüldüğü belirtilmeli; doğrulanmamış performans artışı iddiası kullanılmamalıdır.
- Güncelleme ve ayar değişiklikleri tarihleriyle kaydedilmiş mi?
- Yedek durumu ve son geri yükleme testi belirtilmiş mi?
- Önemli form ve ödeme kontrollerinin sonucu var mı?
- Çözülmeyen konu için sorumlu ve takip tarihi belli mi?
- Ek maliyet veya lisans yenileme ihtiyacı açıklanmış mı?
Hizmet sona erdiğinde erişimi koruyun
Hosting, alan adı ve temel hizmet hesaplarının sahipliği açık olmalıdır. Bakım sona erdiğinde güncel yedek, yapılandırma notları, lisans durumu ve devam eden işler teslim edilebilmelidir. Başka bir sağlayıcıya geçişin nasıl yürütüleceğini en başta konuşmak, bakım ilişkisini daha düzenli hâle getirir.
Değerlendirmeyi kendi listenizle yapın: ihtiyaç, kapsam, doğrulama, müdahale ve devir. Aylık bakım kontrol listesini tekliflerle karşılaştırarak eksik başlıkları görebilirsiniz. En ucuz veya en kapsamlı paket yerine, sitenin gerçek işlevlerini karşılayan ve sonucu gösterilebilen paketi arayın.
Sık sorulan sorular
Hosting desteği bakım hizmetinin yerini tutar mı?
Her zaman değil. Hosting desteği sunucu tarafıyla sınırlı olabilir; tema düzeni, eklenti çakışması veya form teslim testi farklı kapsamda değerlendirilebilir. İki hizmetin sınırlarını karşılaştırın.
Az güncellenen bir site bakım ister mi?
Evet, dış hizmetler ve yazılım bileşenleri değişebilir. Ancak sıklık ve kapsam sitenin kullanımına göre daha sade tutulabilir.
Bakım paketinde hız garantisi aranmalı mı?
Önce ölçüm yöntemi ve hedef sayfalar netleşmelidir. Her cihaz ve bağlantı için tek bir puan garantisi yerine, ölçülebilir sorunların incelenmesi ve işlevlerin korunması daha anlamlıdır.