構造化データとは｜身近な例とSEOでの役割・入れ方の要点
この記事の要点
- 構造化データはページの意味を検索エンジンに伝えるメモ書き。順位を直接上げるものではない
- 中小企業がまず入れるべきはOrganizationとBreadcrumbListの2つ。判断表と貼るだけのJSON-LDを本文に用意
- 入れて終わりの失敗が3つ。本文と食い違うマークアップは逆効果になる
「構造化データを入れた方がいい」と言われたものの、そもそも何をどこに入れるのか分からない。そんな状態でこのページにたどり着いた方が多いと思います。
この記事では、構造化データとは何かを身近な例で押さえたうえで、SEOでどんな役割を果たすのか、自社サイトに何を優先して入れるべきか、そしてコピペで使えるJSON-LDと確認手順までを一気にお伝えします。
対象は、自社サイトを持っていて更新もある程度自分たちでやっている中小企業の経営者・広報・Web担当者の方です。読み終わる頃には、「うちのサイトにはまずOrganizationとBreadcrumbListを入れて、この方法で確認する」と決められる状態を目指します。なお、すでに入れてあるコードのエラー解消が目的の方は、構造化データのエラー確認と直し方｜テストツール手順の方が近道です。
Contents / 目次
構造化データとは。ページの内容を検索エンジンに伝えるメモ書き
構造化データとは、Webページに書かれている情報が「何を意味するのか」を、決められた形式で検索エンジンに伝えるためのデータのことです。人間が読む文章とは別に、機械向けの注釈をページの中に埋め込む、というイメージで合っています。
たとえば、あなたのページに「9時〜18時」と書いてあるとします。人間なら営業時間だと分かります。でも機械にとっては、ただの数字とハイフンの並びです。予約受付時間かもしれないし、配送時間かもしれない。
そこで「この9時〜18時は営業時間です」という注釈を付けておく。これが構造化データのイメージです。ひとことで言うと、機械のための「ここは何の情報か」というラベル貼りです。実際にどのプロパティで何を書くかは、後半のコード例と各ドキュメントで確認してください。
構造化データの身近な例。検索結果で毎日見ている
構造化データの身近な例は、実はあなたが毎日見ている検索結果の中にあります。次のような表示は、いずれも構造化データがもとになっています。
- レシピの星印と調理時間：料理名で検索したとき、レシピの一覧に評価や調理時間が並んで出ることがあります。ページ内の数字に「これは評価」「これは調理時間」というラベルが貼られています
- お店の営業時間と住所：店名で検索したときに出る営業時間・電話番号・定休日。Googleビジネスプロフィールとは別に、自社サイト側からも同じ情報を伝えられます
- パンくずリスト：検索結果のURLの部分が「example.com › 製品情報 › 業務用機器」のように階層で表示されるもの。サイトのどの位置にあるページかを伝えています
- 求人情報の給与と勤務地：職種名で検索したときに、給与レンジや雇用形態がまとまって出るもの
- イベントの日時と会場：展示会やセミナーの検索結果に、開催日と場所が並んで出るもの
もっと身近なたとえで言うと、構造化データは荷物に貼る送り状に似ています。段ボールの中身は開ければ分かりますが、外側に「割れ物」「品名・食品」「配達希望9〜12時」と書いてあれば、開けなくても扱い方が分かる。検索エンジンやAIは、この送り状を見て中身を判断しています。
構造化データは英語で何と言うか
構造化データは英語で「structured data」（ストラクチャード・データ）と言います。Googleの開発者向けドキュメントでもこの表記が使われています。
調べものをしていると、似た言葉がいくつも出てきて混乱しがちです。用語の関係を整理しておきます。
| 用語 | 英語表記 | 意味 |
|---|---|---|
| 構造化データ | structured data | ページの意味を機械に伝えるデータ全般。この記事のテーマ |
| スキーマ | Schema.org | 「何をどう書くか」を決めた共通の語彙集。世界共通のルールブック |
| JSON-LD | JSON-LD | 構造化データの書き方の一種。Googleが推奨する形式 |
| マークアップ | markup | ページにラベルを付ける作業そのもの。「構造化データを実装する」と同義で使われる |
| リッチリザルト | rich results | 構造化データをもとに、検索結果が装飾されて表示されること |
なお、データベースやAIの文脈で「構造化データ」と言うと、表形式に整理されたデータ（Excelの表のようなもの）を指します。同じ言葉ですが別物です。SEOの話をしているときは、この記事で扱う意味だと思って大丈夫です。
SEOでの役割。順位は上がらないが、選ばれる確率は変わる
構造化データはGoogleの検索順位を直接上げる要因ではありません。ここを最初にはっきりさせておきます。「入れれば順位が上がる」と説明している情報を見かけたら、その時点で古いか不正確です。
では意味がないのか。そんなことはありません。効き方が「順位」ではなく「理解と表示」の側にあるだけです。役割は大きく3つに分かれます。
役割1。検索エンジンにページの中身を誤解なく伝える
検索エンジンは本文を読んで内容を推測しますが、推測である以上ズレます。「田中製作所」が会社名なのか商品名なのか、「3,000円」が価格なのか送料無料の条件なのか。構造化データは、こうした情報にラベルを付けて伝える手段です。
Google検索セントラルでも、構造化データはページに関する情報とコンテンツの分類について明確な手がかりを提供するものだと説明されています。詳しくはGoogle検索セントラルの構造化データの仕組みに関する解説で確認できます。
役割2。検索結果の見た目が変わり、クリックされやすくなる
構造化データを正しく入れると、検索結果に星評価やパンくず、価格などが追加表示されることがあります。これがリッチリザルトです。同じ順位でも、情報量の多い枠の方が目に留まりやすくなります。
ただし、構造化データを入れれば必ずリッチリザルトが出るわけではありません。表示するかどうかはGoogleが判断します。また、リッチリザルトとして表示される種類そのものが見直されることもあります。どの種類が現在サポートされているかは、Google検索セントラルの構造化データ機能ギャラリーで必ず最新の一覧を確認してください。「表示されること」を前提に投資判断をしないでください。
役割3。AI検索に引用されるときの材料になる
2026年の今、構造化データを見直す価値が上がっているのはこの3つ目の理由です。ChatGPTやGemini、Perplexity、GoogleのAI Overviewsといった生成AIは、ページの内容を読み取って回答を組み立てます。
ただし、各サービスが構造化データをどう扱うかは公開されていません。営業時間・価格・著者・会社名といった事実をラベル付きで整理しておくのは、あくまで「本文の文章だけに頼らず、機械が読み取れる形でも情報を置いておく」という備えです。効果を約束できるものではありません。
ポイント。構造化データはAI引用の「必要条件」ではありません。中身のないページに入れても引用されません。中身がしっかりあるページの情報を、機械向けにも整理しておく役割だと考えてください。
まず入れるべき構造化データの優先順位
種類は膨大にありますが、中小企業のサイトで最初に検討すべきものは限られます。自社の状況に当てはめて判断してください。
| 種類 | 何を伝えるか | 入れるべきサイト | 優先度 |
|---|---|---|---|
| Organization | 会社名・ロゴ・所在地・公式SNS | すべての企業サイト | 最優先 |
| BreadcrumbList | ページの階層位置 | 階層が2階層以上あるサイト | 最優先 |
| Article | 記事タイトル・著者・公開日 | コラムやブログがあるサイト | 高 |
| LocalBusiness | 店舗の住所・営業時間・電話 | 実店舗・事業所を持つ会社 | 高（店舗業なら最優先） |
| Product | 商品名・価格・在庫 | ECサイト | ECなら最優先 |
| FAQPage | 質問と回答のセット | FAQページを持つサイト | 中 |
| Event | 開催日・会場・チケット | セミナー・展示会を開く会社 | 該当時のみ |
迷ったら、まずOrganizationとBreadcrumbListの2つです。この2つはほぼすべてのサイトに当てはまり、一度入れれば内容がほとんど変わらないので、運用コストがかかりません。
構造化データの入れ方。コピペで使える手順を5ステップで
ここからが実作業です。JSON-LD形式で書いて、`<head>` の中か本文中に貼るだけ。1種類ずつなら、コードを書き換えて貼って確認するまでの短い作業です。
ステップ1。書く形式をJSON-LDに決める
書き方は3種類ありますが、選ぶのはJSON-LD一択です。Googleは構造化データの概要ドキュメントでJSON-LDを推奨しており、開発者向けドキュメントのサンプルもJSON-LDで書かれています。
他にMicrodata（HTMLタグの中に属性で書き込む方式）とRDFaがあります。この2つは本文のHTMLに直接混ぜ込む方式なので、デザインやテンプレートの改修とマークアップの修正が同じ場所で発生します。古い解説記事でMicrodataの例を見かけても、これから新規に入れるならJSON-LDにしてください。
JSON-LDの良いところは、本文のHTMLと完全に分離できる点です。`<script>` タグ1つにまとまるので、貼るのも消すのも簡単です。
ステップ2。会社情報（Organization）を貼る
最初の1つはこれです。全ページ共通で使えるので、テーマのヘッダーやフッターに入れておけば一括で反映されます。
<!-- 設置場所：全ページ共通の <head> 内、または </body> 直前 -->
<!-- WordPressならテーマの header.php か、SEOプラグインのカスタムコード欄 -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "株式会社サンプル商事",
"url": "https://example.com/",
"logo": "https://example.com/images/logo.png",
"description": "業務用厨房機器の販売・メンテナンスを行う会社です。",
"telephone": "+81-97-000-0000",
"address": {
"@type": "PostalAddress",
"streetAddress": "寿町8-11",
"addressLocality": "大分市",
"addressRegion": "大分県",
"postalCode": "870-0036",
"addressCountry": "JP"
},
"sameAs": [
"https://www.instagram.com/example/",
"https://www.facebook.com/example/"
]
}
</script>変更する箇所を説明します。name は登記上の正式名称にしてください（「（株）」ではなく「株式会社」）。logo は実際にアクセスできる画像URLです。存在しないURLを書くとエラーになります。
telephone は、上の例のように国番号（日本は+81）から書き、市外局番の先頭の0を取る国際形式にしています。どの表記にするかは、Schema.orgのtelephoneプロパティの定義と、使う種類のGoogle公式ドキュメントで確認してください。どの表記にする場合でも、サイト内やGoogleビジネスプロフィールと書き方をそろえることが大事です。
sameAs は自社が運営している公式アカウントのURLだけを並べます。ここは「この会社とこのSNSは同一である」と宣言する項目なので、他社のページや個人アカウントを入れてはいけません。運営していないSNSは行ごと削除して構いません。
ステップ3。パンくずリスト（BreadcrumbList）を貼る
2つ目はパンくずです。ページごとに内容が変わるので、テンプレート側で自動生成するのが理想ですが、まずは主要ページに手で入れても効果はあります。
<!-- 設置場所：各ページの <head> 内 -->
<!-- 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": "製品情報",
"item": "https://example.com/products/"
},
{
"@type": "ListItem",
"position": 3,
"name": "業務用冷蔵庫XR-200"
}
]
}
</script>つまずきやすいのは最後の項目です。上の例で3つ目に item（URL）がないのは、Google検索セントラルのパンくずリスト構造化データのドキュメントの「構造化データタイプの定義」で、item が最後の項目では不要とされているためです。禁止ではないので、実装の前に必ずリンク先の定義そのものを見て、自社の書き方を決めてください。
もう1つ大事なのは、ここに書く階層は実際に画面に表示されているパンくずと一致させることです。画面には出していない架空の階層を書くと、後述する「本文と食い違うマークアップ」になります。
ステップ4。記事ページに著者情報（Article）を足す
コラムやブログを持っているなら、記事ページにArticleを入れます。2026年時点では、誰が書いたのかを機械に伝えられる点が一番の価値です。
<!-- 設置場所：記事ページの <head> 内 -->
<!-- 日付はISO 8601形式（YYYY-MM-DD）で書く -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "業務用冷蔵庫の選び方。厨房の広さから逆算する手順",
"image": "https://example.com/images/article-01.jpg",
"datePublished": "2026-08-04",
"dateModified": "2026-08-04",
"author": {
"@type": "Person",
"name": "山田太郎",
"url": "https://example.com/author/yamada/"
},
"publisher": {
"@type": "Organization",
"name": "株式会社サンプル商事",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/images/logo.png"
}
}
}
</script>author の url には、その人のプロフィールページを指定します。プロフィールページがないなら作った方がいいです。名前だけ書いても、機械にとっては「山田太郎という文字列」でしかありません。
dateModified は記事を実際に修正したときだけ更新します。中身を変えずに日付だけ新しくするのは、構造化データがページの実際の内容と食い違う状態になるのでやめてください。日付プロパティの扱いはGoogle検索セントラルのArticle構造化データのドキュメントに書かれています。
ステップ5。店舗があるならLocalBusinessを足す
実店舗や事業所があるなら、店舗ページに入れます。Organizationとよく似ていますが、営業時間を書けるのが違いです。
<!-- 設置場所：店舗紹介ページの <head> 内 -->
<!-- 曜日は Monday〜Sunday の英語表記。時間は24時間表記 -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "サンプル商事 大分ショールーム",
"image": "https://example.com/images/showroom.jpg",
"url": "https://example.com/showroom/",
"telephone": "+81-97-000-0000",
"address": {
"@type": "PostalAddress",
"streetAddress": "寿町8-11",
"addressLocality": "大分市",
"addressRegion": "大分県",
"postalCode": "870-0036",
"addressCountry": "JP"
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00",
"closes": "18:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": "Saturday",
"opens": "10:00",
"closes": "16:00"
}
]
}
</script>ここで一番やりがちなミスが、Googleビジネスプロフィールに登録した情報とズレることです。店名・住所・電話番号は、1字1句そろえてください。表記がそろっていれば、どちらを見た人にも同じ情報が伝わります。
WordPressならプラグインでも入れられる
コードを触りたくない場合、構造化データの出力に対応したSEOプラグインを使う手もあります。どの種類に対応しているか、何を自動出力するかはプラグインによって違うので、導入前に必ず各プラグインの公式ドキュメントで対応範囲を確認してください。
そのうえで、導入したら必ず次のステップの確認作業をしてください。テーマや他のプラグインが同じ種類をすでに出力していないかは、実際のソースを見ないと分かりません。設定項目の名称や場所はプラグインごとに違い、更新でも変わります。
構造化データの確認方法。3つのツールを使い分ける
貼ったら必ず確認してください。JSON-LDは書式が1文字崩れただけでも読み取れなくなります。しかも画面上は何も変わらないので、壊れていても気づけません。
確認に使うツールは3つあり、それぞれ見ているものが違います。
| ツール | 何が分かるか | 使うタイミング |
|---|---|---|
| リッチリザルトテスト | Googleがリッチリザルトの対象として認識するか | 貼った直後・公開前 |
| スキーママークアップ検証ツール | Schema.orgの文法として正しいか | 文法だけを確かめたいとき |
| Search Consoleの構造化データ関連レポート | サイト全体で何件エラーが出ているか | 公開後・月1回の点検 |
貼った直後の確認手順
公開前でも確認できます。次の順番で進めてください。
- Googleのリッチリザルトテストを開く
- 公開済みページなら「URLをテスト」、まだ公開していないなら「コードをテスト」を選んでJSON-LDを貼り付ける
- テストを実行し、検出された項目の一覧を見る
- 入れたはずの種類が一覧に出ているかを確認する（出ていなければ、そもそも読み込まれていない）
- エラーがあれば、指摘されたプロパティ名を手元のコードから探して直す
ここで覚えておいてほしいのが、「エラー」と「警告」の違いです。エラーは必須項目が欠けている状態で、直さないと認識されません。警告は「あった方がいい項目がない」という助言で、無視しても動きます。全部の警告を消そうとして時間を使うのは、優先順位を間違えています。
リッチリザルトテストが何を対象に検出するかは、構造化データ機能ギャラリーで今サポートされている種類を見て確認してください。入れた種類が一覧に出てこないときは、Schema.org公式の検証ツールで文法だけ確認します。
ブラウザで自分の目で見る方法
ツールを使わずに、そのページに構造化データが入っているか確認する方法もあります。
- 確認したいページをブラウザで開く
- ページ内を右クリックして「ページのソースを表示」を選ぶ
- Ctrl+F（Macは Command+F）で検索窓を出す
application/ld+jsonと入力して検索する- ヒットした箇所の中身が、実際に出力されているJSON-LDです
この方法は、競合サイトが何を入れているかを見るときにも使えます。同業のよくできているサイトをいくつか見ていくと、その業界で標準的に使われている種類の見当がつきます。何社見れば十分という決まりはないので、同じ種類が繰り返し出てくると感じるところまで続けてください。
公開後にサイト全体で異常が出ていないかは、Search Consoleの構造化データ関連のレポートで確認します。メニュー名や表示場所は変わることがあるので、Search Consoleヘルプの構造化データレポートの説明で今の名称を確認してください。Search Consoleの見方に不安がある方は、サーチコンソールで除外を確認する手順｜未登録の直し方もあわせて読んでみてください。
どんな変化が期待できるか。数字で見る前に押さえたい前提
構造化データを入れて起きる変化は、「アクセスが倍増する」タイプのものではありません。期待値を正しく持っておくことが、社内で説明するときにも役立ちます。
実際に起きるのは、次のような変化です。
- 検索結果での見え方が変わる：パンくずが階層表示になる、記事の公開日が出るなど。順位が同じでも、枠の中の情報量が増えます
- 情報の誤表示が減る：営業時間や住所が古い情報のまま出る、といった事故が起きにくくなります
- サイト側の情報が整理される：会社名や事業内容を、本文とは別に機械が読める形でも置いておけます
中小企業が現実的に得られる成果
正直に言うと、10ページ程度のコーポレートサイトにOrganizationを入れただけで、問い合わせが増えることはまずありません。取り組む価値があるのは、次のどれかに当てはまるサイトです。
- ページ数が多いサイト：記事や商品ページが多いほど、パンくずや記事情報をテンプレートで一括整備できる利点が大きくなります
- 店舗名で検索される会社：指名検索が発生する事業では、住所と営業時間を正確に伝えられます。来店前の勘違いが減ります
- 会社の実体を明確にしたい会社：会社名・所在地・事業内容を機械が読める形で置いておくと、サイト内の記述と食い違いが起きにくくなります
投資対効果の目安。OrganizationとBreadcrumbListは、一度入れれば内容がほぼ変わらないため、維持コストがほとんどかかりません。「小さく入れて放置できる」施策として取り組みやすい部類に入ります。逆に、商品ページに価格・在庫を入れる場合は、在庫連動の仕組みまで考えないと運用が破綻します。
よくある失敗と回避法。現場で見かける4パターン
構造化データの失敗は、入れる作業より「入れたあと」に集中します。実際によく見かけるものを挙げます。
失敗1。本文に書いていないことをマークアップする
一番危険なのがこれです。ページ内に星評価を表示していないのに評価の構造化データを入れる。FAQを画面に出していないのにFAQPageを入れる。こういう実装をしているサイトを今でも見かけます。
Google検索セントラルの構造化データの一般的なガイドラインには「コンテンツのガイドライン」という項目があり、その中に、ユーザーに表示されないコンテンツをマークアップしないという趣旨の規定と、違反した場合に手動による対策の対象となりうる旨が書かれています。実装前に、この「コンテンツのガイドライン」の項目を必ずご自身で読んでください。
防ぎ方は単純で、「画面に見えていないことは書かない」を絶対のルールにすることです。構造化データは、ページに実際にある情報を機械向けに言い換えたものでなければいけません。
失敗2。プラグインとテーマで二重出力になっている
WordPressで起きがちです。テーマが自動でArticleを出力しているのに、SEOプラグインもArticleを出力し、さらに手でコードを貼る。結果、同じページに3つのArticleが並びます。
こうなると、検索エンジンはどれを信じればいいか分からなくなります。日付が違う、著者が違う、タイトルが違う、といった食い違いが出れば余計に混乱します。
防ぎ方は、手で貼る前に必ずソースを確認することです。application/ld+json で検索して、すでに何が出ているかを見る。テーマやプラグインが出しているなら、そちらを設定で直す方が確実です。手で足すのは、既存の出力がない種類だけにしてください。
失敗3。入れっぱなしで情報が古くなる
営業時間を変えたのに構造化データは前のまま。移転したのに住所が古いまま。電話番号を変えたのにコードだけ取り残される。これが地味に多いです。
本文は目に見えるので気づきますが、構造化データは画面に出ないため誰も気づきません。半年後に「検索結果の営業時間が違う」と客から指摘されて発覚する、というパターンです。
防ぎ方は、会社情報の変更手順に「構造化データの更新」を1行足しておくことです。住所・電話・営業時間・会社名を変えるときは、必ず該当箇所を確認する。手順書に書いておけば、担当者が変わっても引き継がれます。
失敗4。全種類を網羅しようとして手が止まる
Schema.orgには膨大な種類があります。全部調べてから始めようとすると、確実に手が止まります。
防ぎ方は、種類を絞ることです。まずOrganizationだけ入れて、リッチリザルトテストで通ることを確認する。それができたらパンくずを足す。1つずつ確実に増やす方が、結果的に早く終わります。
なお、リッチリザルトの表示仕様は変わります。表示されるかどうかを追いかけるより、「ページの意味を正確に伝える」という本来の目的に集中する方が、長く効く投資になります。FAQの構造化データを具体的にどう扱うかは、FAQ構造化データが表示されない原因と実装手順｜2026年コピペ可で詳しく解説しています。
現場で見えた落とし穴。やる前に知っておいてほしいこと
ここからは、教科書的な解説には出てこない話をします。構造化データを入れる相談を受けるとき、実際に判断が分かれるポイントです。
構造化データより先に直すべきものがある
相談を受けて調査すると、構造化データ以前の問題が見つかることがよくあります。ページがインデックスされていない、タイトルタグが全ページ同じ、スマホで表示が崩れている。
構造化データは「検索結果に出ているページの見え方を良くする」施策です。そもそも検索結果に出ていないなら、優先順位は下がります。インデックスと基本的な内部対策が済んでから着手する方が、投じた時間が無駄になりません。この順番はSEO内部対策チェックリスト｜初心者がまず直すべき優先順位で整理しています。
AIに書かせるときの落とし穴
JSON-LDの生成は、AIが得意な作業です。「うちの会社情報でOrganizationのJSON-LDを作って」と頼めば、形式的に正しいコードが返ってきます。実際、手で書くより速いので使わない手はありません。
頼み方は難しく考えなくて大丈夫です。次くらいの短い指示から始めて、対話しながら詰めていくのが実用的です。
Schema.orgのJSON-LDを作ってください。
種類：［Organization / LocalBusiness など］
会社名：［正式名称］
住所：［郵便番号から］
電話：［番号］
営業時間：［曜日と時間］
公式SNS：［URL］
条件：実在が確認できない項目は勝手に埋めず、空欄のまま返してください。ただし、出てきたコードをそのまま貼ってはいけません。人が必ず確認すべき点が3つあります。
- 存在しない項目を埋めていないか：AIは空欄を嫌うので、渡していない情報をそれらしく補うことがあります。特に評価の星、価格、設立年は要注意です
- URLと画像が実在するか：ロゴURLや著者ページのURLが、実際にアクセスできるか1つずつ開いて確認します
- 本文の内容と一致しているか：ページに書いていない営業時間や住所が入っていないか。ここがズレると失敗1と同じ状態になります
この3点だけ人が見れば、AIに書かせるリスクはほぼ消せます。
外注するときに確認すべきこと
制作会社に依頼する場合、見積もりの中身を確認してください。「構造化データ対応」とだけ書かれた項目は、内容が会社によって大きく違います。
- どの種類を、どのページに入れるのか：Organizationだけなのか、記事テンプレートまで対応するのかで作業量が大きく変わります
- テンプレート化されるのか、手貼りなのか：手貼りだと、記事を追加するたびに作業が発生します。運用を誰がやるのかまで決めてください
- 納品後の変更は誰がやるのか：営業時間が変わったとき、自分たちで直せる場所にあるかを確認します
逆に、「構造化データを入れれば順位が上がります」と説明してくる会社は要注意です。2026年時点でその説明は不正確です。
内製か外注かの分かれ目
判断はシンプルです。1回貼って終わるものは内製、テンプレートに組み込むものは外注。これが現実的な線引きです。
Organizationの1つ貼りなら、この記事のコードを書き換えるだけなので社内でできます。一方、記事テンプレートにArticleを自動出力させる、商品データベースと連動させる、といった作業はプログラムの改修になります。ここは無理せず頼んだ方が早いです。
構造化データを入れてから効果が出るまで、どれくらいかかりますか
検索結果の表示に反映されるかどうかは、Googleが再クロールしてからになります。クロールの頻度はGoogleが決めるもので、いつ反映されるかを事前に見込むことはできません。急ぎたい場合は、Search ConsoleのURL検査ツールからインデックス登録をリクエストする方法もあります。
構造化データを入れたのに、検索結果の見た目が変わりません
リッチリザルトの表示はGoogleが判断するため、正しく実装しても表示されないことはよくあります。まずリッチリザルトテストで「対象として認識されているか」を確認してください。認識されていれば実装は正しく、あとはGoogleの判断待ちです。そもそもリッチリザルトの対象になる種類かどうかも、構造化データ機能ギャラリーで確認してください。
古い記事の構造化データも、全部入れ直すべきですか
全記事を一括でやる必要はありません。まずはアクセスの多いページから始めてください。テンプレートで自動出力する仕組みにすれば、過去記事にも一度に反映されます。手貼りで全記事を追いかけるのは、途中で必ず息切れします。
構造化データとGoogleビジネスプロフィールは、どちらを優先すべきですか
実店舗があるならGoogleビジネスプロフィールが先です。地図検索での露出に直結するためです。自社サイトのLocalBusinessは、その情報を補強する位置づけになります。両方入れる場合は、店名・住所・電話番号の表記を完全にそろえてください。
構造化データを間違えると、ペナルティを受けますか
Googleが手動による対策の対象になりうると明記しているのは、ページに存在しない情報をマークアップした場合などのガイドライン違反です。詳しくは構造化データの一般的なガイドラインの「コンテンツのガイドライン」をご自身で確認してください。書式の不備で読み取れない場合の扱いについても、同じガイドラインと各種類のドキュメントで確認するのが確実です。
まずはソースを開いて、今の状態を見るところから
今日すぐできる最初の一歩をお伝えします。自社サイトのトップページを開いて右クリックし、「ページのソースを表示」から application/ld+json を検索してみてください。何も出てこなければ、この記事のOrganizationのコードが最初の1つになります。
すでに何か出ている場合は、その中身がリッチリザルトテストで通るかを確認しましょう。エラーが出たときの直し方は構造化データのエラー確認と直し方｜テストツール手順にまとめています。
ここまで読んで、「テンプレートへの組み込みまでは社内では難しそうだ」と感じた方もいると思います。株式会社コレットラボ（大分・福岡のAI業務システム化支援）では、AIを使ったサイト制作・運用の内製化を伴走で支援しています。今の状態を見せていただいて、どこから手を付けるべきかを整理するだけでも構いません。AI業務システム化の詳細はこちらから、気軽にお声がけください。
無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →
