WEBサイトschema.orgに語が増えても、Googleが使うとは限らない ── 自社の構造化データを3つの段で確かめる13項目（2026年10月時点）
schema.orgに語が増えても、Googleが使うとは限らない ── 自社の構造化データを3つの段で確かめる13項目（2026年10月時点）
目次
01 何が起きたか — schema.org 30.1で語が増えたが、「定義がある」ことと「Googleが使う」ことは別である
用語
schema.org：構造化データで使う「語」（型とプロパティ）を定めた、共通の辞書のこと。検索エンジンが決めた辞書ではなく、複数の組織が共同で保守している。この記事では、辞書に語が載っていることを「定義がある」と呼び、Googleが検索結果の表示に使うと文書で示していることを「Googleの対応一覧にある」と呼んで、区別する。
30.1は、2026年9月16日に出た
schema.orgのリリースの一覧ページは、新しい版から順に並んでいる。2026年10月4日に開いたところ、いちばん上は、2026年9月16日の版30.1だった。その1つ前の30.0は2026年3月19日、さらに前の29.4は2025年12月8日である。つまり、30.1は、約半年ぶりの版である。
30.1の説明は、一覧に、次のように書かれている。
"Add vocabulary to support discovery of EU Digital Product Passports, Add vocabulary to express common eCommerce product data, Misc. schema, doc, and infra updates."
（訳: EUのデジタル製品パスポートの発見を支える語を追加する。一般的なネットショップの商品データを表す語を追加する。そのほか、スキーマ・文書・基盤の更新。）
増えた語のうち、記事の主題にした語
一覧に書かれている、30.1の主な追加は次のとおりである。商品（Product）には、consumerNotice・isOftenBoughtWith・specificationが入った。購入条件のオファー（Offer）にはitemPopularity、送料の設定（ShippingRateSettings）にはminimumOrderValueが入った。EUのデジタル製品パスポートに関しては、DigitalProductPassportという型と、hasDigitalProductPassportというプロパティが入った。そのほか、authorizedRepresentative・importer・recycledContentPercentage・substanceOfConcernなどのプロパティが入った。このほか、順序のある一覧を明示的に扱えるようにする変更も、一覧に載っている。
この記事は、これらの語の意味を詳しく解説する記事ではない。語が増えたと知った日に、自社のページの構造化データを、3つの段で確かめる手順を書く。
3つの段とは何か
3つの段は、筆者の整理である。1段目は、schema.orgに定義があるか。2段目は、Googleの文書が、その語を使うと示しているか。3段目は、その語の値が、画面に出ている内容と一致しているか。3つが全部そろった語だけが、検索結果の表示に結びつく可能性のある語である。1段目と3段目は自分のページで確かめられ、2段目はGoogleの公式の文書で確かめられる。
02 なぜ・背景 — 辞書が増えても、使われる範囲は別の文書で決まる
Googleは「自分の文書が基準」と書いている
Googleの構造化データの入門のページは、schema.orgの語との関係を、次のように書いている。
"Most Search structured data uses schema.org vocabulary, but you should rely on the Google Search Central documentation as definitive for Google Search behavior, rather than the schema.org documentation."
（訳: 検索の構造化データの多くはschema.orgの語を使いますが、Google検索での動きについては、schema.orgの文書ではなく、Google検索セントラルの文書を、決定的な基準としてください。）
この一文は、2026年10月4日に開いたページの内容である。つまり、schema.orgに載っていることは、Googleが使うことの根拠にならない。使うかどうかは、Googleの文書を見て決める。
Googleの対応一覧は、機能ごとに整理されている
Googleの検索ギャラリーのページは、Googleが対応する構造化データの機能を、一覧にしている。冒頭には、「Google uses structured data to understand the content on the page and show that content in a richer appearance in search results, which is called a rich result.」（訳: Googleは、ページの内容をつかみ、その内容を検索結果で、より豊かな見た目で見せるために、構造化データを使います。これはリッチリザルトと呼ばれます。）と書かれている。機能の表には、記事（Article）から動画（Video）まで、25の機能が並んでいる（表の行を数えた）。ページの最終更新は、2026年6月15日（UTC）と表示されていた。
文書に載っていない語は、「使われない」とも「使われる」とも書かれていない
Googleの入門のページには、Googleの検索ギャラリーに載っている語が、リッチリザルトの対象になる、という趣旨の説明がある。それ以外の語については、同じページが次のように書いている。
"There are more attributes and objects on schema.org that aren't required by Google Search; they may be useful for other search engines, services, tools, and platforms."
（訳: schema.orgには、Google検索では必須とされていない属性やオブジェクトが、ほかにもあります。それらは、ほかの検索エンジン、サービス、ツール、プラットフォームで役に立つ場合があります。）
載っていないことは、無視されるという意味ではなく、Google検索では必須とされていないという意味である。この記事は、「使われない」と断定しない。「文書に載っていない」と書く。
数字で見ると、確認の意味が分かる
2026年10月4日に、Googleの商品の構造化データの文書（「Product snippet」）を開いて、30.1で入った5つの語（consumerNotice・isOftenBoughtWith・specification・hasDigitalProductPassport・itemPopularity）を探した。5つとも、プロパティとして載っていなかった。同じ日に、Googleの組織の構造化データの文書で、プロパティの一覧を見ると、authorizedRepresentativeは載っていなかった。ページの最終更新は、商品の文書が2026年9月8日、組織の文書が同じく2026年9月8日（UTC）だった。
03 この記事で出てくる用語
型とプロパティ
構造化データでは、「これは商品である」と示す名前を「型」（TypeやProduct）と呼び、その型に付ける項目（nameやprice）を「プロパティ」と呼ぶ。schema.orgは、型とプロパティの両方を定義している。
JSON-LD
構造化データを書くときの形式の1つである。Googleの文書は、3つの形式（JSON-LD・Microdata・RDFa）に対応していて、JSON-LDを勧めていると書いている。
"In order to be eligible for rich results, mark up your site's pages using one of three supported formats:"
（訳: リッチリザルトの対象になるためには、サイトのページを、次の3つの対応形式のうち1つでマークアップしてください。）
3つの形式は、JSON-LD（推奨）、Microdata、RDFaである。
リッチリザルト
検索結果で、通常の青いリンクと説明文に加えて、評価・価格・画像などが一緒に出る表示のことである。構造化データが正しく書かれていても、表示されるとは限らない。
デジタル製品パスポート
30.1の説明にある、EUの制度に関わる語である。schema.orgの商品のページは、hasDigitalProductPassportの定義を、次のように書いている。
"A link to a Digital Product Passport (DPP) or a digital record detailing the lifecycle, sustainability, and compliance data for this product or offer."
（訳: この商品またはオファーについて、ライフサイクル・持続可能性・法令順守のデータを詳しく書いた、デジタル製品パスポート（DPP）またはデジタルの記録へのリンク。）
この記事は、制度の内容には踏み込まない。定義として書かれていることだけを、引いている。
04 型別 — 適用範囲・この記事が確かめていないこと・手順
適用範囲 — この確認が向いているサイト
構造化データを、自分のサイトに、すでに入れているか、これから入れる予定のサイトが対象である。商品・組織・記事・パンくずリストなど、どの型でも、3つの段の考え方は同じである。商品を扱うネットショップは、30.1で増えた語が直接関わるので、特に確認の意味が大きい。
この記事が確かめていないこと
30.1で増えた語のすべてについて、Googleの文書を調べたわけではない。調べたのは、商品の文書での5つの語と、組織の文書での1つの語である。ほかの文書（商品のレビューの文書や、販売者向けの商品の文書など）に載っているかは、確かめていない。また、Googleの文書は、あとから更新される。「載っていなかった」は、2026年10月4日に開いた版での話である。
注意
この記事は、構造化データに語を足すことを勧める記事でも、足さないことを勧める記事でもない。足すかどうかは、自社のページの内容と、3つの段の結果で決める。画面に出ていない内容を、構造化データだけに入れる使い方は、Googleの規定の面で問題になりうる（06章で引く）。
手順の流れは4つに分かれる
手順は、4つに分かれる。書き出すのは、自社のページに入っている構造化データの型とプロパティを、全部書き出す作業である。辞書で見るのは、書き出した語を、schema.orgで1つずつ開いて、定義があるかを確かめる作業である。公式で見るのは、Googleの文書で、その語が載っているかを確かめる作業である。画面と見比べるのは、語の値が、画面に出ている内容と一致するかを確かめる作業である。
書き出す前に、ページを3つに絞る
サイトの全ページを一度に確かめる必要はない。トップページ、いちばん構造化データが多いページ（商品や記事）、会社概要のページの3つで、十分に型の種類が見える。残りは、同じテンプレートから作られているページなら、同じ結果になることが多い。違うテンプレートのページがあるときだけ、そのページを足す。
05 明日、自社サイトで確認できることチェックリスト
まず13項目を通して見る
以下は、明日、自社のページを3つ開いて、構造化データの語を3つの段で確かめるための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜4番目が語の書き出し、5〜6番目がschema.orgでの確認（1段目）、7〜9番目がGoogleの文書での確認（2段目）、10〜11番目が画面との見比べ（3段目）、12〜13番目が検証ツールと直す順番の決定である。
実務のヒント
構造化データを、手で書き写す前に、ツールで下書きを作ると速い。当サイトの🔧 WEBサイト・構造化データ自動作成ツールで、構造化データの下書きを作り、値を自社の内容に直して使える。公開済みのページの状態をまとめて見たいときは、🔧 WEBサイト総合分析・レポートツールが使える。
- トップページ・構造化データがいちばん多いページ・会社概要のページの3つを選び、URLを表に書く
- 1つ目のページを開き、ブラウザの「ページのソースを表示」で「application/ld+json」を検索して、見つかった数を書く
- 見つかった各ブロックの「@type」の値を、すべて書き出して、表の「型」の列に入れる
- 各ブロックのプロパティ名を、1つずつ、表の「語」の列に書き写す（1ページあたり20個までで十分）
- schema.orgの検索で、「語」の列の語を1つずつ開き、定義が「ある」か「ない」かを、表の「1段目」の列に書く
- 1段目が「ない」の語は、綴りを1文字ずつ見直し、直せるものは直して、直せないものに印を付ける
- Googleの検索ギャラリーを開き、自社が使っている型（Product・Organization・Articleなど）が載っているかを、表の「2段目」の列に書く
- 載っている型は、Googleの該当する文書を開き、「必須」と「推奨」のプロパティの一覧に、自社の語が載っているかを、1語ずつ「あり」「なし」で書く
- Googleの文書に載っていない語に印を付け、その数を数える（「使われない」とは書かず、「文書にない」と書く）
- 各語の値が、画面に出ている内容（名前・住所・電話番号・価格・画像など）と同じかを、1語ずつ見比べて、違う語の数を数える
- 画面に出ていない内容が、構造化データだけに入っていないかを、3ページで確かめ、見つけた語に印を付ける
- Googleのリッチリザルトテストと、schema.orgのスキーマ検証ツールの両方に、3ページのURLを入れ、エラーと警告の件数を書き写す
- 印が付いた語の中から、直す順に3つを選び、直す日を、表の上に書く
観点別の内訳と、かかる時間
すべてに目を通す時間は、あわせて1時間ほどである（筆者の見積もりで、構造化データの量で変わる）。内訳は、1〜4番目が15分、5〜6番目が10分、7〜9番目が15分、10〜11番目が10分、12〜13番目が10分である。構造化データがまだ入っていないサイトは、1〜4番目で、「見つからなかった」と書いて終わり、「足す語を決める」作業に回る。
5分で終わらない項目があったとき
プロパティの数が多いブロックでは、最初の20語だけで十分である。残りは、「そのほか」としてまとめ、同じ型の別のページで、違いが出たときだけ足す。8番目の「Googleの文書での確認」は、型ごとに文書が違うので、型の数だけ時間がかかる。型が多いときは、画面に直接関わる型（商品・組織・記事）を先にする。
06 代替・他の選択肢（表で）
30.1で増えた語を、3つの段で並べる
30.1で増えた主な語を、1段目と2段目で並べた表を作った。2段目は、Googleの商品の文書か、組織の文書に、その語が出てくるかを、2026年10月4日に調べた結果である。3段目は、自社のページの内容で決まるので、表には入れない。
| 語 | 1段目（schema.orgの定義） | 2段目（Googleの文書） |
|---|---|---|
| consumerNotice | あり（商品への消費者向けの注意書きなど） | 商品の文書にプロパティとして載っていなかった |
| isOftenBoughtWith | あり（よく一緒に買われる商品） | 商品の文書にプロパティとして載っていなかった |
| specification | あり（商品の仕様。additionalPropertyの代わりとして書かれている） | 商品の文書にプロパティとして載っていなかった |
| hasDigitalProductPassport | あり（デジタル製品パスポートへのリンク） | 商品の文書にプロパティとして載っていなかった |
| itemPopularity | あり（Offerの語として一覧に載っている） | 商品の文書にプロパティとして載っていなかった |
| authorizedRepresentative | あり（30.1の追加として一覧に載っている） | 組織の文書のプロパティ一覧に載っていなかった |
この表から言えるのは、6つの語は、どれも、1段目はそろったが、2段目は、文書に載っていなかったことである。2026年10月4日の、開いた版の話であり、将来の文書の更新で変わる可能性がある。
実務のヒント
2段目の表は、自分で作るのがよい。商品の文書の「Required properties」「Recommended properties」の一覧を、自社のページの語と、見比べる。語の数が少ないうちは、手で十分である。
文書に載っていない語を、入れるか、入れないか
文書に載っていない語を、構造化データに入れる選択肢は、いくつかある。公式が勧める順番ではなく、筆者の整理である。
- 入れない。文書に載っている語だけを使う。確認が少なく、画面との不一致も起きにくい。Google検索で必須とされているのは、文書に載っている語である。
- 画面に出している内容に限って入れる。3段目をそろえたうえで、2段目が空の語を入れる。Google検索では必須とされていないが、schema.orgとして正しい構造化データになる。
- 入れる前に、検証ツールで確かめる。スキーマ検証ツールは、schema.orgの語が正しく書かれているかを調べる。Googleのリッチリザルトテストは、Googleの対応する機能に必要な項目を調べる。2つの役目は違う。
画面と一致させる決まりは、Googleの規定に書かれている
3段目の根拠は、Googleの構造化データの一般的なガイドラインに書かれている。
"Don't mark up content that is not visible to readers of the page."
（訳: ページの読者に見えない内容を、マークアップしないでください。）
"Your structured data must be a true representation of the page content."
（訳: 構造化データは、ページの内容を、正しく表したものでなければなりません。）
違反した場合の扱いも、書かれている。
"A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search."
（訳: 構造化データに対する手動による対策は、そのページがリッチリザルトとして表示される資格を失うことを意味します。Google検索でのページの順位には、影響しません。）
画面に出ていない内容を構造化データに入れることは、検索結果の見た目の表示を失う原因になりうる。順位には影響しない、とも書かれているので、不安をあおる必要もない。表示の資格を守るために、3段目を確かめる。
順序のある一覧は、辞書の側の話
30.1には、順序のある一覧を、明示的に扱えるようにする変更も入っている。schema.orgの公式ブログは、背景を、次のように書いている。
"There is still a place for ItemList because RDF structures are not as expandable and are really best suited for property targets than the named/top-level collections that ItemLists are frequently used for."
（訳: ItemListには、まだ居場所があります。RDFの構造は、それほど拡張しやすくなく、ItemListがよく使われる、名前の付いた最上位の集まりよりも、プロパティの対象に向いているからです。）
このブログには、GoogleなどのSearch engineが、この新しい書き方に対応するか、という記述は見つからなかった。ItemListを使っているサイトは、今ある書き方のまま、変える必要があるかどうかを、Googleの文書で確かめるのがよい。この記事のチェックリストの2段目の手順で、確かめられる。
07 当サイトで3つの段を当ててみた例
数えた範囲と方法
当サイト（WEBサイトサポート）が、最近、構造化データに足した2つの項目を、3つの段に当てて見た。1つは、2026年9月11日に、トップページの組織の構造化データに足した、ロゴ（logo）と住所（address）である。もう1つは、2026年9月30日に、会社の構造化データのsameAs（ほかの公式ページへの対応づけ）に、Instagramのアカウントを足したことである。
ロゴと住所は、3つの段をそろえて入れた
1段目のschema.orgの定義は、組織に、logoとaddressがある。2段目のGoogleの文書は、組織の文書の、推奨するプロパティの一覧に、addressとlogoが載っている（2026年10月4日に確かめた）。3段目の画面との一致は、住所を、運営している会社の公式サイトに書かれている住所と同じ内容にそろえた。
sameAsも、同じ見方で確かめた
sameAsは、組織の文書の推奨するプロパティの一覧に載っている（10月4日に確かめた）。Instagramの対応づけは、当サイトのヘッダーにあるInstagramのリンクと一致させて入れた。辞書に定義があり、Googleの文書にも載っていて、実在する公式のページと一致しているという、3つがそろった例である（実在の確認は、当サイトのヘッダーのリンクとの一致までである）。
この例の限界
これは、当サイトで足した2つの項目だけを、3つの段で見た例である。「入れた結果、検索結果の表示が変わったか」は、確かめていない。構造化データを足したことが、順位や表示にどう影響したかは、別の確認が要る。
08 このテーマの、これまで
schema.orgの最近の版
リリースの一覧で、2026年10月4日に確かめた、最近の版は次のとおりである。30.1が2026年9月16日、30.0が2026年3月19日、29.4が2025年12月8日、29.3が2025年9月4日、29.2が2025年5月13日である。この間隔の中では、30.0と30.1の間の約半年が、いちばん長かった。
当サイトの過去の記事 — 構造化データの「正しさ」は1種類ではない
当サイトには、構造化データの「正しさ」を、いくつかの側面から確かめた記事がある。構造化データは、構文が正しくても消えることがある ── 手動による対策の条件を確認する14項目は、書き方が正しくても、対策の対象になる場合を整理した。JSON-LDのHTMLエスケープは、1回しか解除されなくなった ── 自分のサイトに二重エスケープが残っていないか確認する13項目（2026年9月時点）は、書き方の面の確認である。Organization構造化データは、正しく書いても「合格」の通知が来ない ── ナレッジパネルに伝える情報を確認する13項目（2026年9月時点）は、組織の構造化データの話である。
ブログでは、出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴が、出力があるのに値が食い違っていた話である。記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったは、構造化データの名前の書き方を揃えた話である。「1本だけ書き方が違う」と指摘された ── 91本で数え直したら、標準だったのはその1本のほうだったと、「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれも、確かめる段を増やす考え方で、今回の3つの段と同じ形である。
公式情報
この記事で引いた文は、2026年10月4日に開いた公式のページから写した。引用は、Release listing - schema.org（訳: リリース一覧 - schema.org）、Introduction to structured data markup in Google Search（訳: Google検索の構造化データマークアップの入門）（Google 検索セントラル）、General Structured Data Guidelines（訳: 構造化データの一般的なガイドライン）（Google 検索セントラル）などのページである。使うときは、元のページで、最新の内容を確かめてほしい。
現在の貴方のIPアドレス
このサイトで書いている人
