Most WordPress AI plugins are a textarea and an API key. They draft a paragraph, rewrite a meta description, or add a chat widget. That can be fine on a laptop. It is not a production system.
Production means the feature has a job, a failure mode, a cost, and an owner. It means you know what happens when the model is slow, when it is wrong, and when a page with the plugin on it is hit by a crawler. It means personal data does not leave the site in a prompt unless you intended that.
WordPress can host that kind of AI. It usually does not, because the plugin directory rewards demos.
What fails in the wild
Front-end chat on a marketing site. The widget loads a third-party script on every page, talks to a model with the full page as context, and invites visitors to ask questions the model will invent answers to. Legal pages, pricing, and medical or financial claims are the first casualties. You also pay for bot traffic.
One-click “generate the blog”. A bulk generator that publishes twenty posts overnight will tank quality, create near-duplicate URLs, and train your editors that the site is not worth reading. Search engines have seen this pattern. So have readers.
Editor sidebars with no review. A metabox that writes into the live title and excerpt on blur is a publish pipeline with no preview. Autosave then locks the generated text into revisions.
Image and SEO packs that hit external APIs on page view. If the plugin generates alt text or schema when the page is rendered, you have turned TTFB into a model round-trip. That is the opposite of performance work.
Keys in wp-config that every administrator can use. A shared OpenAI key in the database, visible to shop managers, is not a credentials model. It is a bill waiting to happen.
No evaluation. The plugin cannot tell you whether yesterday’s answers were right. There is no golden set, no sampling, no human score. You find out from a customer.
These are the same reasons generic AI features fail in other stacks. WordPress adds a plugin that can enqueue assets globally, a user model that is often too trusted, and a culture of “install it and see”.
Jobs that are worth doing
AI on WordPress earns its keep when it sits behind a human, off the hot path, and against a defined artefact.
Draft, don’t publish. Generate a first pass of a page in a draft post or a private note. An editor accepts, rewrites, or bins it. The model never has publish_posts in practice, even if the user account does.
Moderation and triage. Flag comments, form messages, or support mail that look like spam, abuse, or a real booking problem. A human still decides. This is closer to support copilots than to a public chatbot.
Internal summaries. Turn a 4,000-word policy page into a briefing for staff. Keep it in admin or in a staff-only site. Do not replace the canonical page with the summary.
Schema and metadata assistance. Suggest titles, excerpts, and structured data. Write them into fields the editor can see. Do not inject JSON-LD from a live model call.
Migration mapping. Given a list of ACF field names and a theme grep, propose a mapping for a rebuild. An engineer confirms. This is modernisation support, not a content feature.
Search that is actually retrieval. If you need Q&A over docs, use a retrieval index you control, cite sources, and keep it off the marketing runtime. WordPress can store the docs. It does not have to serve the model.
Notice what is missing: a floating chat bubble, autoblogging, and anything that runs on wp_footer for anonymous visitors.
Production constraints on a CMS
WordPress is a request/response PHP application with plugins. That has consequences.
Do the model work in a job, not in the request. WP-Cron or a real queue. The editor clicks “suggest”, waits for a notice, and reviews. Visitors never wait on an inference.
Cache everything you would be embarrassed to pay for twice. Suggested titles for a post ID should not hit the API on every metabox load.
Budget the key. Per-site keys, monthly caps, and a hard disable when the cap trips. Shared agency keys across fifty client sites are how one client’s loop pays for everyone’s month.
Treat prompts as content. Version them, like any other production artefact. If you change the system prompt for product descriptions, that is a release. We already version prompts in engineering teams; WordPress should not be the exception because the prompt lives in a plugin option.
Keep PII out of prompts unless the processor is under contract. WooCommerce orders, SuperControl guest names, form emails, and membership records do not belong in a consumer chatbot API. Use staging data, redaction, or do not build the feature.
Measure. Sample outputs weekly. Track cost per accepted draft, not cost per token in the abstract. If editors reject 80% of suggestions, turn the feature off.
Performance budget. No extra third-party script on the public theme unless the feature is the product. AI that adds 400ms and 200KB to a cottage site is a net loss.
Plugins versus custom
A plugin is acceptable when it does one job in admin, stores nothing sensitive beyond a scoped API key, and can be disabled without breaking templates. Most “AI for WordPress” suites fail that test because they enqueue front-end chat, rewrite SEO, generate images, and offer a dashboard of upsells.
Custom is worth it when the job is specific: a moderation queue for a membership site, a draft assistant that reads ACF fields your theme actually uses, a retrieval tool over a knowledge base you own. That is ordinary product engineering that happens to run next to WordPress, not a page-builder add-on.
Nought’s WordPress platform is operations infrastructure — Suite, Nought.io, Local — not an AI overlay. When we put models near WordPress, it is for a named workflow with the same production bar we use everywhere else: evaluation, fallbacks, and a human who can say no.
Agency retainers make this worse
On a 50-site retainer, one “AI for WordPress” plugin multiplied across clients is 50 extra update surfaces, 50 API keys, and 50 chances that a front-end script ships on a site that did not ask for it. Standardise on not installing the suite. If a client has a real job — drafts in admin, comment triage — enable that job on that site, with a cap, and review it at renewal.
Do not sell WordPress AI as a line item that means “we turned on a plugin”. Sell a workflow with an owner. If there is no owner, there is no production feature.
A short allow-list
Ship it if:
- It runs in admin or in a job, not on public page render.
- A human publishes.
- You can cap spend and revoke the key in one place.
- You can explain the data that leaves the site.
- Turning the plugin off does not white-screen the theme.
Do not ship it if the demo is a chat widget, a bulk publisher, or a promise that the site will “run itself”.
The rule
WordPress AI in production is a constrained assistant for people who already operate the site. It is not a personality bolted onto the front end.
If the feature cannot survive a disabled API key, a spike in traffic, and an editor who disagrees with the model, it is still a demo. Keep it off the public request.