Pillars & Clusters — the topical-authority architecture underneath the plan

Plain-English briefing on how content is structured into pillars, spokes and clusters — the shape AI search reads as genuine expertise. Written 24 July 2026. Last verified: 3 September 2026 (Agent 11 — Co-Kinetic Sites automatic related links folded in).

1. The point — why we do any of this at all

Historically, SEO taught clinics to write one page per keyword. Google would rank that page if the keyword matched. That model is dying.

AI search (ChatGPT, Perplexity, Google AI Overviews, Copilot) picks a source when the source demonstrates topical authority — not just a single page on the topic, but a whole cluster of interrelated pages showing depth. A clinic with one 800-word page on "neck pain" is invisible next to a clinic that has:

• A pillar page — a comprehensive, authoritative hub explaining the topic end to end
• Spokes — supporting pages each answering one specific patient question (What is chronic neck pain? / What treatment works? / When should I see someone? / How long does recovery take?)
• Reciprocal links between them — pillar linking out to spokes, spokes linking back

That structure signals to AI search: this clinic knows this topic, covers the sub-questions, and has named clinicians with credentials behind the content. Everything below is how we build that shape for a clinic automatically.

2. The building blocks

Cluster = a topical grouping — a folder for one theme. A Chronic Achilles Tendonitis cluster is a folder containing everything about that condition.

Pillar = the main hub page of the cluster: the long-form, authoritative, "start here" page. Its page type follows the topic — a condition cluster's pillar is a condition page; a service-oriented cluster's pillar is a service page. (The pillar for a condition cluster is typically the comprehensive "Causes, Diagnosis and Treatment"-style page.)

Spoke = a supporting page in the same cluster, narrower, answering ONE sub-question. A typical condition cluster carries 8–9 spokes across the patient journey:

Each spoke has a type (condition / treatment / service / blog) that determines which research pipeline and writing template produces it, and where it lives on the clinic's site. The spread across types is deliberate — it covers the patient's journey from "what's wrong with me?" through "what helps?" to "who do I book?"

Hub topic = the working title of the pillar. Cluster type = the kind of clinical grouping (condition / treatment / pathway). Status = active/inactive — only active clusters produce actions on a clinic's plan.

3. Where a clinic's clusters come from

A clinic doesn't get every cluster that exists — it gets the ones its own expertise justifies. The activation sources:

(1) A practitioner declares a niche. When a clinician completes their profile, they list their practice niches. Each declared niche activates a topic cluster for the clinic. This is the core principle of the whole architecture: clusters are anchored to real practitioner expertise. The platform will not build content the clinic has no one qualified to stand behind.

(2) The practice declares priority topics. The clinic can nominate up to three topics it wants to be known for; these activate or reinforce clusters the same way. Confirmed priority topics also earn reserved slots in the content plan: a confirmed priority not already covered is guaranteed its own plan item, carrying a priority badge.

(3) The assessment infers a niche. If the clinic's existing site shows deep de-facto specialisation the team didn't explicitly declare, the assessment can propose it — subject to the clinic's confirmation before anything activates. Nothing activates behind the customer's back.

Whichever source fires, the clinic gets a full cluster. How that cluster is furnished depends on whether the topic is in our curated library:

• Library match: we maintain a curated library of core clusters — each hand-built with a rich set of pre-designed spokes, per-spoke target questions, page-type assignments, priority weighting, and country awareness. A declared niche matching a library cluster activates it with all of that quality built in.
• No library match — an emergent cluster is built. If a practitioner declares something not yet in the library ("Visceral Osteopathy", "Clinical Pilates", a sub-specialism we haven't curated yet), the platform builds a complete cluster for that clinic on the fly — generating a full spoke set (typically 9 spokes across the same condition/treatment/service/blog spread) from the research banked for that practice. The clinic gets the same architecture either way; the library just gives curated topics a head start.

The library grows with the customer base. When the same topic keeps emerging independently across multiple clinics, that's the signal to curate it properly and promote it into the library — so future clinics activating that topic get the refined version. The library is a quality-curation layer that expands as we learn what real practices actually specialise in, not a ceiling on what the platform covers. Coverage is effectively unlimited from day one via the emergent mechanism.

4. How the plan uses clusters

Active clusters drive the content plan (see 02-content-plan.md for full detail). In short: a missing pillar for an active cluster emits a "create the pillar" action; a published pillar unlocks the cluster's spoke-creation actions; existing weak pages inside a cluster emit refresh actions. Every action competes on a scored merit basis for the plan's 15 slots, and the cluster's health (pillar quality, spoke coverage, internal linking) is computed and visible.

5. From plan action to published article

When the clinic clicks Create Content on a cluster action, the five-stage generation pipeline runs — research targeted at the spoke's specific question, named-author selection with optional clinical insight, country-native writing with verified real citations, an automated quality gate, then review and publish. The full pipeline is described in 04-research-and-content-generation.md.

On country specificity: the platform develops country-specific content specifications — clinical terminology, funding and referral context, regulatory framing — as we take on customers in new countries. Each supported country's clinics get content written natively for their healthcare context, not translated-from-elsewhere generics.

6. Internal cross-linking

Every generated article links to the clinic's other relevant pages, drawn from two pools: the clinic's existing site pages (known from the assessment crawl — works from day one) and previously generated pieces once they're live. As the clinic publishes, the clusters become densely interlinked — the precise structural signal AI engines read as topical authority. Detail in 05-publish-and-measure.md. For clinics on a Co-Kinetic Sites website this is fully automatic (live 27 Aug 2026): every page carries "related" links to the practice's other CCS pages (conditions ↔ treatments ↔ services ↔ articles), derived from stored relationships and shared topics, with no customer action needed; a page with nothing related simply shows no related rail.

7. Glossary

• Pillar — the main hub page of a cluster (long-form, authoritative; page type follows the topic).
• Spoke — a supporting page answering one sub-question; typed as condition / treatment / service / blog.
• Cluster — the topical folder containing one pillar plus its spokes.
• Hub topic — working title of the pillar.
• Cluster activation — a cluster becoming live for a specific clinic, via practitioner niche, declared practice priority, or confirmed inferred niche.
• Library cluster — a curated cluster with hand-built spoke seeds, available to any clinic whose expertise activates it.
• Emergent cluster — a complete cluster built on the fly for one clinic when its declared expertise isn't yet in the curated library.
• Cluster health — the computed measure of a cluster's completeness: pillar quality + spoke coverage + internal linking.
• Merit competition — plan candidates competing for the 15 plan slots on transparent scored merit.

8. A running example, end to end

1. A new clinic signs up. Its site is crawled during the AI Visibility Assessment; every page is inventoried, typed and scored.
2. The team completes their profiles. One practitioner declares a musculoskeletal niche; another declares vestibular rehabilitation. Both match curated library clusters, which activate with their full pre-designed spoke sets. A third practitioner declares a specialism not yet in the library — the platform builds a complete emergent cluster for it from the practice's banked research.
3. The clinic nominates a priority topic through onboarding, reinforcing one of the active clusters.
4. The strategy engine composes the 15-action plan. A missing pillar appears as a create action; its spokes queue behind it; two existing weak pages inside another cluster appear as refreshes.
5. The clinic works the plan: each Create Content click runs research → authorship with the matched practitioner's insight → country-native writing with verified citations → quality gate → Content Studio for review.
6. Each published piece joins the linking pool; subsequent articles link back to it; cluster health climbs; the next re-measure registers the improvement in the clinic's preserved score history.
7. Repeat. Every pass compounds the last.