AI integration for WordPress

What AI integration actually means for a WordPress site

AI integration is not a plugin you activate. It is a set of decisions about where a language model touches your content, who reviews its output, whose API key pays for the tokens, and where the data travels. Done well, it removes the mechanical parts of editorial and support work while leaving humans in charge of every published word. Done badly, it hides costs, leaks customer data into a training set, and quietly lets a model publish things nobody checked.

On a WordPress estate the integration surface is concrete. A model can read the post archive, draft against a brief inside the block editor, classify incoming content, answer support questions from your own documentation, or generate WooCommerce copy from real product attributes. Each of those is a separate feature with its own data flow, its own review step, and its own budget. I treat them that way rather than shipping one opaque "AI assistant" that does a bit of everything and can be audited for none of it.

The technical shape is usually simple: the WordPress REST API on one side, a hosted model (Claude or OpenAI) behind a thin gateway on the other, and, where the answer must come from your own material, a retrieval layer in between. The value is not in the novelty of the model. It is in the discipline around it: provenance metadata on every artefact, hard cost caps, opt-in review, and a clear line between what the AI drafts and what a person decides.

What I ship

AI features wired into existing WordPress workflows. Editorial assistance, support fan-out, semantic search over the post archive, translation review, content classification. Every artefact carries provenance metadata (model, prompt version, retrieval source, editor reviewer). Token usage feeds observability with hard monthly caps per integration.

Use cases that pay back

I start from the cases where AI removes real toil and the review cost stays low. These are the ones that reliably earn their token spend on a WordPress or WooCommerce site.

• Editorial content assist. Draft-against-brief inside the block editor: outlines, first drafts, headline variants, meta descriptions, internal-link suggestions grounded in your own archive. The editor stays the author of record; the model removes the blank page, not the judgement.
• WooCommerce product-description generation. Batch generation over the catalogue from real attributes and specifications, run with WP-CLI, landing as drafts for a merchandiser to approve. Accurate copy from your data, not invented marketing lines.
• Semantic search over the archive. Embeddings turn a keyword box into a meaning-aware search. Readers find the right post even when their words do not match your headings, which lifts internal engagement and reduces support tickets that are really navigation failures.
• Support and pre-sales assistance. A retrieval-grounded assistant that answers from your documentation and knowledge base, drafts replies for an agent to send, and never fabricates policy. Draft-only by default; a human sends the message.
• Internal operations automation. Tagging and categorising incoming content, routing form submissions, summarising long comment threads, flagging posts that need a freshness pass. Low-risk, high-volume work that nobody enjoys doing by hand.
• RAG over your own documents. Retrieval-augmented generation that grounds every answer in your material: post archive, handbooks, product data, past tickets. The model retrieves the relevant passages at request time and answers from them, so hallucinations drop and citations point back to your pages.

Why WordPress AI integrations break

The default plugin pattern in 2026 still hides token costs in subscription pricing or silently consumes the customer's keys without surfacing per-feature spend. The default LLM pattern still trains on whatever you send it unless you opt out per request. The default editorial workflow assumes the AI's draft is the final draft. Each of those defaults is wrong for a WordPress estate that has to defend itself in an audit, an editorial integrity review, or a budget review.

The failure mode is rarely the model being wrong. It is the absence of the boundary around it: no cap, so a loop bills for a weekend; no provenance, so nobody can say which post the AI touched; no review gate, so an unchecked answer reaches a customer. The integration work is mostly building those boundaries, not calling the API.

Build in core, plugin, or custom integration

There is no single right answer. The decision turns on how much the feature touches customer data, how much cost control you need, and whether the flow is standard or specific to your store. This is how the three patterns compare for a typical WordPress or WooCommerce site.

Most engagements land on a mix: core or a trusted plugin for the low-stakes tasks, a thin custom integration for anything touching customer data or a budget you must defend. On the hosting side the same logic applies to the model itself. A hosted model (Claude or OpenAI over an EU-routed endpoint) is the right default for almost everyone: no GPU to run, current models, EU residency available. A self-hosted open-weight model earns its place only when a strict data-locality mandate forbids third-party inference, and it comes with real operating cost and a quality gap you should measure before committing.

How I integrate AI safely

The safety work is the integration. Four controls carry most of the weight, and each maps to a real way these projects go wrong.

• API-key security and data residency. Bring-your-own-key by default, so you hold the contract with Anthropic or OpenAI and the keys never sit in a plugin's shared pool. Keys live in server-side secrets, never in the browser or in post meta. Editorial and customer data routes through EU inference endpoints by default, with training opt-out set per request.
• Cost controls. A hard monthly cap per integration, enforced at the gateway rather than trusted to good behaviour. Per-feature metering so finance sees which use case spent what. A model-tier policy that sends cheap work to cheap models and reserves the expensive tier for output where quality pays. Embedding and prompt caching to cut repeat spend.
• Human review and guardrails. Opt-in suggestion plus a human decision, never autonomous publishing. Customer-facing replies are draft-only. Prompts are versioned and pinned; retrieval is scoped with permission boundaries so the model cannot surface content a reader should not see. Output passes validation before it can be saved.
• Provenance and observability. Every AI-assisted artefact records the model, prompt version, retrieval source, and the editor who reviewed it. Token usage, latency, and error rate feed observability. A quarterly review asks the only question that matters: did each use case earn its token spend, and which should be cut.

AI and compliance: labelling generated content

The EU AI Act, Article 50, sets a transparency baseline: content that is generated or meaningfully altered by AI has to be marked as such, in a form both people and machines can detect. For a WordPress publisher that is not a legal footnote to bolt on later. It is a build requirement that shapes how the integration stores and surfaces provenance.

Every integration I ship carries the disclosure through by design: a machine-readable provenance record on each artefact and a visible label where the content is published, consistent across all six site locales. If your estate falls under NIS2 or DORA, the model providers also enter your supplier register, which the same metadata makes straightforward to evidence. The full pattern is documented in our guide to AI Act labelling for AI-generated content.

Who this is for

• Publishers running WordPress with editorial teams that want assisted, not replaced
• WooCommerce stores wanting semantic product search and AI-supported customer support
• Content sites with multilingual archives that need translation review at scale
• B2B SaaS using WordPress as marketing surface that wants RAG-grounded sales enablement

What this costs

Pricing is individual. I do not publish a rate card because the scoping step usually changes the shape of the build, and because there are two separate costs to reason about. There is the integration work, which is a scoped project or a quarterly retainer. And there is the token spend, which under bring-your-own-key you pay directly to the model provider and which the per-feature metering keeps visible and capped. You are never surprised by an opaque AI line item, and you can turn any single feature off the moment it stops earning its keep.

Engagement model

Senior B2B contracts on EU jurisdiction. Four-week typical first engagement: scope the use cases that pay back, set up key management and data residency, wire the AI step into your editorial workflow as opt-in review, and instrument the cost model. Pricing is individual. Quarterly review retainer available for teams that want new use cases added and spend reviewed on a cadence.