Document Type: Framework
Status: Active
Version: v2.1
Authority: HeadOffice
Applies To: Content Brain, Affiliate Brain, Search Intelligence, Research Brain, Customer Brain, Conversion Brain, Ads Brain, Data Brain, Experimentation Brain, Compliance Brain, website owners, publishing owners and approved content operators
Parent: Content Brain Canon
Enforcement Mode: Governance
Last Reviewed: 2026-06-16
Content Brain Topic Cluster And Hub Architecture Framework
Purpose
The Content Brain Topic Cluster And Hub Architecture Framework defines how MWMS plans, creates, connects, reviews, measures and maintains groups of related content.
Its purpose is to help MWMS build useful connected content systems rather than isolated pages with unclear relationships.
The framework governs:
topic-cluster planning
hub-page decisions
supporting-page decisions
keyword-cluster alignment
topic boundaries
URL relationships
search-intent separation
audience-journey support
source and evidence requirements
information-gain requirements
internal-link architecture
commercial and affiliate pathways
production sequencing
review and approval
publishing preparation
measurement
cluster expansion
cluster consolidation
page retirement
content lifecycle management
A topic cluster should help:
readers understand a subject
readers move between related questions
search engines understand content relationships
important pages remain discoverable
content roles remain distinct
internal links remain useful
content duplication is reduced
commercial pathways remain controlled
maintenance becomes easier
A topic cluster must not be treated as:
a requirement to create many pages
a guarantee of rankings
a keyword-volume exercise
a reason to copy competing sites
a reason to create thin supporting pages
a reason to force internal links
a substitute for useful content
a substitute for research
a substitute for human approval
Scope
This framework applies to:
topic clusters
content hubs
pillar pages
supporting articles
supporting guides
FAQ collections
glossary systems
comparison ecosystems
affiliate content ecosystems
product-education ecosystems
service-content ecosystems
local-content ecosystems
trust-content systems
authority-content systems
buyer-journey content
problem-awareness content
solution-awareness content
product-awareness content
decision-support content
post-purchase support content
content-pack relationships
search-led content projects
internal-link structures
cluster refreshes
cluster expansions
cluster consolidations
cluster retirements
This framework may be used for:
affiliate websites
lead-generation websites
service websites
product websites
authority websites
content libraries
resource centres
knowledge bases
documentation systems
campaign-support content
This framework does not directly authorise:
new website creation
new page publication
URL changes
redirect implementation
canonical-tag changes
schema implementation
menu changes
website-development work
technical SEO implementation
campaign approval
offer approval
budget approval
claim approval
compliance approval
automated page generation
automated cluster generation
automated internal linking
automated publishing
worker activation
queue execution
AI Employee activation
Brain Room routing
automatic handoff
Core Principle
Content should be connected where a real topic, reader or operational relationship exists.
A cluster should exist because:
the audience has multiple related needs
the subject requires more than one distinct content role
the site benefits from a clear topic structure
the content cannot be handled well by one page alone
multiple approved assets must work together
A cluster should not exist merely because:
a keyword tool produced many phrases
competitors have many pages
a page needs more internal links
a plugin recommends related topics
the topic could theoretically be split
more pages appear to mean more authority
The correct principle is:
one clear topic system
with distinct page roles
serving distinct audience needs
connected through useful internal links
and maintained as one content ecosystem
Topic Cluster Workflow
The complete topic-cluster workflow is:
Topic Need
Qualification
Existing Content And Cluster Audit
Cluster Action Decision
Audience And Search-Intent Mapping
Topic Boundary Decision
Keyword Cluster Review
Topic Cluster Design
URL Cluster Design
Hub Role Decision
Supporting-Page Role Decisions
Source And Evidence Requirements
Information-Gain Requirements
Internal-Link Architecture
Commercial And Conversion Boundary Review
Content Project And Production Sequence
Content Briefing
Content Production
Editing And Cross-Cluster Quality Control
Search Review
Specialist Review Where Required
Human Approval
Publishing Preparation
Human-Controlled Publication
Outcome Recording
Measurement
Expansion, Consolidation Or Retirement Decision
Topic Need
A topic-cluster request may originate from:
Content Brain
Affiliate Brain
Search Intelligence
Research Brain
Customer Brain
Conversion Brain
Ads Brain
Data Brain
a website owner
a publishing owner
a human operator
an existing-content audit
a Site Intelligence finding
a content-performance review
a content-refresh requirement
a new product or service requirement
a new affiliate-offer requirement
a customer-question pattern
a search-demand finding
Request Identity
Cluster Request Title:
Request ID:
Request Version:
Request Status:
Date Created:
Requested By:
Requesting Brain Or Human:
Target Website:
Target Section:
Related Product:
Related Service:
Related Affiliate Offer:
Related Campaign:
Related Content Project:
Approval Owner:
Publishing Owner:
Measurement Owner:
Qualification
Before designing a cluster, confirm:
the topic need is clearly stated
the requesting human or Brain is known
the target website is known
the intended audience is known
the business purpose is known
the likely search or reader need is known
the request belongs in Content Brain
the request does not require another Brain to act first
the topic is important enough to justify a cluster review
existing content has not already solved the need
the request does not assume that many pages are required
the approval owner is known
the publishing owner is known where relevant
Qualification Result:
Qualified
Qualified With Conditions
Waiting For Information
Another Brain First
Rejected
No Action
Qualification Notes:
Existing Content And Cluster Audit
Before creating or changing a cluster, review the current content environment.
Audit:
existing hub pages
existing supporting pages
existing articles
existing guides
existing FAQs
existing glossary pages
existing comparison pages
existing product pages
existing service pages
existing affiliate pages
existing location pages
existing trust pages
existing authority pages
existing draft pages
existing archived pages
existing retired pages
current internal links
current topic relationships
current site hierarchy
current URL structure
current navigation
current content performance
current search intent
current content duplication
current keyword overlap
current audience overlap
current claim conflicts
current content gaps
Audit Record
Website:
Section:
Audit Date:
Audit Owner:
Existing Hub:
Existing Supporting Pages:
Existing Competing Pages:
Existing Duplicate Pages:
Existing Thin Pages:
Existing Orphan Pages:
Existing Internal-Link Issues:
Existing Search-Intent Conflicts:
Existing Audience Conflicts:
Existing Claim Conflicts:
Existing Content Gaps:
Existing Evidence Gaps:
Existing Maintenance Issues:
Audit Decision:
No Cluster Change Required
Create New Cluster
Strengthen Existing Cluster
Expand Existing Cluster
Correct Existing Cluster
Merge Existing Clusters
Split Existing Cluster
Rebuild Existing Cluster
Relink Existing Cluster
Retire Existing Cluster
Further Review Required
Cluster Action Decision
Select one primary action.
Create
Create a new cluster where no suitable topic system exists.
Strengthen
Improve the hub, supporting pages, internal links or topic clarity of an existing cluster.
Expand
Add justified supporting pages or sections where genuine gaps exist.
Correct
Repair weak, inaccurate, duplicated, misaligned or unsupported content.
Merge
Combine overlapping clusters or pages.
Split
Separate a cluster where multiple distinct topics or search intents have been forced together.
Rebuild
Redesign the cluster where the current structure is fundamentally unsuitable.
Relink
Improve the internal-link architecture without creating unnecessary new content.
Refresh
Update outdated sources, evidence, claims, examples or page roles.
Retire
Remove a cluster or pages that no longer have a valid role.
Archive
Preserve inactive content without treating it as current.
No Action
Record that no cluster work is required.
Selected Action:
Reason:
Affected Pages:
Expected Outcome:
Next Step:
Audience Mapping
A cluster must serve a defined audience.
Primary Audience:
Secondary Audience:
Audience Location:
Audience Stage:
Primary Problem:
Primary Need:
Desired Outcome:
Current Knowledge Level:
Likely Questions:
Likely Objections:
Approved Customer Language:
Language To Avoid:
Confirm:
the audience is specific enough
the cluster reflects real audience needs
the supporting pages have distinct audience roles where required
the cluster does not exist only to cover keywords
the audience journey can be explained
invented customer experience is absent
Search-Intent Mapping
A cluster may contain more than one search intent, but each page should have a clear primary role.
Possible search intents include:
Informational
Commercial Investigation
Transactional Support
Navigational
Local
Post-Purchase
Support
Mixed
For each intended page, record:
Page:
Primary Search Intent:
Secondary Search Intent:
Audience Stage:
Primary User Question:
Primary User Goal:
Expected Next Action:
Intent Confidence:
High
Moderate
Low
Unknown
Intent Conflict:
Yes / No
Search-Intent Separation Rule
Pages should not be separated merely because keywords differ.
Pages should be separated where:
the user intent is materially different
the required format is materially different
the audience stage is materially different
the commercial role is materially different
the page would become confusing if combined
Pages should be combined where:
the intent is substantially the same
the audience need is substantially the same
the content would overlap heavily
separate pages would create thin coverage
separate pages would create unnecessary cannibalisation risk
Topic Boundary Decision
Every cluster must have a clear boundary.
Cluster Name:
Primary Topic:
Topic Definition:
Topic Purpose:
Primary Audience Need:
Primary Business Role:
Topics Included:
Topics Excluded:
Adjacent Topics:
Separate Clusters:
Commercial Boundary:
Affiliate Boundary:
Geographic Boundary:
Product Boundary:
Service Boundary:
Evidence Boundary:
Topic-Boundary Rule
A cluster should remain focused enough that:
the hub can explain the full cluster logically
supporting pages clearly relate to the hub
internal links feel natural
the audience understands the relationship
pages do not compete unnecessarily
Do not expand a cluster merely to include any remotely related topic.
Keyword Cluster
A keyword cluster is a group of related search phrases.
Its purpose is to help identify:
possible audience questions
possible search intents
topic language
subtopics
content overlap
possible page roles
A keyword cluster does not automatically determine the number of pages required.
Keyword Cluster Record
Primary Query:
Secondary Queries:
Related Queries:
Question Queries:
Commercial Queries:
Comparison Queries:
Local Queries:
Brand Queries:
Product Queries:
Service Queries:
Emerging Queries:
Keyword Source:
Keyword Confidence:
High
Moderate
Low
Unknown
Potential Intent Groups:
Potential Page Groups:
Potential Overlap:
Keyword-Cluster Warning
Do not create one page for every keyword variation.
Keywords should be grouped according to:
intent
audience need
topic role
content format
reader outcome
Topic Cluster
A topic cluster is the approved content system covering a defined subject.
It should include only the pages required to serve distinct roles.
Topic Cluster Record
Cluster Name:
Cluster Purpose:
Hub Page:
Supporting Pages:
Primary Audience:
Primary Search Journey:
Primary Commercial Role:
Primary Affiliate Role:
Primary Conversion Role:
Shared Sources:
Shared Evidence:
Shared Terminology:
Shared Claim Boundaries:
Shared Internal-Link Rules:
Cluster Owner:
Review Date:
URL Cluster
A URL cluster is the live or planned page structure representing the approved topic cluster.
Its purpose is to make page relationships clear.
URL Cluster Record
Website:
Cluster Section:
Hub URL:
Supporting URLs:
Existing URLs:
New URLs Required:
URLs To Refresh:
URLs To Merge:
URLs To Redirect:
URLs To Retire:
URLs To Archive:
Parent Structure:
Breadcrumb Structure:
Navigation Requirement:
URL-Cluster Rule
The URL structure should support:
clarity
stability
site hierarchy
reader navigation
content management
It should not be changed merely to imitate another website.
Keyword, Topic And URL Alignment
The three layers should work together:
Keyword Cluster
identifies language, demand and intent patterns
Topic Cluster
defines the approved content roles
URL Cluster
defines the actual page structure
Alignment does not require a one-to-one relationship.
One page may serve multiple closely related queries.
One topic may require multiple pages where intent differs.
One URL should have one clear primary role.
Alignment Check
Keyword groups mapped to page roles: Yes / No
Each page has a clear primary intent: Yes / No
Topic roles are distinct: Yes / No
URL roles are distinct: Yes / No
Unnecessary duplicate pages are absent: Yes / No
Cannibalisation risk reviewed: Yes / No
Hub role is clear: Yes / No
Supporting-page roles are clear: Yes / No
Hub Page Decision
A hub page is the primary organising page for a topic system.
A hub may function as:
topic overview
pillar page
category page
resource guide
buyer guide
service overview
product-category overview
affiliate-category guide
navigation resource
A hub is not required for every small topic group.
A hub should be created or retained where:
multiple supporting pages have a genuine shared topic
readers benefit from an overview or navigation layer
the site needs a primary topic destination
the hub has a distinct role from supporting pages
the cluster can be explained clearly from one central page
Hub Page Record
Hub Title:
Hub URL:
Hub Type:
Hub Purpose:
Primary Audience:
Primary Search Intent:
Primary Reader Outcome:
Primary Business Role:
Primary Commercial Role:
Primary Affiliate Role:
Primary Conversion Role:
Supporting Pages:
Required Sources:
Required Evidence:
Information-Gain Requirement:
Primary CTA:
Approval Owner:
Publishing Owner:
Hub Page Requirements
A hub page should:
define or introduce the central topic
help readers understand the topic structure
guide readers to relevant supporting pages
provide useful value itself
match its intended search or navigation role
avoid becoming a thin directory
avoid duplicating every supporting page
include clear internal links
use accurate and natural anchor context
preserve commercial and affiliate boundaries
Hub pages may include:
topic overview
decision guidance
subtopic summaries
navigation sections
key definitions
important comparisons
approved CTAs
links to supporting pages
Hub pages must not exist only as a list of links.
Supporting-Page Decision
Supporting pages should serve distinct roles.
Possible supporting-page roles include:
problem explainer
solution explainer
how-to guide
FAQ
definition
comparison
review
buyer guide
product explainer
service explainer
location support
trust support
evidence support
objection handling
case-supported explanation
post-purchase support
refresh replacement
For each supporting page, record:
Page Title:
Page URL:
Page Role:
Primary Audience:
Primary Search Intent:
Primary Question:
Primary Reader Outcome:
Relationship To Hub:
Relationship To Other Pages:
Required Sources:
Required Evidence:
Information-Gain Requirement:
Commercial Role:
Affiliate Role:
Conversion Role:
Primary CTA:
Approval Owner:
Publishing Owner:
Supporting-Page Requirements
A supporting page should:
address a distinct audience need
have a clear primary intent
provide enough value to justify a separate page
support the cluster without duplicating the hub
link back to the hub where useful
link to related supporting pages where genuinely helpful
remain within approved topic boundaries
use approved sources and evidence
avoid unsupported claims
Supporting pages should not be created where:
the topic can be handled clearly within an existing page
the page would be thin
the content would duplicate another page
the search intent is the same as an existing page
the page exists only to target a minor keyword variation
Cluster Size
There is no fixed number of pages required for a valid cluster.
Cluster size should depend on:
audience needs
topic complexity
distinct search intents
business purpose
available evidence
content quality
maintenance capacity
commercial value
site maturity
approval capacity
Possible cluster sizes include:
Single Hub With Sections
Small Cluster
Standard Cluster
Expanded Cluster
Large Authority System
A single strong page may be appropriate where one page can satisfy the audience need clearly.
Multiple pages may be appropriate where distinct roles genuinely exist.
Cluster Size Decision:
Reason:
Pages Included:
Pages Excluded:
Future Pages Reserved:
Information Gain
Every cluster should contribute useful value.
Information gain may include:
clearer explanations
better organisation
new evidence
more current evidence
better examples
better comparisons
better limitation handling
better objection coverage
better local context
better practical guidance
better decision support
stronger source transparency
consolidation of scattered information
Information-Gain Record
Cluster-Level Information Gain:
Hub Information Gain:
Supporting Page 1 Information Gain:
Supporting Page 2 Information Gain:
Supporting Page 3 Information Gain:
Additional Page Information Gain:
Evidence Required:
Examples Required:
Tools Required:
Data Required:
Limitations To Explain:
Questions Existing Content Fails To Answer:
Information-Gain Rule
Do not create multiple pages that repeat the same basic information.
Each page should contribute a distinct useful role.
Entity Coverage
Entities may help define the people, products, services, concepts, locations, organisations and terms relevant to the topic.
Primary Entities:
Supporting Entities:
Product Entities:
Service Entities:
Brand Entities:
Location Entities:
Technical Entities:
Regulatory Entities:
People Or Role Entities:
Entity Source:
Entity Coverage Required By Page:
Entity-Coverage Rule
Entity coverage should support topic completeness and audience understanding.
It should not become a checklist requiring every possible entity to be mentioned.
Do not add entities where they are:
irrelevant
unsupported
outside the topic boundary
included only for search manipulation
Source And Evidence Requirements
Possible approved sources include:
Research Brain findings
Search Intelligence findings
Customer Brain intelligence
product information
service information
technical sources
government sources
academic sources
industry sources
legal or regulatory sources
medical sources
financial sources
vendor information
affiliate offer intelligence
internal data
approved case studies
approved testimonials
existing approved content
MCR frameworks and standards
Cluster Source Record
Shared Primary Sources:
Shared Research Sources:
Shared Search Sources:
Shared Customer Sources:
Shared Product Sources:
Shared Service Sources:
Shared Technical Sources:
Shared Compliance Sources:
Shared Data Sources:
Page-Specific Sources:
Evidence Gaps:
Source Classification
Classify important inputs as:
Confirmed Fact
Verified Evidence
Approved Research Insight
Approved Search Finding
Approved Customer Intelligence
Approved Product Information
Approved Service Information
Approved Human Instruction
Approved Internal Data
Approved Vendor Information
Approved Affiliate Brain Direction
Emerging Signal
Working Assumption
Restricted Claim
Unverified Claim
Working assumptions must remain labelled.
Emerging signals must not be presented as proven conclusions.
Unverified claims must not be published as facts.
Research Requirements
Research Required:
Yes / No
Research Type:
Topic Research
Audience Research
Search Research
Competitor Research
Product Research
Service Research
Claim Verification
Evidence Review
Entity Research
Technical Research
Local Research
Refresh Research
Research Owner:
Research Status:
Research Output Reference:
Research Gap:
Production Blocked Until Complete:
Yes / No
Research Brain retains broad research authority.
Search Intelligence Requirements
Search Intelligence Required:
Yes / No
Search Intelligence Owner:
Search Intelligence Status:
Approved Intent Findings:
Approved Format Findings:
Approved Query Groups:
Approved Content Gaps:
Approved Competitor Patterns:
Approved SERP Risks:
Approved Page-Role Findings:
Search findings support cluster planning.
They do not guarantee rankings or traffic.
Internal-Link Architecture
The internal-link system should connect pages according to real content and reader relationships.
Possible link directions include:
Hub To Supporting Page
Supporting Page To Hub
Supporting Page To Supporting Page
Informational To Commercial
Commercial To Evidence
Problem To Solution
Solution To Product
Comparison To Review
Review To Approved Offer
FAQ To Detailed Explanation
Old Page To Replacement
Internal-Link Record
Source Page:
Target Page:
Relationship Type:
Reader-Journey Purpose:
Proposed Anchor:
Placement:
Commercial Role:
Affiliate Role:
Conversion Role:
Approval Required:
Yes / No
Internal-Link Rules
Hub pages should link to relevant supporting pages.
Supporting pages should link to the hub where useful.
Supporting pages may link to related supporting pages where:
the relationship is genuine
the reader benefits
the target page adds useful detail
the link is not forced
Not every page must link to every other page.
Internal links must remain:
natural
accurate
descriptive
relevant
maintainable
Internal links must not be added merely to create the appearance of a cluster.
Orphan-Page Prevention
Every active cluster page should normally have:
a clear role
a logical site position
at least one meaningful discovery path
at least one appropriate inbound internal link
Exceptions may include:
temporary campaign pages
restricted pages
confirmation pages
legal pages
technical pages
other intentionally isolated pages
Exceptions should be deliberate and recorded.
Flat Architecture
Important pages should remain reasonably discoverable.
Avoid unnecessary depth.
This does not mean every page must be within exactly two or three clicks.
Appropriate depth depends on:
site size
site structure
topic complexity
page role
navigation requirements
user expectations
Commercial Integration
Clusters may support commercial journeys.
Possible commercial roles include:
education
trust building
comparison
decision support
product support
service support
lead generation
affiliate progression
Commercial pathways must:
match the reader’s stage
use approved destinations
use accurate anchors
preserve disclosures
remain within owning-Brain authority
avoid premature pressure
avoid unsupported promises
Affiliate Integration
Affiliate content may exist within a cluster where it has a valid role.
Affiliate content may include:
problem-awareness content
solution-awareness content
product education
comparison content
review content
FAQ content
trust content
pre-sell content
bridge content
Affiliate integration must:
follow Affiliate Brain direction
use approved offers
preserve offer status
remain within claim boundaries
use approved affiliate destinations
avoid disguised commercial transitions
Affiliate pages do not have to be embedded in every cluster.
They should exist only where the topic and reader journey justify them.
Conversion Integration
Conversion Brain controls conversion strategy.
Topic clusters may support approved conversion journeys through:
clear next-step links
product pathways
service pathways
lead-generation pathways
comparison pathways
decision-support content
Content Brain may implement approved content pathways.
It must not independently redefine conversion strategy.
Ads Integration
Ads Brain controls paid campaign execution.
Cluster content may support:
message match
post-click education
pre-sell content
trust content
FAQ support
retargeting support
campaign landing-page support
Content Brain does not authorise:
campaign launch
spend
bidding
targeting
scaling
Experimentation
Cluster tests may include:
hub design
navigation structure
internal-link placement
anchor wording
page-role design
content depth
CTA sequencing
related-content modules
Testing must define:
the hypothesis
the controlled difference
the primary signal
the test duration
the traffic requirement
the decision rule
Experimentation Brain retains test-validity authority.
Content Brain must not declare a winning structure from weak or uncontrolled evidence.
Content Project
Create a Content Project where cluster work includes multiple connected assets.
Project Name:
Project Objective:
Cluster Name:
Target Website:
Project Owner:
Primary Audience:
Primary Topic:
Primary Search Journey:
Hub Page:
Supporting Pages:
Production Order:
Shared Sources:
Shared Evidence:
Shared Terminology:
Shared Claim Boundaries:
Shared Internal-Link Plan:
Approval Owner:
Publishing Owner:
Measurement Owner:
Known Dependencies:
Known Blockers:
Completion Standard:
Production Sequence
The production sequence should reflect dependencies.
Possible order:
- cluster plan
- hub brief
- priority supporting-page briefs
- shared research and evidence
- hub production
- supporting-page production
- cross-page editing
- internal-link integration
- specialist review
- human approval
- publishing preparation
- controlled publication
The hub does not always need to be produced first.
The correct order depends on:
source availability
page dependencies
commercial priority
existing content
publishing capacity
review capacity
Production Order:
Reason:
Content Briefing
Each cluster asset should use the appropriate briefing level.
Full Content Brief
Use where:
the page is strategically important
the page is compliance sensitive
the page interprets research
the page supports paid traffic
the page contains material claims
multiple Brains are involved
Short Production Brief
Use where:
the page role is clear
sources are approved
the audience is known
the intent is known
the topic boundary is clear
Direct Production Instruction
Use where:
the task is minor
the source material is complete
the required change is simple
the risk is low
Each brief should record:
page purpose
audience
search intent
cluster role
hub relationship
supporting-page relationships
approved sources
approved evidence
information-gain requirement
claim boundaries
internal-link requirements
CTA requirements
review requirements
approval owner
completion standard
Content Production
For each page, confirm:
the approved brief or instruction is available
the approved sources are available
the page fulfils its cluster role
the page satisfies its primary audience need
the page matches its primary search intent
the page provides distinct value
the page does not duplicate the hub unnecessarily
the page does not duplicate another supporting page unnecessarily
the page uses approved evidence
the page stays within claim boundaries
the page includes required internal links
the page meets its completion standard
Production Outcome:
Draft Complete
Partial Draft
Blocked
Source Gap Found
Evidence Gap Found
Brief Gap Found
Cluster Conflict Found
Compliance Risk Found
Returned To Planning
Cancelled
Editing And Cross-Cluster Quality Control
Page-Level Editing
Confirm:
the page fulfils its brief
the page fulfils its audience role
the page matches its search intent
the page provides useful information gain
the structure is clear
the evidence is accurate
the claims are controlled
the internal links are useful
the CTA is appropriate
the page is complete
Cluster-Level Review
Confirm:
the hub role is clear
supporting-page roles are distinct
the cluster boundary is consistent
page titles are distinct
search intents are distinct where required
topic overlap is controlled
claims are consistent
terminology is consistent
sources are consistent
internal links are logical
commercial pathways are approved
affiliate pathways are approved
the cluster does not contain unnecessary pages
the cluster does not contain obvious gaps required for completion
Editing Outcome:
Ready For Search Review
Ready For Specialist Review
Ready For Human Approval
Revision Required
Major Rework Required
Merge Required
Split Required
Evidence Required
Blocked
Rejected
Search Review
Search review should confirm:
the hub role matches the intended search or navigation need
each supporting page has a distinct role
search intents are appropriately separated
the cluster does not create unnecessary cannibalisation
the content formats suit the intended result environment
the cluster adds useful value
titles and metadata accurately represent page roles
internal-link relationships are appropriate
the topic boundary remains clear
Search Reviewer:
Review Date:
Search Review Decision:
Approved
Approved With Changes
Changes Required
Merge Recommended
Split Recommended
Different Hub Role Required
Different Supporting-Page Role Required
Hold
Reject
Search review does not guarantee:
indexation
rankings
traffic
clicks
conversions
Specialist Review
Specialist review may be required for:
compliance-sensitive content
legal content
medical content
financial content
technical content
affiliate content
product content
service content
campaign content
brand content
data claims
Specialist Review Required:
Yes / No
Specialist Type:
Reviewer:
Review Date:
Decision:
Approved
Approved With Conditions
Changes Required
Evidence Required
Blocked
Rejected
Conditions:
Required changes must return to editing before approval.
Human Approval
Human approval remains mandatory before material cluster changes are published.
Confirm:
the cluster action is approved
the hub role is approved
supporting-page roles are approved
search review is complete where required
specialist review is complete where required
the final page versions are identified
required changes are complete
internal-link structure is approved
commercial pathways are approved
affiliate pathways are approved
publishing ownership is known
Approval Owner:
Approval Date:
Approved Cluster Version:
Approved Page Versions:
Approval Decision:
Approved
Approved With Minor Changes
Revision Required
Held
Rejected
Cancelled
Approval Conditions:
Cluster planning is not publication approval.
Editing completion is not human approval.
Search review is not human approval.
Material Change Check
Material changes after approval include:
new hub role
new supporting-page role
new audience
new search intent
new commercial pathway
new affiliate pathway
new claim
new evidence position
page addition
page removal
major page merge
cluster split
URL change
major internal-link change
Where a material change occurs:
pause publication
update the cluster version
repeat affected search review
repeat affected specialist review
repeat human approval
Material Change After Approval:
Yes / No
New Search Review Required:
Yes / No
New Specialist Review Required:
Yes / No
New Approval Required:
Yes / No
Publishing Preparation
Before publication, confirm:
final page titles are correct
final URLs or slugs are correct
hub and supporting-page roles remain clear
Parent or site sections are correct
internal links are prepared
metadata is prepared
sources and references are complete
images and media are ready
disclosures are present
CTAs are correct
redirect requirements are known
canonical considerations are known
tracking requirements are known
publishing sequence is known
publishing owners have the correct versions
rollback remains possible where required
Publishing Preparation Status:
Not Started
In Preparation
Ready
Partially Ready
Blocked
Returned For Revision
Human-Controlled Publication
An authorised human controls:
WordPress publication
page updates
URL implementation
redirect implementation
canonical implementation
navigation changes
menu changes
breadcrumb changes
internal-link publication
Content Brain does not autonomously publish cluster pages.
Outcome Recording
Cluster Name:
Cluster Version:
Hub Page:
Supporting Pages:
Action:
Created
Expanded
Strengthened
Corrected
Merged
Split
Rebuilt
Relinked
Refreshed
Partially Published
Published
Held
Failed
Cancelled
Action Owner:
Action Date:
Live URLs:
Known Issue:
Corrective Action:
Measurement Required:
Next Review Date:
Measurement
Possible cluster-level signals include:
indexation
search impressions
search clicks
average position
query coverage
hub traffic
supporting-page traffic
internal-link clicks
reader progression
page depth
organic sessions
affiliate progression
lead progression
conversion support
engagement
content decay
orphan-page count
broken-link count
duplicate-page signals
maintenance burden
Measurement Owner:
Measurement Source:
Primary Signal:
Secondary Signal:
Baseline:
Review Date:
Expected Outcome:
Observed Outcome:
Signal Quality:
Strong
Moderate
Weak
Insufficient
Unknown
Measurement Boundaries
Cluster performance should not be reduced to ranking movement alone.
A ranking change does not prove that cluster structure caused the result.
Possible contributing factors include:
content quality
source quality
search-demand change
competition
technical conditions
external links
site authority
internal links
freshness
algorithm changes
commercial relevance
Data Brain retains data-quality authority.
Experimentation Brain retains test-validity authority.
Cluster Review
Review:
whether the hub remains useful
whether supporting-page roles remain distinct
whether search intent has changed
whether audience needs have changed
whether pages are competing
whether pages are thin
whether information is outdated
whether claims remain valid
whether evidence remains current
whether internal links remain correct
whether commercial pathways remain appropriate
whether affiliate offers remain active
whether pages should be expanded, merged, split or retired
Cluster Review Decision:
Continue Monitoring
Strengthen Hub
Expand Cluster
Correct Pages
Relink Cluster
Merge Pages
Merge Clusters
Split Cluster
Refresh Evidence
Change Page Roles
Retire Pages
Retire Cluster
Archive
No Action
Expansion Rule
Expand a cluster only where:
a genuine audience need exists
a distinct search intent exists
a material content gap exists
new evidence requires separate treatment
a page would have a clear unique role
the cluster can be maintained
Do not expand merely because:
new keyword variations appear
competitors publish more pages
a tool suggests related topics
the cluster appears small
Consolidation Rule
Consolidate pages where:
search intent overlaps heavily
audience needs overlap heavily
content duplication is substantial
separate pages are thin
internal competition is likely
maintenance would improve
Consolidation Options:
Merge Into Hub
Merge Into Supporting Page
Create New Consolidated Page
Retire Duplicate Page
Redirect Old Page
Archive Old Page
Split Rule
Split a page or cluster where:
multiple distinct search intents are forced together
multiple audiences require different treatment
multiple commercial roles conflict
the page has become too broad to navigate clearly
separate evidence or compliance requirements apply
Retirement Rule
Retire a page or cluster where:
the topic is no longer relevant
the product or service no longer exists
the affiliate offer is retired
the evidence is no longer supportable
the content is duplicated elsewhere
the page creates avoidable risk
maintenance cost exceeds its value
Retirement must consider:
redirect requirements
internal-link updates
content preservation
archive needs
recovery needs
approval requirements
Lifecycle Decision
Possible lifecycle decisions include:
Monitor
Strengthen
Expand
Refresh
Correct
Relink
Merge
Split
Rebuild
Replace
Retire
Archive
No Action
Lifecycle Decision:
Reason:
Affected Pages:
Lifecycle Owner:
Required Action:
Approval Required:
Next Review Date:
Topic Cluster Planning Record
Cluster Name:
Request:
Website:
Section:
Primary Topic:
Topic Boundary:
Primary Audience:
Primary Search Journey:
Cluster Action:
Keyword Cluster:
Topic Cluster:
URL Cluster:
Hub Page:
Supporting Pages:
Shared Sources:
Shared Evidence:
Information-Gain Requirement:
Internal-Link Architecture:
Commercial Role:
Affiliate Role:
Conversion Role:
Search Review Status:
Specialist Review Status:
Approval Status:
Publishing Status:
Measurement Requirement:
Current Blocker:
Next Action:
Quick Topic Cluster Checklist
Topic need qualified: Yes / No
Existing content audited: Yes / No
Cluster action selected: Yes / No
Audience clear: Yes / No
Search intents mapped: Yes / No
Topic boundary clear: Yes / No
Keyword groups reviewed: Yes / No
Topic roles defined: Yes / No
URL roles defined: Yes / No
Hub required or not required: Yes / No
Hub role clear: Yes / No
Supporting-page roles distinct: Yes / No
Cluster size justified: Yes / No
Sources available: Yes / No
Evidence available: Yes / No
Information gain defined: Yes / No
Internal-link architecture defined: Yes / No
Commercial boundaries checked: Yes / No
Affiliate boundaries checked: Yes / No
Search review complete or not required: Yes / No
Specialist review complete or not required: Yes / No
Human approval complete: Yes / No
Publishing owner known: Yes / No
Measurement requirement known: Yes / No
No unresolved blocker: Yes / No
Quick Decision:
Ready For Production
Ready With Conditions
Audit Required
Research Required
Search Review Required
Specialist Review Required
Merge Required
Split Required
Hold
Reject
No Action
Failure Modes Prevented
This framework should prevent:
isolated pages with no clear role
unnecessary topic clusters
thin supporting pages
keyword-variation pages
duplicate topic coverage
unclear hub roles
unclear supporting-page roles
multiple competing hubs
search-intent conflicts
audience conflicts
keyword cannibalisation risk
forced internal links
orphan pages
deep content with no discovery path
unsupported claims
inconsistent evidence
misaligned commercial pathways
misaligned affiliate pathways
overbuilt clusters
unmaintainable clusters
outdated clusters
retired-offer pages remaining active
automated cluster creation without review
Operator Warnings
Do Not Start With A Keyword List
Begin with:
the audience need
the business purpose
the existing-content audit
the topic boundary
the search intent
Do Not Assume A Cluster Is Required
Some topics are best handled by one strong page.
Do Not Create One Page Per Keyword
Group queries by intent and audience need.
Do Not Force A Hub
A hub should have a genuine organising role.
Do Not Create Thin Spokes
Every supporting page must justify its separate existence.
Do Not Copy Competitor Structures
Competitor pages may help reveal patterns.
They do not define the correct MWMS structure.
Do Not Treat SERP Patterns As Permanent Rules
Search results can change.
Use current approved findings without treating them as guarantees.
Do Not Force Every Page To Link To Every Other Page
Internal links must remain relevant.
Do Not Treat Cluster Size As Authority
More pages do not automatically create stronger authority.
Do Not Treat Internal Links As Guaranteed Ranking Signals
Internal links may support discovery and understanding.
They do not guarantee rankings.
Do Not Hide Commercial Intent
Affiliate and commercial pathways must remain transparent.
Do Not Automate Yet
Do not activate:
automatic topic selection
automatic keyword clustering
automatic page-role creation
automatic cluster generation
automatic brief generation
automatic content generation
automatic internal linking
automatic publishing
workers
queues
AI Employees
Brain Room routing
automatic handoff
Approval Boundaries
HeadOffice controls governance and major structural decisions.
Strategy Brain controls strategic direction.
Research Brain controls broad research evidence and research truth.
Search Intelligence controls approved search analysis and search-opportunity findings.
Customer Brain controls approved customer intelligence.
Affiliate Brain controls affiliate offer direction and affiliate journeys.
Ads Brain controls paid campaign execution and campaign pathways.
Conversion Brain controls conversion strategy.
Compliance Brain controls compliance interpretation and risk decisions.
Finance Brain controls financial and budget authority.
Experimentation Brain controls test validity and interpretation.
Data Brain controls data quality and trusted measurement.
Content Brain controls cluster planning, content roles, briefing, production, editing, internal-link preparation and content lifecycle management within approved boundaries.
The authorised website owner or publishing owner controls final implementation.
Source-Of-Truth Rule
MCR remains the source of truth for:
Content Brain Canon
Content Brain Architecture
Content Brain Operating Model
Content Brain Workflow Map
Content Brain Topic Cluster And Hub Architecture Framework
Content Brain Internal Linking Strategy Framework
Content Brain SEO Content Brief Standard
Content Brain Publishing Readiness Checklist
approved cluster structures
approved page roles
approved content relationships
approved operating standards
This framework must not be replaced by:
keyword-tool exports
plugin suggestions
automated cluster generators
temporary site structures
unapproved operational pages
Supabase Position
Future structured cluster records may include:
request identity
website
cluster name
topic boundary
audience
search journey
cluster action
keyword groups
hub record
supporting-page records
URL records
page relationships
source references
evidence references
information-gain requirements
internal-link records
review status
approval status
publishing status
measurement requirements
lifecycle state
blockers
archive state
Supabase records must not replace:
the controlling framework
approved page content
human approval
website-owner authority
MCR source-of-truth pages
Plugin And UI Position
A future Topic Cluster workspace may eventually support:
request intake
existing-content audits
topic-boundary records
keyword-group records
search-intent mapping
hub decisions
supporting-page decisions
URL mapping
source linking
evidence linking
information-gain planning
internal-link architecture
brief creation
production tracking
review tracking
approval tracking
publishing preparation
measurement tracking
lifecycle management
No Topic Cluster workspace is authorised by this framework.
Manual use must first prove:
the required fields
the cluster-action values
the topic-boundary records
the search-intent records
the hub-role records
the supporting-page records
the URL relationships
the source and evidence requirements
the review flow
the approval flow
the measurement fields
the lifecycle decisions
Relationship To Content Brain SEO Content Brief Standard
The SEO Content Brief Standard defines page-level search briefing.
This framework defines the cluster-level role of each page.
The cluster architecture should inform each page brief.
Relationship To Content Brain Internal Linking Strategy Framework
The Topic Cluster And Hub Architecture Framework defines:
hub roles
supporting-page roles
topic relationships
cluster boundaries
The Internal Linking Strategy Framework governs the actual links connecting those pages.
Relationship To Content Brain Content Brief Template
Each hub and supporting page should use the appropriate brief.
The brief should preserve:
page role
audience
search intent
topic boundary
sources
evidence
information gain
internal-link requirements
review requirements
Relationship To Content Brain Publishing Readiness Checklist
Publishing readiness should confirm:
the correct page version is ready
the page role remains accurate
required internal links are present
URLs and metadata are correct
specialist review is complete
human approval is complete
publishing ownership is clear
Relationship To Affiliate Brain
Affiliate Brain controls:
offer direction
offer status
affiliate journey
offer destination
campaign requirements
Content Brain may structure affiliate-support content within approved clusters.
Relationship To Conversion Brain
Conversion Brain controls conversion strategy.
Content Brain may implement approved content pathways through cluster structure and internal links.
Relationship To Ads Brain
Ads Brain controls paid campaign execution.
Content Brain may provide approved supporting content and post-click content relationships.
Relationship To Research Brain
Research Brain controls broad research evidence and research truth.
Content Brain uses approved research outputs when defining cluster coverage and page requirements.
Relationship To Search Intelligence
Search Intelligence controls approved search findings.
Content Brain uses those findings to support:
intent mapping
query grouping
page-role decisions
content-gap identification
Relationship To Data Brain
Data Brain controls trusted measurement and data quality.
Content Brain records cluster outcomes and lifecycle signals.
Relationship To Experimentation Brain
Experimentation Brain controls controlled-test validity.
Content Brain may create approved cluster, page-role or internal-link variants.
Relationship To Content Brain Page Registry
This page should be recorded as:
Page Title: Content Brain Topic Cluster And Hub Architecture Framework
Document Type: Framework
Version: v2.1
Parent Page: Content Brain Canon
Status: Active
Migration Classification: MCR Source Of Truth
Plugin Or UI Candidate: Possible Topic Cluster Workspace Later
Notes: Controlling topic-cluster framework covering qualification, existing-content audits, topic boundaries, keyword-topic-URL alignment, hub and supporting-page roles, source and evidence requirements, information gain, internal-link architecture, production, review, approval, publishing preparation, measurement and lifecycle management.
Relationship To Content Brain Copy Map
This framework remains an MCR source-of-truth page.
Any future operational copy should:
simplify the framework for operator use
preserve cluster boundaries
preserve page-role decisions
preserve evidence requirements
preserve review and approval requirements
preserve lifecycle controls
not replace this framework
Relationship To mwmscontentbrain.site
A future operational Topic Cluster page may be created on mwmscontentbrain.site.
It must not be created until:
manual cluster planning is validated
the required fields are confirmed
the page-role system is confirmed
the review flow is confirmed
the approval flow is confirmed
lifecycle requirements are confirmed
migration is approved
source links are preserved
the operational page is validated
rollback remains possible
Current Framework Status
Prepared In MCR: Yes
Active Source Of Truth: Yes
Aligned With Content Brain Canon v1.1: Yes
Aligned With Content Brain Architecture v1.1: Yes
Aligned With Content Brain Operating Model v1.2: Yes
Aligned With Content Brain Workflow Map v1.2: Yes
Aligned With Content Brain SEO Content Brief Standard v1.1: Yes
Aligned With Content Brain Internal Linking Strategy Framework v1.1: Yes
Aligned With Content Brain Publishing Readiness Checklist v1.1: Yes
Aligned With Content Brain Page Registry v3.3: Yes
Aligned With Content Brain Copy Map v2.8: Yes
Migrated To mwmscontentbrain.site: No
Operational Copy Created: No
Connected To Full Plugin Or UI: No
Connected To Automatic Keyword Clustering: No
Connected To Automatic Topic Selection: No
Connected To Automatic Cluster Generation: No
Connected To Automatic Content Generation: No
Connected To Automatic Internal Linking: No
Connected To Publishing Automation: No
Connected To Workers: No
Connected To Queues: No
Connected To AI Employees: No
Connected To Brain Room Routing: No
Connected To Automatic Handoff: No
Drift Protection
The system must prevent:
this framework being treated as an operational page
this framework being replaced by keyword-tool exports
this framework being replaced by plugin suggestions
this framework being replaced by automated cluster generators
clusters being created without qualification
clusters being created without existing-content audits
one page being created for every keyword variation
thin supporting pages
unnecessary hub pages
multiple competing hubs
unclear topic boundaries
search-intent conflicts
audience conflicts
duplicate page roles
unsupported sources
unsupported claims
copied competitor structures
forced entity inclusion
forced internal links
forced commercial pathways
forced affiliate pathways
cluster size being treated as authority
page count being treated as authority
search-result patterns being treated as permanent rules
rankings being guaranteed
traffic being guaranteed
automatic topic selection
automatic keyword clustering
automatic page-role creation
automatic cluster generation
automatic brief generation
automatic content generation
automatic internal linking
automatic publishing
worker activation
queue execution
AI Employee activation
Brain Room routing
automatic handoff
Architectural Role
The Content Brain Topic Cluster And Hub Architecture Framework acts as the topic-relationship and content-system layer of MWMS.
Its role is to ensure that:
content roles are clear
related pages work together
audience journeys are supported
topic boundaries are controlled
search intents are separated where required
internal links remain purposeful
commercial pathways remain approved
affiliate pathways remain controlled
content systems remain maintainable
Architectural Intent
This framework exists to transform topic planning from:
keyword lists
isolated pages
copied competitor structures
uncontrolled content expansion
into:
qualified topic systems
clear audience roles
distinct page purposes
approved evidence requirements
useful internal relationships
controlled lifecycle management
Its intended progression is:
topic need
qualification
audit
cluster action
audience and intent
topic boundary
keyword review
topic design
URL design
hub role
supporting-page roles
sources and evidence
information gain
internal linking
production
review
approval
publication
measurement
lifecycle
The framework must create enough structure to prevent duplication and weak page roles without forcing unnecessary clusters or unnecessary pages.
The correct principle is:
the right topic boundary
the right page roles
the right number of pages
the right sources
the right internal relationships
the right review
the right lifecycle decision
Final Rule
Do not create or change a topic cluster until:
the topic need is qualified
existing content is audited
the cluster action is selected
the audience is clear
search intents are mapped
the topic boundary is clear
keyword groups are reviewed
topic roles are defined
URL roles are defined
the hub role is confirmed or deliberately rejected
supporting-page roles are distinct
the cluster size is justified
sources and evidence are available
information gain is defined
internal-link architecture is defined
commercial boundaries are checked
affiliate boundaries are checked
search review is complete where required
specialist review is complete where required
human approval is complete
publishing ownership is known
measurement requirements are known
Do not assume every topic requires a cluster.
Do not assume every cluster requires a hub.
Do not create one page for every keyword.
Do not create thin supporting pages.
Do not copy competitor structures.
Do not force entities or links.
Do not treat page count as authority.
Do not promise rankings or traffic.
Do not treat search review as human approval.
Do not treat publishing preparation as publication.
MCR remains the source of truth.
mwmscontentbrain.site remains the future operational environment.
Supabase remains the structured records layer.
Human approval and website-owner control remain mandatory.
No automatic topic selection is authorised.
No automatic keyword clustering is authorised.
No automatic cluster generation is authorised.
No automatic brief generation is authorised.
No automatic content generation is authorised.
No automatic internal linking is authorised.
No publishing automation is authorised.
No worker is authorised.
No queue execution is authorised.
No AI Employee is authorised.
No Brain Room routing is authorised.
No automatic handoff is authorised.
Change Log
Version: v2.1
Date: 2026-06-16
Author: HeadOffice
Change: Expanded the Content Brain Topic Cluster And Hub Architecture Framework to align with the complete Content Brain request-to-lifecycle workflow.
Added:
topic-need qualification
existing-content and cluster audits
cluster-action decisions
audience mapping
search-intent mapping
search-intent separation rules
topic-boundary controls
keyword-cluster records
topic-cluster records
URL-cluster records
keyword-topic-URL alignment checks
hub-page decision controls
supporting-page role controls
cluster-size decisions
information-gain requirements
entity-coverage controls
source and evidence requirements
source classification
research requirements
Search Intelligence requirements
internal-link architecture
orphan-page controls
commercial integration
affiliate integration
conversion integration
Ads Brain integration
Experimentation Brain boundaries
content-project structure
production sequencing
briefing requirements
content-production controls
page-level editing
cross-cluster quality control
search review
specialist review
human approval
material-change controls
publishing preparation
human-controlled publication
outcome recording
measurement boundaries
cluster review
expansion rules
consolidation rules
split rules
retirement rules
lifecycle decisions
topic-cluster planning records
quick operational checklist
future Supabase record position
future Topic Cluster workspace position
expanded relationships to other Brains and standards
expanded drift protection
Clarified that:
a topic cluster should exist only where multiple distinct content roles are justified
one strong page may be appropriate for some topics
a hub is not required for every topic group
keywords do not determine page count
one page may serve multiple closely related queries
pages should be separated where intent or audience role is materially different
pages should be combined where overlap is substantial
clusters should use the smallest justified number of pages
supporting pages must provide distinct value
information gain must be defined
entity coverage must remain relevant
internal links must not be forced
page count does not guarantee authority
cluster structure does not guarantee rankings or traffic
search review is not human approval
publishing preparation is not publication
implementation remains human controlled
Version: v2.0
Date: 2026-05-02
Author: HeadOffice
Change: Upgraded Topic Cluster Framework to include keyword-versus-topic-versus-URL cluster distinction, search-results alignment, entity coverage, information-gain integration and testing controls.
Change Impact Declaration
Pages Created:
None
Pages Updated:
Content Brain Topic Cluster And Hub Architecture Framework
Pages Deprecated:
None
Pages Permanently Deleted:
None
Registries Requiring Update:
Content Brain Page Registry
Content Brain Copy Map
Canon Version Update Required:
No
Architecture Version Update Required:
No
Operating Model Version Update Required:
No
Workflow Map Version Update Required:
No
Automation Status Change:
No
Plugin Or UI Status Change:
No
Automatic Topic Selection Status Change:
No
Automatic Keyword Clustering Status Change:
No
Automatic Cluster Generation Status Change:
No
Automatic Content Generation Status Change:
No
Automatic Internal Linking Status Change:
No
Publishing Automation Status Change:
No
Worker Status Change:
No
Queue Status Change:
No
AI Employee Status Change:
No
Brain Room Routing Status Change:
No
Automatic Handoff Status Change:
No
END CONTENT BRAIN TOPIC CLUSTER AND HUB ARCHITECTURE FRAMEWORK v2.1
END OF FULL FILE OUTPUT