Implementing Cluster SEO — Passing Pillar Primary to Spoke Secondary

The HUMAN_INPUT marker mentioned in this article is a placeholder used by AI writing skills to indicate areas where a human should later confirm or fill in a specific value (e.g., <!-- HUMAN_INPUT: Enter numerical value -->).

When operating multiple pillars and spokes for owned media, the focus of SEO shifts. It moves from individual article optimization to maintaining the keyword relationships across a group of articles. This is the mindset shift of “cluster SEO.”

By placing a pillar’s primary keyword at the center of a cluster and passing it down to spokes as secondary keywords, the articles form a keyword hierarchy. Instead of individual articles competing for the same keywords (internal cannibalization), each article takes responsibility for a specific layer in the keyword structure.

In Yakumo’s content pipeline, @seo-director (an advisor agent responsible for SEO strategy) maintains this keyword map at the cluster level. This article explains the design of cluster SEO, specifically passing pillar primary keywords to spoke secondary keywords, and its implementation in the new-article-spoke.json pipeline.

→ For information on connecting advisor agents to integrate the SEO strategy layer into the pipeline, see Pipeline Strategy Layer Design.

From Article-Level Optimization to Cluster-Level Keyword Management

Previously, SEO was considered independently for each article. For each spoke, a person would set keywords and decide which search queries the article should target. This approach leads to keyword overlap between articles in the same cluster, creating a situation where multiple articles compete for the same search intent in Google’s eyes.

Internal cannibalization disperses the SEO strength of the entire cluster. If three articles compete for the same keyword, each receives only a diluted evaluation. It is more effective for the cluster’s overall traffic if a single article receives a high evaluation.

Cluster SEO solves this problem through design. The pillar carries the keyword axis of the cluster, and spokes receive the pillar’s secondary keywords as their primary keywords, creating a hierarchical keyword structure for the entire cluster.

The Concept of Cluster SEO — Designing Keyword Hierarchies

Why a Pillar’s Primary Keyword Becomes the Cluster Axis

The pillar is the “entrance” to the cluster. It is the first article a reader lands on when they become interested in a topic and functions as an internal link hub. Because of this positioning, the pillar’s primary keyword is selected from search phrases with the highest search volume that represent the cluster.

In the case of the mcluhan cluster (themed around owned media pipeline design):

• Pillar primary keyword: content cluster persona (tech cluster side), owned media AI operation (business cluster side)
• This keyword becomes the axis for the entire cluster.

Spokes handle the sub-concepts of this axis. By including the pillar’s primary keyword in the spoke’s secondary keywords, the spoke declares its relationship as a detailed article extending from the pillar.

Designing the Inclusion of Pillar Primaries in Spoke Secondaries

In the spoke’s brief YAML, the primary keyword of the parent pillar is always included as one of the secondary_keywords:

# Example of a spoke's brief YAML
slug: 2026-05-cluster-persona-outer-inner-axis
seo:
  primary_keyword: "pillar narrative design audience"   # Spoke-specific keyword
  secondary_keywords:
    - "content cluster persona"   # Inherited from parent pillar's primary
    - "content SSOT persona taxonomy"

This design has two effects. First, it makes it easier for Google to recognize the spoke as a related article to the pillar. Since both the internal link structure and keyword relationships point to the pillar, the cluster’s overall evaluation improves. Second, it prevents the spoke from “stealing” the pillar’s keywords. The spoke only holds the pillar’s primary keyword as a “secondary (support)” and has its own narrower primary keyword.

Preventing Internal Cannibalization

The most important consideration in cluster SEO design is preventing articles within the same cluster from having the same primary keyword.

When designing keywords for a new spoke, @seo-director checks existing pillar and spoke primary_keyword values for overlaps. Specifically:

• Does the candidate primary_keyword for the new spoke match an existing article’s primary_keyword exactly?
• Is the search intent of the candidate keyword the same as an existing article (e.g., “AI pipeline design” and “AI pipeline architecture” are effectively the same)?

Comparing current frontmatter reveals what happened during the period when articles were written without an SEO strategy. While there were 0 cases of exact duplicate primaryKeyword out of 50 articles, numerous cases of stem-level proximity occurred. For example, six spokes under mcluhan-engine had keywords containing “pre-publish gate” (pre-publish-gate-proximity, gate-false-positive-balance, allow-list-brand-check, brand-rule-automation, persona-gate-validation, blog-gate-strategic-validation). Ten articles contained “owned media,” and eleven contained “AI agent.” Even at the primary_keyword level, pairs with matching stems like “pre-publish gate design” and “pre-publish gate false positive” existed. While these don’t compete for the exact same SERP, they are the result of spokes written without @seo-director simply repurposing the parent pillar’s secondary_keyword as their own primary. blog-ops/retros/2026-05-18-seo-missing-from-pipeline.md also records that SEO perspectives (primary_keyword, related keywords) were completely missing from the briefs of three pillars (reset-timeline, mcluhan, bateson).

Specific Structure of the Keyword Map

The current mapping for the mcluhan cluster (pillar = 2026-05-mcluhan-engine) is as follows. The pillar’s primary is “Content Operation Engine Design State Machine,” and its secondaries are “AI Article Pre-publish Gate Automation,” “Owned Media Pipeline Quality Check,” and “Content SSOT Frontmatter Management.”

Two things can be observed. First, the design where the pillar’s secondary “AI Article Pre-publish Gate Automation” flows down to multiple spoke primaries like “pre-publish gate design” and “pre-publish gate false positive” is partially established. Second, the primary_keyword is unset for 6 out of 12 spokes. These are articles written before @seo-director was integrated into Phase 0 of the pipeline; the policy is to fill these in during rewrites.

Designing the Brief YAML SEO Section as SSOT

The keyword map is designed so that the SEO section of each brief YAML functions as the SSOT (Single Source of Truth). We do not maintain keyword lists in Excel or in people’s heads.

Each spoke’s brief contains:

seo:
  primary_keyword: "{Unique keyword for this spoke}"
  secondary_keywords:
    - "{Parent pillar's primary keyword}"
    - "{Related keywords}"
  longtail_clusters:
    - "{Specific search queries the spoke answers}"

@seo-director looks at this structure across the cluster to manage keyword duplication, competition, and gaps. When adding a new spoke, @seo-director reviews all existing brief SEO sections before proposing keywords.

Keyword Map Maintenance Responsibilities of seo-director

Cluster-Level Keyword Map Management

The responsibility of @seo-director is not “setting keywords for a single article” but “maintaining keyword relationships for a cluster.”

Specifically:

• When adding a new pillar: Design the keyword axis for the cluster and organize keyword relationships with existing articles in the cluster.
• When adding a new spoke: Select primary candidates from the parent pillar’s secondary_keywords and check for overlaps with existing spokes.
• When rewriting an existing spoke: Refer to the keyword’s current search intent and traffic data to determine if a primary_keyword change is necessary.

By calling @seo-director at these three timings, the cluster’s keyword structure can grow while maintaining consistency.

When the @seo-director keyword <slug> mode is called, the agent follows these steps to generate and return a draft SEO section:

1. Collect all existing brief YAMLs under blog-ops/articles/ and check primary_keyword values in use (cannibalization avoidance).
2. Confirm the article track’s audience and value proposition in blog-ops/config/audience-tracks.json.
3. Generate and return a YAML SEO section including primary_keyword, secondary_keywords, longtail_clusters, search_intent, serp_title_finalized, serp_description_finalized, and cluster_position.

The main-thread writes this draft to blog-ops/output/rewrite/{slug}/00_seo.yaml and, after confirmation, integrates it into the brief YAML.

Currently, overlap checking is implemented as an LLM-based judgment by @seo-director, not a deterministic script. Rules G1–G14 in scripts/blog-gate.ts do not include checks for keyword overlap (SEO-related checks only include G11: “Missing SEO section in pillar article briefs”). The design calls @seo-director in Phase 0 of blog-ops/config/pipelines/new-article-spoke.json to “confirm cannibalization avoidance and intent differentiation within the cluster.” Step 1 of .claude/agents/seo-director.md also mentions checking primary_keyword usage via Glob, but this is a natural language instruction for the LLM agent, not a deterministic gate. In the future, a G-rule (perhaps G15) could be added to blog-gate.ts to mechanically detect exact primary_keyword matches or N or more stem matches within a cluster.

Keyword Assignment Procedure for New Spokes

When adding a new spoke, @seo-director proposes keywords through these steps:

1. Retrieve seo.secondary_keywords from the parent pillar’s brief.
2. Cross-reference with the seo.primary_keyword list of existing spokes to identify unused secondary keywords.
3. Propose the unused secondary keyword that best aligns with the spoke’s topic as the primary candidate.
4. Propose 3–5 longtail_clusters as specific search queries (e.g., “How to…” or “Method for…”).

Integration of seo-director as Pipeline Phase 0

In new-article-spoke.json, @seo-director is launched in Phase 0:

{
  "phase": 0,
  "step": "seo",
  "kind": "agent",
  "runner": "@seo-director",
  "model": "sonnet",
  "trigger": "At the start of the pipeline. The main-thread calls @seo-director to receive a draft.",
  "depends_on": [],
  "description": "SEO design for the spoke. Recommend selecting the spoke's primary_keyword from the parent pillar's secondary_keywords. Confirm cannibalization avoidance and intent differentiation within the cluster.",
  "input": {
    "slug": "{slug}",
    "parent_pillar_slug": "{parent_pillar_slug}",
    "parent_pillar_brief": "blog-ops/articles/{parent_pillar_slug}.yaml",
    "audience_tracks": "blog-ops/config/audience-tracks.json",
    "existing_articles": "src/content/magazine/**/*.md"
  }
}

Phase 0’s input.parent_pillar_brief is designed to receive the parent pillar’s brief as input. @seo-director uses this input to retrieve seo.secondary_keywords and proposes a primary keyword for the new spoke while avoiding overlap with existing spokes in the cluster. By referencing the pillar’s secondary keywords, the agent can identify “unexplored areas” in the pillar and design spokes to fill those gaps.

The output of Phase 0 is written to blog-ops/output/rewrite/{slug}/00_seo.yaml, and Phase 1 (blog-plan) integrates it into the brief YAML as the SEO section. Due to this dependency (depends_on: ["seo"]), spokes without an SEO section cannot proceed to Phase 1 or beyond.

Conclusion — From Article-Level to Cluster-Level SEO

SEO for owned media should proceed in the order of “designing the cluster’s keyword structure before writing articles,” rather than “writing an article and then fitting keywords to it.”

To summarize the design elements of cluster SEO:

1. Pillar Primary Keyword = Cluster Axis: The pillar has a primary keyword representing the cluster, serving as the cluster’s semantic center.
2. Spoke Secondaries Inherit Pillar Primary: Spokes declare their relationship with the pillar’s keywords as secondaries, forming the cluster’s keyword hierarchy.
3. @seo-director Maintains the Cluster Level: Every time a new article is added, the agent checks the keyword map for the entire cluster to prevent duplication and competition.
4. Brief YAML as Keyword Map SSOT: Instead of Excel or memory, the SEO section of each brief serves as the sole source of truth for keyword relationships.

In an AI-driven production environment, faster article generation increases the risk of keyword competition. Having a structure that calls @seo-director at the start of the pipeline (Phase 0) to design keywords before writing is a prerequisite for maintaining the cluster’s SEO strength.

→ For a business design perspective on utilizing the mcluhan engine as an overall content strategy, see Improving Owned Media with the mcluhan Engine.

→ For the background on why cluster SEO design became necessary — specifically the reality of internal link decay and keyword competition discovered after a bulk release of 48 articles — see The Story of Retreating from an AI-Generated Blog in One Week.

→ For the design of automated gates that fail articles with missing personas, which is another SSOT alongside keywords in cluster SEO, see Designing Automated Gates to Fail on Missing Persona.