この記事の要点：
- WordPress の自動投稿とは、管理画面を開かずに、外部のツールやスクリプトから記事を作成・公開する仕組みです。WordPress 本体に入っている REST API に、アプリケーションパスワードで認証して記事のデータを送るのが、本体の機能だけでできる方法です。
- 記事は
POST /wp-json/wp/v2/postsに、title・content・status・date・categories・featured_media などの項目を送って作ります。status には publish・future・draft・pending・private を指定できます。 - アプリケーションパスワードは WordPress 5.6 から本体に入った機能で、初期設定では HTTPS で配信しているサイトだけで使えます。表示されないときは、HTTPS、無効化の設定、セキュリティ系プラグインやサーバーの制限を順に確かめます。
- 自動で大量に公開すると、title の重複や代表画像の抜けが起きやすく、Google のスパムに関するポリシー（大量生成されたコンテンツの不正使用）にも触れかねません。権限を絞った専用ユーザーで送り、人が確かめてから公開する流れにします。
WordPressの自動投稿とは：外部からREST APIで記事を作る
WordPress の自動投稿とは、WordPress の管理画面で記事を 1 本ずつ入力する代わりに、外部のツールやプログラムから記事を作成・予約・公開することです。記事の制作ツールや社内のシステムで作った原稿を、コピーして貼り付ける手間を省くために使われます。
その土台になるのが WordPress の REST API です。WordPress の公式ハンドブックは、REST API を、アプリケーションが JSON 形式のデータを送受信して WordPress サイトとやり取りするためのインターフェースで、ブロックエディターの基盤でもあると説明しています（REST API Handbook、2026年10月13日確認）。管理画面での投稿も、内部では同じ仕組みを使っています。
同じハンドブックは、REST API は WordPress と同じ認証の制限を持ち、公開されている内容は誰でも読める一方、非公開の内容や記事の作成・変更には認証が必要だとしています。外部から記事を作るときは、この認証にアプリケーションパスワードを使うのが基本です。
自動投稿の方法の種類：プラグイン・連携サービス・REST API
WordPress に自動で投稿する方法は、大きく 3 つに分かれます。どの方法でも、最後に WordPress へ記事を書き込む部分は REST API か WordPress の内部の関数で、違うのは「どこで原稿を作り、何がそれを送るか」です。
| 方法 | 仕組み | 向いている場面 | 確かめること |
|---|---|---|---|
| WordPress のプラグイン | サイトの中で動き、RSS の取り込みや定期実行で記事を作る | 外部のサーバーを用意せず、サイトの中で完結させたい | プラグインの更新状況、サーバーの負荷、取り込む内容の権利 |
| ノーコードの連携サービス | 表計算や他のツールの変更をきっかけに、REST API で投稿する | プログラムを書かずに、他の業務ツールとつなぎたい | サービスに預ける認証情報の範囲、送れる項目 |
| REST API を直接使う | 自社のスクリプトや記事制作ツールから、認証して POST する | 送る項目や公開の条件を細かく決めたい | 認証の方法、エラー時の扱い、権限 |
予約投稿だけが目的なら、WordPress の編集画面で公開日時を未来にして「予約投稿」にすれば、追加の仕組みは要りません。自動投稿が役立つのは、原稿を作る場所が WordPress の外にある場合です。WordPress 全体の SEO の設定はWordPressのSEO対策、CMS を選ぶときに確かめる機能は「CMSとSEO」で説明しています。
アプリケーションパスワードの発行手順
アプリケーションパスワードとは、外部のアプリケーションが REST API に接続するための、ユーザーごとの専用のパスワードです。WordPress の公式ハンドブックは、WordPress 5.6 からアプリケーションパスワードが本体に入り、ユーザーの編集画面から発行できること、認証情報は https:// で配信される REST API に Basic 認証で渡せることを説明しています（Authentication – REST API Handbook、2025年6月4日更新）。
- 投稿に使うユーザーで WordPress の管理画面にログインし、「ユーザー」→「プロフィール」（管理者がほかのユーザーの分を作るときは「ユーザー」→ 対象のユーザーの編集）を開きます。
- 「アプリケーションパスワード」の欄に、用途が分かる名前（例：記事制作ツール）を入れて「新しいアプリケーションパスワードを追加」を押します。
- 表示されたパスワードを控えます。WordPress の開発者向けの解説によると、パスワードは記号を含まない 24 文字で、4 文字ずつ区切って表示され、空白は付けても付けなくても使えます。
- 接続するツールに、サイトの URL、ユーザー名、控えたアプリケーションパスワードを登録します。ログイン用のパスワードは渡しません。
- 使わなくなったツールの分は、同じ画面の一覧から取り消します。一覧では最後に使われた日も確かめられます。
アプリケーションパスワードは、管理画面へのログインには使えません。WordPress の統合ガイドは、アプリケーションパスワードはプログラムから使うためのもので、人が操作する画面のログインに使うものではないと説明しています（Application Passwords: Integration Guide）。
REST APIで下書き・予約公開する：送る項目の表
REST API で記事を作るには、/wp-json/wp/v2/posts に POST で記事の項目を送ります。WordPress の REST API ハンドブックの Posts のリファレンスに載っている主な項目は次のとおりです（Posts – REST API Handbook、2026年10月13日確認）。
| 項目 | 公式の説明（要約） | 使い方の注意 |
|---|---|---|
| title | 記事のタイトル | 空のまま送らない。SEO プラグインの title の元になることが多い |
| content | 記事の本文 | HTML で送る。見出しの階層を崩さない |
| excerpt | 記事の抜粋 | 説明文の元に使うテーマやプラグインがある |
| status | 記事の状態。publish・future・draft・pending・private のいずれか | 人が確かめる運用なら draft か pending で送る |
| date／date_gmt | 公開日時。date はサイトのタイムゾーン、date_gmt は GMT | 予約公開の日時。どちらで送るかをそろえる |
| slug | 記事の種類の中で一意の識別子（URL の末尾） | 既存の記事と重ならない、内容を表す短い語にする（パーマリンクの決め方） |
| categories／tags | カテゴリーとタグの ID の配列 | 名前ではなく ID で送る |
| featured_media | アイキャッチ画像のメディアの ID | 画像は先に /wp/v2/media へ送り、返ってきた ID を指定する（アイキャッチ画像の決め方） |
| author | 投稿者のユーザー ID | 専用ユーザーの ID にそろえる |
下書きで送る場合の最小の例です（ユーザー名とアプリケーションパスワード、サイトの URL は置き換えます）。
curl --user "USERNAME:APPLICATION_PASSWORD"
-X POST https://example.com/wp-json/wp/v2/posts
-H "Content-Type: application/json"
-d '{"title":"記事のタイトル","content":"<p>本文</p>","status":"draft","categories":[5]}'WordPress の説明では、future は「将来の日時に公開を予約された状態」、pending は「publish_posts の権限を持つユーザー（通常は編集者）の公開を待つ状態」、draft は「適切な権限のユーザーだけが見られる未完成の記事」です（Post Status）。予約公開にするときは、status を future にし、公開したい日時を date（サイトのタイムゾーン）か date_gmt（GMT）で渡します。成功すると、作られた記事の id・link・status などが JSON で返ってきます。返ってきた status と link を記録しておくと、後で公開の結果を確かめられます。
使えないときの原因と確かめ方
アプリケーションパスワードの欄が表示されない、または認証に失敗するときは、HTTPS・無効化の設定・サーバーやプラグインの制限の順に確かめます。WordPress の統合ガイドは、初期設定ではアプリケーションパスワードは SSL／HTTPS で配信しているサイトのすべてのユーザーが使え、wp_is_application_passwords_available などのフィルターで使えなくしたり、使えるユーザーを絞ったりできると説明しています。
| 症状 | 考えられる原因 | 確かめ方 |
|---|---|---|
| プロフィールにアプリケーションパスワードの欄が無い | サイトが HTTPS で配信されていない | 「設定」→「一般」の WordPress アドレスとサイトアドレスが https で始まるか |
| 同じく欄が無い | テーマ・プラグインのフィルターで無効化されている | セキュリティ系のプラグインの設定、wp_is_application_passwords_available を使うコード |
| 特定のユーザーだけ欄が無い | ユーザーごとに使えるかを絞る設定がある | wp_is_application_passwords_available_for_user を使うコード |
| 401 が返る | ユーザー名・アプリケーションパスワードの誤り、取り消し済みのパスワード | 公式ハンドブックの例と同じ /wp-json/wp/v2/users?context=edit を同じ認証で読めるか |
| 403 が返る | ユーザーの権限が足りない、サーバーやプラグインが REST API へのアクセスを制限している | ユーザーの権限グループ、サーバーの管理画面のアクセス制限の設定 |
| 予約の時刻がずれる | サイトのタイムゾーンと送った日時の基準が違う | 「設定」→「一般」のタイムゾーン、date と date_gmt のどちらで送ったか |
サーバー側の制限にも注意します。たとえばエックスサーバーの「WordPressセキュリティ設定」には、REST API（/wp-json）への国外からの接続を制限する「REST API アクセス制限」があり、マニュアルは通常は有効のまま運用するよう強く勧める一方、国外から WordPress を使う場合は無効にするよう案内しています（WordPressセキュリティ設定、2026年10月13日確認）。外部のツールが国外のサーバーから送る場合は、こうした制限で 403 になることがあります。設定を変える前に、どこから送られるのかをツールの提供元に確かめます。
統合ガイドは、SSL なしでは通信の途中でアプリケーションパスワードを盗み見られるおそれがあると注意しています。HTTPS でないサイトで無理に使えるようにする前に、サイトを HTTPS にするのが先です。
当サイトの受け口の設定：REST APIで届いた記事を整える
当サイト（seoagent.jp）は WordPress で動いており、SEOAGENT 本体から REST API（/wp-json/wp/v2/posts）にアプリケーションパスワードで記事を送る前提で、サイト側に受け口の処理を入れています（リポジトリの seoagent-site プラグイン、2026年10月13日確認）。
SEOAGENT 本体が送る項目は title・content（HTML）・excerpt（説明文）・slug・categories（1 つ）・tags・featured_media・author で、送る状態は「すぐに公開」（publish）か「予約公開」（future）です。多言語プラグインの言語や、SEO プラグインの説明文は送りません。そこで、WordPress が REST API で記事を作った直後に動くフック（rest_after_insert_post）で、空いている欄だけを次のように埋めています。
| 欄 | 当サイトの補い方 | 補わないと起きること |
|---|---|---|
| 記事の言語 | 選ばれたカテゴリーの言語。カテゴリーが無ければ日本語 | 言語が決まらず、言語別の一覧や hreflang から外れる |
| 分類 | ガイドとニュースのどちらの分類も無ければ、その言語のガイドの分類に入れる。「未分類」だけなら置き換える | 記事が「未分類」に入り、一覧やトピックのページに載らない |
| SEO プラグインの説明文 | 空なら excerpt を使う | meta description が空のまま公開される |
| 構造化データの種類 | 空なら記事（article）として扱う | 記事として扱われない |
入力済みの値は変えないことにしています。外から送られた値を上書きすると、送った側の意図と公開された記事がずれるためです。REST API での自動投稿を受けるサイトでは、「送られてこない項目は何か」と「それが空のまま公開されたら何が起きるか」を先に洗い出しておくと、公開後の手直しが減ります。
自動投稿で起きやすいSEOの問題と点検
自動投稿では、人が画面で見れば気付く抜けや重なりが、そのまま公開されやすくなります。公開後に機械的に点検し、問題のあるページを洗い出す仕組みを用意しておきます。
| 起きやすい問題 | 原因 | 点検のしかた |
|---|---|---|
| title が空、または同じ title が並ぶ | 原稿の title の欄を送り忘れる、同じテンプレートで量産する | 公開ページの title の長さと重複を一覧にする |
| meta description が空 | SEO プラグインの説明文は REST API の標準の項目に無い | 説明文の空と重複を一覧にする |
| アイキャッチが無い | featured_media を送っていない、画像の登録に失敗した | og:image の有無を見る |
| カテゴリーが「未分類」 | categories を名前で送った、ID が違う | カテゴリーごとの記事数を見る |
| 同じ内容の記事が 2 本できる | 送信の再試行で同じ原稿を 2 回 POST した | 同じ title の記事が無いかを見る。送る側で、返ってきた id を記録して再送を防ぐ |
| 画像の alt が空 | 本文の img に alt を付けずに送った | alt の無い画像を一覧にする |
当サイトでは、公開ページを巡回して title の長さと重複、説明文の有無と重複、h1 の数、og:image の有無、alt の無い画像、canonical、noindex とサイトマップの食い違い、どこからもリンクされていないページなどを点検するスクリプトを、記事を足すたびに実行しています。2026年10月13日の実行では、サイトマップに載っている 245 URL を含む 261 ページを点検しました。
安全に運用するための権限と確認の流れ
自動投稿には、管理者ではなく、必要な権限だけを持つ専用のユーザーを使います。WordPress の権限グループの説明によると、「投稿者」は自分の記事の作成・公開・画像のアップロードができ、「編集者」はそれに加えてほかのユーザーの記事やカテゴリーの管理ができます。「寄稿者」は記事を作れても公開はできません（Roles and Capabilities）。
| 運用 | 専用ユーザーの権限 | 送る status |
|---|---|---|
| 人が必ず確かめてから公開する | 寄稿者（公開できない） | pending（レビュー待ち）か draft |
| 確かめた原稿だけを外部から予約・公開する | 投稿者 | future か publish |
| カテゴリーやタグも外部から作る | 編集者 | future か publish |
記事を大量に自動公開する運用には注意が要ります。Google のスパムに関するポリシーは、ユーザーをサポートすることではなく検索ランキングの操作を主な目的として大量のページを生成することを「大量生成されたコンテンツの不正使用」とし、その例として、生成 AI ツールなどを使ってユーザーにとっての価値を付加することなく大量のページを生成することを挙げています（Google ウェブ検索のスパムに関するポリシー、2026年9月2日更新、2026年10月13日確認）。問われるのは作り方ではなく、読者にとっての価値です。
そのため、自動化するのは「入稿の作業」にとどめ、内容の確認は人が行う流れを勧めます。原稿を作る → 事実と数字を確かめる → 下書きか予約で送る → 公開後に点検する、の順です。AI で作った原稿を公開する前に確かめる点は「AIライティングとは」で説明しています。サイトの設定に関わる記事は「テクニカルSEOの記事一覧」にまとめています。なお、Google 検索セントラルは、AI による概要や AI モードでリンクとして表示されるための条件を、インデックスに登録されスニペットを表示できることなどとし、それ以外に追加の技術要件は無いとしています（AI 機能とウェブサイト）。REST API で送った記事も、条件は管理画面で公開した記事と同じです。
よくある質問
アプリケーションパスワードが表示されないのはなぜですか？
多いのは、サイトが HTTPS で配信されていない場合と、セキュリティ系のプラグインやテーマのコードで無効化されている場合です。WordPress の初期設定では、アプリケーションパスワードは HTTPS のサイトでだけ使えます。「設定」→「一般」のアドレスが https で始まるかから確かめます。
予約投稿の時刻がずれるのはなぜですか？
送った日時の基準と、サイトのタイムゾーンが合っていないことが考えられます。REST API の date はサイトのタイムゾーン、date_gmt は GMT として扱われます。「設定」→「一般」のタイムゾーンを確かめ、送る側でどちらの項目を使うかをそろえます。
自動投稿はGoogleのペナルティになりますか？
投稿の方法そのものが問題になるわけではありません。Google のスパムに関するポリシーが問題にするのは、ユーザーにとっての価値を付加せずに大量のページを生成することです。人が内容を確かめてから公開する流れにし、似た記事を量産しないようにします。
画像やカテゴリーも自動で設定できますか？
できます。画像は先にメディアの API（/wp/v2/media）へ送り、返ってきた ID を記事の featured_media に指定します。カテゴリーとタグは、名前ではなく ID の配列で送ります。カテゴリーの ID は WordPress の管理画面か、カテゴリーの API で確かめられます。
SEOAGENTでできること
SEOAGENT では、作成・確認した記事を WordPress へ送る入稿の作業を省力化できます。
- WordPressへの記事投稿・予約公開：サイトの URL・ユーザー名・アプリケーションパスワードで WordPress と接続し、タイトル・本文・画像・カテゴリ・タグ・スラッグなどを設定して送れます。公開のしかたは「公開する（すぐに公開）」と「スケジュールする（日時を指定して公開）」の 2 つで、公開済みの記事の更新にも使えます。スラッグが他の記事と重なる場合は末尾に番号が付き、公開の前の確かめをしないまま予約しようとすると注意が表示されます。
- note向けの記事制作・自動投稿の運用支援：note を公開先にする場合は、接続した Chrome 拡張を通じて予約を入れます。WordPress とは接続の方法が違います。
できないこと：WordPress へ下書きとして送ることはできません（すぐに公開か予約公開のどちらか）。サイト全体のデザインやサーバーを自動で作る機能ではなく、多言語プラグインや SEO プラグインの説明文への対応は接続する環境ごとに確かめます。Yoast SEO を使っているサイトでは、説明文を書き込めない場合や、WordPress 側で入力済みの文を上書きしない場合があります。
参考情報
- WordPress：REST API Handbook
- WordPress：Posts – REST API Handbook
- WordPress：Media – REST API Handbook
- WordPress：Authentication – REST API Handbook
- Make WordPress Core：Application Passwords: Integration Guide
- WordPress Documentation：Roles and Capabilities
- WordPress Documentation：Settings General screen
- WordPress Documentation：Post Status
- エックスサーバー マニュアル：WordPressセキュリティ設定
- Google 検索セントラル：Google ウェブ検索のスパムに関するポリシー
