Kenmark T. / field log
/ case 03 · SEO operations

Building an SEO engine that refuses to take credit for its own fixes.

The problem was not fixing SEO issues. It was building a system that proves each fix is reversible, asks a human before writing, and confirms the public result independently.

Role

Systems design, build & operation

Domain

SEO health monitoring / WordPress

Status

Core engine proven · supervised pilot

Operating principle
Observe → propose → approve → write → verify.

V1 writes deterministic values. AI-generated SEO copy is a later recommendation layer, not a direct write authority.

01 / the problem

SEO tools that fix things but can't prove they're fixed.

A business with a WordPress site needed ongoing SEO health monitoring. Missing meta descriptions, absent Open Graph tags, missing structured data—the fixes are straightforward. The real question was whether a fix actually took effect on the public page.

Most tools tell you what is wrong; some fix it. Very few prove the fix took effect, let you undo it cleanly, and keep reporting when the site is healthy. Silence is the wrong signal for a monitoring product.

I wanted a managed SEO service that behaves like a trustworthy mechanic: explain the issue, wait for approval, use a narrow and reversible path, check the public result, and report even when everything is fine.

02 / what I built

Six workflows that audit, propose, fix, verify, and report.

The system is a chain of six specialized workflows coordinated by one orchestrator. The orchestrator owns the schedule; the workers are reusable and independently testable.

01AuditFetch public HTML and run 15 deterministic checks.
02GovernReconcile findings, request approval, and capture state.
03VerifyRe-fetch the public page and confirm the visible result.

The audit separates “audit failed” from “zero findings,” so a healthy site remains a valid product state. Every supported write captures a before-value and generates an undo token. The final worker sends reports on every run, including clean ones.

03 / what was difficult

The design decisions that mattered more than the code.

The interesting challenges were decisions about what the system should and should not be allowed to trust.

Verification design · trust nothing

A fix that WordPress confirmed but the public page denied.

An Open Graph fix was approved and written successfully. WordPress returned success. The public page still showed the tags missing, so verification marked the fix regressed rather than verified. A CMS confirmation is not proof; the visitor-facing HTML is.

Architecture decision · when to stop

A healthy site that made the engine go silent.

The first orchestrator stopped after an audit with zero issues, sending no report. I changed it so clean runs report “zero issues found” and show the current health state.

Reversibility · controlled writes

Every fix ships with its own undo button.

Every WordPress write captures the before-value and creates an undo token before the change is applied. The worst case for a fix is “put it back how it was.”

End-to-end proof · governed chain

The full approval path, proven on a real site.

The engine detected missing structured data, emailed a proposal, received approval, wrote through the narrow bridge, waited for cache clearance, and independently verified the public page. The ledger records each state and timestamp.

04 / the result · stated honestly

A proven engine, in supervised pilot.

What is true today

  • Core engine proven end-to-end on a live WordPress site: audit, proposal, approval, governed write, independent verification, and health reporting.
  • Verification catches real discrepancies when the public page disagrees with a successful CMS response.
  • Every write is reversible by default, with before-values and undo tokens captured first.
  • Healthy sites get reports too, so monitoring does not go silent.

The engine is currently in supervised pilot with manual trigger runs. Production scheduling, additional sites, and broader check coverage are the next layer—not the current claim.

05 / what it demonstrates

Not fixing SEO issues. Building a system you can trust.

  1. Designing verification that trusts the public result, not its own writes.
  2. Making every production write reversible by default.
  3. Keeping a human in the approval loop for live-site changes.
  4. Continuing to report when the site is healthy, because silence is the wrong signal.
  5. Deferring AI-generated content until the governed path is proven.
/ back to the index

See all three systems and the failures behind them.

Open all work