言語

Open Graph タグ: ランキング要因ではないが、SEO の成果物ではある

Open Graph タグとは何か、なぜ Google のランキング要因ではないのか、Google が og:title/og:image/og:site_name を実際にどう扱うか、プラットフォームごとの og:image サイズの公式情報、プラットフォームごとのフォールバックとキャッシュの挙動、そして再スクレイピングを強制する方法。

初回公開：2026年7月2日 · 最終更新：2026年8月13日 · Advanced
言語
AI執筆者：AI v2

Open Graph (OG) タグは、head 内の <meta> 要素で、Open Graph プロトコル (Facebook が開発した ogp.me) に基づき、ページを共有可能なオブジェクトとして記述します。必須プロパティは og:title、og:type、og:image、og:url の4つで、任意で og:description、og:site_name、og:locale、og:image:alt を追加します。主な役割は、URL が Facebook、LinkedIn、Slack、Discord、WhatsApp、iMessage で共有されたときに表示されるリンクプレビューカードです。つまり、CTR に影響する要素であり、ランキング要因ではありません。ただし、Google はこれらを読み取ります: og:title は SERP のタイトルリンクに使用できるソースの1つとして挙げられ (2024年8月追加)、og:image は Google 検索と Discover の自動画像サムネイル選択への入力として文書化されており、og:site_name は検索結果に表示されるサイト名への優先度の低い入力です。ただし、これらの値がそのまま使用される保証はありません。実務上の要点: og:image は絶対 URL と文書化された代替説明が必要です。各プラットフォームは独自のサイズガイドラインを公開しています (LinkedIn: 最小 1200×627、1,91:1; Google Discover: 幅 1200px 以上、16:9)。普遍的なサイズはありませんが、1200×630 (1,91:1) が長年のクロスプラットフォーム慣行です。タグが欠落すると、プレビューは空白ではなく制御不能になります。すべてのプラットフォームがスクレイピング結果をキャッシュするため、タグを編集しても既に共有されたリンクは修正されません。Facebook Sharing Debugger または LinkedIn Post Inspector で再スクレイピングを強制してください。ほとんどのソーシャルクローラーは JavaScript を実行しないため、タグはサーバーサイドレンダリングされた HTML に含める必要があります。

TL;DR — Open Graph タグは、Open Graph プロトコル（ogp.me、Facebook が作成）の <head> 内の <meta> 要素で、ページを 共有可能なオブジェクトとして記述します。必須: og:title、og:type、og:image、og:url。一般的な 任意項目: og:description、og:site_name、og:locale、og:image:alt。 繰り返されるプロパティは配列を形成し、競合時には最初のタグが優先されます。これらは ランキング要因ではありません — ソーシャル/チャットアプリのリンクプレビュー（Facebook、LinkedIn、Slack、Discord、WhatsApp、iMessage）の 表示 レイヤーです。検索エンジンの 処理は別であり、Open Graph の有効性から推測すべきではありません。プロトコル 自体は og:image のピクセル寸法を設定しません — 各コンシューマーが独自のサイズを公開します （LinkedIn、Google Discover）— そのため、サポートするプラットフォームに合わせたサイズの絶対 URL の og:image を提供してください。タグが欠落すると、制御不能な プレビュー（空白ではない）が生成されることを理解し、すべてのプラットフォームがスクレイプをキャッシュすることを覚えておいてください — タグを編集しても既に共有されたリンクは修正されないため、再スクレイプを強制してください。 ほとんどのソーシャルクローラーは JavaScript を実行しないため、タグは サーバーレンダリングされた HTML に含める必要があります。

Evidence for this claim The Open Graph protocol defines og:title, og:type, og:image, and og:url as basic metadata for representing a page as a graph object. Scope: Open Graph protocol vocabulary; platform rendering can vary. Confidence: high · Verified: Open Graph protocol Evidence for this claim Meta's sharing crawler uses server-rendered Open Graph metadata and provides Sharing Debugger tools to inspect and refresh scraped information. Scope: Meta/Facebook sharing behavior, distinct from search ranking. Confidence: high · Verified: Meta for Developers: Webmasters sharing guide

Open Graph タグの実際の意味

Open Graph タグは、ページの <head> 内の <meta> 要素であり、Open Graph プロトコル — Facebook が作成し、ogp.me で公開している仕様 — によって定義されています。このプロトコルの前提は、Web ページを、小さく一貫したプロパティの語彙を持つリッチな「オブジェクト」に変換できるため、どのプラットフォームでも同じタグから同じプレビューを構築できるというものです。Google 自身の開発者向け解説では、その起源を明確に述べています。Open Graph プロトコルは、「Facebook が Web ページを他の Facebook オブジェクトと同じ機能を持つようにするために必要なメタデータを提供する」 と、web.dev のソーシャルディスカバリー記事 に記載されています。

仕様では、4 つのプロパティが必須とされています — og:title、og:type、og:image、og:url — そして、通常追加するのは og:description、og:site_name、og:locale に加えて、og:image:width、og:image:height、og:image:alt などの構造化サブプロパティです（仕様自身のガイダンス: og:image を指定するページは og:image:alt も指定すべきです）。

繰り返されるタグと構造化プロパティには特定のルールがあります。 プロトコルでは、複数のオブジェクト（たとえば、複数の候補画像）を記述するためにルートプロパティを繰り返すことができます — コンシューマーが同じプロパティに対して競合する値を検出した場合、ドキュメント順で 最初 のタグが優先されます。og:image:width のような構造化サブプロパティは、その直前の og:image タグに適用され、ページ上のすべての画像には適用されないため、各画像の og:image とその構造化サブプロパティをソース順でグループ化してください。これは ogp.me 自体のプロトコルレベルの動作であり、プラットフォーム固有の癖ではありません。

覚えておいてほしい枠組み: これはソーシャル/チャットの表示レイヤーであり、タイトルタグ と メタディスクリプション で管理している SERP 表示レイヤーの兄弟です。同じ考え方 — ページの表示方法を制御する — ただし、異なる表面での話です。

主要な Open Graph タグを一つずつ

Google の web.dev の解説では、タグごとの目的がそれぞれ 1 行で説明されています: og:title は 「Web ページのタイトル」、og:description は 「Web ページの説明」、og:image は 「共有投稿に添付された画像の URL」、og:url は 「Web ページの正規 URL」、og:type は 「Web ページのタイプを示す文字列」 です（web.dev）。実際には:

  • og:title — カードの見出し。モバイル/デスクトップのカードに表示される内容にほぼ合わせてください。サイト名のブランディングを付けずに、生のタイトルを使用します。これはHTMLの<title>要素とは別ですが、Googleはタイトルリンクにどちらかを使用する場合があります（下記参照）。
  • og:description — カードの説明文。1〜2文程度。長いテキストはほとんどのプラットフォームで切り詰められます。
  • og:image — サムネイルであり、カードの成否を左右するプロパティです。絶対URL（https://…）である必要があります — 相対パスはクローラーに静かに無視されます。og:image:width/og:image:heightを追加して、画像の読み込みが完了する前にプラットフォームがカードをレイアウトできるようにし、og:image:altには実際の説明を追加してください — プロトコル自体がog:imageを指定する際にこれを推奨しています。
  • og:url — ページの正規URL（rel=canonicalと揃えて、シェアが1つのアドレスに集約されるようにします）。
  • og:type — オブジェクトタイプを宣言します。websiteがデフォルト（マークされていないページはすべてこれとして扱われます）。articleはarticle:author、article:published_time、article:sectionなどの追加プロパティを有効にします。他にもprofile、book、video.*、music.*タイプがあります。これはプラットフォームの機能に関係し、SEOに直接関係するものではありません。
  • og:site_name と og:locale — 任意ですが便利なペア。og:site_nameはページの背後にあるブランドを指定し、og:locale（デフォルトはen_US）はコンテンツがアメリカ英語でない場合にのみ必要です。

Open Graphタグはランキング要因ですか？いいえ — しかし、Googleがこれらをどう扱うかは次の通りです

OGタグがランキングに影響するという公式のGoogleソースはありません。OGタグは表示を制御し、順位は制御しません — これはJohn Muellerがメタディスクリプションについて述べたのとまったく同じ分類です：「主に検索結果ページのスニペットとして使用されます。そして、それはランキングには使用しないものです」（Search Engine Journalの記事経由）。Open Graphとランキングに特化した同等の公式発言をした指名されたGoogle担当者はいないため、私はそれをでっち上げません — 証拠は文書化されたメカニズムであり、そのメカニズムはすべて表示に関するものです。Google自身のドキュメントがOGタグを読み取ると述べている確認済みの場所は3つあります — そしてすべてのケースで、有効なマークアップはGoogleが参照する可能性のある1つの入力であり、特定の表示、特定のクロップ、またはランキングやトラフィックの結果を保証するものではありません。これらのドキュメントのいずれかに記載がないことは、Googleが他の場所でタグを無視している証拠にはなりません — これは「文書化されているもの」として扱い、Googleのシステムが触れる可能性のあるすべてのものの網羅的なリストとは見なさないでください。

og:titleをタイトルリンクのソースとして

2024年8月26日以降、Googleのドキュメントでは、結果のクリック可能な見出しであるタイトルリンクを自動生成するために使用できるソースの1つとして、「og:title metaタグ内のコンテンツ」が挙げられています。チェンジログの記述は直接的です：「Google検索は、og:title metaタグ内のコンテンツを使用してタイトルリンクを自動生成できます」（Search Centralチェンジログ）。これはGoogleがブレンドする約9つのソースの1つであり（タイトルリンクのドキュメント）、あなたのog:titleがそのまま使用されるという保証ではありません。

og:imageを画像サムネイルのソースとして

Googleの画像SEOのベストプラクティスには、「メタデータで優先画像を指定する」セクションがあり、検索で選ばれる画像に影響を与えるために使用できる2つのメタデータソースを挙げています。schema.orgのprimaryImageOfPage（またはメインエンティティ上の画像）、または 「og:image metaタグ」 です。Googleは、「Googleによる画像プレビューの選択は完全に自動化されている」 と明言し、「schema.orgマークアップやog:image metaタグで一般的な画像（例：サイトのロゴ）やテキストを含む画像を使用しないでください」 と警告しています。そのDiscoverドキュメントでは、Discover画像について同じ2つのオプションを挙げ、具体的なガイドラインを追加しています。幅1200px以上、総ピクセル数30万以上、アスペクト比16:9（独自の例では1280×720）— これは、以下のソーシャルカード画像で使われる1,91:1の慣例とは異なる比率であることに注意してください。そのため、ソーシャル共有用にサイズ設定された単一の画像は、自動的にDiscoverの推奨クロップにはなりません。

業界紙（Search Engine Land、Search Engine Journal、Search Engine Roundtable）は、2026年3月初旬頃にこのImages/Discoverドキュメントを新しいものとして取り上げ、og:imageの役割がAI Overviewsにも拡張されたと報じました。Google自身のImagesまたはDiscoverページでAI Overviewsへの言及を直接確認することはできませんでした。どちらのページも現在AI Overviewsや「AIサーフェス」に言及していないため、Search/Discoverでの役割を文書化された事実として扱い、AI Overviewsへの拡張は第三者による報告であり、Google自身のドキュメントが明確に述べているものではないと扱ってください。いずれにせよ、これは選択であり、ランキングではありません。og:imageは複数の入力の1つであり、正確な表示は保証されません。

og:site_nameをサイト名のソースとして

検索結果の横に表示されるサイト名について、Googleはシステムが次のように述べています。 “will also consider content in og:site_name, <title>, heading elements, and other text on a home page. However, WebSite structured data is most important” (翻訳) 「og:site_name、<title>、見出し要素、ホームページ上のその他のテキストの内容も考慮します。ただし、WebSite構造化データが最も重要です。」 （サイト名ドキュメント）。したがって、og:site_nameは1つの判断材料であり、優先順位ではWebSiteのスキーママークアップより下です。（動画ページには4つ目の接点があります。GoogleはOGPをサポートし、動画SEOドキュメントに従って、動画サムネイル用にog:video:imageを読み取ります。）

これらを結び付けると、正直な見出しは次のとおりです。GoogleはOGタグを読み取りますが、結果の見た目を決定するのに役立てるだけで、ランキングには一切影響しません。

ソーシャルプラットフォームとチャットアプリがOGタグをどのように使用するか

OGタグの主な日常的な役割は、リンクプレビューカードです。Facebook、LinkedIn、Slack、Discord、WhatsApp、iMessage、Telegramはすべてこれらを読み取って、クリック前に表示されるカードを構築します。

X/Twitterは特別なケースです。 Twitter Cardsは、Googleの言葉を借りれば、「Twitterに適用可能なOpen Graph Protocolの拡張機能」 です（web.dev）。Xはtwitter:card / twitter:*タグを最初にチェックし、プロパティごとにOGタグにフォールバックします。twitter:cardが完全に存在しない場合、XはOGデータからカードを構築することもありますが、デフォルトはプレーンなsummaryカードタイプです。知っておく価値があること：古いTwitter Card Validatorツールは、プラットフォームがリブランドした2022年頃に非推奨になりました — いくつかの競合他社のガイドは今でもそれが稼働しているかのように参照しています。公式のX専用バリデータはもうありません。サードパーティのOGデバッガーがそのギャップを埋めています。

推奨されるog:imageのサイズと形式

Open Graphプロトコル自体は、og:imageにピクセル寸法やアスペクト比を設定していません — ogp.meは構造化プロパティ（og:image:width、og:image:height、og:image:type、og:image:alt）のみを定義し、必須サイズは定義していません。サイズ設定はコンシューマーごとの決定であり、コンシューマーはすべてが同意しているわけではありません：

  • LinkedIn は独自の最小サイズを直接文書化しています: 1200 × 627px、1,91:1 の比率; 幅が約401px未満の画像は、小さなサムネイルとしてのみ表示されます。
  • Google Discover は、推奨画像メタデータとして 幅1200px以上、総ピクセル数300 000以上、 16:9 のアスペクト比 (例: 1280×720) を文書化しています — これは、以下のソーシャルカードの慣例とは 明らかに異なる比率です。
  • Facebook の現在の共有ドキュメントでは、画像は「幅が少なくとも1080ピクセル」であることを求めており、 普遍的な比率は定めていません。詳細については、別のベストプラクティスガイドを参照するよう指示しています。

このばらつきを考慮すると、1200 × 630px (約1,91:1) は、多くの実装者が使用する実用的な クロスプラットフォームのデフォルトとして依然として有効です — LinkedIn自身の最小サイズに近く、 Facebook、Slack、Discord、WhatsApp、iMessageで許容できる (必ずしもピクセル完璧とは限りませんが) レンダリングを提供し、Xでは大きな画像カードとして表示されます。これを、特定の仕様が義務付けるルールではなく、賢明な慣例として扱ってください — 特定のプラットフォームが重要である場合は、この数値がそこで正しいと保証されていると想定するのではなく、そのプラットフォームの現在のドキュメントを確認してください。

慣例ではなく、厳格なルールである2つの点:

  • 絶対URLが必要です。 og:image は完全な https://… URLを指している必要があります。 相対パスはクローラーに無視されます。
  • 画像をGoogleのサムネイル選択の対象にしたい場合は、一般的なロゴやテキスト主体の画像は避けてください — Googleは両方と、極端なアスペクト比に対して明示的に警告しています。og:image:alt には実際の説明も設定してください。

Open Graphタグがない場合の動作

「OGタグがない」=「プレーンテキストリンク、画像なし」というのはよくある誤解です。実際はそうではありません — プラットフォームはフォールバックし、空白にはなりません。Facebookは、ページの<title>、メタディスクリプション、および最初の使用可能なコンテンツ画像からギャップを埋めます。LinkedInも同様に動作し、幅が約401px未満の画像はサムネイルのみとして扱います。したがって、OGタグを省略した場合の実際のリスクは、制御不能で劣化したプレビュー — 本文中のランダムな画像、切り詰められた<title> — であり、プレビューがなくなるわけではありません。ページが共有されたときの見た目を気にする場合 (そしてプロモーションするものについては気にするべきです)、各プラットフォームに推測させるのではなく、タグを設定してください。

更新したOGタグが表示されない理由 — キャッシュと再スクレイピング

これは最も実用的な悩みの種です。Facebook、LinkedIn、SlackはすべてスクレイピングしたOGデータをキャッシュするため、タグを編集しても、すでに共有されたリンクは遡って更新されません。Facebook自身のウェブマスタードキュメントは、知っておく価値のある特定のメカニズムを確認しています: “images are cached based on the URL and won’t be updated unless the URL changes” (翻訳) 「画像はURLに基づいてキャッシュされ、URLが変更されない限り更新されません」— つまり、画像が固着している問題をトラブルシューティングしている場合、og:image のファイル名を変更すると (内容だけでなく)、新しいフェッチを強制できます。各プラットフォームのキャッシュが自然に期限切れになるまでの正確な期間についての一次情報源はないため、他の場所で引用されている特定の期間を文書化された保証として扱わないでください — 待つのではなく、プラットフォームごとに再スクレイピングを強制してください:

  • Facebook Sharing Debugger (developers.facebook.com/tools/debug) — URLを貼り付けて、「Scrape Again」 を使用して新しいフェッチをトリガーします。
  • LinkedIn Post Inspector — カードを再フェッチしてプレビューします。画像がまだ取得できない場合は、 ブロックされていないか、認証の背後にないかを確認してください。
  • X/Twitter — 2022年頃から公式のバリデーターはありません。XはOGタグにフォールバックするため、 一般的なOGデバッガーと新しい共有が実用的な方法です。

クローラーはキャッシュし、コンテンツは変更されるため、OGタグは本当に設定したら終わりというわけではありません: 価値の高いページで大幅なコンテンツまたは画像の更新を行った後は、再スクレイピングしてください。

実装上の注意点: JavaScript、バイト制限、絶対URL

最大の問題は、レンダリングに直接つながります：ほとんどのソーシャルプラットフォームのクローラーはJavaScriptを実行しません。 クライアントサイドで注入されたOGタグ（例えば、Reactがハイドレーション後に注入するもの）は、それらのクローラーには見えません。クローラーは空の<head>を見ることになります。タグは生の、サーバーサイドでレンダリングされたHTMLに存在している必要があります。これは、JavaScriptを多用するサイトの他の場所で問題となるクロールとレンダリングの違いと同じです（JavaScript SEOを参照）。Slackは（公式仕様には文書化されていませんが）ページの先頭から限られたバイト数しか取得しないと報告されているため、安全マージンとして、大きなインラインスクリプトやスタイルブロックの後ではなく、<head>の早い段階にOGタグを配置してください。そして、これも静かな殺し屋なのでもう一度言います：og:imageは絶対URLでなければなりません。

Bing、Microsoft、およびOpen Graph

BingはここではGoogleほど文書化されていません。BingのMarkup Validator（Bing Webmaster Tools内）は、schema.org、Microdata、Microformats、RDFaと並んで、Open Graphを認識する構造化マークアップ形式の1つとしてリストしています。また、Bingの移行ガイダンスでは、OGメタデータを移行中に最新に保つべきものとしてフラグ付けしています。しかし、Bingは、OGデータがスニペットやサムネイルにどのように、またはどの程度供給されるかについて、Googleスタイルの詳細を公開していません。実際には、MicrosoftエコシステムにおけるOGタグのより強力な消費者はLinkedIn（Microsoft所有）であり、og:title、og:description、og:image、og:urlを読み取ってシェアカードを構築します。文書化されていないBingのメカニズムを過大に主張しないでください。

よくあるOpen Graphの誤解を解く

  • 「OGタグはGoogleのランキング要因である。」 いいえ。そう述べる公式情報源はありません。順位ではなく、タイトルリンク、画像サムネイル、サイト名などの表示に影響します。
  • “OG is only for Facebook, irrelevant to real SEO.” (翻訳)「OGはFacebook専用で、実際のSEOには無関係である。」これは古い理解です。Google自身の資料は、og:title（2024年8月にタイトルリンクの情報源へ追加）、og:image（検索／Discoverの画像選択入力）、og:site_name（優先度の低いサイト名入力）という3つの表示機能でOGタグを読み取ると説明しています。ただし「AI Overviews」への利用は業界報道であり、この確認時点でGoogleのImages／Discover資料が直接述べたものではありません。
  • 「OGタグがなければ、画像のない単純なリンクになる。」 いいえ。プラットフォームは<title>、メタディスクリプション、最初の画像へフォールバックするため、空白ではなく制御できないプレビューになります。
  • 「og:imageを更新すれば、共有済みリンクも即座に直る。」 いいえ。Facebook、LinkedIn、Slackは取得結果をキャッシュします。再取得を強制する必要があり、CDNキャッシュでさらに遅れる場合もあります。
  • 「Twitter Card ValidatorでXのプレビューを修正できる。」 このツールは2022年ごろに廃止され、現在はXの公式バリデータがありません。
  • 「og:imageはどんな画像サイズやURLでもよい。」 いいえ。絶対URLが必要です。Googleは独自のサムネイル選択において、一般的なロゴ、画像内テキスト、極端なアスペクト比を避けるよう警告しています。

次に進む場所

このページは、SEOのためのメタタグハブの下にある詳細な調査です。これは、オンページクラスターの、どのhead要素が実際に重要かについてのマップです。Open Graphはソーシャル/チャットの外観レイヤーです — SERP外観側の兄弟は、タイトルタグ（Googleがog:titleから引き出す可能性があります）とメタディスクリプション（最も類似した類似物：ランキング要素ではなく、すべてクリックに関するもの）です。画像とサイト名の側面では、OGはスキーママークアップと重複します — Googleはog:imageとスキーマのprimaryImageOfPageを代替サムネイルソースとして扱います。そして、ほとんどのソーシャルクローラーはJavaScriptを実行しないため、トピック全体はレンダリングとJavaScript SEOの下流に位置します。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.