構造化データとJSON-LD：実践的なSEO実装ガイド

前端工程

構造化データは、検索エンジンがページ内容を理解するための手がかりになります。JSON-LDは、機械が読み取るデータを表示用HTMLから分離できるため、よく使われる実装方法です。

構造化データは、ページを拡張検索結果の対象にする可能性があります。ただし、リッチリザルトの表示を保証するものではありません。Googleなどの検索エンジンは、ページ品質、検索意図、適格性ルール、その他多くのシグナルをもとに表示を決めます。

参考リンク：

構造化データの役割

構造化データは、ページ内容に明確な意味を与えます。検索エンジンは単なる文字列だけでなく、そのページが記事、製品、ソフトウェアアプリ、パンくずリスト、FAQ、その他の認識可能なエンティティであることを理解しやすくなります。

良い構造化データは次の条件を満たします。

  • ページ上で見える内容と一致している。
  • 関連性があり、できるだけ具体的なSchema.orgタイプを使っている。
  • 必須プロパティと推奨プロパティを含んでいる。
  • コンテンツ変更後も正確である。
  • 公開前に検証されている。

ユーザーに見えない内容を構造化データだけで記述しないでください。これはよくある品質問題で、マークアップが対象外になる原因になります。

JSON-LDが使いやすい理由

構造化データには複数の形式がありますが、JSON-LDは保守しやすい形式です。

形式 追加方法 保守性
JSON-LD <script type="application/ld+json"> ブロック HTMLと分離できて管理しやすい
Microdata HTML要素の属性に書く テンプレート変更で壊れやすい
RDFa HTML要素の属性に書く 強力だが複雑になりやすい

JSON-LDなら、フロントエンドのHTML構造を変更しても、すべての属性を書き直す必要が少なくなります。

JSON-LDの基本構造

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "構造化データとJSON-LD：実践的なSEO実装ガイド",
  "description": "JSON-LD構造化データを安全に追加する方法を解説します。",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

中心となるフィールドは次の通りです。

  • @context：通常は https://schema.org。
  • @type：Article などのSchema.orgタイプ。
  • プロパティ：headline、author、datePublished など、対象を説明する情報。

Articleマークアップ

編集コンテンツには Article、BlogPosting、NewsArticle を使えます。通常のブログ記事では BlogPosting が合うことが多いです。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "PDFを安全に分割する方法",
  "description": "PDFページの抽出と分割に関する実践ガイド。",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

日付は正直に扱います。実際に内容を変更していないのに、鮮度を見せるためだけに dateModified を更新しないでください。

パンくずの構造化データは、検索エンジンがページ階層を理解する助けになります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

JSON-LDのパンくずは、ユーザーがページ上で理解できるナビゲーションと一致しているべきです。

FAQPageマークアップ

FAQPage は、ページ上に実際に見える質問と回答がある場合だけ追加します。リッチリザルトを狙うためだけに、架空のFAQを追加しないでください。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "構造化データはリッチリザルト表示を保証しますか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "いいえ。構造化データは対象になる可能性を作りますが、表示するかどうかは検索エンジンが判断します。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LDはページ上の表示内容と一致すべきですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "はい。マークアップは、ユーザーがページ上でも確認できる内容を説明するべきです。"
      }
    }
  ]
}
</script>

FAQマークアップは検索結果の面積を増やすための近道ではありません。ユーザーにとって分かりやすくなる場合にだけ使います。

SoftwareApplicationマークアップ

オンラインツール、Webアプリ、ダウンロード可能なソフトウェアのページでは、SoftwareApplication で提供内容を説明できます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

本当に正しいフィールドだけを入れてください。評価、レビュー、価格、対応環境を書くなら、ページ上の表示内容と実際の製品状態で裏付けられている必要があります。

複数のJSON-LDブロック

1つのページに複数の構造化データエンティティを含めることができます。例えば、ブログ記事にパンくずを追加できます。

別々のscriptブロックにする方法：

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

配列にする方法：

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

テンプレートで生成するなら、別々のブロックのほうが管理しやすいことが多いです。

検証ワークフロー

公開前には次の流れで確認します。

  1. ページと同じメタデータからJSON-LDを生成する。
  2. JSONとして正しいか確認する。
  3. URLまたはコードを Rich Results Test にかける。
  4. インデックス後、Search Console の構造化データレポートを確認する。
  5. デザイン、ルーティング、CMSテンプレートを大きく変更したら再チェックする。

検証に通ることは、構文と一部の適格性ルールを満たしているという意味です。リッチリザルト表示を保証するものではありません。

よくあるミス

表示内容と一致していない

JSON-LDにレビュー、FAQ、価格、著者情報を書くなら、ユーザーもページ上で確認できる必要があります。

タイプが合っていない

製品リッチリザルトが魅力的だからといって、すべてのツールページを Product にしないでください。タイプはページの実態に合わせます。

架空の評価やレビュー

レビューや評価マークアップには、実在し、ページ上で見えるレビューが必要です。集計評価を作り上げないでください。

日付が不正確

datePublished と dateModified は、実際のコンテンツ履歴を反映するべきです。意味のある変更があったときだけ更新します。

URLが壊れている

画像、ロゴ、正規URL、ページURLは、絶対URLで、クロール可能で、安定している必要があります。

多言語ページで言語が合っていない

多言語サイトでは、各ローカライズページの構造化データをそのページの言語に合わせます。canonicalとalternateリンクの方針とも矛盾しないようにします。

実装のコツ

  • 各ページで手書きせず、CMSまたはページメタデータから生成する。
  • ユーザー生成テキストは正しくエスケープし、JSONを壊さない。
  • ページタイプごとに再利用できるテンプレートを用意する。
  • ホームページだけでなく、代表的なページをテストする。
  • ルート、スラッグ、著者プロフィール、画像生成を変えたら再検証する。
  • まずエラーを優先し、警告は改善項目として扱う。

公開前チェックリスト

JSON-LDを公開する前に確認します。

  • マークアップがページ上で見える内容を説明している。
  • Schema.orgタイプがページに合っている。
  • 必須フィールドが入っている。
  • URLが絶対URLでクロール可能。
  • 日付、著者、タイトル、説明がページと一致している。
  • 対象ページがRich Results Testを通る。
  • 公開後にSearch Consoleを監視する。

構造化データは、リッチリザルトを強制するための裏技ではありません。ページの意味を明確に伝えるための仕組みです。正確で、保守され、表示内容と一致しているとき、検索エンジンはページを理解しやすくなります。

ブラウザローカルツールを無料で試す →

#JSON-LD#结构化数据#SEO#Schema.org#富摘要