WordPress AI Connectors Solve the Wrong Problem

WordPress is trying to make AI work inside WordPress.

Part of the series starting with WordPress for Blogs Is Dead.

That sounds reasonable until you think about who actually benefits from it.

WordPress 7.0 introduced a Connectors API with an initial focus on AI providers. The official announcement describes standardized API key management, provider discovery, and an admin UI for configuring AI services. It also names Anthropic, Google, and OpenAI as built-in featured connectors.

That all sounds very modern. It also feels like WordPress looked at the AI moment, panicked, and built the most WordPress-shaped version of AI possible.

Not the best version. Not the most useful version. The most WordPress-shaped version.

• A settings screen
• Provider cards
• API key fields
• Plugin discovery
• A registry
• Constants
• Environment variables
• Database-stored keys
• Admin UI
• Filters
• Hooks
• A developer note explaining the lifecycle

Of course.

This is exactly how WordPress over-engineers a trend until the original value gets buried under a pile of implementation details.

The problem is not that AI has no place near WordPress. AI absolutely has a place near WordPress. The problem is that WordPress is trying to make AI useful by pulling it into wp-admin, when the better AI workflow is usually outside WordPress, closer to the code, the content model, the design system, the deployment pipeline, and the actual project.

If AI can only talk to WordPress, it can mostly help with WordPress-shaped things.

If AI can talk to the repo, it can help with the site.

That difference matters.

The wrong user gets the wrong tool

There are basically two groups of people who might care about AI in WordPress.

Novice or semi-technical users

The first group is novice or semi-technical WordPress users. They know how to log into wp-admin, install a plugin, update a page, maybe paste in a shortcode, maybe use a page builder, maybe write a blog post. They are not developers, and they should not have to be.

What they do not want:

• Provider discovery
• API key management
• Environment variable priority
• PHP constants
• Masked database-stored credentials
• Model provider configuration

What they want:

• Help writing content
• Help editing a page
• Help making something look better
• Help generating ideas
• Help rewriting text
• Help producing an image
• Help improving SEO
• Help summarizing something

They do not want to learn that their ChatGPT subscription is not the same thing as OpenAI API billing.

That distinction alone is going to confuse a massive number of people.

A normal person might pay for ChatGPT, see OpenAI in WordPress, generate an API key, paste it into a settings screen, and assume everything is covered. It is not. API usage is billed separately. Claude has its own billing. Google has its own setup. Each provider has its own limits, keys, dashboards, and terminology.

WordPress can make that slightly easier to configure. It cannot make that simple.

Technical users

The second group is technical users. These are people who already use ChatGPT, Claude, Cursor, Claude Code, GitHub Copilot, or whatever tool they prefer. They know how to get real work out of AI. They can prompt, review, reject bad output, iterate, and wire AI into an actual development workflow.

Those users have the opposite problem.

If I know how to use AI well, why would I want to trap it inside WordPress?

What they do not want:

• AI only helping me generate post content inside an editor

What they want:

• AI helping me think through the whole site
• It helping with components, layouts, content structure, frontmatter, route organization, CSS, accessibility, performance, deployment, redirects, metadata, feeds, search, and whatever else the project needs

That work does not live inside wp-admin.

That work lives in the codebase.

AI inside WordPress is too small

When AI runs inside WordPress, the center of gravity is the admin screen.

That means the workflow starts from the assumption that the site already exists, the structure is already WordPress-shaped, the content model is already post types and taxonomies, the editor is Gutenberg, the admin is the interface, and the job is to help the user do something within those walls.

Sometimes that is useful.

If a client needs to summarize drafts, generate headline ideas, rewrite blocks, produce excerpts, suggest tags, or help editors move faster inside WordPress, fine. That can be useful. Large editorial teams may eventually get real value from AI workflows tied into the CMS.

But that is not the same thing as AI-assisted development.

AI-assisted development changes the whole process. It can help design the site before the CMS exists. It can help decide whether a CMS is needed at all. It can generate a first pass at the component architecture. It can refactor the design system. It can reorganize content files. It can improve route structure. It can identify repeated patterns. It can reduce CSS. It can write migration scripts. It can generate tests. It can review pull requests. It can explain why something is slow.

WordPress AI connectors mostly ask, “How do we connect AI providers to WordPress?”

The better question is, “Why should WordPress be the place where this AI workflow happens?”

For many blogs and smaller content sites, it should not be.

WordPress already had external access

The strangest part is that WordPress already had ways for external tools to interact with it.

WordPress has a REST API. WordPress has Application Passwords. WordPress has XML-RPC, even if a lot of people understandably do not love leaving it enabled. WordPress already has mechanisms for authenticated tools to create content, update content, upload media, and interact with the site from outside wp-admin.

Application Passwords are specifically designed for programmatic access without sharing a user’s main password. A script, integration, mobile app, or external tool can authenticate as a WordPress user and call the REST API.

So if the goal is “let an AI-powered tool interact with WordPress,” we already had the bones for that.

An AI tool can authenticate to WordPress. It can fetch posts. It can create drafts. It can update content. It can upload media. It can work from outside the admin. A developer can build that today without WordPress core needing to pretend every AI provider should become a first-class settings card.

That does not mean the existing APIs are perfect. They are not. WordPress authentication can still be annoying. The REST API is not always pleasant. Custom fields, block content, media workflows, and permissions can get messy fast.

But the direction matters.

External AI tools talking to WordPress through APIs make sense.

WordPress turning itself into an AI provider management layer feels like a different thing. It feels like WordPress trying to own the AI workflow instead of exposing the site cleanly to tools that are already better at AI.

That is the wrong instinct.

The API key problem is not a UI problem

WordPress can add a nice settings screen for AI providers. It can show cards for Anthropic, Google, and OpenAI. It can link people to credential pages. It can mask the keys. It can check environment variables first, then constants, then the database.

That is all implementation.

The hard part is not where the field lives.

The hard part is that the user still has to understand what they are connecting, what they are paying for, what permissions they are granting, what data might leave the site, what provider is being used, what model is being called, what tokens cost, what happens when a key leaks, how to rotate it, and why their existing AI subscription may not apply.

A UI does not remove that complexity. It hides some of it until the bill shows up or something breaks.

Developers can handle that. They may not enjoy it, but they can handle it.

Normal WordPress users are going to be confused by it.

Serious AI work belongs near Git

The best AI workflows I use are not magic buttons in admin screens.

They are conversations around a project.

I can ask AI to look at a component and simplify it. I can ask it to compare two approaches. I can ask it to generate a first pass, then tear it apart. I can ask it to find repeated CSS. I can ask it to help name things. I can ask it to make the design more consistent. I can ask it to turn loose notes into an outline, then into prose, then into a publishable draft. I can ask it to explain why a build fails. I can ask it to help me wire deployment. I can ask it to review a diff before I merge.

That is not “AI content generation.”

That is AI-assisted production.

WordPress keeps thinking in terms of the admin. Modern AI workflows think in terms of the project.

That is why static sites and AI pair so well. A static blog in Astro, Eleventy, Hugo, Jekyll, Next.js, or even a bare-bones React setup can put the whole thing in front of the AI. The posts, layouts, components, styles, configuration, metadata, scripts, and deployment behavior all live in a repo. AI can see the actual shape of the product.

WordPress splits the world apart.

Some of the site is in code. Some of it is in the database. Some of it is in plugin settings. Some of it is in theme options. Some of it is in block markup buried in post content. Some of it is in custom fields. Some of it is in a page builder. Some of it is in serialized arrays that look like they were designed as a punishment.

That is not a great environment for AI.

It is not impossible. It is just worse.

WordPress AI will create more mediocre content

There is also the quality problem.

The easiest AI feature to sell is content generation. Write a post. Rewrite this section. Generate a headline. Suggest tags. Create an excerpt. Add SEO keywords.

Some of that is useful. A lot of it is going to be garbage.

WordPress already made it easy for people to publish mediocre content. AI makes it easy to publish mediocre content faster. Connecting AI providers inside WordPress does not automatically make the content better. It just shortens the path from half-formed idea to indexed sludge.

That sounds harsh because it is harsh.

Good writing does not come from putting a model closer to the Publish button. Good writing comes from taste, revision, structure, opinion, experience, and having something to say. AI can help with that process, but only if the person using it knows how to push past generic output.

A WordPress settings screen cannot create taste.

That is why the workflow matters. When AI is part of a broader writing and development process, it can help turn messy thinking into something sharper. When AI is just another button inside the CMS, it is going to encourage a lot of people to publish words that sound like words.

The web already has enough of that.

WordPress is trying to look modern instead of being useful

AI is now one of those features every platform feels pressure to announce.

Nobody wants to look behind. Nobody wants to be the CMS that “missed AI.” Nobody wants to say, “Use the best AI tools directly and let WordPress expose clean APIs.”

So WordPress does what WordPress often does. It absorbs the trend into its own architecture.

That creates activity. It creates dev notes. It creates meetings. It creates APIs. It creates admin screens. It creates plugin opportunities. It creates conference talks. It creates something to point at when someone asks what WordPress is doing about AI.

But activity is not strategy.

A good AI strategy for WordPress would start with the strengths and weaknesses of WordPress itself. It would ask where WordPress should be exposed to AI tools, where it should stay out of the way, where structured content needs to improve, where block markup makes external editing harder, where permissions matter, where editor workflows truly need help, and where the platform should not try to compete.

Instead, WordPress appears to be building a provider layer.

That may be useful infrastructure for some plugins and enterprise workflows. I am not saying there is no value anywhere. I am saying it does not solve the big problem.

The big problem is that AI makes the alternatives to WordPress more capable.

WordPress is responding by making WordPress more complicated.

The better path is smaller

WordPress does not need to be the place where every AI interaction happens.

It needs to be better at being WordPress.

• Give developers cleaner APIs
• Make structured content easier to work with
• Make block content less painful outside the editor
• Improve performance
• Improve metadata
• Improve media handling
• Improve revision workflows
• Improve deployment stories
• Make the admin faster
• Make the basics better

Let AI tools talk to WordPress from the outside.

Let plugin developers build specialized AI features where they make sense.

Let editorial teams adopt AI workflows that fit their actual process.

Do not force AI provider management into the center of WordPress and pretend that serves the 80%. See WordPress Forgot Why WordPress Won.

That is how WordPress keeps ending up in this stupid place where the most advanced features feel disconnected from the most basic publishing needs.

The uncomfortable conclusion

If someone does not know how to use AI well, WordPress AI connectors probably will not help them much.

If someone does know how to use AI well, WordPress is often the wrong place to put the workflow.

That is the trap.

The novice user gets more configuration than they need. The advanced user gets less power than they already have elsewhere.

WordPress AI connectors solve a problem, but not the most important one.

The most important problem is not “How do we connect OpenAI to wp-admin?”

The most important problem is “What role should WordPress play when AI makes building, designing, restructuring, and deploying non-WordPress sites easier than ever?”

That is a much harder question.

It is also the question WordPress seems to be avoiding.