One pillar, many spokes, and a strict rule about how they link — that’s the whole shape of how I organize a WordPress site, and it’s not decoration. Hub-and-spoke clusters are the structure that turns a pile of related posts into something a search engine reads as authority on a topic rather than a scatter of unconnected pages. This very post is a spoke on my own content-pipeline pillar, which makes it a convenient example to point at. Here’s what the structure is, why my posts link the way they do, and how to build one in WordPress without leaving orphans.
What a hub-and-spoke cluster is
A hub-and-spoke cluster is one broad pillar page surrounded by many narrow posts, all on the same theme. The pillar — the hub — is the wide overview of a topic: what my content pipeline is, end to end. Each spoke is a deep, narrow treatment of one piece of it: how the lint gate works, why I keep a human in the loop, how I validate schema. The hub gives the map; the spokes walk each road.
The division of labor is deliberate. A single page can’t rank well for both “how does an AI content pipeline work” and “how do I minify JSON-LD for WordPress” — those are different searches with different intents. Split across a hub and its spokes, each page targets one intent cleanly, and together they cover the topic with a depth no single article could. The pillar earns breadth; each spoke earns a specific query.
What binds them into a cluster rather than a set of loose posts is the linking. The pillar links down to every spoke, and every spoke links back up to the pillar, so the whole group is wired together as one clearly-related body of work on a subject. That wiring is the part people skip, and it’s the part that actually does the work.
Why my posts link the way they do
If you’ve read a few of my posts, you’ll have noticed the pattern: each one links up to the pillar it belongs to, and the pillar lists all of them. That’s not a stylistic tic. Internal links are how a search engine discovers pages and understands the relationship between them, and a consistent hub-and-spoke pattern makes that relationship legible. Google’s own guidance notes that pages need crawlable links to be found and connected at all.
The linking also passes signal. When a cluster of pages all reference a central pillar, and the pillar vouches for each of them, it concentrates relevance on the topic rather than diffusing it. A reader who lands on one spoke has an obvious path to the overview and to sibling posts, which keeps them on the subject instead of at a dead end. Structure that helps a reader move is the same structure that helps a crawler map.
So when a spoke of mine links once to the content pipeline I run, that’s the spoke declaring its hub. It’s a small, deliberate act repeated across every post in the cluster, and the repetition is the point — it’s what makes the group cohere.
The bidirectional links that make a cluster work
The single most important rule in the whole structure is that links run both ways. It’s not enough for the pillar to link down to its spokes, or for the spokes to link up to the pillar — both have to be true at once. A one-directional cluster is only half-wired, and the half you left out is usually the half that matters for discovery.
Beyond the vertical links, closely related spokes link to each other. The post on the lint gate and the post on keeping a human in the loop are natural neighbors, so they reference each other where it genuinely helps a reader, not gratuitously. That horizontal linking is where you have to exercise restraint: a link earns its place when it’s the reader’s likely next step, and cross-cluster links stay rare so the theme doesn’t blur. One or two well-chosen sibling links beat ten forced ones.
| Pillar (the hub) | Spoke (a leaf) | |
|---|---|---|
| Scope | Broad overview of the topic | One narrow piece, in depth |
| Target query | The wide, high-level search | A specific, long-tail search |
| Links down to | Every spoke in the cluster | Closely related siblings only |
| Links up to | — (it is the top) | Always back to its pillar |
Read the table as a wiring diagram, not a hierarchy of importance. The pillar isn’t “better” than a spoke; it just plays a different role in the graph. Get the two columns’ link behavior right and the cluster holds together; get it wrong and you have a folder of posts that merely happen to share a subject.
Orphan pages, and why they never happen here
An orphan is a page nothing links to. It can be your best-written post and still underperform, because a crawler may struggle to find it and a reader never will. Orphans are the natural failure mode of publishing without a structure: you write a post, publish it, and forget to wire it into anything, so it sits alone. In a hub-and-spoke system, orphans are designed out rather than cleaned up.
The mechanism is simple: a post isn’t considered done until it links up to its pillar and the pillar links back down to it. Both links get added as part of publishing, not as an afterthought. Because the rule is “every spoke connects to its hub in both directions,” there’s no state in which a finished post is unconnected. The structure makes the orphan case impossible rather than merely discouraged.
I also verify it rather than trust it. After each publish, I regenerate the internal link map from what’s actually live and check for any page nothing points to. Doing it from the live site matters, because the disk copy of a post can claim links the live version doesn’t have. A stale map is exactly how an orphan sneaks back in, so the check reads reality, not intention.
Handling spokes that aren’t published yet
A cluster is rarely built all at once. You publish the pillar, then the spokes trickle out over weeks. That creates an awkward moment: how do you reference a sibling post that you’ve planned but haven’t published? Linking to a page that doesn’t exist yet gives readers a dead link and crawlers a 404, which is worse than not mentioning it at all.
My rule is to name the unpublished spoke in bold as plain text, marked clearly as coming soon, with no link attached. The reader learns the piece exists and is on the way; nothing points at a missing URL. Then, when that spoke actually publishes, the placeholder becomes a real link and the wiring completes. It’s a small discipline, but it keeps a growing cluster from ever containing a broken internal link.
The same principle applies to the pillar itself while its cluster fills in. The hub can list its spokes as a mix of live links and coming-soon placeholders, and it gets updated each time a new spoke lands. The cluster is a living structure; the linking is maintained as it grows, not frozen at launch.
How to build a cluster in WordPress
In WordPress the mechanics are straightforward, which is part of why I keep content here. Publish the pillar first as a normal post or page, then publish each spoke and, as you do, add the two links that bind it in: the spoke’s link up to the pillar, and the pillar’s link down to the new spoke. Categories can mirror the cluster for navigation, but the internal links between posts are what actually carry the weight — categories are a convenience, not a substitute.
Keep the URLs clean and stable so the links never rot: descriptive slugs, trailing slashes, and no dates baked into the path, since a post you update shouldn’t have a year stuck in its address. If you manage posts through the WordPress REST API, you can even regenerate the link map programmatically and catch orphans automatically. However you do it, the through-line is the same: publish the hub, wire every spoke both ways, name the unpublished ones as coming soon, and verify from the live site that nothing is stranded.
FAQ
What are hub-and-spoke clusters in WordPress?
A hub-and-spoke cluster is one broad pillar page surrounded by many narrow posts on the same theme, all wired together with internal links. The pillar gives an overview; each spoke covers one piece in depth. The pillar links down to every spoke and each spoke links back, so the group reads as one authoritative body of work.
How should a pillar and its spokes link to each other?
Bidirectionally. The pillar links down to every spoke, and each spoke links back up to the pillar. Closely related spokes can also link to each other where it genuinely helps a reader. Both vertical directions must be true at once; a cluster linked only one way is half-wired and hurts discovery.
What is an orphan page and why does it matter?
An orphan is a page nothing links to. Crawlers struggle to find it and readers never do, so even a great post underperforms. Hub-and-spoke structure designs orphans out: a post isn’t done until it links to its pillar and the pillar links back, so no finished page is ever left unconnected.
How do I reference a cluster post that isn’t published yet?
Name it in bold as plain text, marked as coming soon, with no link. The reader learns the piece exists without hitting a dead link or a 404. When that spoke publishes, turn the placeholder into a real link. This keeps a cluster that’s still filling in from ever containing a broken internal link.
Do WordPress categories replace internal links for clusters?
No. Categories mirror the cluster for navigation, but the internal links between the pillar and its spokes are what actually carry the relevance signal. Treat categories as a convenience layer and the bidirectional post-to-post links as the real structure. Build both, but don’t rely on categories alone.
My Thoughts
I resisted this structure for a long time because it felt like bureaucracy — rules about which post links to which, enforced on every publish. What changed my mind was watching individual good posts quietly go nowhere because nothing connected them to anything. The writing wasn’t the problem; the isolation was. A cluster doesn’t make any single post better, but it makes the whole set legible, to readers and to crawlers, as a considered take on a subject rather than a heap of articles. Wire every spoke to its hub, both ways, every time, and the structure quietly compounds.