Wawasan Oura • 16 Oktober 2026
Biaya Maintenance Website: Apa yang Perlu Dirawat dan Ditanggung?
Oura Works
Biaya maintenance website tidak selalu berupa satu paket bulanan. Pisahkan biaya layanan rutin seperti domain, hosting, dan lisensi dari pekerjaan pemeliharaan seperti pembaruan, backup, pemeriksaan, dukungan, dan perbaikan. Sebelum membandingkan penawaran, tulis apa yang harus dikerjakan, siapa yang bertanggung jawab, batas layanan, serta biaya yang tetap ditagihkan terpisah. Besarnya biaya bergantung pada platform, risiko, jumlah perubahan, tingkat dukungan, dan kebutuhan bisnis.
Hal terpenting bukan mencari paket dengan daftar tugas terpanjang, melainkan memastikan situs tetap dapat dikelola sesuai kebutuhan usaha. Toko dengan transaksi harian, misalnya, mungkin memerlukan pemeriksaan berbeda dari situs profil perusahaan yang jarang berubah. Tidak ada satu jadwal atau lingkup maintenance yang otomatis cocok untuk semua website.
Apa saja yang termasuk biaya rutin website?
Mulailah dengan menginventaris biaya yang benar-benar muncul pada akun dan tagihan usaha Anda. Istilah “maintenance” kerap dipakai untuk beberapa pekerjaan berbeda, sehingga dua penawaran dengan nama paket serupa belum tentu menyediakan hal yang sama.
| Komponen | Contoh yang perlu diperiksa | Pertanyaan untuk penyedia |
|---|---|---|
| Domain | Perpanjangan nama domain dan pengelolaan DNS | Akun registrarnya atas nama siapa dan kapan diperpanjang? |
| Hosting atau platform | Server, layanan cloud, atau langganan platform | Kapasitas, batas pemakaian, lokasi akun, serta biaya tambahan apa yang berlaku? |
| Lisensi | Tema, plugin, font, alat formulir, atau layanan pihak ketiga | Apakah lisensi termasuk, siapa pemiliknya, dan apa akibatnya bila paket berhenti? |
| Backup | Pembuatan, penyimpanan, dan retensi salinan | Bagian apa yang disalin, berapa lama disimpan, dan bagaimana pemulihan diuji? |
| Pembaruan | Core, tema, plugin, dependensi, atau konfigurasi | Apakah pembaruan diuji sebelum diterapkan dan siapa menangani konflik? |
| Pemantauan | Pemeriksaan ketersediaan, error, formulir, atau komponen penting | Apa yang dipantau, siapa menerima notifikasi, dan apa tindak lanjutnya? |
| Dukungan dan perbaikan | Penanganan kendala, perubahan ringan, atau waktu kerja teknis | Bagaimana jam dukungan, waktu respons, batas pekerjaan, dan biaya di luar kuota? |
| Pengembangan | Halaman, fungsi, integrasi, atau perubahan desain baru | Apakah pekerjaan ini harus mendapat estimasi dan persetujuan terpisah? |
Biaya domain dan hosting dapat ditagih langsung oleh vendor infrastruktur, sedangkan maintenance mungkin dikelola tim internal atau penyedia lain. Minta daftar nama vendor, akun pemilik, masa berlaku, dan jalur penagihan. Dengan begitu, usaha mengetahui biaya mana yang berhenti jika kontrak jasa pemeliharaan berakhir dan biaya mana yang harus tetap dibayar agar layanan tidak terputus.
Tentukan pembagian tanggung jawab sejak awal
Website sering melibatkan beberapa pihak: pemilik bisnis, staf konten, tim TI, pengembang, penyedia hosting, dan pemilik integrasi. Jika tugas tidak ditetapkan, setiap pihak dapat mengira orang lain yang memegang akses, memperpanjang layanan, atau memeriksa fungsi penting.
| Pekerjaan | Pemilik bisnis | Tim internal | Penyedia teknis |
|---|---|---|---|
| Memegang akses registrar, hosting, CMS, dan analitik | Menetapkan pemilik akun | Menyimpan daftar akses sesuai kebijakan | Memberi akses sesuai peran yang disepakati |
| Memperbarui informasi layanan, harga, dan kebijakan | Menyetujui informasi | Menyediakan naskah dan pemeriksaan | Memasukkan perubahan bila termasuk lingkup |
| Memperpanjang domain dan lisensi | Menyetujui biaya dan memastikan penanggung jawab | Mengingatkan masa berlaku jika ditugaskan | Menangani hanya akun yang tercantum dalam kontrak |
| Memeriksa formulir, tautan, dan fungsi utama | Menentukan fungsi bisnis yang kritis | Menguji alur dari sisi pengguna | Membantu mendiagnosis masalah sesuai akses |
| Menjalankan pembaruan teknis | Menyetujui perubahan berisiko | Menguji alur kerja internal | Menyusun, menerapkan, dan mencatat pekerjaan sesuai kesepakatan |
| Menangani insiden dan pemulihan | Menentukan kontak pengambil keputusan | Menyampaikan dampak yang terlihat | Menjalankan tindakan teknis yang termasuk tanggung jawabnya |
Tabel ini contoh pembagian, bukan aturan baku. Pada usaha kecil, satu orang mungkin mengisi beberapa peran. Hal yang perlu dipastikan adalah siapa berwenang menyetujui perubahan, siapa yang memiliki akun, siapa dapat dihubungi saat masalah terjadi, dan siapa menyimpan dokumentasi setelah pekerjaan selesai.
Backup perlu disertai cara pemulihan yang dipahami
Salinan backup berguna untuk membantu mengembalikan data atau file ketika diperlukan, tetapi keberadaan salinan tidak dengan sendirinya membuktikan bahwa pemulihan akan berhasil atau memenuhi waktu yang dibutuhkan bisnis. Pastikan penyedia menjelaskan komponen yang dicadangkan, lokasi dan masa retensi, akses ke salinan, serta prosedur uji pemulihan.
Untuk WordPress, dokumentasi resminya menjelaskan perlunya mencadangkan file dan database agar website dapat dipulihkan. Panduan pembaruan WordPress juga menyarankan backup database dan file sebelum peningkatan versi. Situs dengan platform lain perlu mengikuti mekanisme backup dan pemulihan sesuai dokumentasi platformnya. Panduan backup WordPress dan dokumentasi layar pembaruan WordPress.
Saat meminta penjelasan, ajukan pertanyaan ini:
- Apakah salinan mencakup database, unggahan, konfigurasi, dan bagian lain yang diperlukan untuk platform tersebut?
- Di mana salinan disimpan, siapa yang dapat mengaksesnya, dan berapa lama disimpan?
- Apakah backup berjalan otomatis, dan bagaimana kegagalan proses diketahui?
- Siapa berwenang meminta pemulihan dan siapa yang melaksanakannya?
- Apakah uji pemulihan dilakukan pada lingkungan terpisah, dengan persetujuan dan prosedur yang jelas?
- Bagaimana hasil dan keterbatasan uji dicatat?
Jangan meminta pemulihan langsung di situs aktif sebagai uji coba tanpa memahami risiko dan prosedurnya. Untuk sistem yang kritis, minta penyedia menjelaskan target pemulihan, ketergantungan pada vendor lain, dan langkah eskalasi. Angka target seperti waktu pemulihan atau kehilangan data yang dapat ditoleransi harus disepakati berdasarkan kebutuhan bisnis, bukan diasumsikan tersedia dalam semua paket.
Bedakan pemantauan, pembaruan, perbaikan, dan pengembangan
Ruang lingkup yang jelas membantu kedua pihak membedakan pemeriksaan rutin dari pekerjaan baru. Nama pekerjaan bisa berbeda antarpenyedia; minta definisi tertulis dan contoh kasus untuk setiap jenis layanan.
| Jenis pekerjaan | Tujuan | Contoh pertanyaan tentang lingkup |
|---|---|---|
| Pemantauan | Mengetahui sinyal gangguan pada komponen yang disepakati | Komponen apa yang diperiksa dan bagaimana notifikasi diteruskan? |
| Pembaruan | Mengelola versi perangkat lunak atau konfigurasi | Apa yang diuji sebelum dan sesudah pembaruan? |
| Perbaikan | Menangani fungsi yang tidak berjalan sesuai kondisi yang disepakati | Bagaimana kendala dicatat, diprioritaskan, dan dinyatakan selesai? |
| Perubahan konten | Memperbarui informasi yang tersedia di halaman | Berapa banyak permintaan, halaman, atau jam yang termasuk? |
| Pengembangan | Membuat fungsi, integrasi, atau struktur baru | Apakah diperlukan spesifikasi, estimasi, persetujuan, dan jadwal terpisah? |
Paket dapat mencakup sebagian kategori atau hanya akses untuk meminta bantuan. Periksa apakah pekerjaan menggunakan batas jam, jumlah permintaan, atau estimasi per tugas. Pastikan penyedia menerangkan biaya pihak ketiga, pekerjaan mendesak, pengujian tambahan, dan proses persetujuan sebelum ada tagihan di luar kesepakatan.
Tanyakan cara dukungan menangani masalah
Istilah service-level agreement (SLA), waktu respons, dan waktu penyelesaian tidak sama. Waktu respons biasanya menunjukkan kapan laporan mulai ditangani atau mendapat tanggapan, sementara waktu penyelesaian bergantung pada penyebab, akses, pihak lain, dan tingkat kerumitan masalah. Tanyakan definisi yang dipakai penyedia dan jangan membaca target respons sebagai janji bahwa seluruh kendala selesai dalam periode tersebut.
Sebelum menyetujui layanan, minta informasi berikut:
- Kanal pelaporan dan jam dukungan, termasuk hari libur bila relevan.
- Cara menentukan tingkat prioritas dan siapa yang menetapkannya.
- Definisi waktu mulai dihitung: sejak tiket dibuat, diterima, atau informasi pendukung tersedia.
- Perbedaan target respons, pembaruan status, dan penyelesaian.
- Ketergantungan pada hosting, gateway pembayaran, DNS, atau vendor eksternal.
- Proses persetujuan biaya jika masalah berada di luar lingkup.
- Laporan pekerjaan yang mencatat masalah, tindakan, perubahan, dan hal yang menunggu pihak lain.
Minta contoh laporan yang telah disamarkan bila ingin memahami bentuk dokumentasinya. Pastikan laporan dapat dibaca oleh orang di bisnis Anda dan bisa menjadi dasar keputusan, bukan hanya daftar istilah teknis.
Buat checklist pemeriksaan yang sesuai dengan risiko situs
Checklist tidak perlu menyalin frekuensi yang sama untuk semua bisnis. Mulai dari fungsi yang bila terganggu akan menghambat penjualan, layanan, atau operasi, lalu tentukan pemeriksaan berdasarkan perubahan sistem, dampak gangguan, ketentuan platform, dan kemampuan tim. Frekuensi akhirnya sebaiknya tertulis dan ditinjau ketika website atau alur kerja berubah.
| Pemeriksaan | Bukti yang bisa dicatat | Penanggung jawab |
|---|---|---|
| Masa berlaku domain, hosting, dan lisensi | Tanggal kedaluwarsa dan nama pemilik akun | … |
| Backup terakhir dan hasil pemantauan proses | Waktu proses dan notifikasi bila gagal | … |
| Fungsi formulir, tombol kontak, atau pemesanan | Hasil uji dari skenario yang disepakati | … |
| Pembaruan dan perubahan teknis | Versi, tanggal, cakupan pengujian, dan catatan | … |
| Akses pengguna dan akun yang tidak lagi diperlukan | Daftar yang ditinjau serta tindak lanjut | … |
| Error, tautan penting, atau halaman yang perlu perhatian | URL, waktu ditemukan, dampak, dan tiket | … |
| Perubahan konten dan kebutuhan berikutnya | Permintaan, persetujuan, dan status | … |
Untuk website yang mengandalkan pencarian, tim dapat memeriksa laporan pengindeksan di Search Console sebagai salah satu sumber diagnosis. Laporan tersebut membantu melihat status yang dilaporkan Google untuk URL, tetapi bukan pengganti pemantauan server atau pengujian fungsi bisnis. Mengirim sitemap membantu Google menemukan URL yang dicantumkan, namun tidak menjamin halaman akan dirayapi atau diindeks. Pelajari laporan pengindeksan halaman dan cara membuat sitemap.
Cara meminta penawaran maintenance yang bisa dibandingkan
Berikan informasi dasar yang sama kepada setiap calon penyedia. Jelaskan platform dan layanan yang dipakai, fungsi website yang penting, riwayat kendala yang relevan, tingkat akses yang tersedia, serta batas perubahan yang mungkin diminta. Jangan mengirim kata sandi melalui dokumen penawaran; buat akses secara terpisah dengan metode yang disepakati.
Minta setiap penawaran mencantumkan:
- daftar tugas yang dikerjakan dan yang tidak termasuk;
- layanan domain, hosting, lisensi, backup, dan pihak ketiga secara terpisah;
- frekuensi atau pemicu pemeriksaan yang disepakati;
- metode pelaporan dan bukti pekerjaan;
- pembagian akses serta kepemilikan akun;
- kanal dukungan, waktu respons, eskalasi, dan pengecualian;
- batas perubahan konten atau jam kerja, jika digunakan;
- cara meminta pekerjaan baru dan mendapatkan persetujuan biaya;
- masa kontrak, penghentian layanan, ekspor data, dan serah terima.
Bandingkan jumlah pekerjaan yang benar-benar diperlukan dan risiko yang ditanggung, bukan hanya nilai tagihan atau banyaknya istilah di proposal. Jika biaya baru akan dipastikan setelah audit atau pembahasan teknis, minta daftar asumsi yang memengaruhi estimasi. Hindari menyetujui kata “support penuh” tanpa definisi tertulis tentang jam, cakupan, prioritas, dan proses perubahan.
Jika website perlu ditinjau sebelum menentukan lingkup kerja, Oura dapat membahas kebutuhan pada layanan pengembangan website dan paket serta harga. Untuk materi operasional terkait, baca panduan perawatan dan backup website dan praktik keamanan website. Pastikan kebutuhan, akses, serta tanggung jawab ditetapkan sebelum pekerjaan dimulai.
FAQ
Apakah maintenance website wajib dilakukan setiap bulan?
Tidak ada frekuensi yang otomatis sesuai bagi semua website. Tentukan pemeriksaan dari risiko, perubahan yang terjadi, platform, serta fungsi yang penting bagi bisnis. Catat jadwal atau pemicunya dan tinjau ulang bila kebutuhan berubah.
Apa beda hosting dengan maintenance website?
Hosting menyediakan lingkungan untuk menjalankan website. Maintenance adalah pekerjaan pengelolaan seperti pembaruan, pemeriksaan, backup, dukungan, atau perbaikan sesuai lingkup layanan. Satu penyedia bisa menawarkan keduanya, tetapi pastikan tagihan dan tanggung jawabnya dijelaskan terpisah.
Apakah backup otomatis sudah cukup?
Backup otomatis membantu membuat salinan sesuai konfigurasi, tetapi tim tetap perlu mengetahui cakupan, lokasi, retensi, status kegagalan, akses, dan prosedur pemulihan. Tanyakan apakah pemulihan pernah diuji serta bagaimana hasilnya dicatat.
Apa yang perlu ditanyakan sebelum memilih penyedia maintenance?
Tanyakan tugas yang termasuk, akun yang akan dikelola, cara backup dan pemulihan, prosedur pembaruan, jam dan kanal dukungan, definisi waktu respons, pengecualian, serta biaya pekerjaan tambahan. Minta semua jawaban penting dimasukkan ke proposal atau kontrak.
Lanjutkan ke panduan dan cerita yang membahas keputusan serupa.
Fondasi SEO untuk pencarian AI
Rawat akses teknis dan informasi yang membantu pembaca.
Pengukuran prospek dengan GA4
Hubungkan tindakan website dengan konteks sales.
Brief proyek website yang jelas
Sepakati tujuan, cakupan, serta keputusan proyek.
Copy layanan sebelum konsultasi
Perjelas manfaat, cakupan, bukti, dan langkah berikutnya.