資格であって、順位ではない
妥当な markup は、ページをリッチリザルトの対象として適格にします。Google はこの語を意図して使っています。必須プロパティをすべて含めればページは拡張表示の資格を得ますが、表示が約束されるわけではありません。構造化データはそれ自体がランキング要因でもありません。
「資格がある」と「表示される」の隔たりは、多くの人が思うより広く、しかも恣意的ではありません。拡張が現れるかどうかは、クエリ、端末、国、その言語でその機能が提供されているか、そしてその文脈で役に立つかというGoogle自身の判断に左右されます。同じページが、ある検索では星を表示し、次の検索では表示しないこともあります。
使うべき形式は JSON-LD
三つの構文——JSON-LD、Microdata、RDFa——はいずれもGoogleにとって等しく受け入れ可能で、推奨されているのが JSON-LD です。この推奨は技術的というより実務的な理由によります。
JSON-LD は、説明対象の要素に属性として編み込まれるのではなく、単一の script タグの中に収まります。そのためテンプレートのリファクタリングを生き延び、引き継いだ人が一箇所で読め、そこにある誤りが表示中のページを壊しません。Microdata は説明を表示に結びつけるので、リデザインのたびにプロパティを黙って落とす危険があります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Robots.txt and sitemaps",
"datePublished": "2026-06-14",
"author": { "@type": "Organization", "name": "DigestSEO" }
}
</script>- エンティティごとに一つのブロックのほうが、ページ上のすべてを説明しようとする巨大な一塊より明快です。
- ページを描画するのと同じデータから生成してください。そうすれば両者は食い違いようがありません。
- JavaScript で差し込むこともできますが、markup が見られるにはページ自体が問題なくレンダリングされる必要があります。
markup はページと一致していなければならない
訪問者が見られない内容を説明することは、近道ではなくガイドライン違反です。Googleは二つの失敗形態を名指ししています。markup を載せるためだけに作られた空の器のようなページと、ページが決して表示しない事実を主張するプロパティです。どちらもリッチリザルトを丸ごと失わせうるうえ、手動による対策はそれをページ単位ではなくサイト全体から取り除きます。
最も多い形は、意図的ではありません。レビューが削除された集計評価をテンプレートが出し続けている、通貨切り替えがクライアント側で変える価格を出している、過ぎ去ったイベント日を出している——誰も欺くつもりはなく、markup が説明対象の内容より長生きしただけです。だからこそ、一度正しく書くことより、描画されるデータから生成することのほうが重要になります。
| 症状 | よくある原因 |
|---|---|
| 拡張が一度も現れない | 必須プロパティが欠けており、ページに資格がない |
| 現れていたのに止まった | 内容が変わり、markup がもう一致していない |
| markup は妥当なのに拡張がない | 資格はあるが選ばれていない——クエリ、言語、端末 |
| サイト全体で拡張を失った | 手動による対策。Search Console に報告される |
繰り返す代わりにエンティティをつなぐ
多くのサイトは結局、同じ組織を全ページで、その都度少し違う言い回しで説明することになります。この語彙には繰り返しより良い答えがあります。エンティティに @id を与えて一度定義し、他のすべての場所ではその識別子を参照するのです。
これは整頓の話にとどまりません。あなたの会社について微妙に異なる三つの記述を突き合わせる検索エンジンは、それが一つの組織なのか三つなのかを判断しなければなりません。明示的な識別子はその推測を取り除きます。サイト全体で書いている著者にも、一覧とレビューの両方から参照される製品にも、同じことが当てはまります。
もう半分が sameAs です。これは、そのエンティティを他所ですでに説明しているプロフィールや項目——Wikipediaの記事、公式アカウント、法人登記——を指し示します。順位のための手ではなく、裏付けです。あなた自身についての主張を、検索エンジンが確認できる何かに結びつけるために必要なのはまさにこれです。
どの型を追加するか選ぶ
役に立つふるいは短いものです。この型に対応する検索機能は存在するか、そしてこのページはそれを本当に得られるか。リッチリザルトが紐づいていない型を記述しても、保守が増えるだけで結果は何も変わりません。markup は妥当で、正確で、そして無為です。
ページの実態に合わないタイプをマークアップするのは、何も追加しないより悪い選択です。有用な検索表示につながらないまま、機能のガイドラインに違反する可能性があるからです。ガイド記事は Product ではありません。Google は 2026 年 5 月 7 日に FAQ リッチリザルトの表示を停止し、6 月にはそのドキュメントも削除しました。検索機能は廃止されることがある、という現在の例です。ページが実際に示している内容だけをマークアップし、検索機能向けのマークアップを維持する前にサポート対象機能の一覧を確認してください。
- そのページが実際に何であるかを、この語彙の言葉で特定します。
- その型に対応する検索機能があるか、そして何を要求するかを確認します。
- 必須プロパティのすべてを、ページを描画するデータから出力します。
- 構文を検証し、そのうえで拡張レポートで資格を確認します。
- テンプレート変更のあとに再点検します。markup と内容が食い違うのはそこです。