Bảo trì website định kỳ là nhóm công việc giúp website tiếp tục hoạt động ổn định sau khi bàn giao: backup, cập nhật core/plugin/theme, kiểm tra form và CTA, theo dõi lỗi, bảo mật cơ bản, uptime và khả năng khôi phục khi có sự cố. Đây là công việc vận hành kỹ thuật; nó khác với viết thêm content, mở rộng SEO hay thiết kế lại website.
Bài này khóa một owner rõ: kế hoạch bảo trì kỹ thuật + checklist + SLA sau bàn giao. Nếu câu hỏi của bạn là “ai sở hữu domain, hosting, GA4/GSC và ai chịu trách nhiệm từng đầu việc?”, xem ma trận phân vai website sau bàn giao. Nếu nhu cầu chính là cập nhật nội dung, xem quản trị và chăm sóc website.

Bảo trì website gồm những gì?
| Nhóm | Công việc điển hình | Bằng chứng nghiệm thu |
|---|---|---|
| Backup | Sao lưu file và database; kiểm tra nơi lưu và retention | Có bản backup gần nhất và biết cách restore |
| Update | Core, plugin, theme và dependency liên quan | Changelog + test trang quan trọng sau update |
| Form/CTA | Form, email nhận lead, nút gọi/chat/booking | Test thật và có kết quả nhận thành công |
| Bảo mật cơ bản | Tài khoản, quyền user, plugin không dùng, cảnh báo bất thường | Danh sách user và thành phần đang hoạt động được rà soát |
| Khả dụng | Uptime, lỗi 5xx, trang trắng, lỗi checkout/booking nếu có | Log sự cố và thời điểm khôi phục |
| Hiển thị | Trang chủ, dịch vụ, mobile, menu, footer | Checklist frontend sau thay đổi |
| Tracking | GA4/GSC và key event quan trọng | Không mất dữ liệu do thay đổi website |
Bảo trì khác phát triển website ở đâu?
Bảo trì ưu tiên ổn định, an toàn và khả năng phục hồi. Phát triển website ưu tiên tạo năng lực hoặc giá trị mới như landing page, tính năng, UX, content mới hoặc chương trình CRO. Hai nhóm có thể phối hợp nhưng không nên gộp thành một danh sách mơ hồ vì sẽ khó xác định trách nhiệm và SLA.
| Tình huống | Bảo trì | Phát triển/cải tiến |
|---|---|---|
| Plugin có bản vá | Có | Không nhất thiết |
| Form đang gửi lỗi | Có | Không |
| Thêm landing page cho chiến dịch mới | Không | Có |
| Viết lại trang dịch vụ | Không | Có |
| Khôi phục website sau lỗi update | Có | Không |
| Thiết kế lại flow checkout | Không | Có |
Backup: có bản sao chưa đủ, phải biết restore
WordPress khuyến nghị backup website trước khi cập nhật để có thể khôi phục nếu xảy ra vấn đề. Một kế hoạch backup nên ghi rõ tối thiểu: file nào được sao lưu, database nào được sao lưu, bản sao lưu nằm ở đâu, giữ trong bao lâu, ai có quyền truy cập và ai chịu trách nhiệm restore.
Tham khảo tài liệu chính thức Updating WordPress và WordPress site maintenance.
Với website có nhiều thay đổi dữ liệu như đơn hàng, booking hoặc form lead, tần suất backup cần dựa trên mức dữ liệu doanh nghiệp chấp nhận mất nếu phải restore. Không có một lịch backup cố định phù hợp cho mọi website.
Cập nhật core, plugin và theme theo quy trình có kiểm soát

WordPress hỗ trợ cập nhật core, plugin và theme; tài liệu chính thức cũng khuyến nghị có backup và khả năng rollback trước khi bật hoặc thực hiện auto-update. Với website quan trọng, nên phân loại update theo mức rủi ro thay vì cập nhật tất cả mà không kiểm tra.
- Trước update: kiểm tra backup gần nhất, ghi version hiện tại, xác định trang/tính năng chịu ảnh hưởng.
- Trong update: ưu tiên thay đổi theo nhóm nhỏ nếu website phức tạp.
- Sau update: test homepage, service page, form, menu, mobile, checkout/booking nếu có.
- Nếu lỗi: ghi nhận symptom, ngừng thay đổi tiếp và rollback theo snapshot phù hợp.
Xem thêm hướng dẫn WordPress về plugin và theme auto-updates.
Form, CTA và tracking cần được test như chức năng kinh doanh
Một website vẫn mở bình thường nhưng form gửi lỗi, email rơi sai mailbox hoặc key event không còn ghi nhận vẫn có thể gây thiệt hại. Vì vậy maintenance không nên chỉ nhìn uptime. Với website lead-gen, hãy test định kỳ toàn bộ đường đi quan trọng từ trang → CTA → form/cuộc gọi → nơi nhận lead.
| Điểm kiểm tra | Cách nghiệm thu |
|---|---|
| Form liên hệ | Gửi thử và xác minh email/CRM thực sự nhận được |
| Click gọi/chat | Kiểm tra link và thiết bị mobile |
| Booking/checkout | Chạy test flow phù hợp môi trường và quy trình |
| GA4 key event | Kiểm tra sự kiện sau thay đổi website |
| Search Console | Theo dõi lỗi hoặc biến động bất thường sau migration/thay đổi lớn |
Lịch bảo trì gợi ý cho website SME
Tần suất dưới đây là khung vận hành gợi ý, không phải tiêu chuẩn bắt buộc. Website bán hàng, đặt lịch hoặc có thay đổi thường xuyên cần lịch dày hơn website giới thiệu ít cập nhật.
| Tần suất | Việc nên làm | Đầu ra |
|---|---|---|
| Hằng tuần | Test form/CTA quan trọng, xem cảnh báo uptime/sự cố | Không có lỗi blocker chưa xử lý |
| Hằng tháng | Review update, backup, user/plugin, trang chính, mobile | Changelog + checklist |
| Hằng quý | Test restore mẫu nếu quy trình cho phép, rà dependency và tracking | Xác nhận khả năng phục hồi và dữ liệu đo lường |
| Sau thay đổi lớn | Frontend QA, form, tracking, cache, indexability liên quan | Read-back và biên bản thay đổi |
SLA bảo trì nên ghi những gì?
SLA không nên chỉ ghi “hỗ trợ nhanh”. Cần định nghĩa loại sự cố, kênh tiếp nhận, giờ hỗ trợ, thời gian phản hồi mục tiêu, người có quyền phê duyệt thay đổi và điều kiện escalation. Thời gian dưới đây chỉ là ví dụ để doanh nghiệp thiết kế SLA; không phải chuẩn chung.
| Mức | Ví dụ | Cách xử lý nên có |
|---|---|---|
| P1 | Website không truy cập, checkout/booking ngừng hoàn toàn, sự cố bảo mật nghiêm trọng | Kênh khẩn cấp, owner rõ, ưu tiên khôi phục trước tối ưu |
| P2 | Form chính lỗi, lỗi hiển thị ảnh hưởng nhiều người dùng | Ticket ưu tiên, workaround nếu có, xác minh sau sửa |
| P3 | Lỗi nhỏ, chỉnh nội dung kỹ thuật, warning không chặn người dùng | Xử lý theo backlog bảo trì |
Quan trọng hơn con số phản hồi là quy trình: incident → owner → snapshot → fix → read-back → frontend verify → ghi log. Nếu thay đổi có rủi ro cao, phải có phương án rollback trước khi triển khai.
Những việc không nên nhét vào gói “bảo trì” mơ hồ
- Viết hàng loạt bài SEO mới.
- Thiết kế lại toàn bộ giao diện.
- Xây module hoặc tích hợp lớn mới.
- Cam kết traffic, ranking hoặc lead.
- Quản trị ownership/domain/account nếu chưa xác định quyền và vai trò.
Nếu mục tiêu là content, internal link, CTA hoặc cập nhật bài cũ, đó là workstream chăm sóc nội dung/SEO. Có thể xem dịch vụ content marketing hoặc quy trình tối ưu content cũ.
Checklist nghiệm thu sau mỗi đợt bảo trì

- Website và các trang quan trọng mở được.
- Form/CTA/booking quan trọng đã test.
- Mobile không có lỗi hiển thị lớn.
- Tracking quan trọng vẫn ghi nhận.
- Backup/snapshot và changelog đã được lưu.
- Nếu có lỗi, trạng thái rollback hoặc ticket follow-up đã rõ.
Khi nào cần đội kỹ thuật, khi nào cần đội nội dung?
Nếu vấn đề liên quan hosting, code, plugin/theme, backup, bảo mật, lỗi form, downtime hoặc tích hợp, hãy giao cho người có năng lực kỹ thuật. Nếu website chạy ổn nhưng nội dung cũ, page dịch vụ thiếu thông tin, internal link yếu hoặc CTA chưa rõ, đó là bài toán content/SEO. Tách đúng workstream giúp SLA rõ và tránh để một bên chịu trách nhiệm cho phần họ không kiểm soát.
Kết luận
Website sau bàn giao không cần một danh sách công việc thật dài; cần một hệ thống bảo trì có thể kiểm chứng. Với SME, nền tảng tối thiểu là backup có thể restore, update có kiểm soát, test form/CTA, theo dõi sự cố, kiểm tra tracking và SLA có owner rõ. Các nhu cầu phát triển content, SEO hoặc tính năng mới nên được tách thành workstream riêng để không làm mờ trách nhiệm bảo trì.
Nếu doanh nghiệp chưa rõ ai sở hữu và ai chịu trách nhiệm từng phần sau bàn giao, bắt đầu từ ma trận phân vai Owner – Content – SEO – Technical. Nếu cần quản trị nội dung định kỳ, xem quản trị và chăm sóc website.