Topical Maps
Two queries that return the same ranking pages are one topic, whatever the words say. Ivan Sp builds topical maps that define a site’s pillar and cluster structure before any page gets written. A map sized correctly becomes a work order a team can actually finish, rather than a wish list that never gets built.
Four Steps, in Order
Every map follows the same sequence. Step one defines a core topic scope, big enough to support multiple pages and specific enough to stay coherent. Step two researches subtopics through keyword tools, autocomplete, People Also Ask, and competitor sitemaps. Step three clusters the research by search-result overlap rather than keyword wording. Step four builds the pillar-to-cluster hierarchy with internal linking planned in both directions.
Skipping the order produces the usual failure. Clustering before researching invents categories nobody searches for, and building the hierarchy before clustering produces a structure that fights the actual query data.
Clustering by What Google Already Believes
I cluster on ranking overlap. Two differently worded queries returning the same URLs are one cluster rather than two. Google is already telling you which queries it considers related through shared rankings, and pure keyword-string similarity misses that signal entirely.
This distinction is what actually prevents future cannibalization. A map built on wording alone can group two queries that read similarly but need separate pages, or split two that Google already treats as one.
Deliberate Sizing
I cap a map, usually in the 25 to 40 page range, rather than letting it grow without limit. Unbounded topical maps tend toward the same failure: hundreds of thin, low-value topics instead of a focused set a team can execute.
Size gets set by what a team can realistically write to a real standard, not by how many keyword variants a tool returns.
Stating the Border on Purpose
Every map states explicitly what it does not cover, and why. A map covering service pages might exclude URL folder architecture, because that decision belongs to the content management system rather than to the map.
The stated border serves two purposes: an honest scope statement, and a guardrail against expansion requests creeping the map back toward the unbounded version it was built to avoid.
Flagging Rows That Decay
Rows covering pricing, regulations, or “best X in [year]” listicles get flagged for volatility at map-building time, not discovered later as a stale page. The flag turns the map into a built-in refresh schedule instead of treating every published page as permanent.
The Map Becomes the Work Order
Pages get built directly off map rows, service pages first and sub-service pages nested under them. One moving-company client’s full topic map replaced duplicate city-to-city pages that existed before the map was built, consolidating scattered content into a coherent structure.
Working from the map in sequence prevents the ad hoc build order that creates gaps in one area and duplicate coverage in another. Where a map surfaces missing coverage against a competitor’s own site, that comparison runs through content gap and competitor analysis.
Where the Standard Keyword Grouping Advice Breaks Down
- The usual advice
- Group keywords by semantic similarity, then build one page per group of closely related terms.
- What holds up in practice
- Wording similarity and intent similarity are different things, and only the results page knows which applies. Two phrases that read as synonyms can return almost no shared URLs, which means Google reads them as separate needs.
Consider a strategist grouping heat pump installation with heat pump installer near me. The words overlap almost completely, so one page seems obvious.
The ranking sets share three URLs out of ten. One query wants a guide and the other wants a local business, and a single page satisfies neither fully.
Ivan Sp measures the overlap rather than reading the words. Google has already decided which queries share an intent, and the ranking URLs are where that decision is published.
Building one page for two intents is the most common reason a well-written page ranks for neither. The fault stays invisible until the page has already been written.
Four Things Commonly Assumed About Topical Maps
Have you checked whether two of your pages are targeting the same intent?
I meet these four assumptions whenever a keyword list is mistaken for a map.
| Commonly assumed | What actually holds |
|---|---|
| A keyword list is a topical map. | A list has no structure. A map assigns each cluster to a page type and states how the pages link to each other. |
| Bigger maps cover more ground. | An uncapped map produces pages nobody has the budget to write well. Capping forces the scoring conversation early. |
| Semantic similarity is the right clustering signal. | Ranking URL overlap is the signal, because it reflects Google’s own judgement about which queries share an intent. |
| A map should cover everything adjacent to the topic. | A map that states nothing about its own boundary grows until it dilutes. Naming the exclusions is part of the deliverable. |
| A map is finished once it is written. | Pricing, regulatory, and year-dated rows decay on a schedule. Flagging them at build time is cheaper than discovering stale pages later. |
Building one page for two intents is why well-written pages rank for neither. The fault stays invisible until after the page is written and paid for.
How a Map Is Built and Bounded
- Clustering rule
- Queries returning substantially the same ranking URLs are treated as one cluster.
- Why URL overlap works
- Overlap reveals Google’s own judgement about which queries share an intent.
- Typical map size
- Roughly 25 to 40 pages, capped deliberately rather than left open ended.
- Structure
- Pillar pages holding a topic, with cluster pages nested beneath and linking up.
- Demand source
- Search Console query data, plus People Also Ask and related search prompts.
- Volatility flag
- Rows covering pricing, regulation, or year-dated listings, which decay on a schedule.
- Boundary statement
- An explicit list of adjacent topics the map excludes, with a reason recorded for each.
A Worked Example: Nine Queries, Three Pages
Consider a firm targeting nine related queries. The clustering below is illustrative, written to show how URL overlap collapses a keyword list. No client engagement is described here.
| Queries | Ranking URL overlap | Pages the map creates |
|---|---|---|
| heat pump cost, heat pump price, how much is a heat pump | 8 of 10 URLs shared | One page on cost |
| heat pump vs furnace, is a heat pump better than gas | 7 of 10 URLs shared | One comparison page |
| heat pump rebates bc, heat pump grant canada | 9 of 10 URLs shared | One rebates page, flagged volatile |
| heat pump installation, heat pump installer near me | 3 of 10 URLs shared | Two pages, since intent splits |
I let the overlap decide. The final row looks like one topic in a keyword tool and behaves as two in the results, so the map builds two pages.
Clustering by wording is sorting a library by the colour of the spines. Clustering by ranking overlap sorts by what readers actually came for.
The rebates row carries a volatility flag from day one. Programme names and amounts change, and a scheduled refresh is cheaper than discovering a stale page later.
How a Topical Map Gets Built
I follow four steps in a fixed order, and the order matters more than the tooling.
- Export the full query set from Search Console, then add competitor terms supplied as URLs or sitemaps.
- Run each candidate query and record the ranking URLs, so overlap can be measured rather than guessed.
- Group queries whose ranking sets overlap substantially, and treat each group as one page.
- Split any group whose ranking sets diverge, since divergence means Google reads two intents.
- Assign each cluster a page type: pillar, cluster page, comparison, or supporting answer.
- Score every row on demand, commercial value, and the credibility the site can bring to it.
- Cap the map at roughly 25 to 40 rows, cutting the lowest scoring rows rather than shrinking every row.
- Flag pricing, regulatory, and year-dated rows for scheduled refresh at map-building time.
- Write the exclusion list, naming each adjacent topic left out and the reason for leaving it out.
- Order the build so every pillar publishes before the cluster pages that will link up to it.
How Map Work Is Scoped
I scope a map against the number of service lines rather than the number of keywords.
- What arrives
- A scored map, a build order, a volatility schedule, and a written exclusion boundary.
- Typical duration
- Three to four weeks for a single service line, longer where several exist.
- What the client supplies
- Search Console access, competitor URLs, and confirmation of commercial priorities.
- Included
- Query export, ranking overlap analysis, clustering, scoring, and the finished map.
- Not included
- Writing the mapped pages, and ongoing publication management.
- What changes the estimate
- Several locations, several languages, or a catalogue needing programmatic treatment.
- How it is quoted
- After a short scoping call, once the service lines are known.
Tools and Primary Sources
The references below supply the demand data and the competitive comparison. Each opens in a new tab.
- Search Console Performance report reports the queries a site already earns impressions for, which is the honest starting point.
- Google Trends shows relative interest over time, which is useful for spotting seasonal and declining topics.
- Ahrefs Keywords Explorer reports the ranking URL set per query, which is what clustering by overlap requires.
- Semrush Keyword Magic Tool expands a seed term into grouped variations from its own index.
Cluster Two of Your Own Queries
I suggest a manual version of the clustering test, which takes about ten minutes.
- Pick two queries you assumed were the same topic.
- Search each one in a private browser window, and write down the first ten URLs for both.
- Count how many URLs appear in both lists.
- Treat seven or more shared URLs as one page, and three or fewer as two pages.
The count settles an argument that keyword tools usually leave open. Building one page for two intents is the most common reason a page ranks for neither.
Common Questions
How is a topical map different from a keyword list?
A keyword list is flat and ungrouped. A topical map clusters keywords by search intent, assigns each cluster to a pillar or sub-page, and defines the internal linking between them, which a keyword list does not do on its own.
How often should a topical map get revisited?
Quarterly suits most sites, with an immediate review whenever a volatility-flagged row’s underlying facts change, such as a pricing update or a regulation shift.
What happens to existing pages that do not fit the new map?
They get evaluated individually. Some get folded into a mapped page, some get pruned, and some justify keeping their existing position when the map’s own logic supports it.
Why cap a topical map instead of letting it grow?
An uncapped map produces pages nobody has the budget to write well. A capped map forces the scoring conversation early, and a page written properly outranks three written thinly.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.