Sign in Start free

Multi-location cannibalisation

Multiple locations competing for overlapping geography produce a specific failure: search engines cannot decide which page serves which area, so the selection flips. This is an internal signalling problem rather than a content quality one, and it is fixed by making the mapping explicit.

CATEGORY
Local SEO
FORMAT
multi-location-cannibalisation.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when a business with several branches finds the wrong branch page ranking for a town, or branches trading places in results without any change being made.

The skill file

multi-location-cannibalisation.md 
---
name: multi-location-cannibalisation
description: Use when a business with several branches finds the wrong branch page ranking for a town, or branches trading places in results without any change being made.
---

# Multi-location cannibalisation

Multiple locations competing for overlapping geography produce a specific failure: search engines cannot decide which page serves which area, so the selection flips. This is an internal signalling problem rather than a content quality one, and it is fixed by making the mapping explicit.

## What you need first

- A list of locations with their true catchment areas
- Ranking data per location page for its target town
- Internal link map and the current URL structure

## Method

1. Map each target town to exactly one location page and record the intended pairing before looking at any data.
2. Compare intended pairing against observed rankings and list every town where a different page appears - flapping between two pages is the signature of cannibalisation, not of a poor page.
3. Check overlapping service areas on the profiles, since two branches claiming the same radius force the ambiguity you are trying to remove.
4. Fix internal linking so each town term links to one page only, and remove the cross-links between branch pages that make them look interchangeable.
5. Differentiate the on-page targeting: distinct title tags, distinct headings, and no shared list of every town on every branch page.
6. Re-measure over at least 30 days and treat stability of the pairing, not raw position, as the success measure.

## What this produces

A one-to-one town-to-page mapping with the internal linking and service area changes made to enforce it, plus a stability measure over 30 days.

## Where this goes wrong

- Adding more content to the losing page, which raises the noise instead of resolving the ambiguity
- Letting every branch page list every town served, which guarantees the pages compete
- Canonicalising one branch page to another and removing a page that had genuine local demand

---

From the QuQi skill library - https://www.quqi.io/skills/multi-location-cannibalisation
Free to download · no account, no email

What you need first

  • A list of locations with their true catchment areas
  • Ranking data per location page for its target town
  • Internal link map and the current URL structure

Method

  1. 01 Map each target town to exactly one location page and record the intended pairing before looking at any data.
  2. 02 Compare intended pairing against observed rankings and list every town where a different page appears - flapping between two pages is the signature of cannibalisation, not of a poor page.
  3. 03 Check overlapping service areas on the profiles, since two branches claiming the same radius force the ambiguity you are trying to remove.
  4. 04 Fix internal linking so each town term links to one page only, and remove the cross-links between branch pages that make them look interchangeable.
  5. 05 Differentiate the on-page targeting: distinct title tags, distinct headings, and no shared list of every town on every branch page.
  6. 06 Re-measure over at least 30 days and treat stability of the pairing, not raw position, as the success measure.

What this produces

A one-to-one town-to-page mapping with the internal linking and service area changes made to enforce it, plus a stability measure over 30 days.

Where this goes wrong

  • Adding more content to the losing page, which raises the noise instead of resolving the ambiguity
  • Letting every branch page list every town served, which guarantees the pages compete
  • Canonicalising one branch page to another and removing a page that had genuine local demand

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/multi-location-cannibalisation/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When is this the right diagnosis rather than a content quality problem?

When the branch ranking for a town keeps changing and nobody has edited anything. Flapping between two of your own pages is a selection problem, not a quality one, and adding content to the page that keeps losing makes the two more alike. A page holding a steady but low position is an ordinary ranking problem and this method does not apply.

What do I need in hand before starting?

The locations with their true catchment areas, ranking data per location page for its target town, and the internal link map. Record the intended town-to-page pairing before looking at any data, or you will rationalise whatever currently ranks as correct. You also need the service areas set on each profile, since two branches claiming the same radius create the ambiguity.

What do I end up with, and which part of it gets used?

A one-to-one mapping of town to page, the internal linking and service area changes that enforce it, and a stability measure over at least 30 days. Stability is the success measure, not position. A page sitting at six every week has resolved the problem; one alternating between four and eleven with another branch has not.

What ruins this most often?

Letting every branch page list every town served, usually because sales wants it there. That single block guarantees the pages compete. The expensive mistake is canonicalising one branch page to another to stop the flapping, which removes a page serving real local demand and hands those queries to a competitor rather than to your surviving branch.

More in Local SEO

Google Business Profile optimization

Use when a business is visible on its own site but absent or weak in the map pack, and the profi...

NAP consistency audit

Use when a business has moved, rebranded, changed phone numbers, or has been listed by third par...

Local landing pages that are not doorway pages

Use when a business serves multiple towns and needs a page per location, without producing the t...

Review acquisition and response

Use when review volume is stagnant, ratings are dropping, or reviews arrive in bursts that look...