Claude SEO Strategy: Build a Workflow with Loops

Claude is useful for SEO strategy when it stops acting like a prompt box and starts acting like a workflow layer. The real advantage comes from loops: clean inputs, repeatable analysis, scoring, briefs, QA gates, publishing decisions, and visibility feedback.

This guide shows how to build a practical Claude SEO strategy for advanced teams that work with data, templates, content systems, AI visibility, and approval workflows. The goal is not more content. The goal is better decisions moving through a controlled system.

Claude Is Not the Strategy, It Is the Workflow Layer

A strong Claude SEO strategy does not start with “write me a blog post.” It starts with a system that decides what Claude is allowed to analyze, what it can suggest, what it must verify, and what a human has to approve before anything moves forward.

Claude is most useful when it sits between your SEO inputs and your execution layer. It can read exports, classify opportunities, generate structured briefs, review content against rules, summarize performance, and suggest the next loop. But the strategy still comes from your data model, your scoring logic, your business priorities, and your publishing standards.

For advanced SEO systems, the difference is simple:

• Weak use: Claude produces ideas from a prompt.
• Strong use: Claude processes approved inputs through a repeatable workflow.
• Controlled use: Claude cannot move work forward unless the required checks pass.

That control matters because SEO strategy has state. A page can be researched, approved, drafted, reviewed, refreshed, consolidated, noindexed, submitted, indexed, or monitored. If Claude treats every task as a fresh conversation, the workflow breaks. If Claude works inside a defined loop, every output becomes an input for the next decision.

A simple loop can look like this:

seo_loop:
inputs:
  - gsc_export
  - ai_visibility_export
  - page_inventory
  - competitor_list
claude_tasks:
  - classify_demand
  - identify_visibility_gaps
  - score_opportunities
  - create_briefs
  - review_against_qa_rules
  - summarize_next_actions
human_gates:
  - approve_priority
  - approve_brief
  - approve_publish
  - approve_outreach
outputs:
  - opportunity_queue
  - content_brief
  - qa_report
  - weekly_action_plan

This is where Claude becomes strategically useful. It is not replacing SEO judgment. It is reducing the manual drag between analysis and action.

The practical rule is this: do not ask Claude to “do SEO.” Give it a defined role inside the loop. One role can analyze GSC demand. Another can compare AI visibility gaps. Another can draft briefs. Another can verify that the page meets your rules.

The workflow layer is what keeps quality high. Claude accelerates the work, but the loop decides what matters, what ships, and what gets improved next.

Start With a Data Contract Before You Ask Claude Anything

Claude can only build a useful SEO workflow if the inputs are stable. Before you ask it to analyze keywords, score pages, or create briefs, define the data contract it must work from.

A data contract is the agreed structure for the information entering the loop. It tells Claude what each field means, which fields are required, how topics are grouped, and which outputs are allowed. Without it, every analysis becomes a one-off interpretation of a messy export.

For a serious Claude SEO strategy, the minimum contract should include search, page, visibility, and business fields.

{
"url": "/blog/claude-seo-strategy",
"template": "blog_guide",
"topic_cluster": "ai-seo-workflows",
"primary_query": "claude seo strategy",
"clicks_28d": 120,
"impressions_28d": 9400,
"ctr": 0.012,
"avg_position": 11.4,
"ai_visibility_status": "weak",
"competitors_cited": ["competitor-a.com", "competitor-b.com"],
"business_priority": 4,
"current_page_state": "refresh_candidate"
}

Google Search Console gives you the demand layer: clicks, impressions, average CTR, and average position over a selected period. It can also show query and page-level performance, which makes it useful for spotting demand shifts, weak CTR, and ranking distance before you ask Claude to interpret anything.

The contract should also include fields that do not come from GSC. For modern SEO and GEO workflows, you need AI visibility status, competitor visibility, page template, funnel stage, target entity, conversion relevance, and current page state. These fields help Claude understand whether a URL needs a new brief, a refresh, a stronger answer block, internal links, or no action.

A clean contract also protects the workflow from vague AI output. Instead of asking, “What should we do with these pages?” you can ask Claude to return only approved action types:

allowed_actions:
- create_new_page
- refresh_existing_page
- improve_title_meta
- add_answer_block
- strengthen_internal_links
- consolidate_duplicate
- keep_monitoring
- exclude_from_indexable_queue

This matters even more when the site has hundreds or thousands of URLs. Claude should not decide from prose. It should classify from fields.

The practical setup is simple:

data/
gsc_queries_28d.csv
gsc_pages_28d.csv
ai_visibility.csv
page_inventory.csv
competitor_mentions.csv

outputs/
opportunity_queue.csv
briefs/
qa_reports/

Start every loop by validating the inputs before analysis. Are the required columns present? Are URL formats consistent? Are query clusters mapped? Are template types known? Are empty rows removed? Has the same date window been used across sources?

Claude can help with this validation, but the schema should belong to your team. The data contract is the rulebook. Claude is the operator inside it.

Build the First Loop Around Search Demand

The first useful loop in a Claude SEO strategy should not be content generation. It should be demand classification.

Start with Search Console because it gives Claude a grounded view of how people already discover the site: queries, pages, clicks, impressions, CTR, and average position. The job is not to ask Claude, “What keywords should we target?” That is too loose. The better task is to give Claude a cleaned 28-day export and ask it to classify opportunity patterns.

The first demand loop should look for five signals:

• Striking-distance queries: positions 8 to 20 with relevant impressions.
• High-impression, low-CTR pages: pages that may need title, meta, intent, or SERP-fit improvements.
• Decaying pages: URLs losing clicks or impressions compared with the previous period.
• Rising query clusters: topics gaining impressions before the site has a strong page.
• Intent mismatch: pages ranking for queries they do not fully answer.

Before Claude sees the file, normalize the export. This keeps the model focused on interpretation instead of cleaning obvious spreadsheet noise.

import pandas as pd

gsc = pd.read_csv("gsc_queries_28d.csv")

required_columns = [
  "query",
  "page",
  "clicks",
  "impressions",
  "ctr",
  "position"
]

missing = [col for col in required_columns if col not in gsc.columns]
if missing:
  raise ValueError(f"Missing required columns: {missing}")

gsc = gsc.dropna(subset=["query", "page"])
gsc["ctr"] = gsc["ctr"].astype(float)
gsc["position"] = gsc["position"].astype(float)

gsc["opportunity_signal"] = "monitor"

gsc.loc[
  (gsc["position"].between(8, 20)) & (gsc["impressions"] >= 500),
  "opportunity_signal"
] = "striking_distance"

gsc.loc[
  (gsc["impressions"] >= 1000) & (gsc["ctr"] < 0.01),
  "opportunity_signal"
] = "high_impression_low_ctr"

gsc.to_csv("gsc_demand_normalized.csv", index=False)

Now Claude can work from a cleaner artifact. The prompt should force structured output:

Analyze this normalized GSC export.

Return a CSV-ready opportunity table with:
- opportunity_signal
- query_cluster
- affected_url
- likely_reason
- recommended_action
- confidence
- why_this_matters

Allowed recommended_action values:
- improve_title_meta
- refresh_existing_page
- create_supporting_page
- expand_answer_section
- consolidate_duplicate_intent
- monitor_only

Do not recommend a new page unless the query cluster has clear intent separation from the existing URL.

That last line matters. Without it, Claude will usually create more pages than the site needs. For large SEO systems, the goal is not to inflate the roadmap. The goal is to separate real demand from noise.

The output should be an opportunity queue, not a report. A report explains what happened. A queue tells the team what to do next.

opportunity_signal,query_cluster,affected_url,likely_reason,recommended_action,confidence
striking_distance,claude seo strategy,/blog/ai-seo-workflows,topic partially covered,expand_answer_section,0.82
high_impression_low_ctr,seo workflow automation,/blog/seo-automation,title does not match intent,improve_title_meta,0.76

Once this loop runs weekly, Claude can compare patterns over time. Which query clusters keep rising? Which templates keep producing low CTR? Which pages repeatedly sit near page one but never break through?

That is where the workflow starts to become strategic. Claude is no longer generating ideas from thin air. It is classifying search demand into repeatable action types.

Add an AI Visibility Loop, Not Just Ranking Data

Search demand tells you what people look for. AI visibility tells you whether your brand, pages, and proof points are showing up when answers are synthesized.

That distinction matters. A page can rank, get impressions, and still fail inside AI search if the brand is not mentioned, the page is not cited, or competitors are used as the supporting sources. A modern Claude SEO strategy should therefore run a second loop around AI visibility, not just rankings.

The input should be simple at first:

{
"topic_cluster": "claude-seo-strategy",
"buyer_prompt": "how to use claude for seo strategy",
"brand_visible": true,
"brand_position": "mentioned_not_recommended",
"brand_pages_cited": ["/blog/claude-seo-strategy"],
"competitors_visible": ["competitor-a", "competitor-b"],
"visibility_status": "weak",
"likely_gap": "page explains the topic but lacks a concise answer block and external corroboration",
"next_action": "strengthen_answer_fit"
}

Some search platforms now separate classic search visibility from generative AI visibility, including signals such as impressions, pages, countries, citation activity, grounding queries, page-level citation data, and visibility trends where available.

That does not mean the data is complete. Treat AI visibility as a directional signal. The loop should classify patterns, not pretend to measure the entire AI search universe.

For each important topic, ask Claude to return a structured diagnosis:

Review this AI visibility export.

For each topic_cluster, return:
- visibility_status: strong, weak, none, inconsistent
- brand_visible: true or false
- competitors_visible
- cited_brand_pages
- missing_source_types
- likely_reason
- recommended_action

Allowed recommended_action values:
- create_answer_block
- refresh_existing_page
- add_comparison_section
- strengthen_entity_signals
- add_evidence_or_sources
- pursue_citation_gap
- monitor_only

The useful output is not “we need more AI visibility.” That says nothing. The useful output is a mapped action:

• Weak visibility + strong existing page: improve answer structure, entity clarity, and supporting proof.
• No visibility + high buyer intent: create or rebuild the page around the decision being made.
• Competitors visible + brand absent: inspect cited source types and build a citation gap loop.
• Visible but not recommended: sharpen positioning, comparison logic, and trust signals.
• Cited page is wrong: fix internal linking, canonical signals, and topical structure.

For large sites, the AI visibility loop should run by prompt category, not by random prompt list. Group prompts by buyer job, page type, product category, comparison need, and funnel stage. That makes the output useful for page architecture, not just reporting.

Claude’s role is to normalize messy AI visibility observations into decisions the team can act on. It should identify whether the next move is content, structure, corroboration, internal linking, or monitoring.

The key is to keep the loop connected to search demand. AI visibility without demand can become vanity monitoring. Search demand without AI visibility can miss where discovery is moving. Together, they give Claude a better strategic surface to work from.

Merge Demand and AI Visibility Into One Opportunity Queue

The merge is where a Claude SEO strategy becomes useful for execution. Search demand alone can push the team toward pages that get impressions but do not change brand visibility. AI visibility alone can push the team toward prompts that look important but have weak search demand. The opportunity queue prevents both problems.

Search demand gives you query and page-level pressure: clicks, impressions, CTR, and average position. AI visibility adds whether the brand appears, which competitors are named, which pages are cited, and where the brand is missing from synthesized answers. These are different signals, so they should not live in separate reports.

The simplest merge key is topic_cluster. For larger systems, use a stronger join layer:

• topic_cluster
• intent_type
• page_template
• funnel_stage
• primary_entity
• canonical_url

That prevents Claude from merging unrelated rows just because two queries share similar words.

import pandas as pd

gsc = pd.read_csv("outputs/gsc_demand_normalized.csv")
ai = pd.read_csv("data/ai_visibility.csv")
inventory = pd.read_csv("data/page_inventory.csv")

merged = (
  gsc
  .merge(ai, on=["topic_cluster", "intent_type"], how="left")
  .merge(inventory, on="canonical_url", how="left")
)

merged["ai_visibility_status"] = merged["ai_visibility_status"].fillna("unknown")
merged["competitors_visible"] = merged["competitors_visible"].fillna("")

Once the data is joined, Claude should not be asked for a general opinion. Give it decision rules.

def classify_opportunity(row):
  high_demand = row["impressions"] >= 3000
  near_page_one = 8 <= row["position"] <= 20
  weak_ai = row["ai_visibility_status"] in ["weak", "none", "inconsistent"]
  has_page = pd.notna(row["canonical_url"])

  if high_demand and weak_ai and has_page:
      return "refresh_for_search_and_ai_visibility"

  if high_demand and weak_ai and not has_page:
      return "create_new_decision_page"

  if high_demand and row["ctr"] < 0.01 and has_page:
      return "improve_serp_fit"

  if near_page_one and has_page:
      return "expand_existing_page"

  return "monitor"

merged["recommended_action"] = merged.apply(classify_opportunity, axis=1)
merged.to_csv("outputs/opportunity_queue.csv", index=False)

Now Claude has a real queue to interpret. The output should explain why each item matters, but the action types should stay controlled.

Review opportunity_queue.csv.

For each topic_cluster, return:
- recommended_action
- affected_url
- demand_reason
- ai_visibility_reason
- competitor_context
- business_risk
- next_artifact_needed

Allowed next_artifact_needed values:
- refresh_brief
- new_page_brief
- title_meta_test
- internal_link_plan
- answer_block_update
- citation_gap_review
- monitor_only

The priority logic should be practical:

• High demand + weak AI visibility: usually the strongest opportunity.
• High demand + strong AI visibility: protect, improve CTR, and strengthen conversion.
• Low demand + weak AI visibility: monitor unless the topic has high commercial value.
• Strong rankings + missing AI visibility: improve answer-fit, entity clarity, and corroboration.
• Competitors visible + brand absent: move the topic into citation gap review.

This also helps avoid page bloat. Claude should not turn every weak signal into a new URL. Sometimes the right action is a better answer block, a title/meta rewrite, stronger internal links, a comparison section, or consolidation.

The queue is the operating artifact. Briefs, QA checks, publishing decisions, and reporting should all start from it. When the merge is clean, Claude is not guessing what SEO work matters. It is translating demand and visibility gaps into controlled next actions.

Score Opportunities Before Claude Writes Briefs

Claude should not write a brief for every keyword, page, or prompt it finds. That creates content bloat. The better move is to score every opportunity before it reaches the briefing stage.

This is where the workflow becomes strategic. GSC metrics can show clicks, impressions, CTR, and average position, but those metrics do not automatically tell you what to build next. A query with high impressions may need a title rewrite. A page losing traffic may need a refresh, consolidation, or no action at all.

The scoring layer gives Claude a decision frame. It should rank opportunities using defined weights, not vibes.

A practical scoring model can include:

• Demand score: impressions, clicks, and query growth.
• Ranking gap score: how close the page is to meaningful visibility.
• AI visibility gap score: whether the brand is weak, absent, or inconsistent in AI answers.
• Business value score: how close the topic is to revenue.
• Content effort score: how hard the page will be to create or refresh.
• Citation gap score: whether competitors are supported by sources where the brand is missing.
• Indexation risk score: whether the URL type should even be indexable.

Keep the weights outside Claude. Let Claude explain and classify, but do not let it invent the prioritization model every week.

def score_opportunity(row):
  score = (
      row["demand_score"] * 0.25 +
      row["ranking_gap_score"] * 0.20 +
      row["ai_visibility_gap_score"] * 0.20 +
      row["business_value_score"] * 0.20 +
      row["effort_score"] * 0.10 +
      row["citation_gap_score"] * 0.05
  )

  if row["indexation_status"] in ["noindex", "canonicalized_elsewhere"]:
      return 0

  return round(score)

The effort_score should be inverted. A lower-effort opportunity should score higher. Otherwise, Claude may over-prioritize complex ideas that look strategically important but are slow to ship.

def normalize_effort(raw_effort):
  # raw_effort: 1 = easy, 5 = very hard
  return {
      1: 100,
      2: 80,
      3: 60,
      4: 35,
      5: 15
  }.get(raw_effort, 50)

The output should be a ranked queue with a reason attached to each score.

topic_cluster,url,score,recommended_action,score_reason
claude-seo-strategy,/blog/ai-seo-workflows,87,refresh_existing_page,"High demand, weak AI visibility, strong business fit"
seo-workflow-automation,/blog/seo-automation,74,improve_title_meta,"High impressions, low CTR, existing page has intent match"
ai-search-reporting,,68,create_new_page,"Growing demand, no mapped URL, medium business value"

Then ask Claude to review the queue, not the raw dataset:

Review this scored opportunity queue.

For each item with score above 70, return:
- recommended_action
- why_now
- brief_type_needed
- risk_if_ignored
- data_points_supporting_priority
- human_decision_required

Do not create a content brief yet.
Flag any item where the score looks inflated by weak data.

That last instruction is important. Claude should be allowed to challenge the queue when the data is thin, duplicated, or misleading.

A good scoring loop does not remove judgment. It protects judgment from noise. It helps the team separate pages worth briefing from pages that should be monitored, consolidated, rewritten, or excluded from the indexable roadmap.

Turn the Highest-Scoring Opportunities Into Structured Briefs

Claude should only write briefs after an opportunity has passed the scoring layer. Otherwise, the workflow turns into content inflation: too many briefs, too many pages, and no clear reason why each page deserves to exist.

A strong brief is not a loose outline. It is a production contract. It should tell the writer, editor, CMS, QA layer, and internal-linking system exactly what the page must do.

For a serious Claude SEO strategy, every brief should answer five questions:

• What search demand justifies this page?
• What AI visibility gap does it help close?
• What entity, product, category, or decision must the page clarify?
• What proof is required before publishing?
• What checks must pass before the page reaches the CMS?

The output should be structured enough to move through a workflow without being rewritten by hand.

{
"brief_id": "brief_claude_seo_strategy_001",
"source_opportunity_id": "opp_8721",
"page_type": "strategic_guide",
"recommended_action": "refresh_existing_page",
"primary_keyword": "claude seo strategy",
"topic_cluster": "ai-seo-workflows",
"search_intent": "learn how to use Claude inside a controlled SEO workflow",
"ai_answer_target": "Claude is most useful for SEO strategy when it connects data, scoring, briefs, QA, and reporting into repeatable loops.",
"target_reader": ["founder", "seo_lead", "content_lead"],
"must_include_entities": [
  "Claude",
  "Google Search Console",
  "AI visibility",
  "opportunity scoring",
  "content briefs",
  "QA gates"
],
"proof_requirements": [
  "support claims about GSC metrics with documentation",
  "support claims about structured data with documentation",
  "avoid unsupported automation claims"
],
"cms_status": "brief_ready_for_review"
}

This format makes the brief auditable. If the page fails later, the team can see whether the problem came from weak demand, poor intent mapping, missing proof, bad publishing rules, or execution quality.

Claude should also separate answer-fit from article structure. The answer-fit layer is the concise explanation AI systems can extract. The article structure is the full editorial path that earns trust from a human reader.

answer_fit:
short_answer: >
  Claude supports SEO strategy best when it operates inside repeatable loops
  for data analysis, prioritization, briefing, QA, and reporting.
extraction_targets:
  - definition
  - workflow_steps
  - decision_rules
  - risks_to_avoid

article_structure:
h1: "How to Use Claude for SEO Strategy: Build a Workflow with Loops"
required_sections:
  - workflow_layer
  - data_contract
  - search_demand_loop
  - ai_visibility_loop
  - opportunity_queue
  - scoring
  - structured_brief
  - qa_gates

For pages that need structured data, the brief should define the schema requirement early. Structured data should not be added as an afterthought, especially when page type, content format, and rich-result eligibility depend on clear implementation rules.

Claude can draft the brief, but the workflow should block weak briefs before production. Use a validation step:

required_fields = [
  "source_opportunity_id",
  "page_type",
  "primary_keyword",
  "search_intent",
  "ai_answer_target",
  "must_include_entities",
  "proof_requirements",
  "qa_checks"
]

def validate_brief(brief):
  missing = [field for field in required_fields if not brief.get(field)]
  if missing:
      return {"status": "failed", "missing_fields": missing}
  return {"status": "passed", "missing_fields": []}

The best briefs are not longer. They are more operational. They reduce ambiguity before writing starts.

Claude should produce the brief, explain the strategic reason for the page, and flag missing evidence. A human should approve the page angle, claims, and publishability. That keeps the loop fast without letting the workflow generate pages just because it can.

Add QA Gates Before Anything Reaches the CMS

Claude should not send content directly into the CMS because the highest-risk SEO mistakes are usually workflow mistakes, not writing mistakes. A page can read well and still have a duplicate slug, missing canonical, wrong indexation state, weak intent match, unsupported claims, or schema that does not match the page.

The fix is a QA gate between brief approval and CMS entry. For advanced SEO systems, this gate should combine deterministic checks, Claude review, and human approval.

qa_gates:
deterministic:
  - title_present
  - h1_present
  - meta_description_present
  - canonical_valid
  - slug_unique
  - indexation_status_allowed
  - internal_links_min_3
  - schema_type_allowed
  - no_empty_required_sections
claude_review:
  - search_intent_match
  - answer_fit
  - entity_coverage
  - unsupported_claims
  - duplication_risk
  - thin_section_risk
human_approval:
  - page_priority
  - brand_claims
  - publish_decision

The deterministic layer should run first. It should block obvious failures before Claude reviews the page. Robots.txt, noindex, canonicals, schema, and sitemap inclusion should not be handled casually inside a content prompt. They need explicit rules.

A simple pre-CMS validator can look like this:

def validate_page(page):
  errors = []

  if not page.get("title"):
      errors.append("missing_title")

  if not page.get("h1"):
      errors.append("missing_h1")

  if not page.get("canonical_url"):
      errors.append("missing_canonical")

  if page.get("indexation_status") == "indexable" and page.get("robots") == "noindex":
      errors.append("indexable_page_has_noindex")

  if page.get("schema_type") not in ["Article", "BreadcrumbList", None]:
      errors.append("unsupported_schema_type")

  if len(page.get("internal_links", [])) < 3:
      errors.append("too_few_internal_links")

  return {
      "status": "failed" if errors else "passed",
      "errors": errors
  }

After the deterministic layer passes, Claude can review quality and strategy. This is where the model is useful, because not every issue is binary. Claude can check whether the page answers the approved intent, whether the introduction matches the search problem, whether the answer block is extractable, whether entities are covered naturally, and whether claims need stronger evidence.

Review this drafted page against the approved brief.

Return:
- intent_match: pass / revise / fail
- answer_fit: pass / revise / fail
- entity_coverage: pass / revise / fail
- unsupported_claims
- duplicated_angles
- thin_sections
- recommended_fixes

Do not rewrite the page.
Do not approve publication.
Only return QA findings.

That final instruction matters. Claude should not be the same layer that writes, reviews, approves, and publishes. Keep maker and verifier roles separate.

For larger page systems, the QA gate should also check whether a page deserves to enter the indexable set. Helpful, reliable content and indexation logic belong in the same workflow. A page should not become indexable just because the prose is clean.

The practical rule is simple: Claude can draft, diagnose, and recommend. Scripts can validate hard rules. Humans approve strategy, claims, and publishing. That separation keeps the workflow fast without letting bad pages move through the system just because the model produced clean prose.

Use Skills, Subagents, and Hooks to Keep the Loop Controlled

Once the SEO loop is clear, the next step is architecture. Do not put every instruction into one long prompt. Split the workflow into components that match the job: skills for repeatable procedures, subagents for heavy analysis, and hooks or scripts for hard controls.

Claude Code skills are designed for reusable workflows. A skill can live in a SKILL.md file, load when relevant, or be invoked directly by command. That makes skills a better fit for repeatable SEO procedures than pasted prompts.

Use skills for steps that should run the same way every time:

.claude/
skills/
  merge-demand-visibility/
    SKILL.md
  score-opportunities/
    SKILL.md
  create-seo-brief/
    SKILL.md
  review-page-qa/
    SKILL.md

A scoring skill, for example, should not “think creatively.” It should follow the same scoring rules, required fields, and allowed outputs every time.

---
name: score-opportunities
description: Score SEO opportunities from the approved opportunity queue.
---

Inputs required:
- opportunity_queue.csv
- scoring_weights.yaml

Rules:
- Do not create briefs.
- Do not invent missing data.
- Return only rows with score, action, reason, and human_decision_required.
- Set score to 0 if indexation_status is noindex or canonicalized_elsewhere.

Subagents are better for analysis that would pollute the main context. They can isolate context, run focused subtasks, and use specialized instructions without adding everything to the main prompt.

For SEO, that separation matters. A GSC analyst can inspect thousands of rows. An AI visibility analyst can review prompt results. A content decay analyst can compare performance periods. The main workflow only needs the findings.

.claude/
agents/
  gsc-analyst.md
  ai-visibility-analyst.md
  content-decay-analyst.md
  qa-verifier.md

The subagent output should be concise and machine-usable:

{
"agent": "gsc-analyst",
"period": "last_28_days",
"findings_file": "outputs/gsc_findings.csv",
"top_signals": [
  "striking_distance",
  "high_impression_low_ctr",
  "content_decay"
],
"ready_for_merge": true
}

Hooks and deterministic scripts are the control layer. Use them to block bad states before they create cleanup work:

{
"hooks": {
  "PreToolUse": [
    {
      "matcher": "Write|Edit",
      "hooks": [
        {
          "type": "command",
          "command": ".claude/hooks/block-unapproved-cms-write.sh"
        }
      ]
    }
  ]
}
}

The script can check whether the page has passed QA before allowing a write to the CMS export, content repo, or publishing branch.

#!/bin/bash

STATUS=$(jq -r '.tool_input.file_path' | grep -q "cms-ready" && echo "allowed" || echo "blocked")

if [ "$STATUS" = "blocked" ]; then
jq -n '{
  hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "deny",
    permissionDecisionReason: "CMS writes require approved QA status."
  }
}'
fi

The architecture should be simple:

• Skills run repeatable SEO procedures.
• Subagents analyze large or messy inputs.
• Hooks/scripts enforce rules Claude should not negotiate.
• Humans approve strategy, claims, publishing, and outreach.

This is how Claude becomes reliable in SEO systems work. Not because it gets one perfect prompt, but because every loop has defined roles, controlled inputs, blocked failure states, and clear approval points.