$ man how-to/content-cluster-strategy

A content cluster topology is the deliberate architecture of how content connects within and across websites. Individual pages are nodes. Cross-references and internal links are edges. The topology determines how authority flows through the graph. A flat blog with no internal links is a collection of disconnected nodes — each page starts from zero. A cluster topology with bidirectional links, shared vocabulary, and explicit hierarchy creates a graph where every new page strengthens every existing page. AI engines evaluate topical authority by measuring this graph. Sites with comprehensive, interconnected coverage of a topic get preferential citation.

PATTERN

Define one parent concept as the hub. Branch specialized verticals as spokes. The hub site covers the meta-narrative — the process of building. Spoke sites cover the outputs — what the process produces. In a three-site architecture: the hub (shawnos.ai) covers building with AI and the system-building journey. Spoke one (thegtmos.ai) covers the GTM workflows the system produces. Spoke two (thecontentos.ai) covers the content methodology the system demonstrates. The recursive structure is the point. Each site content proves the other two sites thesis. The act of building IS the hub content. The workflows produced ARE spoke one content. The methodology of creating content IS spoke two content.

CODE

Define the topology in a version-controlled taxonomy file, not in someone head. Map every content pillar to a domain. Map routing rules explicitly: personal stories route to the hub, GTM systems route to spoke one, content strategy routes to spoke two. Cross-domain posts get a primary domain plus cross-links to siblings. The taxonomy file becomes the single source of truth for content placement. Any team member, any AI agent, any automation skill can read the file and know where content belongs. Status lifecycle (draft, review, final, published, archived) applies uniformly across all domains.

PATTERN

Every shared content entry gets a canonicalSite field designating which domain renders it natively. When a how-to guide has canonicalSite set to gtmos, it renders on thegtmos.ai and generates a redirect from shawnos.ai. The hub does not duplicate spoke content — it routes to it. This prevents duplicate content penalties while maintaining the cross-site graph. All three sites import the same TypeScript data package. The canonical designation is a field on the data object, not a DNS or CMS configuration. Adding a new cross-site entry means setting one field. The monorepo handles the rest.

PATTERN

Every new entry must link to existing related entries. Every existing entry that relates to the new one must link back. This creates bidirectional edges in the content graph. No dead ends, no orphans. The implementation is simple: related arrays on every data object. When you add a new how-to guide, populate its related array with existing guide IDs. Then update those existing guides to include the new ID in their related arrays. The template pages render these arrays as clickable links. Programmatic internal linking handles mention-level connections. The result is a graph where you can reach any node from any other node within two or three clicks.

PRO TIP

Breadcrumbs are not just navigation — they are topology signals. BreadcrumbList schema markup in JSON-LD tells search engines and AI engines exactly where a page sits in your hierarchy. A how-to guide on gtmos gets breadcrumbs: GTMOS, How-To, Content Cluster Strategy. This communicates that gtmos is the authority site for this topic. Cross-site breadcrumbs tell AI engines that the hub and spokes are part of one entity. Combined with sameAs schema connecting the three domains, the breadcrumb hierarchy signals a multi-site cluster, not three independent blogs. AI engines with 15 or more recognized entities have 4.8x higher citation probability. The cluster architecture is how you build entity count.