「良い記事を書いたのに、思ったように伝わっていない気がする」——そう感じたことはないでしょうか。
前回の記事で、AIや検索エンジンは文章の「行間」を読めない、という話をしました。書かれていない意図は、機械には伝わりません。会社名も、サービス内容も、記事の中身も、機械にとっては「たぶんこうだろう」という推測のままです。
その推測を「確定」に変えるのが、構造化データという仕組みでした。今回はその続きです。実際にどの構造化データを使えばよいのか、そして「正しく入っているか」をどう確認するのか。ここを、コードが読めなくても判断できる形でまとめます。
先に安心していただきたいことがあります。これらを一つひとつ覚える必要はありません。 中身は数行のメモのようなもので、正しく一度だけ入っていれば、それでいいものです。最後に、無料ツールにURLを入れるだけで確認できる方法もお伝えします。
1. 構造化データは「機械に渡す短いメモ」
構造化データとは、ページに書かれている情報が「何を意味するのか」を、機械が読める形で添えておく短いメモです。
たとえば同じ「2026年7月20日」という文字でも、人間なら文脈から「これは公開日だな」とわかります。機械にはそれがわかりません。そこで「これは公開日です」「これは著者名です」と、意味のラベルを添えておく。それが構造化データです。
書き方はいくつかありますが、今はJSON-LDという形式が推奨されています。 HTMLの本文とは切り離して、決まった枠の中にまとめて書ける形式で、あとから見返しやすく、間違いも起きにくいためです。この記事でもJSON-LDだけで統一してお見せします。
（以前はHTMLのタグ一つひとつに印を付けていく「Microdata」という書き方もありましたが、手で触ると崩れやすいので、今から新しく用意するならJSON-LDで十分です。）
2. 記事・コラムを伝える：Article
ブログやお知らせ、コラムなど、記事ページに使うのがArticleです。
「この記事は、いつ公開されて、いつ更新され、誰が書いた、何というタイトルの記事なのか」を機械に伝えます。前回お伝えした、最低限入れておきたい基本のひとつです。
中身はこれだけです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "記事のタイトル",
"image": "https://example.com/thumbnail.jpg",
"datePublished": "2026-07-20T09:00:00+09:00",
"dateModified": "2026-07-20T10:30:00+09:00",
"author": {
"@type": "Person",
"name": "著者名"
},
"publisher": {
"@type": "Organization",
"name": "会社名・サイト名"
}
}
</script>難しく見えるかもしれませんが、やっていることは「タイトル」「画像」「公開日」「更新日」「著者」「発行元（会社名）」を並べているだけです。一つひとつ覚える必要はありません。正しく一度入っていれば、それでいい。
ひとつだけ、間違えやすい点をお伝えします。ここは「Article」を使います。 似た名前で「NewsArticle」というものがありますが、これは新聞社などの報道記事向けの型です。一般の会社のコラムやブログを「ニュース」として機械に伝えてしまうと、意味がずれます。ブログだと明示したい場合は「BlogPosting」でも構いません。
（日付の末尾にある +09:00 は日本時間という意味です。海外の時刻になっていないか、ここだけ気にしておけば十分です。）
3. サイト内の現在地を伝える：パンくずリスト（BreadcrumbList）
「トップページ ＞ サービス一覧 ＞ Web制作」のような、今どの階層のページを見ているかを示す道しるべ。これがパンくずリストです。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/service/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Web制作"
}
]
}
</script>
position が階層の順番、name がページの名前、item がそのURLです。いちばん奥の「今見ているページ」はURLを省いて構いません。要は、ページの居場所を順番に並べているだけです。
4. よくある質問（FAQPage）：期待していいこと、いけないこと
よくある質問（FAQ）を載せているサイトは多いと思います。この質問と回答のまとまりを機械に伝えるのがFAQPageです。
ここで、正直にお伝えしておきたいことがあります。以前は、この記述を入れると検索結果に質問と回答が折りたたみ表示されました。でも今は、その表示はほぼ出ません。
Googleは2023年に、FAQのこの表示を「政府機関や医療系など、限られた公式サイト」だけに絞りました。一般の会社のサイトでは、書いても検索結果の見た目は変わりません。「検索結果を目立たせるため」という理由でこれを入れても、成果は出ません。ここは期待しないでください。
では、もう書く意味がないのかというと、そうとも言い切れません。見た目のためではなく、質問と回答の構造を機械に正しく伝えるためであれば、今も意味があります。AIや検索エンジンに「この会社は、この質問にこう答えている」と、推測ではなく確定情報として届けられるからです。
その目的で書くなら、中身はこれだけです。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "質問の文章",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答の文章"
}
},
{
"@type": "Question",
"name": "質問の文章",
"acceptedAnswer": {
"@type": "Answer",
"text": "回答の文章"
}
}
]
}
</script>Question が質問、acceptedAnswer の中の text がその回答です。質問の数だけ、この一組を増やしていくだけです。
5. 正しく入っているかを確認する方法
ここまでコードをお見せしましたが、冒頭でお伝えした通り、中身を覚える必要はありません。 大事なのは「正しく入っているか」を確認できることです。そして確認は、無料のツールにURLを入れるだけでできます。
① リッチリザルトテスト（Google公式） https://search.google.com/test/rich-results
自分のサイトのページURLを入れて実行すると、構造化データが正しく読み込まれているか、エラーがないかを教えてくれます。前回の記事でも紹介した、Googleが今いちばん案内しているツールです。
② スキーマ マークアップ バリデーター https://validator.schema.org
「Googleの検索結果に出るかどうか」はいったん置いて、schema.orgの書き方そのものが正しいかだけを見たいとき、こちらが使えます。
どちらも、URLを貼って実行するだけです。エラーが出なければ、機械に意味が正しく届いている、という目安になります。専門知識がなくても、ここまでは自分の目で確かめられます。
まとめ
最後に整理します。
- 記事・コラムには Article（NewsArticleではなく）
- ページの居場所には パンくずリスト（BreadcrumbList）
- よくある質問には FAQPage（検索結果の見た目は変わらない前提で、機械に構造を伝えるために）
- 書き方は JSON-LD に統一
- 確認は リッチリザルトテストにURLを入れるだけ
構造化データは、「検索対策」のためのテクニックではありません。機械に、自社の情報を推測ではなく確定で伝えるための、短い自己紹介です。一度正しく入れておけば、あとは機械の側が正しく読んでくれます。
とはいえ、「自分のサイトに何が入っていて、それが正しいのか」は、普段の画面を見ているだけでは気づきにくい部分です。わからなくても、それが普通です。
外から診て、直すべきところだけを指す。それが私の仕事だと考えています。もし必要でしたら、その相談相手になれれば幸いです。
