SEO Operating System

How It Works

System View

The dashboard is a layer on top of several separate pipelines

What you are seeing is not one single process. It is the combined output of discovery, monitoring, content generation, quality checks, review queue building, workflow decisions, Git sync, and Cloudflare deployment.

Discovery and monitoring Opportunities and action queues Content and review queues Workflow feedback layer

Step 1

Discovery and monitoring run first

Scripts like skills/seo-agent/scripts/seo-discover.sh and the monitoring jobs pull rankings, strike-zone keywords, and client performance data.

Output: workspace/<client>/seo/opportunities/discovery-*.json

Step 2

Opportunity files get normalized

bin/build-opportunities.py turns raw discovery, monitoring, and gap data into one canonical opportunity list per client.

Output: workspace/<client>/seo/opportunities/opportunities.json

Step 3

Action queues are ranked

bin/build-action-queue.py picks the next best tasks from those opportunities so the team is not just looking at raw SEO data.

Output: workspace/<client>/seo/opportunities/action-queue.json

Step 4

Content and service-page jobs create drafts

The content pipeline and service-page pipeline generate or refresh drafts, then normalize them into usable article files.

Output: workspace/<client>/content/articles/*.md

Step 5

Quality checks assign review status

bin/check-content-quality.py gives each draft a review state like editor review, strategist review, or ready to publish.

Output: frontmatter on each article plus review-queue.json

Step 6

The dashboard aggregates those files

The cross-client dashboards are built from per-client queue files. The UI does not invent the data; it reads from those generated artifacts.

Output: workspace/content-review-dashboard.json and workspace/action-dashboard.json

Dashboard Mapping

What each part of the dashboard is actually showing

Team Workflow

A merged operating layer. It combines review queue items and action queue items, then overlays human decisions like owner, status, and irrelevant.

Cross-Client Queue Board

Only review queue items. This is content status across all clients, grouped by publish stage.

Client Drilldown

The selected client’s review queue plus their ranked action queue. This is the best place to understand one account in isolation.

Cross-Client Next Best Actions

The SEO opportunity backlog across the portfolio. This is driven by action-queue data, not by article review status.

Feedback Loop

What your team changes when they use the workflow board

Owner

Assigns the work to Pamela, Ravel, Shastine, or JM so the board becomes role-based instead of just status-based.

Status

Changes whether the task is in triage, SEO review, in progress, blocked, or ready to publish.

Irrelevant

Hides weak tasks from the active board so the system stops resurfacing items you already know are bad fits.

Notes

Stores the human reason behind a decision so later you can see why something was approved, blocked, or rejected.

These workflow decisions are stored separately from the static queue files. That means the dashboard shows machine outputs first, then overlays human decisions on top.

Common Issue

Why the system can feel disconnected

Multiple layers

SEO opportunities, content review states, and workflow decisions are different layers. If the dashboard does not explain that, it feels like mixed signals.

Stale upstream files

If discovery, action queues, or review queues have not been rebuilt recently, the dashboard may be accurately showing outdated pipeline output.

Missing feedback binding

If the workflow database is not configured, the board can display tasks but cannot persist decisions, which makes it feel fake.

No explicit narrative

Before this page existed, the UI mostly showed status snapshots. That made it harder to understand the actual sequence of work underneath.