先に結論を書きます。LocalBusinessスキーマ（構造化データ）は、入れたら順位が上がる魔法のタグではありません。それでも店舗サイトには入れる価値があります。理由は2つ。検索エンジンとAIに「どこにある、何の店か」を誤解の余地なく伝えられること。そして、Googleマップ・自社サイト・各種ポータルの情報が機械的に照合しやすくなり、情報の信頼性の裏付けになることです。この記事では、仕組みの説明から、JSON-LDの骨格、公式の検証ツールで何を確認するのか、そして実装したあとに必ず訪れる更新の問題までを解説します。
構造化データは「何をしてくれる」のか
人間はホームページを見れば「池袋にある整体院で、平日は20時まで」と読み取れます。しかし検索エンジンやAIにとって、ページ上の文字は最初「ただのテキストの並び」です。どれが店名で、どれが住所で、どの数字が電話番号なのか——それを機械が読める形式でラベル付けして渡すのが構造化データです。schema.orgという共通規格があり、店舗ビジネス用の型が「LocalBusiness」です。
効果として期待できるのは次の2つです。
- 情報の正確な伝達: 検索エンジンが店舗情報を誤読するリスクを減らす。Googleビジネスプロフィールや他サイトの情報と照合され、「同一の実在店舗」という確認材料になる
- リッチリザルトの可能性: 検索結果に営業時間や星評価などが表示される形式の対象になり得る（保証はされません）
そして近年重要度が増しているのがAI検索との関係です。ChatGPTやGoogleのAIによる概要が店舗を紹介するとき、参照元の情報が構造化されているほど誤引用が起きにくくなります。MEOとLLMO（AI検索対策）の両方の土台になるのが構造化データ、という位置づけです。単体で順位を動かすタグではないぶん、ここで正確さを担保できているかどうかが、その上に積むカテゴリ・口コミ・写真といった打ち手の効き方を左右します。
LocalBusinessスキーマで書くべき項目
プロパティ（項目）は数十種類ありますが、全部書く必要はありません。役割で分けると、大きく3つの層になります。
| 層 | 役割 | 判断が要る点 |
|---|---|---|
| 店舗の同一性を示す層 | 業種タイプ・店名・住所・電話番号。いわゆるNAP情報の中核で、機械が「実在するあの店」と結びつけるための情報 | GBPや各種ポータルとの表記の揃え方。どの表記を正とするかを先に決めないと、揃える対象が定まりません |
| 営業実態を示す層 | サイトURL・営業時間・所在地の座標。開いているのか、どこにあるのかを機械に伝える | 実態が複雑な店ほど表現が難しい層です。曜日で変わる、季節で変わる、予約時間と受付時間が違う——どこまで正確に書き切るかで手間が変わります |
| 補足の層 | 写真・価格帯・SNSやGBPのURLなど | 書くほど良いわけではなく、実態とずれた値を置けば、他の層の信頼まで下げます |
@typeは「LocalBusiness」のままでも動きますが、より具体的な下位タイプが用意されている業種は、そちらのほうが情報として正確になります。ただし、複数の業態を持つ店ではどのタイプを名乗るかが一意に決まりません。カテゴリ設定と同じで、ここも「自店をどう定義するか」の判断が先に立ちます。
そして、この3層はどれも「一見どちらでもよさそうに見える」選択肢の連続です。住所にビル名を含めるか省くか、営業時間を1本にまとめるか曜日別に割るか、下位タイプを名乗るか広いままにするか——どちらを選んでも構文は通り、画面上の見た目も変わりません。ところが取り違えると、GBP側の情報と機械的に照合されず、せっかく書いた情報が「同じ店の裏付け」として使われないまま眠ります。損失は「間違いが表示される」形では出ず、「何も起きない」形で出る。だから間違えたことに気づけないまま、半年後に「構造化データは効かなかった」という結論だけが残ります。判断材料は自店の情報だけでは足りません。同じ商圏の競合がどの粒度で情報を出し、Googleがそれをどう束ねているかと突き合わせて初めて、どちらに倒すかが決まります。当社では、この粒度を「書ける項目をすべて埋める」ではなく、狙う検索語に対して機械が照合すべき情報はどれか、から逆算して決めています。
ここで書く店名・住所・電話番号は、Googleビジネスプロフィール・サイトのフッター・各種ポータルの表記と完全に一致させてください。表記ゆれ（ビル名の有無、全角半角など)があると、照合の材料がかえってノイズになります。いわゆるNAP統一の話で、構造化データはその「機械向けの出口」です。
記述例（JSON-LD）の骨格
Googleが推奨する書き方はJSON-LD形式です。HTML本文を書き換える必要はなく、コードブロックを1つ、ページの<head>内（または<body>内）に追加する形をとります。骨格だけを示すと、次のような構造になります。
構造としてはこの形が土台になります。ただし難所は構文の側ではなく、値の決め方にあります。住所ひとつ取っても、ビル名や階数をどこまで含めるか、GBPの登録とどちらの表記に揃えるかで、機械側の照合精度が変わります。営業時間も、曜日別・季節別・臨時休業をどこまで表現するかで、書く量が何倍にもなります。「とりあえず埋めた」構造化データは、実態とずれた瞬間に、間違った情報を機械に断言する装置に変わります。
設置場所は、店舗の基本情報が載っているページ（トップページや店舗概要ページ、アクセスページ）が基本です。全ページに同じものを入れても問題はありませんが、複数ページに置くほど、更新のときに直し漏れる箇所が増えます。WordPressの場合はSEO系プラグインが同種の出力をしていることもあるため、二重に出力していないかは必ず確認してください。プラグイン側の出力と手書きの記述が食い違っていると、どちらが正なのか機械にも判別できません。
検証ツールで何を確認するのか
書いたら必ず検証します。使えるツールは主に2つで、見ている対象が違います。
- schema.org公式の「Schema Markup Validator」——コードそのものの文法を見ます。カンマ抜けや括弧の閉じ忘れといった、JSONとして壊れている状態を検出できます
- Googleの「リッチリザルトテスト」——公開されたページのURLを入れて、Google側が構造化データを検出できているかを見ます。書いたつもりで検出されていない、という状態はここで初めて分かります
重要なのは、どちらのツールも「内容が正しいか」は見てくれないということです。実在しない住所を書いても、去年の営業時間を書いても、文法として正しければ両方のツールを通過します。検出された値をGBP・サイトの表記と並べて突き合わせる作業は、最後まで人間の仕事として残ります。ここを飛ばした実装は、検証を通ったという安心感だけが手に入る、いちばん危ない状態です。
公開後しばらくすると、Search Consoleにも構造化データ関連のレポートが出ることがあります。エラーが通知されたら放置せず、その都度直してください。ただし、本当に困るのはエラーが出ないケースです。通知されるのは「壊れている」ときだけで、「正しい形式で、間違った内容を書いている」状態は、どのツールも警告を出しません。同じページに古いプラグインの出力と手書きの記述が二重に載っていても、両方が構文として正しければ、画面上はすべて緑のまま通ります。ここは見るべき場所を知っていないと、そもそも疑うきっかけが生まれない領域です。検証を通ったという安心だけを持ったまま、機械には矛盾した情報を渡し続ける——実装した店舗で最も多い失敗の形がこれです。
※当社FACTORは、この構造化データの実装と、GBP・サイト・スキーマの3点をずらさず保ち続ける運用を、設計から運用ごと引き受けています。営業時間の変更、移転、電話番号の切り替え、年末年始の臨時営業——店舗の情報は思っている以上に動きます。実装そのものは一度で形になりますが、変わったことに気づいて3点を同じ日に同じ値へそろえる作業は、誰かが月次で見続けなければ止まります。しかも止まったことは誰も教えてくれません。ずれた構造化データは、書いていない状態より性質が悪く、間違った情報を機械に断言し続けます。
よくあるミスと、放置したときの損失
1. 実物と違う値を書いてしまう
最も多く、最も本末転倒なミスです。旧店舗の住所のまま、営業時間の変更が未反映、電話番号が携帯と固定で混在——構造化データは「機械に断言する」仕組みなので、間違った情報を堂々と伝え続けることになります。しかも、ずれていることは検索結果を見ても分かりません。気づくきっかけは、たいてい「閉まっていた」という口コミが入った時です。棚卸しの機会と、情報が変わったときに誰が直すのかを、あらかじめ決めておく必要があります。
2. 星評価（aggregateRating)を自作自演する
検索結果に星を出したいがために、根拠のない評価値を書き込むケースがあります。実際のレビューの裏付けがない評価のマークアップはGoogleのガイドライン違反で、リッチリザルトの対象外になったり、手動対応の対象になるリスクがあります。書いてよいのは、実在するレビューデータに裏付けられた値に限られます。
3. 文法エラーで丸ごと無効になっている
JSONはカンマ1つの抜けで全体が読めなくなります。「入れたつもりが検出されていなかった」は珍しくないので、実装した日に必ずリッチリザルトテストを通す習慣をつけてください。なお、自店のサイトとGBPが機械側からどう見えているのかは、実際に確認しないと分かりません。現状の把握からなら無料のAI診断が使えます。
よくある質問
構造化データを入れると検索順位は上がりますか？
HTMLに詳しくなくても実装できますか？
Googleビジネスプロフィールがあれば構造化データは不要では？
まとめ
LocalBusiness構造化データは、順位を直接動かす施策ではなく、店舗情報を機械に正確に伝えるための土台です。店舗の同一性を示す項目（店名・住所・電話・業種タイプ）をGBPと揃えて書き、JSON-LDで設置し、検証ツールで検出を確かめる。ここまでが実装のパートです。ただし本当に判断を要するのは、どの表記を正とするか、実態が複雑な項目をどこまで書き切るかという値の決め方のほうにあります。本番はその先で、情報が変わるたびに3点をずらさず更新し続けること——気づく人と直す人を決めていない店舗ほど、半年後には古い住所や去年の営業時間を機械に断言し続けています。検索にもAIにも「正確に知られている店」であること。これは順位を狙いにいくときの前提条件であって、ここが崩れていると、その上に積んだカテゴリも口コミも写真も効きが落ちます。
NEXT ACTION
この記事の内容、貴店の場合はどうなっているか気になりませんか？
記事で挙げた観点が自店に当てはまるかは、実際の状態を見ないと判断できません。まず現状の把握から。
- ✓AI無料診断 — GoogleマップのURLを貼るだけ。改善点の要点がその場で表示されます
- ✓30分無料相談 — GBPと競合の状況を一緒に確認（売り込みなし）
- ✓1エリア1業種限定 — 貴店の競合とは契約しません（先着順）