はじめに
検索結果を眺めていると、価格や在庫、「ホーム > カテゴリ > 商品」といった階層まで一緒に表示されているリンクがあります。一方で自分のサイトは、青いタイトルと2行の説明文だけ。同じ順位に並んでいても、目に留まる度合いはかなり違ってきます。
あの追加情報は、検索エンジンが本文から推測しているわけではありません。ページ側が「ここに書いてあるのは価格です」と機械の読める形で申告することで、はじめて表示されます。既製のECテーマを使っているときはテーマが自動で出していた部分で、ヘッドレス構成に移すとまるごと止まります。
この記事では、モーターサイクル用品を扱うECサイトで、商品ページ・カテゴリページ・よくあるご質問のそれぞれに何を申告しているのか、そして運用してみて決めたルールを解説します。
構造化データは画面に出ないもう一つのページ情報
同じ内容を、人向けと機械向けの2通りで持つ
構造化データは、HTMLの中に埋め込む小さなデータのかたまりです。画面には一切表示されません。商品ページで言えば、写真や商品名や値段が「人が見る部分」、種類・価格・通貨・在庫・階層をまとめたものが「機械が読む部分」。同じ内容を2つの形式で用意しておく、というだけの考え方です。
写真・商品名・価格・説明文
種類・価格・通貨・在庫・階層
価格・在庫・階層つきの検索結果
図の要点は、1つのページが人向けと機械向けの2つの顔を持っている、という一点です。
条件は、この2つが食い違わないこと。機械向けにだけ書かれていて画面には存在しない情報や、画面と違う価格を申告している状態は、検索エンジンから信頼できないページとして扱われます。片方だけ都合よく盛る、ということはできません。
JSON-LDという書き方を選んだ理由
構造化データの書き方は何種類かあります。HTMLのタグ一つひとつに属性を足していく方式もありますが、採用したのはJSON-LDです。本文のHTMLとは切り離して、ページの中に申告用のデータ置き場を一枚だけ用意する形になるので、見た目のマークアップには手を入れずに済みます。
HTMLの属性に散らばって書く。デザインを変えると壊れやすい
本文と分離した一枚のデータとして書く。まとめて管理できる
つまり、SSR（サーバー側でHTMLを組み立ててから返す方式）で作った本文の上に、申告用のデータを一枚重ねるだけで済むということです。デザインを変えるたびに申告側が壊れる、という事故が起きにくいのも利点でした。
商品ページに出している3種類
商品そのものの情報
もっとも効果が大きいのが、商品を表すデータです。商品名・説明文・ブランド名・商品画像・価格・通貨・在庫状況・商品ページのURL・商品コードといった項目を並べています。
表の項目が揃うと、検索結果に価格や在庫が表示される可能性が出てきます。
注意しているのが、色やサイズを切り替えたときの扱いです。ヘッドレス構成ではバリアント（同じ商品の色違い・サイズ違い）の切り替えが画面上で瞬時に終わります。そのとき表示価格だけが変わって申告側の値が古いまま残ると、画面と申告が食い違う。表示に使っている値を、そのまま申告側にも渡す作りにしてあります。
パンくずリスト
検索結果でURLの代わりに「ホーム > ライディングジャケット > 商品名」のような階層が出るのは、パンくずの申告データがあるからです。サイトの構造が伝わるうえ、見た目としても分かりやすくなるので、クリック率に効いてきます。
現在のページがどのカテゴリ配下かをサーバー側で判定
ホーム → カテゴリ → 商品 の順に並べる
各項目に表示用の名前とページのURLを添える
画面のパンくずと同じ材料からサーバー側で出力
この4段階を通ると、画面に出ているパンくずと申告した階層が同じ材料から作られる、という流れです。
実装で手間取ったのが、階層に出す名前をどこから取るかでした。カテゴリには「検索結果に出したいタイトル」と「サイト内で使う短い呼び名」の2つがあることが多く、前者は検索語を詰め込んだ長めの文言になりがちです。そのまま使うと階層表示が読みにくくなる。そこで表示用の名前を1か所で決めておき、画面のパンくず・申告データ・商品ページからカテゴリへ戻る導線のすべてで同じ値を使う形にしました。
運営者情報
3つ目が、サイトの運営者名・ロゴ・公式サイトのURL・SNSアカウントをまとめたデータです。商品ページ単体というよりは、ブランド名で検索されたときの表示やサイト全体の信頼性に関わる部分。地味ですが、一度用意すれば全ページで使い回せます。
カテゴリページとよくあるご質問への申告
並んでいる24件をそのまま伝える
カテゴリ一覧ページには、「これは商品を集めたページです」という申告と、そこに並んでいる商品のリストを添えています。リストに入れるのは表示順・商品名・商品ページのURL・説明の抜粋です。
件数は、ページを開いたときに最初に表示される24件に揃えました。画面に出ていない商品まで書き足すと、画面と申告が食い違う状態になってしまうためです。SSRで出力しているカテゴリページの内容と、まったく同じ材料を使っています。
質問と回答のページ
質問と回答が並ぶページには、その組み合わせをそのまま申告しています。ページ内の質問をすべて拾い、回答からは装飾用のタグを外した文字列を入れる形です。
補足しておくと、質問と回答が検索結果に直接展開される表示形式は、現在は公的機関や医療分野など一部のサイトに限られています。ECで申告しても、そのまま検索結果の見た目が変わるわけではありません。それでも出しているのは、ページの内容が質問と回答であると伝わること自体に意味があるためです。表示形式の仕様は変わっていくものなので、正しい形で持っておくこと自体を先行投資と考えています。
運用して決めた3つのルール
値の出どころを1か所にする
申告した値と画面の値は必ず揃える
申告データに書いた価格や在庫が、実際にページに表示されている内容と食い違うと、検索エンジンから信頼できないページとして扱われるおそれがあります。SSRで取得した同じデータから画面と申告の両方を組み立てることで、この不一致が構造的に起きない作りにしています。
画面表示用の価格と、申告に書く価格を別々に計算していると、割引や会員価格が絡んだ時点で必ずズレます。表示に使っている値をそのまま渡す作りにしておけば、この種のズレは発生しません。ルールとしても覚えやすく、あとから触る人が迷わないのが利点です。
申告する種類を増やしすぎない
ページの内容と対応しないデータを足しても効果はなく、検証時のエラーが増えて管理の手間だけが増えます。商品ページなら商品・パンくず・運営者情報の3種類で十分でした。種類を絞っておくと、あとから見直すときの確認箇所も少なくて済みます。
公開後に必ず検証をかける
構造化データは書き方を1文字間違えても画面は正常に表示されるので、ミスに気づけません。検索エンジンが公開しているテストツールに商品ページやカテゴリページのURLを1つずつ入れて、意図した項目が読み取れているかを確認しています。AIエージェント（AIによる開発支援）に組んでもらった部分ほど、この目視の確認工程は省かないようにしました。
まとめ
構造化データは、ページの内容を機械が読める形式で書き直して添える作業です。商品ページには商品・パンくず・運営者情報、カテゴリページには並んでいる商品のリスト、質問ページには質問と回答。どれも画面に表示されている内容と必ず一致させる、という一点さえ守れば難しいものではありません。
作業自体は地味ですが、検索結果での見え方は同じ順位でも明確に変わります。SSRでの情報出力とセットで、早めに組んでおきたい部分です。