Internal linking for AEO: topic clusters that compound

The cluster model, updated

The hub-and-spoke topic cluster model was invented for SEO circa 2016 and has been the default content-strategy framework ever since. It still works for AEO, but the wiring that made it effective for organic search is not identical to the wiring that makes it effective for AI citation. Two differences matter.

First, the anchor text conventions differ. Organic SEO has rewarded varied anchor text to avoid over-optimization penalties. AEO rewards specific, topical anchor text because the anchor signals to engines what is on the other side of the link.

Second, the cluster density expectations differ. Organic SEO typically recommends 3 to 5 links between every pair of pages in a cluster. AEO works fine with 1 to 2 links per pair, provided they are in the right places and with the right anchors. Over-linking is closer to neutral for AEO than for SEO.

Here is how to design a cluster that actually helps citation.

The basic structure

A topic cluster has three layers:

Pillar page

The comprehensive central page on the topic. 1,800 to 3,000 words. Introduces the topic, covers the main subtopics at a summary level, and explicitly links out to spoke pages for detailed coverage. Example: "What is AEO in 2026" is a pillar.

Spoke pages

The deeper, narrower pages that cover specific sub-topics. 800 to 1,500 words each. Each spoke answers one specific sub-question from the pillar. Spokes link back to the pillar and optionally to each other when topically adjacent. Example: "How to write llms-full.txt" is a spoke under the AEO pillar.

Supporting pages

Tangentially related content - news posts, case studies, team bios - that may reference the cluster but do not belong inside it structurally.

The cluster's gravity center is the pillar. The spokes derive authority from the pillar and, over time, push authority back to it through internal linking. Done right, the cluster compounds: each new spoke strengthens the pillar, the pillar strengthens every spoke, and the whole cluster becomes the go-to reference for the topic.

The wiring: what links where

Three link patterns matter, in order of importance.

1. Pillar to every spoke

The pillar should link to every spoke from its relevant section. Do not dump the links in a "related posts" footer; put them inline, in the section of the pillar where that spoke's topic comes up. Anchor text should be specific: "For more on FAQPage schema specifically, see when it lifts citations and when it backfires." The anchor tells the engine what the destination covers.

2. Every spoke to the pillar

Each spoke links back to the pillar once or twice, typically early in the post. Anchor text should reference the pillar topic: "This post is part of our larger guide to AEO in 2026." One link in the first paragraph and optionally one in the conclusion is enough.

3. Spokes to adjacent spokes

When spokes are topically close - FAQPage schema and HowTo schema, for example - link them to each other. Not every spoke pair needs a link; only when the topics naturally connect. Anchor text should be specific to the target spoke's topic.

The anchor text rule

AEO rewards specificity. Bad anchors:

• "Click here"
• "Read more"
• "Learn more about this"
• The destination page's title copy-pasted

Good anchors:

• "When to use FAQPage schema and when to skip it"
• "The 30-day content freshness rule"
• "How AI Overviews pick citations"

The rule: the anchor text should answer the question "what specific thing is on the other side of this link". Vague anchors waste the signal; specific anchors turn it into extractable context.

The two mistakes that unravel the cluster

1. The "related posts" footer dump

Many sites implement topic clusters by adding a "related posts" widget at the bottom of every post that auto-links to the 5 most-recent posts tagged with the same category. This produces the appearance of a cluster without the function.

Problems:

• Auto-generated related-post widgets produce generic anchors ("Read more", post titles with no context).
• The links are at the bottom of the page where the engine has least extraction budget left.
• The auto-generation often links posts that are not topically relevant because the tag is broad.

A cluster built on a related-posts widget is indistinguishable from no cluster at all. The engine sees the widget pattern, recognizes it as boilerplate, and discounts it.

The fix: inline links in the body with specific anchors, manually chosen. If that is too much per-post work, build a shortcode system where authors can insert cluster links with a slug reference, and the system renders the specific anchor.

2. The over-dense cluster

The opposite mistake: a team decides that topic clusters are the answer and links every post to every other post in the cluster via 10+ inline links. The post becomes hard to read, the signal dilutes, and the engine starts treating the linking as spammy.

The fix: 2 to 5 cluster links per post, placed in the sections where they are topically relevant. Quality over quantity.

Designing a new cluster from scratch

If you are starting a cluster today, here is the order of operations we recommend.

1. Pick the pillar topic. One central question your audience asks. "What is AEO?" is a pillar; "Does FAQPage schema work?" is a spoke. 2. Write the pillar first. 1,800 to 2,500 words covering the main subtopics at summary level. Leave placeholder links where spokes will eventually live. 3. List 5 to 10 spoke topics. Each one a sub-question the pillar touches but does not fully answer. 4. Write spokes one at a time. Each spoke gets direct-answer lede, full schema, FAQ tail, and two links: one to the pillar, one or two to adjacent spokes. 5. Return to the pillar and fill in the real spoke links. Replace placeholders with inline links to the spoke URLs with specific anchor text. 6. Ship. Let the first crawl cycle pass.

This process takes 4 to 8 weeks for a typical cluster, assuming one writer and one topic. After the first cluster is live and performing, the pattern is repeatable; later clusters often go faster because the template is established.

Maintaining clusters over time

Clusters decay if neglected. Three maintenance rhythms:

Quarterly: check pillar freshness

Every 90 days, reread the pillar. Is anything stale? Any new sub-topic that has come up since the pillar was written? Either update the pillar or add a new spoke and link to it from the pillar.

As-needed: update linking

When you publish a new spoke, add a link from the pillar. When you update a spoke, recheck whether the pillar's description of that spoke's topic is still accurate.

Annual: full audit

Once a year, pull every post in every cluster, check all internal links resolve, check schema is still valid, check dates are current. Refresh anything that has aged past its sell-by date.

A cluster dashboard view

For teams running multiple clusters, it helps to maintain a lightweight dashboard (spreadsheet is fine) showing:

• Cluster name
• Pillar URL and date of last substantive update
• Spoke URLs and their dates
• Recent citation events (from your monitoring)
• Open maintenance items

A weekly 15-minute review of this dashboard catches problems before they become visible. Most teams should not maintain more than 3 to 5 active clusters at once; past that, attention spreads too thin and individual clusters weaken.

Run a free audit to see which clusters on your site are well-linked and which are not

How Citevera detects cluster structure

The audit looks at internal-link density, anchor-text specificity, and entity consistency across pages. Sites that have built clean clusters show characteristic signatures: pillar pages with many inbound internal links using specific anchors, spoke pages with consistent reference back to a single pillar, and clear entity language across the set. Sites that have not built clusters show flat linking patterns with generic anchors and no discernible hub.

The audit does not score cluster design directly - that is a content-strategy decision, not a single-page signal - but it does surface the mechanical fingerprints of good linking that let teams diagnose where their clusters are working and where they are not.

Frequently asked questions about internal linking for AEO

How do I know if my cluster is working?

Monitor citation across 5 to 10 target queries in your topic space. If your pillar is being cited on the main query and at least one or two spokes are cited on their sub-queries, the cluster is functioning. If only the pillar is cited, the spokes are probably not being surfaced; usually that means the spokes need stronger direct-answer ledes.

Should I link from every paragraph to somewhere?

No. Over-linking is distracting to humans and provides little additional value to engines. 2 to 5 substantive internal links per post is the sweet spot.

What about linking across different clusters?

Cross-cluster links are fine when the topics connect. The rule is the same: specific anchor, topically relevant. A post in the "AEO" cluster can link to a post in the "schema" cluster without disrupting either.

Should I noindex spokes so they do not compete with the pillar?

No. Spokes should be indexed. They serve their own queries; the pillar serves the umbrella query. Both can rank and both can be cited without competing.