The content-role playbook for AI on WordPress sites in 2026 is the one with the most polarized takes online. The honest middle position: AI is excellent at the structural work around content (outlines, briefs, titles, refreshes, format conversion, fact-check audits) and bad at being the voice of a publication. Use it for the scaffolding; do not let it write the prose your readers (and search engines) will see. The line is sharper than it was a year ago because both readers and AI-detection signals have gotten better.
Jump to:
- The rule that defines this playbook
- Workflow 1: outlines and briefs
- Workflow 2: article refreshes
- Workflow 3: title and meta generation
- Workflow 4: format conversion
- Workflow 5: fact-check passes
- Workflow 6: content QA at scale
- What stays human-written end to end
The rule that defines this playbook
The single rule: the published prose your readers see should be written by a human. The AI participates in every other step. Outlines, briefs, structural suggestions, format conversion, fact-checking, headline generation, meta description, internal-link suggestions, all fair game. The body text itself, written by a human in a real voice.
Why: Google's helpful content guidelines (merged into the core ranking algorithm in 2024) and AI search engines both increasingly detect and demote pure-AI content. The agencies and publications still ranking well are the ones whose human voice is real. The ones disappearing from rankings since 2024 are the ones that published AI prose unchanged.
This is not a moral position; it is an economic one. AI-written content has negative ROI in 2026.
Workflow 1: outlines and briefs
The highest-value workflow. Hand the AI the topic and the target audience; get back a structured brief.
I am writing an article on [topic] for the [TechEarl] audience
(WordPress developers, agency operators, mid-to-senior level).
Generate a brief that includes:
- Primary search intent (informational / comparison / transactional).
- Suggested H1.
- 5-8 H2s with one-sentence summaries of what each section should cover.
- 3-5 key facts/statistics the article should include (with citation
suggestions if you know them).
- 2-3 opening hooks the writer could choose between.
- 5-8 internal links that would fit (from URLs I will provide separately).
- Suggested word count.
Output as a structured brief I can hand to the writer.The writer takes the brief, ignores the parts that do not fit, writes the article in their voice. The brief saves 60-90 minutes per article of "what should this article cover, in what order?" thinking.
Workflow 2: article refreshes
The "this article was published two years ago and needs an update" workflow. AI is excellent at flagging what changed.
Read the article at [URL] (or paste). It was published [date].
Identify everything in the article that may have changed since [date]:
- Tool versions mentioned (current vs published).
- Pricing mentioned (verify current pricing if you can).
- API behavior (any deprecations or changes since the original publish?).
- Best practices that may have evolved.
- Statistics or dates that are now stale.
- Links that may have broken.
For each, propose what the update should be. Do not rewrite the
article; just identify the changes.
Output a structured update plan.The writer applies the changes. The article gets bumped to a new modified_date (and the cover cache is busted per the image conventions). The refresh discipline is what keeps a content backlog from rotting.
Workflow 3: title and meta generation
The mechanical part of every article publish.
Here is the article body (attached). Generate:
- 5 H1 title variants, each under 60 characters, with the primary
keyword near the start.
- 3 meta description variants, each under 155 characters, with a
clear value proposition.
- 5 social-share title variants (slightly different framing for
Twitter/LinkedIn vs SERP).
- 1 suggested URL slug, kebab-case.
The article voice is first-person, practitioner-focused, no fluff.
Match that register in the titles.The editor picks one, possibly tweaks it, ships. The cost is 2 minutes; the alternative (the editor staring at the article trying to come up with a title) used to take 15-20.
Workflow 4: format conversion
Turn one form of content into another. Meeting transcript into article. Article into newsletter. Article into LinkedIn post. Internal memo into blog post.
Here is a meeting transcript (attached). The participants are talking
about [topic].
Extract the key points and structure them as a draft technical
article in the TechEarl voice (first-person, practical, no fluff).
Use the topic order from the transcript; do not invent points that
were not discussed.
Output a draft article body.The writer takes the draft, rewrites it in actual voice, ships. The format-conversion AI is doing the boring extraction work; the writer is doing the voice work.
Workflow 5: fact-check passes
The single highest-value editorial workflow for any non-trivial article.
Read this article (attached or via URL). Identify every concrete,
checkable claim:
- Version numbers (e.g., "WordPress 6.6 introduced X").
- Pricing (e.g., "Kinsta starts at $35/mo").
- Dates (e.g., "ACF was released in 2011").
- API behavior (e.g., "wp_remote_get returns WP_Error on failure").
- Statistics (e.g., "30% of WordPress sites use ACF").
For each, classify:
- VERIFIED-CORRECT (you are confident it is accurate).
- LIKELY-CORRECT (probably right but worth confirming).
- NEEDS-MANUAL-CHECK (cannot verify from your knowledge alone).
- LIKELY-WRONG (suspicious based on your knowledge).
- DEFINITELY-WRONG (you know this is incorrect).
For LIKELY-WRONG and DEFINITELY-WRONG, propose what the correct
value should be.
Output as a structured fact-check report.This is the workflow that catches the "we wrote 'PHP 8.2' but the example actually requires 8.3" bug before it ships. Used to be a 60-minute manual chore; now runs in 5.
Workflow 6: content QA at scale
For sites publishing weekly or daily, an end-to-end content QA pass:
Read the article at [URL]. Audit against our content standards:
1. First-person voice consistent throughout (no slip into "we").
2. No em-dashes (project convention).
3. No fluff opening ("In today's fast-paced...").
4. Specific examples, not generic platitudes.
5. At least one comparison table OR numbered list OR specific data point.
6. 3+ internal links to related articles.
7. Sources frontmatter populated with verified external links.
8. Title under 60 chars, meta under 155.
9. Image alt text describes the article topic (SEO field), not the
picture content.
10. Date plausibility: any tech mentioned that did not exist when
the article claims to have been published?
Output a checklist with pass/fail per item.The "date plausibility" check is especially useful for sites with staggered publish dates (like the techearl WordPress cluster). Backdated articles must not reference post-dated tech.
What stays human-written end to end
- Body prose of any published article. Always.
- Opinion pieces. The opinion has to be the author's.
- Personal anecdotes. Self-evidently.
- Case studies and client stories. Specifics matter; AI generalities ruin them.
- Newsletters (the prose itself). The voice is the newsletter.
- Anything where the editorial position contradicts the AI's default training. The AI defaults to anodyne; your publication's position may be more pointed.
For the broader role map of AI in agency operations, see How Small WordPress Agencies Can Use AI in 2026, by Role. For the SEO-side patterns that compose with this content workflow, see AI for WordPress SEO. For agency operations, see AI for WordPress Agency Operations.
The discipline that makes this work: AI in every step that is structural, human in every step that is voiced. That line is the difference between content that compounds value over years and content that stops getting indexed within months.
Sources
Authoritative references this article was fact-checked against.
- Claude Code overview (Anthropic documentation)code.claude.com
- Creating helpful, reliable, people-first content (Google Search Central)developers.google.com





