Schema.orgマークアップ最新実務 型を増やす前に見直す判断軸

構造化データの相談では、いまも「型を増やせば検索結果で強くなる」と受け止められがちです。ですが、2026年4月18日時点で先に見直すべきなのは量ではありません。Google が現在どの型をどこまで扱っているかを見極め、保守できる範囲まで実装を絞ること。ここを外すと、公開直後は整って見えても、四半期をまたぐ頃には著者名、更新日、価格、パンくずのどれかがずれ始めます。

判断の出発点も明快です。最初に読むべき資料は Google の構造化データの概要 と 構造化データ ギャラリー で、Schema.org: Getting Started はその次に置くのが妥当でしょう。Schema.org は語彙の広さを把握するうえで役立ちますが、検索流入の改善を狙うなら、一次根拠は Google Search Central に置くべきです。一般の事業サイトで差を分けるのは、語彙の多さではなく、Google が読んだときに意味がぶれない設計だからです。

最初に確認したいGoogleの対象範囲と優先順位

Schema.orgとGoogle対応は同じではない

Schema.org は共通語彙であって、Google専用の仕様ではありません。Schema.org: Getting Started でも、まずは語彙と項目の考え方が説明されています。一方で、Google が検索結果や理解補助に使う範囲は 構造化データ ギャラリー に個別に整理されています。ここを混同すると、「記述できること」と「検索で意味を持つこと」が一緒くたになってしまいます。

そのため、新規導入の判断では Google Search Central を一次根拠、Schema.org を二次根拠に置くべきです。とくに月間PVが10万未満で、構造化データの保守担当が1〜2人しかいない体制なら、この順序は崩さない方がよいでしょう。理由は単純で、導入候補が増えすぎると、実装より協議の時間が長くなるからです。

もちろん例外はあります。検索だけでなく、外部データ連携、ナレッジグラフ整備、アプリ連携、別の検索エンジンへの配信まで同時に考えるなら、Schema.org 側の広い語彙を先に確認する場面もあります。ただし、その場合でも Google 向けの実装優先順位は分けて考えるべきです。同じ図面で全部を満たそうとすると、現場の運用が重くなります。

一般サイトでFAQPageを主施策にしない

いま最も誤解されやすいのが FAQPage です。Google の FAQPage 構造化データ では、FAQ のリッチリザルトは 政府系または健康分野の著名サイト向けに限定されています。つまり、一般的な事業サイトでは、FAQPage を「表示を取りにいく主施策」として扱うべきではありません。

ここは曖昧にしない方が実務は楽になります。一般サイトで最初に着手すべき型は FAQPage ではなく、Article、BreadcrumbList、Organization、必要に応じて Product です。 FAQPage を先に入れると、社内では期待だけが先行し、表示が出なかったときの説明コストだけが残ります。

例外は二つあります。ひとつは、政府系や健康分野で Google の対象条件に明確に近い場合。もうひとつは、検索表示ではなく、サイト内の情報整理と問い合わせ削減を主目的にする場合です。このときは FAQ 本文の整備そのものに意味があります。ただし、それでも「FAQPage を書けば検索表示が強くなる」という説明は避けた方がよいでしょう。

構造化データは本文の代わりにはなりません。Google の構造化データの概要 でも、ページに見えていない情報を裏側だけで補うことは勧められていません。本文が弱いまま FAQ だけを増やすやり方は、短期でも長期でも得策とは言えません。

型を増やす前に実務で絞り込む四つの優先順位

結論から言えば、多くの事業サイトは最初に3〜4型へ絞るべきです。月間PVが10万未満、主要テンプレートが5種類未満、更新担当が2人以下なら、5種類以上を同時運用する設計は避けた方が安全でしょう。型を増やした直後は整って見えても、90日以内に一部が放置される例が非常に多いためです。

記事中心ならArticleから着手する理由

Google の Article 構造化データ は、必須項目を大量に求める設計ではありません。Google は「該当する推奨項目を入れる」という方針を示しており、記事ページでは `author`、`datePublished`、`dateModified`、`headline`、`image` といった基本情報が中心です。だからこそ、記事系サイトは Article を最初の主役に選ぶべきです。

推奨の線引きも明確です。記事詳細ページが検索流入の50%以上を占めるなら、まず Article と BreadcrumbList に投資してください。逆に、記事が全体流入の20%未満で、問い合わせや購入がサービス詳細や商品詳細に集中しているなら、Article を最優先にしない判断もありえます。流入構成を見ずに「記事だから Article」と決めるのは粗い見方です。ページ数が多い領域と、成果に近い領域が重なる場所から着手するのが筋でしょう。

例外は、多ページ構成の特集や会員限定記事です。Article ガイド でも、複数ページの記事では canonical の扱いに注意が必要とされています。分割記事や会員制コンテンツが多いなら、構造化データだけでなく、URL設計と canonical を一緒に確認した方がよいでしょう。その判断基準は canonicalタグの使い方を誤らないための最新実務 検索評価を集約する判断基準 と合わせて見ると整理しやすくなります。

商品型は同期できるときだけ入れる

Google の Product 構造化データ は、商品情報の見せ方を強化しやすい一方、誤実装の影響も大きい領域です。Google は商品ページ向けのマークアップと Merchant Center フィードの併用を案内しています。つまり、ECで売上への寄与が大きいなら Product を優先すべきですが、価格と在庫を日次で同期できないなら先送りにすべきです。

実務上の目安は次の通りです。SKUが300件未満で、価格更新が週1回以下、在庫更新も人手で追えるなら、Product を段階的に導入して構いません。SKUが300件を超え、セールや在庫変動が日常的に起きるなら、CMS手入力だけで回す設計は避けるべきです。古い価格や欠品情報を出し続けるくらいなら、未実装の方がまだ傷が浅い場面もあります。

例外は、購入導線を持たないカタログ型ページや比較レビュー記事です。Product ガイド には、購入ページ向けの Merchant listings と、編集記事向けの Product snippets という整理があります。直接販売しないなら、価格や配送情報まで無理に埋める必要はありません。どこまで入れるかは商品詳細のSEO設計全体とつながるため、EC運用では ECサイト商品ページSEOの実務基準 商品情報と構造設計で評価を積み上げる とセットで判断した方が失敗しにくくなります。

最初に選ぶ型を比較表で整理する

この表で重要なのは、「書けるから入れる」ではなく「維持できるから入れる」と考えることです。構造化データは設定した瞬間より、その後の更新で差がつきます。JPSM SEO 編集事業部でも、初回提案では型の数より、保守責任を持てる項目数を先に確定させます。その方が半年後の精度が高いからです。

JSON-LDを主軸に据える実装判断の基準

新規実装でJSON-LDを選ぶ理由

新規導入なら、主系統は JSON-LD に絞るべきです。Google の構造化データの概要 では、JSON-LD、Microdata、RDFa の3形式が扱える一方で、実装と保守のしやすさから、通常は JSON-LD が勧められています。HTML本文と分けて管理しやすく、CMSの項目とも対応づけやすいためです。

とくに、記事、サービス、商品など複数テンプレートをまたいで運用する場合、JSON-LD の利点ははっきりしています。見出し、著者、価格、パンくずのどこから値を引くかを整理しやすく、出力漏れが起きたときも原因を追いやすい。月間PVが10万を超えた段階では、実装形式の見やすさより、保守のしやすさを優先すべきです。

実務では、JSON-LD を「コード」ではなく「項目表」と捉えると運用しやすくなります。記事なら `headline`、`author`、`datePublished`、`dateModified`、`image`。商品なら `name`、`offers`、`availability`、`brand`、`review`。この程度まで分解できれば、編集、制作、開発の会話も噛み合いやすくなります。実装手順の整理は JSON-LDの書き方を実務で整理 ツールを使って安全に実装する基本手順 を併読すると理解しやすいはずです。

既存形式が安定稼働しているなら例外

ただし、ここで「Microdata はすべて避けるべき」と切り捨てるのは乱暴です。Google は有効に実装されていれば3形式を読めます。したがって、既存の Microdata が数百ページで安定稼働し、改修コストが高いなら、無理に JSON-LD へ全面移行する必要はありません。 重要なのは形式の見た目ではなく、出力の整合性です。

移行を勧める基準は三つあります。ひとつめは、テンプレート改修のたびに本文HTMLまで触る必要があること。ふたつめは、同じページで CMS、テーマ、プラグインの三系統が別々にマークアップを出していること。みっつめは、保守担当が「どこから何が出ているか」を説明できないことです。この三つのうち二つ以上に当てはまるなら、JSON-LD に寄せた方がよいでしょう。

逆に、出力元が一つで、更新漏れもなく、検証結果も安定しているなら、形式変更の優先順位は下げてください。構造化データは、書き換えること自体が目的ではありません。乱れないことに価値があります。

実装形式の選び方を比較表で整理する

ここで最も避けたいのは、形式を混在させることです。JSON-LD を追加したうえで、テーマ側の Microdata も残す。さらにタグ管理で別の JSON-LD を差し込む。この状態になると、重複か不一致のどちらかが必ず起きます。主系統は一つ、例外運用は期間限定。この原則は崩さない方が安全です。

サイト規模ごとに見直す導入順と保守体制

同じ構造化データでも、月間PVやテンプレート数によって適切な導入順は変わります。ここを一律にすると、必要以上に重い設計になりがちです。判断基準は「理想の網羅」ではなく「四半期をまたいでも保守できるか」に置くべきでしょう。

月間十万PV未満は三型で止める

月間PVが10万未満、主要テンプレートが3種類以下、更新担当が実質1人なら、Article、BreadcrumbList、Organization の三型だけで十分です。この段階で FAQPage や細かな派生型まで広げる必要はありません。まずは代表URLを10本前後選び、項目の整合性をそろえる方が成果につながります。

例外は、売上の大半が商品詳細ページに依存しているECです。この場合に限っては Product を四つ目として加える意味があります。ただし、それでも価格と在庫の同期条件は外せません。同期できないなら、三型のままで止めてください。

月間百万PV未満は五テンプレートまで固める

月間PVが10万〜100万で、記事とサービス詳細が混在し、テンプレート数が4〜8種類に増えてきた段階では、主要5テンプレートまで先に固めるべきです。記事、カテゴリ、サービス、商品、パンくず。このあたりまでは、入力ルールと検証手順を定義してから広げた方が安定します。

この規模では、月1回の目視巡回だけでは足りません。更新のたびに、代表URLを各テンプレート5本、合計20〜25本確認する体制へ移した方がよいでしょう。月次監視だけに頼ると、壊れてから1か月放置されるためです。

例外は、テンプレート改修が止まっている古いサイトです。変更頻度が低いなら、毎回すべてのテンプレートを検査する必要はありません。その代わり、CMS項目を変更したときだけは再検証を必須にしてください。

SKU三百件超のECは自動連携が前提

SKUが300件を超えるECで Product を使うなら、手入力前提の運用はやめるべきです。1日数件の更新でも、値引き、在庫切れ、バリエーション追加が重なると、人手では追いつきません。Google の Product ガイドでも、構造化データと Merchant Center フィードの併用が案内されています。SKUが1,000件を超えるなら、むしろそれを前提に設計した方がよいでしょう。

例外は、販売商品が少なく、月に数回しか更新しない高単価商材です。この場合は CMS マスタ管理でも回ります。ただし、レビュー、価格、配送情報まで広げるなら、いずれ自動連携が必要になります。先に出口を決めておく方が賢明です。

シナリオ別に導入順の先手を打つ

1. 記事流入が全体の60%以上なら、Article と BreadcrumbList を先に整えてください。FAQPage は後回しで問題ありません。
2. 問い合わせの70%以上がサービス詳細から生まれているなら、Organization とパンくず整備を優先し、記事型の拡張は二段目に回すべきです。
3. ECでSKUが300件以上あり、価格更新が日次なら、Product は CMS単独で回さず、フィードまたは基幹データ連携を前提にするべきです。
4. サイト改修直前で URL 再編も入るなら、構造化データだけを先に触らず、canonical とパンくずの整合を同時に見直してください。

この四つのシナリオを外さなければ、導入順の判断はかなりぶれにくくなります。逆に、「全部やってから比べる」という進め方は大規模メディア向けの発想です。一般の事業サイトでは、最初から五種類以上を並行運用するより、三種類を高精度で維持した方が結果は安定します。

公開後七十二時間で見直したい検証項目

構造化データは、公開した瞬間より公開後の方が壊れやすい施策です。CDNの画像URL差し替え、テーマ更新、CMSの項目追加、パンくず再編。こうした変更は、ページ表示が正常でも JSON-LD や Microdata だけを静かに壊します。だからこそ、公開後72時間以内の再確認は必須です。

Google のリッチリザルト テスト は、公開URLが Google のリッチリザルト対象としてどう見えるかの確認に向いています。加えて Schema Markup Validator を使えば、Google の表示可否だけでなく、語彙や構造の妥当性も確認しやすくなります。公開前はどちらか片方で済ませがちですが、本番投入の前後では二つとも使うべきです。片方だけでは、表示要件は通るのに構造が不自然、あるいは語彙上は通っていても Google 対応が弱い、といった見落としが残ります。

公開直後に見るべき実務チェックリスト

1. ページの主役になる型が一つに定まっているかを確認する。記事なのに Product と FAQ を主役扱いにしない。
2. 見出し、本文、著者、公開日、更新日、画像がマークアップと一致しているかを確認する。
3. リッチリザルト テスト で代表URLを確認し、重大なエラーを解消する。
4. Schema Markup Validator で、型と項目の組み合わせに不自然さがないかを見る。
5. パンくずリスト構造化データ の順序が、実際の画面表示と一致しているかを確認する。
6. 商品ページでは価格、在庫、レビューの更新元が明確かを確認する。担当者が口頭で説明できない設計は危険です。
7. 出力元が CMS、テーマ、プラグイン、タグ管理のどこかを整理し、三系統以上に分散していないかを確認する。

この七項目が回れば、事故の大半は防げます。とくに、更新日と出力元の確認は軽く見られがちですが、現場で最も壊れやすい部分です。`dateModified` だけが毎日自動で進む設計や、テーマとプラグインが別々に JSON-LD を出す構成は、早い段階で止めた方がよいでしょう。

よくある失敗は公開前に潰しておく

よくある失敗は、どれも型が決まっています。FAQ を大量複製する、本文にない情報を裏側だけで補う、価格だけを手で更新する、パンくず変更と URL 統合を別々に進める。この四つです。いずれも「やろうと思えばできる」施策ですが、続ける前提で設計されていないことが共通しています。

対策もシンプルです。FAQ は必要なページに絞る。本文にない値は書かない。Product は同期できる範囲にとどめる。URL再編では構造化データ、パンくず、canonical を同時に見直す。これだけでも、公開後に慌てる回数はかなり減ります。

次の四半期で進める実行計画の組み方と順序

Schema.orgマークアップの最新トレンドを実務の言葉に置き換えるなら、増やす競争は終わり、整合性を維持する競争に移ったということです。2026年4月18日時点で優先すべきなのは、Article、BreadcrumbList、Organization、必要に応じた Product。FAQPage は一般サイトの主施策にしない。新規実装は JSON-LD を主軸にする。公開後72時間で再検証する。この四つを押さえれば、大半の判断はぶれません。

次の四半期は、次の順番で進めるのが現実的です。

1. 1週目に、主要ページを「記事」「カテゴリ」「サービス」「商品」の4群へ分け、検索流入比率を確認する。
2. 2週目に、Article、BreadcrumbList、Organization の出力元を洗い出し、担当者と更新項目を固定する。
3. 3週目に、代表URLを各テンプレート5本ずつ選び、リッチリザルト テスト と Schema Markup Validator で初回検証を行う。
4. 4週目に、FAQPage を使っているページを棚卸しし、表示狙いだけの実装は整理する。
5. 商品詳細が主要導線なら、価格と在庫の同期方法を決め、日次更新できない場合は Product の拡張を止める。

最後に決めるべきなのは、「次に何を追加するか」ではありません。どの値を、誰が、どの更新タイミングで責任を持つかです。構造化データは、そこまで定義して初めて強くなります。今週やるべきことは、型を増やすことではなく、主要テンプレートごとの出力元と代表URLを一覧にすることです。