Tự động đăng bài lên WordPress bằng n8n qua REST API

Bạn đang cần kiểm tra một việc rất cụ thể: n8n có gửi được một bài viết tới WordPress hay không. Bài này hướng dẫn tự động đăng bài lên wordpress bằng một lượt thử gồm ba node, tạo bài nháp hoặc bài xuất bản, đọc phản hồi rồi mới quyết định có thêm lịch chạy, AI và các bước xử lý khác.

Tự động đăng bài lên WordPress bằng n8n: tách lượt kiểm tra kết nối khỏi quy trình chạy lịch

Đừng bắt đầu bằng một quy trình dài có AI, lịch chạy, tạo nội dung, kiểm tra trùng lặp và thông báo lỗi. Nếu lượt gửi cơ bản chưa hoạt động, bạn sẽ không biết lỗi nằm ở tài khoản WordPress, địa chỉ REST API, dữ liệu bài viết hay node lịch. Việc cần làm ngay là tạo một bài thử bằng tay trong n8n, với tiêu đề và nội dung cố định, rồi gửi nó tới WordPress bằng một yêu cầu POST.

Lượt thử này không phải hệ thống tu dong dang bai wordpress hoàn chỉnh. Nó chỉ trả lời một câu hỏi: tài khoản đã cấp quyền có thể tạo bài qua n8n WordPress REST API hay chưa? Chọn trạng thái draft trong lần đầu để bài không xuất hiện công khai. Khi đã nhìn thấy bài trong khu vực quản trị WordPress, bạn mới đổi sang publish, thêm lịch chạy hoặc đưa dữ liệu từ AI vào. Cách tách từng lớp như vậy cũng giúp bạn khoanh vùng lỗi thay vì sửa nhiều node cùng lúc.

Chuẩn bị site, tài khoản và Application Password trước khi mở n8n

Trong WordPress, mở hồ sơ của tài khoản sẽ dùng để đăng bài và tìm phần Application Passwords. Tạo một mật khẩu riêng với tên dễ nhận biết, chẳng hạn n8n-test. WordPress chỉ hiển thị chuỗi này đầy đủ lúc tạo; hãy sao chép ngay và lưu ở nơi an toàn. Đây không phải mật khẩu đăng nhập thông thường. Nếu không còn chuỗi, bạn có thể thu hồi mật khẩu ứng dụng cũ và tạo chuỗi khác. Không đặt nó vào nội dung bài, tên workflow hoặc ảnh chụp màn hình công khai.

Ghi lại địa chỉ website gốc, không nhầm với địa chỉ trang quản trị. Tuyến thường dùng để tạo bài là https://ten-mien-cua-ban/wp-json/wp/v2/posts; tài liệu WordPress REST API gọi đây là endpoint posts. Hãy mở tuyến này trên trình duyệt để xem site có trả về dữ liệu JSON hay không, nhưng đừng dùng kết quả đó thay cho bài kiểm tra xác thực. Kiểm tra thanh địa chỉ có HTTPS trước khi nhập Application Password WordPress n8n vào credential. Tài liệu WordPress nói Application Password được thiết kế cho kết nối qua HTTPS; một số môi trường phát triển cục bộ có ngoại lệ, còn hosting thật có thể chặn hoặc xử lý khác tùy cấu hình. Site chỉ chạy HTTP thì nên xử lý chứng chỉ trước khi đi tiếp: gửi Application Password qua kết nối không mã hoá là gửi một khoá dùng lại được qua đường ai cũng đọc được. Bản chạy trên máy trong bài này là ngoại lệ có ý thức — nó không ra Internet.

Dựng workflow n8n đăng bài WordPress gồm Manual Trigger, Set và HTTP Request

Tạo một workflow mới trong n8n và thêm Manual Trigger. Node này chỉ cho phép bạn bấm chạy bằng tay, phù hợp với lượt thử và không tạo lịch ngoài ý muốn. Thêm node Set, hoặc node có tên Edit Fields ở phiên bản n8n mới hơn nếu giao diện của bạn dùng tên đó. Nối Manual Trigger với node này, rồi nối tiếp sang HTTP Request. Đây là workflow n8n đăng bài WordPress tối giản: một node khởi chạy, một node chứa dữ liệu, một node gửi yêu cầu.

Trong node Set hoặc Edit Fields, tạo đúng ba trường: title, content và status. Cho title một câu dễ nhận ra như Bài kiểm tra n8n WordPress; cho content một đoạn ngắn có thời điểm hoặc dấu hiệu riêng để bạn tìm lại trong wp-admin. Trường status đặt là draft ở lần đầu. WordPress REST API hỗ trợ các trạng thái bài viết phù hợp với quyền của tài khoản; publish có thể không được chấp nhận nếu tài khoản không có quyền xuất bản. Đừng lấy nội dung từ AI trong bước này, vì mục tiêu là kiểm tra dữ liệu cố định có đi hết quy trình hay không.

Chạy riêng node Set sau khi nối xong để xem nó tạo ra một item chứa cả ba trường. Tên trường phải nhất quán với phần body bạn sẽ cấu hình ở node HTTP Request; Title, post_title và title không tự động được xem là một. Nếu giao diện n8n hiển thị dữ liệu đầu vào dưới dạng JSON, kiểm tra lại ba khóa này trước khi đi tiếp. Một lượt thử tốt phải có dữ liệu đủ để gửi, nhưng càng ít trường càng dễ đọc lỗi. Chưa cần thêm danh mục, ảnh đại diện, thẻ, slug hay trường tùy chỉnh.

Cấu hình HTTP Request để n8n đăng bài tự động bằng POST tới REST API

Mở node HTTP Request. Chọn phương thức POST, nhập URL endpoint posts của site, chẳng hạn https://ten-mien-cua-ban/wp-json/wp/v2/posts, rồi kiểm tra lại dấu gạch chéo và tên miền. Đừng gửi tới /wp-admin/post-new.php; đó là trang giao diện quản trị, không phải tuyến REST để nhận dữ liệu. Tài liệu WordPress REST API mô tả thao tác tạo bài bằng yêu cầu POST tới tài nguyên posts. Nếu website nằm trong thư mục con, đường dẫn wp-json cũng phải phản ánh đúng vị trí cài đặt thực tế.

Ở phần xác thực, tạo hoặc chọn Basic Auth credential trong n8n. Username là tên đăng nhập WordPress của tài khoản, còn password là Application Password vừa tạo; khi nhập, có thể bỏ khoảng trắng được hiển thị giữa các nhóm ký tự của mật khẩu ứng dụng nếu WordPress đã thêm chúng để dễ đọc. n8n sẽ dùng credential này để gửi thông tin xác thực, vì vậy không gõ trực tiếp mật khẩu vào biểu thức hoặc trường body. Nếu n8n báo lỗi xác thực, kiểm tra lại tên người dùng, chuỗi Application Password, HTTPS và plugin bảo mật hoặc máy chủ trung gian đang chặn Basic Auth. Chưa thể kết luận lỗi nằm ở WordPress nếu chưa xem phần chi tiết phản hồi.

Bật phần gửi body của HTTP Request và chọn định dạng JSON, không gửi dữ liệu biểu mẫu nếu bạn đang làm theo cấu trúc REST API này. Chọn Specify Body là Using JSON, rồi dán đúng một expression lấy cả ba trường từ item đầu vào:

{{ JSON.stringify({ title: $json.title, content: $json.content, status: $json.status }) }}

Dấu {{ }} bật chế độ expression của n8n, $json là item mà node Set vừa đẩy sang, nên không phải chép cứng nội dung lần nữa trong node HTTP Request. Tên các ô trên giao diện đổi theo phiên bản n8n — bản dùng ở đây là 2.35.7 — nhưng ba thứ cần tìm thì không đổi: bật gửi body, chọn kiểu JSON, và trỏ giá trị về node trước. Nếu n8n có tùy chọn tự đặt tiêu đề Content-Type, hãy kiểm tra nó đang nhận dạng body là JSON. Lưu workflow rồi chạy thử với status là draft. Đổi sang publish chỉ sau khi bạn đã xác nhận tài khoản có quyền xuất bản và bạn thực sự muốn bài xuất hiện trên site.

Bấm Execute, đọc response và ba kết quả dễ nhầm

Bấm Execute Workflow hoặc chạy node theo thứ tự từ Manual Trigger. Kiểm tra từng node: Manual Trigger phải khởi chạy được, Set phải tạo ra một item có ba trường, còn HTTP Request phải nhận item đó và trả về phản hồi. Một item ở đây là dữ liệu của một lượt chạy, không phải bằng chứng rằng bài đã hiển thị đúng ngoài website. Trong response thành công của WordPress, tài liệu REST API thường trả về đối tượng bài viết có id, status, link và các trường nội dung khác. Lấy giá trị id và status để đối chiếu, sau đó mở wp-admin bằng tay để tìm bài. Nếu status là draft, bài nằm trong danh sách bản nháp và chưa phải bài công khai.

Có ba kết quả dễ bị nhầm. Thứ nhất, bạn thấy phản hồi thành công nhưng không thấy bài ngoài trang chủ: đó có thể chỉ là bài nháp, hoặc giao diện trang không hiển thị loại nội dung này ở vị trí bạn đang kiểm tra. Thứ hai, bấm Execute nhiều lần và thấy nhiều bài giống nhau: mỗi lần POST tạo tài nguyên mới, không phải cập nhật bài trước; hãy lấy id của bài cũ và dùng yêu cầu cập nhật tới tuyến /wp-json/wp/v2/posts/{id} nếu cần sửa nó. Thứ ba, response báo lỗi nhưng bạn vẫn tìm thấy một bài: có thể yêu cầu đã tới WordPress rồi nhưng n8n hoặc lớp trung gian gặp lỗi khi nhận phản hồi, nên cần kiểm tra thời gian tạo và các bài trùng trong wp-admin trước khi chạy lại. Với lỗi mã trạng thái hoặc thông báo quyền, giữ nguyên response đầy đủ để tra theo tài liệu WordPress và cấu hình máy chủ; đừng vội đổi toàn bộ workflow.

Chỉ thêm lịch, AI hoặc node WordPress sau khi lượt POST tối giản đã thông

Sau khi lượt POST cố định chạy được, bạn có thể chọn tiếp tục dùng HTTP Request hoặc thử node WordPress nếu phiên bản n8n của bạn có node phù hợp. HTTP Request cho phép nhìn rõ URL, phương thức, body và response, nên dễ kiểm tra khi làm tự động đăng bài lên wordpress. Node chuyên dụng có thể thuận tiện hơn cho các thao tác được nó hỗ trợ, nhưng tên trường và tùy chọn có thể thay đổi theo phiên bản n8n. Tôi chưa kiểm tra workflow này trên hosting cụ thể của bạn; plugin bảo mật, tường lửa, bộ nhớ đệm và quyền tài khoản có thể làm kết quả khác đi.

Chỉ thêm Schedule Trigger sau khi bạn đã lưu được post id và biết cách xử lý bài trùng. Trước node xuất bản, đặt một bước duyệt: kiểm tra nội dung, trạng thái và người nhận thông báo khi request thất bại. Nếu dùng AI, giữ đầu ra của AI ở một node riêng và yêu cầu người xem duyệt trước khi đổi draft thành publish. Lúc này bạn mới đang xây một quy trình chạy được lâu dài, thay vì chỉ thử xem một yêu cầu có đi qua được hay không.