ページを共有する前に、画像とタイトルを確認する

ページを共有する前に、公開URLが提供するタイトル、説明文、画像を確認しましょう。その後、実際に使うサービスでプレビューを確認します。この二つは別の確認です。正しいメタデータはサービスに適切な情報を渡し、サービス上の実際のプレビューは、相手にどう見える可能性があるかを示します。

製品ガイドを仕上げ、自分のサイトで開くと、見出しもイラストも正しく表示されています。ところが、そのURLをSNSの投稿に貼ると、プレビューにはトップページの説明が出てきます。記事そのものには問題がないかもしれません。見直すべきなのは、リンクと一緒に広がる短い紹介です。

創業者や少人数のチームにとって、これは公開前に担当者を決めておく価値のある確認作業です。正確な公開URLから始めてください。CMS上の見栄えのよいプレビューやブラウザーのタブ、ページからの正常な応答だけでは、共有用プレビューの準備ができたとは判断できません。

公開ページが提供する情報を調べる

ページ上の見出しと共有用メタデータは、表示される場所が異なります。見出しは、すでにページへ来た読者に内容を紹介します。メタデータは、その訪問より前に、別のサービスへページの情報を伝えます。多くのサイトでは、このためにOpen Graphの項目を使っています。

Open Graphプロトコルは、タイトル、オブジェクトの種類、画像URL、オブジェクトの正規URLという四つの基本プロパティを定めています。短い説明文などの任意項目もあります。これらはページのスクリーンショットではなく、名前の付いた入力項目だと考えてください。

私たちは2026年10月14日に、ページタイトルのガイドが公開時に返すHTMLを調べました。その時点のOpen Graphタイトルは「Write a Title That Matches the Page | FounderOmni」、画面に表示される主見出しは「Write a Page Title That Matches the Answer Inside」でした。表現は異なりますが、どちらも同じ編集作業を紹介しています。

応答には、記事という種類、ガイド自体のURL、タイトルと本文の答えを照合するという説明文、末尾がpage-title-label-cover-v1.jpgの画像URLも含まれていました。この公開画像をダウンロードし、1,536×1,024ピクセルのJPEGであることを確認しました。実際の寸法は、返されたHTMLの幅と高さの指定に一致していました。

これは実際のページとファイルを調べた記録であり、Facebook、LinkedIn、メッセージアプリのプレビューをテストしたものではありません。サーバーが何を返し、どの画像を確認したかは分かります。しかし、各サービスが選ぶ切り抜き方、キャッシュ情報、表示文言までは確認できません。

開発者には、同じように範囲を絞った依頼ができます。指定したページが返すHTMLを調べ、共有用のタイトル、説明文、URL、画像を一覧にしてもらい、その画像URLも直接開きます。別のページを紹介するプレビューが出る場合、これらの項目をまとめて記録しておくと調査しやすくなります。

情報の不足だけでなく、意図しない重複も探してください。テーマ、SEO拡張機能、ページテンプレートが、それぞれメタデータを追加していることがあります。プロトコルの配列に関する説明では、重複する値が競合した場合、先にある値が優先されます。追加の画像がすべて誤りとは限りません。意図的な代替画像もあります。ただし、記事用の画像より前に古いトップページ画像が出てくるなら、その原因を調べましょう。

公開応答に古い項目が残っている場合は、共有する投稿を何度も直す前に、公開までの処理を修正してください。CMSで改訂版を保存しても、公開ページは更新されていない可能性があります。公開内容の確認ガイドでは、正常な応答と、意図した内容が実際に公開されている状態を区別する方法を説明しています。

このページの紹介として画像を見直す

サイトのメイン画像を見るだけでなく、実際に使われる画像を開いてください。記事のヘッダーと共有メタデータで別の素材を使うサイトもあります。同じ主題を紹介し、無関係な製品や成果を連想させないのであれば、適切な使い分けになり得ます。

私たちの例では、書類ケースにラベルを貼る手を描いたイラストを使っています。ラベルを中身に合わせるというガイドの主題を支えるものです。これは編集用のイラストであり、検索結果が改善したことを検証する証拠ではありません。実用上の意味はタイトルと説明文が伝え、画像はそれを補います。

自分で画像を準備する際は、小さく表示されても何が分かるべきかを決めてください。想定される切り抜き方でも意味が通じる位置に主役を置き、重要な説明は添える文章に残します。画像に長い見出しを入れると、プレビューが小さい場合や切り抜かれた場合に読みにくくなります。

ローカルで画像を切り抜き、明らかな構図の問題を探すことはできます。ただし、それはデザイン上の検討として扱ってください。自分で正方形に切り抜いたからといって、特定のサービスが同じ切り抜きを使う証拠にはなりません。予定している投稿で確認すべきなのは、そのサービスの実際のプレビューです。

製品の告知では、飾りのイラストより、実際の状態を正確に示すスクリーンショットが役立つこともあります。許可された公開画面やデモ画面を使い、対象の機能を明確に示し、非公開のワークスペース情報は除いてください。画面がまだ構想段階なら、その旨を明示します。完成度の高いモックアップで、未提供の機能がすでに使えると誤解させてはいけません。

代替テキストにも役立つ情報を入れましょう。Open Graphの画像プロパティには寸法と画像説明があります。宣伝文句を繰り返すのではなく、画像に何が写っているかを説明してください。私たちの例では、画像ファイルとその説明文の両方を確認しています。説明文だけでは、ファイルにアクセスできることは証明できません。

サービスのプレビューとリンク先を一緒に確認する

公開項目と画像が正しいことを確認したら、サービスが対応するプレビューや投稿エディターを開き、実際に共有する正確なURLを使ってください。下書きプレビューが使える場合は、公開せずに確認します。チームの人が同じ観察を再現できるよう、サービス、URL、時刻を記録しましょう。

見た目だけでなく、目的を果たせるかも確認します。タイトルはこのページを説明していますか。説明文は役立つ背景を加えていますか。画像はまだ判別できますか。そのうえでプレビューのリンクを開き、期待する答えに到達することを確認してください。見栄えのよいカードでも、一般的なトップページに飛ぶだけでは、情報の引き渡しは完了していません。

表示される情報が現在の応答と異なる場合は、両方の観察結果を残してください。違いがあるからといって、CMSの変更が失敗したとは限りません。サービスが以前の情報を保持していたり、別の情報を選んでいたりする可能性があります。共通の更新ボタンや待ち時間があると決めつけず、最新の公式説明や利用できる診断ツールを確認しましょう。

別の見た目のプレビューを無理に出すためだけに、無作為なクエリパラメーターを追加し続けないでください。まず、どのURLを共有していて、それが一貫して同じページを示しているかを把握します。意図的に画像ファイルを版分けする場合は、ページ側の参照を更新し、新しいファイルを確認してください。ファイル名を変えただけでは、サービスが取得したとは分かりません。

引き継ぎには、次の短い記録を使えます。

• ページ：正確な公開URLと、開いた後に得られるはずの役立つ答え。
• 入力項目：共有タイトル、説明文、画像URL、返されたHTML内で見つかった競合する値。
• ファイル：実際の画像形式、寸法、アクセス可能かどうかの確認結果。
• プレビュー：対象サービス、観察時刻、下書き画面や診断画面に実際に表示された内容。
• リンク先：リンクを開いた結果と、ページの約束に合わない場合の次の修正。

この記録を公開用の下書きと一緒に保管してください。項目の調査、画像の見直し、サービスのプレビューは、それぞれ異なる問いに答えます。組み合わせて記録すれば、次の担当者は「SNS用画像をもっとよくして」という依頼ではなく、具体的な修正対象を受け取れます。