There is a chatbot on every WordPress site now. Almost nobody clicks them. Meanwhile, the AI work that would actually move the needle — automated alt text, semantic search, AI-assisted editorial workflows, code-level security review — mostly isn't happening. Here's what's worth building, and what to skip.
Every WordPress site shipped a chatbot in the last twelve months. Almost none of them are used. Meanwhile, the AI integrations that would actually make a platform better — quietly, in the background, where users don’t have to notice them — mostly aren’t getting built. The default AI strategy for WordPress in 2024 has become: bolt on a chat widget, hope it deflects support tickets, move on. That isn’t an AI strategy. It’s a feature.
The chatbot problem.
The chatbot has become the visible proof that a site “has AI.” It’s also, in most cases, the wrong AI investment. Three reasons:
- Most B2B visitors don’t want one. A senior buyer evaluating a service provider doesn’t want to talk to a bot. They want to read the site, get their questions answered by the content, and then talk to a human if they’re serious. The chatbot is friction, not capability.
- The training data is usually the site itself. If the chatbot’s only knowledge source is your existing public content, it’s strictly less useful than reading that content. The visitor could have found the same answer faster with the search bar.
- The maintenance cost compounds. Models change. Prompts drift. The chatbot that worked on launch day breaks in a new model release six months later, and now you have a support burden you didn’t plan for.
None of this means chatbots are universally wrong. They can earn their keep on high-volume support sites where a fraction of tickets really are FAQ-deflectable. They mostly aren’t earning their keep on a marketing site for a B2B consultancy.
What “AI capabilities” actually means.
The interesting AI work in WordPress is structural, not surface. It changes what the platform does rather than adding a new UI element on top. A capability is something the site couldn’t do before, that runs whether the visitor notices or not. A few categories worth knowing:
- Editorial workflow assist. AI-generated draft alt text on image upload, with editor review. AI-suggested categories or tags based on the post body. Semantic similarity surfacing “related” posts as the editor writes. The work that used to fall to the human at the end of the queue, partially automated.
- Site-wide content infrastructure. Embeddings-backed search that understands intent rather than keywords. Automated content audits that flag stale pages by analyzing the corpus. Translation pipelines that make multilingual sites maintainable instead of frozen.
- Code-level review. LLM-assisted security audits that flag patterns static scanners miss. Pull request review that catches accessibility regressions before deploy. Generated documentation for custom plugins, kept in sync as the code changes.
- Privacy-respecting personalization. First-party signal — what someone has read on this site, in this session — used to vary CTAs or recommendations, without surveillance pixels. AI on the inputs the site already has, not on identity inferred from third-party trackers.
None of these have a visible “AI” badge. None of them ship as a widget. They show up in faster editorial work, more accessible content, fewer security regressions, better search results. They make the platform better at being a platform.
What to be careful of.
Not every AI integration that could be built should be built. A few patterns to be skeptical of:
- AI features that depend on third-party data. If the AI works by sending visitor data to a model provider, you’ve created a third-party dependency that someone needs to disclose in your privacy policy. Often the simpler answer is to do less.
- AI features that drift silently. Anything that affects what visitors see needs a human-readable log. “The AI changed something” is not an explanation that survives a content audit.
- AI features that replace human judgment on accessibility. Auto-generated alt text is a draft, not a finished product. Letting it ship without editorial review will produce alt text like “a person standing in a room” for every photo on your site — technically compliant, practically useless.
- AI security tools without verification. An LLM that flags a vulnerability has to be checked by someone who knows what a vulnerability looks like. Otherwise you’re just creating a more confident version of the same problem.
How to evaluate AI features for your WordPress site.
Before adding any AI capability, three questions:
- What does this do that the site couldn’t do before? If the answer is “respond to user questions,” the existing content already does that. If the answer is “generate draft alt text for every image at scale,” that’s a real capability.
- Who maintains it when the model changes? Every AI integration is a moving target. If there’s no plan for the day the underlying model is deprecated or behaves differently, the integration will eventually be a liability rather than an asset.
- Does it require sending data off-site? If yes, the privacy implications need to be modeled and disclosed. If the capability can be delivered with on-site computation or with a vetted provider under a data-processing agreement, that’s usually the better path.
The right AI strategy for most WordPress sites in 2024 is to skip the chatbot, identify two or three editorial workflow bottlenecks that AI could meaningfully accelerate, and build capabilities into those workflows. Quieter, more durable, and far more valuable than another widget in the corner of the page. See practical AI integration for what that looks like in practice.
Common questions.
Should I add a chatbot to my WordPress site?
Usually no, unless you’re running high-volume customer support where genuine FAQ deflection is on the table. For B2B, consulting, marketing, and content-led sites, the chatbot is more likely to cost you trust than earn you leads. The right alternative is better content and better site search, not a conversational interface.
What’s the difference between an AI chatbot and a semantic search?
A chatbot pretends to be a person and tries to interpret intent. A semantic search returns ranked content based on meaning rather than keyword match. The semantic search trusts the visitor to read; the chatbot tries to mediate. For most use cases, semantic search delivers more value with less risk.
How do I know if an AI feature is worth building?
The honest test: would you build the same feature without AI if you could? If the answer is yes, this is a real capability the site needs, then AI is the right implementation choice. If the answer is no, we only want this because it has “AI” in the name, that’s a signal to skip it.