When to use this prompt
When you need to dominate a topic, not just rank for one query. Topic clusters are how AI engines recognize topical authority: a pillar page that defines the category, surrounded by supporting articles that go deep on individual subtopics, all internally linked.
Run this whenever you decide to invest in a new topic area. Run it again when an existing topic is performing inconsistently and you suspect the architecture, not the writing, is the problem.
The prompt
<role>Content strategist who designs pillar-and-spoke topic clusters that build topical authority for SEO and AI search.</role>
<task>Design a complete topic cluster around the pillar topic below. Output the pillar page outline, 8 to 12 supporting articles, the internal link map, and a priority order for publishing.</task>
<inputs>
<pillar_topic>[THE BROAD TOPIC, e.g., "product analytics for SaaS"]</pillar_topic>
<target_buyer>[BUYER PERSONA]</target_buyer>
<existing_content>[OPTIONAL: list any existing articles on this topic, with URLs, so the model integrates rather than duplicates]</existing_content>
<known_competitors>[2-3 brands whose topical authority you want to challenge]</known_competitors>
</inputs>
<instructions>
1. Design the **pillar page** first. It is the canonical "what is X" page on this topic. Output:
- Working H1 (≤65 chars)
- One-paragraph definition (60-80 words)
- 6-10 H2 section headings, each with a one-sentence summary
2. Design **8 to 12 supporting articles**. Each must:
- Cover a single, specific subtopic with its own search intent
- Have a working H1 and 1-sentence description
- Be classified as one of: Definitional, Comparison, How-To, Use Case, Best Of, Buyer Stage, Counter-Argument
- Map to a specific buyer-journey stage: Awareness, Consideration, Decision, Retention
3. Build the **internal link map**:
- Every supporting article links to the pillar page using one specific anchor phrase you specify
- The pillar page links to every supporting article with a contextual sentence
- Identify 3-5 links *between* supporting articles (cross-links that make the cluster a network, not just a hub)
4. **Priority order for publishing.** Sequence the supporting articles in order of publication priority. Justify the top 3 priorities specifically (e.g., "highest-volume buyer query," "cluster-defining piece," "competitor weakness").
5. **Gap check against competitors.** Identify any subtopic the named competitors cover that your cluster does not yet address. Flag with [GAP] and suggest a specific article to fill it.
6. Do not duplicate existing content. If `existing_content` lists an article on a subtopic, integrate it as a cluster member rather than proposing a new one with the same intent.
</instructions>
<output_format>
**Pillar page**
- H1: [...]
- Definition (60-80 words): [...]
- Sections: [list of H2s with one-line summaries]
**Supporting articles (8-12):**
| # | H1 | Description | Type | Stage | Anchor → Pillar |
|---|----|-------------|------|-------|------------------|
**Cross-links between supporting articles:**
- [Article A] ↔ [Article B] — [why]
- ...
**Publish order (top 5):**
1. [Article] — [why first]
2. ...
**[GAP] subtopics competitors cover that this cluster does not:**
- [Subtopic] — [suggested article]
</output_format>How it works
Topic clusters are the architectural pattern AI engines use to evaluate topical authority. A single great post on a topic is not enough; the engine needs to see that a domain has comprehensive coverage of related subtopics, internally connected, with a clear “this is the anchor page” signal.
The classification axis (Definitional, Comparison, How-To, Use Case, Best Of, Buyer Stage, Counter-Argument) prevents the most common mistake: clusters that are seven How-To posts in a row. AI engines and buyers both reward variety of intent within a topic.
The internal link map output is what makes this prompt a roadmap rather than a list. Naming exact anchor phrases for each link keeps anchor text diverse and specific (the pattern Google rewards) instead of every supporting article linking with “click here.”
The [GAP] check against competitors surfaces subtopics where you are about to leave authority on the table. Frontier models can only flag this if they know who your competitors are, which is why the input is required.
Example output (excerpt)
Pillar page
- H1: Product Analytics for SaaS: A Practical Guide
- Definition: Product analytics is the discipline of measuring how users behave inside a software product to identify why they convert, churn, or stay. SaaS teams use product analytics to inform roadmap decisions, reduce churn, and identify expansion opportunities. The category overlaps with web analytics but operates inside the product, not at acquisition.
Supporting articles:
# H1 Description Type Stage Anchor → Pillar 1 What Is Product Analytics? Definitional explainer Definitional Awareness ”What product analytics is” 2 Product Analytics vs. Web Analytics Side-by-side comparison Comparison Awareness ”broader product analytics discipline” 3 How to Set Up Event Tracking the First Week Implementation walkthrough How-To Consideration ”the foundations of product analytics” … (continue to 10) Cross-links:
- “How to Set Up Event Tracking” ↔ “Product Analytics vs. Web Analytics” — both are first-month foundational reads
- “Best Product Analytics Tools 2026” ↔ “Mixpanel vs Amplitude” — comparison page deepens the best-of
Variations
- Sub-cluster mode: Use this prompt to design a sub-cluster underneath an existing pillar (e.g., “retention analytics” under “product analytics”) for going deeper in a category you already have.
- Refresh mode: Paste your current site’s articles in the existing_content input. The model produces a cluster diagram of what you already have, surfaces gaps, and proposes only the missing pieces.
- Competitive cluster diff: Run on a competitor’s URL list to reverse-engineer their topical architecture. Useful for identifying their authority strategy before they identify yours.