LocalBusiness構造化データとは？店舗サイトの設定手順

ホームページには店名も住所も営業時間もきちんと書いてあるのに、Google検索やGoogleマップでの見え方がどうも整わない。店舗オーナーの方から、そんなご相談をいただくことがあります。

原因のひとつが、店舗情報が「人間には読めるけれど、検索エンジンには読み取りづらい形」で置かれていることです。この状態を解消する仕組みが、今回取り上げる構造化データ（LocalBusiness）です。

専門的な話に聞こえるかもしれませんが、やること自体は「決められた形式で店舗情報を書き足す」だけです。制作会社に依頼する場合でも、何をお願いすればよいかが分かるところまで噛み砕いて説明します。

この記事では、Googleの公式ドキュメント（Google検索セントラル）に沿って、必須項目・推奨項目・やりがちな失敗・確認方法までを順にまとめました。すぐに手を動かせるチェックリストとしてお使いください。

構造化データとは？店舗オーナーが最初に理解すべきこと

検索エンジンに渡す「店舗情報の名札」だと考える

構造化データとは、ページの内容が何を意味しているのかを、決まった書式で検索エンジンに伝えるための仕組みです。Googleは「ページの意味について明示的な手がかりを提供するもの」と説明しています。

たとえばページに「9:00〜18:00」と書いてあっても、機械にとってそれが営業時間なのか、受付時間なのか、イベントの開催時間なのかは確実には分かりません。構造化データは、その数字に「これは営業時間です」という名札を付ける作業だと考えると分かりやすいはずです。

店舗ビジネス向けの名札の種類が、schema.orgで定義されている LocalBusiness というタイプです。名前・住所・電話番号・営業時間・緯度経度といった項目を、決められたキー名で書き並べていきます。

書式はいくつかありますが、Googleが推奨しているのはJSON-LDという形式です。HTMLの本文をいじらずに、ページの中に小さなデータのかたまりを1つ埋め込むだけで済むため、既存サイトへ後から足しやすいのが利点です。

MEOとの関係｜順位が上がる魔法ではない

ここが最も誤解されやすい点なので、先にはっきりさせておきます。構造化データを入れたからといって、Googleマップの検索順位が自動的に上がるわけではありません。

Googleはローカル検索の順位を、関連性・距離・視認性（知名度）という3つの要素で評価すると説明しています。構造化データはこのうち関連性の理解を助ける材料にはなりますが、順位を直接押し上げるスイッチではありません。

構造化データの本当の役割は、情報の食い違いを減らし、あなたの店舗をGoogleに正確に認識させることです。サイトとGoogleビジネスプロフィール（GBP）の情報が一致しているほど、Googleは迷わずに済みます。

順位への影響を期待して入れるものではなく、土台を整えるための作業だと位置づけてください。効果は「検索結果での表示が安定する」「情報の誤りが減る」という形で、じわじわ現れます。

自社サイトとMEOの関係全体を整理したい方は、自社サイトとMEOを連携させて集客を最大化するもあわせてご覧ください。

AI検索の時代に、効いてくる理由

近年は、検索結果の上部にAIによる要約が表示されたり、ChatGPTやGeminiのような対話型サービスで店舗を探す人が増えたりしています。こうしたサービスは、Webページの内容を読み取って回答を組み立てます。

文章の中に散らばった情報より、決まった形式でまとまったデータのほうが、機械にとっては圧倒的に扱いやすいものです。構造化データを整えておくことは、AIに正しく引用されるための下準備にもなります。

ただし、AIが構造化データをどう扱うかは各社が詳細を公開していないため、断定はできません。あくまで「正確な情報を機械可読な形で置いておく」ことの副次的なメリットとして捉えるのが安全です。

AI検索・音声検索の全体的な対策は、音声検索・AI検索時代のローカル対策で詳しく解説しています。

LocalBusinessの必須項目と、業種タイプの選び方

必須はnameとaddressの2つだけ

意外に思われるかもしれませんが、GoogleがLocalBusinessの必須項目として挙げているのは name（店名）と address（住所）の2つだけです。まずはこの2つを正確に書くところから始めれば十分です。

住所は PostalAddress という入れ子の形で書きます。都道府県・市区町村・番地・郵便番号・国コードを、それぞれ別のキーに分けて記述するのがポイントです。

{
  "@context": "https://schema.org",
  "@type": "HairSalon",
  "name": "ヘアサロン アクセス",
  "address": {
    "@type": "PostalAddress",
    "postalCode": "329-0414",
    "addressRegion": "栃木県",
    "addressLocality": "下野市",
    "streetAddress": "小金井1-2-3 アクセスビル2F",
    "addressCountry": "JP"
  }
}

Googleは「できるだけ多くのプロパティを含めてください。提供する項目が多いほど、ユーザーにとって質の高い結果になります」と案内しています。まずは必須2つ、次に後述の推奨項目、という順番で足していきましょう。

日本の住所は表記ゆれが起きやすいところです。ハイフンの有無、ビル名の省略、「丁目」の書き方などは、サイト内のどこに書いても同じになるよう統一してください。

「型」はできるだけ細かい業種を選ぶ

@type には LocalBusiness と書いてもよいのですが、Googleは「可能な限り具体的なLocalBusinessのサブタイプを使ってください」と推奨しています。Restaurant（飲食店）、HairSalon（美容室）、Dentist（歯科医院）などです。

細かい型を選ぶほど、その業種ならではの項目が使えるようになります。たとえばRestaurantには servesCuisine（提供する料理のジャンル）や menu（メニューのURL）といった項目があります。

自分の業種に合う型が分からないときは、schema.orgのLocalBusinessのサブタイプ一覧を眺めて、近いものを選べば問題ありません。迷ったときは無理に細かくせず、LocalBusinessのままにしておくほうが安全です。

よく使う型としては、Restaurant／Cafe／BeautySalon／HairSalon／Dentist／MedicalClinic／Store／ClothingStore／AutoRepair／RealEstateAgent／ProfessionalService などがあります。

複数の業種を兼ねる場合の書き方

カフェも併設した美容室、電気工事と水道工事の両方を手がける工務店など、複数の業種にまたがる事業もあります。この場合は @type に配列で複数の型を並べます。

Googleの公式ドキュメントでも、電気工事・配管・鍵屋を兼ねる例として配列指定が紹介されています。なお additionalType というプロパティはサポートされていないため、使わないでください。

{
  "@context": "https://schema.org",
  "@type": ["Electrician", "Plumber", "Locksmith"],
  "name": "アクセス設備サービス"
}

ただし、あれもこれもと型を並べすぎると、かえって何の店なのか伝わりにくくなります。看板として掲げている主力業種を2〜3個に絞るのが実務的です。

Organizationの項目もあわせて設定する

LocalBusinessは Organization（組織）のサブタイプにあたります。そのためGoogleは、LocalBusinessの項目に加えてOrganizationの項目にも従うことを推奨しています。

具体的には、ロゴ画像を指定する logo、公式サイトのURLを示す url、SNSアカウントを列挙する sameAs などです。ロゴを正しく指定しておくと、検索結果やナレッジパネルでの表示に使われる可能性があります。

sameAs には、Instagram・X・Facebookなど、自社が公式に運用しているアカウントのURLだけを書きます。運用していないアカウントや、他人が作った非公式ページを書いてはいけません。

推奨項目を足して「伝わる情報」を増やす

geo（緯度・経度）は小数点以下5桁以上

geo は店舗の位置を緯度・経度で示す項目です。住所の文字列だけでは特定しづらい場所でも、座標があれば地図上の位置がはっきりします。

geo自体は必須ではなく推奨項目ですが、書くなら精度の要件があります。Googleは緯度・経度とも小数点以下5桁以上の精度を求めていますので、「36.4」のような粗い値では要件を満たしません。

"geo": {
  "@type": "GeoCoordinates",
  "latitude": 36.39012,
  "longitude": 139.84567
}

座標はGoogleマップで店舗の位置を右クリックすれば確認できます。表示された数値をそのままコピーすれば、必要な桁数は自然と満たせます。

地図をサイトに載せる方法とあわせて整えたい方は、ホームページへのGoogleマップ埋め込みと店舗情報の見せ方も参考になります。

営業時間（openingHoursSpecification）の基本形

営業時間は openingHoursSpecification という項目で書きます。曜日と開店・閉店時刻をセットにして、必要なだけ並べる形です。

曜日が同じ時間帯なら、配列でまとめて書けます。平日9時〜21時、土日10時〜23時という店なら、次のように2つのかたまりで表現できます。

"openingHoursSpecification": [
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "21:00"
  },
  {
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Saturday","Sunday"],
    "opens": "10:00",
    "closes": "23:00"
  }
]

時刻は24時間表記で、必ず2桁ずつ書きます。「9:00」ではなく「09:00」と書く点に注意してください。

なお、臨時休業や年末年始のような一時的な変更は、サイトの構造化データよりもGoogleビジネスプロフィール側の「特別営業時間」で管理するほうが確実です。設定方法は営業時間・臨時休業の正しい設定で機会損失を防ぐで解説しています。

深夜営業・24時間営業・季節営業の書き分け

日付をまたぐ深夜営業は、開店曜日を1つ指定して、閉店時刻に翌日の時刻を書きます。土曜18時から日曜3時までなら、dayOfWeek は Saturday のまま closes を “03:00” とします。

24時間営業は opens を “00:00″、closes を “23:59” にします。一日中休業であることを示したいときは、opensもclosesも “00:00” にするのがGoogleの案内する書き方です。

"openingHoursSpecification": [
  { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "00:00", "closes": "23:59" },
  { "@type": "OpeningHoursSpecification", "dayOfWeek": "Sunday",   "opens": "00:00", "closes": "00:00" }
]

海の家やスキー場の売店のように期間限定で営業する場合は、validFrom と validThrough で有効期間を挟みます。この2つを書かなければ「一年を通じて有効な営業時間」という意味になります。

url・telephone・image・menuの扱い

url にはその店舗のページのURLを、telephone には店舗の電話番号を書きます。電話番号は国番号から始まる形（日本なら +81 で始まる形）で書くと、機械が確実に解釈できます。

image は店舗の写真のURLです。Googleの例では、1対1・4対3・16対9という3つの比率の画像を配列で並べる形が示されています。

表示先に応じて最適な比率が選ばれるためで、1枚しか用意できない場合でも問題はありません。まずは店の外観が分かる写真を1枚指定するところから始めてください。

飲食店の場合は menu にメニューページの完全なURLを書けます。画像に文字を焼き込んだメニューではなく、テキストで読めるメニューページを指定するほうが、機械にも人にも親切です。

priceRange（価格帯）は、日本の店舗なら「￥￥」のような記号でも「1000-3000円」のような文字列でも構いません。ただしサイト上の表示と食い違わないようにしてください。

部門（department）がある場合

同じ建物の中に、営業時間や電話番号が異なる部門がある場合は department という項目で入れ子にできます。ドラッグストアの中の調剤薬局、家電量販店の中の修理カウンターなどが典型例です。

部門名は「店舗名＋部門名」の形にするのがGoogleの案内です。ただし部門が独立したブランド名を持っている場合は、その名称単独で書いても構いません。

部門ごとに違う項目だけを個別に書けばよく、本体と同じ内容を全部書き直す必要はありません。実務上は、営業時間と電話番号が違うときだけ使えば十分です。

やりがちな失敗と、放置すると損をする落とし穴

自社サイトに自社の星評価を書いてはいけない

最も多い失敗がこれです。「Googleの口コミが4.6点だから、自社サイトの構造化データにも星4.6と書いておこう」という発想は、Googleのレビュー用ガイドラインの想定から外れています。

Googleは、レビュー対象の事業者自身がそのレビューを管理している状態を「自己申告のレビュー」と呼び、LocalBusinessとOrganizationについては自己申告のレビューをリッチリザルトの対象外にしていると明言しています。

つまり、自社サイトに自社のお客様の声を並べて aggregateRating を書いても、検索結果に星は出ません。Googleの口コミやSNSの評価を埋め込みウィジェットで表示している場合も、同じ扱いになります。

aggregateRating が推奨されるのは、口コミポータルのように「他の事業者のレビューを集めているサイト」の場合だけです。自店のサイトでは、原則として使わないと覚えておいてください。

なお、構造化データに対する手動による対策を受けた場合、そのページはリッチリザルトとして表示される資格を失います。Googleは、これがウェブ検索の順位そのものに影響するわけではないと説明しています。

お客様の声そのものをページに載せること自体は問題ありません。問題になるのは、それを星評価としてマークアップし、検索結果に表示させようとする行為です。

ページに表示されていない情報を書かない

構造化データの一般的なガイドラインでは、ユーザーに見えないコンテンツをマークアップすることが禁じられています。ページに書いていない営業時間や、実際には提供していないサービスを構造化データにだけ書くのはNGです。

たとえば「24時間対応」と構造化データに書きながら、ページには「9:00〜18:00」としか書いていない、という状態は避けてください。構造化データは、ページに書いてある内容を機械向けに言い換えたものであるべきです。

制作会社に依頼するときも、この原則だけは共有しておくと安全です。「見えている情報と同じ内容を、同じ値で書いてください」と伝えれば通じます。

GBP・サイト表記とのNAP不一致

構造化データの住所が「栃木県下野市小金井1-2-3」、サイトのフッターが「下野市小金井1丁目2-3」、Googleビジネスプロフィールが「小金井1-2-3」と、少しずつ違う。これは非常によくある状態です。

Googleは表記ゆれをある程度は吸収しますが、揃っているに越したことはありません。店名・住所・電話番号の3点セットを揃える考え方は、店名・住所・電話（NAP）を統一する重要性で詳しく解説しています。

構造化データを入れる作業は、こうした表記ゆれを棚卸しする良い機会でもあります。サイト・GBP・ポータルサイト・名刺まで、まとめて見直してみてください。

電話番号・住所の書式でつまずくポイント

電話番号を「028-123-4567」のようにハイフン区切りで書いても間違いではありませんが、国番号付きの形のほうが機械にとって曖昧さがありません。「+81281234567」のように書けば確実です。

addressCountry には、国名ではなく2文字の国コード（日本なら「JP」）を書くのが推奨されています。ここに「日本」や「Japan」と書いてしまう例をよく見かけます。

また、JSON-LDは1文字でも書式を間違えると全体が読み取られなくなります。カンマの付け忘れ、閉じ括弧の抜け、全角の引用符などが典型的なつまずきどころです。

「入れたのに何も変わらない」と焦らない

構造化データを追加しても、その日のうちに検索結果が変わることはまずありません。Googleがページを再クロールして再インデックスするまで、数日かかることもあります。

また、LocalBusinessの構造化データが必ずリッチリザルト（装飾された検索結果）として表示されるわけでもありません。表示するかどうかはGoogleの判断であり、要件を満たすことは「対象になる資格を得る」ことを意味するだけです。

入れた直後に何も起きなくても、設定が間違っているとは限りません。まずは後述するテストツールで「エラーがないこと」を確認し、あとは腰を据えて待つのが正解です。

導入手順とチェック方法｜多店舗・出張型のケースも

どのページに置くのが正解か

Googleは「LocalBusinessの構造化データはサイト内のどのページにも追加できますが、ビジネスに関する情報を含むページに置くほうが理にかなっています」と説明しています。

店舗が1つなら、トップページか「店舗情報」「アクセス」ページのどちらかに置くのが自然です。複数のページに同じ内容を重複して置く必要はありませんので、置き場所は1つに決めましょう。

店舗ページを持っている場合は、そのページに置くのが最も分かりやすい形です。ページの内容と構造化データの内容が一致していれば、Googleも判断に迷いません。

WordPressでの入れ方は3パターン

1つめは、SEO系プラグインの店舗情報設定を使う方法です。多くのプラグインには「ローカルビジネス」向けの入力欄があり、フォームに入力するだけで構造化データを出力してくれます。

2つめは、テーマのカスタム機能やウィジェットで、ヘッダーにコードを差し込む方法です。SWELLのようにカスタムコードを追記できるテーマなら、head内に1回だけ書けば済みます。

3つめは、固定ページの中にHTMLブロックとしてJSON-LDを貼る方法です。手軽ですが、テーマを変えると消えてしまうことがあるため、どこに書いたかを必ずメモしておいてください。

どの方法でも構いませんが、同じ店舗の情報を2つの方法で二重に出力してしまうことだけは避けてください。プラグインとテーマの両方から出力されていないか、必ず確認しましょう。

リッチリザルトテストとURL検査で確認する

書いたコードが正しいかは、Googleの「リッチリザルトテスト」で確認できます。URLを入力するか、コードを直接貼り付けると、検出された項目とエラーが一覧で表示されます。

Googleの手順では、まず致命的なエラーを修正することが求められています。致命的でない警告についても、直しておくと構造化データの品質向上につながります。

公開後は、Search ConsoleのURL検査ツールで「Googleが実際にどう見ているか」を確かめます。robots.txtやnoindexタグ、ログイン制限でブロックされていないかもここで分かります。

問題がなければ、URL検査ツールからインデックス登録をリクエストして、再クロールを促しておくとよいでしょう。

多店舗は「1店舗＝1ページ＝1件」が原則

複数の店舗を運営している場合、1つのページに全店舗の情報を詰め込むのは避けたほうが賢明です。店舗ごとに個別ページを作り、そのページにその店舗のLocalBusinessを1件だけ置きます。

Googleも「各店舗をそれぞれ1つのLocalBusinessタイプとして定義してください」と案内しています。店舗一覧ページはあくまで入口とし、実データは各店舗ページに持たせる構成が管理しやすいはずです。

店舗数が多い場合は、CSVなどで店舗マスタを管理し、そこから自動でJSON-LDを生成する仕組みにすると、更新漏れが起きにくくなります。

店舗を持たない出張・訪問型の場合

出張整体や訪問リフォームのように、お客様の場所へ出向く業態では、住所を公開したくないケースがあります。この場合、schema.orgには areaServed や serviceArea といった対応エリアを示す項目があります。

ただし、LocalBusinessの必須項目である address を省略すると要件を満たさなくなります。事業所の所在地を書ける場合は書き、公開したくない場合はGoogleビジネスプロフィール側でサービス提供地域として設定するのが現実的です。

この判断は事業の実態によって変わります。バーチャルオフィスや自宅住所の扱いには注意すべき点が多いため、迷うときは無理に公開せず、GBP側の設定を優先してください。

入れた後にやっておきたいこと

構造化データを追加したら、サイトマップを送信して変更をGoogleに伝えておきます。WordPressなら標準のサイトマップが自動生成されているはずなので、Search Consoleに登録済みか確認するだけで十分です。

あとは定期的な棚卸しです。営業時間を変えた、電話番号を変えた、店名を変えた——こうした変更のたびに、構造化データも直す必要があります。

放置された古い営業時間ほど、機会損失につながるものはありません。年に2回でも構わないので、見直す日を決めておくことをおすすめします。

よくある質問（FAQ）

Q. 構造化データを入れれば、Googleマップの順位は上がりますか？

直接的に順位を上げるものではありません。Googleはローカル検索の順位を関連性・距離・視認性で判断すると説明しており、構造化データは順位要因として公表されていません。

ただし、店舗情報を正確に伝えることは関連性の理解を助けます。順位対策というより、土台を整える作業として取り組むのが適切です。

Q. プラグインで入れた分と手書きの分が二重になっても大丈夫？

推奨できません。同じ店舗について矛盾する情報が2つ出力されると、Googleがどちらを信じればよいか判断できなくなります。

リッチリザルトテストで検出される項目を確認し、同じ内容が2件出ていないかを必ずチェックしてください。二重になっている場合は、どちらか一方を止めます。

Q. 医療機関や士業でも、同じように設定してよいですか？

基本的な考え方は同じで、MedicalClinic や Dentist、LegalService といった専用の型が用意されています。診療科目や対応業務を正確に書ける点はメリットです。

ただし医療広告ガイドラインなど、業種固有の規制がかかる表現があります。治療効果や実績の書き方については、必ず専門家にご相談ください。

Q. 反映されるまでどのくらいかかりますか？

Googleは、ページを公開してから見つけてクロールするまでに数日かかることがあると案内しています。再クロールと再インデックスの時間を見込んでおいてください。

急ぐ場合は、Search ConsoleのURL検査ツールから再クロールをリクエストできます。それでも即時反映が保証されるわけではありません。

Q. JSON-LD以外の書き方でもいいですか？

microdataやRDFaといった書き方もサポートされていますが、GoogleはJSON-LDを推奨しています。HTMLの構造から切り離して書けるため、後から修正しやすいという実務上のメリットも大きいです。

これから新しく入れるのであれば、迷わずJSON-LDを選んでください。

お困りのことがあればご相談ください

構造化データは、正しく設定すれば店舗情報の伝わり方を底上げしてくれる一方、書式のミスひとつで丸ごと無効になる、少し扱いのむずかしい仕組みでもあります。

株式会社アクセス・リンクでは、全日本SEO協会認定SEOコンサルタントの三田が、店舗サイトの構造化データ設定からGoogleビジネスプロフィールの運用改善まで、実務ベースでお手伝いしています。

「自分のサイトに入っているか分からない」「入れてみたが正しいか自信がない」といった段階でも構いません。お問い合わせフォームから、お気軽にご相談ください。