WordPress 與 N8n 整合的應用範例：從發文到名單同步的實作流程
- 最後更新日期：
🚀 讀者專屬工具
立即開啟 →
在開始閱讀前，先用 AI 自動生成您的網站架構圖？
你可能也遇過這種狀況，WordPress 文章已上線，但通知、同步、整理、回報都還要靠人複製貼上。事情不難，只是很耗時間，而且每次都容易漏一步。
WordPress n8n 整合的價值很直接，把「事件」變成「流程」。WordPress 一有動作，n8n 就接手處理通知、寫入資料庫、更新欄位、發警報，最後留下可追蹤的紀錄。
下面用實作角度，拆成前置選擇，外加 3 個常見應用範例。每個範例都包含 WordPress 端設定、n8n workflow 建立，還有測試與上線方式。
串接方式先選對，REST API vs 外掛 Webhook 怎麼挑
大方向只有兩條路，n8n 主動打 WordPress REST API，或是 WordPress 主動丟 Webhook 給 n8n。兩者都能做出成果，但適用情境不同。
先用一個簡短對照表抓方向：
| 選項 | 觸發方式 | 優點 | 你會遇到的代價 |
|---|---|---|---|
| REST API (HTTP Request) | n8n 主動查詢或寫入 | 控制力高，能補抓漏資料 | 需要排程與去重，避免重複處理 |
| Webhook (外掛或自建) | WP 有事件就推送 | 即時，流程更貼近「事件驅動」 | 要做驗證與重試，避免丟失 |
什麼時候選 REST API？
當你要「批次同步」、要補跑歷史資料，或要穩定讀取 posts/users/media 時，REST API 很好用。參考像 Hostinger 的 n8n 自動化指南 這類作法，通常就是 Cron 加 HTTP Request 的組合。
什麼時候選 Webhook？
當你在意「即時性」，例如發文立刻通知、表單送出立刻分派，就選 Webhook。你可以用支援 Webhook 的外掛，或用簡單的自訂動作在特定事件發送請求。
不管選哪條路，權限建議用 WordPress 內建的應用程式密碼，並開專用帳號，只給必要權限。想把內容發布與管理流程做成一個中心化的自動化後台，可以延伸看 n8n 與 WordPress 深度整合完整教學。
小提醒：WordPress REST API 常見會遇到分頁與上限，像
per_page最多 100。做同步時要記得加上「游標」或「最後處理時間」。
範例一：新文章發布後，自動通知 Slack 或 Telegram
這個流程適合行銷與內容團隊。你要的不是「有人發文」，而是「該通知的都通知，該存檔的都存檔」。
WordPress 端設定（兩種做法）
- REST API：準備應用程式密碼，讓 n8n 可讀取文章。常用端點是
GET /wp-json/wp/v2/posts，需要的欄位多半是id、date、link、title.rendered、status、categories。 - Webhook：用外掛或自建事件，在「文章從草稿變已發布」時 POST 到 n8n Webhook URL。常見 payload 可以先用精簡版，例如
{"post_id":123,"status":"publish","title":"新文章","url":"https://example.com/p/123","categories":[7,9]}。
n8n workflow 建立（建議 nodes）
Webhook 或 Cron、HTTP Request、IF、Set、Merge、Slack 或 Telegram、(可選) Notion 或 Google Sheets。
做法很直覺：收到事件或查到新文章後，用 IF 篩選分類或標籤，再把標題與連結組成訊息發出去。同時，你也可以把摘要寫進 Notion，或追加到 Google Sheets 當內容台帳。
測試與上線
先用測試文章跑一次，確認不會重複通知。上線後，建議在 n8n 的節點開啟失敗重試，並把失敗分支接到 Email 或 Slack 告警。若你走 Webhook 路線，可以參考 Webhook 同步 Telegram 範例 的思路，但記得補上驗證與重試。
範例二：表單或註冊名單同步到 Google Sheets，並回寫標籤到 WordPress
名單同步常見的痛點是，資料出去就回不來。更好的做法是，n8n 在外部整理後，再回寫 WordPress，讓後台也看得到處理狀態。
WordPress 端設定（兩種做法）
- REST API：如果你把每筆名單存成自訂內容類型，記得註冊時開
show_in_rest=true，之後就能用GET /wp-json/wp/v2/{cpt_slug}讀取。要回寫狀態時，可用POST /wp-json/wp/v2/{cpt_slug}/{id}更新meta。 - Webhook：表單送出時直接 POST 到 n8n。payload 建議固定欄位，後面才好維護，例如
{"name":"王小明","email":"a@b.com","source":"landing-page","consent":true,"utm":"google-cpc"}。
n8n workflow 建立（建議 nodes）
Webhook、Set、Function、IF、Google Sheets、Notion、HTTP Request、Merge、Email。
流程可以這樣排：先清洗資料(去空白、email 小寫化)，再用 IF 判斷是否同意行銷或是否為公司信箱。接著寫入 Google Sheets，並用 HTTP Request 回寫 WordPress，把該筆名單標記為 synced=true，或加上 status="qualified"。
測試與上線
測試時要特別看兩件事：重送 Webhook 是否會產生重複列，還有回寫失敗是否會卡住整條流程。上線後，把敏感欄位做遮罩，只在需要的節點保留明文。
範例三：每日自動稽核待審留言，出事就告警
這個範例適合站長。你不需要每天巡後台，但你需要知道「今天有沒有怪事」。
WordPress 端設定（兩種做法）
- REST API：用
GET /wp-json/wp/v2/comments?status=hold&per_page=100抓待審留言，欄位常用id、author_name、author_email、content.rendered、post。 - Webhook：如果你有自訂審核規則，也能在留言進入待審時觸發 Webhook，但多數情況排程抓取更穩。
n8n workflow 建立（建議 nodes）
Cron、HTTP Request、Function、IF、Email 或 Slack、(可選) WordPress node。
Function 用來做簡單規則，例如同一 IP 次數、關鍵字命中、或包含多個連結。IF 命中後就寄信或丟到 Slack，並附上留言連結與摘要。
測試與上線
先用幾筆假留言測試規則，避免誤報。上線後，建議限制 Cron 的並行數，避免瞬間抓太多造成 API 壓力。
安全底線：Webhook 一定要驗證(自訂 header token 或 Basic Auth)，而且別把應用程式密碼寫進可公開的欄位。n8n 也要把憑證放在 Credentials，並控制可讀權限。
結語：把重複工作交給流程，把時間留給成長
當你把通知、同步、稽核都交給 n8n，WordPress 後台就不再是「人工工作台」，而是可被調度的資料來源。從一個發文通知開始，你會很快想把第二個、第三個流程也接上去。只要先把權限、驗證、重試與告警做好，WordPress n8n 整合就能長期穩定運作。下一步，你最想先自動化的是內容流程，還是名單流程？
