WordPress自動投稿後に公開URLとステータスを再確認する方法

2026年9月22日

【PR】この記事には広告リンクが含まれています。

WordPress REST APIへ投稿データを送り、GASの実行ログに「完了」と出ても、読者が見られる状態になったとは限りません。statusがdraftのまま、slugが変更されて別URLになった、本文が途中で欠けた、featured_mediaが0、カテゴリやタグが付いていない、といった不一致が残る可能性があります。

筆者の週4本運用では、処理関数が終了したことと、4記事の公開が完了したことを分けています。各記事について投稿ID、URL、公開状態、時刻、サムネイルを個別に確認し、1本でも未公開なら週全体を完了と報告しません。この記事では、POST直後のレスポンスだけに頼らず、同じ投稿を再取得して公開結果を照合する方法を整理します。

結論：POST、GET、公開URLの3段階で確認する

完了判定は、作成・更新リクエストのレスポンス、投稿IDを指定したGET、公開URLへのアクセスという3段階に分けます。POSTはWordPressがリクエストを受け付けた結果、GETは保存された投稿データ、公開URLは読者から見える結果を確認するものです。

三つを同じ記事IDで記録し、予定値と一致した場合だけ成功にします。どこかが不一致なら、公開済みと偽らず工程別のエラーとして残します。通信の一時障害なら限定再試行し、slugや本文の不一致なら入力や更新処理を直します。

POSTレスポンス：投稿IDと返却値を確認
GET再取得：status・slug・本文・画像を照合
公開URL：HTTP 200と実表示を確認

【実体験】実行ログの成功表示を完了条件から外した

筆者の運用では、週次関数が終了しても公開対象が見つからない場合は、公開本数は増えません。また、途中工程が止まっても、エラー記録の仕方によっては全体関数が終了します。そのため「関数が例外なく終わった」ことを週4本の成功条件にしないよう変更しました。

現在は、全記事のURL、公開状態、時刻、サムネイルを個別確認します。記事マスター、WordPress下書き、処理キュー、実行ログの記録が一致し、公開ページを確認できたときに完了とします。この運用は、公開されていない記事を成功扱いしないための最低条件です。

WordPress Posts APIで再取得できる主な項目

WordPress公式のPosts APIでは、個別投稿をGET /wp/v2/posts/<id>で取得できます。公開確認ではid、date、modified、slug、status、link、title、content、featured_media、categories、tagsなどを使います。認証済みのeditコンテキストでは、公開画面だけでは分からない情報も確認できます。

返却項目を減らす場合は_fieldsを使えますが、最初から絞りすぎると必要な不一致を見落とします。運用開始時は確認項目を広めにし、安定後に必要な項目だけへ絞ります。

statusは文字列publishと完全一致させる

投稿ステータスにはpublish、future、draft、pending、privateなどがあります。公開予定の記事なら、再取得したstatusがpublishであることを完全一致で確認します。値が存在するだけ、draft以外、真偽値がtrueといった曖昧な判定にしません。

予約投稿を扱う場合はfutureが正しいこともありますが、週次の即時公開と同じ判定へ混ぜないようにします。公開経路ごとに期待ステータスを設定し、今回の処理ではpublishのみを合格とします。

slugとlinkを予定値へ照合する

slugは投稿タイプ内で一意な英数字識別子です。同じslugが既にあると、WordPressが末尾へ数字を付けるなど、予定外のURLになることがあります。投稿前に既存slugを検索し、投稿後は返却slugが予定値と一致するかを確認します。

linkは自ドメインで、予定slugを含み、不要なリダイレクトがないことを確認します。管理表にはAPIから返ったURLを記録し、手入力で推測したURLを使いません。再実行時はslug検索または投稿IDを使い、既存投稿を更新します。

タイトルと本文は保存後の値を比較する

REST APIのcontentはオブジェクトとして返り、公開用HTMLはcontent.renderedで確認できます。送信前HTMLとWordPress保存後HTMLは、ブロック変換、ショートコード、テーマ・プラグイン処理で完全な文字列一致にならない場合があります。

そのため、記事ID、主要見出し、PR表記、CTA、内部リンク、広告URL、計測ピクセルなど、消えてはいけない要素を確認します。本文が空、途中で切れている、HTMLがエスケープされたまま表示される、といった状態を重大エラーにします。タイトルもrendered値と予定値を正規化して比較します。

featured_mediaは0以外だけで終わらせない

featured_mediaにはメディアIDが入ります。0ならアイキャッチ未設定です。ただし0以外でも、別記事の画像、古い画像、alt未設定の可能性があります。メディアAPIで該当IDを取得し、ファイル名、mime_type、source_url、alt_textを予定値と照合します。

公開ページでは、一覧と記事上部で画像が実際に表示されるかを見ます。API上のIDが正しくても、キャッシュ、画像変換、テーマ設定で見え方が異なるためです。文字切れや内容不一致は機械判定だけで拾いにくく、目視確認を残します。

カテゴリとタグのIDを照合する

Posts APIではcategoriesとtagsがID配列で返ります。予定カテゴリ・タグ名をWordPress側のIDへ変換し、投稿後の配列に必要なIDが含まれるかを確認します。名前を本文へ書いただけではタクソノミー設定になりません。

カテゴリが未設定だと「未分類」へ入る場合があります。運用上必要なカテゴリが1件、タグが指定数あるかを確認し、重複や意図しないタグを増やさないようにします。

SEO・OGはプラグインの保存先を確認する

SEOタイトル、メタディスクリプション、OGタイトル、OG説明、OG画像は、利用中のSEOプラグインやテーマによって保存方法が異なります。標準Posts APIのtitleやexcerptだけで全項目を確認できない場合があります。

運用中のサイトでREST APIへ公開されているメタ項目を確認し、取得できない場合は公開HTMLのmetaタグを確認します。投稿本文と同様に、管理表の予定値と公開ページの実値を比較します。プラグイン名やメタキーを推測で決めません。

公開URLのHTTP 200を確認する

APIでpublishでも、公開URLが404、403、5xxになる可能性があります。UrlFetchApp.fetchでURLへアクセスし、レスポンスコードを確認します。リダイレクトを追う設定の場合は最終URLも確認し、予定外のページへ移動していないかを見ます。

HTTP 200だけで完全な成功とは判断しません。WordPressテーマが404ページを200で返す構成や、トップページへ転送する構成もあり得るため、タイトルや記事固有の本文断片を確認します。サイト障害の5xxは間隔を置いて限定再試行します。

GASでの確認処理例

GASではUrlFetchAppで個別投稿エンドポイントを取得し、レスポンスコードを確認してからJSONを解析します。認証情報はスクリプトプロパティ等で管理し、ログやスプレッドシートへ保存しません。以下は考え方を示す骨組みであり、実際の認証方法やサイトURLへ合わせて調整します。

function verifyPost(postId, expected) {
  const response = UrlFetchApp.fetch(
    expected.apiBase + '/wp/v2/posts/' + postId,
    { headers: expected.headers, muteHttpExceptions: true }
  );
  if (response.getResponseCode() !== 200) {
    throw new Error('投稿再取得に失敗');
  }
  const post = JSON.parse(response.getContentText());
  if (post.status !== 'publish') throw new Error('status不一致');
  if (post.slug !== expected.slug) throw new Error('slug不一致');
  if (!post.featured_media) throw new Error('アイキャッチ未設定');
  return post;
}

本文ハッシュと必須要素で差分を検知する

HTMLの完全一致が不安定な場合は、送信前後のHTMLを同じ方法で正規化してハッシュ比較する方法があります。ただしWordPress側の正当な変換まで差分になるため、運用環境で確認してから使います。

別案として、記事ID、PR表記、主要見出し、内部リンク、広告URL、画像、FAQ、まとめなど、必須要素の存在を検査します。何を保証する検査かを明示し、完全一致と要素検査を目的に応じて使い分けます。

実行ログと管理表へ記録する項目

確認結果は、記事ID、投稿ID、予定slug、実slug、URL、status、featured_media、確認時刻、HTTPコード、検査結果、エラー工程を記録します。成功時だけでなく失敗時も同じ形式にすると、再実行対象を抽出しやすくなります。

記事マスター、WordPress下書き、記事生成管理、最終確認、処理キュー、実行ログで記事IDを共通キーにします。公開後に一部だけ更新されると、翌週の選定で重複するため、検証合格後に関連表をまとめて同期します。

記事ID・投稿ID・slug・URL
status・featured_media・カテゴリ・タグ
本文必須要素・PR・広告・内部リンク
公開URLのHTTPコードと確認時刻
成功・失敗・ブロック理由・再試行回数

失敗原因別の復旧方法

statusがdraftなら公開権限や送信値を確認し、対象投稿IDを更新します。slug不一致なら重複投稿を探し、既存投稿を統合または正しいslugへ更新します。featured_mediaが0なら画像アップロード結果と投稿更新を確認します。本文不足なら送信サイズ、HTML、レスポンスを確認します。

403は認証、REST API制限、WAF・セキュリティ設定を確認します。筆者がエックスサーバー環境で経験したアクセス拒否エラーの原因はREST APIのアクセス拒否エラーを直した方法にまとめています。5xxは一時障害の可能性があるため、間隔を置き失敗記事だけ再試行します。

公開後確認チェックリスト

週4本の運用では、4本の行を並べて個別に確認すると、対象なしの処理や一部成功を週完了と誤認しにくくなります。

投稿IDが発行され、予定記事IDへ紐付いている
statusがpublish
slugが予定値と一致
linkが自ドメインの公開URL
タイトルと本文必須要素が存在
featured_mediaとaltが一致
カテゴリ・タグ・SEO・OGが一致
公開URLがHTTP 200で記事本文を表示

公開前の期待値を保存する

投稿後に正しいか判断するには、投稿前の期待値が必要です。記事ID、タイトル、slug、本文の必須要素、メタディスクリプション、カテゴリ、タグ、画像ファイル、alt、広告URL、内部リンクを一つの検証オブジェクトへまとめます。

WordPressから返った値だけを見て「値が入っているから成功」と判断せず、期待値との比較にします。期待値は公開直前に確定し、その後に原稿が変更された場合はバージョンや更新日時を変えます。古い期待値で新しい本文を検査しないようにします。

POSTレスポンスを安全に読む

UrlFetchAppのレスポンスコードを先に確認し、Content-Typeや本文先頭を見てJSONかを判定します。WAFや認証画面のHTMLをJSON.parseすると、本来のサーバーエラーが構文エラーに置き換わり、原因が分かりにくくなります。

成功レスポンスでもid、status、slug、linkが欠けていれば、その時点で検証エラーにします。レスポンス全文を機密情報と一緒にログへ残さず、必要項目とエラー要約だけを記録します。

投稿IDを最優先の照合キーにする

slugは変更でき、タイトルは重複できますが、投稿IDはWordPress内で投稿を識別します。作成レスポンスで投稿IDを得たら、記事マスターとWordPress下書きへ一時保存し、以降の再取得と更新に使います。

投稿ID保存前に処理が中断した場合はslug検索で候補を探し、タイトル、日付、記事固有の本文を照合して同一投稿かを確認します。検索結果が複数、または別記事の可能性がある場合は自動更新を止めます。

公開日時と更新日時を確認する

dateはサイトのタイムゾーン、date_gmtはUTCを表します。週次公開本数を数えるとき、GAS側のUTC日付とWordPress側の日本時間を混同すると、深夜付近の投稿が別週に入る可能性があります。サイトのタイムゾーンを確認し、基準日を統一します。

modifiedが公開直後に変わっている場合は、プラグインや追加更新が動いた可能性があります。予定した変更なら問題ありませんが、本文やslugが変わった場合は再検証します。管理表の公開日はAPIのdateを基準に記録します。

公開URLの本文を軽量に確認する

公開ページ全体を毎回詳細解析すると処理時間が増えます。まずHTTPコード、最終URL、title要素、記事固有の見出し、本文の短い識別文字列、画像URLを確認します。これでトップページ転送や空本文を検知しやすくなります。

JavaScriptで後から描画される要素はUrlFetchAppだけでは確認できない場合がありますが、WordPressの通常記事本文はサーバーHTMLに含まれることが多いです。テーマやキャッシュ構成に合わせ、読者が見る重要要素を検査します。

キャッシュを考慮して再確認する

投稿更新直後は、キャッシュに古いタイトルや画像が残る場合があります。API値が正しく、公開ページだけ古い場合は、短い待機後に対象URLを限定再取得します。何度も全記事を更新し直すのではなく、表示確認だけを再試行します。

キャッシュ削除を自動化する場合は、サイト全体へ影響しない範囲を選びます。原因が画像CDNやOGキャッシュにある場合、本文公開自体とは別の警告として扱い、SNS共有前に再確認します。

広告と内部リンクを公開HTMLでも検査する

送信前HTMLにrel=”sponsored nofollow”があっても、エディターやフィルターで属性が変わる可能性があります。公開後のcontent.renderedまたはページHTMLから広告URL、rel属性、計測ピクセルを確認します。PR表記が導入の早い位置に残っているかも見ます。

内部リンクはhrefが正しいだけでなく、リンク先がHTTP 200で公開済みかを確認します。同週の未公開記事へ先にリンクしていないか、slug変更で旧URLになっていないかを検査します。

SEO・OGの公開HTML確認

SEOプラグインのメタをREST APIで取得できない場合、公開HTMLのtitle、meta name=”description”、link rel=”canonical”、og:title、og:description、og:imageを確認します。canonicalが別URL、OG画像が既定画像のままなら、検索結果やSNS表示に影響します。

SEOタイトルと記事タイトルを意図的に変える場合は、それぞれの期待値を持ちます。空でないことだけではなく、予定文と一致するか、長すぎて主要語が欠けていないかを確認します。

カテゴリ・タグ・画像の関連APIを使う

投稿レスポンスのカテゴリ・タグはIDなので、用語APIから名前とslugを確認できます。メディアはMedia APIでalt_text、caption、source_url、media_detailsを確認します。複数APIを呼ぶときも、記事IDと投稿IDの対応を維持します。

メディアIDが別記事と共有される設計も可能ですが、記事ごとに専用画像を使う運用なら、期待したDrive画像からアップロードされたファイルかをファイル名等で確認します。画像の縦横比もメタ情報から確認できます。

検証の再試行回数を制限する

公開確認が失敗したとき、無限ループで再取得すると実行時間やクォータを消費します。一時的な5xxやキャッシュなら待機して限定再試行し、同じ不一致が続く場合はブロックします。現行運用では失敗記事だけを最大2回まで再実行します。

400系や内容不一致は、待つだけでは直らないため修正後に再検査します。再試行回数、前回エラー、変更点をログへ残し、同じリクエストを繰り返していないか確認します。

公開確認関数を投稿関数から分ける

投稿関数の戻り値だけで合格を決めると、検証ロジックを単独テストできません。verifyPost関数を分け、投稿IDと期待値を渡せば、手動公開や既存投稿にも同じ検査を使えるようにします。

週次処理はpublishOneArticleの後にverifyPostを呼び、検証結果を受けて管理表を更新します。検証だけを再実行できれば、公開済み本文を不必要に再送せず、キャッシュや一時通信の確認を行えます。

本数判定は公開日と実データから行う

週の開始時には、WordPressの公開投稿と記事マスター、WordPress下書き、処理キュー、実行ログを照合します。実行ログに成功があっても、公開投稿がなければ公開済み本数へ数えません。反対にWordPressへ公開済みでシート未反映なら、二重作成せず管理表を復旧します。

対象週で4本未満なら差分を不足本数とし、既存の公開可能記事を使い、足りなければ計画から補充します。過去週が4本確認済みなら再公開せず、次の未完了週へ進みます。

よくある質問

Q. POSTが201なら公開成功ですか？
作成レスポンスの成功を示しますが、期待するstatus、slug、本文、画像、公開URLまで再確認します。

Q. publicなREST APIでstatusは確認できますか？
公開投稿は取得できますが、必要項目や下書き確認には認証やcontextが関係します。サイト設定に合わせます。

Q. HTTP 200なら十分ですか？
記事固有のタイトルや本文も確認します。別ページやエラーテンプレートが200を返す可能性があります。

Q. 4本中3本が公開なら今週分完了ですか？
いいえ。週4本が目標なら不足1本として扱い、失敗記事を復旧または別候補で補充します。

WordPressの運用基盤を整える

自動投稿では、REST APIへの到達性、画像アップロード、公開ページの安定表示まで含めて確認できるサーバー環境が必要です。筆者が実際に使っているエックスサーバーの内容は、公式ページで確認できます。

エックスサーバーの公式情報を確認する

確認した公式情報

制度や仕様は変更される可能性があるため、2026年9月19日に以下の現行ページを確認しました。

まとめ

WordPress自動投稿の完了判定は、GASの実行終了やPOSTレスポンスだけでは不十分です。同じ投稿IDをGETし、status=publish、slug、link、本文、featured_media、カテゴリ、タグ、SEO・OGを予定値へ照合します。最後に公開URLのHTTP 200と記事固有の表示を確認します。

筆者の運用では、4記事すべてを個別確認し、1本でも未公開なら週全体を完了としません。公開結果を記事IDで各管理表へ同期し、失敗記事だけを限定再実行することで、二重投稿を避けながら確実な週次運用へ近づけられます。