構造化データは何から入れる？優先順位の決め方

構造化データを入れたほうがいいとは聞く。でも型が多すぎて、どれから手をつければいいか分からない。答えは単純です。全部入れる必要はありません。自社のページに実際にある情報で、テンプレートから自動で出せる型から入れるのが、手間に対して効果の見込みがいちばん大きい順番です。

ここでいう構造化データは、ページの中身を検索エンジンに決まった書式で伝えるための記述です。書式の語彙として schema.org という共通の規格が使われ、「これは記事」「これはパンくず」「これは会社情報」といった「型」を選んで書きます。

そもそも入れると何が変わるのか

まず期待値をそろえます。Google の概要ページは、構造化データがページ内容に対する Google 検索の理解を高めると説明しています。そのうえで、JSON-LD・Microdata・RDFa といった形式で実装すると、リッチリザルトにつながることがある、と書いています。

リッチリザルトは、通常の青いリンクと説明文に加えて、パンくずの階層や画像などが付いた検索結果の見え方です。概要ページでは、構造化データのあるページでクリック率・訪問・ユーザーの関与が伸びた事例があることにも触れています。

ここで読み違えやすい点があります。「つながることがある」は「入れれば必ず出る」ではありません。事例で伸びたのも、そのサイトの条件でのことです。だから、構造化データは「検索結果での見え方の選択肢を増やすもの」と考えておくほうが安全です。順位そのものを押し上げる道具として期待すると、入れたあとに判断を誤りやすくなります。

なぜ「全部入れる」がうまくいかないのか

型をたくさん入れれば、どれかは当たりそうに見えます。ところが実務では、3つの理由で逆効果になりがちです。

一つは保守の手間です。ページごとに手書きした構造化データは、本文を直したときに更新が漏れます。本文と中身が食い違った状態が残るのは、入れないより扱いにくい状態です。

二つめは、自社のページにない情報を書きたくなることです。商品やレビューの型を「入れられるから」と入れると、ページに見えていない内容までマークアップしてしまう場合があります。構造化データはページの中身を伝えるものなので、中身にないことは書かない、が原則と考えてください。

三つめは、効果の検証ができなくなることです。一度に何種類も入れると、どの型が検索結果の見え方を変えたのか分かりません。

サイトの種類別「入れる価値が高い型」判断表

以下は、ページに実在する情報とテンプレート化のしやすさから見た目安です。運用の手間と効果の見込みから組み立てた、この記事独自の判断表です。

表の読み方は一つだけです。左の列ほど、サイトのほぼ全ページに共通の情報で、一度作れば全体に効く型になっています。

たとえば Organization は、会社の公式サイトの URL、ロゴ、公式プロフィールへのリンク（sameAs）といった情報を伝える型です。公式の例では「会社概要」のページに置かれています。会社情報は全ページで共通なので、一度テンプレートに組み込めば以後ほぼ手がかかりません。

BreadcrumbList はパンくずリストの型です。各階層は ListItem という項目で表し、公式ページでは各項目の item（その階層のページの URL）が必須の項目として挙げられています。パンくずはサイト構造から自動で出せることが多く、ここも手間が小さい型です。

Article はブログ記事やお知らせのための型です。公式の例では、見出し（headline）や画像（image）を記述しています。記事テンプレートにすでにタイトルとアイキャッチ画像があるなら、そこから値を流し込めます。

会社サイトで優先度を仕分ける6ステップ

架空の例で一度通してみます。題材は、BtoB のサービスサイトです。ページは「トップ」「サービス紹介」「資料請求LP」「技術ブログ（記事40本）」「会社概要」の5種類があるとします。

1. ページの種類を棚卸しする。 URL 単位ではなく「テンプレートの種類」で数えます。この例では5種類です。ブログ40本も、テンプレートとしては1種類です。
2. 各テンプレートに「ページに見えている情報」を書き出す。 会社概要には社名・ロゴ・SNSのリンク。ブログには記事タイトル・公開日・アイキャッチ。全ページ共通でパンくずがあります。
3. 見えている情報に対応する型だけを候補にする。 社名とロゴは Organization、パンくずは BreadcrumbList、ブログは Article。資料請求LPには対応しそうな型が見当たりません。ここで無理に探さないのがポイントです。
4. テンプレートから自動で出せるかで並べる。 Organization とパンくずは共通部品に一度足すだけ。Article は記事テンプレートに1回足せば40本に効きます。どれも手作業がページ数に比例しません。
5. 1種類ずつ入れて、検証ツールで確認する。 まず Organization とパンくず、次に Article の順にします。まとめて入れると、あとで何が効いたか分からなくなるからです。
6. 数週間おいて、検索結果の見え方を確かめる。 パンくずの階層が出たか、記事の見え方が変わったかを見ます。変わらなくても、それだけで失敗とは決めません。

この例の結論は「Organization → BreadcrumbList → Article の順、資料請求LPは見送り」です。

ステップ3で資料請求LPを外したのは、さきほどの「中身にないことは書かない」の実践です。LPに商品の価格もレビューもないのに Product を入れれば、ページに見えない情報を書くことになります。

ステップ6で「失敗と決めない」のは、記述が正しくても表示されるとは限らないからです。概要ページも「つながることがある」という書き方にとどめています。検索クエリや端末、検索結果の変動によって、同じページでも見え方が変わることがあります。

よくある誤解：FAQ や HowTo を入れれば目立つ

「質問と回答を並べれば検索結果で大きく表示される」と聞いて、FAQ の型を最優先にしたくなるかもしれません。ただ、FAQ の型を入れても、期待した表示が出ないケースがあります。その切り分け方と、マークアップを残すかの判断はFAQ構造化データが表示されないときの判断にまとめています。

ここから言える一般的な教訓は、見た目の変化が大きい型ほど、提供条件が変わりやすいことがあるという点です。目立つ型を追いかけるより、会社情報・パンくず・記事のように、サイトの中身そのものを素直に表す型を先に固めるほうが、条件の変化に左右されにくくなります。

導入前の自己点検チェックリスト

入れる型を決めたら、着手前に次の5つを確かめてください。1つでも「いいえ」なら、その型は後回しで構いません。

最後の項目が一番大事です。「なんとなく入れておく」型は、保守の手間だけが残りがちです。

次にやること

まず自社サイトのテンプレートの種類を数えてください。そして、上の判断表で「最初に入れる型」に当たるものが、すでに入っているかを確かめます。入っていれば、次の型に進む前に検索結果の見え方を一度見ておくと、効果を切り分けやすくなります。

書式を JSON-LD にするか Microdata にするかで迷ったらJSON-LDとMicrodataの違いを、入れたあとに Search Console でエラーや警告が出たら構造化データのエラーと警告の直す順番を参考にしてください。