LocalBusiness構造化データの
書き方｜値の決め方でずれが生まれる理由

先に結論を書きます。LocalBusinessスキーマ（構造化データ）は、入れたら順位が上がる魔法のタグではありません。それでも店舗サイトには入れる価値があります。理由は2つ。検索エンジンとAIに「どこにある、何の店か」を誤解の余地なく伝えられること。そして、Googleマップ・自社サイト・各種ポータルの情報が機械的に照合しやすくなり、情報の信頼性の裏付けになることです。この記事では、仕組みの説明から、JSON-LDの骨格、検証ツールを通っても安心できない理由、そして実装したあとに必ず訪れる更新の問題までを解説します。

構造化データは「何をしてくれる」のか

人間はホームページを見れば「池袋にある整体院で、平日は20時まで」と読み取れます。しかし検索エンジンやAIにとって、ページ上の文字は最初「ただのテキストの並び」です。どれが店名で、どれが住所で、どの数字が電話番号なのか——それを機械が読める形式でラベル付けして渡すのが構造化データです。schema.orgという共通規格があり、店舗ビジネス用の型が「LocalBusiness」です。

効果として期待できるのは次の2つです。

• 情報の正確な伝達: 検索エンジンが店舗情報を誤読するリスクを減らす。Googleビジネスプロフィールや他サイトの情報と照合され、「同一の実在店舗」という確認材料になる
• 検索結果での表示: 検索結果の表示形式に使われることがあるとされる（保証はされません）

そして近年重要度が増しているのがAI検索との関係です。ChatGPTやGoogleのAIによる概要が店舗を紹介するとき、参照元の情報が構造化されているほど誤引用が起きにくくなります。MEOとLLMO（AI検索対策）の両方の土台になるのが構造化データ、という位置づけです。単体で順位を動かすタグではないぶん、ここで正確さを担保できているかどうかが、その上に積むカテゴリ・口コミ・写真といった打ち手の効き方を左右します。

LocalBusinessスキーマの項目は、どこで判断が割れるか

プロパティ（項目）は数十種類あり、役割で分けるといくつかの層になります。ただ、層の分け方を知ることと、自店でどこまで書くかを決めることは別の作業です。店舗の同一性を示す部分では、GBPや各種ポータルとの表記をどう揃えるかが問われます。どの表記を正とするかを先に決めないと揃える対象が定まらず、直した先から古い表記が戻ることがあります。営業実態を示す部分は、実態が複雑な店ほど表現が難しくなります。そして補足にあたる情報は書くほど良いわけではなく、実態とずれた値を置けば他の部分の信頼まで下げます。しかも下がったことは画面に何も表示されないので気づけません。

@typeは「LocalBusiness」のままでも動きますが、より具体的な下位タイプが用意されている業種は、そちらのほうが情報として正確になります。ただし、複数の業態を持つ店ではどのタイプを名乗るかが一意に決まりません。カテゴリ設定と同じで、ここも「自店をどう定義するか」の判断が先に立ちます。

そして、これらの層はどれも「一見どちらでもよさそうに見える」選択肢の連続です。住所にビル名を含めるか省くか、営業時間を1本にまとめるか曜日別に割るか、下位タイプを名乗るか広いままにするか——どちらを選んでも構文は通り、画面上の見た目も変わりません。ところが取り違えると、GBP側の情報と機械的に照合されず、せっかく書いた情報が「同じ店の裏付け」として使われないまま眠ります。損失は「間違いが表示される」形では出ず、「何も起きない」形で出る。だから間違えたことに気づけないまま、半年後に「構造化データは効かなかった」という結論だけが残ります。判断材料は自店の情報だけでは足りません。同じ商圏の競合がどの粒度で情報を出し、Googleがそれをどう束ねているかと突き合わせて初めて、どちらに倒すかが決まります。この粒度は「書ける項目をすべて埋める」という方針からは決まりません。狙う検索語に対して機械が照合すべき情報はどれか、から逆算する以外に決めようがない種類の判断です。

記述例（JSON-LD）の骨格

Googleが推奨する書き方はJSON-LD形式です。骨格だけを示すと、次のような構造になります。

構造としてはこの形が土台になります。ただし難所は構文の側ではなく、値の決め方にあります。住所ひとつ取っても、ビル名や階数をどこまで含めるか、GBPの登録とどちらの表記に揃えるかで、機械側の照合精度が変わります。営業時間も、曜日別・季節別・臨時休業をどこまで表現するかで、書く量が何倍にもなります。「とりあえず埋めた」構造化データは、実態とずれた瞬間に、間違った情報を機械に断言する装置に変わります。

置く場所そのものは、店舗の基本情報が載っているページであれば構文上はどこでも成立します。ただし置く数を増やすほど、情報が変わったときに直し漏れる箇所も増えます。さらにWordPressのようにSEO系プラグインが同種の出力をしている場合、手書きの記述との食い違いが重なることがあります。プラグイン側と手書きが食い違っていると、どちらが正なのか機械にも判別できません。そしてこの食い違いは、画面上にも検証ツール上にも一切表示されません。

検証ツールを通っても、なぜ安心できないのか

構造化データには公式の検証ツールが用意されていて、構文が壊れていれば知らせてくれます。ただし、どの検証ツールも「内容が正しいか」は見てくれません。実在しない住所を書いても、去年の営業時間を書いても、文法として正しければ通過します。通知されるのは「壊れている」ときだけで、「正しい形式で、間違った内容を書いている」状態には、どこからも警告が出ません。画面上はすべて緑のまま通るので、見るべき場所を知っていないと、そもそも疑うきっかけが生まれない領域です。検証を通ったという安心だけを持ったまま、機械には矛盾した情報を渡し続ける——実装した店舗で起きやすい失敗の形がこれです。

※当社FACTORは、この構造化データの実装と、GBP・サイト・スキーマをずらさず保ち続ける運用を、設計から運用ごと引き受けています。どこまで実装するかを決めるとき見ているのは自社のページだけではなく、同じ検索語で上に並ぶ他社がどういう形で表示されているか、その並びが語や地点を変えたときにどう入れ替わるかです。他社側の表示の推移は自社の管理画面には一行も残らないため、社内では最初から組み立てようがありません。営業時間の変更、移転、電話番号の切り替え、年末年始の臨時営業——店舗の情報は思っている以上に動きます。そして変わったことに気づいて3点を同じ日に同じ値へそろえる作業は、誰かが見続けていなければ止まります。しかも止まったことは誰も教えてくれません。ずれた構造化データは、書いていない状態より性質が悪く、間違った情報を機械に断言し続けます。

よくあるミスと、放置したときの損失

気づけない形で外れているミス

ずれ方は店ごとに違いますが、構造化データは「機械に断言する」仕組みなので、間違った情報を堂々と伝え続けることになります。JSONがカンマ1つの抜けで丸ごと読めなくなっている、という形もここに入ります。共通しているのは、ずれていることが検索結果にも画面上にも出ないことです。気づくきっかけは、たいてい「閉まっていた」という口コミが入った時になります。

そしてこの期間に抜けていくのは客数です。営業しているのに閉まっていることになっている店、移転前の住所を機械に断言し続けている店は、行こうとしていた人がその手前で離脱します。放置した月数ぶん来店が他店に吸われ続け、しかも取りこぼした分は自店の数字のどこにも記録されないので、売上が痩せていることに気づくのは常に後になります。

線を越えてしまうミス

代表的なのは、検索結果に星を出したいがために、根拠のない評価値を書き込むケースです。実際のレビューの裏付けがない評価のマークアップはGoogleのガイドライン違反で、リッチリザルトの対象外になったり、手動対応の対象になるリスクがあります。ほかにも判断の要る線はありますが、どの線に当たるかは扱う商材と業種の規制によって変わります。

なお、自店のサイトとGBPが機械側からどう見えているのかは、店の中からは確かめられません。GoogleマップのURLを貼ると要点がその場で表示される無料のAI診断で、いまの見え方は外から押さえられます。

よくある質問

まとめ

LocalBusiness構造化データは、店舗情報を機械に正確に伝えるための土台です。構文を書いて検証ツールを通すところまでは形になっても、結果を分けるのは値の決め方です。どの表記を正とするか、実態が複雑な項目をどこまで書き切るかは、構文の側からは決まりません。しかも本番はさらにその先、情報が変わるたびにGBP・サイト・スキーマをずらさず更新し続けるところにあります。情報がよく動く店ほど、気づかないうちに古い住所や去年の営業時間を機械に断言し続けています。そしてずれたことは、画面上にも検証ツール上にも一切表示されません。機械から自社がどう見えているかは、店の中からは再現できない情報です。順位を狙いにいくなら、並び順の施策に加えてこの土台が乗ります。だからこそ、まずいまの出方を外から見てもらうところから始めてください。そこだけは持っている側に出してもらうほうが早い領域です。