SEO Clusters: Build Pillar and Spoke Content with Knowledge Graphs

Posted Sunday, April 19, 2026.

SEO clusters is a way of organizing your content to help you rank for multiple related keywords. Traditionally, it is a way of thinking about your content as a network of related concepts. Usually, you start with one pillar page, a handful of spokes (pages connected to the pillar), internal links between them. The pages are then filled with keywords chosen by volume. However, you end up with distinct content silos that might miss the bigger picture of how your content fits into the already existing discourse on the topic you want to rank for in search engines and LLMs.

There is an alternative way to build SEO clusters from the bottom up. Instead of starting from the pillar - spoke structure, you analyze the existing content you have and the existing informational supply. The clusters are already there, in the co-occurrence patterns of what people search for and what search engines return. It has a topology: some concepts are dense, some are peripheral, some bridge one community to another. A knowledge graph makes that topology visible. Once it is visible, the pillar and spoke structure stops being a decision — it emerges from the data itself.

This page describes how to build SEO clusters by treating the underlying discourse as a network and letting its structure dictate the content architecture. It is the strategic counterpart to the more tactical Keyword Clustering for SEO page — where this one designs the hub-and-spoke geometry, the other one fills the spokes with specific keyword groups.

1. What Are SEO Clusters?

An SEO cluster is not a collection of related pages. It is a content cluster architecture where one pillar page covers a broad head topic and several spoke pages cover adjacent subtopics, all linked bidirectionally. The point of the arrangement is not that the pages look connected from the outside. The point is that, read together, they form a coherent semantic region — a small knowledge graph of its own, embedded in the site.

Search engines have always rewarded density. Google's topical authority signals, the entity consolidation inside its Knowledge Graph, the way LLM search engines decide which page to cite — all of these operate on the same logic. A page is easier to retrieve when it sits inside a well-linked region of related content. An isolated article targeting a single keyword can rank, but it decays faster, answers fewer adjacent queries, and gets passed over when an AI assistant is looking for a source to quote.

The reframe is simple: a cluster is not what you build on your site. It is what already exists in the discourse around your topic. Your site either mirrors that structure or diverges from it — and the divergence, not the mirroring, is where ranking is decided.

2. SEO Clusters vs Keyword Clusters vs Topic Clusters

Three terms circulate, often treated as synonyms. They refer to different layers of the same process and conflating them is the most common reason cluster strategies fail at the drafting stage.

• Keyword clusters are groups of search terms sharing intent or SERP overlap. They live in spreadsheets. They are tactical, and the Keyword Clustering for SEO page covers how to produce them.
• Topic clusters are groups of concepts and entities that belong together semantically. They live in a knowledge graph. They are descriptive — a reading of how a domain is organised in language.
• SEO clusters (or content clusters) are the page-level architecture built on top of the topic cluster: a pillar page, a set of spoke pages, and the internal links between them. They live on the site.

The three layers feed each other. Keyword clusters surface the terms people actually use. Topic clusters organise those terms into coherent regions of meaning. SEO clusters turn those regions into navigable content on your site. Skip any of the layers and the architecture starts drifting — spokes that nobody searches for, pillars that cover everything and rank for nothing.

3. Why Knowledge Graphs Build Better Clusters Than Templates

Template-driven cluster strategy starts from a fixed form — one pillar, ten spokes, three supporting FAQs — and asks the writer to fill it. It assumes the shape of the discourse before looking at it. Knowledge-graph clustering does the opposite. It reads the SERP and the search-intent data, builds a network of co-occurring concepts, and lets the shape emerge from the data itself.

Three network measures do the work:

• Betweenness centrality — finds the node that bridges the most clusters. That node, not the highest-volume keyword, is the natural pillar. It is the concept through which every other subtopic has to pass.
• Community detection — partitions the graph into regions of densely connected nodes. Each region is a candidate spoke: a coherent subtopic with its own internal vocabulary.
• Structural gaps — the edges that could exist between communities but don't. These are the spokes that have the highest informational gain when written, because nobody else has connected those regions yet.

Templates give you a plausible structure. Graph topology gives you the one that matches the niche you're actually writing into. The difference shows up in rankings that survive algorithm updates, in pages that get cited by AI assistants, and in clusters that don't need rewriting every time a competitor publishes something new.

 

4. Step 1 — Read the Cluster Landscape

Before picking a pillar, you need two graphs in parallel: one for what people are looking for, one for what they currently find. Run them through the InfraNodus MCP server or directly in the app.

• The search-intent graph is built from related queries and People-Also-Ask data — call analyze_related_search_queries with your main term. This is the demand side: the language and the combinations your audience actually uses.
• The SERP graph is built from the top search results — call analyze_google_search_results with the same term. This is the supply side: the vocabulary of the pages currently ranking.

The overlap between the two is the shared language of the niche — the words you must use to be recognised as belonging to it. The divergence is more interesting. It marks the terms people reach for that existing content does not satisfy, and the terms existing content insists on that nobody is actually searching. Between these two asymmetries, the outline of a cluster begins to show itself.

5. Step 2 — Design the Hub and Spokes from Graph Topology

With the graph in front of you, the editorial decisions that normally take a week reduce to four readings.

• The highest-betweenness node becomes the pillar topic. It is the concept that everything in the graph has to pass through — a good proxy for the page that will earn the most inbound links within the cluster.
• Each community (a colored region in the visualisation) becomes a candidate spoke. One page per community, titled around that community's most central keyword combination.
• The dense cores inside each community become the subsections of that spoke page — the H2s and H3s that will make the page feel comprehensive to both a reader and a crawler.
• Bridging keywords, the ones sitting on the edge between two communities, are candidates for comparison or "X vs Y" articles. These pages do double duty: they rank for the comparison query and they knit two spokes together structurally.

What emerges is a sitemap that is not a guess. The biggest node is the pillar page. The cluster centroids are the spoke pages. The edges are the internal links. The graph is the blueprint, and the only thing left is to write.

6. Step 3 — Find Content Gaps That Become Unique Spokes

The most valuable spokes are often the ones nobody has written yet. Run search_queries_vs_search_results and the tool will surface the combinations people search for that do not appear in the top results. These are the gap spokes — pages you can publish into empty structural space.

The mechanics of gap detection are covered in the Content Gap Analysis tutorial. What's specific to cluster work is how you use the gaps. A gap between two communities in the demand graph tells you there is demand for a concept that connects those two regions — write the spoke as a bridge article and link it to both adjacent spokes. A gap that appears in demand but is missing in supply tells you the niche hasn't caught up with what searchers want — that spoke is the one most likely to rank quickly, and most likely to be cited by AI search engines later, for the same reason: it offers informational gain that the existing corpus does not.

7. Step 4 — Map Clusters to Content Types

Each position in the cluster suggests its own form. The table in the Keyword Clustering doc lists the full mapping by keyword characteristic. For strategic cluster design the same mapping expressed by position in the graph looks like this:

Graph Position	Content Type	Typical Length
Highest-betweenness node (network hub)	Pillar guide	3000+ words, covers every community briefly
Community centroid	Spoke page	1500–2000 words, covers one community in depth
Bridging node between communities	Comparison / "vs" article	1200 words, explicit connections both ways
Structural gap (demand without supply)	Gap-bridge article	1500 words, novel angle, highest informational gain
Frequently co-occurring pairs	FAQ / Q&A block	Short, structured for AI retrieval

The rule of thumb is not the word count — it is the linking obligation. A pillar touches every community briefly and links outward. A spoke goes deep into one community and links laterally to siblings. A bridge article links to both sides of the bridge in its first paragraph. Get that geometry right and the word counts sort themselves out.

8. Step 5 — Internal Linking from Graph Edges

The graph is also the sitemap. Every edge in it suggests an internal link, and the shape of the linking follows the shape of the graph rather than the shape of the site's navigation.

• Every spoke links to the pillar, and to any other spoke whose community shares an edge with its own. Never link all spokes to each other by default — dilute everything and nothing signals strongly.
• Edge weight in the graph maps to link prominence on the page. A strong co-occurrence becomes a link in the intro paragraph. A weaker one becomes a mention further down, or a link in a "related reading" block.
• Anchor text comes from the top bigrams and relations the graph returns (the topRelations and topBigrams fields in the MCP response). Rather than invent link text, you use the phrases your audience already types.

A concrete example: in a SERP graph for "seo clusters" the strongest relations are topic <-> cluster, pillar <-> page, and cluster <-> strategy. Those pairings become anchor text across the cluster — "topic cluster" links the pillar to the definition spoke, "pillar page" links the pillar to the architecture spoke, "cluster strategy" links both spokes into the comparison article. The linking doesn't have to be invented; it is already implied by the co-occurrence data.

9. Step 6 — Audit and Refresh the Cluster

Clusters decay. A SERP from last quarter is not the same as today's — new entities enter, old ones drop, communities merge or split as the discourse shifts. A cluster that ranked on publication can lose coherence within a year without anyone changing a line on the site.

The maintenance workflow is to re-run the same two graphs quarterly and compare them. The difference_between_texts tool surfaces what's new and what has dropped out.

• A new community appeared in the demand graph — consider adding a new spoke, before competitors do.
• A node that used to be central has lost betweenness — either the discourse moved on, or that spoke needs to merge into a neighbour.
• A gap you published into is now covered — either deepen the angle, or pivot the spoke toward a newer gap that has opened nearby.

The audit is cheap if you save the previous graph. The MCP server keeps named graphs, so a quarterly diff takes a single prompt.

10. Automating the Cluster Workflow with the InfraNodus MCP Server

Every step above can be run manually, but the whole chain is designed to be callable from a single prompt inside Claude, Cursor, Claude Code, n8n, or Make.com. The InfraNodus MCP server exposes each graph operation as a tool an LLM can compose, which means a cluster plan is one conversation away.

1. analyze_related_search_queries — builds the demand graph
2. analyze_google_search_results — builds the supply graph
3. search_queries_vs_search_results — surfaces the gap spokes
4. generate_topical_clusters — proposes the spoke list
5. generate_content_gaps — proposes the unique angles per spoke
6. generate_seo_report — produces a per-page brief

The same workflow is packaged as the Claude SEO skill if you prefer a single installable capability rather than composing the tools yourself. More on deployment options in the MCP Tools Catalog.

11. SEO Clusters for LLMO and AEO (AI Search Optimization)

The shift from keyword retrieval to entity retrieval has made clusters more important, not less. An LLM that is deciding which page to cite for a query does not look at a single page in isolation — it looks at how that page sits inside the entity graph it has already built. A well-clustered site reads as a coherent region of that graph; an isolated article reads as a node with no neighbourhood.

The practical consequence is that semantic SEO and LLMO / AEO optimization are downstream of cluster work, not parallel to it. If the pillar and spokes are structured to mirror the entity relations of the niche, citations by AI assistants follow. If they aren't, no amount of schema markup compensates.

Two specifics worth keeping in mind:

• Expose the cluster as structured data. The pillar-to-spoke links should be crawlable <a> elements, not JavaScript-only navigation, and the breadcrumb / hasPart schema should make the hierarchy explicit.
• Use the graph's top relations as sentence-level phrasing. LLMs learn which entities belong together from co-occurrence. If the same pairings show up as bigrams across your cluster, the entity graph of the model absorbs them as a unit — which is exactly how citation decisions get made.

See Entity-Driven SEO and Knowledge Graphs for LLM Reasoning for the deeper mechanics of how clusters map onto entity retrieval.

12. Common Mistakes to Avoid

Most cluster strategies fail for one of a small number of structural reasons. All of them share a common shape: a decision made about the cluster before looking at the discourse itself.

• Picking the pillar by search volume instead of by graph centrality. The highest-volume keyword is often the most generic — it will compete with aggregators and dictionaries. The highest-betweenness keyword is usually more specific and more defensible.
• Spokes that only link back to the pillar. A star topology is brittle — it signals a shallow cluster. Spokes that share an edge in the graph should share a link in the site, or the topology is lost in translation.
• Templates copied from HubSpot or Ahrefs guides without looking at the actual SERP. The template is a useful heuristic when the niche is already well-mapped; it is a liability when it isn't.
• Treating keyword clusters as finished SEO clusters. Keyword clusters are a raw input. Until they are assigned positions in a pillar-and-spoke architecture and wired with internal links, they are not yet an SEO cluster.
• Never re-running the analysis. A cluster built once and never revisited decays with the SERP. The graph is a reading, not a blueprint — it needs to be read again.

13. Try It Yourself

Pick a single search query that matters for your site. Run the two graphs — demand and supply — and read their topology before writing anything. The pillar, the spokes, and the gap spokes will usually be obvious within the first few minutes. The rest of the work is writing into a structure the discourse has already given you.

You can do this directly in the InfraNodus SEO app, or let the MCP server run the whole chain from your IDE, chatbot, or automation workflow.

Log In    Sign Up