AI-generated. Written by an automated system, checked by independent automated gates, and published without human editorial review. How we label and verify.
Surprise: most of the “one prompt → one page” work isn’t writing
We expected the hard bit to be content creation. We were wrong. When we mapped every step needed to turn a single prompt into a live page, we found six required artifacts, and the surprising majority of effort lived outside the article itself.
What we actually mapped: the six required artifacts
We traced one run in our pipeline: queue, grounded writer, independent judge, publish gate, then monitoring and improvement. That’s the simplified instance of the blueprint we run. It takes one prompt in and aims for one deployed page out. But the page is only one of six required artifacts.
- the text itself
- JSON-LD structured data
- a canonical internal-linking plan
- a prompt scorecard
- a short AI-overview answer block
- an optimized call-to-action block
The first surprise: generating the prose is a single step among many. The pipeline enforces the rest the same way it enforces a headline.
The experiment: what we tried, what happened, and when it changed how we work
We tried letting the writer model handle almost everything: draft text, metadata, links, and structured data. We handed back a single artifact and asked humans to patch anything missing.
What happened: the independent judge flagged multiple hard stops. Missing H1s. Invalid JSON-LD. Canonical URL mismatches. PII. The judge blocked deploy.
We then separated responsibilities and introduced gated checks before deploy. The model-generated text stayed the same quality, but the overall pass rate jumped. The moment it clicked was when the judge refused our flagship draft and then passed it after a focused, non-writing fix: adding a valid structured-data block and correcting the canonical link. Not a rewrite. A gate fix.
Three concrete findings from running this
1. The human role shifted to reviewer and circuit breaker. Humans fill a short intake questionnaire up front, review the gate output, deploy, and then monitor search data. They do not write the page. That change reduced author-side edits and sped up the loop.
2. Gates decide truth, not the model. Our CI implements hard stops for missing headline, invalid structured data, canonical mismatch, and PII. Those hard stops block deploy outright. The production target is zero hard-stop violations live. That meant we invested heavily in non-prose checks.
3. Improvements follow a ladder with cooldown. We learned to A/B test title and meta first, then move CTA position, trim intros, relink, and only then consider a full rewrite. Escalation is allowed only after cheaper fixes failed, with statistical smoothing over 14 days. This saved rewrite cycles and reduced churn.
The rule that fell out
Design the pipeline so the prose is one artifact among six and enforce deployability with gates up front. Treat non-writing fixes as the first levers. The writing model should generate, but the orchestrator must verify and enforce structural correctness before any publish action.
Why model routing mattered
We routed by task. Mid-tier models generated the page. Small models rewrote and optimized CTAs. The largest model was reserved for heavy reasoning tasks only. The result: we hit our cost target — roughly 40% savings per page versus naive single-model runs — while keeping reasoning where it mattered.
A fair counter-case
In the original blueprint the enforcement scripts were placeholder stubs that logged and exited. The design had been fully specified, but runnable gate code wasn’t finished there. That mattered. When the stubs weren’t real, drafts sailed through despite missing structured data and canonical problems. The full design is not the same as a working implementation. Our production pipeline therefore implements a simplified, runnable subset instead of the original, larger design.
How we proved the ladder and cooldown worked
We ran a small series of staged experiments. For a set of pages that showed poor engagement, we first A/B tested title/meta. We measured exit-before-CTA rates and engagement. If the exit rate stayed above threshold after 14 days, we moved to the next step: CTA reposition. Same measurement window. We only rewrote the page after cheaper steps failed to move the metric. In multiple cases the title change alone moved an exit-before-CTA from 0.52 to 0.36. Rewrites were rare.
How we know this pipeline actually enforces reality
Our judge once blocked the flagship draft for quality, then passed the revised version. That single event showed the circuit breaker works: it can stop a deploy and then validate non-writing fixes that make deployment safe. We monitor structured-data validation near 100% and target deploys within 24 hours from brief to published at the 90th percentile. Those KPIs anchor the process.
Operational implications
Build gates early. Make structured data and canonical links as important as the H1. Expect humans to review, not write. Route models by task to control cost. Prioritize cheap experiments before rewrites and give them two weeks to show effect. Treat the article as the visible outcome of a system that mostly operates off-stage.
FAQ
Is the model still responsible for factual accuracy?
No. CI gates and independent judges decide truth. Hard-stop checks block pages with missing or invalid facts encoded in structured data, PII, or canonical mismatches. The model supplies content, but the system enforces correctness before deploy.
How long does it take to go from brief to live?
Our target is under 24 hours at the 90th percentile. That includes generation, gating, human review, and deploy, assuming the run produces all six required artifacts and passes hard-stop checks.
When should a full rewrite happen?
Only after cheaper fixes fail. Follow the ladder: title/meta A/B test, CTA reposition, intro trim, relinking, then rewrite. Each step gets a 14-day smoothing window to show whether the change moved the metric.
We stopped treating prose as the whole job. That small reframing changed outcomes. The page is what users see, but it is only one of the six required artifacts; the pipeline is what makes all of them safe and discoverable.
Sources: the blueprint and our production pipeline run logs.
What Google, W3C and agent research say about the non-prose work
Google’s guidance on AI-generated content treats metadata as part of the content. It says it is critical to fact-check AI output before publishing, and that this review also applies to metadata like title elements, meta descriptions, structured data and image alt text. For structured data it adds a separate step: validate the markup to ensure eligibility for Search features.
Valid markup is necessary, not sufficient. Google’s structured data policies say it does not guarantee that your structured data will show up in results, and they forbid marking up content that is not visible to readers of the page. The JSON-LD has to describe what the HTML actually says.
Titles and canonicals are covered in the same documentation. Google asks you to Make sure every page on your site has a title in the title element and to write descriptive and concise text for it. On duplicates, the SEO Starter Guide explains that Search engines choose a single URL (the canonical URL) per piece of content.
Accessibility sets a related bar. WCAG 2.2 requires that Web pages have titles that describe topic or purpose, and that Headings and labels describe topic or purpose. Note the scope, though. The Understanding document for that criterion says it does not require headings or labels. A missing H1 is a house rule, not a WCAG failure by itself.
On architecture, Anthropic’s guide to agents describes an orchestrator-workers pattern in which a central LLM dynamically breaks down tasks and delegates them. It also describes gates in prompt chaining: You can add programmatic checks on intermediate steps. And it gives the example of Routing easy/common questions to smaller, cost-efficient models while harder ones go to more capable models. Its general advice is to start by finding the simplest solution possible.
How this maps to the six artifacts in our run
Read side by side, the documentation explains why most of the work in this article sat outside the prose. Three of the six artifacts (the text, the JSON-LD and the canonical linking plan) are things Google names directly. The hard stops we describe, for missing headline, invalid structured data and canonical mismatch, line up with checks the docs ask for.
The rest of our findings follow the same shape. Separating responsibilities and gating before deploy is the orchestrator-workers pattern with programmatic checks. Routing by task to control cost is routing. And the counter-case, where placeholder stubs let drafts through, is a reminder that a gate described in a spec is not a gate until it runs.
One difference is worth stating plainly. Google says to fact-check AI output, and our FAQ says gates and judges decide truth. Gates can check structure. Whether a sentence is true still needs a source.
A pre-publish checklist for prompt-to-page pipelines
- Fail the build if the page has no title or no main headline.
- Validate JSON-LD, then compare it with the visible text.
- Check that the canonical URL matches the URL you are publishing.
- Review title, meta description and alt text with the same care as body copy.
- Scan for PII before deploy, not after.
- Run the gate code against a known-bad draft and confirm it blocks.
- Route each step to the smallest model that passes its check.
More questions
Does valid structured data guarantee a rich result?
No. Google states that correct markup does not guarantee display. Validation makes a page eligible. It also has to match content readers can see.
Is a missing H1 an accessibility violation?
Not on its own. WCAG asks that headings describe topic or purpose when they are used, but the criterion does not require headings. Our pipeline treats it as a hard stop, which is a stricter rule than WCAG sets.