n8n + WordPress API: tự động publish bài đã duyệt từ NocoDB và ghi log lỗi về Telegram

Tiếp nối blueprint duyệt nội dung AI bằng NocoDB và n8n: bước này biến bản ghi đã duyệt thành bài WordPress publish thật, có log lỗi để vận hành.

Nhiều đội marketing đã bắt đầu dùng AI để viết nháp, dùng NocoDB để duyệt nội dung và dùng n8n để nối dữ liệu giữa các công cụ. Nhưng nếu quy trình dừng ở bước “đã duyệt” thì vẫn còn một khoảng trống vận hành: ai sẽ copy bài sang WordPress, upload ảnh, đặt category, gắn tag, kiểm tra lỗi và báo cho đội phụ trách?

Bài viết này hướng dẫn một blueprint thực chiến để tự động publish bài đã duyệt từ NocoDB lên WordPress bằng n8n và WordPress REST API, đồng thời ghi log lỗi về Telegram. Mục tiêu không phải là “đăng càng nhiều càng tốt”, mà là xây một đường ống xuất bản có kiểm soát: chỉ bài đủ điều kiện mới được publish, lỗi nào cũng có log, và đội content biết chính xác bài nào đã lên site.

1. Khi nào nên tự động publish từ NocoDB sang WordPress?

Automation publish WordPress phù hợp khi bạn đã có quy trình duyệt nội dung rõ ràng. Ví dụ: AI tạo bản nháp, editor sửa lại, người phụ trách SEO kiểm tra tiêu đề/meta/ảnh, sau đó đổi trạng thái trong NocoDB thành approved. Lúc này n8n có thể lấy bản ghi đó và đăng lên WordPress mà không cần thao tác thủ công.

Không nên tự động publish nếu bài chưa có bước kiểm duyệt. Với blog doanh nghiệp, đặc biệt là các chủ đề liên quan Smax.AI, n8n, chatbot, Facebook Ads, CAPI, NocoDB hay quy trình bán hàng, nội dung sai hoặc quá khẳng định có thể gây hiểu nhầm cho khách hàng. Vì vậy, hãy xem automation là người vận hành cuối cùng, không phải người thay thế biên tập.

Một kịch bản hợp lý gồm bốn tầng: dữ liệu bài viết nằm trong NocoDB, logic kiểm tra nằm trong n8n, nội dung xuất bản nằm ở WordPress, còn cảnh báo vận hành đi qua Telegram hoặc email nội bộ. Nếu doanh nghiệp đã dùng Smax.AI để gom lead từ Messenger, website, Zalo hoặc landing page, cùng một tư duy này cũng có thể áp dụng cho content ops: mọi bản ghi đều có trạng thái, người phụ trách và lịch sử xử lý.

2. Thiết kế bảng NocoDB cho bài chờ publish

Trước khi mở n8n, hãy chuẩn hoá bảng dữ liệu. Một bảng đơn giản có thể tên là content_queue hoặc blog_posts. Các cột quan trọng gồm: title, slug, excerpt, content_html, category, tags, featured_image_url, inline_image_urls, status, approved_by, approved_at, publish_at, wp_post_id, wp_url, last_error, retry_count và published_at.

Trạng thái nên được định nghĩa rõ. Ví dụ: draft, reviewing, approved, publishing, published, failed. n8n chỉ xử lý bản ghi có status = approved và chưa có wp_post_id. Sau khi bắt đầu chạy, workflow đổi status thành publishing để tránh một bản ghi bị nhiều lần xử lý. Khi WordPress trả về post ID, n8n cập nhật status thành published. Nếu lỗi xảy ra, status chuyển thành failed và last_error lưu thông tin ngắn gọn để đội vận hành biết cần sửa gì.

Với ảnh, có hai hướng. Cách đơn giản là lưu sẵn URL ảnh nội bộ hoặc URL media đã upload. Cách tốt hơn cho quy trình chuyên nghiệp là lưu file/URL nguồn, để n8n tải về rồi upload vào WordPress Media Library. Không nên chèn trực tiếp URL tạm từ công cụ tạo ảnh vào bài, vì URL đó có thể hết hạn hoặc không thuộc tài sản media của website.

3. Workflow n8n nên chia thành các bước nhỏ

Một workflow dễ bảo trì thường không gom tất cả vào một node. Hãy chia thành các đoạn rõ ràng: trigger, fetch record, validate dữ liệu, upload ảnh, tạo bài WordPress, cập nhật NocoDB, gửi thông báo. Cách chia này giúp bạn nhìn lỗi nhanh hơn và dễ thay đổi từng phần khi cấu trúc dữ liệu thay đổi.

Trigger

Bạn có thể dùng Cron node chạy mỗi 5-15 phút, hoặc Webhook node nếu NocoDB/ứng dụng duyệt nội dung có thể gọi webhook khi status đổi sang approved. Với đội nhỏ, cron là lựa chọn đơn giản vì ít phụ thuộc vào webhook. Điều kiện lọc nên giới hạn số lượng bản ghi mỗi lần chạy để tránh publish hàng loạt ngoài ý muốn.

Validate dữ liệu

Trước khi gọi WordPress API, workflow nên kiểm tra các trường tối thiểu: tiêu đề không rỗng, slug hợp lệ, content_html có nội dung, category tồn tại, ảnh đại diện đã có hoặc có thể upload, tag không quá nhiều, và bài chưa từng có wp_post_id. Nếu thiếu dữ liệu, đừng cố publish. Hãy cập nhật status failed kèm lý do rõ ràng.

Upload ảnh

WordPress REST API cho phép upload ảnh qua endpoint media. n8n cần gửi Basic Auth hoặc Application Password, đặt header Content-Disposition, Content-Type và body là binary file. Sau khi upload thành công, API trả về media ID và source_url. Featured image dùng media ID; ảnh minh hoạ trong nội dung dùng source_url và alt text phù hợp keyword.

Tạo bài

Khi tạo post, payload cơ bản gồm title, slug, content, excerpt, status, categories, tags và featured_media. Với quy trình có duyệt, status có thể là publish nếu người duyệt đã xác nhận. Nếu đội muốn kiểm tra lần cuối trong WordPress, status nên là draft hoặc future. Trong bài này, chúng ta đang nói về quy trình đã duyệt nên publish là hợp lý.

4. WordPress REST API: những điểm dễ sai

Lỗi phổ biến nhất là nhầm giữa tên category/tag và ID. WordPress thường yêu cầu categories và tags là mảng ID, không phải chuỗi tên. Vì vậy workflow nên có bước lấy danh sách category/tag hiện có, map tên sang ID, rồi mới tạo post. Nếu cần tạo tag mới, chỉ tạo khi thực sự cần và tránh sinh quá nhiều tag trùng nghĩa.

Lỗi thứ hai là HTML không sạch. Nếu nội dung đến từ AI hoặc nhiều nguồn khác nhau, hãy thống nhất format trước khi publish: H2/H3 rõ ràng, đoạn văn ngắn, figure cho ảnh, alt text tiếng Việt, CTA cuối bài. Không nên đẩy thẳng Markdown vào WordPress nếu theme không xử lý tốt. Hãy chuyển sang HTML hợp lệ trong bước chuẩn hoá.

Lỗi thứ ba là retry không kiểm soát. Nếu node tạo bài timeout nhưng WordPress vẫn đã tạo post, lần retry có thể tạo bài trùng. Để giảm rủi ro, hãy dùng slug cố định, kiểm tra slug trước khi tạo, và sau lỗi timeout hãy gọi GET posts?slug=… để xem bài đã tồn tại chưa. Nếu tồn tại, cập nhật lại NocoDB bằng post ID thay vì tạo bài mới.

5. Ghi log lỗi về Telegram như thế nào?

Telegram không chỉ dùng để báo “xong rồi”. Giá trị lớn hơn là giúp đội vận hành biết lỗi nào cần can thiệp. Một thông báo tốt nên có: tên workflow, môi trường, record ID trong NocoDB, tiêu đề bài, bước lỗi, thông điệp lỗi rút gọn, retry_count và link mở bản ghi.

Ví dụ, nếu lỗi upload ảnh do file quá lớn, Telegram nên ghi rõ “Media upload failed” thay vì chỉ báo “workflow failed”. Nếu lỗi do category không tồn tại, thông báo nên gợi ý kiểm tra mapping category. Nếu lỗi do WordPress auth, cần báo khẩn hơn vì toàn bộ pipeline có thể dừng.

Với bài publish thành công, thông báo nên ngắn: tiêu đề, URL, category/tag, người duyệt, thời gian publish. Nếu kết hợp với Smax.AI hoặc chatbot nội bộ, đội sales/marketing có thể nhận link bài mới để tái sử dụng trong kịch bản tư vấn, broadcast, follow-up hoặc thư viện nội dung trả lời khách.

6. Blueprint dữ liệu: từ content ops sang sales automation

Điểm thú vị của NocoDB là cùng một nền tảng có thể lưu nhiều loại dữ liệu: bài viết, lead, hội thoại, task sales, log thanh toán, log workflow. Khi blog đã publish, URL bài viết có thể quay lại làm tài sản cho automation bán hàng. Ví dụ, khách hỏi về NocoDB mini CRM thì chatbot gửi bài hướng dẫn phù hợp; khách quan tâm WordPress automation thì sales gửi bài blueprint này; lead đến từ Facebook Ads có thể được gắn nguồn nội dung đã đọc.

Trong mô hình đa kênh, WordPress không đứng một mình. Bài blog có thể kéo lead về Messenger, Zalo, form Ladipage, Webcake, WooCommerce hoặc livechat website. Sau đó Smax.AI, n8n và NocoDB tiếp tục phân loại, giao task, nhắc Follow Up, hoặc gửi tín hiệu đo lường về Meta Dataset/CAPI nếu doanh nghiệp có triển khai tracking nâng cao.

Vì vậy, đừng xem workflow publish bài là một tiện ích nhỏ. Nó là một phần của hệ thống nội dung – lead – sales. Khi dữ liệu publish sạch, URL rõ ràng và log đầy đủ, đội marketing có thể đo nội dung nào thường được dùng trong tư vấn, nội dung nào cần cập nhật, và nội dung nào nên chuyển thành kịch bản chatbot.

7. Checklist triển khai nhanh

• Tạo bảng NocoDB lưu title, slug, content_html, excerpt, category, tags, ảnh, status và log.
• Chỉ cho phép n8n xử lý bản ghi status = approved và chưa có wp_post_id.
• Đổi status sang publishing trước khi gọi WordPress để tránh xử lý trùng.
• Kiểm tra slug đã tồn tại trên WordPress trước khi tạo bài.
• Upload ảnh vào WordPress Media Library, không chèn URL tạm.
• Map category/tag sang ID trước khi POST bài.
• Lưu wp_post_id, wp_url, published_at về NocoDB sau khi thành công.
• Gửi Telegram khi publish thành công hoặc khi lỗi cần người xử lý.
• Thiết kế retry có giới hạn và có log last_error rõ ràng.
• Định kỳ rà soát bài đã publish để cập nhật nội dung cũ.

8. Sai lầm thường gặp khi tự động publish WordPress

Sai lầm 1: bỏ qua bước duyệt. AI có thể viết nhanh, nhưng bài doanh nghiệp cần đúng ngữ cảnh, đúng cam kết và đúng thông điệp. Hãy dùng NocoDB như lớp phê duyệt trước khi publish.

Sai lầm 2: không lưu log. Nếu chỉ nhìn trạng thái workflow trong n8n, đội content có thể không biết bản ghi nào lỗi. Log nên quay lại NocoDB và gửi cảnh báo Telegram.

Sai lầm 3: tạo tag quá nhiều. Tag sinh tự động dễ làm website rối. Hãy giới hạn 3-7 tag chính, ưu tiên các nhóm có giá trị SEO và vận hành như n8n, WordPress, NocoDB, Automation, Smax.AI.

Sai lầm 4: không kiểm tra trùng slug. Đây là nguyên nhân phổ biến khiến website có nhiều bài gần giống nhau. Luôn kiểm tra slug trước khi tạo bài và lưu post ID sau khi tạo.

Sai lầm 5: coi publish là điểm kết thúc. Sau khi bài lên site, URL nên được đưa vào thư viện nội dung, chatbot, kịch bản follow-up và dashboard đo hiệu quả.

FAQ

Có nên để n8n publish thẳng bài AI viết không?

Không nên nếu chưa có bước duyệt. Cách an toàn hơn là để AI tạo bản nháp, con người duyệt trong NocoDB, rồi n8n chỉ publish bản ghi đã approved.

Nên dùng status publish hay draft khi gọi WordPress API?

Nếu quy trình duyệt đã hoàn tất, có thể dùng publish. Nếu đội vẫn muốn kiểm tra trong WordPress, hãy dùng draft hoặc future. Điều quan trọng là trạng thái phải phản ánh đúng quy trình nội bộ.

Nếu WordPress API timeout thì làm sao tránh bài trùng?

Hãy dùng slug cố định và sau lỗi timeout gọi lại WordPress để kiểm tra bài theo slug. Nếu bài đã tồn tại, cập nhật post ID về NocoDB thay vì tạo bài mới.

NocoDB có thay Google Sheets trong quy trình này không?

Với quy trình nhỏ, Google Sheets vẫn dùng được. Khi cần phân quyền, trạng thái rõ ràng, nhiều bảng liên kết, log lỗi và mini CRM nội bộ, NocoDB thường phù hợp hơn.

Có thể dùng blueprint này cho WooCommerce hoặc landing page không?

Có. Tư duy tương tự áp dụng cho nhiều hệ thống: bản ghi đã duyệt trong NocoDB, n8n kiểm tra điều kiện, gọi API đích, ghi log và gửi cảnh báo khi có lỗi.

Kết luận

Tự động publish WordPress bằng n8n và NocoDB không chỉ giúp tiết kiệm thao tác copy-paste. Giá trị lớn hơn là tạo một pipeline nội dung có kiểm soát: bài nào được duyệt, bài nào đã đăng, lỗi ở đâu, ai cần xử lý và URL nào có thể tái sử dụng cho chatbot, sales và CSKH.

Nếu bạn đang xây hệ thống Smax.AI + n8n + NocoDB cho marketing/sales automation, hãy bắt đầu từ một workflow nhỏ: lấy một bài approved, upload ảnh, tạo post, cập nhật log và gửi Telegram. Khi bước này ổn định, bạn có thể mở rộng sang dashboard content ops, phân phối nội dung đa kênh và đo hiệu quả nội dung trong phễu bán hàng.

Nếu bạn muốn triển khai hệ thống automation tương tự cho doanh nghiệp, hãy liên hệ Quân Chatbot để được tư vấn giải pháp phù hợp.