AI can draft your SEO titles, meta descriptions, and FAQs faster than any human, and it will occasionally do so confidently wrong, in the wrong language, with your brand name where it shouldn’t be. Project Spark’s answer is a fire-and-confirm workflow: the AI proposes every field at once, and a human approves each one individually before anything is saved.
This post documents that workflow end to end, how content reaches the model, how proposals reach the editor, and the seven guardrails that turned a demonstration into a production system a Hebrew-first business trusts daily. None of the guardrails is exotic. All of them exist because something went wrong without them.
Key takeaway: The safe unit of AI automation in SEO is the suggestion, not the save. Let AI generate everything in one pass; let a human own the write button.
Why “human in the loop” is a design problem, not a slogan
Every vendor now claims human oversight. The difference between the claim and the reality is where the loop sits. If AI writes to the database and a human can review afterwards, the human is not in the loop, they are in the audit trail. If a human must click “generate” but the output saves automatically, the loop contains a trigger, not a judgement.
Project Spark places the loop at the only point that matters: between generation and persistence. The AI can propose anything; it can persist nothing. That single placement decision eliminates the entire category of incidents people fear from AI content tools, wrong-language metadata shipped site-wide, hallucinated claims published unread, an editor’s careful phrasing silently overwritten. Not because the model is reliable, but because the architecture never asks it to be.
The fire-and-confirm workflow
For any post, one click sends the content, resolved through an 8-layer extractor that handles page builders, custom fields, and shortcodes, to Google Gemini, which returns a complete metadata set: SEO title, meta description, social titles and descriptions, FAQ pairs, and topic tags.
The extractor deserves a sentence of its own, because AI output quality is mostly input quality. Real WordPress content rarely lives in the plain content field: it hides in page-builder layouts, custom-field structures, and shortcode expansions. The extraction layer resolves all of these, with caching in front, so repeated analyses cost nothing, before the model ever sees the page. Sending a page builder’s raw markup to a language model produces summaries of markup; sending clean resolved text produces summaries of the business.
Nothing is saved when the response arrives. Instead, a review panel shows each proposed field next to the current value, with a checkbox per field. The editor selects what they accept, edits inline what’s almost right, and discards the rest. Only checked fields are written. Per-field approval, rather than one accept-all button, is deliberate: coarse approval teaches people to stop reading, and an unread approval is no approval at all. The diff-style layout is what makes per-field review fast enough that a busy team genuinely performs it.
The same pattern repeats everywhere AI appears in the plugin: AI-generated featured images are previewed with editable alt text before locking; the AI-assisted setup wizard shows its proposed configuration for review before applying anything; bulk optimization runs post-by-post with a visible diff each time.
Guardrails that made AI production-safe
- Language guardrail. Every prompt carries an output-language directive resolved from the site’s actual language (multilingual plugin settings first, then WordPress locale). On a Hebrew site, answers come back in Hebrew, without the editor thinking about it. This exists because early output arrived in English whenever context leaked from an English-profile administrator’s session; the resolution order was tuned through real bug reports (Part 2).
- Brand-name exclusion. Prompts forbid the brand in generated titles and descriptions, because WordPress appends the site name at render time. AI + template both adding the brand was an early duplicate-suffix source, the same bug family as Part 7, arriving through a second door.
- Banned-words list. Site owners maintain exclusion terms (regulatory, brand-voice) enforced in the prompt with hard framing. For businesses in regulated sectors, this is not a stylistic preference; it is compliance.
- Character budgets. Titles cap near 60 characters and descriptions near 160, enforced with multibyte-safe truncation so Hebrew characters are never split mid-codepoint. Byte-based truncation on multibyte text produces invalid fragments; the safe variant costs one function choice.
- Error classification and short-circuits. API failures map to stable categories (auth, quota, server). Bulk runs stop immediately on account-level errors instead of failing identically on 200 posts. Quota errors trigger a client-side cooldown so repeated impatient clicking can’t extend the lockout.
- Pre-flight checks. Every AI surface verifies a key is configured before showing buttons, no dead UI promising features that instantly fail.
- Temperature and audience control. Site owners tune output creativity within a bounded range and maintain a persona description of their audience that travels with every request, so the model writes for the actual readership rather than a generic one.
The economics: why error handling is a feature
One guardrail deserves expansion because it is invisible in demonstrations and decisive in production: what happens when the AI provider says no.
Bulk operations are where AI tooling meets reality. A 200-post optimization run makes 200 API calls; if the account’s key is invalid or its quota exhausted, a naive implementation fails 200 times, identically, slowly, burning time and, on metered plans, money. Project Spark classifies every provider error on arrival. Account-level failures (authentication, quota, permissions) stop the run at the first post with a clear message; transient failures retry with backoff; a quota rejection starts a local cooldown that blocks new requests until the window passes, protecting the account from the click-storm of an impatient user.
None of this improves any individual AI output. All of it determines whether a business can afford to keep the feature enabled. Treating provider economics as a first-class design input is the least discussed and most practical part of building on language models.
Why Gemini at runtime, and where Claude and GPT fit
“Which model?” deserved the same rigor as any other engineering decision, and the answer in this project is deliberately hybrid: three model families, three different jobs.
Gemini runs production. The runtime features, metadata drafting, FAQ generation, image analysis, featured-image creation, sit on Gemini’s fast tier, chosen on four measured grounds: latency an editor can wait through, per-call economics that survive a 200-post bulk run, genuinely fluent Hebrew under the language directive, and multimodality that keeps text and image work on one integration surface with one encrypted key, one error classifier, and one quota model. Every additional runtime provider would double that security and reliability surface, so production stays on exactly one, on purpose.
Claude carried the engineering. Building and maintaining a codebase of roughly 41,000 lines with more than 4,700 automated checks leaned on Claude’s long-context reasoning, reviewing whole subsystems at once, generating regression tests, hunting sister-bugs across dozens of files. An engineering assistant is judged on defects prevented, not price per call, which is a different economic question with a different best answer.
GPT plays the adversary. Prompt designs and generated copy were cross-checked by asking a second, unrelated family to attack them, find factual drift, flag unnatural Hebrew, argue against the draft. Models from different lineages fail differently, so agreement across families is a stronger signal than any single model’s confidence, and disagreement reliably points a human at the interesting problem.
Critically, no feature in the plugin talks to any vendor directly: everything routes through a provider-agnostic layer that attaches the guardrails and dispatches to the configured provider. The project has already swapped a provider out once through that seam, cheaply. The principle that summarizes the whole arrangement, be hybrid in strategy, deliberate in runtime, gets its own deep dive: Hybrid AI Optimization: Claude, GPT and Gemini in One Strategy.
Bulk optimization without bulk risk
The workflow scales beyond one post at a time, and the scaling design is where human-in-the-loop principles usually die. Most tools offer a bulk mode that trades review for throughput: select 200 posts, click once, accept whatever happens. Project Spark’s bulk optimization refuses that trade. It processes posts sequentially, and for each one presents the same per-field diff panel as the single-post flow, proposed values beside current values, checkboxes per field, skip and stop always available. The human stays in the loop for every post; the AI merely removes the drafting time between posts.
This sounds slower than fire-and-forget, and per post it is. Across the project it was faster, for a reason that only shows up in practice: unreviewed bulk output generates rework. Every wrong-language field, every clumsy phrasing, every overwritten editorial choice that a review would have caught in two seconds instead surfaces weeks later as a correction task, with the added cost of finding it first. Reviewed throughput is honest throughput. The featured-image generator follows the same shape: images are produced with editable metadata (alternative text, title, caption) shown for adjustment before anything locks, because an image with wrong alternative text is an accessibility defect and an SEO defect at once.
What AI is not allowed to do
No auto-publish. No writes to Google Business Profile (Part 10). No slug rewriting. No silent overwrites of human-entered values. The plugin’s job is to make the human reviewer fast, not absent.
Write your own version of this list before building any AI feature. The forbidden list is a specification, and it belongs in tests: several of these prohibitions are enforced by automated checks that fail the build if a future change introduces an unattended write path. A rule that exists only in documentation erodes; a rule that fails CI survives (Part 14).
Questions to ask any AI-SEO vendor
The workflow above doubles as an evaluation rubric. Whether you build or buy, these five questions separate production-grade AI integration from a demonstration with a subscription price:
- Where exactly does human approval sit, before or after the write? “You can review afterwards” means the AI writes first. That is a different product.
- Is approval per field or all-or-nothing? Coarse approval decays into no approval.
- How is the output language guaranteed? Ask what happens when an English-profile administrator optimizes a Hebrew page. Blank looks are diagnostic.
- What happens on the 200-post run when the API key expires at post 3? The answer reveals whether anyone has operated the tool at scale.
- What is the tool contractually unable to do? A vendor without a forbidden list has not thought about failure.
Results in practice
What did the client actually get? A workflow where an editor opens a post, clicks once, and thirty seconds later reviews a complete, Hebrew-language, correctly-sized metadata set, accepting most fields, adjusting a few, rejecting the occasional miss. The AI does the ninety percent that is drafting; the human does the ten percent that is judgement. Metadata coverage across the site went from a perpetual backlog to a routine editorial task, with zero AI-caused incidents in production, an outcome that owes everything to the guardrails and nothing to model perfection.
Next: Part 6, Migrating From Yoast Without Corrupting a Single Byte
FAQ
Can AI write my meta descriptions?
Yes, and it’s good at it, provided a human reviews before saving. Enforce character limits, language directives, and brand-name exclusions in the prompt, and keep the final write behind human approval.
Is AI-generated SEO content safe for my site?
It’s safe when scoped: AI drafting with human approval, error handling that stops bulk runs on account-level failures, and no auto-publishing. Unattended AI writes are where sites get hurt.
What is a human-in-the-loop AI workflow?
A design where AI generates proposals and a human explicitly approves each change before it takes effect, in our case, per-field checkboxes on every AI suggestion.
Which AI model powers the plugin?
Google Gemini at runtime, a fast text model for analysis and an image model for featured images, behind a provider-agnostic layer. Claude assisted the engineering; GPT served as a cross-model verifier. See the hybrid AI deep dive.
Can AI write SEO content in Hebrew?
Yes. With an explicit output-language directive resolved from the site’s language settings, modern models produce fluent Hebrew titles, descriptions, and FAQ pairs, reviewed by a human before saving.
What happens when the AI service quota runs out?
A well-built integration classifies the error, stops bulk operations immediately, and enforces a local cooldown before new requests, so one exhausted quota never becomes hundreds of failed calls.
