10年前の記事を書き直します
2015年に、構造化データについて2本の記事を書きました。
当時のGoogleのドキュメントには、JSON-LDが使えるのはレシピやイベントなど一部の機能だけで、パンくずリストなどは「MicrodataやRDFaを使うのがおすすめ」と書かれていました。
だから旧記事では、MicrodataとJSON-LDを並べて紹介していたんですね。
あれから10年。いまはGoogleがJSON-LDを推奨していて、検索結果に表示される「リッチリザルト」の種類もかなり入れ替わりました。
そこで今回は、構造化データの記事を2026年版としてまとめ直します。
今回の記事の目的
- この10年で構造化データの何が変わったかを知る
- 2026年にJSON-LDで書いておくべきものを決める
- 自分のサイトで正しく書けているか確認する
※この記事は2026年10月時点のGoogle検索セントラルの情報をもとにしています。
対応している種類や表示の条件は変わることがあるので、実装前に公式ドキュメントで確認してください。
そもそも構造化データとは(30秒でおさらい)
構造化データは、ページの内容を検索エンジンに分かりやすく伝えるための書き方です。
人が読めば「これはレシピの記事で、材料はこれ、調理時間は30分」と分かりますが、検索エンジンにとってはただの文字の並びです。
そこで、決まった形式で「これはレシピです」「これは材料です」と書き添えておくのが構造化データです。
Googleはこの情報を使って、検索結果に画像や評価、調理時間などを表示することがあります。
2015年の記事では「リッチスニペット」と呼んでいましたが、いまは「リッチリザルト」という呼び方が一般的です。
この10年で変わったこと
MicrodataからJSON-LDが主流に
2015年は、機能によってはMicrodataが推奨されていました。
いまのGoogleのドキュメントでは、JSON-LD・Microdata・RDFaの3つはどれも有効としたうえで、一般的にはJSON-LDを推奨しています。
JSON-LDは、HTMLの本文とは別に <script> タグの中へまとめて書けるので、
- ページのデザインやHTMLを触らずに追加できる
- あとから修正しやすい
- 書き間違いが起きにくい
といったメリットがあります。これから書くなら、JSON-LD一択と考えてよいと思います。
表示されなくなったリッチリザルト
この10年で、検索結果に表示されなくなったリッチリザルトもたくさんあります。主なものをまとめると、こんな流れです。
| 時期 | 主な変化 |
|---|---|
| 2023年8月 | HowTo(手順)の表示が終了。FAQは政府・医療系の権威あるサイトだけに限定 |
| 2024年 | サイトリンク検索ボックスの表示が終了 |
| 2025年6月〜 | Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing などのサポートを順次終了 |
| 2026年5月 | FAQのリッチリザルトがすべてのサイトで表示終了 |
特にFAQ(よくある質問)は、2015年〜2020年ごろに「検索結果で目立てる」と多くのサイトが入れていたので、影響を受けた方も多いかもしれません。
「書いても順位は上がらない」は変わらない
これは10年前から変わっていませんが、構造化データを入れても、検索順位が直接上がるわけではありません。
Googleも、リッチリザルトの整理について「ランキングには影響しない」と説明しています。
構造化データの目的は、
- ページの内容を正しく理解してもらうこと
- リッチリザルトで、検索結果からのクリックを増やすこと
の2つです。順位を上げる裏ワザではない、と考えておきましょう。
2026年に書いておきたい構造化データ
では、いま書いておきたい構造化データはどれでしょうか。サイトの種類ごとに整理してみます。
どのサイトにも:Organization・WebSite・BreadcrumbList
Organization(組織)は、会社やお店の名前、ロゴ、連絡先などを伝えるものです。トップページに1つ入れておきましょう。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "THIRDPARTY",
"url": "https://third-party.org/",
"logo": "https://third-party.org/logo.png"
}
</script>
WebSite(ウェブサイト)は、検索結果に表示されるサイト名をGoogleに伝えるのに使われます。
BreadcrumbList(パンくずリスト)は、ページがサイトのどの階層にあるかを伝えるものです。2015年にはMicrodataが推奨されていたものの1つですね。
ブログ記事に:Article
ブログやお知らせの記事にはArticleを使います。記事のタイトル、公開日、更新日、著者などを伝えます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "構造化データ2026年版",
"datePublished": "2026-10-28T09:00:00+09:00",
"dateModified": "2026-10-28T09:00:00+09:00",
"author": {
"@type": "Person",
"name": "著者名"
},
"image": "https://third-party.org/wp-content/uploads/eyecatch.png"
}
</script>
お店・事務所に:LocalBusiness
実店舗や事務所があるならLocalBusinessです。住所、電話番号、営業時間などを伝えられます。
電気屋さんなら ElectronicsStore、飲食店なら Restaurant のように、より細かい種類も選べます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "ElectronicsStore",
"name": "まちの電気屋(例)",
"address": {
"@type": "PostalAddress",
"addressRegion": "愛知県",
"addressLocality": "名古屋市◯◯区",
"streetAddress": "◯◯町1-2-3"
},
"telephone": "+81-52-000-0000",
"openingHours": "Mo-Sa 09:00-18:00"
}
</script>
レシピ・商品・イベントなど、該当するなら
レシピ、商品、イベント、求人、動画など、内容に合う種類があればそれも書きましょう。リッチリザルトの対象になっているものは、いまも検索結果で目立つ効果があります。
せっかくなので、2015年の記事で書いたレシピのJSON-LDを、2026年の書き方で書き直してみます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Recipe",
"name": "たっぷりえのきのアヒージョ",
"image": [
"https://third-party.org/wp-content/uploads/ahijo.jpg"
],
"author": {
"@type": "Person",
"name": "斉藤家"
},
"datePublished": "2015-09-10",
"description": "えのきをたっぷり使った、おつまみにも夕食にもぴったりのアヒージョです。",
"prepTime": "PT10M",
"cookTime": "PT15M",
"totalTime": "PT25M",
"recipeYield": "2人分",
"recipeIngredient": [
"えのき 1袋",
"にんにく 2かけ",
"オリーブオイル 適量"
],
"recipeInstructions": [
{ "@type": "HowToStep", "text": "えのきの石づきを切り落として、ほぐします。" },
{ "@type": "HowToStep", "text": "にんにくをオリーブオイルで弱火にかけ、香りを出します。" },
{ "@type": "HowToStep", "text": "えのきを加えて、火が通るまで煮ます。" }
]
}
</script>
2015年の書き方から変わったポイントは、次のとおりです。
http://schema.org/→https://schema.org(httpsに)- 材料は
ingredientsではなくrecipeIngredient - 作り方は1つの文章ではなく、手順ごとに
HowToStepで分ける - 旧記事ではJSON-LDの中に
//でコメントを書いていましたが、JSONにコメントは書けません。 そのまま貼るとエラーになるので注意しましょう
※コード例の値はサンプルです。実際に使うときは、ページに表示されている内容に合わせて書き換えてください。
書かなくていい・消さなくていいもの
FAQのように、検索結果に表示されなくなった構造化データはどうすればいいでしょうか。
まず、慌てて消す必要はありません。 Googleの検索結果に表示されなくなっただけで、schema.orgの種類としてなくなったわけではないからです。ほかの検索エンジンやサービスが使う可能性もあります。
一方で、これから時間をかけて新しく入れる優先度は低い、と考えてよいと思います。
その時間があるなら、先ほど紹介したOrganizationやArticleなど、いまも使われている構造化データを正しく入れることを優先しましょう。
WordPressでの入れ方
まずは、すでに出力されているものを確認する
WordPressの場合、テーマやSEO系のプラグインが、すでに構造化データを出力していることがよくあります。
自分で追加する前に、まずは今のページに何が入っているかを確認しましょう(確認方法は次の章で紹介します)。
同じ種類の構造化データが2つ出ていると、内容が食い違ったときに正しく伝わらない原因になります。足りないものだけを追加するのが基本です。
自分で追加するなら:カスタムフィールドで記事ごとに出力
テーマやプラグインが対応していない種類(レシピなど)を追加したいときは、2015年の記事でも紹介した、カスタムフィールドで記事ごとにJSON-LDを出力する方法が今も使えます。
Advanced Custom FieldsなどでJSON-LD用のフィールドを作り、テンプレートの <head> 内で出力する形です。
記事ごとに中身が違うレシピや商品などは、この方法が管理しやすいですね。
気をつけたいこと
- ページに表示されていない情報は書かない:Googleのガイドラインでも、ページに見えない情報を構造化データに入れないよう求められています
- 構造化データのためだけのページを作らない
- 内容が古くならないように:営業時間や価格を変えたら、構造化データも一緒に直しましょう
書けたかどうかの確認方法
構造化データを入れたら、必ずツールで確認しましょう。
- リッチリザルト テスト:Googleの公式ツール。リッチリザルトの対象になる構造化データが正しく書けているかを確認できます
- スキーマ マークアップ検証ツール:schema.orgの公式ツール。リッチリザルトの対象かどうかに関係なく、すべての構造化データを確認できます
- Search Console:サイト全体で、構造化データにエラーが出ていないかを継続して確認できます
まずはリッチリザルト テストに自分のサイトのURLを入れて、今どんな構造化データが出ているかを見てみるところから始めるのがおすすめです。
まとめ
10年前と比べて、構造化データは「JSON-LDで書く」がはっきりした一方で、検索結果に表示されるリッチリザルトの種類は絞られてきました。
- 書き方は JSON-LDが推奨。Microdataで書いていたものも、直すならJSON-LDで
- FAQやHowToなど、表示されなくなったものを慌てて消す必要はないが、新しく頑張る優先度は低い
- Organization・WebSite・パンくず・Article・LocalBusinessなど、いまも使われているものを正しく
- 書いたらリッチリザルト テストで確認。WordPressはテーマやプラグインとの重複に注意
構造化データは地味な作業ですが、ページの内容を正しく伝えるための大事な土台です。
自分のサイトで今どうなっているか、ぜひ一度チェックしてみてくださいね。
