n8nでWordPressを自動化｜下書き・通知・データ連携【2026年】

※本記事には外部リンクが含まれています。

n8nをWordPressにつなぐと、投稿の下書き作成、記事データの取得、更新案の通知などを一連の流れにできます。ただし「自動化できる」と「安全に本番公開してよい」は別問題です。この記事では、初めて設定する人向けに、読み取り→テスト下書き→承認→更新前確認という順序で、設定手順と失敗しやすい箇所を整理します。ここに記載するのは公式ドキュメントに基づく操作の説明であり、特定の環境で接続・速度・成功率を実測した結果ではありません。

最初に決める：何を自動化し、何を人が確認するか
準備：WordPressとn8nの接続方法
安全な最小フロー：テスト下書きを1件作る
記事の下書き・通知・データ連携で使う3つの例
既存記事を更新するときの安全設計
よくあるエラーと切り分け
参考にした公式情報と関連記事
ここで終わらず、次の判断までつなぐ
そのAI、何分時短できれば元が取れる？

最初に決める：何を自動化し、何を人が確認するか

作業	初期設定での推奨	確認すること
投稿一覧の取得	読み取りから開始	対象サイト・件数・取得日時
原稿の生成	下書き用テキストに限定	出典・著作権・実体験表現
WordPressの投稿作成	まず非公開のテスト下書き	投稿ID・タイトル・本文・カテゴリー
既存記事の更新	差分承認と直前照合の後	URL・旧本文・Gutenberg・広告
公開・削除	初期フローには含めない	人の承認と復旧手順

定期的な記事更新では、誤ったサイトへ送信する事故や、別の担当者が編集した記事を古い本文で上書きする事故が起こり得ます。最初は記事取得と下書きだけを対象にし、正常に処理できたことを確認してから対象を増やします。完成イメージが曖昧なら、先に手動で1回実行して必要な情報を一覧化してください。

準備：WordPressとn8nの接続方法

n8n公式のWordPressノードには、投稿の作成・取得・一覧取得・更新、固定ページとユーザー関連の操作が用意されています。通常のセルフホストWordPressに対しては、WordPressのユーザー名・アプリケーションパスワード・サイトURLを使う認証手段が公式ドキュメントで案内されています。WordPress.comのOAuth2と同じ設定だと思わず、利用環境に合う認証方法を選びます。

WordPress管理画面で自動化専用のユーザーの権限を検討する。管理者権限は必要最低限にし、公開が必要ない工程へ公開権限を与えない。
利用するWordPressのプロフィール画面などで、アプリケーションパスワードを作成する。ホスティング方式やセキュリティ設定により表示場所・利用可否が異なる場合がある。
n8nのCredentialsでWordPress接続情報を作り、サイトの正確なHTTPS URL、ユーザー名、アプリケーションパスワードを登録する。パスワードをノードの説明欄や実行ログへ平文で書かない。
TLS証明書に問題がある場合、検証無効化で回避しない。証明書・URL・サーバー時刻を修正してから接続する。
WordPress REST APIが接続先から利用できるか、ログイン・ファイアウォール・アクセス制限を確認する。

二段階認証やCloudflare等を使用するサイトでは、ブラウザのログイン可否とREST APIの利用可否が一致しないことがあります。接続に失敗したからといってセキュリティ機能を一律停止せず、ブロックされた通信と例外設定の必要性を切り分けてください。

安全な最小フロー：テスト下書きを1件作る

次は既存公開記事に触れず、手動操作で下書きを1件作るだけの練習フローです。n8nのバージョンにより表示ラベルは変わるため、以下の項目がない場合はWordPressノード公式ドキュメントで対応操作を確認し、別の操作を推測で選ばないでください。ここで実アカウントに接続・実行したわけではありません。

n8nで新規ワークフローを作り、最初のノードにManual Trigger（手動トリガー）を置く。外部Webhookや定期実行はまだ設定しない。
次にEdit Fields（Set）など入力値を作るノードを追加し、文字列 title＝【接続テスト】n8n下書き、content＝<p>公開しない接続テストです。</p>、status＝draft を入力する。文字列の引用符はフィールド値に含めない。
WordPressノードを追加する。接続情報には、対象WordPressの正確なサイトURL・専用ユーザー名・そのユーザーのアプリケーションパスワードを保存したCredentialsを選ぶ。別サイト用のCredentialsを選んでいないか、接続先を読み上げて確認する。
ノードにある投稿のCreate／作成操作を選び、タイトル欄には前のノードから title、本文欄には content を対応付ける。投稿状態を指定できる場合はdraft／下書きを明示する。もし当該ノードのUIで投稿状態を設定できない、または出力内容を確認できない場合は実行を中止し、ノードのオプションや公式ドキュメントを確認する。
ワークフローを手動で1回だけ実行する。返却された投稿ID・status・リンクなどの値を記録する。自動リトライを有効にしたままCreateを再実行しない。
WordPressの投稿一覧→下書きから該当ID・タイトル・本文を再確認する。編集URLはWordPress側で開き、公開用URLが意図せず生成されていないかを確かめる。確認が終わるまでワークフローを有効化しない。

入力値の例は概念を説明するためのもので、実際のUIに必ず title や content という日本語・英語ラベルが表示される保証はありません。下書き用アカウントに投稿作成権限がない場合は、対象ユーザーの権限とREST APIの認証結果を確認します。失敗したとき管理者権限を一律付与したりWAFを丸ごと無効にしたりしないでください。

作成後の重複防止： WordPressが投稿IDを返したあと通知処理だけ失敗した場合、Createから最初からやり直すと下書きが増えます。最初のテストでも投稿IDを保存し、再実行前にそのIDの下書きが存在するか確認します。実運用では外部の依頼IDと作成済み投稿IDを紐づけ、同じ依頼を二度作成しない設計が必要です。

記事の下書き・通知・データ連携で使う3つの例

下書き作成： フォームや表計算の依頼内容を受け、必須項目の空欄を確認→AIへ構成案を依頼→原稿を下書き保存→担当者へ編集URLを通知。AI生成文の出典や画像の権利を点検する工程を公開前に挟みます。「AIが書いたからそのまま公開」という設計にしないことが重要です。

記事台帳： WordPress投稿一覧からID・URL・更新日時・タイトルを取得し、DBや管理表に保存。スケジュール処理で差分だけを取得する場合も、ページネーションやタイムゾーン、非公開記事の混入を確認します。公開記事の件数が合わないときはAPIの一度の取得件数制限を疑います。

通知： 既存記事の更新日時を監視し、意図しない変更を検出したら担当者へ通知。これは監査の補助であって、変更理由やSEO効果を自動断定するものではありません。送信する通知には、記事ID・サイトURL・変更日時・確認用リンクを必ず含めます。

既存記事を更新するときの安全設計

既存記事の本文を上書きする前には、WordPressから編集元を再取得し、記事ID・URL・更新日時・本文ハッシュを確認します。事前に保存した原本と異なる場合は自動処理を止め、最新内容へ差分を作り直します。下書き作成時点では一致していても、実際の更新直前に別の人が変更している可能性があるからです。

更新対象を本文の一部分に限定できるなら、Gutenbergブロック全体を置き換えず差分変更を検討します。CocoonのSEO設定、アイキャッチ、カテゴリ、タグ、PR表記、ASP広告、計測用の画像や属性は本文と別に保護すべき項目です。WordPressの「本文が更新できた」という応答だけでは、これらが保存されている保証にはなりません。

更新後にはAPIで本文を取得し直し、表示ページでも見出しのコントラスト、表の横スクロール、リンク、広告表示、関連記事の重複を確認します。失敗した場合に戻せるよう、更新前の本文とメタデータを記事IDごとに保管します。バックアップだけ作って復元手順を確かめない運用は避けてください。

よくあるエラーと切り分け

症状	まず確認する場所	対応の方向
401／403	ユーザー権限、アプリケーションパスワード、セキュリティ設定	対象操作の権限を最小限で再設定
404	サイトURL、REST APIのパス、投稿ID	手動で対象URLと公開状態を再確認
投稿だけ作られ本文が空	入力フィールド名、本文形式、バリデーション	入力データと返却本文を比較
二重投稿	Webhook重複、再試行設定、一意キー不足	作成済みIDを照合して再作成を止める
古い内容に戻った	編集後の再取得不足	更新を止め最新原本で差分を再作成