WordPress · AI

AI content scorer for Google E-E-A-T

Real-time E-E-A-T scoring inside the editor, so marketers get specialist SEO judgement without specialist SEO knowledge.

Industry
WordPress · AI
Engagement
Productized AI
Stack focus
WordPress + LLM
Model
DeepSeek
Editor
Froala WYSIWYG
Delivery
Distributed plugin
WordPressPHPDeepSeekFroala
Challenge

The problem we were handed.

E-E-A-T is not a checklist. Google's Helpful Content guidance describes what good writing looks like — experience, expertise, authoritativeness, trust — and then leaves the interpretation to whoever is holding the draft. A marketer writing a product page has no reliable way to tell whether their section on installation reads as first-hand experience or as competent paraphrase of someone else's. The people who can tell are SEO specialists, and specialists are not sitting inside the CMS at five on a Thursday.

The tooling that existed was keyword tooling. Density, heading counts, readability grade — mechanical signals that a genuinely good article already passes and a thin one can be made to pass. None of it addressed the thing Google actually says it cares about. The gap wasn't a shortage of rules; it was judgement, and judgement is exactly what a rules engine can't fake.

So the brief was to put that judgement where the writing happens. Not a report emailed after publishing, not a separate dashboard nobody opens — scoring that runs while the draft is being written, anchored to the section it's talking about, and phrased as an edit a marketer can make without first learning what the acronym stands for.

Constraints we designed around
Scoring fast enough to feel live while typing
Token cost bounded per document
API keys never exposed to the browser — the plugin ships to sites we don't administer
Ordinary shared WordPress hosting: no queue workers, no long-running processes
Feedback specific enough to act on, and honest about what a model can't judge
Approach

How we built it.

A WordPress plugin pairing the DeepSeek API with a Froala WYSIWYG editor — real-time scoring, per-section insights and impact-prioritized recommendations.

01

Real-time scoring

A scoring pass over the draft that returns per-section insight rather than one opaque number. The document is split on its own heading structure, and each section is judged against the E-E-A-T dimension it is actually carrying — a methodology section on demonstrated experience, an author block on authoritativeness. A composite document score is derived from the sections, not handed down to them.

  • Heading-aware chunking, so feedback lands on the passage it refers to
  • Debounced triggers — scoring follows pauses in typing, not keystrokes
  • Section hashing: unchanged sections are served from cache, never re-scored
  • Partial results stream in as sections return, instead of one long wait
02

Prompt and eval discipline

A model's opinion is only useful if it's stable. We kept a fixture set of drafts — strong, mediocre and deliberately thin — and re-scored all of them on every prompt change, checking that the relative ranking held and that the same draft scored the same twice. Prompts are versioned with the plugin, so a change to scoring behavior ships as a release rather than as a surprise.

  • Golden-set drafts with an expected ranking, run before any prompt change
  • Structured JSON output, schema-validated, with a bounded retry on malformed responses
  • Low temperature and pinned prompt versions for repeatable scores
  • Reviewer disagreements logged and fed back into the next prompt revision
03

Impact-prioritized recommendations

The first version surfaced everything the model noticed, which is functionally the same as surfacing nothing. Recommendations are now ordered by likely effect on the page rather than by the order the checks happened to run — a missing author credential outranks a long sentence. Each one names the section, what's weak in it, and the edit that would fix it.

  • Every recommendation scoped to a section and an E-E-A-T dimension
  • Ranked by estimated impact and capped, so the list stays readable
  • Written as an edit to make, not a rule that was broken
04

Keys behind a proxy

The plugin runs on sites we don't administer, so the model credential never reaches the browser and never sits in plugin options where an editor-role user could read it. Requests go from PHP to a server-side proxy that holds the key, validates origin and rate-limits per site. Changing the model is a change in that layer — the plugin doesn't know or care which model answered.

  • Proxy holds the credential; the editor only ever talks to its own WordPress
  • Per-site rate limits and usage telemetry, so spend is visible before it's a bill
  • Nonce and capability checks on every scoring route
05

Froala, doing the editor work

Froala is the editing surface, and the scoring UI lives inside it rather than beside it. Section scores render in the gutter next to their headings, and selecting a recommendation scrolls to the passage it belongs to and highlights it. Setup is an install and a key — no build step, no theme edits, no shortcode surgery.

  • Insight panel and gutter markers built as Froala plugins, not bolted-on DOM
  • Falls back to a manual score action when the API is unreachable, rather than blocking the editor
  • No-code activation: install, authenticate, start writing
Under the hood

Architecture & integrations.

DeepSeek API behind a server-side proxy
Froala WYSIWYG as the editing surface
Scoring service in PHP, exposed through registered WordPress REST routes
Section splitting and hashing done in PHP; only changed sections leave the site
Model responses schema-validated before anything reaches the UI
Scores and recommendations cached against the post revision, so reopening a draft costs nothing
Results

What it delivered.

Outcomes
E-E-A-T
aligned scoring
Live
recommendations
No-code
plugin setup
What changed
Recommendations ordered by likely impact, not by rule order
Marketers act on E-E-A-T without knowing the acronym — feedback names the edit, not the guideline
Review closes inside the editor: scoring reads as part of writing rather than a step after it
Token spend tracks editing activity, not traffic, because unchanged sections cost nothing to re-score
The model is a swappable dependency — the proxy decides who answers, not the plugin

The interesting part was never the API call. It was deciding what a score is allowed to claim, and then building the fixtures that keep it honest release after release. That's the line between a production AI feature and a thin wrapper — and it's the same discipline we bring to any system we run: measure the thing, then keep measuring it.

Frequently asked

Questions this project raises.

Whichever fits the job and the budget — this build used DeepSeek, and we work across Claude, OpenAI and Gemini too. The model sits behind a proxy layer, so switching it is a config change.

Token cost is bounded by design. Documents are scored section by section, unchanged sections come from cache, and per-site rate limits cap the worst case. Usage telemetry shows spend before it becomes a bill. Cost tracks editing activity, not page views.

Trust it as a strong second reader, not an oracle. Feedback is scoped to a section and phrased as an edit to make rather than a rule that was broken, and where the model can't judge something it says so instead of guessing.

Prompts are versioned with the plugin, and a fixture set of strong, mediocre and deliberately thin drafts is re-scored on every change to check the ranking still holds. If a change makes the fixtures worse it doesn't ship — scoring changes arrive as releases.

You do, along with the code and proxy config — clean, documented, no lock-in. Prompts and golden-set fixtures are the part most vendors keep back; they're the only thing that makes a score reproducible, so they ship with everything else.

Have a problem shaped like this one?

Tell us what's in the way. You'll hear back from a senior engineer within one business day.