Q: How many supporting articles does one pillar actually need to "count" as a cluster?
Short answer: there's no magic number, but think in terms of subtopic coverage, not post count. A pillar is "complete" when you've answered the questions a knowledgeable reader would still have after reading it.
A practical floor is 6-10 supporting articles, but I've seen a 4-article cluster outrank a 30-article one because the 4 covered every distinct angle and the 30 were thin reslices of the same keyword.
In practice: list every subquestion from People Also Ask, autocomplete, and your own forums. Group near-duplicates. The number of leftover groups is your cluster size. If two "articles" answer the same question, they're one article.
Got a question about cluster sizing? Send it in.
Short answer: there's no magic number, but think in terms of subtopic coverage, not post count. A pillar is "complete" when you've answered the questions a knowledgeable reader would still have after reading it.
A practical floor is 6-10 supporting articles, but I've seen a 4-article cluster outrank a 30-article one because the 4 covered every distinct angle and the 30 were thin reslices of the same keyword.
In practice: list every subquestion from People Also Ask, autocomplete, and your own forums. Group near-duplicates. The number of leftover groups is your cluster size. If two "articles" answer the same question, they're one article.
Got a question about cluster sizing? Send it in.
Q: Is my pillar page just a fancy category page?
Short answer: no, and treating it like one is why a lot of pillars underperform. A category page lists links. A pillar page actually teaches the topic end to end, then links out to the deep dives.
The difference is substance. A pillar should rank on its own for the broad term even if you deleted every internal link from it. If it can't, it's a navigation page wearing a pillar costume.
In practice: write the pillar so a complete beginner finishes it feeling oriented on the whole topic. Each subsection is a 2-4 sentence summary that hands off to a cluster article via a contextual in-text link, not a sidebar widget. Aim for genuine standalone value plus the hub role.
Question of your own? Drop it in the chat.
Short answer: no, and treating it like one is why a lot of pillars underperform. A category page lists links. A pillar page actually teaches the topic end to end, then links out to the deep dives.
The difference is substance. A pillar should rank on its own for the broad term even if you deleted every internal link from it. If it can't, it's a navigation page wearing a pillar costume.
In practice: write the pillar so a complete beginner finishes it feeling oriented on the whole topic. Each subsection is a 2-4 sentence summary that hands off to a cluster article via a contextual in-text link, not a sidebar widget. Aim for genuine standalone value plus the hub role.
Question of your own? Drop it in the chat.
Q: People keep saying "optimize for entities, not keywords." What does that actually mean in practice?
Short answer: an entity is a distinct thing search engines recognize and store in their knowledge graph: a person, brand, place, concept, product. Keywords are the words people type; entities are what those words refer to.
Optimizing for entities means making sure your page clearly establishes which thing it's about and how that thing relates to others, so the engine can place you on its mental map.
In practice three concrete moves:
— Name the entity explicitly and consistently (don't switch between "the platform," "it," and the brand name).
— Mention the related entities a reader would expect (a page on "link building" that never names anchor text, NoFollow, or outreach looks incomplete).
— Use sameAs links and schema to tie your entity to its canonical references.
Got a question? Send it in.
Short answer: an entity is a distinct thing search engines recognize and store in their knowledge graph: a person, brand, place, concept, product. Keywords are the words people type; entities are what those words refer to.
Optimizing for entities means making sure your page clearly establishes which thing it's about and how that thing relates to others, so the engine can place you on its mental map.
In practice three concrete moves:
— Name the entity explicitly and consistently (don't switch between "the platform," "it," and the brand name).
— Mention the related entities a reader would expect (a page on "link building" that never names anchor text, NoFollow, or outreach looks incomplete).
— Use sameAs links and schema to tie your entity to its canonical references.
Got a question? Send it in.
Reading rec
If this channel's your speed, @KeywordLabNumbers runs a sharp feed on keyword research. Different angle, same depth — worth a follow.
If this channel's your speed, @KeywordLabNumbers runs a sharp feed on keyword research. Different angle, same depth — worth a follow.
Q: I built a big cluster and now my pages are cannibalizing each other. What went wrong?
Short answer: you probably created multiple articles targeting the same search intent instead of distinct subtopics. Clusters fail when "best running shoes," "top running shoes," and "running shoes to buy" become three pages instead of one.
Cannibalization isn't caused by having many pages on a topic; it's caused by overlapping intent. Search engines pick one page per intent and bury the rest.
In practice:
— Map each article to a unique question or intent before writing.
— If two pages rank for the same query in Search Console, merge them or differentiate the angle sharply.
— Use the strongest page as the canonical for that intent and 301 the weaker duplicate into it, preserving the link.
Dealing with overlap? Send the details and I'll help you sort it.
Short answer: you probably created multiple articles targeting the same search intent instead of distinct subtopics. Clusters fail when "best running shoes," "top running shoes," and "running shoes to buy" become three pages instead of one.
Cannibalization isn't caused by having many pages on a topic; it's caused by overlapping intent. Search engines pick one page per intent and bury the rest.
In practice:
— Map each article to a unique question or intent before writing.
— If two pages rank for the same query in Search Console, merge them or differentiate the angle sharply.
— Use the strongest page as the canonical for that intent and 301 the weaker duplicate into it, preserving the link.
Dealing with overlap? Send the details and I'll help you sort it.
Q: How long before topical authority actually kicks in?
Short answer: usually 3-6 months for a focused cluster to gain real traction, but the curve is non-linear: little movement, then a jump once enough of the cluster is indexed and interlinked.
Authority isn't a switch; it's an accumulation of signals: coverage depth, internal links, external mentions, dwell, and crawl frequency. Engines need repeated crawls to recognize that you cover a topic comprehensively.
In practice: don't judge a cluster by week 6. Publish the core set close together (not one post a month), interlink them immediately, and give it a full quarter before evaluating. What predicts success early is whether your narrowest long-tail articles start ranking, that's the canary signaling the engine trusts your coverage.
Got a timeline question? Send it in.
Short answer: usually 3-6 months for a focused cluster to gain real traction, but the curve is non-linear: little movement, then a jump once enough of the cluster is indexed and interlinked.
Authority isn't a switch; it's an accumulation of signals: coverage depth, internal links, external mentions, dwell, and crawl frequency. Engines need repeated crawls to recognize that you cover a topic comprehensively.
In practice: don't judge a cluster by week 6. Publish the core set close together (not one post a month), interlink them immediately, and give it a full quarter before evaluating. What predicts success early is whether your narrowest long-tail articles start ranking, that's the canary signaling the engine trusts your coverage.
Got a timeline question? Send it in.
Q: Backlinks or topical coverage, which moves the needle more?
Short answer: they do different jobs, so it's the wrong either/or. Coverage and internal structure get you eligible to rank across a topic; external links push you up within competitive queries where everyone is already eligible.
A mental model that holds up: on-page topical depth sets your ceiling; links determine how much of that ceiling you reach. A thin site with great links ranks for a few terms and stalls. A deep site with no links ranks easily for long-tail but can't break the top 3 on money terms.
In practice: build the cluster first so links have something worth pointing at, then earn links to the pillar specifically and let your internal mesh distribute that authority to the cluster.
Which half are you stuck on? Send it in.
Short answer: they do different jobs, so it's the wrong either/or. Coverage and internal structure get you eligible to rank across a topic; external links push you up within competitive queries where everyone is already eligible.
A mental model that holds up: on-page topical depth sets your ceiling; links determine how much of that ceiling you reach. A thin site with great links ranks for a few terms and stalls. A deep site with no links ranks easily for long-tail but can't break the top 3 on money terms.
In practice: build the cluster first so links have something worth pointing at, then earn links to the pillar specifically and let your internal mesh distribute that authority to the cluster.
Which half are you stuck on? Send it in.
Q: Do orphan pages hurt my topical authority?
Short answer: yes, more than people think. An orphan page (one with no internal links pointing to it) is invisible to your topic structure. Search engines see an isolated page, not part of a coherent cluster, so it gets weak crawl priority and contributes nothing to your topic's overall signal.
Worse, orphans dilute perceived focus: you have content on the topic that isn't connected, so the engine can't tell you cover it systematically.
In practice:
— Crawl your own site (Screaming Frog, Sitebulb) and filter for pages with zero inlinks.
— Either link each orphan into the relevant cluster from contextually relevant articles, or, if it's off-topic and low value, remove or noindex it.
— Check your sitemap-vs-crawl gap; orphans often show in the sitemap but never get crawled organically.
Found orphans? Tell me how many and I'll help prioritize.
Short answer: yes, more than people think. An orphan page (one with no internal links pointing to it) is invisible to your topic structure. Search engines see an isolated page, not part of a coherent cluster, so it gets weak crawl priority and contributes nothing to your topic's overall signal.
Worse, orphans dilute perceived focus: you have content on the topic that isn't connected, so the engine can't tell you cover it systematically.
In practice:
— Crawl your own site (Screaming Frog, Sitebulb) and filter for pages with zero inlinks.
— Either link each orphan into the relevant cluster from contextually relevant articles, or, if it's off-topic and low value, remove or noindex it.
— Check your sitemap-vs-crawl gap; orphans often show in the sitemap but never get crawled organically.
Found orphans? Tell me how many and I'll help prioritize.
Q: What is "semantic relevance" really measuring?
Short answer: whether your content covers the concepts that genuinely belong to a topic, not whether it repeats a keyword. Modern engines use language models that understand meaning, so they evaluate whether the surrounding ideas match what a comprehensive page on that subject should contain.
A page about "espresso" that never mentions crema, tamping, grind size, or pressure reads as semantically shallow even if "espresso" appears 40 times. The related concepts are the signal.
In practice:
— Don't chase keyword density; chase concept coverage.
— Pull the vocabulary of the topic from the top-ranking pages and your own expertise, then make sure your draft genuinely addresses those concepts.
— Tools that show "missing terms" are proxies for missing concepts; use them as a checklist, not a stuffing list.
Got a question about semantics? Send it in.
Short answer: whether your content covers the concepts that genuinely belong to a topic, not whether it repeats a keyword. Modern engines use language models that understand meaning, so they evaluate whether the surrounding ideas match what a comprehensive page on that subject should contain.
A page about "espresso" that never mentions crema, tamping, grind size, or pressure reads as semantically shallow even if "espresso" appears 40 times. The related concepts are the signal.
In practice:
— Don't chase keyword density; chase concept coverage.
— Pull the vocabulary of the topic from the top-ranking pages and your own expertise, then make sure your draft genuinely addresses those concepts.
— Tools that show "missing terms" are proxies for missing concepts; use them as a checklist, not a stuffing list.
Got a question about semantics? Send it in.
Q: Does updating old cluster posts help topical authority, or should I just publish new ones?
Short answer: both, but refreshing your existing cluster usually beats adding more pages once the core is built. A topic's authority compounds when your established URLs stay current; decay on a pillar drags the whole cluster down.
New pages expand coverage. Updates protect coverage you already have. Past a point, the highest return is keeping the pillar and top cluster articles accurate, not endlessly widening.
In practice:
— Quarterly, pull the cluster's pages that lost clicks or impressions in Search Console and refresh those first.
— On a refresh, add genuinely new info or sections, don't just change the date.
— Re-link: when you update an article, check whether newer cluster posts should now link to it.
Deciding between expand vs refresh? Send your situation in.
Short answer: both, but refreshing your existing cluster usually beats adding more pages once the core is built. A topic's authority compounds when your established URLs stay current; decay on a pillar drags the whole cluster down.
New pages expand coverage. Updates protect coverage you already have. Past a point, the highest return is keeping the pillar and top cluster articles accurate, not endlessly widening.
In practice:
— Quarterly, pull the cluster's pages that lost clicks or impressions in Search Console and refresh those first.
— On a refresh, add genuinely new info or sections, don't just change the date.
— Re-link: when you update an article, check whether newer cluster posts should now link to it.
Deciding between expand vs refresh? Send your situation in.
Q: Should my topic cluster live in a subfolder or a subdomain?
Short answer: subfolder, almost always, for topical authority. Engines treat a subdomain as a partially separate site, so authority and topic signals don't flow between it and your main domain as freely.
A cluster's strength comes from concentrating related content and internal links in one connected structure. Splitting it onto blog.yoursite.com fragments that signal and forces the cluster to build trust from a weaker base.
In practice:
— Put clusters under a clear path like /topic/ with cluster articles at /topic/subtopic/.
— Reserve subdomains for genuinely distinct properties (app., docs., shop.) where mixing would confuse intent.
— If you're already on a subdomain and it's working, don't migrate impulsively, the move carries risk; weigh it carefully.
Weighing a structure decision? Send the details.
Short answer: subfolder, almost always, for topical authority. Engines treat a subdomain as a partially separate site, so authority and topic signals don't flow between it and your main domain as freely.
A cluster's strength comes from concentrating related content and internal links in one connected structure. Splitting it onto blog.yoursite.com fragments that signal and forces the cluster to build trust from a weaker base.
In practice:
— Put clusters under a clear path like /topic/ with cluster articles at /topic/subtopic/.
— Reserve subdomains for genuinely distinct properties (app., docs., shop.) where mixing would confuse intent.
— If you're already on a subdomain and it's working, don't migrate impulsively, the move carries risk; weigh it carefully.
Weighing a structure decision? Send the details.
Q: How does Google actually "know" I'm an authority on a topic?
Short answer: it infers it from patterns, not a single label. There's no "authority score" you can see, but several measurable signals stack up: breadth and depth of related content, how that content interlinks, external references that mention you alongside the topic, and engagement signals on those queries.
Think of it as a reputation the engine assembles from evidence. The more consistently your domain shows up answering questions within a topic, and the more others reference you in that context, the stronger the inference.
In practice the strongest tells you can influence:
— A connected cluster (not scattered posts).
— Co-occurrence: getting mentioned on other sites next to the topic's key entities.
— Ranking spread: when you rank for many long-tail terms in one topic, that breadth itself is a signal.
Question on this? Send it in.
Short answer: it infers it from patterns, not a single label. There's no "authority score" you can see, but several measurable signals stack up: breadth and depth of related content, how that content interlinks, external references that mention you alongside the topic, and engagement signals on those queries.
Think of it as a reputation the engine assembles from evidence. The more consistently your domain shows up answering questions within a topic, and the more others reference you in that context, the stronger the inference.
In practice the strongest tells you can influence:
— A connected cluster (not scattered posts).
— Co-occurrence: getting mentioned on other sites next to the topic's key entities.
— Ranking spread: when you rank for many long-tail terms in one topic, that breadth itself is a signal.
Question on this? Send it in.