What Is a Topical Map and How Do You Plan One?

A topical map is not a list of articles. It is an assignment document that ties every page to be published in a given topic area to a single query cluster, a single search intent and a specific link position on the map. A keyword list tells you what you could write; a topical map tells you which page owns which query, which pages it receives links from and which pages it links to.

This distinction looks like an administrative detail, but it determines most of the costly mistakes in production. When publishing decisions come from a volume spreadsheet instead of the map, the result is pages that repeat each other, queries left without an owner and content that connects to nothing. Starting the map from the commercial core cuts off all three problems at the source.

Topical authority is an outcome, not a score

The term "topical authority", widely used in the industry, does not refer to a sitewide score that Google assigns and that can be read from the outside. The only system Google has documented under this name is on the news side. Topic authority is used to determine which publisher counts as an expert source for newsworthy queries in areas that require expertise, such as health, politics or finance.

Google has also described the signals this system looks at: how well known a source is for a particular topic or location, how often its original reporting is cited by other publishers, and the source's history of publishing. These do not define the kind of score a corporate blog could accumulate by publishing forty articles. Google's published guide to its ranking systems does not include a general sitewide topical authority score either.

That is why the sentence "once the map is complete, your authority score goes up" is not a measurable promise. It is more accurate to think of topical authority as an output rather than an input: when you have pages in an area that are interlinked, match intent correctly and are genuinely useful, visibility for individual queries in that area increases. Google's helpful content guidance asks the same question from the reader's point of view: would someone researching the site come away with the impression that it is a trusted, recognized source on that topic? The map's job is to build the foundation for that impression, not to fill a metric.

Three mechanisms that make a map useful

There is nothing mystical about how a topical map works. It does three concrete, measurable jobs.

• Discovery and link flow. The rule in Google's link documentation is simple: every page you care about should have a link from at least one other page on your site. The map determines, before publication, where that link will come from. The same documentation says there is no such thing as an ideal number of links on a page, so the question is direction, not quantity. How to choose link directions is the subject of internal linking architecture.
• Meeting intent. When each node is assigned a single search intent, the page format becomes clear too. Writing a guide for a query that expects a comparison, or publishing a definition article for a query with purchase intent, creates a mismatch regardless of content quality.
• Uniqueness. The map pins the primary owner of a query to a single page. Without this record, it is only a matter of time before three separate articles target the same query.

Directory structure plays a supporting role. Google notes that grouping topically similar pages in the same directory can help with crawling behavior, but it describes this effect in the context of sites with more than a few thousand URLs. On a small site, reorganizing URL folders is not something that comes before building the map itself.

Building the map from the commercial core

Starting a topical map from blog ideas turns the map's direction upside down. The page that needs to rank is usually a service, category or product page; guide content paves the way to that page. The setup follows this order.

1. Write down the commercial core. List the pages that generate revenue. The map starts from them, because the map's job is not to collect traffic but to build the link and relevance path to those pages.
2. Extract the decision questions. For each core page, write down the questions buyers have to answer before purchasing: what is it, how does it work, what does it cost, what are the alternatives, what are the risks, when is it not a good fit, what happens if things go wrong. This fan-out list grows as long as the topic is genuinely complex; it is not about reaching a target number.
3. Reduce the questions to meaning clusters. Different phrasings of the same information need form a single cluster. "What is crawl budget" and "crawl budget meaning" are not separate nodes. Distinguishing semantically close expressions is the step that keeps the map from bloating.
4. Layer them. The commercial core page at the top, the cluster's main guide beneath it, and nodes that go deeper beneath that. The number of layers comes from the topic; forcing four layers onto an area that ends at three produces empty nodes.
5. Make an assignment for every node. One primary query, one intent, one format.
6. Write down link directions. For each node, fill in the "receives links from" and "links to" fields. If these fields are empty, the node has not yet entered the map.
7. Set the production order. A page that is a link target is published before the page that will link to it.

In this form, the map does not require a complex tool. A filterable spreadsheet or a plain text file is enough:

core: /seo-consulting                [commercial]
  guide: what is technical seo       [info]      -> link: core
    node: crawl budget               [info]      -> link: guide
    node: robots.txt rules           [info]      -> link: guide, crawl budget
    node: finding orphan pages       [problem]   -> link: guide, internal linking
  guide: internal link architecture  [info]      -> link: core
    node: choosing anchor text       [info]      -> link: guide
    node: click depth                [info]      -> link: guide

Assigning one intent and one primary query to each node

The assignment table is the working part of the map. However good the diagram looks, if this table has not been filled in, the map is nothing more than a drawing.

The primary query belongs to a single page and cannot be shared. Supporting phrases can appear on more than one page, but they cannot become the primary target of a second page. If this rule is not kept in writing, the map gradually collides with itself; working out retroactively which page lost which query then requires a cannibalization check. How to validate intent assignments is a separate discipline, covered under search intent alignment.

A new page or a new section?

The most expensive mistake in fan-out work is turning every question that comes up into a page. If you extracted a hundred questions, you do not need a hundred pages. Fan-out coverage means meeting the information need; it does not mean producing shallow long-tail pages.

A question deserves its own node only if it meets all three of these conditions: it has its own distinct search intent or format, it needs an answer too independent and deep to be given within a section, and it has a position on the map from which it can meaningfully give and receive links. If any of the three is missing, that question is a section inside an existing node.

The reason for this conservatism is cost. Every new page needs internal link budget, adds update overhead and carries the risk of colliding with neighboring nodes. The gain, on the other hand, is not guaranteed. Google's helpful content guidance lists producing lots of content on many different topics in the hope that some of it might perform well among the warning signs of search engine-first content. Its spam policies likewise define scaled content abuse as producing many pages for the purpose of ranking without adding value for users; the criterion in that definition is not the production method but the absence of value in the result.

Another point in the same guidance directly concerns map planning: Google has no preferred word count. Writing targets such as "three thousand words" into nodes turns the map into a volume-filling document instead of an information-needs document.

From map to publishing calendar

The map and the calendar should share the same row identifier. Each row in the calendar corresponds to a node on the map; a publishing row with no counterpart is a page produced outside the map and has no link plan.

Two rules make sequencing easier. First, the page that is a link target is published first: producing child nodes that will link to a guide node before the guide exists creates a link debt that has to be paid off later. Second, do not move on to another cluster until one is finished. Half-finished clusters look complete on the map, but their actual link structure is incomplete, and that gap surfaces at the first audit, if not sooner.

Within the priority order, commercial proximity is decisive. Nodes one step away from the core page come before rare queries in the fourth layer. Volume alone is not a sufficient criterion for ordering; a high-volume node far from the purchase path can come after a low-volume decision question.

Keeping the map alive

A topical map is not a document you build and then archive. It changes in three situations. When a real question with no counterpart on the map shows up in search data or sales conversations, a new node is opened. When two nodes start competing with each other for the same query, one is merged into the other and the old URL is redirected. When a node's traffic and coverage erode over time, the page is refreshed or retired; how to make that decision is the subject of content decay analysis.

The one practice that keeps the map honest is regularly comparing the link plan in the document with the links actually published. A link written into the plan but missing from the page slowly turns the map into fiction.

Frequently Asked Questions

How many pages should a topical map have?

There is no target number. The number of nodes comes from the number of distinct intents you can serve well. Filling fifteen nodes of a forty-node map with shallow content gives a weaker result than building twenty nodes solidly. Google has neither a preferred word count nor an ideal number of links per page, and the map should not be built on fixed targets like these either.

Does a small site need a topical map?

Its value comes from the assignments, not the page count. Even on a ten-page site, if it is not written down which page owns which query and which page it links to, collisions start from the third article onward. On a small site the map is short, not unnecessary.

Can there be both a service page and a guide on the same topic?

Yes, if their intents differ, and usually there should be. The service page serves commercial intent and the guide serves informational intent. The problem starts when both target the same primary query. If you cannot write a separate primary query for each in the assignment table, one of them is not really a separate page.

What format should the map be kept in?

The format does not matter; the fields do. If a filterable spreadsheet has fields for node name, primary query, intent, format, link source, link target and status, the map works. Visual diagrams are useful for presentations, but production decisions come from the table.