WordPress REST APIを使った自動投稿では、APIが200系を返した瞬間に「公開成功」と判断したくなります。しかし実運用では、REST APIの更新成功と、読者や検索エンジンから見た本番ページの成功は別物です。投稿データが保存されても、キャッシュで古い本文が表示される、canonicalが想定外を向く、noindexが残る、内部リンクが壊れる、画像が出ない、といった問題は公開URLを確認しないと分かりません。
そこで必要になるのがproduction QA（公開後QA）です。この記事では、WordPress自動投稿を「送信できたか」ではなく「本番で正しく見えるか」まで閉じるために、どの項目をどの順番で確認するかを整理します。AIBlogBaseで実際に採用している、GitHubでコンテンツを管理し、WordPress REST APIで反映し、公開URLを再取得して検証する考え方を一般化したものです。
すでにGitHub ActionsからWordPressへ投稿する基本構成を知りたい場合は、先にGitHub ActionsでWordPress投稿を自動化する方法を確認すると、今回のQA設計とのつながりが分かりやすくなります。
なぜREST APIの成功だけでは足りないのか
WordPress REST APIは、外部アプリケーションから投稿やメディアなどを操作するための正式なインターフェースです。外部ツールから認証する場合はApplication Passwordを使う構成が用意されており、HTTPS経由での利用が前提になります。ここまでは「WordPressへ正しくリクエストを送る」ための仕組みです。
一方で、公開後のページにはREST API以外の要素が関わります。テーマがタイトルを加工する場合もあれば、SEOプラグインがcanonicalやrobotsを出力する場合もあります。CDNやページキャッシュが古いHTMLを返すこともあります。つまり、APIレスポンスだけを見ても、最終的なHTMLがどう配信されているかは保証できません。
自動化で重要なのは、この境界を明確にすることです。おすすめは、処理を次の2段階に分けることです。
- Write QA：WordPress REST APIで意図した投稿が作成・更新されたかを確認する
- Production QA：公開URLを外部から取得し、読者と検索エンジンが見るHTMLを確認する
この2段階を分けると、「WordPressには保存されたが本番HTMLは古い」というキャッシュ問題も検出できます。
公開後QAで確認すべき7項目
すべてのサイトで同じ検査が必要とは限りませんが、記事公開やリライトの自動化では、少なくとも次の7項目を基準にすると失敗を拾いやすくなります。
1. HTTPステータスが200か
最初に公開URLへGETリクエストを送り、HTTP 200で取得できることを確認します。404、500、リダイレクトループなどが起きている場合は、本文の検査へ進む前に失敗として扱います。
ここで注意したいのは「WordPress REST APIで投稿IDが返ったからURLも正常」と決めつけないことです。パーマリンク、Webサーバー設定、キャッシュ、プラグインなど、公開側で別の問題が起きる可能性があります。
2. 想定したタイトルと主要本文が表示されているか
次に、公開HTML内へ今回のタイトルと主要な本文断片が存在するかを確認します。単にページが200で返ってきても、古いキャッシュや別投稿が表示されていれば更新成功とは言えません。
全面一致を要求するとテーマの装飾やHTML正規化で誤判定しやすいため、タイトル、記事固有の見出し、更新した重要文など、複数の安定したマーカーを確認する方法が実用的です。リライトなら「削除すべき古い文言が残っていないこと」も同時に確認します。
3. canonicalが意図したURLを指しているか
Google Search Centralでは、重複または非常に似たページについて、リダイレクト、rel="canonical"、サイトマップなどがcanonical選択のシグナルになると説明されています。通常の記事更新でURLを変えていないなら、公開HTMLのcanonicalがその記事自身を指しているかを確認しておくと安全です。
自動化で特に危険なのは、テンプレートやSEOプラグイン設定変更により、全記事がトップページや別URLをcanonicalとして出してしまうケースです。本文が正常でも、検索側では重大な問題になり得るため、production QAへ含めます。
4. 意図しないnoindexがないか
本番公開する記事なのにrobots metaへnoindexが含まれていないかを確認します。下書きや検証環境用の設定が残っていると、記事は人間には読めても検索流入を得られません。
逆に、サイト全体で意図的にnoindexにしているページまで一律にindexへ変えるのも危険です。QAは「期待する状態と一致するか」を見るものであり、すべてのページをindexさせる処理ではありません。
5. 内部リンクとCTAが正しい到達先を向いているか
記事更新時に追加した内部リンクやCTAは、リンク文字列がHTMLに存在するだけではなく、対象URLが正しいかまで確認します。リンク先を変更した記事や、日付入りURLを使うサイトでは、古いURLが残りやすいためです。
AIBlogBaseでは、情報記事から次に読む記事や実際に使える無料資産へ自然に進める導線を重視しています。たとえばWordPress運用の自動化を自分のブログで試したい読者には、AIBlogBase Liteのようなowned assetへの導線が、テーマと関係する場合だけ置かれているかを確認します。無関係なCTAを増やすことはproduction QAの目的ではありません。
6. アイキャッチと主要画像が壊れていないか
WordPressの投稿本文だけを更新する処理でも、featured_mediaを誤って0へ戻したり、更新用スクリプトが別画像を割り当てたりする事故があります。更新前に既存のfeatured media IDをスナップショットとして保存し、更新後も同じ画像を維持すべきケースでは、その値を比較すると安全です。
新規公開では、画像URLが実際に取得できるか、altが記事内容と一致するかも確認します。自動生成した画像を使う場合も、ファイルがアップロードできたことと公開ページで表示できることは分けて確認します。
7. 失敗したときに「公開済み」と記録しないか
最後が最も重要です。QAのどれかが失敗したとき、処理結果を成功として記録してはいけません。自動化の状態管理で「公開済み」と残ると、次のrunはその記事を正常とみなし、問題が長期間放置される可能性があります。
既存記事を更新した場合は、変更前のタイトル、本文、抜粋、カテゴリ、タグ、featured mediaなど、必要な範囲をスナップショットとして保存しておくと、QA失敗時に戻しやすくなります。新規記事なら、QA失敗時に公開状態から下書きへ戻す方法もあります。
キャッシュがあるサイトでは再試行を入れる
production QAでよく起きるのが、WordPress REST APIでは新しい本文を確認できるのに、公開URLだけ古いHTMLを返す状態です。この場合、更新処理そのものが失敗したとは限りません。CDN、サーバーキャッシュ、WordPressキャッシュプラグインなどが旧ページを返している可能性があります。
そこで、公開直後の1回だけで失敗確定にするのではなく、数回の再試行を入れます。ただし無制限のリトライは避けます。たとえば、短い間隔で数回だけ再取得し、それでも期待する本文が見えなければ失敗として扱います。
また、再試行のたびにWordPressへ同じ更新を投げ直す必要はありません。Write QAでWordPress側の内容が正しいと確認できているなら、公開HTMLだけを再取得します。これにより二重投稿や不要な更新履歴を防げます。
GitHub ActionsではSecretsと権限を最小化する
公開後QAのために認証情報をログへ出す必要はありません。GitHub ActionsではSecretsを使って認証情報を通常ファイルと分離できます。WordPressのApplication Passwordも記事ファイルやPythonコードへ直書きせず、workflowの実行時だけ環境変数として渡します。
GitHubのworkflowではpermissionsでGITHUB_TOKENの権限を調整できます。WordPressへ外部HTTPリクエストを送るだけの公開ジョブなら、リポジトリへの書き込み権限が本当に必要かを確認し、不要ならread中心にします。production QAのためだけに過剰な権限を付ける必要はありません。
また、Secretsが自動的にマスクされる仕組みに依存し過ぎず、そもそも値をechoしない設計にします。例外発生時のリクエストヘッダー全文出力なども避けるべきです。
production receiptを残すと次の自動化が安全になる
公開後QAが成功したら、何を確認して成功したのかを機械可読なreceiptとして残すと、次のrunが安全になります。最低限、対象URL、変更種別、公開時刻、QA結果、rollback有無、実行runの識別子などを保存します。
receiptがあれば、「GitHubのコードは直っているが本番反映の証拠がない」「一度失敗した通知だけ残っているが、その後成功したのか分からない」といった状態を減らせます。特に複数の自動化が同じWordPressを触る場合、成功判定をログの雰囲気ではなく状態ファイルで共有できるのが大きな利点です。
ただしreceiptへApplication Password、affiliate ID、tracking IDなどを保存してはいけません。必要なのは実行証拠であり、秘密情報ではありません。
実装例：公開後に確認する順番
実装時は次のような順序にすると、失敗原因を切り分けやすくなります。
- 公開前の品質ゲートを通す
- 既存記事なら更新前スナップショットを取得する
- WordPress REST APIで作成または更新する
- REST APIで保存後の投稿状態を確認する
- 公開URLを取得しHTTP 200を確認する
- タイトルと主要本文を確認する
- canonicalとnoindexを確認する
- 内部リンク、CTA、画像など今回変更した要素を確認する
- 全項目PASSならreceiptを保存する
- FAILなら必要に応じてrollbackし、成功扱いにしない
この方式なら、自動投稿の目的が「WordPressへPOSTすること」から「安全な完成品を本番へ届けること」に変わります。
まとめ：自動投稿のゴールはAPI成功ではなく本番成功
WordPress REST APIとGitHub Actionsを使えば投稿処理そのものは自動化できます。しかし、長期運用で重要なのは公開後の状態を確認し、異常を成功扱いしない仕組みです。
HTTP、タイトル・本文、canonical、noindex、内部リンク・CTA、画像、rollbackという7項目を基準にproduction QAを作ると、APIだけを見ていたときより公開事故を検出しやすくなります。さらにキャッシュ再試行とreceiptを組み合わせれば、次の自動runでも「何が本当に本番で成功したか」を追跡できます。
これからWordPress自動化を組む場合は、生成や投稿処理より先に「失敗をどこで検知し、どう戻し、何を成功証拠として残すか」を設計してください。それが、記事数を増やすだけの自動化と、安心して回し続けられる運用システムの大きな違いです。
