Skip to main content
Sebitu Pewobe logo

Editorial strategy notes for independent publishers

Stop publishing at random. Start mapping topical authority before you write a single word.

This blog is a working record of how pillar pages and supporting articles fit together, how a topic gets mapped on a whiteboard before any drafting starts, and how internal links tell Google what your site is actually about. It is written for people who run their own sites, not for teams handing the job to a content agency.

  • Source-checked before publishing
  • Plain-language explanations
  • No filler word counts
  • Built for solo publishers
A whiteboard covered in sticky notes and marker lines mapping out a content cluster topic before any writing begins
A topic map, sketched before the first draft.
  • Pillar Pages
  • Whiteboard Mapping
  • Internal Linking
  • Content Depth

Why the random approach stops working

Fifty unrelated posts don't add up to anything Google can point to

Most publishers start the same way: an idea shows up, an article gets written, it goes live, and the process repeats with the next idea that comes along. There's nothing wrong with enthusiasm. The problem is that a site built entirely from disconnected ideas never accumulates a shape. Search engines can crawl every page individually, but they have a much harder time understanding what the site, as a whole, actually knows.

A content cluster works differently. One page, the pillar page, covers a topic at a manageable depth and openly signals that there is more to explore. Every supporting article underneath answers one narrower question and links back to that pillar. The result isn't fifty scattered guesses. It's a structure that reads, to a crawler and to a human, as a body of knowledge rather than a pile of posts.

The anchor of the cluster

What a pillar page actually does

A pillar page is not the longest post on the site and it isn't meant to answer every question in exhaustive detail. Its job is to frame the whole topic, name the subtopics that matter, and hand the reader off to the article that goes deeper on whichever piece they need. Think of it as a table of contents that happens to be genuinely useful on its own.

Supporting articles do the opposite job. Each one narrows in on a single question, term, or use case, and answers it thoroughly rather than broadly. The relationship only works if both directions of linking exist: the pillar has to link down into every supporting piece, and every supporting piece has to link back up to the pillar and, where relevant, sideways to its neighbors.

  • Frames the territory

    Names every subtopic the cluster is going to cover, in the order a reader would naturally ask about them.

  • Sends readers onward

    Links out to each supporting article at the exact point where a reader would want more depth.

  • Stays broad on purpose

    Avoids duplicating the depth found in the supporting content, so the two don't compete for the same search intent.

  • Gets updated first

    Serves as the page that's revisited whenever the cluster grows, since it's the one place tracking the whole map.

A hand sketching a hub and spoke diagram on paper showing a central pillar page connected to several supporting articles
The pillar sits at the center; supporting articles branch outward and link back in.

A cluster only functions as a cluster once every supporting article can point to why it exists in relation to the pillar, not just on its own.

Editorial notes, Sebitu Pewobe

Before the first draft

Mapping the whole topic on a whiteboard, before writing a word

The temptation is to open a blank document and start typing the moment an idea feels ready. Waiting a little longer and mapping the full topic first tends to save far more time than it costs. A whiteboard, a stack of index cards, or a plain sheet of paper works fine. What matters is seeing the entire subject at once instead of one article at a time.

  • 01

    Brain-dump the territory

    Write down every question, subtopic, and related term connected to the subject, without judging whether each one deserves its own article yet.

  • 02

    Group by intent, not by keyword

    Cluster the raw list by what a reader is actually trying to do or decide, since several keyword variants often belong to one real question.

  • 03

    Assign one article per group

    Give each intent group a single supporting article rather than letting it splinter into three or four thin, near-duplicate posts.

  • 04

    Circle the pillar and draw the spokes

    Mark which group is broad enough to become the pillar, then draw the connecting lines so the linking plan exists before the writing does.

A person standing at a whiteboard grouping topic ideas into clusters using colored markers during an editorial planning session
Grouping by reader intent, before deciding on article count.
A close up of sticky notes arranged in a hub and spoke pattern representing a content cluster topic map
Each sticky note becomes one supporting article, not five.

Focus over volume

Why ten focused articles tend to outperform fifty scattered ones

Fifty posts sounds like more coverage than ten. In practice, fifty scattered posts usually means dozens of thin pages competing against each other for the same handful of search terms, while whole parts of the topic are never addressed at all. Ten articles that were mapped against a real topic model, each answering a distinct question and linked deliberately to the others, tend to read as more complete, even though the raw count is lower.

Drag the handle in the bottom-right corner of the frame to compare

Ten organized article folders arranged neatly around a central pillar folder, each labeled with a distinct subtopic
A ten-article cluster, mapped around one pillar
Fifty scattered article drafts spread randomly across a desk with no visible grouping or connection between them

50 scattered drafts10 mapped articles

An open notebook with hand drawn arrows connecting article titles to show an internal linking strategy for a content cluster
Arrows drawn before links are built, so nothing gets skipped.

Making the relationship legible

Interlinking a cluster so Google can read the relationship

A crawler doesn't know that ten articles belong together just because they sit in the same folder or share a tag. It learns that from links, and specifically from the words used in the anchor text around those links. A cluster is interlinked properly when the connections run in more than one direction and the anchor text describes the destination honestly rather than generically.

  • Pillar to cluster

    The pillar links down to every supporting article, at the point in the text where that subtopic is first mentioned.

  • Cluster to pillar

    Every supporting article links back up to the pillar, usually early on, so readers and crawlers can find the fuller map.

  • Cluster to cluster

    Related supporting articles link sideways to each other where the subject naturally overlaps, not as an afterthought.

  • Descriptive anchor text

    Anchor text names the destination topic instead of relying on "click here" or "read more" phrasing.

Knowing when to stop, and when to keep going

Signals that a cluster has enough depth, or needs more

There isn't a fixed article count that marks a cluster as "done." What tends to matter more is whether the reader's likely follow-up questions have somewhere to go, and whether two articles have quietly started competing for the same search intent instead of covering separate ground.

  • Every subtopic identified on the whiteboard has a published article, or a clearly marked gap on the map.
  • No two articles in the cluster are trying to rank for the same core phrase.
  • The site's internal search or "people also ask" style questions stop surfacing new subtopics the cluster hasn't touched.
  • The pillar page can still fit an honest, one-sentence description of each supporting article without repeating itself.
  • Adding one more article would mean splitting an existing topic rather than covering new ground.
A person reviewing printed article drafts spread on a table, checking off completed subtopics against a topic map
Checking coverage against the original map, not against a target word count.

Common questions

Frequently asked questions

  • A regular post is usually written on its own, answering one question in isolation. A pillar page is written as part of a plan: it exists specifically to introduce a broader topic and link out to the narrower articles that cover each part of it in more depth. The pillar is judged by how well it organizes and connects, not by how exhaustively it covers any single detail.

  • It depends entirely on how many distinct subtopics the whiteboard mapping session turns up. Some topics map cleanly into six or seven supporting pieces. Others, especially broader subjects, might map into fifteen or more. The number is a result of the mapping process, not a target set in advance.

  • No. A physical whiteboard, sticky notes, or a plain spreadsheet all work. What matters is being able to see every subtopic at once and draw the connections between them before any article is drafted. The tool is far less important than the habit of mapping before writing.

  • This usually means the original mapping split one subtopic into two articles instead of one. The typical fix is to consolidate the weaker of the two pieces into the stronger one, then redirect internal links so the cluster points at a single, clear destination for that subtopic rather than two competing options.

  • Older posts are often worth reviewing against the new topic map rather than deleting outright. Some will slot neatly into an existing cluster as a supporting article once it's relinked. Others may cover ground the map doesn't need at all, in which case merging them into a stronger page or retiring them tends to make more sense than leaving them standing alone.

  • Generally, yes. Since the pillar is the page responsible for framing the whole topic and linking to every supporting piece, it needs a short update whenever a new article is added or an old one is retired. Skipping this step is one of the more common reasons clusters end up with orphaned pages that nothing links to.

Have a topic you're trying to map?

If a question about pillar structure, cluster depth, or internal linking came up while reading, the contact page is open for exactly that kind of note.

Send a note