構造化データを「なぜ入れるか」は理解している。でも「どう書くか」でつまずいている——そういうWeb担当者が一番多いのが実情です。
結論からお伝えすると、構造化データの書き方はJSON-LDという形式に統一して考えれば十分です。
この記事では、JSON-LDの基本構文から、タイプ別のコピペテンプレート、WordPressへの設置手順まで、実装に必要なものを一通り揃えています。
「構造化データとは何か・なぜ重要か」については構造化データとは？Schema.orgの基本とSEO・AI検索に効く実装入門【2026年版】で解説しているので、本記事では書き方と実装に集中します。
JSON-LDの基本構文はどう書くのか？
JSON-LDは<script type="application/ld+json">タグの中にJSONを記述する形式です。HTMLの本文とは独立しているため、既存のページデザインに影響を与えずに追加できます。
最低限おさえる4つのキー
JSON-LDを書くにあたって、まず4つのキーを覚えるだけで始められます。
| キー | 役割 | 例 |
|---|---|---|
@context | 使う語彙（ボキャブラリー）の宣言 | "https://schema.org" |
@type | ページや情報の種類 | "Article", "FAQPage" |
name | 記事タイトルや会社名などの名称 | "構造化データの書き方" |
url | そのページや組織のURL | "https://example.com/..." |
@contextと@typeはすべてのJSON-LDに必須です。 これがないとGoogleはスキーマとして認識してくれません。
実際のコードで見る基本パターン
最もシンプルなArticleスキーマを例にとると、骨格はこうなります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "ページのタイトル",
"author": {
"@type": "Person",
"name": "著者名"
},
"datePublished": "2026-03-18",
"dateModified": "2026-03-31"
}
</script>
{}が1つのオブジェクト、"キー": "値"の組み合わせでデータを記述します。著者情報のように複合的な情報は{}でネストして書きます。
JSON形式なので、カンマの付け忘れと閉じ括弧の対応ミスが最大の落とし穴です。後述する検証ツールで必ず確認してください。
【タイプ別】コピペで使えるJSON-LDテンプレート
Article（ブログ・コラム記事）
ブログ記事やコラムに使うタイプです。著者情報・公開日・更新日を記述することで、E-E-A-T（経験・専門性・権威性・信頼性）シグナルをGoogleとAIの両方に伝えられます。
AI引用の観点で特に重要なプロパティ：author（誰が書いたか）、dateModified（情報が最新か）、image（コンテンツの視覚的な信頼性）
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトルをここに入力",
"description": "記事の概要・メタディスクリプション相当のテキスト（120文字程度）",
"url": "https://www.example.com/記事のURL/",
"datePublished": "2026-01-15",
"dateModified": "2026-03-31",
"author": {
"@type": "Person",
"name": "著者名",
"url": "https://www.example.com/about/"
},
"publisher": {
"@type": "Organization",
"name": "サイト運営者名",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png"
}
},
"image": {
"@type": "ImageObject",
"url": "https://www.example.com/アイキャッチ画像のURL.jpg"
}
}
</script>
datePublishedは記事を最初に公開した日付を入れ、以後変更しないのが原則です（よくある間違いは後述します）。更新のたびに変わるのはdateModifiedだけです。
FAQPage（よくある質問）
2025年まではFAQPageを実装すると検索結果にQ&Aのアコーディオン表示（FAQリッチリザルト）が出る施策として知られていました。ただし2026年5月にFAQリッチリザルトの表示は終了しています。
では実装する意味がなくなったかというと、そうではありません。FAQPageスキーマ自体はSchema.orgの型として有効で、AI検索（Google AI Overview・ChatGPT・Perplexity）がコンテンツの内容を理解する際に「このページはこの質問に答えられる」と判定しやすくなる効果は続いています。AIO・LLMO観点での実装価値は引き続き高いです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "質問文1をここに入力",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文1。結論を最初に述べ、補足を続ける形式が推奨。"
}
},
{
"@type": "Question",
"name": "質問文2をここに入力",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文2。"
}
},
{
"@type": "Question",
"name": "質問文3をここに入力",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文3。"
}
}
]
}
</script>
ポイント：mainEntityは配列（[]）で複数の質問を並べる形式。 質問を追加するたびに{}で囲んだブロックをカンマ区切りで追加します。また、ページ本文に表示されていないFAQをスキーマに書くとガイドライン違反になります。スキーマの内容は必ずページのコンテンツと一致させてください。
Organization（会社・サービス情報）
サイト運営者の組織情報を記述します。「このサイトは実在する組織が運営している」という信頼性シグナルをAIと検索エンジンに伝える基盤となるスキーマです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "会社名",
"url": "https://www.example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png"
},
"address": {
"@type": "PostalAddress",
"streetAddress": "〇〇区〇〇1-2-3",
"addressLocality": "〇〇市",
"addressRegion": "東京都",
"postalCode": "100-0001",
"addressCountry": "JP"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "03-0000-0000",
"contactType": "customer service"
},
"sameAs": [
"https://x.com/yourhandle",
"https://www.facebook.com/yourpage"
]
}
</script>
sameAsは公式SNSや外部プロフィールのURLを配列で並べます。これによって「同じ組織に関する情報が複数の場所にある」とAIが判定しやすくなり、エンティティとしての認識が強化されます。通常はトップページかフッターに一度だけ実装します。
BreadcrumbList（パンくずリスト）
サイト内の階層構造を記述します。検索結果のURL表示がパンくず形式になるほか、AIがサイト構造を把握する手がかりにもなります。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "トップ",
"item": "https://www.example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "カテゴリ名",
"item": "https://www.example.com/category/"
},
{
"@type": "ListItem",
"position": 3,
"name": "現在の記事タイトル",
"item": "https://www.example.com/category/article/"
}
]
}
</script>
positionは階層の順番（1から始まる整数）、itemはそのページのURLです。最下層（現在のページ）はitemを省略できますが、記述しておいた方がGoogleが認識しやすくなります。
@graph形式で複数スキーマをまとめて書く方法
1つのページにArticle・FAQPage・BreadcrumbList・Organizationをそれぞれ別々の<script>タグで書いてもGoogleは認識しますが、@graph形式を使うと1つの<script>にまとめて、スキーマ間の関係を明示できます。
Technogramでもクライアントサイトおよび自社サイトで@graph形式を採用しています。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Article",
"@id": "https://www.example.com/category/article/#article",
"headline": "記事タイトル",
"url": "https://www.example.com/category/article/",
"datePublished": "2026-01-15",
"dateModified": "2026-03-31",
"author": {
"@type": "Person",
"name": "著者名",
"url": "https://www.example.com/about/"
},
"publisher": {
"@id": "https://www.example.com/#organization"
},
"image": {
"@type": "ImageObject",
"url": "https://www.example.com/アイキャッチ画像.jpg"
}
},
{
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "会社名",
"url": "https://www.example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.example.com/logo.png"
}
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "トップ",
"item": "https://www.example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "カテゴリ名",
"item": "https://www.example.com/category/"
},
{
"@type": "ListItem",
"position": 3,
"name": "記事タイトル",
"item": "https://www.example.com/category/article/"
}
]
},
{
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "質問文1",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文1。"
}
},
{
"@type": "Question",
"name": "質問文2",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答文2。"
}
}
]
}
]
}
</script>
@graphの中に各スキーマを{}で並べ、カンマで区切る形式です。@idを使うと「この記事のpublisherはOrganizationの@idで指定した組織」という形で参照でき、同じ情報を何度も書かずに済みます。@contextは外側に1回書けば@graph内のすべてのスキーマに適用されます。
WordPressへの設置はどうやるのか？
カスタムHTMLブロックで記事末尾に直書きする方法（FAQPage用）
WordPressのブロックエディタ（Gutenberg）を使っている場合、最もシンプルな設置方法がカスタムHTMLブロックへの直書きです。特にFAQPageは記事ごとに内容が変わるため、この方法が実用的です。
手順
- 投稿の編集画面を開く
- 記事末尾（FAQセクションの直後が理想）にブロックを追加
- 「カスタムHTML」ブロックを選択
- 上記のFAQPageのJSON-LDコードをそのまま貼り付け
- 更新を保存し、リッチリザルトテストで検証
カスタムHTMLブロックは<head>ではなく<body>内に出力されますが、Googleは<body>内のJSON-LDも問題なく認識します。
テーマ・プラグインが自動出力するスキーマとの使い分け
SWELLを含む多くのWordPressテーマは、Article・BreadcrumbListなどを自動的に出力します。また、Yoast SEOやAll in One SEOなどのプラグインも同様です。
自動出力との重複に注意が必要です。 同じタイプのスキーマが複数出力されてもGoogleはエラーとして扱いませんが、内容が矛盾する場合は混乱を招きます。まず自サイトに何が出力されているかをSchema Markup Validatorで確認してから、手動で追加するスキーマを判断してください。
実務上の整理は以下の通りです。
| スキーマタイプ | 設置方法の推奨 |
|---|---|
| Article | テーマ・プラグインが出力している場合はそちらに任せる。出力されていなければ手動追加 |
| BreadcrumbList | テーマのパンくず設定で自動出力されるケースが多い。重複確認をしてから対応 |
| Organization / WebSite | プラグインで設定するか、テーマのカスタムコード欄に直書き（全ページ共通） |
| FAQPage | 記事ごとに内容が変わるため、カスタムHTMLブロックで各記事に手動追加が基本 |
実装後に必ずやる検証3ステップ
構造化データは「書いて終わり」ではありません。 構文エラーや必須プロパティの漏れがあると無効化されます。
①リッチリザルトテストでエラーチェック
リッチリザルトテスト（Google公式）にURLを入力します。「Article」「FAQPage」などがタイプとして「検出済み」と表示されれば基本的な実装は成功です。
エラー（Error）は必ず修正が必要です。警告（Warning）は推奨プロパティの不足を示すもので、必須ではありませんが対応できるものは対応してください。
②Schema Markup Validatorで網羅性チェック
Schema Markup Validatorでは、Schema.orgの仕様に沿って記述が正しいかを詳細に検証できます。
リッチリザルトテストでは見つからない細かい記述ミスや、プロパティ値の型の不一致なども検出されます。リッチリザルトテストと合わせて使うことで、実装の精度が上がります。
競合サイトのURLをここに入力すると、競合が実装しているスキーマタイプも確認できます。
③Google Search Consoleで運用監視
実装直後だけでなく、定期的にGoogle Search Console（GSC）の「拡張」メニューを確認する習慣をつけてください。構造化データの認識状況・警告・エラーが一覧で表示されます。
Googleがページを再クロールするまでGSCに反映されないため、実装後すぐに表示されないことがあります。数日〜2週間程度は待ってから確認するのが現実的です。テクニカルSEO全体の観点についてはテクニカルSEO完全ガイド｜診断・優先施策・実装手順を実務で解説【チェックリスト30項目】もあわせてご覧ください。
よくある書き方ミスと対処法
Technogramがクライアントサイトを診断する際、構造化データの問題は驚くほど多く見られます。代表的な3つを紹介します。
ページに存在しないコンテンツをスキーマに書いている
「FAQPageで質問と回答をスキーマに書いたが、ページ本文にFAQセクションがない」というケースです。
Googleのガイドラインは、スキーマの内容と実際のページに表示されている内容が一致することを求めています。 ページに存在しないコンテンツをスキーマに書くと、スパムとして扱われリッチリザルトの対象から除外されるリスクがあります。
コンテンツを先に書き、そのコンテンツをスキーマに写す順番が正しいです。
datePublishedを更新のたびに書き換えている
記事を更新するたびにdatePublishedを更新日に書き換えてしまうケースです。
datePublishedは最初の公開日です。更新のたびに変わるのはdateModifiedだけで、datePublishedは初公開日から変えてはいけません。記事の公開履歴をGoogleに正しく伝えるために、この2つのプロパティは役割が違います。
構文エラー（カンマ・括弧）で全体が無効化している
JSONはカンマの位置と括弧の対応が厳密な形式です。たとえば以下のようなミスで全体が無効になります。
// NG例：最後の要素の後ろにカンマがついている
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事タイトル", ← ここのカンマが不要
}
// NG例：閉じ括弧の対応がずれている
{
"@context": "https://schema.org",
"@type": "Article",
"author": {
"@type": "Person",
"name": "著者名"
} ← ここで閉じてしまい、全体の閉じ括弧が不足
手書きで記述する場合は必ずリッチリザルトテストで検証してください。Visual Studio CodeなどのエディタでJSONの整形・検証機能を使うのも有効です。
まとめ
この記事のポイントを整理します。
- JSON-LDの骨格は
@contextと@typeから始まる。 この2つがなければスキーマとして認識されない - Article・FAQPage・Organization・BreadcrumbListが基本セット。
@graph形式でまとめると関係が明示できる - FAQリッチリザルトは2026年5月に終了。 ただしFAQPageスキーマ自体のAI引用効果は継続中
- WordPressでのFAQPage設置はカスタムHTMLブロックが最もシンプル。 テーマ・プラグインとの重複は事前に確認する
- 実装後の検証3ステップ（リッチリザルトテスト → Schema Markup Validator → GSC）は省略厳禁
構造化データの実装は、一度やり方を覚えれば記事ごとに5〜10分で追加できる作業です。まずはArticleとFAQPageのテンプレートをコピーし、1記事に試してみてはいかがでしょうか。
よくある質問（FAQ）
Q. JSON-LDはHTMLのどこに書けばいいですか？
<head>タグ内が一般的ですが、<body>内でも問題なくGoogleに認識されます。WordPressのブロックエディタで記事ページのFAQPageを追加する場合は、カスタムHTMLブロックで本文末尾に書く方法が最も手軽です。
Q. 複数のスキーマタイプを1記事に入れていいですか？
はい。むしろ推奨されます。Article + FAQPage + BreadcrumbListを1ページに実装するのは一般的な手法です。それぞれ独立した<script>タグで記述するか、@graph形式で1つにまとめる方法が使えます。
Q. WordPressのSEOプラグインが入っている場合はどうすればいいですか？
まずSchema Markup Validatorで自サイトに何が出力されているかを確認してください。Yoast SEOやAll in One SEOはArticle・Organizationなどを自動出力します。重複しているタイプは手動で追加不要です。自動出力されていないFAQPageを追加するのが最初の一手です。
Q. 構造化データを書いたのにGSCに表示されないのはなぜですか？
GoogleがページをクロールしてGSCに反映するまで、数日〜2週間程度かかります。実装直後は表示されないのが通常です。リッチリザルトテストでエラーが出ていなければ、しばらく待ってから再確認してください。それでも表示されない場合は、必須プロパティの漏れやコンテンツとの不一致を疑います。
Q. FAQPageスキーマはリッチリザルトが終了したなら入れても意味がないですか？
意味はあります。FAQリッチリザルト（検索結果上のQ&A展開表示）は2026年5月に終了しましたが、FAQPageスキーマ自体はAI検索（Google AI Overview・ChatGPT・Perplexity）がページの内容を把握するためのシグナルとして機能しています。AIO・LLMO対策の観点では引き続き実装する価値があります。
