複数店舗の地域ページ競合を監査する方法｜市区町村ページ・店舗ページのローカルSEOカニバリを判定

監修: 菊地 将（リブランディング株式会社）

複数店舗サイトでは、すでに作成済みの店舗ページ、市区町村ページ、駅・地区ページ、サービス×地域ページが、同じ地域検索で競合することがあります。

本記事が扱うのは、一般的なSEOカニバリの見つけ方そのものでも、地域ページの新規設計方法でもありません。公開済みの地域ページ群について、地理的にどのページがその検索を担当すべきかを監査する方法に限定します。

Search Consoleは競合候補を見つける入口として使います。最終判断では、地域の包含関係、実店舗の所在地、実来店・対応商圏、確認地点ごとのSERP、最終送客先を重ねます。

一般的な「クエリ重複・URL入替・SERP・回答範囲」の監査手順や、canonical・301など技術処置の一般論は「SEOカニバリを監査する方法」へ委譲します。店舗ページをどう作り分けるかは、既存の「複数店舗の地域ページSEO・MEO設計」が担当範囲です。

このページでは、地域一般クエリ・店舗指名・駅/地区・サービス×地域の4種類について、どのURLを『所有ページ』にするかを決めるところまでを扱います。

地域ページのカニバリは「複数URLが出た」だけでは判断しない

地域ページのローカルSEOカニバリとは、同一サイト内にある複数の店舗ページ・地域ページが、実質的に同じ地域検索の意図を担当している状態です。

地域ページ・店舗ページの役割設計やNAP・サイテーションを含む全体像は、ローカル検索対策の全体像で確認できます。

たとえば、

• 「新宿 整体」を狙う新宿区ページ
• 新宿店の店舗ページ
• 東京都の整体ページ

が同時に存在していても、それだけで問題とは限りません。

東京都ページが「東京都内の店舗を比較したい人」、新宿店ページが「新宿店の場所や営業時間を知りたい人」、新宿区ページが「新宿区で利用できるサービスを調べたい人」に答えているなら、ページの役割を分けられます。

一方、3ページとも「新宿で整体を探している人」にほぼ同じ説明を行い、最終的に同じ店舗へ送客しているなら、競合している可能性が高くなります。

Google Search Consoleではクエリやページ単位で検索パフォーマンスを確認できます。ただし、一部のクエリは匿名化され、表示データにも制限があります。また、ページ別データの多くはGoogleが選択した正規URLへ集約されます。そのため、Search Consoleだけでカニバリの有無を断定するのではなく、他の情報と組み合わせて判断します。

地域ページでは、次の5項目をセットで確認するのが実務的です。

同じ地域クエリで複数URLが表示されても、それだけではカニバリとは断定せず、5つの条件を重ねて判断します。

STEP1｜店舗ページ・地域ページのURLをすべて洗い出す

最初に、監査対象となる地域系URLを一覧化します。

地域ページのカニバリ監査では、Search Consoleだけで判断せず、URL整理から地域・店舗情報、SERPまで順番に確認します。

検索順位が下がったページだけを見るのではなく、地域検索を担当しているURLを横断して確認することが重要です。

最低限、次の種類に分類します。

ここで重要なのは、「地域名が入っているか」ではなく、各URLが何を担当しているかを整理することです。

Googleは、似た検索クエリで順位を獲得するために地域・都市別の類似ページを大量に作り、最終的に同じ場所へ誘導するような構造を「doorway abuse」の例として挙げています。地名だけを差し替えたページが大量にある場合は、カニバリだけでなく、ページ群そのものの存在意義を確認する必要があります。

STEP2｜Search Consoleでは「地域クエリでURLが入れ替わる箇所」だけを見る

Search Consoleは、地域ページ同士が競合している可能性のある組み合わせを見つけるために使います。一般的な操作手順をここで再説明するのではなく、監査では次の読み方に絞ります。

• 重要な地域クエリに複数URLが出ているか
• 期間を変えたとき、主に表示されるURLが入れ替わっていないか
• 本来その地域を担当させたいURLではないページが継続的に出ていないか
• 店舗ページと市区町村ページが同じ地域一般クエリで交互に出ていないか

たとえば「新宿 整体」で、4月は/service/shinjuku/、5月は/shops/shinjuku/、6月は再び/service/shinjuku/が主に表示されるなら、2URLを優先監査します。

ただし、Search Consoleでは匿名化クエリやデータ行の制限があり、多くのページデータはGoogleが選択した正規URLへ集約されます。したがって、URL入替はカニバリ確定ではなく、地理的役割を確認するための発見シグナルとして扱います。

地域包含×店舗実体×商圏で「所有ページ」を決める

ローカルSEOのカニバリ監査で中心になるのは、キーワードの似方ではなく、その地域検索をどのURLが代表するべきかです。本記事では、その代表URLを「所有ページ」と呼びます。

所有ページは、次の3条件を重ねて決めます。

1. 地域包含：都道府県、市区町村、駅・地区のどの範囲を検索しているか
2. 店舗実体：その地域に実在する店舗・拠点があるか
3. 商圏：実際に来店・訪問・提供できる範囲と一致しているか

重要なのは、URL名に地名が入っているかではありません。検索者が指定した地域の広さと、実店舗・商圏の事実が一致するURLを優先することです。

地理階層と実店舗実体が矛盾する場合

地理階層だけでは所有ページを決められないケースがあります。

たとえば、東京都ページ→新宿区ページ→西新宿ページというきれいな階層があっても、西新宿に店舗がなく、実際の送客先が新宿店1店舗だけなら、3ページを独立させる実体的な理由があるかを確認します。

逆に、同じ新宿区内に実在店舗が2店舗あり、来店圏・設備・営業時間・提供サービスが違うなら、「新宿区」という1つの地理単位だけで店舗ページを統合するべきではありません。

監査では各URLについて、少なくとも次を記録します。

• ページが代表する行政区・駅・地区
• 実在店舗の所在地
• 来店・訪問・配送などの実商圏
• サービス提供条件
• 案内する店舗・拠点
• 予約・問い合わせ先

Googleビジネスプロフィールでも、拠点ごとにその拠点を表すWebサイトや電話番号を使う考え方が示されています。サービス提供地域も、実際に提供できる範囲を正確に設定する必要があります。

STEP3｜地理階層と実店舗実体の衝突を洗い出す

次に、所有ページ候補を並べ、地理階層と店舗実体が矛盾している組み合わせを優先監査します。

特に、地域ページに店舗実体がなく、より広い地域ページと同じ説明をし、同じ店舗へ送客する状態は優先監査対象です。

一方、店舗ページは実店舗が異なるだけで独立価値を持ちやすいため、単に同じ「新宿 整体」で表示されたという理由では統合しません。

STEP4｜確認地点を固定してローカルSERP上の店舗ページ/地域ページの役割を判定する

ローカル検索では確認地点によって検索結果が変わるため、SERP比較は同じ地点条件で行います。地点を固定しないまま結果を見比べると、「ページの役割が変わった」のか「検索地点が変わった」のかを区別できません。

監査記録には最低限、次を残します。

• 検索クエリ
• 確認日
• 確認地点または確認地域
• デバイス条件
• オーガニック検索結果で表示された自社URL
• ローカル結果に出た自社店舗

ここで見るのは順位そのものより、同じ地点・同じクエリで、店舗ページと地域ページのどちらがどの役割を担っているかです。

たとえば、同じ新宿区内の確認地点で「新宿 整体」は市区町村ページ、「○○整体 新宿店」は店舗ページが安定して表示されるなら、役割分離は成立しやすい状態です。

反対に「新宿 整体」で市区町村ページと店舗ページが交互に入れ替わり、どちらも同じ新宿店へ同じ説明で送客しているなら、所有ページを1つに固定する必要性が高まります。

地点別順位の計測設計そのものは、兄弟記事のMEO順位計測記事に委譲し、本記事ではカニバリ判定に必要な固定地点比較だけを扱います。

クエリ種類ごとに「所有ページ」を固定する

同じ地域名を含む検索でも、検索者が求めるページは同じではありません。地域ページ群を監査するときは、クエリを少なくとも次の4種類に分け、所有ページを決めます。

地域一般クエリ

地域一般クエリは、最もカニバリが起きやすい領域です。市区町村ページと店舗ページのどちらを所有ページにするかは、検索者が「地域内から選びたい」のか「実店舗へ行きたい」のか、サイト側が何を提供できるかで決めます。

店舗指名

店舗指名は、原則として実在店舗ページの役割です。市区町村ページが店舗指名まで取り込む構成になっているなら、タイトル・見出し・内部リンク・CTAを店舗ページ側へ寄せます。

駅/地区

駅・地区ページは、地名を細分化しただけでは所有ページにしません。最寄り店舗、徒歩導線、対応条件、地区固有の実績など、検索者の判断材料が独立している場合に限り残す理由があります。

サービス×地域

サービス×地域ページは、一般地域ページと同じサービス説明を複製するだけでは役割分離できません。その地域での提供店舗、対象条件、料金、予約導線などが異なるかを確認します。

STEP5｜5つの判定軸でカニバリか役割分担かを決める

地域ページの判定では、次の5軸を使います。

1. 検索意図が同じか

2ページが同じ検索クエリで表示されていても、ユーザーへの回答が違えば維持できます。

反対に、タイトルだけ違って本文・CTA・対象サービスがほぼ同じなら、役割が重なっている可能性があります。

2. 地域範囲が同じか

東京都ページと新宿区ページは包含関係にあります。

親ページを「比較・一覧」、子ページを「地域詳細」にすれば分離しやすくなります。

一方、「新宿区」と「新宿エリア」という別URLが実質同じ地域を対象にしているなら、統合候補です。

3. 実店舗が異なるか

新宿店と渋谷店のように実在する店舗が異なる場合、同じブランド・サービスであってもユーザーが必要とする住所、営業時間、アクセス、設備などは異なります。

GoogleのLocalBusiness構造化データでも、各ローカルビジネス拠点を個別に定義する考え方が示されています。

したがって、複数店舗ページが存在すること自体を理由に統合する必要はありません。

4. 提供サービスと来店・対応条件が異なるか

同じ市内でも、

• サービスA対応店
• サービスB専門店
• 来店型店舗
• 訪問対応拠点

など条件が違えば、別ページとして成立しやすくなります。

5. 最終的な送客先が同じか

地域名だけを変えた複数ページが、すべて同じ内容で同じ店舗・同じ問い合わせフォームへ送客している場合は注意が必要です。

特に、地域ページごとに固有の判断材料がなく、検索流入を取ることだけが目的になっている場合は統合を検討します。

地域ページの処置は「維持・役割分離・統合」を中心に決める

地域固有の判定が終わったら、URLごとに処置を決めます。本記事では、技術処置の一般論ではなく、地域役割の判定に絞ります。

301、canonical、noindexの一般定義や実装手順は本記事では扱いません。地域・店舗・商圏の監査で「統合すべき」「技術重複である」「検索対象外である」と判断した後の実装は、汎用のSEOカニバリ監査へ引き継ぎます。

代表的な4ケースで所有ページと処置を判断する

ケース1｜東京都ページと新宿区ページが同じクエリで表示される

「東京都 整体」の所有ページを東京都ハブ、「新宿 整体」の所有ページを新宿区ページと定義でき、各ページの比較範囲も異なるなら維持できます。

一方、新宿区ページも東京都ページも新宿店1店舗だけを同じ説明で案内しているなら、地理階層だけを理由に2ページを残さず、どちらが地域一般クエリを所有するかを見直します。

ケース2｜同じ市内に実店舗が2店舗ある

2店舗が実在し、住所・営業時間・アクセス・設備・商圏が異なるなら、店舗ページは分けます。

そのうえで「○○市 整体」の地域一般クエリは、市内店舗を比較できる地域ハブに持たせるのか、代表店舗ページに持たせるのかを別途決めます。店舗ページを統合する問題と、地域一般クエリの所有ページを決める問題を混同しません。

ケース3｜実店舗ページと対応エリアページが競合する

「新宿店」と「新宿区対応」が同じ新宿店、同じサービス、同じ予約先を案内している場合、まず新宿区対応ページに独立した地域価値があるかを確認します。

地域内の複数店舗比較、訪問対応条件、地区別の実績などがなければ、地域一般クエリを店舗ページに寄せるか、市区町村ページへ役割を集約する候補です。

ケース4｜地名だけ違う市区町村ページが大量にある

店舗実体、商圏、サービス条件、事例などの差がなく、地名だけを置き換えて同じ店舗へ送客している場合は、ページ群全体の必要性を見直します。

Googleのスパムポリシーでは、地域・都市向けの類似ページを多数作り、最終的に同じ場所へ誘導する構造がdoorway abuseの例として示されています。地域ハブや実店舗ページに集約した方がユーザーの選択に役立つ場合があります。

地域ページのカニバリ監査で優先度を付ける方法

すべてのページを一度に修正する必要はありません。

実務では、次の順番で対応すると整理しやすくなります。

優先度A

• 重要な地域クエリで複数URLが継続的に表示される
• 表示URLが期間ごとに入れ替わる
• 対象地域が同じ
• サービスが同じ
• 送客店舗が同じ
• コンテンツの役割もほぼ同じ

統合または役割分離を優先します。

優先度B

複数URLが表示されるものの、店舗や検索意図に一定の差があるケースです。

タイトル、H1、内部リンク、ページ冒頭、CTAなどを確認し、ページの役割を強めます。

優先度C

対象地域や店舗が明確に異なり、複数URLが出てもユーザーの選択に役立っているケースです。

基本的には維持し、経過を確認します。

修正後は「所有クエリとURLの対応」が安定したか再監査する

修正後は、重要な地域クエリごとに、意図した所有ページが選ばれる状態へ近づいたかを確認します。

• 地域一般クエリで表示されるURL
• 店舗指名で表示されるURL
• 駅/地区クエリで表示されるURL
• サービス×地域で表示されるURL
• 同一条件でのURL入替が減ったか
• 問い合わせ・予約先がページ役割と一致しているか

短期間の順位上下だけで修正を戻さず、同じ確認地点・同じクエリ条件でURLの役割が安定したかを見ます。技術的な正規URLやインデックス処置の再確認が必要なケースは、汎用SEOカニバリ監査の工程へ送ります。

地域ページのローカルSEOカニバリ監査チェックリスト

URL・地域

• 地域系URLをすべて一覧化した
• 店舗ページと市区町村・駅/地区・サービス×地域ページを区別した
• 都道府県→市区町村→駅/地区の包含関係を整理した
• 各ページの想定所有クエリを記録した

店舗実体・商圏

• 実在店舗の所在地を確認した
• 来店・訪問・配送など実際の商圏を整理した
• ページが案内する店舗・予約先を確認した
• 地理階層と店舗実体が矛盾するページを抽出した

Search Console・SERP

• 地域クエリでURL入替がある箇所を抽出した
• 地点条件を固定してSERPを比較した
• 地域一般、店舗指名、駅/地区、サービス×地域で表示URLを分けて確認した
• 複数URL表示だけを理由にカニバリと断定していない

所有ページ

• 地域一般クエリの所有ページを決めた
• 店舗指名の所有ページを店舗ページに固定できている
• 駅/地区ページに独立した存在理由がある
• サービス×地域ページに地域固有の提供条件がある

処置

• 維持するURLを決めた
• 役割分離するURLを決めた
• 統合候補を決めた
• 技術的正規化が必要なケースを汎用SEO監査へ送った
• 内部リンクとCTAが所有ページの役割を補強している

まとめ

複数店舗の地域ページで起きるローカルSEOカニバリは、一般的な「同じクエリに複数URLが出た」という見方だけでは判定できません。

本記事で中心になるのは、地域包含×店舗実体×商圏から、地域検索ごとの「所有ページ」を決めることです。

監査では、

1. 地域系URLを棚卸しする
2. Search Consoleで地域クエリのURL入替を見つける
3. 地域包含・店舗実体・商圏から所有ページ候補を決める
4. 確認地点を固定してローカルSERP上の役割を確認する
5. 地域一般・店舗指名・駅/地区・サービス×地域ごとに所有ページを固定する
6. 維持・役割分離・統合を判断する

という順で進めます。

特に重要なのは、地理階層がきれいに分かれていても、実店舗がなく、商圏も同じで、同じ店舗へ同じ説明で送客するだけなら独立ページの根拠は弱いという点です。

反対に、実店舗・商圏・検索意図が明確に異なる店舗ページまで機械的に統合すると、ユーザーが必要な店舗情報を失います。

一般的なSearch Console操作、canonical、301、noindexなどの技術処置は汎用SEOカニバリ監査へ、地域ページを新しくどう設計するかは複数店舗の地域ページ設計記事へ委譲し、本記事は作成済み地域ページ群の地理的役割衝突の判定に集中します。

参考文献・データ元

‹ 親記事: ローカル検索対策の全体像｜NAP・サイテーション・地域ページ・被リンク・複数店舗管理まで