構造化データを書こうとして、Schema.org のドキュメントを開いた瞬間、英語の仕様書と大量の型定義に圧倒されたこと、ありませんか？
今回この記事を書くにあたって、自分のサイト（フロントエンドノート）にも FAQPage と BreadcrumbList を実装してみました。最初は型の多さに迷いましたが、実は「最低限知っておけば書ける3点セット」だけで動くと分かりました。
この記事では @context / @type / プロパティの3点セットだけに絞り、コピペで動くサンプルから入ります。FAQPage と BreadcrumbList をハンズオン形式で実装し、最後に WordPress 組み込みと検証ツールでの確認まで一気通貫で解説します。「概念から知りたい」という方は、先に AEO対策とは？SEOとの違いとWeb制作者が今すぐできること を読んでいただくと、本記事の位置づけがより理解しやすいと思います。
- JSON-LDの基本構文（
@context/@type/ プロパティ）の読み書き - FAQPage 構造化データの実装（コピペ用フルコード付き）
- BreadcrumbList 構造化データの実装（パンくずリストの構造化）
- WordPress でのJSON-LD組み込み方法（カスタムHTMLブロック方式 / functions.php 方式）
- 書いたJSON-LDをリッチリザルトテスト・Schema.org Validator で検証する手順
- そもそもJSON-LDって何？ — Schema.orgとの関係を整理する
- JSON-LDの基本構文 — 3点セットだけ覚える
- FAQPage 構造化データの書き方（コピペで動くフルコード付き）
- BreadcrumbList 構造化データの書き方（パンくずリストの構造化）
- その他に押さえておきたいSchema.orgタイプ — Article / WebSite / Organization
- WordPressへの組み込み方法 — カスタムHTMLブロック vs functions.php
- 書いたJSON-LDを検証する — リッチリザルトテスト・Schema.org Validator
- よくある質問（FAQ）
- まとめ
そもそもJSON-LDって何？ — Schema.orgとの関係を整理する
実装に入る前に、よく混同される4つの用語を整理しておきます。
- 構造化データ: ページの内容を機械が読みやすい形で書き加える「概念」全体
- JSON-LD: 構造化データを書くための「記述形式」のひとつ（他に Microdata / RDFa がある）
- Schema.org: 構造化データで使う「語彙（タイプとプロパティの辞書）」
- リッチリザルト: 構造化データを読み取った Google が検索結果を装飾表示する「結果」
つまり「Schema.org という辞書を使って、JSON-LD という書き方で、構造化データを書く。その結果としてリッチリザルトが出ることがある」という流れです。
Google が JSON-LD を推奨する理由は、HTMLマークアップとは別の場所に独立して書けるため、既存のデザインを壊さずに追加できるからです。構造化データを入れると、(1)リッチリザルト表示対象になる、(2)AEOの引用ソースに選ばれやすい、(3)ナレッジパネル等の補助情報に寄与する、といった効果が期待できます。
ただし Google は構造化データに関する一般的なガイドラインの中で「Google ウェブ検索でのページの掲載順位には影響しません」と明言しています。順位を上げる魔法ではなく、「Google にページ内容を正確に伝える言語」と捉えるのが正確です。
JSON-LDの基本構文 — 3点セットだけ覚える
Schema.org のドキュメントは膨大ですが、JSON-LD の構造自体は驚くほどシンプルです。次の3要素だけ押さえれば書き始められます。
@context: どの語彙集を使うかを宣言する。Schema.org を使う場合は固定で"https://schema.org"@type: 何の型を表現するかを宣言する。FAQPageBreadcrumbListArticle等- 各プロパティ: その型ごとに定義された情報項目（
nameurlmainEntity等）
サイト運営者情報の最小サンプルはこれだけです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "フロントエンドノート",
"url": "https://frontend-note.blog/"
}
</script><script type="application/ld+json"> の囲み忘れに注意
JSON-LDは <script> タグに type="application/ld+json" を指定して囲みます。ld+ は「Linked Data」の略です。type 指定を忘れたり application/json と書いたりすると、Google は認識できません。
<!-- NG: ld+ が抜けている -->
<script type="application/json">
{ "@context": "https://schema.org", "@type": "Organization", "name": "フロントエンドノート" }
</script>application/json のままでは Google が構造化データとして認識しません。必ず application/ld+json を指定してください。
<!-- OK -->
<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Organization", "name": "フロントエンドノート" }
</script>検証ツールで「構造化データが見つかりません」と言われたときは、まずここを疑ってみてください。
入れ子・配列の使い分け
Schema.org の型はプロパティの値として「別のオブジェクト」も持てます。FAQPage は mainEntity に「Question オブジェクトの配列」を持つ、といった具合です。複数あるものは [...]（配列）、単一のものは {...}（オブジェクト）で表現する、と覚えれば迷いません。入れ子の中の各オブジェクトにも @type を書くのがポイントです。
FAQPage 構造化データの書き方（コピペで動くフルコード付き）
最も需要の高い FAQPage から実装していきます。階層構造は、FAQPage → mainEntity（配列）→ Question ×繰り返し → acceptedAnswer → Answer → text です。
コピペ用フルコード（質問3件版）
下記をそのまま <head> または <body> の任意の位置に貼り付ければ動きます。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "構造化データを入れるとSEO順位は上がりますか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "構造化データはランキング要因ではないとGoogleが明言しています。ただし、リッチリザルト表示やAI検索の引用ソースとしての選ばれやすさには寄与すると考えられています。"
}
},
{
"@type": "Question",
"name": "JSON-LDはどこに書けばいいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "<head>タグ内が一般的ですが、<body>内のどこに書いてもGoogleは認識します。WordPressの場合はカスタムHTMLブロックに貼る方法と、functions.phpでwp_headに注入する方法があります。"
}
},
{
"@type": "Question",
"name": "1ページに複数のJSON-LDを入れていいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "問題ありません。FAQPageとBreadcrumbListを別々の<script>で記述するのは一般的なパターンです。"
}
}
]
}
</script>自サイト用に書き換える5ステップ
<script>ブロック全体をコピーして自サイトに貼り付けname（質問文）を自サイトの実際の質問に書き換えるacceptedAnswer.text（回答文）を自サイトの実際の回答に書き換える- 質問の数に合わせて
{ "@type": "Question", ... }ブロックを増減する - 表示されている FAQ の文言と完全に一致しているかをチェックする
よくあるミス — HTMLタグとクォート衝突
回答文内に HTML タグを入れること自体は許可されていますが、JSON の " と属性のクォートが衝突しないよう注意が必要です。シンプルにいきたい場合はテキストのみで書くのが確実です。
NG: "text": "詳細は<a href="/contact/">お問い合わせ</a>をご覧ください。"
OK: "text": "詳細は<a href=\"/contact/\">お問い合わせ</a>をご覧ください。"ブラウザ上の HTML としてはシングルクォート（<a href='/contact/'>）でも動きますが、JSON 文字列内ではダブルクォートを \" でエスケープする方法に統一するのがおすすめです。HTML/JSON のルールが両方守れて、後から見たときに混乱しません。
表示内容と JSON-LD を完全一致させる
Google ガイドラインは「ページ本文に表示されている FAQ と JSON-LD の内容が一致していること」を求めています。表示にない質問を JSON-LD だけに書くとガイドライン違反になり、リッチリザルト対象から外されることがあります。
補足: Google は2023年以降、FAQ リッチリザルトの表示対象を「公的機関や医療系など一部のみ」に限定しています。リッチリザルト目当てというより、AEO・サイト品質の観点で実装するのが現実的です。
公式仕様の詳細は次を参照してください。
BreadcrumbList 構造化データの書き方（パンくずリストの構造化）
多くの WordPress テーマ（XWRITE 含む）はパンくずリストを画面表示してくれますが、構造化データまで自動出力しているとは限りません。表示と構造化は別レイヤーなので、自分で補完します。
構造はシンプルで、BreadcrumbList → itemListElement（配列）→ ListItem ×階層数 → position（連番）/ name（階層名）/ item（URL）です。
コピペ用フルコード（3階層）
「ホーム → カテゴリー → 記事」の3階層をパンくずで構造化する例です。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "ホーム",
"item": "https://frontend-note.blog/"
},
{
"@type": "ListItem",
"position": 2,
"name": "SEO",
"item": "https://frontend-note.blog/category/seo/"
},
{
"@type": "ListItem",
"position": 3,
"name": "FAQPage・BreadcrumbList 構造化データの書き方",
"item": "https://frontend-note.blog/structured-data-jsonld/"
}
]
}
</script>実装時のポイント3つ
positionは1始まりの連番: 0スタートはNG。Schema.org 仕様に従うitemには絶対URLを書く: 相対パスはNG。最後の階層（現在ページ）にも自身のURLを書く- テーマがパンくずを表示していても構造化データは別途必要: 表示と構造化は別レイヤー。ただしテーマやプラグインがすでに BreadcrumbList の JSON-LD を出力していないか、リッチリザルトテストで確認してから実装する（二重出力回避）
4階層版への拡張
サブカテゴリーがある場合は position を1つずつずらして追加するだけです。
<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": "Web制作", "item": "https://example.com/web/" },
{ "@type": "ListItem", "position": 3, "name": "WordPress", "item": "https://example.com/web/wordpress/" },
{ "@type": "ListItem", "position": 4, "name": "記事タイトル", "item": "https://example.com/web/wordpress/article-slug/" }
]
}
</script>公式仕様の詳細は次を参照してください。
その他に押さえておきたいSchema.orgタイプ — Article / WebSite / Organization
FAQPage と BreadcrumbList を押さえたら、次のステップとして覚えておきたい型を簡単に紹介します。
Article / BlogPosting
ブログ記事や報道記事の構造化に使う型です。記事タイトル・著者・公開日・更新日といった「記事メタ情報」を、機械が読める形で Google に伝えます。
多くの SEO プラグイン（Yoast、Rank Math 等）が自動生成しているため、手書きで追加する場面は限定的です。ただし、自前テーマで SEO プラグインを使わない場合や、テーマ自動生成の内容を補完したい場合（例: dateModified が記事更新時に追従しない、publisher.logo が出ていない等）は、手書きで補う必要があります。
下記は Google が推奨するプロパティを過不足なく入れた、実用版の BlogPosting サンプルです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "FAQPage・BreadcrumbList 構造化データの書き方",
"image": "https://frontend-note.blog/wp-content/uploads/structured-data-thumbnail.png",
"datePublished": "2026-04-25T10:00:00+09:00",
"dateModified": "2026-04-25T10:00:00+09:00",
"author": {
"@type": "Person",
"name": "Kuroda"
},
"publisher": {
"@type": "Organization",
"name": "フロントエンドノート",
"logo": {
"@type": "ImageObject",
"url": "https://frontend-note.blog/wp-content/uploads/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://frontend-note.blog/structured-data-jsonld/"
}
}
</script>
<!-- image / logo のURLは自サイトのアイキャッチ・ロゴに差し替えてください -->各プロパティの役割は次のとおりです。
headline: 記事タイトル。本文 H1 と一致させる（110文字以内が Google公式の推奨。長いタイトルは省略版を入れる）image: アイキャッチ画像のURL。絶対URL推奨（Google は1200px幅以上を推奨）datePublished/dateModified: ISO 8601 形式（+09:00で JST を明示）author: 個人運営ならPerson、複数執筆や法人運営ならOrganizationを使い分けるpublisher: 発行元。logoは Google がリッチリザルト表示で参照する可能性ありmainEntityOfPage.@id: その記事自身のURL（カノニカルURLと一致させる）
実装時の注意:
dateModifiedは記事を更新するたびに必ず書き換える。古いまま放置すると「Google には更新したと伝わらない」状態になるauthorをPersonで書く場合、可能ならurlプロパティで著者プロフィールページへリンクするとエンティティ評価が安定しやすい- SEO プラグイン併用時は二重出力にならないよう、リッチリザルトテストで既存出力を確認してから追加する
WebSite — サイト全体の検索ボックス構造化
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "フロントエンドノート",
"url": "https://frontend-note.blog/"
}
</script>サイト内検索を Google 検索結果から使えるようにする場合は、potentialAction で SearchAction を追加します（詳細は公式仕様参照）。
Organization — 運営者情報
フリーランスの場合は Organization の代わりに Person 型を使うこともできます。logo プロパティは Google が推奨している項目で、ナレッジパネル等で利用される可能性があります。本記事の他の最小例では省略していますが、Organization を実装する場合は併せて入れておくのがおすすめです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Kuroda Code",
"url": "https://frontend-note.blog/",
"logo": "https://frontend-note.blog/wp-content/uploads/logo.png"
}
</script>ガイドラインの大原則「表示されている情報だけを構造化する」を守り、SEO プラグイン併用時はリッチリザルトテストで重複出力を確認してください。
WordPressへの組み込み方法 — カスタムHTMLブロック vs functions.php
「コードは書けたけど、WordPress のどこに貼ればいいの？」を解消します。主な方法は2つです。
方法A — 投稿・固定ページの「カスタムHTMLブロック」に貼る
ページ単位（特定の記事だけに入れたい場合）に向く方法です。投稿の編集画面でブロック追加 →「カスタムHTML」ブロックを選び、<script type="application/ld+json">...</script> をそのまま貼り付けて保存するだけです。
メリット: ページごとに内容を変えられる。FAQPage のように記事ごとに異なる FAQ に向く。
デメリット: 全記事共通で入れたい場合は手作業の繰り返しになる。
方法B — functions.php で wp_head フックに注入
サイト全体・全記事に共通で入れたい場合（BreadcrumbList・Organization など）に向く方法です。子テーマの functions.php を編集します。
ポイントは、JSON-LD を PHP 配列で組み立ててから wp_json_encode() で出力すること。サイト名やカテゴリー名にダブルクォート（"）や < などが混ざっていても自動的にエスケープされ、JSON が壊れる事故や XSS のリスクを避けられます。
<?php
// 全記事の<head>にOrganization構造化データを出力する例
function fn_output_organization_jsonld() {
$data = [
'@context' => 'https://schema.org',
'@type' => 'Organization',
'name' => get_bloginfo('name'),
'url' => home_url('/'),
];
echo '<script type="application/ld+json">'
. wp_json_encode( $data, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE )
. '</script>' . "\n";
}
add_action( 'wp_head', 'fn_output_organization_jsonld' );
// 投稿ページだけに出したい場合は条件分岐で絞り込む
function fn_output_breadcrumb_jsonld_single_only() {
if ( ! is_single() ) return;
$items = [];
$items[] = [
'@type' => 'ListItem',
'position' => 1,
'name' => 'ホーム',
'item' => home_url('/'),
];
// 主カテゴリーを1つだけ取得して2階層目に
$cats = get_the_category();
if ( ! empty( $cats ) ) {
$cat = $cats[0];
$items[] = [
'@type' => 'ListItem',
'position' => 2,
'name' => $cat->name,
'item' => get_category_link( $cat->term_id ),
];
}
// 現在の記事を最終階層に
$items[] = [
'@type' => 'ListItem',
'position' => count( $items ) + 1,
'name' => get_the_title(),
'item' => get_permalink(),
];
$data = [
'@context' => 'https://schema.org',
'@type' => 'BreadcrumbList',
'itemListElement' => $items,
];
echo '<script type="application/ld+json">'
. wp_json_encode( $data, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE )
. '</script>' . "\n";
}
add_action( 'wp_head', 'fn_output_breadcrumb_jsonld_single_only' );JSON_UNESCAPED_SLASHES は URL の / が \/ にエスケープされるのを防ぎ、JSON_UNESCAPED_UNICODE は日本語をそのまま出力するためのオプションです。検証ツールでの可読性が上がります。
メリット: 全記事に一括反映できる。is_single() 等の条件分岐で「投稿だけ」「特定カテゴリーだけ」と細かく制御できる。
デメリット: PHPに不慣れな方は慎重に。子テーマ運用が前提。
方法Aと方法Bの使い分け
| ケース | 推奨方法 | 理由 |
|---|---|---|
| FAQPage | 方法A（カスタムHTMLブロック） | 記事ごとに FAQ 内容が違うため |
| BreadcrumbList | 方法B（functions.php） | 全記事共通の階層構造のため |
| Organization | 方法B（functions.php） | サイト全体で1つのみ |
重要:
functions.phpの編集は子テーマで行うことを強く推奨します。親テーマを直接編集するとアップデート時に消えます。
プラグイン任せにしない選択肢を持っておくと、細かい調整・プラグイン依存の低減・学習価値、といったメリットがあります。SEO プラグイン併用時はFAQで触れる「重複出力」に注意してください。
書いたJSON-LDを検証する — リッチリザルトテスト・Schema.org Validator
「コードは書けたけど合ってるか分からない」を解消するのが検証ツールです。代表的な2つを使い分けます。
- Googleリッチリザルトテスト: Google が「リッチリザルト対象として認識する型か」を検証。ページURL または「コードスニペット」タブにJSON-LDを直接貼り付けて確認できる
- Schema.org Validator: Schema.org 仕様への準拠を検証。リッチリザルト対象でない型（WebSite・Organization 等）もチェックできる
ページURL での検証は公開後しかできないので、開発中はコードスニペット貼り付けで先に確認しておくとスムーズです。
WebSite や Organization のように「Schema.org 仕様にはあるが Google のリッチリザルト対象ではない」型を書いた場合、リッチリザルトテストでは「対応していない」と表示されますが、Schema.org Validator なら正しさをチェックできます。両方使うのが安心です。
よくあるエラーと対処
| エラー・警告 | 原因 | 対処 |
|---|---|---|
| 必須プロパティ欠落 | 型に必須の項目が抜けている | 該当プロパティを追加する |
| 型の指定ミス | @type の名前が間違っている | Schema.org の正式名と一致させる |
| URL形式の誤り | item に相対パスを入れている | 絶対URLに修正 |
| 構造化データが見つかりません | <script> 囲み忘れ・type指定ミス | 囲みと type 属性を確認 |
よくある質問（FAQ）
このFAQセクション自体を、FAQPage構造化データで実装しています。表示Q&Aと完全一致するJSON-LDコードも下に掲載しているので、「どう書けば動くか」の実例として参照してください。
- SEOプラグインの自動生成と手書きJSON-LDは併用していいですか？
技術的には可能ですが、同じ型を二重出力すると検索エンジンが混乱する可能性があります。プラグインがどの型を自動生成しているかをリッチリザルトテストで確認し、重複しないタイプだけを手書きで補うのが現実的だと感じています。
- 構造化データを入れたら検索順位は上がりますか？
構造化データはランキング要因ではないとGoogleが明言しています。ただし、リッチリザルト表示によるクリック率向上や、AI検索（AEO）における引用ソースとしての選ばれやすさには寄与すると考えられています。
- ページに表示されていない情報をJSON-LDに書いてもいいですか？
Googleガイドラインで明確に禁止されています。表示内容と構造化データの内容は一致させるのが原則で、違反するとペナルティを受ける可能性があります。
- 1ページに複数の
<script type="application/ld+json">を入れていいですか？ 問題ありません。FAQPageとBreadcrumbListを別々の
<script>で記述するのは一般的です。1つにまとめる場合は@graphを使う方法もありますが、複数<script>の方が読みやすいケースが多いと感じています。
このFAQセクションに対応するFAQPage JSON-LD（実装デモ）
上記4問のFAQをFAQPage構造化データとして表現したJSON-LDが下記です。このページのカスタムHTMLブロックにそのまま貼り付けています。
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "SEOプラグインの自動生成と手書きJSON-LDは併用していいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "技術的には可能ですが、同じ型を二重出力すると検索エンジンが混乱する可能性があります。プラグインがどの型を自動生成しているかをリッチリザルトテストで確認し、重複しないタイプだけを手書きで補うのが現実的だと感じています。"
}
},
{
"@type": "Question",
"name": "構造化データを入れたら検索順位は上がりますか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "構造化データはランキング要因ではないとGoogleが明言しています。ただし、リッチリザルト表示によるクリック率向上や、AI検索（AEO）における引用ソースとしての選ばれやすさには寄与すると考えられています。"
}
},
{
"@type": "Question",
"name": "ページに表示されていない情報をJSON-LDに書いてもいいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "Googleガイドラインで明確に禁止されています。表示内容と構造化データの内容は一致させるのが原則で、違反するとペナルティを受ける可能性があります。"
}
},
{
"@type": "Question",
"name": "1ページに複数の <script type=\"application/ld+json\"> を入れていいですか？",
"acceptedAnswer": {
"@type": "Answer",
"text": "問題ありません。FAQPageとBreadcrumbListを別々の <script> で記述するのは一般的です。1つにまとめる場合は @graph を使う方法もありますが、複数 <script> の方が読みやすいケースが多いと感じています。"
}
}
]
}これを <script type="application/ld+json">...</script> で囲んでカスタムHTMLブロックに貼り付けた状態で、リッチリザルトテストで「有効」と判定されることを確認しています。「表示Q&A」と「JSON-LDのname・text」が完全一致している点がガイドライン準拠のポイントです。
なぜFAQPageだけ手書きしているのか — SEOプラグインの自動出力との役割分担
「BreadcrumbListやArticleも手書きしないといけないの？」と思った方向けに、実運用での補足です。
Rank Math SEO や Yoast SEO といった主要なSEOプラグインを入れている場合、Article / BlogPosting / BreadcrumbList / WebSite / Organization といった代表的な型は自動で出力されています。一方で FAQPage は SEOプラグインが自動生成しない型のひとつで、手書きで実装する必要があります。本記事でFAQPageを中心の実装デモとして扱ったのは、こうした実運用上の役割分担が背景にあります。
実例として、フロントエンドノートで Rank Math SEO を使っている別記事 Webコーダーが知っておきたいSEO内部対策6選 をリッチリザルトテストにかけてみたところ、こちらが何も書いていないのに BreadcrumbList / Article / BlogPosting の3つがエラーなしで自動検出されました。プラグインが裏で出力してくれていたわけです。
そのため、実装に取りかかる前に 自サイトのページをリッチリザルトテストで一度確認し、すでに出力されている型と、まだ出力されていない型を切り分けることをおすすめします。すでに出ている型を手書きで重ねて追加すると、本文中の「H2-5 Article末尾の注意」「H2-6 二重出力に注意」で触れた重複出力の問題に直結します。足りない型だけ手書きで補うのが、SEOプラグイン併用環境での現実的な進め方だと感じています。
公式参考: 構造化データと検索順位の関係について詳しくは、Google検索セントラルの構造化データに関する一般的なガイドラインを参照してください。
まとめ
JSON-LDは構文だけ見れば驚くほどシンプルです。@context / @type / プロパティの3点セットさえ押さえれば、Schema.orgの膨大なドキュメントに圧倒されることなく書き始められます。
- 基本構文: 3点セット +
<script type="application/ld+json">での囲み - FAQPage: コピペ用フルコードから書き換え。表示内容と完全一致
- BreadcrumbList:
positionは1始まり連番。テーマ表示と構造化は別レイヤー - WordPress組み込み: ページ単位はカスタムHTMLブロック、サイト全体は functions.php
- 検証: リッチリザルトテストとSchema.org Validatorの両方でチェック
まずは FAQPage か BreadcrumbList の どちらか1つ をコピペから始めて、自サイトで動かしてみるのがおすすめです。検証ツールで「有効」と表示された瞬間、構造化データの仕組みが体で理解できると思います。構造化データは、AIにサイトを正しく説明するための「機械が読める形式での自己紹介」のようなもの。ぜひ手を動かしてみてください。
関連記事
- AEO対策とは？SEOとの違いとWeb制作者が今すぐできること — 構造化データの「概念編」
- Webコーダーが知っておきたいSEO内部対策6選 — 実装目線でできるSEO内部対策6項目を解説。構造化データの位置付けにも触れています
- Contact Form 7 のラジオボタンで2回つまずいた話 — 同じくWordPress実装系の記事
