Quản lý nội dung SEO cho nhiều website khách: quy trình cho agency

Quản lý nội dung SEO cho nhiều website khách thế nào để không rối? Tách riêng từng khách: mỗi khách một kho tài liệu, một hồ sơ giọng văn và danh sách từ cấm. Lập lịch theo cụm chủ đề cho từng site, chia rõ ai soạn, ai duyệt nội bộ, ai bên khách duyệt. Dùng tài khoản WordPress quyền thấp nhất đủ dùng, ghi nhật ký mọi thay đổi, và làm báo cáo tháng theo quy tắc trung thực đặt trước.

Bài này dành cho agency SEO, marketing đang chăm 5 đến 30 website WordPress của khách: những chỗ thường vỡ khi số site tăng, quy trình đề xuất, bảng phân vai và bảng "điểm vỡ, cách chặn" để dùng ngay.

Với 2–3 khách, một người có thể nhớ hết. Khi số site tăng lên, lỗi dễ nằm ở chỗ nối giữa các bước hơn là ở chất lượng từng bài.

Những chỗ vỡ khi agency tăng số website

Khi số website tăng, sáu điểm sau thường vỡ trước:

• Tài liệu khách nằm rải rác. Bảng giá ở Zalo, hồ sơ năng lực trong email, chính sách trong file Drive cũ. Lấy nhầm bản là bài nói sai giá.
• Giọng văn lẫn giữa các khách. Viết xong cho công ty luật chuyển sang khách cơ khí, câu chữ mang theo giọng khách trước; từ khách này cấm lại lọt sang bài khách kia.
• Bài trùng ý định trong cùng site. "Giá dịch vụ X" và "Chi phí dịch vụ X" khác tên nhưng cùng trả lời một câu hỏi, tự giành chỗ của nhau trên Google.
• Quyền đăng WordPress lộn xộn. Cả đội dùng chung tài khoản quản trị của khách; có sự cố thì không biết ai đã sửa gì.
• Khách duyệt chậm. Bài chờ hai, ba tuần vì không rõ ai bên khách có quyền nói "được".
• Báo cáo tháng tốn công. Cuối tháng, một người mất vài ngày gom số từ Search Console, GA4, tin nhắn khách cho từng site.

Gốc chung: thông tin của từng khách không có chỗ ở cố định, và quyết định không có người chịu trách nhiệm rõ.

Mỗi khách một kho tài liệu, một hồ sơ giọng văn, một danh sách từ cấm

Gom tài liệu của mỗi khách vào một kho riêng, tách hẳn khỏi khách khác. Kho nên có tối thiểu: trang dịch vụ, hồ sơ năng lực, bảng giá kèm ngày hiệu lực, chính sách bảo hành, đổi trả, và danh sách câu hỏi khách hay hỏi.

Đi kèm kho là hồ sơ giọng văn một trang: xưng hô với người đọc, mức trang trọng, độ dài câu, vài đoạn mẫu khách đã duyệt. Ví dụ (giả định) cho một công ty luật: xưng "quý doanh nghiệp", câu dưới 25 chữ, không dùng câu cảm thán, mỗi điều luật nhắc tới phải ghi số điều và văn bản. Thêm danh sách từ cấm: từ khách không muốn dùng, cam kết không được hứa, tên đối thủ không được nhắc. Với ngành có quy định quảng cáo riêng như y tế, danh sách này nên bám theo quy định đó.

Quy tắc quan trọng nhất: điều gì kho không có thì bài không tự điền. Thiếu giá, thiếu thời hạn bảo hành thì bài mời khách liên hệ hỏi, không đoán. Lỗi "bài nói sai về doanh nghiệp" hay bắt đầu từ chỗ người soạn hoặc AI tự lấp chỗ trống. Bài AI bịa thông tin: nhận biết và chặn trước khi đăng nói kỹ hơn về cơ chế này.

Trong XD DashWP, đây là cách tổ chức mặc định: mỗi khách của agency có một kho tài liệu và một báo cáo tháng riêng, AI soạn nháp chỉ từ kho của đúng khách đó, theo giọng văn và từ cấm trong hồ sơ thương hiệu. Không dùng phần mềm, đội vẫn làm được bằng một thư mục riêng cho mỗi khách, miễn là giữ kỷ luật "không có trong kho thì không viết".

Lập lịch nội dung theo cụm chủ đề cho từng site

Lịch nội dung nên lập theo cụm: một bài trụ cột và các bài nhánh trả lời từng câu hỏi hẹp hơn, nối với nhau bằng liên kết nội bộ. Người duyệt bên khách đọc một lần cả cụm thay vì từng bài rời.

Trước khi giao một chủ đề, người lập lịch kiểm hai việc:

1. Site đã có bài nào trả lời cùng câu hỏi chưa. Nếu có, cập nhật bài cũ thay vì viết bài mới.
2. Hai chủ đề trong cùng lịch có cùng ý định tìm kiếm không. Cách kiểm nhanh: tìm cả hai cụm từ trên Google, nếu kết quả trang đầu gần như giống nhau thì gộp lại.

Site lớn cần sắp lại chuyên mục thì có thể dựng sơ đồ silo trước, ví dụ bằng XD Silo Commander, rồi mới xếp cụm vào lịch. Số cụm chạy song song nên vừa sức đọc của người duyệt bên khách, ví dụ (giả định) một đến hai cụm mỗi tháng cho mỗi site, rồi chỉnh theo số bài khách đọc kịp trong thực tế.

Phân vai: người soạn, người duyệt nội bộ, khách duyệt

Khi có AI soạn nháp, vai người duyệt càng quan trọng; bài Viết bài SEO bằng AI giải thích vì sao nên để AI soạn từ tài liệu và để người quyết định bài nào được đăng. Ở cấp agency, mỗi việc cần một người chịu trách nhiệm cuối.

Bảng RACI đơn giản (R: làm, A: chịu trách nhiệm cuối, C: được hỏi ý kiến, I: được báo):

Việc	Người soạn	Người duyệt nội bộ	Khách duyệt	Trưởng nhóm tài khoản
Cập nhật kho tài liệu	R	C	C (cung cấp tài liệu)	A
Lập lịch cụm chủ đề	C	R	C	A
Soạn bài (người hoặc AI soạn nháp)	R, A	I	–	I
Kiểm dữ kiện, từ cấm, liên kết	C	R, A	–	I
Duyệt nội dung về doanh nghiệp	I	C	R, A	I
Đăng lên WordPress	–	R	I	A
Báo cáo tháng	–	R	I	A

Hai điểm nên chốt với khách ngay từ hợp đồng: ai bên khách có quyền duyệt (một người, có tên), và hạn duyệt (ví dụ 5 ngày làm việc, giả định). Quá hạn thì agency nhắc người duyệt, rồi báo lên người phụ trách bên khách theo lịch đã thống nhất trong hợp đồng. Bài chưa được duyệt thì giữ lại, dời lịch đăng, không đăng. Nguyên tắc nên ghi rõ: không bài nào lên khi người duyệt chưa đồng ý.

Người duyệt nội bộ nên có một danh sách kiểm cố định cho mọi khách. Bài Checklist kiểm tra bài AI trước khi đăng có thể dùng làm điểm xuất phát.

Quản lý nhiều website WordPress với quyền tối thiểu

Nguyên tắc là mỗi người, mỗi công cụ chỉ có đúng quyền cần cho việc của mình. Theo tài liệu vai trò và quyền của WordPress, vai Cộng tác viên (Contributor) viết và quản lý bài của mình nhưng không đăng được; vai Tác giả (Author) đăng và quản lý bài của chính mình, có thêm quyền tải tệp lên; vai Biên tập viên (Editor) đăng và quản lý cả bài của người khác. Làm nội dung hiếm khi cần quyền Quản trị.

Vai Tác giả thường hợp hơn vì cần tải ảnh lên. Nhưng Tác giả tự đăng được, nên quy trình hoặc công cụ đăng nên gửi bài ở trạng thái chờ duyệt (pending), để chủ website là người bấm đăng.

Với công cụ kết nối qua REST API, WordPress có mật khẩu ứng dụng (Application Passwords), có sẵn từ bản 5.6 (WordPress REST API Handbook). Theo hướng dẫn tích hợp của WordPress core, 2020, mỗi mật khẩu xem và thu hồi được riêng trong trang sửa người dùng, và chỉ dùng được khi site chạy HTTPS (trừ khi được cấu hình khác). Ở thời điểm hướng dẫn đó, việc giới hạn phạm vi quyền cho từng mật khẩu còn được nêu là hướng phát triển sau; anh chị nên kiểm lại phiên bản WordPress đang dùng. Vì vậy:

• Tạo mật khẩu ứng dụng trên tài khoản quyền thấp, không trên tài khoản quản trị.
• Mỗi công cụ, mỗi người một mật khẩu riêng, đặt tên dễ nhận ra.
• Khi nhân sự nghỉ hoặc hết hợp đồng, thu hồi đúng mật khẩu đó, không phải đổi mật khẩu chính của khách.

Nhật ký thay đổi cho từng site

Mỗi website một bảng: ngày, người làm, việc đã làm (đăng bài, sửa tiêu đề, đổi đường dẫn, thêm chuyển hướng), lý do. Khi số liệu một trang tụt, anh chị mở nhật ký trước khi đoán nguyên nhân.

Nên ghi cả những sự kiện không do agency làm: khách đổi giao diện, chuyển hosting, làm lại website. Nếu không, biến động do Google đọc lại site dễ bị nhầm là kết quả của bài mới.

Báo cáo SEO hàng tháng cho khách: số liệu và quy tắc trung thực

Báo cáo tháng nên trả lời ba câu: Google thấy website thế nào, bài mới đã được ghi nhận chưa, có khách thật liên hệ không. Nguồn số thường gồm Google Search Console (lượt hiển thị, lượt bấm, truy vấn), GA4 (hành vi trên trang) và bộ đếm lượt bấm gọi, nhắn Zalo trên bài.

Báo cáo đáng tin khi quy tắc đọc số được chốt trước, áp dụng như nhau cho mọi khách:

• Tháng chưa hết: so với đúng chừng ấy ngày của tháng trước, không ghi phần trăm.
• Số nhỏ: ghi số tuyệt đối. Từ 2 lên 4 lượt gọi (giả định) ghi là "2 lên 4", không ghi "tăng 100%".
• Website mới làm lại: ghi rõ ngày làm lại, để không nhận phần biến động đó là công của bài mới.
• Nhóm đối chứng: so bài mới với các trang có sẵn trên cùng site trong cùng khoảng ngày, vì cùng chịu chung các đợt cập nhật của Google.
• Chưa đủ số liệu thì nói chưa đủ, không viết nhận xét thay cho số.

Báo cáo tháng của XD DashWP theo đúng các quy tắc này: mỗi website một báo cáo, xuất PDF hoặc trang web để gửi khách, tiêu đề mỗi trang do app tính từ số liệu chứ AI không tự viết số. Nếu tự làm bằng bảng tính, có thể dùng một mẫu sáu phần: tóm tắt, Google thấy website thế nào, khách tìm gì, bài nào mang khách, đã làm và sắp làm, cách đọc số liệu.

Bảng điểm vỡ và cách chặn

Điểm vỡ	Dấu hiệu	Cách chặn
Tài liệu khách rải rác	Bài nói giá cũ, chính sách cũ	Mỗi khách một kho, bảng giá ghi ngày hiệu lực
Giọng văn lẫn	Khách sửa câu chữ nhiều ở mọi bài	Hồ sơ giọng văn một trang, đoạn mẫu đã duyệt
Từ cấm lọt	Bài có cam kết khách không cho hứa	Danh sách từ cấm riêng, kiểm trước khi duyệt
Bài trùng ý định	Hai trang cùng site thay nhau lên xuống	Kiểm bài có sẵn và trang kết quả trước khi giao
Quyền đăng lộn xộn	Không biết ai sửa gì	Tài khoản riêng quyền thấp, mật khẩu ứng dụng riêng
Khách duyệt chậm	Lịch trượt nhiều tuần	Một người duyệt có tên, hạn duyệt và lịch nhắc ghi trong hợp đồng; bài chưa duyệt thì chưa đăng
Báo cáo tốn công	Cuối tháng mất vài ngày gom số	Một mẫu chung, quy tắc đọc số chốt trước
Báo cáo thổi phồng	Phần trăm lớn trên số rất nhỏ	Số nhỏ ghi tuyệt đối, tháng chưa hết không ghi %

Không cần sửa cả tám điểm cùng lúc: chọn hai điểm tốn công nhất, chạy một tháng, rồi thêm điểm tiếp.

Câu hỏi thường gặp

Có nên dùng chung một tài khoản WordPress cho cả đội không?

Không nên. Tài khoản chung làm mất dấu ai làm gì và khó thu hồi khi có người nghỉ. Mỗi người, mỗi công cụ nên có tài khoản hoặc mật khẩu ứng dụng riêng.

Khách không gửi đủ tài liệu thì sao?

Bắt đầu với các chủ đề kho đã đủ nguồn, và gửi khách danh sách tài liệu còn thiếu kèm chủ đề đang chờ. Bài không tự điền giá hay chính sách khi chưa có nguồn.

Báo cáo tháng nên gửi vào ngày nào?

Nên gửi vài ngày sau khi tháng kết thúc, để số liệu những ngày cuối tháng kịp cập nhật. Nếu khách cần báo cáo giữa tháng, ghi rõ số chưa đủ tháng và chỉ so với cùng số ngày của tháng trước.