構造化データの基本｜検索エンジンにページ内容を正しく伝える実装方法
2026/08/25
リニューアル・運用ノウハウ構造化データとは？ページの意味を検索エンジンに伝える仕組み
構造化データとは、Webページに掲載されている情報を、検索エンジンが理解しやすい形式で記述するためのデータです。
例えば、ホームページに次のような情報が掲載されていたとします。
- 会社名
- 所在地
- 代表者
- ロゴ
- 電話番号
人間がページを見れば、「これは会社情報だ」と理解できます。
一方、検索エンジンに対して、
「これは会社名です」
「これは所在地です」
「これは会社のロゴです」
と、情報の意味まで明確に伝えるために使われるのが構造化データです。
Googleも、構造化データをページに関する情報を標準化して提供するデータ形式として案内しており、ページの内容をより正確に理解するために利用しています。
つまり構造化データは、簡単にいえば、
検索エンジンに渡す「ページの説明書」
のようなものです。
構造化データを入れるとSEO順位は上がる？
構造化データについてよくある誤解が、
「構造化データを設定すると検索順位が上がる」
という考え方です。
構造化データは、設定するだけで検索順位を直接上げるための仕組みではありません。
Googleが構造化データを利用する大きな目的の一つは、ページの内容を理解し、対応している場合にはリッチリザルトなどの検索機能へ利用することです。
流れを整理すると、次のようになります。
- 構造化データを実装する
- Googleがページの内容を理解しやすくなる
- 条件を満たせば、検索結果の表示方法が拡張される可能性がある
- 検索ユーザーにページ内容が伝わりやすくなる
構造化データは、順位を直接上げるための裏技ではなく、検索エンジンとの情報伝達を正確にするSEOの土台として考えましょう。
構造化データとリッチリザルトの関係
構造化データを理解するときに、一緒に覚えておきたいのがリッチリザルトです。
通常の検索結果よりも追加情報を含んだ表示を、Googleではリッチリザルトと呼びます。
構造化データを正しく実装することで、対応する検索機能へ表示される資格を得られる場合があります。
ただし、ここには重要な注意点があります。
構造化データを正しく実装しても、リッチリザルトとして表示される保証はありません。
Googleも、リッチリザルトテストで正しくマークアップされていても、実際の検索結果で拡張表示されることを保証していません。
検索内容や地域、端末など複数の要因によって、通常の検索結果が表示される場合もあります。
そのため、
「構造化データを入れたのに検索結果が変わらない＝失敗」
とは限りません。
企業サイトで検討したい代表的な構造化データ
Googleがサポートする構造化データには多くの種類があります。
企業サイトですべてを設定する必要はありません。
重要なのは、そのページに実際に存在する内容に合った構造化データだけを使うことです。
企業サイトでは、Organization、Breadcrumb、Article、LocalBusiness、JobPostingなどが代表的です。
Organization｜会社・組織情報を伝える
企業サイトでまず検討したいのがOrganizationです。
会社や組織に関する情報をGoogleへ伝えるための構造化データです。
例えば、
- 会社名
- URL
- ロゴ
- 所在地
- 電話番号
- 組織に関する情報
などを、サイトや組織の実態に合わせて記述します。
Googleは、Organization構造化データを追加することで、組織の情報をGoogleが理解しやすくなり、他の組織との識別にも役立つと説明しています。
企業サイトでは、サイト全体の運営主体を正確に伝えるという意味でも検討したい構造化データです。
Breadcrumb｜ページの階層構造を伝える
Breadcrumbは、いわゆるパンくずリストを検索エンジンへ伝える構造化データです。
例えば、
トップ ＞ サービス ＞ ホームページ制作
という階層です。
BreadcrumbListを利用することで、そのページがサイト内のどこに位置しているのかをGoogleへ伝えられます。
Googleも、パンくずリストはページのサイト階層上の位置を示し、ユーザーがサイト構造を理解・移動するうえで役立つと説明しています。
ページ数の多い企業サイト、オウンドメディア、サービスサイトなどでは特に相性のよい構造化データです。
Article｜ブログ・コラムの記事情報を伝える
オウンドメディアやブログを運用している場合は、Article系の構造化データを検討できます。
例えば、
- 記事タイトル
- 公開日
- 更新日
- 著者
- 画像
など、記事に関する情報を検索エンジンへ伝えます。
特に企業のオウンドメディアでは、
誰が書いたのか
いつ公開・更新されたのか
といった情報をページ上でも明確にし、構造化データの内容と一致させることが重要です。
LocalBusiness｜店舗・地域ビジネスの情報を伝える
飲食店、美容室、クリニック、工務店など、実店舗や地域との結びつきが強い事業では、LocalBusiness系の構造化データを検討できます。
業種やページ内容に応じて、
- 店舗名
- 所在地
- 営業時間
- 電話番号
- 業種
などを記述します。
ただし、構造化データを設定するだけでローカルSEOが強くなるわけではありません。
Googleビジネスプロフィール、サイト内の会社・店舗情報、実際の営業時間など、Web上の情報を正確かつ一貫させることが重要です。
JobPosting｜求人情報を伝える
採用サイトや求人ページを運営している企業では、JobPostingを検討できます。
求人内容に応じて、
- 職種
- 仕事内容
- 勤務地
- 雇用形態
- 給与
- 求人掲載日
などを記述します。
重要なのは、構造化データだけに情報を書かないことです。
ユーザーがページ上で確認できる求人情報と、構造化データの内容を一致させる必要があります。
Googleも、ユーザーから見えない情報や、ページの主な内容を正しく表していない情報を構造化データとしてマークアップしないよう案内しています。
構造化データの形式｜Googleが推奨するJSON-LDとは？
構造化データには、主に次の形式があります。
- JSON-LD
- Microdata
- RDFa
Googleはいずれもサポートしていますが、一般的にはJSON-LDが推奨されています。
HTMLの表示部分と分けて管理しやすく、実装や保守もしやすいことが特徴です。
JSON-LDは、例えばHTML内に次のような形で記述します。
<script type="application/ld+json">
企業サイトを運用する担当者が、コード自体をすべて覚える必要はありません。
重要なのは、
「どのページに、どの情報を構造化データとして設定しているのか」
を管理できる状態にしておくことです。
構造化データの基本的な実装手順
ページに合った構造化データを選ぶ
最初に、
「SEOに良さそうだから、とりあえずschemaを入れる」
という考え方は避けましょう。
Googleがサポートしている構造化データを確認し、ページの内容に合うものがある場合に実装するのが基本です。
例えば、
- トップ・企業情報 → Organization
- 記事 → Article
- 求人詳細 → JobPosting
- サイト階層 → BreadcrumbList
といった考え方です。
ページに実際に掲載されている情報をマークアップする
構造化データの内容と、ユーザーが見ているページの内容は一致させます。
例えば、ページ上に「創業30年」と書かれていないにもかかわらず、構造化データだけで30年の実績があるように記述する、といった使い方は避けます。
Googleは、ユーザーから見えないコンテンツや、ページ内容を正しく表していない情報をマークアップしないことを品質ガイドラインで求めています。
構造化データは、
検索エンジンだけに見せる「裏側の広告スペース」ではありません。
必須・推奨プロパティを設定する
構造化データの種類ごとに、
- 必須プロパティ
- 推奨プロパティ
があります。
対象の検索機能を利用できる状態にするためには、必要なプロパティを正しく設定します。
推奨プロパティについても、実際に確認できる情報であれば追加を検討します。
ただし、
項目数を増やすことより、正確な情報を設定すること
の方が重要です。
分からない情報や、実態と異なる情報を無理に設定する必要はありません。
リッチリザルトテストで確認する
実装後は、Googleのリッチリザルトテストで確認します。
主に、
- 構造化データが認識されているか
- 重大なエラーがないか
- 対象となるリッチリザルトの種類
などを確認できます。
実装して終わりではなく、
実装 → テスト → 修正
までを1セットにしましょう。
公開後はSearch Consoleで監視する
公開後はSearch Consoleも確認します。
基本的な流れは、
- 構造化データを実装する
- リッチリザルトテストで確認する
- ページを公開する
- URL検査ツールでGoogleからの見え方を確認する
- Search Consoleで継続的に監視する
となります。
サイトリニューアルやCMS変更によって、公開前には正常だった構造化データが崩れるケースもあります。
そのため、公開後の確認まで含めて運用することが重要です。
構造化データでやってはいけないこと
ページに存在しない情報を記述する
ユーザーに見えていない情報を、検索エンジンだけに伝える目的で構造化データへ追加するのは避けましょう。
構造化データは、ページに存在する情報の意味を説明するものです。
偽のレビュー・評価をマークアップする
検索結果で星評価を表示させたいからといって、
- 実際には存在しないレビュー
- 架空の評価
- ページ内容と関係のない評価
などを設定してはいけません。
ユーザーを誤解させる構造化データは、Googleのガイドラインに抵触する可能性があります。
内容によっては、リッチリザルトの対象外や手動による対策につながる可能性もあるため注意が必要です。
関係のない構造化データを設定する
構造化データは、多ければ多いほどよいわけではありません。
例えば、
- 一般的な企業コラムをRecipeとしてマークアップする
- 会社紹介ページを商品ページとしてマークアップする
など、実際のページ内容と異なる設定は避けます。
数を増やすより、適切な種類を正確に実装する。
これが基本です。
「入れれば必ずリッチリザルトになる」と考える
構造化データを正しく設定しても、検索結果の表示方法はGoogleが判断します。
そのため、
「星が表示されないから構造化データを増やそう」
「検索結果を目立たせるためだけにschemaを追加しよう」
という発想ではなく、
ページ内容を検索エンジンへ正確に説明する
ことを目的にしましょう。
WordPressサイトではどう実装する？
WordPressの場合は、主に次のような実装方法があります。
- テーマ側で実装する
- SEO系プラグインで出力する
- 独自プラグインで実装する
- テンプレートにJSON-LDを組み込む
WordPressなどのCMSでは、管理画面やプラグインから構造化データを出力できる場合もあります。
ただし、注意したいのが複数箇所からの出力です。
例えば、
テーマがOrganizationを出力
＋
SEOプラグインもOrganizationを出力
＋
独自実装でもOrganizationを出力
という状態になることがあります。
複数の構造化データが存在すること自体が直ちに問題になるとは限りませんが、内容が矛盾すると管理しづらくなります。
WordPressサイトでは、
「現在、どのテーマ・プラグイン・コードから構造化データが出力されているのか」
を一度確認しておくことをおすすめします。
リニューアル時に構造化データを見直すべき理由
構造化データは、ホームページリニューアルによって崩れやすい項目の一つです。
例えば、
- 会社情報が変更された
- URL構造が変わった
- パンくずの階層が変わった
- ブログの著者情報が変わった
- CMSやテーマを変更した
- 採用ページの構造が変わった
といった場合、旧サイトの設定をそのまま流用できない可能性があります。
特にWordPressでは、テーマ変更によって構造化データの出力方法そのものが変わる場合もあります。
リニューアル公開前には、
- Organization
- Breadcrumb
- Article
- 求人・商品などサイト固有の構造化データ
を確認し、現在のサイト内容と一致しているかチェックしましょう。
構造化データチェックリスト
実装前
- ページ内容に合った構造化データを選んでいる
- Googleが現在サポートしている種類を確認している
- 構造化データの目的を「順位アップ」と誤解していない
- ページ上の情報と構造化データの内容が一致している
実装時
- JSON-LDなど適切な形式を使用している
- 必要なプロパティを設定している
- 推奨プロパティも正確な範囲で設定している
- 偽のレビューや実績を入れていない
- ユーザーから見えない情報だけをマークアップしていない
- 同じ情報が複数箇所から矛盾して出力されていない
公開前
- リッチリザルトテストで確認した
- 重大なエラーを修正した
- 対象ページがrobots.txtやnoindexによって意図せず制限されていない
- 構造化データ内のURLが本番URLになっている
公開後
- Search Consoleで状況を確認している
- URL検査ツールでGoogleからの見え方を確認している
- CMS・テーマ更新後に再確認している
- 会社情報・営業時間・求人などを変更した際、構造化データも更新している
まとめ：構造化データは「検索エンジンへの説明書」として考える
構造化データは、検索順位を簡単に上げるためのSEOテクニックではありません。
本来の役割は、
「このページには何が書かれているのか」
を、検索エンジンへ正確に伝えることです。
企業サイトであれば、
- Organization＝会社・組織情報
- Breadcrumb＝ページ階層
- Article＝記事情報
- LocalBusiness＝店舗・地域事業情報
- JobPosting＝求人情報
など、ページの目的に合わせて適切な構造化データを検討します。
Googleがサポートする検索機能や実装要件は変更されることもあるため、実装時には最新のGoogle検索セントラルを確認することも重要です。
そして何より、
ユーザーに見えている情報と一致させる
正確な情報だけを記述する
ページに合った種類だけを使う
実装後にテスト・監視する
ことが重要です。
構造化データは「検索結果を派手にするためのコード」ではなく、自社サイトの情報を検索エンジンへ正しく届けるための情報設計として活用しましょう。
構造化データ・SEO設定の見直しならRefuへ
Refuでは、サイトリニューアル時のSEO設計だけでなく、Organization・Breadcrumb・Articleなどの構造化データ、title・description、内部リンク、Search Consoleまで含めた技術面のチェックにも対応しています。
「今のサイトに構造化データが入っているか分からない」
「WordPressをリニューアルするのでSEO設定も見直したい」
「検索エンジンにサイト情報を正しく伝えられているか確認したい」
といった場合も、お気軽にご相談ください。
その他おすすめ記事はこちら
E-E-A-Tを強化するサイト改修ポイント｜信頼を積み上げる情報設計
301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点
リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴
