【PR】この記事には広告リンクが含まれています。
WordPressの自動投稿では、画像をアップロードできたことと、記事のアイキャッチとして正しく表示されたことは別です。メディアのalt_text、投稿のfeatured_media、テーマやSEO機能が出力するOG画像、記事一覧と本文の表示を順に確認する必要があります。
運営者の公開後確認では、4本中3本のアイキャッチに文字被りや旧デザインの問題があり、差し替え対象になりました。この実体験を基に、画像を作る工程ではなく、記事との対応、代替テキスト、公開後表示を一致させる自動化へ焦点を当てます。
最初に確認したい結論
- 画像アップロード後に返るメディアIDを記事IDへ保存する
- Media REST APIでalt_textを設定し、再取得して確認する
- Posts REST APIのfeatured_mediaへ正しいメディアIDを設定する
- OG画像はテーマ・SEO機能の実出力を別途確認する
- 記事一覧・本文・SNS共有プレビューの役割を分けて検査する
- 公開後に画像URL、alt、比率、文字欠け、内容一致を目視確認する
altとアイキャッチは別の情報
WordPress REST APIでは、メディア項目にalt_textがあり、投稿項目にはfeatured_mediaがあります。altを設定しても自動的に投稿のアイキャッチになるわけではなく、featured_mediaへメディアIDを指定する必要があります。
反対にfeatured_mediaを設定しても、メディアのalt_textが空なら代替テキストは整いません。画像アップロード、alt設定、投稿への関連付けを別ステップとして記録します。
記事IDとメディアIDを対応させる
複数記事を連続処理すると、アップロード順だけで画像を対応させる設計は危険です。記事ID、画像ファイル名、メディアID、source_url、altを一つのレコードへ保存します。
次の画像が先にアップロードされたり、一件だけ失敗したりしても、配列の位置ではなく記事IDで対応付けます。再実行時は既存メディアを検索し、同じ画像を無条件に重複登録しません。
altは画像の役割を説明する
altは画像が表示されない場合の代替テキストです。記事タイトルを機械的に詰め込むのではなく、その画像が記事内で何を表しているかを短く説明します。
装飾だけの画像と、内容を伝えるアイキャッチでは役割が異なります。サイトのアクセシビリティ方針と画像の用途を確認し、キーワードの羅列にしません。
featured_mediaを再取得する
投稿作成時にfeatured_mediaを送信しても、レスポンスだけで完了としません。投稿IDを指定して再取得し、返ったfeatured_mediaが予定したメディアIDと一致するか確認します。
0や別IDなら公開完了にしません。投稿がpublishでもアイキャッチ設定は別の品質条件として扱い、失敗した記事だけを修正します。
OG画像は実出力を見る
OG画像はテーマやSEOプラグインの設定によって生成され、WordPress標準のfeatured_mediaと常に同じになるとは限りません。REST APIの投稿項目だけで一致を断定しません。
公開ページのHTMLに出力されたOGメタ情報を確認し、期待した画像URLかを見ます。キャッシュがある場合は更新後の反映時刻を記録し、一時的な差と設定ミスを分けます。
16:9と安全余白を確認する
このブログの差し替え用アイキャッチは16:9を基準にし、スマートフォン一覧でも読める大きな日本語、強いコントラスト、十分な安全余白を求めます。
画像ファイルが16:9でも、テーマ側のトリミングで端の文字が切れる可能性があります。中央寄せだけに頼らず、実際の一覧・本文・OG表示で主役と文字を確認します。
文字被りを自動判定だけに任せない
画像生成やテンプレート配置で文字領域と主役ビジュアルが重なる場合があります。ファイルサイズやaltが正しくても、クリックしたい見た目にはなりません。
公開後は人が4枚を目視し、文字の正確さ、欠け、端切れ、意味不明な文字、大きな空白、記事内容との一致を確認します。目視結果を最終確認へ戻します。
本文画像とアイキャッチを混同しない
本文内に同じ画像を置く場合でも、投稿のfeatured_mediaとは別のHTML要素です。本文画像が表示されているからアイキャッチも設定済みとは判断しません。
一覧、記事上部、SNS共有など表示場所ごとに取得元が異なる可能性を考えます。検査項目へ、メディア、投稿、本文、OG、実画面の五つを分けて持ちます。
差し替え時に同じ投稿を更新する
強化版アイキャッチを作る場合も、新しい記事を作成しません。同じ記事IDと投稿IDを維持し、画像だけを安全に差し替えます。
差し替え前のメディアIDと画像URLを記録し、更新後のfeatured_media、alt、OG、表示を確認します。途中で失敗した場合に元へ戻せる情報を残します。
公開後確認を完了条件にする
画像アップロード成功、メディア作成成功、投稿更新成功は中間状態です。公開URLのHTTP 200、status=publish、本文、slug、featured_media、実表示が揃って初めて完了です。
4本のうち1本でも確認できなければ、4本完了とは報告しません。画像だけの失敗で本文を作り直さず、対象記事IDの画像工程だけを再実行します。
公開前に確認したい実務ポイント
ファイル名を記事IDへ結び付ける
似たタイトルの画像を連続生成すると取り違えやすくなります。
記事IDとslugを含む管理用ファイル名を使い、表示用altとは分けます。
アップロード後にメディアIDとsource_urlを台帳へ戻します。
altを再取得する
更新リクエストが成功しても、保存値を確認しなければ確定できません。
Media APIで対象IDを再取得し、alt_textを比較します。
空白や別記事の文言なら公開完了にしません。
画像比率を検査する
縦横サイズが想定と違うと、一覧やOGでトリミングが崩れます。
media_detailsまたは画像情報で幅と高さを確認します。
比率だけでなく、960×540相当で使える解像感を目視します。
代替テキストをタイトル全文にしない
長い記事タイトルをそのまま入れると、画像の説明として冗長になることがあります。
画像の主役と目的を短く表現します。
記事ごとの違いが分かり、同じaltの使い回しにならないようにします。
OGキャッシュを区別する
差し替え直後はSNSやキャッシュで旧画像が残る場合があります。
公開HTMLのOG URLと画像本体を確認し、キャッシュの更新範囲を分けます。
反映待ちと設定不備を同じエラーにしません。
文字の正確さを見る
画像内日本語は誤字や意味不明な文字が発生する可能性があります。
見出しと補助文を一文字ずつ確認します。
不正確な画像は提出せず、生成し直します。
小さい一覧で確認する
大画面では読めても、スマートフォンのカードでは文字が小さくなります。
実際の一覧相当サイズへ縮小して主見出しが読めるか確認します。
補助文を増やし過ぎず、主役ビジュアルを一つに絞ります。
安全余白を確保する
テーマやSNSが周囲を切り取ると、端の文字やロゴが欠けます。
重要要素を内側へ置き、四辺の余白を目視します。
同じテンプレートの大きな空白を使い回さず、記事に合う構図を作ります。
個人情報を画像へ入れない
会計画面や管理表のスクリーンショットには氏名や口座情報が含まれる場合があります。
実データを使うなら不要情報を除き、生成ビジュアルでは個人名・住所を入れません。
会社名を使う場合も記事の説明に必要な範囲へ限定します。
差し替え後の表示を記録する
更新した事実だけでは、どこで何が表示されたか分かりません。
記事URL、メディアID、画像URL、alt、OG、確認日時を残します。
本文表示と一覧表示の両方が一致してから完了にします。
運用を安定させる追加手順
画像アップロードの前処理
アップロード前に画像の縦横比、幅、高さ、ファイル形式、容量、記事ID、予定altを確認します。16:9の比率だけでなく、スマートフォン一覧へ縮小したときに主見出しが読めるかを確認します。
画像内文字は長い記事タイトルをそのまま詰め込まず、検索意図を保った短い見出しと補助文へ分けます。主役ビジュアルと文字領域が重ならない構図を選び、四辺に安全余白を確保します。
メディア作成レスポンスの保存
Media APIで画像を作成したら、返されたid、source_url、mime_type、media_detailsを記事IDへ保存します。HTTP成功だけでなく、media_typeがimageで、想定したファイルの寸法が返っていることを確認します。
同じ記事の再実行では、既存メディアIDと画像URLを確認します。アップロードが成功しているのに管理表更新だけ失敗した場合、新しい画像を追加せず、既存メディアを回収して続きを実行します。
alt_textの更新と再取得
メディア作成後にalt_textを設定し、同じメディアIDをGETして保存値を確認します。リクエストへ送った文字列ではなく、WordPressに保存された値を合格判定へ使います。
altは画像が示す内容を短く説明し、記事タイトル、キーワード、CTAを無理に詰め込みません。四記事で同じ定型文を使い回さず、主役ビジュアルと記事の違いが分かる文にします。
投稿へのfeatured_media設定
投稿作成または更新時にfeatured_mediaへメディアIDを送ります。本文HTMLへ画像を置いただけでは投稿サムネイルにならないため、投稿レコードのfeatured_mediaを別に確認します。
更新後は投稿IDを指定して再取得し、featured_mediaの値が予定IDと一致するか見ます。statusがpublishでも、0や別IDなら画像工程は未完了として記事ID単位で修正します。
OG画像の確認手順
公開ページのHTMLからOG画像メタ情報を確認し、期待した画像URLと比較します。テーマやSEO機能が別の既定画像を使う場合があるため、featured_mediaの一致だけでOGまで正しいと断定しません。
差し替え直後はキャッシュの影響も考え、確認時刻と取得したURLを記録します。キャッシュ更新後も違う画像なら、テーマ・SEO設定の優先順位を確認し、記事本文を作り直さず設定部分だけを修正します。
実画面の目視確認
記事一覧、記事上部、スマートフォン表示を確認し、文字欠け、端切れ、小さすぎる文字、意味不明な文字、大きな空白、記事との不一致を点検します。画像が表示されるだけでは合格にしません。
複数記事で同じチェックリスト画像やベージュの簡素なテンプレートを使い回さず、記事ごとに主役を変えます。視認性と内容一致を優先し、装飾の多さだけでクリックされると断定しません。
差し替えのバックアップ
既存記事の画像を差し替える前に、現在のfeatured_media、画像URL、alt、OG URLを記録します。新画像の設定途中で失敗しても、元の公開記事を壊さず戻せる状態を作ります。
差し替え後は同じ投稿ID、slug、公開URLを維持します。新記事や重複投稿を作らず、画像だけを更新した履歴と確認結果を記事マスター・最終確認へ戻します。
4本分の完了判定
週の4記事では、各記事についてstatus=publish、slug、公開URL、本文、featured_media、HTTP 200を個別確認します。4本目が未確認なら、先の3本が正常でも4本完了と報告しません。
4本の公開確認後に強化版アイキャッチを生成し、同じ週に提出済みなら重複生成しません。画像はWordPressへ自動差し替えせず、ユーザーが手動で選べる状態で提出します。
チェック項目を管理表へ落とし込む方法
1. 画像アップロード後に返るメディアIDを記事IDへ保存する
この項目では「画像アップロード後に返るメディアIDを記事IDへ保存する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
2. Media REST APIでalt_textを設定し、再取得して確認する
この項目では「Media REST APIでalt_textを設定し、再取得して確認する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
3. Posts REST APIのfeatured_mediaへ正しいメディアIDを設定する
この項目では「Posts REST APIのfeatured_mediaへ正しいメディアIDを設定する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
4. OG画像はテーマ・SEO機能の実出力を別途確認する
この項目では「OG画像はテーマ・SEO機能の実出力を別途確認する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
5. 記事一覧・本文・SNS共有プレビューの役割を分けて検査する
この項目では「記事一覧・本文・SNS共有プレビューの役割を分けて検査する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
6. 公開後に画像URL、alt、比率、文字欠け、内容一致を目視確認する
この項目では「公開後に画像URL、alt、比率、文字欠け、内容一致を目視確認する」を確認対象として独立させます。作業者の記憶や前回の成功表示に頼らず、対象記事ID、確認に使った原資料または公式ページ、確認日時を同じ行へ記録します。別の工程が合格していても、この項目の証拠がなければ完了へ進めません。
作業前には、管理表に保存された値と実サービスから取得した現在値を並べます。タイトルや表示文だけで同一と判断せず、ID、URL、日付、状態、対応する証拠を確認します。将来の予定や推測値は実績列へ入れず、確認できない内容は未確認として残します。
作業後には同じ取得経路でもう一度読み、更新した値が保存されているかを確かめます。書き込み処理の成功、画面の表示、公開後の取得結果を分けて記録すると、途中で失敗してもどの工程から再開すべきか判断できます。
差異が見つかった場合は、事実を変える大きな修正をせず、原因になった記事IDと項目だけを安全に直します。一時的な通信失敗は限定再試行し、認証、権限、事実関係を確定できない問題は公開を止めます。正常な他の記事や確認済みのデータはそのまま維持します。
関連記事
複数記事の画像工程を記事ID単位で扱う設計は4記事連続公開の失敗分離、公開後検証はWordPress公開状態の再確認、品質ゲートは自動投稿の品質ゲート設計で解説しています。
WordPress運用の土台を確認する
内部リンク、画像、広告コードを正しく管理しても、公開先のWordPressが安定して動かなければ運用は続きません。運営者が利用しているエックスサーバーについて、現在のプランと仕様は申込み前に公式ページで確認してください。
確認した公式情報
画面や仕様は変更される可能性があるため、2026年10月10日に次の現行ページを確認しました。
- WordPress.org：Media REST API
- WordPress.org：Posts REST API
- WordPress.org：Featured Images & Post Thumbnails
まとめ
WordPressアイキャッチのaltを自動設定｜画像・OG・本文表示を一致させる方法で大切なのは、画面上の成功表示だけで処理を終えず、原資料または公式仕様、管理表、WordPressに保存された状態、公開後の実表示を同じ記事IDで照合することです。
未確認の数字や体験を足さず、失敗した工程だけを記事ID単位で直します。変更履歴と確認日を残しておけば、次回の更新やリライトでも同じ基準を再利用できます。
