Mục lục
Hỏi mười chủ doanh nghiệp "bảo trì website là làm gì", chín người trả lời gần như giống nhau: cập nhật phiên bản, sao lưu, kiểm tra xem site có sập không. Và tần suất thì mặc định: gói hàng tháng.
Tôi hiểu vì sao cách nghĩ đó phổ biến. Nó gọn, dễ báo giá, dễ ghi vào hợp đồng.
Nó cũng sai — và tôi sẽ chứng minh bằng một con số duy nhất: 5 giờ.
Đó là khoảng thời gian trung vị từ lúc một lỗ hổng bị công bố đến lúc nó bị khai thác hàng loạt, theo báo cáo State of WordPress Security in 2026 của Patchstack: "the weighted median time to first exploit is 5 hours" (Patchstack).
Năm giờ. Còn gói bảo trì của bạn chạy 30 ngày một lần.
Vấn đề không nằm ở việc bạn có bảo trì hay không. Nó nằm ở chỗ bạn đang chạy mọi đầu việc trên cùng một cái đồng hồ — trong khi chúng cần bốn cái.
Vì sao "hàng tháng" là một câu trả lời sai
Hãy làm phép tính đơn giản nhất bài này.
Một lỗ hổng nghiêm trọng được công bố vào ngày 3. Gói bảo trì của bạn chạy vào ngày 1 hàng tháng. Nghĩa là website của bạn phơi mình 29 ngày trước một thứ mà kẻ tấn công bắt đầu khai thác sau 5 giờ.
Đây không phải giả thuyết. Ngày 22/9/2026, WordPress phát hành bản vá cho một lỗ hổng cho phép chiếm quyền thực thi mã. Chưa đầy 5 tiếng sau, hệ thống giám sát của Patchstack đã ghi nhận những lượt dò tìm đầu tiên — tôi đã viết chi tiết về vụ này trong bài phân tích CVE-2026-87902.
Ở chiều ngược lại, cũng cái gói hàng tháng đó bắt bạn trả tiền để ai đó kiểm tra năm copyright ở footer mười hai lần một năm. Một việc thay đổi đúng một lần mỗi năm.
Đó là toàn bộ vấn đề: bạn đang quá chậm ở thứ có thể giết bạn, và quá siêng ở thứ không đổi.
Câu hỏi đúng không phải "bao lâu bảo trì một lần?" mà là: "Việc này chạy theo nhịp của ai — của kẻ tấn công, của nền tảng, của thị trường, hay của doanh nghiệp tôi?" Mỗi câu trả lời là một cái đồng hồ khác nhau.
Trước hết: nền tảng của bạn lo gì, và KHÔNG lo gì
Đây là nguyên tắc gốc, và là thứ quyết định danh sách việc của bạn dài hay ngắn.
Mỗi nền tảng đã lo sẵn một phần. Squarespace, Shopify, Wix lo server, lõi CMS, vá bảo mật hệ thống, SSL, CDN, uptime. WordPress tự quản thì bạn lo gần hết — và đó là lý do khối lượng bảo trì WordPress lớn hơn hẳn.
Nhưng không nền tảng nào lo giúp bạn bốn thứ sau. Chúng luôn là của bạn:
- Custom code — đoạn JS/CSS mà ai đó gắn thêm vào site bạn.
- Backup đầy đủ — thứ hầu hết nền tảng SaaS chỉ cung cấp một nửa.
- Script và tích hợp bên thứ ba — pixel, form, CRM, chat.
- Quyền truy cập — ai đang có chìa khoá vào nhà bạn.
Con số của Patchstack nói đúng điều này. Trong 11.334 lỗ hổng mới phát hiện ở hệ sinh thái WordPress năm 2025 (tăng 42% so với 2024), 91% nằm ở plugin, 9% ở theme — và chỉ 6 lỗ hổng nằm ở lõi WordPress.
Đọc lại tỉ lệ đó. Lõi phần mềm gần như không phải vấn đề. Những thứ bạn hoặc đơn vị làm web gắn thêm vào mới là vấn đề.
Và trước khi bạn nghĩ "hosting của em có WAF rồi": cùng báo cáo đó cho biết trong các bài kiểm thử xâm nhập, các lớp phòng thủ phổ biến (WAF của hosting, Cloudflare) chỉ chặn được 26% tổng số đòn tấn công — và với những lỗ hổng đã biết là đang bị khai thác, con số chỉ còn 12%.
Bốn cái đồng hồ
Đây là khung tôi dùng để thiết kế mọi gói bảo trì. Không phải một lịch. Là bốn nhịp song song.
Đồng hồ 1 — Bảo mật & truy cập: chạy theo giờ của kẻ tấn công
Nhịp: ngay khi có bản vá, không chờ lịch. Cộng một lần rà nhanh mỗi tháng.
Đây là nhóm duy nhất không được phép nằm trong lịch cố định. Cụ thể:
- Cập nhật bản vá bảo mật trong 24–48 giờ, không phải "kỳ bảo trì tới". Bật cập nhật tự động cho bản vá bảo mật và xác nhận nó thật sự chạy — bằng số phiên bản, không bằng cảm giác.
- Rà lại danh sách người có quyền truy cập. Còn tài khoản Administrator của agency cũ không? Nhân viên nghỉ ba tháng trước còn đăng nhập được không?
- Kiểm 2FA còn bật cho mọi tài khoản. Việc này mất 5 phút và là 5 phút giá trị nhất trong cả danh sách. Với site trên nền tảng SaaS, con đường bị chiếm phổ biến nhất không phải lỗ hổng code — mà là tài khoản quản trị.
- Đối chiếu script đang chạy trên site với bảng kiểm kê. Xuất hiện một domain lạ nghĩa là có người chèn code mà bạn không biết.
- Kiểm hạn tên miền và khoá chuyển nhượng. Mất tên miền khó phục hồi hơn mất website rất nhiều.
Vì sao nhóm này đứng đầu? Vì dữ liệu của VulnCheck cho thấy trong nửa đầu 2026, 23,43% lỗ hổng đã-biết-bị-khai-thác có bằng chứng bị tấn công vào đúng ngày hoặc trước ngày CVE được công bố (VulnCheck). Với gần một phần tư số ca, bản vá đến sau kẻ tấn công.
Đồng hồ 2 — Những thứ hỏng trong im lặng: hàng tháng
Nhịp: mỗi tháng một lần. Đây mới đúng là phần "hàng tháng".
Đây là nhóm mà tôi cho rằng chứa toàn bộ giá trị thật của một gói bảo trì — và gần như không bao giờ được nhắc tới khi báo giá. Đặc điểm chung: không có ai báo cho bạn khi nó hỏng. Site vẫn chạy, vẫn đẹp, vẫn lên Google. Chỉ có tiền là không về.
Từ nhật ký bảo trì thực tế của chúng tôi, bốn thứ hỏng lặng lẽ nhất:
- Form gửi về hư không. Kết nối từ form sang Mailchimp hoặc Google Sheets tự ngắt sau một thời gian, không báo gì. Cách duy nhất để biết: tự gửi thử một form mỗi tháng từ trình duyệt ẩn danh, và kiểm hộp thư đích — kể cả spam.
- Custom code vỡ âm thầm sau khi nền tảng cập nhật. Không ai được cảnh báo. Trang vẫn tải, chỉ là cái nút không còn bấm được trên mobile.
- Tracking ngừng bắn. GA4, GTM, Meta Pixel ngừng ghi nhận sự kiện. Bạn vẫn mở báo cáo hàng tuần, vẫn thấy biểu đồ — nhưng đang ra quyết định ngân sách trên dữ liệu chết. (Liên quan trực tiếp: hai bản cập nhật Google Analytics tháng 9.)
- Redirect thiếu sau khi đổi đường dẫn. Đổi slug một trang là tạo ra một lỗi 404 ngay lập tức. Nhiều nền tảng không tự tạo redirect. Backlink và thứ hạng của trang đó bốc hơi trong im lặng.
Cộng thêm: kiểm 404 mới trong Search Console, meta title/description cho trang và bài mới, alt text cho ảnh mới upload, ảnh nặng bất thường, hạn licence của các script trả phí.
Đồng hồ 3 — Hiệu năng, backup & SEO kỹ thuật: hàng quý
Nhịp: ba tháng một lần, làm sâu.
Những việc không đáng làm mỗi tháng, nhưng bỏ hẳn thì tích nợ kỹ thuật:
- Restore drill — diễn tập khôi phục. Thử dựng lại site từ bộ backup đang có. Đây là việc bị bỏ qua nhiều nhất và tốn kém nhất khi thiếu. Một bản backup chưa từng được thử khôi phục thì chưa phải backup — nó chỉ là một file bạn hy vọng là đúng.
- Đo Core Web Vitals trên dữ liệu người dùng thật (field data), không phải điểm lab: LCP > 2,5s, INP > 200ms, CLS > 0,1 là ngưỡng phải xử lý.
- Audit sâu tài khoản và nhật ký hoạt động, không chỉ rà nhanh như hàng tháng.
- Đọc lại toàn bộ custom code và plugin bên thứ ba: còn cần không, vendor còn sống không, nền tảng đã có tính năng thay thế chưa. Code thừa là rủi ro vỡ mỗi lần nền tảng cập nhật.
- Rà alt text toàn site, không chỉ ảnh mới trong tháng.
Vì sao hiệu năng xứng đáng một cái đồng hồ riêng chứ không phải mục "nice to have"? Nghiên cứu Milliseconds Make Millions của Google và Deloitte, thực hiện trên 37 thương hiệu và hơn 30 triệu phiên truy cập, cho thấy chỉ 0,1 giây cải thiện tốc độ tải đã mang lại: +8,4% tỷ lệ chuyển đổi và +9,2% giá trị đơn hàng trung bình với bán lẻ; +21,6% số người đi tới bước gửi form với nhóm thu thập khách hàng tiềm năng (web.dev).
Một phần mười giây. Đó là mức chênh mà một lần tối ưu ảnh tử tế có thể tạo ra.
Đồng hồ 4 — Nội dung & chiến lược: hàng năm
Nhịp: một lần mỗi năm, dành hẳn một buổi.
- Audit nội dung và SEO: trang nhiều hiển thị nhưng ít click thì viết lại; trang chết thì gộp hoặc xoá kèm redirect.
- Rà lại trang giới thiệu, thông tin pháp nhân, nhân sự, năm ở footer.
- Tổng rà soát ảnh toàn site: crawl, lọc ảnh nặng, nén, thay, xác minh.
- Đối chiếu giờ thực tế với giờ đã báo giá. Lệch quá 30% thì phải điều chỉnh giá hoặc phạm vi.
Lưu ý một điều quan trọng: nâng cấp lớn hay di trú nền tảng KHÔNG phải việc bảo trì. Đó là một dự án riêng, có phạm vi riêng, báo giá riêng. Ai gộp nó vào gói bảo trì hàng tháng thì hoặc là chưa từng làm, hoặc đang tính thiếu.
Vậy thật sự mất bao nhiêu thời gian?
Đây là phần mà hầu hết bài viết về chủ đề này né tránh. Tôi sẽ đưa số thật, từ nhật ký bảo trì của chính chúng tôi.
Với một site SaaS cỡ vừa (Squarespace/Shopify, không thương mại điện tử phức tạp):
| Chu kỳ | Thời gian thực tế | Ghi chú |
|---|---|---|
| Hàng tháng | 1,5 – 2,5 giờ | Tháng ổn định, không sự cố |
| Hàng tháng (phức tạp) | 3 – 4 giờ | Có bán hàng, nhiều script, nhiều custom code |
| Tháng đầu tiên | Luôn lâu hơn | Phải dựng bảng kiểm kê, chưa có mốc so sánh |
| Hàng quý (cộng thêm) | 2 – 3 giờ | Trong đó restore drill chiếm ~1 giờ |
| Hàng năm (cộng thêm) | 4 – 6 giờ | Audit nội dung chiếm phần lớn |
Với WordPress tự quản, nhân khối lượng hàng tháng lên khoảng 1,5–2 lần — vì bạn gánh thêm phần mà nền tảng SaaS đã lo: cập nhật lõi, plugin, theme, PHP, và giám sát bảo mật chủ động.
Và đây là chi tiết quan trọng nhất về con số đó: nếu cộng đủ mọi đầu việc trong checklist của chúng tôi, tổng thời gian lên tới khoảng 5 giờ. Nhưng thực tế chỉ mất 1,5–2,5 giờ — vì phần lớn là kiểm tra và không phát hiện gì.
Đó chính là bản chất của bảo trì, và là lý do nó khó bán: bạn đang trả tiền cho việc kiểm tra, không phải cho việc sửa. Tháng nào cũng "không có gì" là tháng thành công. Tháng đầu tiên phát hiện form đã chết ba tuần là tháng gói bảo trì tự trả tiền cho chính nó.
Chỗ tôi từng làm sai: nhiều năm trước tôi bán gói bảo trì "1 giờ/tháng" và thấy mình khá hào phóng. Sai — nhưng không phải vì rẻ. Sai vì tôi gộp việc kiểm tra bảo mật chung nhịp với việc đổi ảnh banner. Khi một lỗ hổng nghiêm trọng xuất hiện giữa hai kỳ, hợp đồng của tôi không có chỗ nào cho phép xử lý ngay. Bây giờ điều khoản bảo mật luôn nằm ngoài lịch: có bản vá là làm, tính riêng.
Ba câu hỏi để chấm gói bảo trì bạn đang mua
Không cần hiểu kỹ thuật. Chỉ cần hỏi ba câu và nghe cách người ta trả lời:
- "Nếu tuần sau có lỗ hổng nghiêm trọng, các anh xử lý trong bao lâu?" — Câu trả lời đúng là một khoảng thời gian (24 giờ, 48 giờ). Câu trả lời sai là "kỳ bảo trì tới".
- "Lần gần nhất các anh thử khôi phục site tôi từ backup là khi nào?" — Nếu chưa từng, thì bạn đang trả tiền cho một file, không phải một bản backup.
- "Tháng trước các anh phát hiện ra điều gì?" — Một báo cáo bảo trì tốt luôn có mục đã phát hiện gì và còn tồn gì. Nếu tháng nào cũng chỉ có "đã cập nhật, đã sao lưu, mọi thứ bình thường", thì rất có thể không ai thực sự nhìn.
Cái giá của việc làm sai nhịp
Hãy quy về tiền, vì đó mới là thứ đáng bàn.
Một website bị chiếm quyền không chỉ mất mấy ngày khôi phục. Nó mất thứ hạng đã xây nhiều năm, mất lòng tin của khách đang trong giỏ hàng, và có thể kéo theo trách nhiệm pháp lý nếu dữ liệu khách hàng rò rỉ.
Một form chết ba tuần mà không ai biết là ba tuần khách hàng tiềm năng gõ cửa và không ai mở. Đây là thiệt hại tôi gặp thường xuyên hơn cả bị hack — và nó không bao giờ hiện lên trên bất kỳ cảnh báo nào.
Một trang chậm hơn 0,1 giây là bao nhiêu phần trăm doanh thu? Google và Deloitte đã trả lời ở trên rồi.
Bảo trì không phải là chi phí giữ cho website "không sập". Nó là chi phí giữ cho website tiếp tục làm việc bạn đã trả tiền để nó làm. Site sập thì bạn biết ngay trong mười phút. Site vẫn chạy nhưng đã ngừng tạo ra khách hàng — đó mới là thứ âm thầm tốn tiền nhất, và đó chính là thứ bảo trì đúng nhịp phát hiện ra.
Nếu bạn nhớ đúng một câu từ bài này, hãy nhớ câu này: đừng hỏi "bao lâu bảo trì một lần". Hãy hỏi "việc này chạy theo nhịp của ai". Bảo mật chạy theo giờ của kẻ tấn công. Tích hợp chạy theo tháng. Hiệu năng chạy theo quý. Nội dung chạy theo năm.
Ép cả bốn vào một lịch duy nhất là cách chắc chắn nhất để vừa tốn tiền, vừa không an toàn.
Muốn biết website của bạn đang hở ở cái đồng hồ nào? Gửi cho chúng tôi địa chỉ site — chúng tôi rà miễn phí phần thấy được từ bên ngoài và nói thẳng bạn đang thiếu gì. Nếu vấn đề nằm ở tốc độ và thứ hạng, xem thêm dịch vụ SEO & tối ưu hiệu suất.
