ローカル SEO と Google ビジネスプロフィール

ローカル SEO は、実在の場所（来店可能な店舗、クリニック、訪問できるオフィス、またはサービス提供エリア型のビジネス）を、Google マップ、検索のローカルパック、そして「近くの〜」や都市名を含むクエリに対するアシスタントの回答で見つけやすくするための取り組みです。中心となるのは、ほぼ常に、オーナー確認済みで項目が埋まった Google ビジネスプロフィールであり、それを全ての場所で同一の名称／住所／電話番号（NAP）で支え、適法なレビューと、サイト上の LocalBusiness 構造化データで裏付けることです。

このページでは、例として SaaS を提供する「Fernwood」がオースティンに顧客向け教育スタジオを運営し、ハンズオンの経費ワークショップを予約できる状況を想定します。スタジオには住所、営業時間、電話があります。訪問可能な場所やサービス提供エリアがまったくない純粋なオンライン製品は、この手法の大部分を省略できます。その場合の取り組みは、代わりに Organization identity markup と Review platform presence に該当します。

本ページは、Review platform presence が Google ビジネスプロフィールに触れる際に概説した内容をローカル観点で掘り下げたものです。レビューは依然として重要ですが、ここではプロフィール、地図のピン、エンティティ整合性こそが成果物です。

なぜ有効か

Google は、ローカル検索結果は主に「関連性」「距離」「知名度」に基づくと述べています（ローカル検索での掲載順位を改善するためのヒント）。

関連性 — クエリとプロフィールの適合度。カテゴリ、提供サービス、属性を正確かつ完全にすると一致度が高まります。
距離 — 検索者（またはクエリ内で指定された場所）からの距離。近づくように「SEO で操作」することはできません。実際の営業エリアを正直に示すのみです。
知名度 — ウェブ全体での知れ渡り度。リンク、言及、そして特にレビューと評価が効きます。

アシスタントが「オースティンで経費トレーニング」や「訪問できる Fernwood のオフィスはある？」に答える際も、参照するのは同じ公開エンティティグラフです。すなわちビジネスプロフィール、ロケーションページ、各種ディレクトリ、レビューサイトです。NAP の不一致（サイトとマップで電話が違う等）は単なる誤記ではなく、エンティティの曖昧さです。Google 自身がビジネスプロフィール情報を完全かつ正確にと強調するのは、不正確なプロフィールは関連するローカル検索に表示されない可能性があるためです。

適用タイミング

次のいずれかに当てはまる場合に、この手法を適用します:

状況	対応
顧客が実店舗を訪れる	GBP を完全化 + ロケーションページ + LocalBusiness マークアップ
店舗を持たず特定の地理的エリアで提供（配管工、出張トレーナーなど）	サービス提供エリア型のビジネスプロフィール。NAP／対応都市も統一
複数拠点ブランド	拠点ごとに 1 プロフィール（通常は 1 ロケーション URL）。拠点を統合しない
ローカル拠点のない SaaS／メディア	対象外。マップ対策のために偽のピンを作らない

訪問実態がないのに自宅住所やコワーキングの私書箱を使って仮想ブランドの Google ビジネスプロフィールを作成することは、Google の禁止および制限されている行為に違反し、審査に耐えません。

1. Google ビジネスプロフィールを所有権確認し、完全に埋める

顧客が実際に訪れる場所（または実際にカバーするサービス提供エリア）に対して、プロフィールを「申請・作成」します。
まずは主カテゴリ。人々が検索に使うカテゴリ（「企業向け研修センター」「ソフトウェア会社」など）を選びます。副カテゴリは補助的なシグナルで、主カテゴリが関連性マッチの大半を左右します（Google のローカル掲載順位のヒント）。
真実であるすべての項目を入力します。営業時間（特別営業時間含む）、電話、ウェブサイト URL（ロケーションのランディングページを推奨）、予約リンク、属性、サービス、そしてロケーションページと一致する短い説明文。都市名が合っていない全国向けスローガンは避けます。
写真と投稿。実際の外観、内観、チーム、製品の写真はストックよりも有効です。営業時間や祝日の案内を常に最新に保ちましょう。プロフィールが「営業中」と表示しているのに店舗が閉まっているのは信頼を損ない、クリックを無駄にします。
Google の掲載に関するルールに従います。管理権限のあるビジネスのみを代表し、情報を正確かつ最新に保ち、所在地・アイデンティティ・サービス提供エリアについて誤解を与えないでください（Google でビジネス情報を表示するためのガイドライン）。

2. NAP をあらゆる場所で同一にする

略記（Suite と Ste、Street と St）や電話番号の表記も含め、名称・住所・電話番号の「正準（canonical）」な表記を 1 つ決め、それを唯一の真実（SoT）として扱います。

掲載先	そろえる内容
Google ビジネスプロフィール	Google におけるマスターレコード
fernwood.example のロケーションページ	画面に見える NAP + LocalBusiness の JSON-LD
サイト全体の会社／連絡先フッター	同一の電話番号と住所表記
Apple Business Connect、Bing Places、Yelp、業界ディレクトリ	同一の文字列
メール署名、PDF、広告	同一の文字列

変更が起きたら（新しいスイート番号、代表番号の変更など）、まず GBP を更新し、次にウェブサイト、そして各ディレクトリを更新します。公開 NAP と異なるコールトラッキング番号は広告内のみに使用し、GBP の主電話にしてはいけません。避けたいはずの不一致を自ら生み出すことになります。

3. 実体のあるロケーションページを公開する

各拠点（または単一のスタジオ）には、JavaScript なしでもクローラが読める公開 HTML ページが必要です—Content readable without JavaScript を参照。最低限のコンテンツ:

GBP と同一の NAP（通常の可視テキストで記載）
営業時間、駐車／アクセス情報、この場所で提供される内容
地図の埋め込みは任意。住所テキストを地図ウィジェットだけで置き換えない
そのページの主要 CTAとして、予約・電話・経路案内へのリンク
ページが記事的な性質なら機械判読可能な日付（安定したロケーションの定型ページのみなら不要）

4. LocalBusiness 構造化データを宣言する

ロケーションページでは、可視テキストの NAP と一致する JSON-LD を追加します。可能な限り具体的なサブタイプ（Store、ProfessionalService、EducationalOrganization、または汎用の LocalBusiness）を使用します。サイト全体の Organization エンティティとは分離して維持してください。ロケーションマークアップは「場所」を追加するもので、会社情報の置き換えではありません。

<script type=\"application\/ld+json\">
{
  \"@context\": \"https:\/\/schema.org\",
  \"@type\": \"LocalBusiness\",
  \"@id\": \"https:\/\/fernwood.example\/locations\/austin#place\",
  \"name\": \"Fernwood Austin Education Studio\",
  \"image\": \"https:\/\/fernwood.example\/locations\/austin\/exterior.jpg\",
  \"url\": \"https:\/\/fernwood.example\/locations\/austin\",
  \"telephone\": \"+1-512-555-0142\",
  \"address\": {
    \"@type\": \"PostalAddress\",
    \"streetAddress\": \"500 Congress Ave Suite 200\",
    \"addressLocality\": \"Austin\",
    \"addressRegion\": \"TX\",
    \"postalCode\": \"78701\",
    \"addressCountry\": \"US\"
  },
  \"geo\": {
    \"@type\": \"GeoCoordinates\",
    \"latitude\": 30.2672,
    \"longitude\": -97.7431
  },
  \"openingHoursSpecification\": [
    {
      \"@type\": \"OpeningHoursSpecification\",
      \"dayOfWeek\": [\"Monday\", \"Tuesday\", \"Wednesday\", \"Thursday\", \"Friday\"],
      \"opens\": \"09:00\",
      \"closes\": \"17:00\"
    }
  ],
  \"parentOrganization\": {
    \"@id\": \"https:\/\/fernwood.example\/#organization\"
  }
}
</script>

求められる誠実性のルールは、Google のローカルビジネス構造化データのガイダンスおよび構造化データポリシーに一致します。ユーザーが見えるもののみをマークアップし、座標・営業時間・レビューを捏造しないでください。JSON-LD は初期 HTML での出力を推奨します。

ビジネスプロフィール（および他の公式プロフィール）は、企業エンティティの sameAs リストに組み込みます—Organization identity markup を参照。

5. ローカルレビューを適法に獲得する

レビューはローカル順位付けの明示された知名度要因です（Google のローカル掲載順位のヒント）。収集は Review platform presence と同じ法的ルールに従います。

直近の顧客に中立的に依頼する — Google はレビューへのインセンティブ提供を禁止しています（Google レビューポリシー）。
感情（評価の良し悪し）で選別しない。
否定的なレビューには事実で公開返信する。
レビューの購入、ゲーティング、正当な批判の抑止は行わない—これは偽・誘導レビューに該当します。

6. サイテーションと言及（スパムなし）

主要ディレクトリ（Apple、Bing、Yelp、業界団体）で NAP を一貫させることはエンティティ解決を支援します。だからといって数千件の粗雑なサイテーションやプライベートブログネットワークを購入してよい理由にはなりません。推奨は次のとおりです。

顧客が実際に利用するプラットフォームでの正確な掲載
実際の露出がある場合に都市名や場所を明記するデジタル PR
ロケーション URL への本物のリンクを生むローカル連携

ありがちな失敗パターン

失敗例	問題となる理由
未申請または放置された GBP	競合や顧客に情報を決められる／誤った営業時間が固定化
サイト／マップ／広告で NAP がずれる	実体の信頼度が低下／不通番号に電話が流れる
偽または過大なサービス提供エリア	ガイドライン違反。短期の可視性はあっても長期的には停止リスク
LocalBusiness を JS だけで出力	多くのクローラが認識できない
レビューのゲーティング／買われた星	ポリシー・法的リスク。偽レビューの手法を参照
1 つの GBP で 5 拠点を代表	顧客の行き先を誤認させる

Silktide が支援できること

Silktide は Maps のローカルパック順位そのものを製品として評価するわけではありません。ローカル SEO が依存するオンサイトおよびマークアップ要素を評価します。

Structured data／Structured data validity — name など LocalBusiness の必須項目を含む
AI schema signals — Organization の sameAs（企業エンティティからリンクすべき公式プロファイル）
Content readable without JavaScript — ロケーション本文と JSON-LD は初期 HTML 内に存在する必要
Review platform presence — GBP の知名度に寄与する適法なレビュー戦略