WordPressの優先画像設定｜og:imageとschema.orgの整え方

WordPressでアイキャッチ画像を設定しているのに、検索結果やGoogle Discoverで意図した画像が出ないことはありませんか。2026年3月、Googleは「優先画像」の考え方を整理し、検索やDiscoverのサムネイル候補として schema.org と og:image を参照しうることを、これまで以上にわかりやすく示しました。

• 優先画像とは何か、Googleがどう画像を選んでいるのかがわかる
• WordPressで og:image・schema.org・max-image-preview:large をどう整えるべきかがわかる
• 意図通りに画像が出ないときの確認手順がわかる

本記事では、WordPressの優先画像設定について、og:image と schema.org を中心に、Discoverも含めた画像メタデータの整え方をわかりやすく解説します。（専門知識は不要です！）

注：設定を整えれば必ずその画像が表示される、という意味ではありません。Google側の画像選択は自動で行われ、クロールや再処理のタイムラグもあります。

優先画像とは何か｜2026年のGoogle公式情報を先に整理する

優先画像とは、Googleに「このページを代表する画像候補」を伝えるためのメタデータ上の指定です。

Googleは画像を手動ではなく自動で選んでいる

Googleの画像SEOベストプラクティスでは、検索結果画像やDiscoverのプレビュー画像を選ぶ処理は「完全に自動化されている」と案内されています。つまり、サイト運営者が「この画像を絶対に出せる」と確約できる仕組みではなく、Googleがページ内容やメタデータ、画像の関連性などを見て判断している、というのが前提です。

ここで大切なのは、「指定」よりも「伝える」という発想です。検索エンジンに対して、ページを代表する画像がどれかをわかりやすく示しておくほど、意図に近い選択をしてもらいやすくなります。

schema.org と og:image はどこで効くのか

Googleは同じ文書の中で、優先したい画像を伝えるメタデータソースとして、schema.org の primaryImageOfPage、または記事のメインエンティティに関連付けた image、そして og:image を例示しています。詳しくはGoogle公式の該当セクションで確認できます。

この整理が重要なのは、WordPress運用でありがちな「アイキャッチは設定しているのに、head内のタグや構造化データはバラバラ」という状態を見直すきっかけになるからです。画像そのものより、画像をどう説明しているかが問われる場面が増えています。

Discoverと通常検索では重なる部分と前提差がある

Google Discoverの公式文書によると、Discoverに表示されるために特別なタグや構造化データが必須というわけではありません。ただし、Discoverでは大きく見せやすい画像、つまり少なくとも幅1200px以上で、高解像度の画像が推奨されています。

通常検索でも画像の関連性は重要ですが、Discoverは視認性の影響がより大きいため、「ページを代表する画像を明確に伝えること」と「見せたときに強い画像を用意すること」の両方がより重要になります。

WordPressで最低限そろえる3つの設定

先に結論を書くと、WordPressではアイキャッチ設定だけで安心せず、次の3点をそろえておくと整理しやすくなります。ただし、これだけで十分という意味ではなく、画像そのものの関連性・サイズ・構図もあわせて整えることが大切です。

og:image でサムネイル候補を明示する

og:image はOpen Graphの代表的な画像タグで、WordPressでは多くのSEOプラグインやテーマが自動出力します。ただし、自動で出るから安心とは限りません。古いデフォルト画像、カテゴリの共通画像、ロゴ画像が優先されているケースもあります。

実際には、公開ページのHTMLソースを開いて、<meta property="og:image" ...> が意図したURLになっているかを見るのが早道です。画像URLは相対パスではなく、取得可能な絶対URLであることも確認しておきましょう。

<meta property="og:image" content="https://example.com/uploads/priority-image.jpg">

このようなタグが出ていれば、少なくとも候補画像の指定自体は確認しやすくなります。

schema.org で記事やページの代表画像を伝える

Google公式では、優先画像の伝え方として、WebPageの primaryImageOfPage や、BlogPostingなどのメインエンティティに関連付ける image が紹介されています。記事ページなら、まずはArticleまたはBlogPostingの image を整えておくのが基本です。

加えて、記事の構造化データではGoogleのArticle構造化データ文書が、16×9、4×3、1×1 の高解像度画像を推奨しています。ニュースサイトのように複数比率を厳密に用意する運用までは難しくても、少なくとも記事を代表する十分な解像度の画像を用意する意識は持っておきたいところです。

公開ソースで確認する際は、たとえば次のような JSON-LD（構造化データ）の image を探します。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "image": "https://example.com/uploads/priority-image.jpg"
}

max-image-preview:large で大きな画像プレビューを許可する

画像URLを示すだけでは足りません。大きな画像プレビューを許可する設定として、Google公式のrobotsメタタグ文書では、max-image-preview:large が案内されています。これを指定していない場合、Googleはデフォルトサイズの画像プレビューを表示する可能性があります。

Discoverを意識する記事では、head内に <meta name="robots" content="max-image-preview:large">、または同等の設定が出ているかも確認対象です。SEOプラグインで自動出力されている場合もありますが、テーマやキャッシュ設定の影響で想定どおりになっていないこともあります。

WordPressのアイキャッチ画像だけでは足りない理由

アイキャッチはWordPress内の管理情報であって、Google向けの説明そのものではない

WordPress公式のFeatured Images文書では、アイキャッチ画像は投稿や固定ページなどを表す画像として扱われています。ただし、それはあくまでWordPress内部の管理概念です。

Googleに対して画像の意図を伝えるうえで重要なのは、head内のメタタグやJSON-LD（構造化データ）でページ外部に出力された情報です。つまり、管理画面でアイキャッチを選んだだけでは、Google向けの優先画像設計が完了したとは言い切れません。

テーマやSEOプラグインが出力して初めて og:image や構造化データになる

WordPressでは、テーマ・SEOプラグイン・独自コードがそれぞれhead出力に関与できます。たとえば、テーマがOGPを出し、SEOプラグインがJSON-LDを出し、さらにfunctions.phpで独自タグを追加していると、意図しない競合が起きやすくなります。

このため、「アイキャッチを設定したのに画像が違う」という問題は、画像選択ミスだけではなく、出力レイヤーの重なりが原因であることも少なくありません。設定画面を見比べるより、まずソースを見るほうが早いケースが多いです。

複数の画像指定が競合すると意図がぶれやすい

たとえば、og:image は本文冒頭の画像、構造化データの image はアイキャッチ、さらにテーマ側でロゴ画像を別に出している、という状態では、「どれを代表画像として見せたいのか」が曖昧になります。

WordPress実務では、少なくとも og:image とArticleまたはBlogPostingの image は同じ画像URLにそろえ、必要があればWebPageの primaryImageOfPage も同系統で統一するほうが、判断材料を散らさずに済みます。

Discoverと検索で見られやすい画像の作り方

幅1200px以上・16:9を基本に考える

Discoverで使う画像を考えるなら、まずGoogle Discover公式文書の推奨を基準にしましょう。少なくとも幅1200px以上で、高解像度、さらに総画素数が300,000ピクセルを超える画像が推奨されています。

実務では、16:9の横長画像をベースにすると扱いやすくなります。たとえば1280×720なら921,600ピクセルなので、Discoverの推奨条件を満たしやすく、記事のアイキャッチとしても運用しやすいサイズです。

ロゴ・文字だらけ・極端な比率の画像を避ける

Googleの画像SEO文書では、優先画像として使う画像に、一般的な画像、たとえばサイトロゴや、テキストが多い画像は使わないよう案内しています。また、狭すぎる画像や広すぎる画像など、極端なアスペクト比も避けるべきとされています。

つまり、デザイン的にきれいでも、ロゴ中心のアイキャッチや、帯だけの横長画像は候補として弱くなりやすい、ということです。タイトル文字を大きく乗せたサムネイルを多用しているサイトは、この点を見直す余地があります。

切り抜かれても意味が残る構図にする

検索やDiscoverでは表示面ごとに見え方が変わるため、画像がそのまま等倍で出るとは限りません。重要な被写体やメインメッセージは中央寄りに配置し、上下左右が多少切れても意味が崩れにくい構図にしておくと安全です。

細かい文字情報で伝えるより、「何についての記事か」が視覚的に一目でわかる写真や図版のほうが、プレビュー画像としては安定しやすい傾向があります。画像SEOの基礎設計については、別記事の画像SEOの基本ポイントもあわせて確認してみてください。

テーマ・SEOプラグイン別に確認したい実装ポイント

まずは公開ページのソースで何が出ているかを見る

テーマやプラグインの設定画面を開く前に、対象ページの公開URLをブラウザで開き、ソース表示で og:image、application/ld+json、max-image-preview を検索してください。この順番にすると、何が起きているかを短時間で把握しやすくなります。

チェックしたいのは、「タグがあるか」ではなく、「意図した画像URLが出ているか」「同じタグが複数回出ていないか」「古い画像URLが残っていないか」です。キャッシュやCDNの影響で、設定変更後もしばらく古い出力が見えることもあります。

SEOプラグインの設定とテーマ出力が重なっていないか確認する

SEOプラグインを使っている場合、OGPや構造化データは多くのケースでプラグイン側が担います。一方で、テーマにも独自のOGP出力機能があると、同じ役割のタグが二重に出ることがあります。

プラグイン名が違っても、確認する論点は大きく変わりません。少なくとも「ソーシャル共有画像」「構造化データの画像」「robotsメタ」の3点が、同じ意図の画像を向いているかを見ておくと整理しやすくなります。

この場合は、どちらか一方に役割を寄せるほうが管理しやすくなります。テーマ設計から見直したい場合は、関連する基本論点としてSEOに強いテーマを選ぶ考え方も参考になります。

カスタムコードで上書きするのは最後の手段にする

どうしても必要な場合を除き、最初からfunctions.phpや独自プラグインで無理に上書きするのはおすすめしません。まずは既存のテーマ機能とSEOプラグイン設定でどこまで整えられるかを確認し、それでも不足がある場合だけ追加調整するほうが、更新時のトラブルを減らしやすいからです。

特にサイト運営人数が複数いる場合、出力の責任範囲が見えにくい状態は後から保守が難しくなります。「このタグはテーマ」「この構造化データはプラグイン」と整理しておくと、画像トラブルの切り分けも早くなります。

画像が意図通りに出ないときの確認手順

画像が出ない、別画像になる、古い画像が残る。こうしたときは、まず公開ソースで出力を確認し、その後にGoogle側の見え方を確かめる順で進めると、切り分けしやすくなります。

head内の og:image・JSON-LD・robotsメタを確認する

最初に確認するのは、ページのhead内です。ここで見たいのは、og:image が目的の画像か、ArticleやBlogPostingの image が一致しているか、そして max-image-preview:large が有効かどうかです。

もしここで画像URLが食い違っているなら、Googleの前に、まずサイト側の出力整理が必要です。逆にここがそろっていれば、「出力はできているので、反映待ちやGoogle側の選択の問題かもしれない」と切り分けられます。

Rich Results TestとURL検査でGoogle側の見え方を確かめる

構造化データ側は、Rich Results Testで確認するとわかりやすいです。ここではJSON-LD自体の有無や内容を把握しやすくなります。

あわせて、Search ConsoleのURL検査ツールも使いましょう。Google公式のデバッグ系ヘルプにもあるように、ライブURLで現在の取得状態を見たり、レンダリングや取得リソースを確認したりできます。Search Consoleの基本的な見方は、別記事のSearch Consoleで再クロールを確認する方法も役立ちます。

反映タイムラグを前提に再クロールまで見る

設定を直しても、その場ですぐ検索結果やDiscoverの見え方が変わるとは限りません。Googleは再クロールと再評価を経て表示を更新するため、数日単位で待つ必要があることもあります。

そのため、確認後の動きは「修正したら終わり」ではなく、「再クロール依頼を出す」「数日後にもう一度HTMLと検索結果を見直す」まで含めて考えるのが実務的です。特に画像だけ差し替えた場合は、キャッシュやCDNの残り方も合わせて確認しておくと安心です。

よくある質問（FAQ）