構造化データの書き方ガイド｜SEO効果と実装方法【2026年版】

Q: 複数の構造化データを1ページに混在させても大丈夫ですか？

大丈夫です。1つのページに複数の<script type="application/ld+json">タグを置き、それぞれ異なる@typeを記述できます。ただし同じ@typeを重複させないよう注意してください。

Q: 構造化データを入れたのにGoogle Search Consoleでエラーが出ます

まず必須プロパティが抜けていないかを確認します。Articleならheadlineやauthor、Productならpriceやavailabilityなど、@typeごとに必須項目が決まっています。次に、ページ上に表示されている内容とJSON-LDの内容が一致しているかも確認してください。

Q: WordPressのプラグインとfunctions.phpの実装を両方使っても良いですか？

同じ@typeの構造化データが重複して出力される可能性が高いため、避けたほうが安全です。どちらか一方に統一し、テストツールで重複がないか確認してから公開してください。

この記事の対象: 構造化データの実装方法を知りたいWeb制作者
読了時間: 約8分

検索結果にレビューの星マーク、FAQの展開、パンくずリストが表示されているのを見たことはありませんか。これらは構造化データによって実現されている「リッチリザルト」です。

構造化データを正しく実装すると、検索結果での視認性が上がり、クリック率の改善につながります。加えて2026年現在は、ChatGPTやGeminiといったAI検索・生成AIがページ内容を読み取る際にも構造化データを手がかりにする場面が増えています。この記事では主要な構造化データの種類とJSON-LDでの書き方、そして導入後のチェック方法までを解説します。

構造化データとは

構造化データは、Webページの内容を検索エンジンやAIが理解しやすい形式で記述するマークアップです。Schema.orgの語彙に基づいて、ページが「何について書かれているか」を機械にも分かる形で明示します。

人間はタイトルやレイアウトを見れば「これは商品ページだ」「これはFAQだ」と直感的に判断できますが、機械にとってHTMLはただのタグの集合です。構造化データはその間を埋める「翻訳」のような役割を果たします。

正しく実装すると、検索結果にリッチリザルト（星評価、FAQの展開、パンくず表示など）が出る可能性があります。さらに、AI検索エンジンがページ内容を要約・引用する際の精度にも関わってくるため、2026年のSEOでは「検索結果の見た目を良くする施策」から「機械に正しく読んでもらうための前提条件」へと位置づけが変わってきています。この文脈はAIO対策・LLMO対策で本当にやることは何か【2026年版】で詳しく扱っています。

構造化データが機能する仕組み

HTMLに記述JSON-LDでページ内容を明示

検索エンジンが読み取るクロール時にSchema.orgとして解釈

リッチリザルト対象に条件を満たせば検索結果に反映

構造化データを入れたからといって必ずリッチリザルトが出るわけではない点には注意が必要です。あくまで「対象になる資格を得る」ものであり、表示するかどうかは検索エンジン側の判断に委ねられます。

主要な構造化データの種類

サイトの種類によって、優先的に入れるべき構造化データは変わります。すべてを一度に入れる必要はなく、サイトの目的に合うものから着手するのが現実的です。

Article（記事ページ）

ブログ記事やニュース記事に使用します。著者、公開日、更新日、画像といった情報を検索エンジンに伝えます。オウンドメディアを運営しているなら最優先で入れるべき項目です。

BreadcrumbList（パンくずリスト）

サイトの階層構造を検索結果に表示します。URLがそのまま表示されるより、ユーザーが現在地を把握しやすくなり、クリック前の安心感につながります。パンくずの階層とURLの階層が食い違っていると、検索エンジンに伝わる構造とJSON-LDの内容が矛盾してしまうため、URL設計自体も合わせて見ておく必要があります。Shopifyのように標準のURL構造に制約があるプラットフォームでは、この食い違いが起きやすい点に注意してください。詳しくはShopifyのSEO対策｜URL構造の制約とその回避策【2026年】で扱っています。

FAQ（よくある質問）

FAQの質問と回答を検索結果に直接表示します。検索結果の占有面積が増えるため、CTRの向上が期待できます。ただし2023年以降、Googleはこの表示を権威性の高い政府機関・医療系サイトなど一部に限定する方針を取っており、一般的な企業サイトでは表示されにくくなっている点は押さえておく必要があります。それでも、マークアップ自体はAI検索がQ&A形式の情報を抜き出す際の手がかりになるため、実装の価値は残っています。

HowTo（手順解説）

料理のレシピやDIY手順など、ステップバイステップの情報を表示する際に使います。こちらもリッチリザルトとしての表示機会はFAQ同様に限定的になっていますが、マークアップ自体は無駄になりません。

LocalBusiness（店舗情報）

住所、電話番号、営業時間、レビューなどのローカルビジネス情報を表示します。Googleマップとの連携にも影響するため、実店舗を持つ業種では欠かせません。

Product（商品情報）

商品名、価格、在庫状況、レビュー評価を検索結果に表示します。ECサイトには必須の項目です。Shopifyで構築している場合、テーマ側の実装によってはJSON-LDが自動出力されないケースもあるため、Shopifyテーマの開発環境の作り方｜CLIで本番を壊さない手順で検証環境を整えたうえで確認するのが安全です。

JSON-LDでの書き方

構造化データの記述形式はJSON-LDがGoogleの推奨です。以前はMicrodata形式でHTMLタグの中に属性として埋め込む方法もありましたが、HTML本体と構造化データの記述を分離できるJSON-LDのほうが保守性が高く、現在はこちらが標準になっています。<script type="application/ld+json">タグでHTMLに埋め込みます。

Article（記事）の例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "記事のタイトル",
  "image": "https://example.com/image.jpg",
  "author": {
    "@type": "Organization",
    "name": "Soreiine!!"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Soreiine!!",
    "logo": {
      "@type": "ImageObject",
      "url": "https://soreiine.jp/logo.png"
    }
  },
  "datePublished": "2026-01-10",
  "dateModified": "2026-10-02"
}
</script>

ポイントはdateModifiedです。記事を更新したのに公開日のまま放置していると、検索エンジンに「情報が古いまま」と判断される余地が生まれます。更新を反映する運用があるかどうかは、地味ですが効いてくる部分です。

FAQ の例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "ホームページ制作の費用はいくらですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "規模や要件によって異なります。テンプレート利用の5ページ構成なら比較的安価に、フルスクラッチのコーポレートサイトなら相応の費用になります。"
      }
    },
    {
      "@type": "Question",
      "name": "制作期間はどのくらいですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "要件定義からデザイン、実装、検証まで含めると、一般的な企業サイトの場合は2〜4ヶ月が目安です。"
      }
    }
  ]
}
</script>

BreadcrumbList の例

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "コスト", "item": "https://example.com/cost/" },
    { "@type": "ListItem", "position": 3, "name": "費用相場" }
  ]
}
</script>

実装のポイントとしては、実際にページ内に表示されている情報とJSON-LDの内容を一致させることです。価格やレビュー件数など、ページ上に見えない情報だけを構造化データに書き込む行為はGoogleのガイドライン違反になり、ペナルティの対象になり得ます。

つまずきやすい点としては、JSON-LDをコピペで使い回した際に@typeや日付の書き換え漏れが起きがちなことです。特に複数ページに同じテンプレートを流用するCMSでは、urlやdatePublishedが全ページ同じ値のまま残っているケースをよく見かけます。

対応ブラウザについては、JSON-LD自体はHTML内のスクリプトタグなので表示上の互換性問題は発生しません。重要なのは検索エンジン・クローラー側の解釈であり、GoogleはJSON-LDを公式に推奨、Bingも同様にサポートしています。

テストツール

実装して終わりではなく、必ず検証まで行います。

Googleリッチリザルトテスト

URLまたはコードを入力して、構造化データが正しく実装されているか、リッチリザルトの対象になるかを確認できます。公開前の最終チェックに使うツールです。

Schema Markup Validator

Schema.orgの仕様に準拠しているかを検証するツールです。Googleのテストでは検出されない構文エラーも発見できることがあるため、両方のツールを併用するのが安全です。

ツール	主な用途	確認できること
Googleリッチリザルトテスト	公開前の最終確認	リッチリザルトの対象可否
Schema Markup Validator	構文レベルの検証	Schema.org仕様への準拠

テクニック WordPressのパンくずリストを自作する｜構造化データ（JSON-LD）付き実装パンくずリストのためだけにプラグインを1本入れる。よくある判断ですが、出力される HTML はテーマのデザインに合わず、構造化データの中身も選べず、更新のた…

WordPressでの導入方法

プラグインを使う方法

Yoast SEO: ArticleやBreadcrumbListを自動出力
Rank Math: FAQ、HowTo、Productなど多数の構造化データに対応
Schema Pro: 構造化データ専門のプラグイン

どのプラグインを使うにしても、すでにテーマ側で構造化データを出力していないかを先に確認してください。プラグインとテーマが二重にJSON-LDを出力していると、同じ@typeの情報が重複し、検証ツールでエラーになることがあります。

テーマのfunctions.phpで実装

プラグインに頼らず、wp_headアクションフックで直接JSON-LDを出力する方法もあります。パフォーマンスを重視する場合や、カスタム投稿タイプに合わせて細かく出し分けたい場合に有効です。独自のfunctions.phpへの追記方法はWordPressカスタム投稿の一覧テンプレートの作り方｜実装手順とコードでも扱っています。

Soreiine!!ギャラリーに見る実装の工夫

Soreiine!!のギャラリーに掲載されているサイトの中には、構造化データの扱いが丁寧なものがいくつかあります。たとえばオウンドメディア系のサイトでは、記事一覧ページにCollectionPage、個別記事にArticleを使い分けて、ページの性格を機械にも伝わる形で分離している実装が見られます。一覧と個別で同じ@typeを使い回すと、検索エンジン側がページの役割を取り違えやすくなるため、この使い分けは地味ながら効果的な工夫です。

また店舗・サービス紹介系のサイトでは、LocalBusinessのopeningHoursSpecificationを曜日ごとに細かく分けて記述している例もあります。営業時間が曜日によって変動する業種では、ここを大まかにまとめてしまうと検索結果の表示とサイト本文の実際の営業時間にズレが生じるため、丁寧に書き分けている実装は参考になります。

こうした細部の作り込みは、デザインの見栄えだけでは判断できない部分です。ギャラリーで気になったサイトがあれば、ページのソースを開いてJSON-LDの中身まで見てみると、実装のヒントが見つかることがあります。

よくある質問

構造化データを入れればリッチリザルトは必ず表示されますか？

表示されません。構造化データはあくまで「表示される資格を得る」ためのもので、実際に表示するかどうかは検索エンジン側のアルゴリズムが判断します。特にFAQやHowToは、近年表示対象が限定される傾向にあります。

FAQの表示機会が減っているなら、もう実装する意味はないですか？

意味はあります。検索結果での表示機会は減りましたが、AI検索エンジンがページ内容をQ&A形式で正確に抜き出す際の手がかりとして機能します。表示目的だけでなく、機械に正しく読まれるための実装として捉えるのが現実的です。

複数の構造化データを1ページに混在させても大丈夫ですか？

大丈夫です。1つのページに複数の<script type="application/ld+json">タグを置き、それぞれ異なる@typeを記述できます。ただし同じ@typeを重複させないよう注意してください。

構造化データを入れたのにGoogle Search Consoleでエラーが出ます

まず必須プロパティが抜けていないかを確認します。Articleならheadlineやauthor、Productならpriceやavailabilityなど、@typeごとに必須項目が決まっています。次に、ページ上に表示されている内容とJSON-LDの内容が一致しているかも確認してください。

WordPressのプラグインとfunctions.phpの実装を両方使っても良いですか？

同じ@typeの構造化データが重複して出力される可能性が高いため、避けたほうが安全です。どちらか一方に統一し、テストツールで重複がないか確認してから公開してください。

まとめ

構造化データのポイントをまとめます。

構造化データは検索エンジンやAIにページ内容を正しく伝えるマークアップで、リッチリザルトの表示機会につながる
記述形式はJSON-LDがGoogleの推奨。HTML本体と分離できるため保守性が高い
Article、BreadcrumbListは多くのサイトで実装すべき基本。FAQ、HowToは表示機会が限定的になっているが、AI検索向けの価値は残る
実装後はGoogleリッチリザルトテストとSchema Markup Validatorの両方で検証する
WordPressならYoast SEOやRank Mathで手軽に導入できるが、テーマ側との重複出力に注意
ページ上の表示内容とJSON-LDの内容を一致させることがガイドライン上も実務上も重要