自社サイトでやるMEO対策｜NAP統一とローカルビジネス構造化データ

Googleマップの上位表示を狙うとき、自社サイト側でやることは大きく2つです。

• NAPの統一：店舗名・住所・電話番号の表記を、サイトとGoogleビジネスプロフィールで完全に一致させる
• 構造化データの設置：その情報をローカルビジネスの構造化データ（JSON-LD）で機械が読める形にして置く

この記事は、Googleビジネスプロフィールの設定はひととおり済んでいて、次にホームページ側で何をすればいいか分からない方に向けて書いています。読み終わる頃には、表記ゆれの洗い出し方、コピペして使えるJSON-LDの雛形、公開後の検証手順まで、自分の手で進められる状態を目指します。

なお、Googleビジネスプロフィール側の基本設定（カテゴリ・営業時間・写真など）は範囲外です。そちらがまだの方は先にGoogleマップ順位を自社で上げる基本設定5つとチェックリストを読んでから戻ってきてください。

Contents / 目次

1. 自社サイト側でやるMEO対策は「NAP統一」と「構造化データ」の2つだけ
2. ステップ1〜4。NAPの表記ゆれを棚卸しして1つに決める手順
3. ローカルビジネス構造化データ（JSON-LD）の書き方とコピペ用の雛形
4. Googleマップの上位表示にSEOは効くのか。サイト側が担いでいるもの
5. よくある失敗5パターンと、その防ぎ方
6. 構造化データを入れる前に知っておきたい、現場での限界
7. よくある質問
8. 今日やる最初の1つ

自社サイト側でやるMEO対策は「NAP統一」と「構造化データ」の2つだけ

ホームページ側でMEO対策としてやるべきことは、突き詰めると次の2つです。

• NAP表記を揃える：サイト上のNAP表記を、Googleビジネスプロフィールと1字単位で揃える
• 同じ情報を機械向けに置く：その同じ情報を、ローカルビジネスの構造化データとしてHTMLに埋め込む

NAPとは、Name（店舗名・会社名）、Address（住所）、Phone（電話番号）の頭文字をとった呼び方で、店舗情報の骨格にあたる3点セットのことです。Googleは、あちこちに散らばったこの3点を突き合わせて「これは同じお店だ」と判断しています。

だから、サイトのフッターが「大分市寿町8-11」で、Googleビジネスプロフィールが「大分県大分市寿町8丁目11番」で、ポータルサイトが「大分市寿町8-11 1F」だと、Googleから見て同じ店かどうかの確信が持ちにくくなります。ここを揃えるのが1つ目の仕事です。

ローカルビジネスの構造化データとは、店舗名・住所・電話番号・営業時間などを、検索エンジンが誤解しないきまった書式で記述したデータのことです。人間が読むページ本文とは別に、機械向けの「名刺」をページの中に1枚入れておくイメージだと思ってください。

先に誤解を解いておきます。構造化データを入れれば地図検索の順位が上がる、とGoogleは公表していません。Google ビジネス プロフィール ヘルプ「Google のローカル検索結果でのビジネスの掲載順位を改善する」では、ローカル検索結果の順位が関連性・距離・知名度の組み合わせで決まると説明されています。 構造化データの役割は順位の押し上げではなく、情報の食い違いをなくすことにあります。

やること	具体的な作業	初回の目安時間	期待していい効き方
NAP表記の統一	サイト・GBP・ポータル・SNS・PDFの表記を洗い出し、1つの正解表記に寄せる	媒体数によって大きく変わる	同一ビジネスとして認識されやすくなる。移転や社名変更のときの事故を防ぐ
ローカルビジネス構造化データ	店舗ページにJSON-LDを1つ設置し、リッチリザルトテストで検証	雛形があれば1ページ単位で完結する（2拠点目以降は短縮できる）	営業時間・所在地・電話番号を機械が誤読しにくくなる
（補助）店舗ページの整備	1拠点＝1ページにして、NAPをテキストで明示する	ページの構成量による	指名検索や「エリア＋業種」の受け皿になる

順番も決まっています。先にNAPを統一してから、構造化データを書きます。表記がバラバラなまま構造化データを入れると、食い違った情報を機械可読な形でわざわざ宣言することになり、状況が悪化します。

この章の結論として、自社サイト側のMEO対策は「新しい施策を足す」話ではなく、「すでにバラバラになっている情報を1つに揃えて宣言し直す」作業だと考えてください。順位を買いに行く施策ではないぶん、地味ですが失敗しにくい領域です。

ステップ1〜4。NAPの表記ゆれを棚卸しして1つに決める手順

NAP統一は、正解の表記を1つ決めて、そこに全媒体を寄せる作業です。いきなりサイトを直すのではなく、まず今どうなっているかを一覧にするところから始めます。

ステップ1. 自社の情報が載っている媒体を全部書き出す

スプレッドシートを1枚作り、1行1媒体で書き出します。ここで漏れが出ると、あとから「あの求人サイトだけ旧住所だった」という事故になります。

• 自社サイト：トップのフッター、会社概要ページ、店舗ページ、お問い合わせページ、特定商取引法の表記
• Googleビジネスプロフィール：ビジネス名、住所、電話番号（拠点ごとに1行）
• ポータル・予約サイト：業種ごとの掲載媒体、地図アプリ、業界団体の会員名簿
• SNS：Instagramのプロフィール、Facebookページ、LINE公式アカウントのプロフィール
• 紙・PDF：会社案内PDF、見積書・請求書のテンプレート、メール署名、名刺データ

媒体数は業種や拠点の状況で大きく変わります。多いと感じるかもしれませんが、この一覧そのものが資産です。移転や電話番号変更のときに、そのまま作業リストとして使えます。

ステップ2. 正解の表記を1つ決める（迷ったらGBPに合わせる）

表記の正解は、Googleビジネスプロフィールに登録済みの表記に合わせるのが最も手戻りが少ない選び方です。Google ビジネス プロフィール ヘルプ「ビジネス情報を編集する」では、編集した内容が公開されるまでに審査が行われる場合があると案内されています。サイト側を動かすほうが手戻りが少ない、というのが理由です。

決めるべきポイントは次のとおりです。

迷いやすい箇所	決め方	例
丁目・番地の書き方	GBPの表記に合わせて、ハイフン形式か漢数字形式かを固定する	「1-2-3」に統一するなら全媒体で「一丁目2番3号」を使わない
ビル名・階数	GBPに入っているなら全媒体に入れる。入っていないなら全媒体で書かない	「〇〇ビル2F」を書くか書かないかを揃える
都道府県から書くか	どちらでもよいが、サイト内で混在させない	フッターだけ「大分県」なし、はNG
法人格の位置と表記	登記どおりの前株・後株を守り、「(株)」の省略形は使わない	「株式会社〇〇」で統一
店舗名の付け方	GBPのビジネス名と完全一致。キーワードの後付けはしない	「〇〇整体院 大分駅前店」（「大分 腰痛」等を足さない）
電話番号の区切り	ハイフンありなしを固定。全角数字は使わない	「097-537-7522」で統一

Google ビジネス プロフィール ヘルプ「ビジネス情報を編集する」のビジネス名に関する説明では、実店舗で使われている正式名称を使い、キーワードや所在地情報を余分に含めないよう求められています。 サイト側の見出しでキーワードを使うのは自由ですが、NAPの「N」として書く名称は、看板と登記に合った正式名称だけにしてください。

ステップ3. 表記ゆれの洗い出しをAIに手伝わせる

棚卸しの一覧ができたら、差分チェックはAIに任せると速くなります。人間の目は「大分市寿町8-11」と「大分市寿町8‐11」（ハイフンの種類違い）を見分けるのが苦手だからです。

渡すものはシンプルで、正解として決めたNAPと、各媒体から拾ってきた実際の表記の一覧、この2つだけです。出発点になる頼み方は次くらいで十分です。

以下が正解のNAPです。
名称：［正式名称］
住所：［正解の住所表記］
電話：［正解の電話番号］

下の一覧は各媒体に実際に載っている表記です。正解と1字でも違う箇所を、
媒体名・違っている箇所・修正後の文字列の3列の表にしてください。
全角半角、ハイフンの種類、スペースの有無も違いとして扱ってください。

［媒体名と実際の表記を貼り付け］

人が必ず確認するのは1点だけです。AIが出した「修正後の文字列」が、Googleビジネスプロフィールの実際の登録内容と一致しているかを、管理画面を開いて目視で突き合わせてください。AIは渡された一覧の中でしか整合を取れないので、正解そのものが間違っていたら全媒体を間違った表記に揃えてしまいます。

ステップ4. サイト側のNAPをテキストで置き直す

サイトを直すときは、住所と電話番号を必ずテキストで書きます。画像に焼き込まれた住所は、人間には読めても機械には読めません。

フッターや店舗ページに置く形は、次のようなものが扱いやすいです。

<!-- 店舗ページ・フッター共通のNAP表記。テーマのfooter.phpや
     ウィジェットに貼る想定。住所・電話は［　］内を自社の値に変更 -->
<div class="shop-nap">
  <p class="shop-nap__name">［サンプル整体院 大分駅前店］</p>
  <p class="shop-nap__address">〒［870-0000］ ［大分県大分市中央町1-2-3 サンプルビル2F］</p>
  <p class="shop-nap__tel">
    電話：<a href="tel:［097-000-0000］">［097-000-0000］</a>
  </p>
  <p class="shop-nap__hours">営業時間：9:00〜18:00（日曜・祝日は休み）</p>
</div>

電話番号は tel: リンクにしておくと、スマホからそのまま発信できます。href の中の番号と、画面に表示する番号は必ず同じにしてください。

多拠点の場合は、1拠点＝1ページを原則にします。会社概要ページに全店の住所をまとめて羅列すると、どの住所がそのページの主題なのかが機械側から判断できません。拠点が多くて管理が回らない場合の運用ルールは多拠点の店舗情報を統一する管理術｜NAP統一と口コミ運用ルールにまとめています。

この章の結論です。NAP統一で一番時間がかかるのは修正作業ではなく、媒体の洗い出しです。一覧を1枚作っておけば、次の移転・番号変更のときに同じ苦労を繰り返さずに済みます。

ローカルビジネス構造化データ（JSON-LD）の書き方とコピペ用の雛形

ローカルビジネス構造化データは、JSON-LDという書式でページの中に1ブロック置いて使います。設置位置や必須プロパティの扱いはGoogle 検索セントラル「ローカル ビジネス（LocalBusiness）の構造化データ」に記載があるので、書く前に現行のマークアップ例を確認してください。同ドキュメントでは、ローカルビジネスの構造化データがビジネスの営業時間や所在地などをGoogleが理解するのに役立つと説明されています。

下の雛形は、どのプロパティが必須でどれが推奨かを筆者が判断したものではありません。必須・推奨の区分と、各プロパティの意味はGoogle 検索セントラル「ローカル ビジネス（LocalBusiness）の構造化データ」とschema.orgのLocalBusinessで必ず確認してください。Google側の扱いは更新されることがあります。priceRange・geo・openingHoursSpecification などを雛形に入れているのは、店舗情報として書ける項目を一通り見せるためで、すべてを埋めないと無効になるという意味ではありません。自社に当てはまらない項目は削って構いません。

まずはこのJSON-LDをコピーして値を差し替える

次のコードは、1拠点の店舗ページに置く想定の完結した例です。［　］で囲んだ部分を自社の値に変えれば動きます。

<!-- 店舗ページの <head> 内に貼る。1ページにつき1店舗分。
     ［　］の中を自社の値に差し替える。JSONにコメントは書けないので、
     貼り付けたあとに ［　］ ごと消して値を入れること -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "@id": "https://［自社ドメイン］/shop/oita/#localbusiness",
  "name": "［サンプル整体院 大分駅前店］",
  "url": "https://［自社ドメイン］/shop/oita/",
  "image": "https://［自社ドメイン］/img/oita-exterior.jpg",
  "telephone": "［097-000-0000］",
  "priceRange": "［4000円〜8000円］",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "［中央町1-2-3 サンプルビル2F］",
    "addressLocality": "［大分市］",
    "addressRegion": "［大分県］",
    "postalCode": "［870-0000］",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": ［33.2396］,
    "longitude": ［131.6094］
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "sameAs": [
    "https://www.instagram.com/［自社アカウント］/"
  ]
}
</script>

差し替えるときのつまずきポイントを補足します。

• 緯度・経度：取得方法はGoogle マップ ヘルプ「場所の緯度と経度を取得する」で確認してください。［　］を消して数字だけを書きます。schema.orgのGeoCoordinatesでは latitude・longitude の値としてNumberまたはTextが定義されているので、迷ったら数値のまま書くのが無難です
• @id：そのページ固有の文字列にします。多拠点でここを使い回すと、全店が同一の存在として宣言されます
• 定休日：営業する曜日だけを dayOfWeek に並べます。休みの曜日を書く必要はありません
• 昼休みがある場合：openingHoursSpecification のブロックを2つ並べます（午前の枠と午後の枠）
• sameAs：自社が運営しているアカウントのURLだけを書きます。ポータルサイトの掲載ページや、他社が作ったまとめページは入れません

@typeは業種に合わせて具体的にする

LocalBusiness のままでも動きますが、schema.orgのLocalBusinessには業種ごとの下位タイプが用意されています。たとえば次のとおりです。

• 美容室：HairSalon
• 歯科：Dentist
• 飲食店：Restaurant

該当するものがあれば具体的なタイプを使い、なければ LocalBusiness のままで問題ありません。下位タイプの一覧はschema.orgのLocalBusinessのページで確認できます。

どのプロパティが必須で、どれが推奨かはGoogle側の扱いが更新されることがあるので、書く前にGoogle 検索セントラルのローカル ビジネス（LocalBusiness）の構造化データで現行のマークアップ例と実装方法を確認してください。

公開前に必ずやる検証の3手順

JSON-LDは、1文字のカンマ抜けで丸ごと無効になります。公開したら必ず次の順で確認してください。

1. Google のリッチリザルト テストにページURLを入れて、構文エラーと警告が出ていないか見る
2. 読み取られた住所・電話番号・営業時間を、Googleビジネスプロフィールの管理画面と並べて目視で突き合わせる
3. そのページを実際にブラウザで開き、画面に表示されている住所・電話番号・営業時間が、JSON-LDに書いた内容と一致しているか確認する

3つ目を軽く見ないでください。Google 検索上の構造化データ ガイドラインでは、構造化データに関する一般的な決まりごとが示されており、ページの内容と食い違う情報を構造化データだけに書くやり方は認められていません。 「サイトには載せていない番号を構造化データにだけ書く」といった使い方は避けてください。

検証ツールが見てくれる範囲は限られています。ツールが判定するのは書式が正しいかどうかで、住所そのものが合っているかは判定しません。「エラー0件」は「正しい情報が入っている」という意味ではないので、内容の突き合わせは人の目でやってください。

この章の結論です。JSON-LDは書式より内容の一致が本体です。エラーが消えた時点で終わりにせず、画面表示・GBP・構造化データの3つを並べて見る手順まで含めて1セットだと考えてください。

Googleマップの上位表示にSEOは効くのか。サイト側が担いでいるもの

Googleマップの上位表示とサイトのSEOは、別物ですが無関係でもありません。Google ビジネス プロフィール ヘルプ「Google のローカル検索結果でのビジネスの掲載順位を改善する」では、ローカル検索結果の順位が主に関連性・距離・知名度の組み合わせで決まると説明されています。 このうちサイト側が関われるのは、関連性と知名度の部分です。

距離は動かせません。店舗の場所と検索した人の位置で決まるからです。だから「NAPを揃えれば距離のハンデが消える」ということはありません。ここは正直にお伝えしておきます。

一方で、関連性は「そのお店が、その検索語に対してどれだけ合っているか」の話なので、サイト側で扱う余地があります。何のサービスをいくらで、どのエリアで提供しているのかがテキストで書かれているページと、写真とキャッチコピーだけのページでは、機械が読み取れる情報量が違います。

NAP統一と構造化データで、実際に何が変わるのか

期待していい変化は、順位が何位上がるという形では出てきません。次のような、地味だけれど取りこぼしに直結する部分で効いてきます。

• 誤情報の連鎖が止まる：ポータルサイトに残った旧電話番号が別の媒体に転載され続ける、という流れが断ち切れる
• 移転・改称のときの復旧が速い：媒体一覧があるので、どこを直せばいいかを探すところから始めずに済む。一覧がないと、発見漏れを潰す作業が後々まで残る
• 営業時間の問い合わせが減る：ページ表示・構造化データ・GBPが揃っていれば、「今日やってますか」の確認電話が減る
• AI検索で拾われる情報がぶれない：生成AIが複数の情報源を突き合わせたとき、食い違いが少ないほど扱いやすい情報になる

AI検索を意識した店舗情報の整え方はAI検索に拾わせるGBP整備チェックリストと手順で別途扱っています。この記事のNAP統一は、その前提部分にあたります。

成果を数字で確かめるなら、順位より行動を見る

効果測定を順位だけでやると、判断を誤ります。地図検索の順位は検索した人の現在地で変わるため、自分のスマホで見た順位はあくまで「その場所での順位」でしかないからです。

見るべきなのは、Googleビジネスプロフィールのパフォーマンス画面で見られる指標と、サイト側のアクセス解析の突き合わせです。Google ビジネス プロフィール ヘルプ「ビジネス プロフィールのパフォーマンスを確認する」で、どの指標が確認できるかと画面上の表示名を確かめてください。ウェブサイトへのアクセスや通話、ルート検索にあたる項目を、NAPを直した月と翌月で並べておくと、施策の効きが判断できます。

GBPからサイトへの流入を分けて数えたい場合は、リンクにパラメータを付ける方法があります。手順はMEOの効果をGA4で計測する方法｜UTMパラメータ設定手順にまとめています。順位そのものを継続的に測りたい場合はMEO順位を自分で確認する手順｜無料の測り方とツール選びの観点を参照してください。

この章の結論です。サイト側の整備は順位を直接動かす施策ではなく、関連性と情報の一貫性を底上げする土台づくりです。成果は順位ではなく、サイトへのアクセスや通話、ルート検索の動きで判断してください。

よくある失敗5パターンと、その防ぎ方

NAPと構造化データの整備でつまずく場所は、だいたい決まっています。現場で実際によく見かける順に並べます。

失敗1. 広告用のコールトラッキング番号をサイトに載せてしまう

広告の効果測定のために、サイトの電話番号だけ転送用の番号に差し替えているケースがあります。Googleビジネスプロフィールには実際の店舗番号、サイトには転送番号、という状態です。

こうなると、NAPの「P」がGBPとサイトで一致しません。しかも構造化データにも転送番号を書いてしまうと、機械可読な形で食い違いを宣言することになります。Google 検索上の構造化データ ガイドラインでは、構造化データはページを訪れた人に見える内容を表すものとされており、ページに表示していない情報を構造化データにだけ書くやり方は認められていません。

防ぎ方は、構造化データの telephone とページに大きく表示する番号を必ず同じ番号にしておき、計測は電話番号の差し替えではなく、リンクのクリック計測やパラメータで行うことです。どうしても番号を分けたい事情があるなら、その番号を載せるページを広告のランディングページだけに限定し、店舗ページとフッターには持ち込まないでください。

失敗2. 住所と電話番号が画像になっている

デザイン重視で作られたサイトほど、フッターの店舗情報が1枚のバナー画像になっていることがあります。人間には読めますが、機械が読み取れるテキストとしては存在していません。

解決は、住所と電話番号をテキストで置くことです。デザインを崩したくない場合でも、画像の上にテキストを重ねるか、画像とは別にテキストのNAPブロックをフッターに1つ置いてください。alt属性は画像の内容を説明するためのものなので、NAPの掲載場所としては使わず、本文のテキストとして書いてください。

失敗3. 年末年始に、営業時間が3か所でバラバラになる

営業時間はサイト表示・構造化データ・Googleビジネスプロフィールの3か所に存在します。臨時休業や年末年始のとき、GBPだけ直してサイトと構造化データが通常営業のまま、という状態が毎年発生します。

結果として、Googleマップでは休みと出ているのにサイトでは営業中、という食い違いが起きます。ユーザーは判断できず、確認の電話が増えます。

防ぎ方は運用側にあります。年末年始・お盆・GWの3回だけでいいので、「GBP・サイトの表示・構造化データの3か所を直す」というチェック項目をカレンダーに入れておいてください。

失敗4. 多拠点でJSON-LDを丸ごとコピーして、@idとURLが全店同じ

2店舗目以降を作るとき、1店舗目のJSON-LDをコピーして住所だけ書き換える、という進め方をしがちです。このとき @id と url の書き換えを忘れると、全店が同じ識別子を名乗ることになります。

住所は違うのに識別子は同じ、という状態は、機械から見ると矛盾です。防ぎ方は単純で、店舗ページを追加したら次の7項目を1つずつ確認することです。

1. @id（コピー後、必ずここから先に書き換える）
2. url
3. name
4. image
5. 住所（address の各項目）
6. 電話番号（telephone）
7. 緯度・経度（geo）

順番を固定して上から潰していけば漏れません。

失敗5. GBPのウェブサイト欄がトップページのまま

店舗ごとの詳細ページを作ったのに、Googleビジネスプロフィールのウェブサイト欄が会社のトップページのまま、というのもよくあります。せっかくNAPを揃えた店舗ページに人が着地しません。

多拠点なら、各拠点のGBPのウェブサイト欄には、その拠点の店舗ページのURLを入れてください。設定の考え方はGBPに公式サイトを設定｜指名検索で自社に流入で解説しています。

この章の結論です。失敗の大半は、書き方の間違いではなく「直す場所が3か所以上ある」ことに起因します。営業時間と電話番号は複数箇所に散らばっている前提で、更新のたびに全部を回るチェックリストを持ってください。

構造化データを入れる前に知っておきたい、現場での限界

ここは教科書には書かれない部分です。NAP統一と構造化データは効果の割に安く済む施策ですが、実際にやろうとすると、技術以外のところで止まります。

CMSのテンプレートが、拠点ごとの住所を持てない

よくあるのが、テーマの設定画面に「住所」の入力欄が1つしかなく、全ページのフッターに同じ住所が出る作りになっているパターンです。この状態で店舗ページを増やしても、フッターには本社住所が出続けます。

解決には、店舗ごとのカスタム投稿タイプやカスタムフィールドを用意して、テンプレートから呼び出す改修が必要になります。ページを1枚足すのとはコストの桁が変わるので、拠点を今後増やす予定があるなら、この改修を先に見積もっておいてください。改修せずに店舗ページを増やすと、あとで全ページを作り直すことになります。

プラグイン任せにせず、実際の出力を自分の目で見る

構造化データの出力をプラグインに任せている場合でも、何が出力されているかは必ず自分で確認してください。確認方法は、自分の店舗ページのソースを開いて application/ld+json で検索し、実際に出力されている内容を読むことです。名前とURLしか入っていないなら、住所・電話番号・営業時間を足す余地があります。

もう1つ気をつけたいのが二重出力です。プラグインが出力しているところに手書きのJSON-LDを足すと、同じページに内容の違うローカルビジネス情報が2つ並びます。どちらか片方に寄せるか、同じ @id を使って同一の存在だと示したうえで内容を一致させてください。

「誰が直すか」が決まっていないと、必ずまた崩れる

一番の落とし穴はここです。サイトは制作会社、Googleビジネスプロフィールは店長、ポータルサイトは本部の販促担当、というように担当が分かれている会社では、電話番号が変わったときに全員が「誰かがやっているはず」と思います。

整えた直後は完璧でも、半年後にまた食い違っています。防ぎ方は、媒体一覧のスプレッドシートに「担当者」の列を1つ足して、名前を書くことだけです。仕組みとしては拍子抜けするほど単純ですが、これがないと同じ作業を毎年やることになります。

構造化データの見積もりが高いと感じたときの判断

制作会社に依頼すると、構造化データの実装が別項目の見積もりで出てくることがあります。1拠点なら自社でやれる範囲なので、この記事の雛形を使って自分で入れてしまうのも十分ありです。

逆に、次のような条件が重なるなら、テンプレート側から自動出力する作りにしたほうが結果的に安く済みます。

• 拠点数が多い：手で貼るページ数がそのまま作業量になる
• CMSの改修が必要：どのみちテンプレートを触るので、同時にやったほうが安い
• 営業時間が拠点ごとに違う：更新のたびに全ページを個別に直すことになる

1ページずつ手で貼る方式は、拠点が増えるほど更新漏れのリスクが積み上がります。何拠点から自動出力に切り替えるべきかは、更新の頻度や社内の運用体制で変わるので、一律の目安はありません。

なお、構造化データの導入を「順位保証」とセットで提案してくる業者には注意してください。Googleは構造化データで地図検索の順位が上がるとは公表していないので、その提案は根拠のない約束になります。

AIについても一言だけ触れておきます。表記ゆれの洗い出しやJSON-LDの雛形づくりはAIに任せて構いませんが、正解のNAPを決めることと、公開後にGBPと突き合わせる作業は人がやってください。AIは渡された情報の中でしか整合を取れないためです。

この章の結論です。技術的な難所は構造化データの書き方ではなく、CMSの作りと更新担当の決め方にあります。拠点を増やす予定があるなら、手作業で貼る前にテンプレート側の設計を相談したほうが安上がりです。

よくある質問

今日やる最初の1つ

まずは自社サイトのフッターと、Googleビジネスプロフィールの管理画面を並べて開き、住所と電話番号を1字ずつ見比べてください。ずれが見つかったら、この記事のステップ1に戻って媒体の棚卸しから始めましょう。順位そのものの測り方が気になった方はMEO順位を自分で確認する手順｜無料の測り方とツール選びの観点もあわせてどうぞ。

ここまで読んで、拠点が複数ある・CMSの作り替えが必要そう・そもそも媒体を全部洗い出せる気がしない、と感じた方は、一度状況を聞かせてください。コレットラボのMEO対策支援では、店舗情報の統一からサイト側の整備、公開後の運用まで伴走しています。今の状態を整理するだけの相談でも大丈夫です。MEO対策の詳細はこちらからお気軽にどうぞ。