なぜ、あなたの「OGP」はSNSで思った通りに表示されないのか？
フロントエンドエンジニアとして数年現場にいると、必ず一度は頭を抱えるのがOGP（Open Graph Protocol）の挙動です。「ローカルでは完璧に見えるのに、本番環境でなぜかカードが表示されない」「意図したレイアウトと違う」。そんな経験はありませんか？
今回は、OGPの中でも特に重要な役割を果たす`og:type`に焦点を当てます。単なる「設定項目」として流すのではなく、SNSのクローラーがどう解釈し、UIがどう変化するのか。その深淵を覗いてみましょう。
—
1. `og:type`が握る「情報の解釈」の鍵
`og:type`は、そのページが「何者であるか」をSNS側のサーバーに伝える識別子です。単なるメタタグの羅列に見えますが、クローラーからすれば、これは「このコンテンツをどう調理して表示すべきか」というレシピの選定プロセスに他なりません。
代表的な値である `website` や `article` を設定することで、SNSのプラットフォームは以下のような処理を裏側で行っています。
- website: トップページやサービス紹介ページなど、サイト全体を指す場合に利用。汎用的なカードとして表示。
- article: ニュース記事やブログ投稿など、日付や著者情報を持つコンテンツに利用。記事特有のメタデータ（更新日など）を付与。
- profile: 人物紹介ページに利用。名前やユーザー名などの固有のスキーマと紐付け。
もし、ブログの個別記事なのに `website` を指定していたらどうなるか。SNS側は「これは単なるサイトのトップページだな」と判断し、本来表示されるはずの「投稿日時」や「読了目安時間」といった、記事としてのリッチな表示オプションを捨ててしまう可能性があります。これが「なんとなく動いているからOK」という落とし穴です。
—
2. 実務で「失敗しない」ための実装テンプレート
実務では、動的なページ生成（SSRやSSG）を行うことがほとんどです。以下のコードは、Next.jsやNuxt.js、あるいは汎用的なPHPベースのテンプレートにそのまま組み込める、現場仕様のサンプルです。
—
3. シニアからのアドバイス：クローラーの「視点」を忘れない
エンジニアがやりがちなミスは、「ブラウザで見えているもの」だけを基準にしてしまうことです。OGPは、ブラウザではなくSNSのクローラー（bot）が見るためのものです。
現場で役立つチェックリスト
1. OGPデバッガーを信じろ: Facebookの「Sharing Debugger」やTwitter（X）の「Card Validator」は必須ツールです。これらを通さずに公開してはいけません。
2. キャッシュに泣かされるな: SNS側は一度取得したOGP情報を長期間キャッシュします。修正したのに反映されない場合、デバッガーツールから「Scrape Again（再取得）」を明示的にリクエストしましょう。
3. `og:type` に合わせるべき他のタグ: `article` を選択したなら、`article:section`（カテゴリ）や `article:tag` もセットで記述することで、SNSのアルゴリズムに対して、より解像度の高いコンテンツ情報を渡すことができます。
まとめ：小さなタグが、UXの体験価値を底上げする
`og:type`を適切に設定することは、単なる仕様の遵守ではありません。あなたの作り上げたコンテンツが、SNSという巨大な海の中で「正しく、美しく」表示されるための最低限のマナーであり、ユーザーがクリックしたくなる動機そのものです。
細かいメタタグの管理は地味な作業ですが、ここを疎かにするエンジニアと、細部までこだわり抜くエンジニア。その差は半年後、一年後のサイトの流入数に確実に跳ね返ってきます。ぜひ、次回のデプロイ前に一度、あなたのサイトの`og:type`を見直してみてください。
現場からは以上です。もし「特定のOGPタグがうまく反映されない！」といった泥臭いトラブルがあれば、いつでも相談してくださいね。
コメント