$ man content-wiki/content-clustering-architecture

Content clustering is the deliberate architecture of how content connects within and across websites. Individual pages are nodes. Internal links and cross-references are edges. The topology determines how authority flows through the graph. A flat blog with no internal linking means every page starts from zero — no authority passes between pieces. A cluster topology with bidirectional links 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 over sites with isolated content.

PATTERN

One parent concept serves as the hub. Specialized verticals branch as spokes. The hub covers the meta-narrative — the process of building. The spokes cover the outputs — what the process produces. Each spoke builds deep authority in one vertical. The hub connects the verticals into a unified graph. Cross-site links between hub and spokes signal to search engines that these sites are one entity covering different facets of the same expertise. The key is that each site content proves the other sites thesis. The building process IS hub content. The workflows produced ARE spoke content. The methodology of creating content IS the other spoke. The recursion is structural, not accidental.

CODE

Define the topology in a version-controlled taxonomy file. Map every content pillar to a domain. Map routing rules explicitly: personal stories go to the hub, GTM systems go to spoke one, content strategy goes 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. The lifecycle — draft, review, final, published, archived — applies uniformly across all domains. The taxonomy routes by pillar, not by platform or format.

PATTERN

Every shared content entry gets a canonical site field designating which domain renders it natively. When a how-to guide has its canonical set to a spoke site, it renders on that spoke and generates a redirect from the hub. The hub does not duplicate spoke content — it routes to it. This prevents duplicate content penalties while maintaining the cross-site graph. In a monorepo setup, all sites import the same data package. The canonical designation is a field on the data object, not a DNS or CMS configuration. Changing which site owns a piece of content means changing one field value.

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 entry, populate its related array with existing entry IDs. Then update those existing entries 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 automatically. 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. BreadcrumbList schema markup in JSON-LD tells AI engines exactly where a page sits in your hierarchy. A guide on a spoke site gets breadcrumbs that communicate the spoke is the authority for that topic. Cross-site breadcrumbs combined with sameAs schema connecting the domains signal a multi-site cluster, not three independent blogs. This is how you build entity count. The breadcrumb protocol becomes a forward-referencing navigation system where each page knows its position in the topology and signals that position to machines.