Keyword Mapping: Assign One Keyword to One Page

Keyword mapping is the unglamorous spreadsheet discipline that prevents SEO's most self-inflicted wound: two of your own pages fighting for the same query. The rule is one line long — every target keyword-group gets exactly one URL, recorded before content gets written — and the map that enforces it becomes the operating document for your whole content programme. Here's how to build one, maintain it, and use it to catch problems before they cost rankings.

What a keyword map is

A living table with one row per URL (existing and planned), holding: the URL, its primary keyword-group, the intent type, secondary variants the page also owns, its cluster/pillar assignment, status (live/planned/needs-refresh), and current ranking. That's the whole artefact — a sheet, not software — and it answers the two questions that govern every content decision: "do we already have a page for this?" and "which page should this new keyword belong to?"

Building the map

1. Inventory what exists

Export your URLs (crawl or sitemap) and, from Search Console, the queries each already ranks or gets impressions for. Every live URL gets a row and — critically — a declared primary keyword, even if that means admitting a page currently has none (those rows become your refresh or prune list).

2. Assign the research output

Take the grouped keyword-list from the research process and match groups to rows: existing page already covers it → assign and note gaps; no page → create a planned row with its future URL (yes, decide the slug now — it's free today and expensive later). The grouping rule carries over unchanged: keywords whose SERPs overlap belong to one row; distinct SERPs, distinct rows.

3. Arrange rows into clusters

Sort the map by topic and the pillar-cluster structure appears by itself: head-term rows are pillars, subtopic rows are their clusters, and the map's cluster column becomes the internal linking plan — every row knows its UP link and its siblings. (This site's content calendar is exactly this map with dates attached: ID, slug, primary keyword, link plan, one row per article, written before any article existed.)

Using the map day-to-day

• Before any new content: check the map. Keyword already owned → improve that page instead of writing a rival. Not owned → new row, assigned before drafting. This single habit prevents nearly all cannibalization — the disease this whole discipline exists to prevent.
• At every refresh: the row states the page's job; refresh against that ("does this page fully own its group?") rather than vague improvement instincts.
• In reporting: the map joined to rank tracking becomes the coverage dashboard — which groups are won, contested, unstarted — feeding the monthly report's pipeline block.
• In quarterly research cycles: new keywords from the cycle land as map assignments first; content decisions second. The map is the interface between research and production.

Map hygiene rules

1. One owner per group, no exceptions — when two pages both plausibly claim a keyword, the map forces the choice: consolidate, differentiate, or prune. Ambiguity in the sheet becomes ambiguity in the SERP.
2. Primary keywords are commitments, not wishes — a row whose page has ranked nowhere for its keyword in a year triggers the difficulty re-check from the audit: wrong keyword, wrong page, or missing links — the map surfaces the question on schedule.
3. Secondaries live under their primary — variants and long-tails satisfied by the same page get listed on its row, so nobody "discovers" them later and writes duplicates. The section-vs-page rule is executed here.
4. Deletions get map entries too — pruned or merged pages keep a row noting the redirect target, so history stays legible and equity paths stay documented.

Frequently asked questions

What tool should the map live in?

A spreadsheet, genuinely — the value is the discipline, not the software. Teams past ~500 URLs graduate to Airtable-class databases for filtering; the columns stay identical.

How is keyword mapping different from a content calendar?

The map is the territory (every keyword-group and its owner); the calendar is the schedule (which planned rows get built when). This site runs both as one sheet — rows with dates — which is the natural end state.

We have 300 blog posts and no map. Where do we start?

Inventory + Search Console assignment first (a day's work), which immediately exposes the duplicate-owner clusters — then fix those via the cannibalization playbook before mapping anything new. It's the audit that pays for itself fastest; we build these maps as engagement groundwork, with the link supply attached to the rows that need it.