Topical Authority: depth, breadth, and the hub-and-spoke pattern

A comprehensive installation and audit reference for engineering topical authority into a site's architecture. Topical authority is the property that makes Google and AI engines treat a site as the…

The Operational Playbook for Earning Recognition as the Authority on a Topic Cluster

A comprehensive installation and audit reference for engineering topical authority into a site's architecture. Topical authority is the property that makes Google and AI engines treat a site as the canonical reference for a defined topic. Built through deliberate design of pillar pages, cluster pages, link topology, keyword-to-page mapping, and cannibalization discipline. This document specifies how to define the topics a site should own, how to architect the pages and links that earn ownership, how to detect and resolve conflicts that erode it, and how to audit against the topical authority signal. Dual purpose: installation manual and audit document.

Cross stack implementation note: code samples are plain HTML for clarity. For React, Vue, Svelte, Next.js, Nuxt, SvelteKit, Astro, Hugo, 11ty, Remix, WordPress, Shopify, and Webflow equivalents, see framework-cross-stack-implementation.md. For pure client rendered SPAs (no SSR/SSG) see framework-react.md. For Tailwind specific concerns see framework-tailwind.md.

1. Document Purpose and How to Use This Document

1.1 What This Document Is

The canonical operational reference for engineering topical authority. Multiple existing frameworks reference topical authority as a prerequisite or consequence (framework-hcs.md, framework-infogain.md, framework-entitysalience.md). None operationalize it. This is that playbook.

The unit of competition in 2026 search is no longer the page. It is the topical cluster. A site with 18 interconnected articles covering a topic at depth outranks a site with one well written 5,000 word guide, holds rankings approximately 2.5 times longer, and earns approximately 3.2 times the AI citation rate (HireGrowth 2025, Digital Elevator 2026). ALM Corp's December 2025 core update analysis found sites with 10 to 15 supporting articles per pillar gained 23 percent average organic visibility; flat-architecture sites lost share regardless of individual page quality.

This document specifies how to identify the 3 to 7 topics a site should own, how to architect pillar and cluster pages, how to assign keywords without cannibalization, how to detect and resolve conflicts, and how to audit topical authority site wide.

1.2 Three Operating Modes

Mode A, Install. Build topical authority architecture on a new or existing site. Follow Sections 2 through 14 in order.

Mode B, Audit. Evaluate an existing site for topical authority strength and cannibalization debt. Skip to Section 13.

Mode C, Hybrid. Audit first, then install for failing items.

1.3 How Claude Code CLI Should Consume This Document

1. Read Section 2 and collect client variables.
2. Run Section 13 audit on existing site to baseline current state.
3. Apply Section 4 topical map definition.
4. Build pillar pages per Section 5, cluster pages per Section 6.
5. Install internal link topology per Section 7.
6. Run cannibalization detection per Section 9 and resolve.
7. Run saturation analysis per Section 10 to identify gap pages.
8. Apply Section 14 maintenance cadence.

1.4 Conflict Resolution Rules

1.5 Required Tools

• Google Search Console for query-to-page mapping, cannibalization detection, impression baselines
• Screaming Frog or Sitebulb for internal link graph extraction and orphan detection
• Ahrefs Site Explorer or Semrush for competitor topical maps and keyword universe
• Surfer SEO, Frase, or Clearscope for SERP coverage and gap analysis
• Spreadsheet (Sheets or Excel) for the cannibalization matrix and topic-to-keyword map
• Graphviz, yEd, or Gephi for visualizing the link topology (optional, useful for clusters above 30 pages)

1.6 Relationship to Neighboring Frameworks

This framework covers the architectural layer: how to define topics, structure pillars and clusters, and resolve cannibalization. Keyword research mechanics live in framework-keywordresearch.md. Generic internal linking mechanics live in framework-internallinking.md. Content quality requirements live in framework-contentfirst.md, framework-hcs.md, and framework-infogain.md. Entity declarations live in framework-entitysalience.md and framework-knowledgegraph.md. The AI citation surface lives in framework-aioverviews.md and framework-aicitations.md. This document is what those frameworks point to when topical architecture is the question.

2. Client Variables Intake

# TOPICAL AUTHORITY FRAMEWORK CLIENT VARIABLES

# --- Business and Site Identity (REQUIRED) ---
business_name: ""
primary_domain: ""
business_industry: ""
business_age_years: 0
total_indexed_pages: 0

# --- Topical Focus Baseline (REQUIRED) ---
declared_primary_topics: []          # 3 to 7 topics the site genuinely owns
declared_secondary_topics: []        # Meaningful but not authoritative coverage
out_of_scope_topics: []              # Topics the site does not cover
topical_focus_documented_publicly: false

# --- Existing Architecture (REQUIRED) ---
existing_pillar_pages: []
average_cluster_pages_per_pillar: 0
orphan_pillar_pages: 0               # Fewer than 5 cluster pages linking to them
orphan_cluster_pages: 0              # No pillar to link back to
cross_silo_link_density: ""          # "high", "medium", "low"
existing_url_taxonomy: ""            # "topic_based", "date_based", "category_flat", "mixed"

# --- Cannibalization Baseline (REQUIRED for audit) ---
known_cannibalization_pairs: 0
gsc_queries_with_multipage_impressions: 0
gsc_queries_with_position_volatility: 0

# --- Topic to Keyword Mapping (REQUIRED) ---
topic_to_keyword_map_exists: false
keyword_to_url_assignment_exists: false
priority_pillar_keywords: []
priority_cluster_keywords: {}

# --- SERP Coverage Baseline (RECOMMENDED) ---
target_pillar_queries: []
top_10_sub_questions_per_pillar: {}
saturation_coverage_percent: {}

# --- Internal Link Density (REQUIRED for audit) ---
average_internal_links_per_pillar: 0
average_internal_links_per_cluster: 0
sibling_link_density_within_cluster: ""

# --- Capacity (REQUIRED) ---
content_creation_rate_per_month: 0
content_team_size: 0
domain_expertise_areas: []
willing_to_remove_off_topic_content: false

# --- Cross Framework Prerequisites (REQUIRED) ---
contentfirst_score: 0                # Out of 30
hcs_score: 0                         # Out of 54
infogain_distribution_percent: 0
schema_core_graph_present: false

Topical authority work cannot deliver compounding lift until contentfirst_score is at least 22, hcs_score is at least 41, and the schema core graph is server rendered. Sites failing those dependencies route back to those frameworks first. Building a pillar-cluster architecture on a substrate that AI engines cannot parse wastes the work.

3. What Topical Authority Is

3.1 Definition

Topical authority is the site-wide property that causes Google's ranking systems, AI Overview synthesis, and AI Mode citation to treat a site as the canonical reference for a defined topic. It is measured by a composite of: content density on the topic, depth per sub-topic, internal link concentration around hub pages, entity declarations across topical content, citation patterns from external sites, and consistency of coverage scope.

Topical authority is a site-level signal, not page-level. A single excellent article does not establish authority. Eighteen interconnected articles on a topic do. The operational meaning across Google's documentation and patent literature is consistent: the systems trust the site's coverage of the topic.

Topical authority is distinct from domain authority (Moz DA, Ahrefs DR, Semrush AS) which measures aggregate backlink strength across all topics. SearchAtlas's 2026 DA vs TA analysis found pages with strong topical authority on a sub-topic outrank higher DA sites lacking topical density approximately 64 percent of the time.

3.2 What Google Measures

Converging signals reverse engineered from patent literature, Search Liaison statements, and large-sample correlation studies.

Content density. ALM Corp's December 2025 analysis found sites with 10 to 15 supporting articles per pillar gained 23 percent visibility. Sites with fewer than 5 supporting articles showed no measurable lift.

Entity declarations across pages. Consistent entity declaration using schema, internal links, and visible text builds a coherent entity graph. See framework-entitysalience.md.

Internal link concentration on hub pages. When most pages within a topic link back to the same pillar, that pillar accumulates equity and topical centrality. Princeton GEO study (SIGKDD 2024) found pages with at least three inbound topical internal links earn higher AI Overview citation rates.

Citation patterns from external sites. Authoritative sites linking to or mentioning the site specifically for the topic confirm reference status. AI engines weight this heavily.

Consistency of coverage scope. Publishing across foundational, intermediate, advanced, edge case, comparison, and application sub-domains signals completeness. Patchy coverage signals partial authority.

Temporal consistency. Compounds over 18 to 36 months. Quick wins exist (Section 11); the durable advantage compounds annually.

3.3 The 2026 State

Three forces have raised the stakes on topical authority.

The December 2025 core update. ALM Corp's analysis found sites with deep content clusters gained 23 percent average visibility. Raptive's December 2025 quality analysis found the update rewarded sites where less than 7 percent of pages had 500 words or fewer and penalized sites where over 32 percent of content was thin. The signature shift: cluster level evaluation outweighed individual page quality. A great article on a flat site lost to a good article on a deeply clustered site.

AI Overview citation decoupling. Surfer SEO December 2025 study of 173,902 URLs found 68 percent of AI Overview citations come from outside the top 10 organic. Ahrefs February 2026 study of 863,000 keywords found only 38 percent of AIO cited pages also rank top 10, down from 76 percent in mid 2025. Digital Elevator's 2026 correlation study found topical authority has r equals 0.41 correlation with AI Overview citation, outperforming domain authority (r squared equals 0.032) and raw backlinks (r squared equals 0.038). Pages ranking 6 through 10 with strong topical authority earn citation approximately 2.3 times more often than number 1 pages with weak topical authority.

Query fan out. AI Overview and AI Mode generate 8 to 16 sub queries per head query (see framework-aioverviews.md Section 4.1). Pages are 161 percent more likely to be cited when they rank for both the main query and at least one related fan-out query. Pages ranking for 4 or more related queries are cited approximately 3 times more often. Topical authority is now the primary lever for multi-sub-query citation.

3.4 Four Pillars Context

Topical authority is foundational across all four pillars of the visibility architecture. SEO (classic ranking) rewards topical authority via the December 2025 cluster effect. AEO (Answer Engine Optimization) rewards topical authority because answer engines prefer sources with breadth of coverage. AIO (AI Overview Optimization) rewards topical authority via citation decoupling and Information Gain. GEO (Generative Engine Optimization, broader AI citation across ChatGPT, Claude, Perplexity, Gemini) rewards topical authority because AI engines select sources by topical coherence. A topical authority deficit shows up simultaneously across all four. A strength compounds across all four. One of the highest leverage frameworks in the stack.

3.5 Why Topical Authority Compounds

Cluster equity transfer. Each new cluster page flows link equity to the pillar. The pillar's ranking strength grows with the cluster, and the pillar's strength lifts every cluster page via reciprocal flow. Citation acquisition acceleration. External sites researching the topic encounter the site repeatedly through different sub-topic searches. A site cited once becomes more likely to be cited again; the curve is convex. AI engine memory. AI engines build implicit topical models over multiple crawl cycles. Once identified as a topical reference, a site is preferentially surfaced for that topic on future queries, observable in citation patterns across ChatGPT, Claude, and Perplexity over rolling 6 month windows.

4. Defining the Topical Map

4.1 The 3 to 7 Topic Rule

Most sites cannot sustain authority on more than 3 to 5 topics. Some stretch to 7 if the team is large and the topics are tightly adjacent. Beyond 7, the site dilutes resources and ends up shallow on all of them.

The rule applies to primary topics where the site is genuinely the authority. Secondary topics (meaningful but not authoritative coverage) can exist alongside, but primary topics define the architecture. Cross reference framework-hcs.md Section 6.1.1.

4.2 Selecting Topics the Site Can Own

For each candidate topic, run two qualifications.

Authority qualification. Does the team have demonstrable expertise (credentials, years of practice, original research capacity)? Has the site published meaningful content on this topic for at least 12 months, or is the team committing to do so? Is the topic central to the business's actual offerings, audience, or mission? Can the team produce Information Gain on this topic regularly (see framework-infogain.md)? Are there 10 to 25 sub topics the team can cover at depth?

Market qualification. Is there meaningful search volume on the topic and its sub topics? Is the competitive set within reach (not all DR 90 plus institutional sources)? Are there clear sub-topic gaps to fill? Are AI engines currently citing weak sources for this topic, indicating a gap to capture?

Topics passing both qualifications become primary. Topics passing market but not authority become secondary or out-of-scope. Topics passing authority but not market are personal interest content and should not anchor the topical map.

4.3 The Topical Map Tree

For each primary topic, build the tree.

PILLAR TOPIC: [Topic Name]
|
+-- Sub Topic 1
|   +-- Foundational: [keyword]
|   +-- Intermediate: [keyword]
|   +-- Advanced: [keyword]
|   +-- Edge case: [keyword]
|   +-- Comparison: [keyword]
|
+-- Sub Topic 2
|   +-- Foundational
|   +-- Application
|   +-- Failure modes
|
+-- Sub Topic 3
    +-- ...

A typical pillar tree has 3 to 6 sub topics, each with 3 to 6 cluster page entries, producing 12 to 30 cluster pages per pillar. Smaller (8 to 15 cluster pages) works for narrower topics. Larger trees should be split into two pillars.

4.4 Topic Map Format

A topical map is a working document. Spreadsheet or markdown file in the team knowledge base. Suggested columns.

This is the single source of truth for content production, link discipline, and audit. Every page maps to a single row. Every row maps to a unique URL. No row competes with another for the same query.

4.5 Visible Topical Map on Site

Publish a stripped down version of the topical map at /topics/ or as part of the About page.

<section class="site-topical-map">
  <h2>What This Site Covers</h2>
  <p>We cover {{N}} primary topics deeply. We do not cover everything.</p>
  <article class="primary-topic">
    <h3><a href="/topics/{{TOPIC_1_SLUG}}/">{{TOPIC_1_NAME}}</a></h3>
    <p>{{ONE_SENTENCE_AUTHORITY_CLAIM}}</p>
    <ul><li><a href="/topics/{{TOPIC_1_SLUG}}/sub-1/">{{SUB_TOPIC_1}}</a></li></ul>
  </article>
  <section class="topics-not-covered">
    <h3>Topics We Do Not Cover</h3>
    <ul>
      <li>{{ADJACENT_TOPIC_1}}: see {{TRUSTED_SOURCE_1}}</li>
    </ul>
  </section>
</section>

The "topics we do not cover" section signals editorial discipline, reinforces topical focus for readers and AI engines, and earns goodwill from adjacent sources cited.

5. Pillar Pages

A pillar page is the comprehensive hub on a primary topic. It is the canonical reference URL the site claims authority for on the topic's head query.

5.1 Pillar Page Anatomy

Every pillar page contains the following sections in this order.

1. H1 and lede. H1 names the topic. Lede (40 to 75 words) defines the topic and states what the page covers. See framework-aioverviews.md Section 6.1.
2. Authority signal. 100 to 200 words answering "why is this site the authority on this topic?" Team credentials, years of coverage, original research, operational scope. AI engines and quality raters both read this.
3. Topic overview. 400 to 800 words. Not a glossary, not a definition. A reader who reads only the overview should leave with a working understanding of the topic's shape, sub-domains, and key concepts.
4. Sub topic navigation with cluster page links. The structural heart of the pillar. Each sub topic gets a heading and brief description, with links to cluster pages.
5. Original perspective or methodology. The site's distinctive approach. This is where Information Gain lives on the pillar.
6. Frequently asked questions. 5 to 12 questions covering common entry-point queries. FAQPage schema mirrors visible content per framework-schema.md.
7. Related pillars. Sparse links (2 to 5) to other primary topic pillars.
8. Author and reviewer. Visible byline with credentials. For YMYL pillars, visible reviewer credit per framework-ymyl.md.
9. Last updated date. Visible dateModified and schema dateModified, reflecting substantive updates per framework-hcs.md Section 9.6.

5.2 Pillar Page Length

Typically 3,000 to 6,000 words. Inmotion Marketing's 2026 pillar analysis found pillars in the 3,000 to 5,000 word range outperformed shorter and longer variants on the head query, controlling for cluster density. Length is a consequence of comprehensive coverage, not a target. Padding fails HCS criteria per framework-hcs.md Section 9.4.

5.3 Pillar Page Template

<article class="pillar-page" itemscope itemtype="https://schema.org/CollectionPage">
  <header>
    <h1>{{TOPIC_NAME}}: Complete Coverage</h1>
    <p class="lede">{{TOPIC_NAME}} is {{DEFINITION_40_TO_75_WORDS}}. This guide covers {{SUB_TOPICS}}.</p>
    <div class="article-byline">
      <p>By <a href="/authors/{{AUTHOR_SLUG}}/" rel="author">{{AUTHOR_NAME}}</a>, {{CREDENTIAL}}</p>
      {{REVIEWER_IF_YMYL}}
      <time datetime="{{PUBLISHED}}">Published {{PUBLISHED_HUMAN}}</time>
      <time datetime="{{UPDATED}}">Updated {{UPDATED_HUMAN}}</time>
    </div>
  </header>

  <section class="authority-claim">
    <h2>Why We Cover {{TOPIC_NAME}}</h2>
    <p>{{100_TO_200_WORD_AUTHORITY_STATEMENT}}</p>
  </section>

  <section class="topic-overview">
    <h2>{{TOPIC_NAME}}: The Working Overview</h2>
    <p>{{400_TO_800_WORD_OVERVIEW}}</p>
  </section>

  <section class="sub-topic-hub">
    <h2>Complete Coverage</h2>
    <section>
      <h3>Foundations</h3>
      <ul>
        <li><a href="/{{TOPIC_SLUG}}/{{CLUSTER_1_SLUG}}/">{{CLUSTER_1_TITLE}}</a></li>
        <li><a href="/{{TOPIC_SLUG}}/{{CLUSTER_2_SLUG}}/">{{CLUSTER_2_TITLE}}</a></li>
      </ul>
    </section>
    <section>
      <h3>Application</h3>
      <ul>
        <li><a href="/{{TOPIC_SLUG}}/{{CLUSTER_3_SLUG}}/">{{CLUSTER_3_TITLE}}</a></li>
      </ul>
    </section>
    <section>
      <h3>Comparison and Choice</h3>
      <ul>
        <li><a href="/{{TOPIC_SLUG}}/{{CLUSTER_4_SLUG}}/">{{CLUSTER_4_TITLE}}</a></li>
      </ul>
    </section>
    <section>
      <h3>Edge Cases and Failure Modes</h3>
      <ul>
        <li><a href="/{{TOPIC_SLUG}}/{{CLUSTER_5_SLUG}}/">{{CLUSTER_5_TITLE}}</a></li>
      </ul>
    </section>
  </section>

  <section class="distinctive-perspective">
    <h2>Our Framework on {{TOPIC_NAME}}</h2>
    <p>{{ORIGINAL_PERSPECTIVE_400_TO_800_WORDS}}</p>
  </section>

  <section class="pillar-faq">
    <h2>Common Questions</h2>
    <details><summary>{{QUESTION_1}}</summary><p>{{ANSWER_1}}</p></details>
    <details><summary>{{QUESTION_2}}</summary><p>{{ANSWER_2}}</p></details>
  </section>

  <section class="related-pillars">
    <h2>Related Topics We Cover</h2>
    <ul>
      <li><a href="/topics/{{OTHER_PILLAR_SLUG}}/">{{OTHER_PILLAR_NAME}}</a></li>
    </ul>
  </section>
</article>

5.4 Pillar Page Schema

{
  "@type": "CollectionPage",
  "@id": "https://example.com/topics/{{topic-slug}}/#webpage",
  "url": "https://example.com/topics/{{topic-slug}}/",
  "name": "{{TOPIC_NAME}}: Complete Coverage",
  "isPartOf": {"@id": "https://example.com/#website"},
  "about": {"@type": "Thing", "name": "{{TOPIC_NAME}}", "sameAs": "{{WIKIDATA_URL}}"},
  "datePublished": "{{PUBLISHED}}",
  "dateModified": "{{UPDATED}}",
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": [
      {"@type": "ListItem", "position": 1, "url": "https://example.com/{{topic-slug}}/{{cluster-1}}/", "name": "{{CLUSTER_1_TITLE}}"},
      {"@type": "ListItem", "position": 2, "url": "https://example.com/{{topic-slug}}/{{cluster-2}}/", "name": "{{CLUSTER_2_TITLE}}"}
    ]
  }
}

The CollectionPage type signals a hub page aggregating related content. The ItemList enumerating cluster pages makes the cluster relationship explicit in schema, reinforcing the visible link structure. Pair with FAQPage schema mirroring the visible Q-and-A per framework-schema.md.

5.5 Pillar Page Minimum Cluster Density

A pillar is hollow until it has at least 5 cluster pages linking to it. Below 5, the page is functionally a long form article, not a pillar. The target range is 8 to 15 cluster pages per pillar (per multiple 2025 to 2026 topic cluster studies). Beyond 25, the pillar typically benefits from splitting into two adjacent pillars.

6. Cluster Pages

Cluster pages cover specific sub topics within the pillar. Each targets one or two long tail queries, links back to the pillar, and may link to sibling cluster pages within the same topic.

6.1 Cluster Page Anatomy

1. H1 and lede. H1 names the specific sub topic. Lede answers the target query in 40 to 75 words.
2. Pillar context link. Within the first 200 words, a contextual link to the parent pillar with descriptive anchor text. The load-bearing back-link.
3. Direct answer to target query. Substantive content per framework-aioverviews.md Section 6.3 (answer-first under every H2).
4. Sibling cluster page links. 2 to 5 contextual links to siblings within the same pillar. In prose, not as a "related articles" appendix.
5. Information Gain contribution. Per framework-infogain.md, the page must contribute something not in the top 10 for the target query.
6. Author and dates. Visible byline. Visible dateModified.

6.2 Cluster Page URL Structure

Recommended pattern: /topics/{{pillar-slug}}/{{cluster-slug}}/ or flatter /{{pillar-slug}}/{{cluster-slug}}/. The flat pattern is preferred when the pillar slug is recognizable as a topic name. The nested pattern is preferred for sites with mixed content types (blog plus product plus topic hubs) where namespace isolation matters. Anti pattern: dating cluster URLs (/2026/05/{{cluster-slug}}/). Date-based URLs disconnect the page from the topic and complicate refresh cycles. See framework-internallinking.md.

6.3 Cluster Page Template

<article class="cluster-page" itemscope itemtype="https://schema.org/Article">
  <header>
    <h1>{{SPECIFIC_SUB_TOPIC_TITLE}}</h1>
    <p class="lede">{{40_TO_75_WORD_DIRECT_ANSWER}}</p>
    <nav aria-label="Breadcrumb">
      <ol>
        <li><a href="/">Home</a></li>
        <li><a href="/topics/">Topics</a></li>
        <li><a href="/topics/{{pillar-slug}}/">{{PILLAR_NAME}}</a></li>
        <li aria-current="page">{{SUB_TOPIC}}</li>
      </ol>
    </nav>
    <div class="article-byline">
      <p>By <a href="/authors/{{author}}/" rel="author">{{AUTHOR}}</a>, {{CREDENTIAL}}</p>
      <time datetime="{{PUBLISHED}}">Published {{PUBLISHED_HUMAN}}</time>
      <time datetime="{{UPDATED}}">Updated {{UPDATED_HUMAN}}</time>
    </div>
  </header>

  <section class="pillar-context">
    <p>This article is part of our complete guide on <a href="/topics/{{pillar-slug}}/">{{PILLAR_NAME}}</a>. For the foundations, see <a href="/topics/{{pillar-slug}}/{{sibling-foundational}}/">{{SIBLING_FOUNDATIONAL_TITLE}}</a>.</p>
  </section>

  <section class="content-body">
    <h2>{{H2_QUESTION_1}}</h2>
    <p>{{ANSWER_FIRST_PARAGRAPH_40_TO_75_WORDS}}</p>
    <p>{{SUPPORTING_DETAIL}}</p>
    <p>For more on {{ADJACENT_SUB_TOPIC}}, see <a href="/topics/{{pillar-slug}}/{{sibling-slug}}/">{{SIBLING_TITLE}}</a>.</p>

    <h2>{{H2_QUESTION_2}}</h2>
    <p>{{ANSWER_FIRST_PARAGRAPH}}</p>
  </section>

  <aside class="information-gain-marker">
    <h3>What This Article Adds</h3>
    <p>{{ORIGINAL_CONTRIBUTION_PER_INFOGAIN}}</p>
  </aside>

  <footer>
    <h2>Continue with {{PILLAR_NAME}}</h2>
    <ul><li><a href="/topics/{{pillar-slug}}/{{next-cluster}}/">{{NEXT_CLUSTER_TITLE}}</a></li></ul>
    <p><a href="/topics/{{pillar-slug}}/">Return to the {{PILLAR_NAME}} pillar</a></p>
  </footer>
</article>

6.4 Cluster Page Length

1,200 to 2,500 words typical. Long enough for substantive coverage, short enough to stay focused on a single sub topic. Above 4,000 words is often a misclassified pillar candidate. Under 800 is usually thin content per framework-hcs.md.

6.5 Cluster Pages Cannot Be Independent

A cluster page that does not link to its pillar is not part of the cluster. The back-link is structurally mandatory, ideally in the first 200 words. Multiple back-links are fine but the first is load-bearing for topical signal.

7. Internal Link Topology for Topical Authority

Generic internal linking discipline (anchor text, crawl depth, orphan rescue) lives in framework-internallinking.md. This section covers the topology specific to topical authority architecture. The two frameworks compose: this defines what links exist between which pages; the internal linking framework defines how each link is written.

7.1 The Five Link Types in a Cluster

Hub to spoke. Pillar links out to every cluster page (in the sub topic navigation section of the pillar). The structural promise of the pillar.

Spoke to hub. Every cluster page links back to its parent pillar contextually within the prose, ideally in the first 200 words. The load-bearing link for cluster-to-pillar equity transfer.

Spoke to spoke (sibling). Cluster pages link to sibling cluster pages within the same topic where topically warranted. A page on "quarterly estimated taxes for LLCs" links to "quarterly estimated taxes for S-corps." Sibling link density should be high within a tight cluster (3 to 8 siblings per cluster page on average).

Hub to hub (cross pillar). Pillar pages link to related pillars sparingly (2 to 5 per pillar maximum) and only where topically warranted.

Spoke to cross pillar. Cluster page links to a different-topic pillar or cluster. Rare (0 to 3 per cluster page), only when the topical bridge is genuine.

7.2 The Cluster Link Density Pattern

For a healthy cluster of 1 pillar plus 12 cluster pages.

Hub to spoke:   12 outbound to each cluster
Spoke to hub:   12 inbound to pillar
Spoke to spoke: 36 to 72 sibling links (3 to 6 per cluster page)
Hub to hub:     2 to 5 outbound to other pillars
Spoke to cross: 0 to 3 per cluster page

Total internal link mass: 60 to 100 links within the cluster
Pillar inbound: 18 to 25 (clusters plus site nav plus topical map page)

Princeton GEO study (SIGKDD 2024) established that pages with at least three inbound topical internal links earn higher AI Overview citation rates. Healthy pillars typically receive 18 to 40 inbound internal links.

7.3 Anchor Text Discipline in a Cluster

Per framework-internallinking.md Section 7, anchor text should be descriptive, varied, and topical. Within a cluster the discipline tightens.

Hub to spoke. Use the cluster page's specific sub-topic title or query as the anchor. "Quarterly estimated taxes for LLCs," not "click here."

Spoke to hub. Vary across cluster pages. A given cluster page should not link to the pillar with the same anchor every time. Variations: "complete guide to quarterly estimated taxes," "our coverage of quarterly estimated taxes." Anchor diversity protects against over-optimization signals.

Sibling. Use the sibling page's specific sub-topic title or a descriptive variant. The anchor should convey what the linked page covers.

Cross pillar. Be especially descriptive. The link is bridging topics; the anchor must clarify why.

7.4 The Anti Pattern: Indiscriminate Linking

A "related posts" carousel showing random recent articles dilutes the topical signal. Cluster pages should link primarily to other cluster pages in the same topic. A generic "you might also like" footer surfacing random unrelated articles erodes topical signal more than it helps engagement. Replace generic widgets with topic-aware widgets that surface only same-cluster pages.

7.5 Breadcrumb and Navigation Reinforcement

Breadcrumb navigation reinforces the cluster structure. Every cluster page carries a breadcrumb showing Home > Topics > Pillar > Cluster, reflected in BreadcrumbList schema and visible UI. See framework-schema.md. The signal: breadcrumbs implicitly assert "this page belongs to this pillar." Site main navigation should expose the pillar pages, not random featured articles. A "Topics" or "Library" menu listing the 3 to 7 pillars is preferable to a "Latest Posts" menu. Pillars in main nav accumulate site-wide internal link mass.

7.6 Visualizing the Cluster

For clusters above 20 pages, visualize in Graphviz, yEd, or Gephi. Extract the graph via Screaming Frog or Sitebulb, filter to the topical scope, and render. A healthy cluster shows a dense hub-and-spoke with thick edges to the pillar and a moderately connected sibling mesh. A broken cluster shows orphans, isolated sub-groups, or thin spoke connections.

8. Content Silos

A content silo is a section of a site dedicated to a single topic, with URL structure, navigation, breadcrumb signaling, and internal link density all reinforcing topical isolation. Silos are stricter than clusters: a cluster is a logical group of pages, a silo is a structural enclosure.

8.1 When Silos Help

Silos help on multi-topic sites where topical separation needs structural reinforcement.

Multi-vertical sites. A site covering 3 plus separate topics (each its own potential business unit) needs silos to prevent Google from confusing the topical scope. A site covering both "tax planning" and "real estate investing" benefits from /tax-planning/ and /real-estate/ as silos, with internal linking dense within each, sparse across.

Mixed YMYL and non-YMYL content. YMYL silos benefit from explicit isolation because the YMYL bar for credentialing applies within the silo and not necessarily across. See framework-ymyl.md.

Sites scaling past 10 primary topics. At this scale, silos become the architectural unit. The site is effectively a network of mini sites, and silo isolation prevents cross contamination.

8.2 When Silos Hurt

Silos hurt when over-isolation kills internal link equity flow.

No cross silo links at all. Some 2018 era guidance recommended zero links between silos. Modern Google does not require silo purity. A site with no cross-silo links signals brittle architecture.

Silos that should be merged. Two silos covering closely adjacent topics (each with 3 to 5 pages) often perform worse than one merged silo with 6 to 10 pages. Silo proliferation dilutes density.

Silos that prevent legitimate user paths. If a real reader has a reason to traverse from one silo to another and the silo structure prevents that link, the silos hurt user experience for an outdated SEO discipline.

8.3 The Modern Silo

A modern silo is structural (URL plus breadcrumb plus navigation) but allows topical bridges (2 to 5 cross silo links per silo where genuinely warranted). The discipline is "link densely within, sparsely across." Not "never across."

/tax-planning/                       silo 1 pillar
/tax-planning/quarterly-taxes/       silo 1 cluster
/tax-planning/llc-tax/               silo 1 cluster
/real-estate/                        silo 2 pillar
/real-estate/rental-tax/             silo 2 cluster
/real-estate/depreciation/           silo 2 cluster

Cross-silo bridges (sparse, topical):
  /tax-planning/llc-tax/ -> /real-estate/rental-tax/ (LLC owning rentals)
  /real-estate/rental-tax/ -> /tax-planning/quarterly-taxes/

8.4 URL Structure and Navigation

Silos benefit from URL structure that makes the silo visible: /{{silo-slug}}/{{cluster-slug}}/. Avoid silos sharing a prefix with the blog unless the blog is itself a silo. Silos appear in site-wide nav as top-level items. Cluster pages within a silo appear in silo-specific sub-navigation. Both a user experience signal and a topical signal to crawlers.

9. Topic to Keyword Mapping and Cannibalization

The cannibalization matrix prevents two pages from competing on the same query. Every priority keyword maps to exactly one URL. Every URL maps to a primary keyword and optional secondary keywords. Violations cause cannibalization, the most common topical authority defect on mature sites.

9.1 The Keyword to URL Map

One row per priority keyword.

Build by walking the topical tree (Section 4.3) and assigning a target URL to each terminal node. Add rows for variants the same URL targets. Each variant maps to exactly one URL.

9.2 The One Page One Head Query Rule

A page can rank for many long tail queries but should claim exactly one head query as its primary target. The head query is the highest volume, highest intent term in the page's keyword cluster. Two pages may not legitimately claim the same head query. If both compete, one is misassigned. Consolidate or reassign per Section 9.5.

9.3 What Cannibalization Actually Is

Google's 2025 guidance (John Mueller, Lizzi Sassman) clarified that multiple pages ranking for the same query is not inherently a problem. Different pages can serve different intents on overlapping queries.

Cannibalization in the operational sense is the subset where two or more pages target the same intent for the same query, splitting impressions and CTR and degrading both pages' ranking strength. The signs:

1. Two URLs appear for the same query in GSC over a rolling 90 day window with non-trivial impressions on each.
2. The position difference is less than 3, and the lower-ranking URL receives more than half the impressions of the higher-ranking URL (Advanced GSC Visualizer 2025 high-severity threshold).
3. Week-to-week ranking volatility, with the ranking URL rotating between the two pages.
4. SERP same-domain dual-listings on the query.
5. CTR on the cannibalized query is below the expected curve for its average position.

A site with a few years of content typically has 15 to 30 queries showing this pattern.

9.4 Cannibalization Detection in GSC

Pull GSC data via API or export for 90 days. For each query receiving impressions, list every URL that received impressions. Any query with 2 or more URLs is a candidate. Filter to cases where each URL has non-trivial impressions (above 5 percent of query total), the URLs are not legitimate intent splits, and position difference is less than 5.

# gsc_export.csv columns: query, url, clicks, impressions, ctr, position
cd /var/www/sites/example.com/audits/
awk -F',' 'NR>1 {print $1}' gsc_export.csv | sort | uniq -c | awk '$1 > 1 {print $2}' > candidates.txt

while read query; do
  echo "Query: $query"
  awk -F',' -v q="$query" '$1==q && $4>50 {print "  "$2" pos:"$6" impr:"$4}' gsc_export.csv
done < candidates.txt > cannibalization_report.txt

Manual review classifies each pair as legitimate intent split or genuine cannibalization.

9.5 Cannibalization Resolution Decision Tree

For each genuine pair, choose one resolution.

Consolidate. Both pages cover the same ground at similar depth. Merge into one comprehensive page. Pick the URL with stronger backlink profile as canonical. 301 redirect the other. Update internal links. See framework-hcs.md Section 6.4.3.

Differentiate. The pages cover overlapping but distinct intents. Rewrite each to clarify its specific intent. Page A targets "what is X." Page B targets "how to do X." Update titles, metas, lede, and H1 to make the split unambiguous. Add a contextual link clarifying which to read.

Redirect. One page is the canonical target; the other is incidental. 301 redirect to canonical. Update internal links.

Noindex. A page that should not target the query at all but cannot be redirected (a category page incidentally ranking for an informational query). Add noindex or restructure to remove the query targeting.

9.6 The Cannibalization Matrix

Maintain a matrix as part of the topic-to-keyword map.

Severity:

• High: position difference under 3, impression ratio above 0.5, on a head query critical to the pillar.
• Medium: position difference 3 to 5, impression ratio 0.2 to 0.5, or on a non-critical query.
• Low: position difference above 5, or impression ratio below 0.2, or on a long tail query.

High severity items resolve immediately. Medium severity batched monthly. Low severity tolerated unless clustering around a single pillar.

9.7 Preventing Cannibalization on New Content

Every new article gets a pre-publish cannibalization check. The author confirms via the keyword-to-URL map that the article's primary target query is not already assigned to another URL. If conflict exists, the article is reassigned, merged with the existing page, or the existing page is retired before publication. The cost of preventing one cannibalization pair is approximately 5 minutes. The cost of resolving an established pair is hours of work and weeks of recovery.

10. Topic Saturation Analysis

A cluster is "complete" when incremental cluster pages no longer add citation surface area or ranking lift. Saturation analysis identifies the gaps preventing completeness.

10.1 The Three Saturation Signals

Signal 1, SERP coverage. For the pillar's head query, examine the top 10 organic results. Do you cover every sub-topic the top 10 collectively cover? Map each top-10 page to its primary sub-topic. Cross reference against your topical tree. Gaps are cluster page candidates.

Signal 2, People Also Ask coverage. For the pillar's head query and each cluster's target query, capture the People Also Ask box. Each PAA question should map to a cluster page (or a section within a cluster page) that answers it directly. Uncovered PAA questions are cluster gaps.

Signal 3, query fan out coverage. Per framework-aioverviews.md Section 4.1, AI Overview and AI Mode generate 8 to 16 sub queries per head query. Capture the sub queries (via AI Mode's expose-sub-queries panel for priority head queries) and map each sub query to a cluster page. Uncovered sub queries are cluster gaps with high AI citation potential.

10.2 SERP Coverage Audit Procedure

1. Identify the 1 to 3 head queries each pillar targets.
2. Capture the current top 10 organic results for each head query.
3. Map each top-10 result to its primary sub topic and unique angle.
4. List the union of all sub topics covered by the top 10.
5. Cross reference against your cluster pages. Gaps become new cluster page candidates, prioritized by search volume and authority fit.

The output is a per-pillar gap report.

PILLAR: Tax Planning for Small Business
Top 10 SERP sub topics:
  Quarterly estimated taxes (covered)
  LLC tax classification (covered)
  S-corp election (covered)
  Home office deduction (GAP)
  Vehicle deduction (GAP)
  Self employment tax (GAP)
  Year-end tax planning (GAP)

Gap candidates ordered by volume:
  1. Self employment tax
  2. Home office deduction
  3. Vehicle deduction
  4. Year-end tax planning

10.3 People Also Ask Coverage

PAA capture is mechanical: for each priority query, scrape the PAA box (SERP API or manual) and record the questions. PAA boxes refresh on each click, so capture across multiple sessions. Across 5 to 10 captures the question pool stabilizes. Each unique PAA question becomes a candidate. Some are answered by existing cluster pages (good). Some are answered but not surfaced as Q-and-A (add a <details> block on the existing page). Some are unanswered (new cluster candidate).

10.4 Query Fan Out Coverage

For each priority head query, run through Google AI Mode and inspect the sub queries panel where available. Record the 8 to 16 sub queries generated. Cross reference against existing cluster pages. Uncovered sub queries are high-leverage cluster candidates: the engine has explicitly generated them as the head query's decomposition, they are by definition relevant to the head query, and pages addressing them directly are eligible for AI Overview citation per framework-aioverviews.md.

10.5 The Completeness Threshold

A pillar is "saturated enough" when 80 percent of top 10 SERP sub topics for the head query are covered, 75 percent of stable PAA questions are answered, and 70 percent of AI Mode sub queries map to cluster pages. Below these thresholds the cluster should grow. Above, additional cluster pages produce diminishing returns; expand into adjacent pillars or deepen existing cluster pages instead.

10.6 The Diminishing Returns Inflection

Most clusters show diminishing returns between 15 and 25 cluster pages. The first 5 produce the largest ranking lift per page. Pages 6 through 15 deliver compounding lift via internal link equity. Pages 16 through 25 deliver smaller marginal lift. Beyond 25, additional pages frequently introduce cannibalization risk and dilute pillar coherence.

When approaching 25 cluster pages, audit for cluster pages to consolidate (similar intent splitting authority), cluster pages large enough to spin off as sub-pillars, and cluster pages that have not earned rankings (removal candidates). A mature cluster of 18 plus 1 pillar typically outperforms a sprawling 35 plus 1.

11. Building Topical Authority From Scratch

11.1 The 0 to 90 Day Plan

The first 90 days establish the foundation. Outcomes by day 90: topical map defined, 1 pillar fully built with 8 to 12 cluster pages, internal link topology functional, baseline GSC tracking in place.

Days 1 to 14, foundation. Define 3 to 5 primary topics passing the qualification checklist (Section 4.2). Build the topical map tree for each topic (Section 4.3). Document publicly on the About page or /topics/. Audit existing content against the topical map: pages that fit each pillar, pages to retire, pages to consolidate.

Days 15 to 45, first pillar build. Pick the highest-leverage pillar (largest market, strongest team authority, biggest competitive gap). Build the pillar page per Section 5. Identify the 8 to 15 cluster pages from the topical tree. Begin cluster production at 3 to 5 per week (typical for a team of 2 to 3 writers).

Days 46 to 90, cluster completion and link topology. Complete the 8 to 12 cluster pages. Install the full internal link topology per Section 7. Submit updated sitemap. Capture baseline GSC and Analytics for the pillar head query and cluster target queries. Begin saturation audit per Section 10.

By day 90 the first pillar should show early ranking signals. um.marketing's 2025 internal linking analysis found new clusters typically show meaningful ranking movement within 90 to 120 days for low to mid competition keywords.

11.2 The 90 to 365 Day Plan

Days 91 to 180. Apply the pillar-cluster build to the second pillar. Begin third in parallel if capacity allows. Continue saturation work on the first pillar. Begin site-wide cannibalization detection per Section 9.4.

Days 181 to 270. Continue building remaining pillars. Refresh first pillar cluster pages substantively per framework-hcs.md Section 6.6. Begin original research production per framework-infogain.md Section 6.3 to anchor pillar authority. Begin earned media outreach. External citations on the topic compound topical authority signal.

Days 271 to 365. All primary pillars are functional clusters of 12 plus pages. Site-wide internal link topology is consistent. Cannibalization matrix is operational. Monthly maintenance cadence per Section 14 is in place. AI Overview citation tracking is operational per framework-aioverviews.md.

11.3 Maturity Benchmarks

By month 12 the topical authority architecture should hit these benchmarks.

Sites hitting all 8 benchmarks have sustainable topical authority. Sites missing 3 or more should re-audit per Section 13 and prioritize remediation.

11.4 Quick Wins

The 12 month plan compounds, but quick wins exist throughout. Inmotion Marketing's 2026 pillar analysis and HireGrowth's 2025 cluster analysis documented 30 to 50 percent traffic lifts within 6 to 12 weeks of pillar plus link installation. Conditions: existing base of 10 plus topic articles lacking pillar coordination, weak existing link structure, mid-tier competitive set, and genuine Information Gain across the cluster. Sites meeting all four can see lift within 6 to 8 weeks.

12. Multi Topic Sites

Sites covering 3 plus primary topics face an architectural choice: unify (one site with multiple silos) or split (separate sites per topic).

12.1 When to Unify

Unify when topics share substantial audience overlap, the team's authority is the unifying brand, cross topic synergies exist (tax planning informs small business operations), the combined site supports enough internal link mass per topic, and the team can sustain authority across all topics simultaneously. When unifying, use clear silo architecture per Section 8. Each topic is its own silo with its own pillar and cluster set. Cross silo links are sparse and topical.

12.2 When to Split

Split when audiences are genuinely separate, brand identity does not extend across topics naturally (a personal finance brand cannot credibly extend into video game reviews), team authority is concentrated on one topic, the combined site has too many topics for any cluster to get enough resource, or different topics require different YMYL classifications or credentialing. Splitting means separate domains or subdomains per topic. Each becomes an independent topical authority project per Section 11. The trade-off: each new site must build its own domain authority from zero. Slower, but produces cleaner topical signal per domain.

12.3 The Hybrid Pattern

Some operations run a unified primary site plus separate sites for topics that are too distinct to unify. A SaaS team may run the SaaS domain (product, customers, support) plus a separate content domain (industry blog, research, thought leadership). Topical authority is built on the content domain; the SaaS domain inherits trust by association. Appropriate when topics merit separation but the team's brand benefits from both being recognized.

12.4 Multi Topic Site Constraints

For unified multi topic sites: each primary topic gets its own URL namespace (silo); each pillar has its own breadcrumb root; site-wide navigation exposes all primary pillars at top level; the About page declares the full topical scope and the team's authority on each; each silo carries its own cannibalization matrix; cross silo cannibalization is checked separately for queries that legitimately span silos.

12.5 The 7 Topic Ceiling

Sites running more than 7 primary topics struggle to maintain authority on all. Team attention and site link mass are both finite. Most enterprise sites that appear to cover dozens of topics either aggregate sub-topics under fewer pillars than they appear to (each "topic" is actually a cluster in a larger pillar), or fail on most and succeed on a few while the failures drag site-wide signals. If the team wants more than 7 primary topics, the architectural answer is usually multiple sites, not one bigger site.

13. Audit Rubric

13.1 Per Pillar Audit Rubric

For each primary pillar, score each criterion pass or fail.

Score per pillar: 10. World class pillar: 9 plus pass with zero critical fails.

13.2 Site Wide Audit Rubric

Score: 10. World class topical authority site: 9 plus pass with zero critical fails on S1, S2, S5, S6, S10.

13.3 First 90 Days Subset

For sites in early pillar build (under 90 days from topical map definition), the audit subset.

Score 5. All 5 must pass before claiming Phase 1 complete and moving to a second pillar.

13.4 Audit Output

The audit output is a per-pillar score table plus the site-wide score table, plus the cannibalization matrix, plus the saturation gap report, plus a remediation priority list. See Section 14.3 for the full audit report template.

14. Maintenance Schedule and Report Templates

14.1 Maintenance Cadence

Weekly. Pre-publish cannibalization check on any new article. Review GSC for emerging dual-page impressions on priority queries. Track ranking position on each pillar's head query.

Monthly. Run the cannibalization detection sweep per Section 9.4. Resolve medium severity items. Audit 2 to 3 cluster pages for refresh need per framework-hcs.md Section 6.6. Update internal link audit (orphan check, sibling density spot check).

Quarterly. Site wide audit per Section 13. Run full saturation analysis per Section 10 on every pillar. Refresh pillar pages where dateModified exceeds 6 months and substantive updates are warranted. Review topical map: any topics to add, retire, or split?

Annually. Full topical map review. Are the declared primary topics still the right 3 to 7? Are any topics close to splitting into two? Refresh out-of-scope content list. Refresh competitive context for each pillar. Run multi-engine citation audit per framework-aicitations.md to validate topical authority compounding across surfaces.

14.2 Implementation Report Template

# Topical Authority Implementation Report

**Site**: {{BUSINESS_NAME}}
**Implementation Date**: {{TODAY}}

## Summary
- Primary topics declared: {{COUNT}}
- Pillar pages live: {{COUNT}}
- Cluster pages live: {{COUNT}}
- Internal link topology installed: yes / partial / no
- Cannibalization matrix initialized: yes / no

## Pillar Build Status
| Pillar | URL | Cluster pages | Pillar inbound links |
|---|---|---|---|

## Cannibalization Baseline
- High severity pairs identified, resolved, remaining: {{X / Y / Z}}

## Out-of-Scope Content Handled
- Pages removed / consolidated / retained: {{X / Y / Z}}

## Saturation Baseline
| Pillar | SERP coverage % | PAA coverage % | Fan out coverage % |
|---|---|---|---|

## Sign-Off

14.3 Audit Report Template

# Topical Authority Audit Report

**Site**: {{BUSINESS_NAME}}
**Audit Date**: {{TODAY}}

## Executive Summary
{{ONE_PARAGRAPH}}

**Site wide score**: {{X}}/10
**Average pillar score**: {{X}}/10
**Cannibalization (high severity unresolved)**: {{COUNT}}

## Pillar Scorecards
| Pillar | Score | Critical fails |
|---|---|---|

## Cannibalization Matrix Status
- High / Medium / Low unresolved: {{X / Y / Z}}

## Saturation Gap Summary
- Pillars at or above 80 percent SERP coverage: {{LIST}}
- Pillars below threshold with top gap candidates: {{LIST}}

## Critical Failures
List with remediation path.

## Recommended Remediation Order
1. Critical (under 30 days)
2. High (under 90 days)
3. Medium and structural (under 365 days)

## Sign-Off

End of Framework Document

Document version: 1.0 Created: 2026-05-14 Maintainer: ThatDeveloperGuy

Topical authority is the architectural signal that determines whether a site is treated as a reference or as one of many sites covering a topic. In 2026, with the December 2025 core update's cluster level evaluation, AI Overview citation decoupling, and query fan out retrieval, topical authority is the highest leverage SEO investment a site can make. Sites that build deliberate pillar-cluster architectures with disciplined link topology, resolved cannibalization, and saturated SERP coverage compound visibility across all four pillars (SEO, AEO, AIO, GEO). Sites that publish broadly without topical architecture rank for nothing in particular and get cited rarely.

This framework operationalizes the topical authority requirement referenced across framework-hcs.md, framework-infogain.md, framework-entitysalience.md, and framework-aioverviews.md. Apply it after prerequisite thresholds (contentfirst score 22 plus, hcs score 41 plus, schema core graph server rendered). The pillar-cluster architecture turns each new article into compounding authority rather than scattered impressions.

Companions

• framework-contentfirst.md, substrate doctrine, prerequisite for topical authority work
• framework-hcs.md, Helpful Content System
• framework-infogain.md, Information Gain
• framework-entitysalience.md, entity declarations
• framework-knowledgegraph.md, Wikidata and Knowledge Graph
• framework-keywordresearch.md, keyword research feeds the topic-to-URL map
• framework-internallinking.md, generic internal link discipline composes with Section 7
• framework-schema.md, CollectionPage and FAQPage
• framework-contentaudit.md, audit cadence
• framework-eeat.md, E-E-A-T pillar weighting
• framework-ymyl.md, YMYL credentialing
• framework-sqrg.md, Search Quality Rater Guidelines
• framework-coreupdates.md, December 2025 core update
• framework-aioverviews.md, AI Overview citation surface
• framework-aicitations.md, broader AI citation surface
• framework-contentrefresh.md, refresh cadence (scheduled Phase 1)
• SEO-Search-Appearance.md, multi engine surface map
• SERP-Optimization.md, feature targeting playbook
• 14 tier Engine Optimization Stack, Tier 2 Topical Authority Architecture