構造化データとは
SEOの構造化データとは、ページに書かれている内容（記事の題名・著者・公開日・パンくずなど）を、検索エンジンが読み取りやすい決まった形式で書き添えるコードです。項目の名前は schema.org という共通の語彙で決められていて、「これは記事で、題名はこれ、書いた人はこの人」という情報を、文章とは別に機械向けに伝えます。
「構造化データ」という言葉は、データ分析の分野では「表の形に整理されたデータ」という意味でも使われます。この記事で扱うのは、Webページに書き添える、SEOの構造化データです。
構造化データは、サイトの中で整える内部対策の1つです。内部対策の全体はSEOの内部対策のやり方でまとめています。
構造化データでできること・できないこと
構造化データを入れると、検索結果でリッチリザルト（特別な表示）の対象になり得ますが、表示も順位も保証されません。Google の「構造化データに関する一般的なガイドライン」では、正しくマークアップしても、リッチリザルトとして必ず表示されるとは限らないと説明されています。
| 項目 | 内容 |
|---|---|
| できること | ページの種類・題名・著者・日付などを正確に伝える。対応する種類なら、リッチリザルトの対象になる |
| できないこと | リッチリザルトの表示を約束する。構造化データだけで順位を上げる |
| AI検索との関係 | Google は、AIによる概要のために特別な構造化データは要らないと説明している |
Google がリッチリザルトに対応している種類は、「検索ギャラリー」に一覧があります。2026年10月時点では、記事・パンくずリスト・組織・商品・レシピ・イベント・求人情報・ローカル ビジネス・動画など25種類が載っています。
書き方は JSON-LD がおすすめ
Google は、書き方が3つある中で、実装と管理がしやすい JSON-LD をすすめています。JSON-LD は、ページの HTML の中に script タグを1つ置き、その中にまとめて書く方式です。
| 書き方 | 書く場所 | 向いている場合 |
|---|---|---|
| JSON-LD | script type="application/ld+json" の中 | ほとんどの場合（Google のおすすめ） |
| microdata | 本文の HTML タグの属性 | 既存のテンプレートが microdata で作られている |
| RDFa | 本文の HTML タグの属性 | 既存のテンプレートが RDFa で作られている |
JSON-LD は本文の HTML と分かれているため、デザインを変えても構造化データが壊れにくく、まとめて直せます。これから入れるなら JSON-LD を選びます。
記事ページに入れる基本の4つ
ブログやコラムの記事ページには、記事（BlogPosting）・パンくず（BreadcrumbList）・運営者（Organization）・著者（Person）の4つを入れれば足ります。どれも、ページに表示されている情報をそのまま書くものです。
記事（BlogPosting）
Google の「記事」の構造化データでは、使える種類は Article・NewsArticle・BlogPosting の3つで、必須の項目はありません。推奨の項目は、題名（headline）、著者（author）、公開日（datePublished）、更新日（dateModified）、画像（image）です。
| 項目 | 書くこと | Google の説明の要点 |
|---|---|---|
| headline | 記事の題名 | 簡潔に。長いと切られることがある |
| author | 著者（Person か Organization） | 名前だけを書く。複数人は1人ずつ配列にする |
| datePublished | 最初に公開した日時 | ISO 8601 の形式。タイムゾーンも書く |
| dateModified | 最後に更新した日時 | 中身を変えたときだけ更新する |
| image | 記事の画像の URL | 横長・4:3・正方形など、高解像度のものを複数 |
パンくず（BreadcrumbList）
パンくずは、「トップ ＞ カテゴリ ＞ 記事」のような、ページの位置を表すリストです。ページに表示しているパンくずと同じ順番・同じ名前で書きます。
運営者（Organization）と著者（Person）
運営者は会社の名前と URL、著者は名前とプロフィールページの URL を書きます。記事（BlogPosting）の author と publisher から、この2つを参照する形にすると、「誰が書き、誰が運営しているか」がまとまって伝わります。
実装の手順
構造化データは、入れる種類を決め、JSON-LD を書き、ページに入れ、リッチリザルト テストで確かめ、Search Console で見守る、の5つの手順で入れます。順番を飛ばさないことで、表示されない理由を後から探す手間が減ります。
- 入れる種類を決める：記事ページなら上の4つ。商品ページなら Product、店舗なら LocalBusiness など、ページに合うものを選びます。
- JSON-LD を書く：ページに表示されている題名・著者・日付・パンくずを、そのまま書き写します。
- ページに入れる：HTML の head か body に script タグで入れます。WordPress などの CMS なら、プラグインやテーマの機能で入ることが多いので、まず今のページに何が入っているかを確かめます。
- リッチリザルト テストで確かめる：公開した URL を入力して、エラーと警告を直します。
- Search Console で見守る：公開後は、Search Console のリッチリザルトのレポートで、エラーが出ていないかを確かめます。
記事の JSON-LD は、たとえば次のような形になります（簡単にした例）。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "構造化データの書き方｜JSON-LDの実装手順と確かめ方",
"datePublished": "2026-10-24T09:00:00+09:00",
"dateModified": "2026-10-24T09:00:00+09:00",
"author": { "@type": "Person", "name": "イカラシ", "url": "https://noren.blog/about/" },
"publisher": { "@type": "Organization", "name": "株式会社アップワード", "url": "https://up-ward.info/" },
"image": ["https://noren.blog/images/seo/structured-data/thumb.png"]
}
</script>
Google タグ マネージャーなどで JavaScript から入れる場合
構造化データは、Google タグ マネージャーなどを使って JavaScript で入れることもできます。Google の説明では、ページを表示した時点で有効な JSON-LD があれば処理できますが、確かめるときはリッチリザルト テストに URL を入力します。コードを貼り付けて試す方法では、JavaScript の処理に制限があるためです。
やってはいけないこと
ページに表示されていない内容をマークアップすること、事実と違う内容やレビューの捏造は、Google のガイドライン違反です。違反すると、手動による対策を受けて、リッチリザルトとして表示されなくなることがあります。
| やってはいけないこと | 例 | 正しいやり方 |
|---|---|---|
| ページに表示されていない内容を書く | ページに無いレビューの点数、隠した文章 | 表示している内容だけを書く |
| 事実と違う内容を書く | 架空の評価、ほかの会社のなりすまし | 実際の情報だけを書く |
| ページと関係のない種類を使う | 記事ではない一覧ページに Article | ページの主な内容に合う種類を選ぶ |
| robots.txt や noindex でページを止める | 構造化データを入れたページをクロールさせない | Googlebot が読める状態にする |
よくある質問（FAQPage）の構造化データはどうするか
2026年10月時点で、Google のリッチリザルトの一覧（検索ギャラリー）に「よくある質問」は無く、多くのサイトでは入れても検索結果に特別な表示は出ません。Google は2023年8月に、よくある質問のリッチリザルトを、よく知られた政府・医療のサイトに限ると発表しました。
一方で、同じ発表の中で、使われなくなった構造化データを消す必要は無く、残しても問題は起きないと説明されています。このブログでは、ページに表示しているよくある質問の内容と一致させたうえで、FAQPage を残しています。新しく入れる手間をかけるかどうかは、表示の効果を期待せずに判断します。
のれんでの実装例
このブログ（のれん）では、1つの script の中に @graph でまとめ、@id で組織・著者・サイト・記事をつなぐ書き方をしています。運営者や著者の情報を記事ごとに書き直さず、@id で同じものを指すため、どの記事でも同じ情報が伝わります。
| 種類 | @id | 主な項目 |
|---|---|---|
| Organization（運営者） | https://up-ward.info/#organization | 名前・URL・住所 |
| Person（著者） | https://noren.blog/about/#person | 名前・肩書き・説明・所属（運営者を参照） |
| WebSite（サイト） | https://noren.blog/#website | サイト名・説明・運営者と著者を参照 |
| WebPage（ページ） | 記事のURL#webpage | 題名・説明・公開日・更新日・パンくずを参照 |
| BlogPosting（記事） | 記事のURL#article | 題名・公開日・更新日・著者・運営者・画像・カテゴリ |
| BreadcrumbList（パンくず） | 記事のURL#breadcrumb | トップ ＞ カテゴリ ＞ 記事 |
のれんは、記事を公開するときに、この構造化データを静的な HTML に直接書き出しています。JavaScript で後から入れていないため、ページのソースを見れば、検索エンジンが読む内容をそのまま確かめられます。ページごとに入っている種類は、SEO診断のやり方で紹介しているスクリプトでも一度に確かめられます。
確かめ方
構造化データは、公開前にリッチリザルト テストと Schema Markup Validator で確かめ、公開後は Search Console のレポートで見守ります。2つのテストは役割が違うので、両方を使うと抜けが減ります。
| 道具 | 確かめること | 使い方 |
|---|---|---|
| リッチリザルト テスト（Google） | Google 検索のリッチリザルトに使える種類か、エラー・警告 | URL かコードを入力。初めはスマートフォンとして検査する |
| Schema Markup Validator（schema.org） | schema.org の書き方として正しいか | Google のリッチリザルトに無い種類（Person など）も確かめられる |
| Search Console | 公開後のエラー・警告の推移 | リッチリザルトのレポートを月に1回見る |
よくある質問
構造化データを入れると、検索順位は上がりますか？
構造化データだけで順位が上がるとは言えません。Google は、構造化データでリッチリザルトの対象になり得ると説明していますが、表示も順位も保証していません。ページの内容を正確に伝えるために入れるものと考えます。
WordPress でも手で書く必要がありますか？
多くの場合、テーマや SEO のプラグインが自動で入れています。まずリッチリザルト テストで今のページに何が入っているかを確かめ、足りないものや重複しているものだけを直します。
AI検索に出るには構造化データが必要ですか？
必須ではありません。Google は、AIによる概要に表示されるために特別な構造化データは要らないと説明しています。AI検索への対応は、AIO・LLMO対策のやり方でまとめています。
エラーと警告はどちらも直す必要がありますか？
エラーは直します。Search Console ヘルプでは、重大な問題（エラー）が1つでもあるとリッチリザルトとして表示できず、重大ではない問題（警告）は、表示はできるものの見え方を改善できる余地を示すものと説明されています。警告は、推奨の項目を足せるときに直します。
まとめ
構造化データは、次の順番で入れると迷いません。
- 構造化データは、ページの内容を検索エンジン向けの形式で書き添えるコード。書き方は JSON-LD
- 記事ページは、記事・パンくず・運営者・著者の4つで足りる
- ページに表示している内容だけを書く。見えない内容や事実と違う内容は書かない
- リッチリザルト テストは URL で確かめ、公開後は Search Console で見守る
- よくある質問のリッチリザルトは、2026年10月時点の Google の一覧に無い
