# AI chatbot for website: what it is and how to pick one

> By Lawrence Dauchy, Founder, DFYe. Published 2026-09-09. 10 min read. Guides.
> Source: https://dfye.com/blog/ai-chatbot-website/
> Language: en

The category covers four different products that share a name. Telling them apart before you install anything saves the month you would otherwise spend finding out.

**TL;DR.** An AI chatbot for a website reads your published pages, turns them into passages, and answers visitor questions from those passages rather than from general knowledge. At least 826,000 WordPress sites run some kind of chat widget, and almost none of it is AI: the most-installed one is a button that opens WhatsApp. The four kinds on the market differ less in features than in how much of the work you finish yourself.

An AI chatbot for a website reads the pages you have already published, splits them
into passages, and answers a visitor's question from the passages that match it.
That is the whole category in one sentence, and it is the part most product pages
skip. At least **826,000 WordPress sites** run some kind of chat widget, measured
against the [WordPress.org plugin API](https://api.wordpress.org/plugins/info/1.2/)
on 8 September 2026, and almost none of that is AI at all. The most-installed one
is a floating button that opens WhatsApp.

So the first useful question is not which product to buy. It is which of four
different things sharing one name you actually want.

## What is an AI chatbot for a website?

It is a retrieval system with a chat window on the front. Your pages are converted
into numeric representations, a visitor's question is converted the same way, and
the passages closest to the question are handed to a language model with an
instruction to answer from them. The mechanism is described plainly in
[OpenAI's embeddings guide](https://platform.openai.com/docs/guides/embeddings),
and every product in this category is some arrangement of those same parts.

What separates the products is not the model. Everyone is calling the same handful
of models. What separates them is what happens around the retrieval: which pages
get read, how the passages are scored, what the thing does when nothing scores well,
and whether the answer arrives with the page it came from attached. Our own account
of those steps is on [how it works](/how-it-works/), and every vendor should be able
to give you theirs in the same detail.

That last one is worth dwelling on, because it is the difference between a tool you
can check and a tool you have to trust.

## Which kind should you actually install?

Four products share this name and they are not substitutes for each other. The
honest way to choose is to decide how much of the work you intend to finish
yourself, because that is the axis they actually differ on.

| Option | Best for | Why it works | Main limit |
|---|---|---|---|
| Messenger button | A shop with one person answering | Nothing to configure, no answers to check, the visitor reaches a human | Answers nothing at 2am, and the visitor has to leave your site |
| Human live chat | Teams with support hours | A person handles nuance a model cannot | Costs a salary, and coverage ends when the shift does |
| AI framework plugin | Developers who want control | You choose the model, the prompt, the index, the styling | You are finishing a product, and that is a project rather than an install |
| AI chat product | Site owners without a developer | Arrives working, indexes your pages, styles itself | You get the vendor's opinions about retrieval, and usually their model key |

The framework and the product rows are where most of the confusion lives. AI Engine,
the most-installed AI option on WordPress at 100,000 installs with a 4.9 rating
across 864 reviews, is a framework, and an excellent one. To
get value from it you bring an API key, choose a model, build the knowledge base and
style the widget. That is the right tool if you want those decisions. If you wanted
the thing to arrive already answering, it is a project you did not know you had
signed up for.

Nothing above is a recommendation in either direction. A messenger button is a
completely reasonable answer for a shop that gets nine questions a week, and our own
[comparison pages](/compare/) name the free option first wherever it is the better
one.

## How does it know what is on your site?

By crawling what you have published and rebuilding that index when you change it.
The good implementations read published pages, posts and products, skip anything
marked noindex, skip drafts and password-protected pages, and re-read a page when
it is edited rather than on a nightly schedule that leaves your prices stale for
fourteen hours.

The failure mode to ask about is exclusion. A shop usually has pages it does not
want quoted back at customers: an old shipping policy, an internal page that was
never linked, a landing page for a campaign that ended. If the only exclusion
control is a list of URLs you type in by hand, you will forget one.

Deletion is the other half of the same question. When you remove a page, the
passages built from it have to go with it. A bot still answering from a page that
now returns a 404 is citing a source the reader cannot open, which is worse than
not answering at all, and it is the kind of fault nobody notices until a customer
quotes your old returns policy back at you.

The second thing to ask about is what happens on a multilingual site. Indexing a
Dutch page and answering a Dutch question from an English passage produces fluent
nonsense. Each language has to be indexed and retrieved separately, which sounds
obvious and is skipped surprisingly often.

## What does it cost?

The number on the pricing page matters less than the shape behind it, because the
shape decides whether a good month costs you more than a bad one.

| Pricing shape | What you are paying for | Goes wrong when |
|---|---|---|
| Per message | Each exchange with a visitor | Traffic spikes, or a bot scrapes you, and the bill follows |
| Per seat | Human agents with logins | You wanted automation and are paying for chairs |
| Per resolution | Conversations the bot closed | The vendor defines what counts as resolved |
| Flat licence, your own key | The software, once or yearly | You have to get your own model key, which is a five-minute job people avoid |

Per message is the shape that catches people out, and it is worth being specific
about why. Your support load does not scale with your revenue. A product that goes
briefly viral, a delivery delay that makes three hundred people ask the same
question, a competitor linking to you: all of those raise your message count without
raising your income. A flat licence with your own key moves that risk onto the model
provider's per-token price, which is public and falling.

None of that makes per-message pricing dishonest. It makes it a risk you should take
deliberately rather than by default.

## How long does setup really take?

Installing the plugin takes minutes. Every vendor quotes that number and every
vendor is telling the truth about the wrong thing.

The real work is three jobs. Pointing it at the right pages, which on a tidy site is
ten minutes and on a shop with policies scattered across the footer is an afternoon.
Excluding the pages it must not read, which nobody enjoys and everybody skips.
And then the job that actually decides whether this was worth doing: asking it
twenty questions you know the answers to, and reading what it says.

That third job is where you find out whether you bought a retrieval system or a
confident stranger. Ask it something your site genuinely does not answer. A good
one says it does not know and offers you a person. A bad one invents a delivery
window.

The widget's own weight is worth thirty seconds of your attention too. A chat widget
is the one plugin whose output loads on every page for every visitor, so a heavy one
taxes your whole site rather than one template. The ones built properly render inside
a [shadow root](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)
so your theme and the widget cannot break each other, and load after your content
rather than before it. We measured our own on the way to
[dropping a 31kB animation library](/blog/we-dropped-gsap/) for thirty lines of
code, which is the same habit applied to a smaller problem.

## What about privacy and the law?

Visitor questions are personal data, and the vendor processing them is a processor
under [GDPR Article 28](https://gdpr-info.eu/art-28-gdpr/). That means a written
agreement, named sub-processors, and a defensible answer to where the conversations
are stored.

This is the question most worth asking before you install, because it is the one
you cannot retrofit. If the vendor holds the model key, your visitors' questions
pass through their account before reaching the model, and the list of parties with
a copy is longer than you would guess from the pricing page. If you hold the key,
the vendor is not in that path at all.

Ask three things: who holds the model key, whether conversations are used to train
anything, and what happens to the data if you stop paying. A vendor that answers
all three in plain language has thought about it.

## When is an AI chatbot the wrong answer?

Often enough that it deserves its own section.

If you get fewer than about ten questions a week, an answer to an email is cheaper
and warmer than any of this, and you will spend longer configuring the bot than you
would have spent answering. If your questions are mostly about order status, a link
to a tracking page on your confirmation email solves more of them than a chatbot
will. If your site genuinely does not contain the answers, a retrieval system has
nothing to retrieve, and the fix is writing the pages rather than installing
software to read the pages you did not write.

And if you sell something where a wrong answer is expensive, medical, legal or
regulated, the refusal behaviour is not a feature you evaluate at the end. It is the
first thing to test and the reason to walk away.

The pattern underneath all four is the same: this category is worth its cost when
the same question arrives often, the answer is already written down somewhere on
your site, and nobody is enjoying copying it into a reply. Outside that, it is
software solving a problem you do not have. The scan of what the market actually
installs, in [826,000 WordPress sites and almost no AI](/blog/wordpress-chat-plugin-market-2026/),
suggests most site owners have worked this out already.

## Quick answers

### What is an AI chatbot for a website?

It is software that reads the pages you have already published, splits them into
passages, and answers a visitor's question from the passages that match it. The
distinction that matters is the source of the answer: a general AI assistant answers
from what it was trained on, while a site chatbot answers from your own content and
can show you which page each answer came from.

### How much does an AI chatbot for a website cost?

Less than the pricing pages suggest, and in a shape that matters more than the
number. Four shapes exist: per message, per seat, per resolved conversation, and a
flat licence where you bring your own model key. Per message is the one that
surprises people, because the bill scales with your traffic rather than your
revenue, and a busy launch week costs more than a quiet month.

### Can I just use ChatGPT on my website instead?

You can put a general assistant on a page, but it will not know your delivery times,
your stock or your refund window unless something feeds it those. That feeding is
most of what a site chatbot product is. If your questions are general enough that a
public model already answers them well, you do not need this category at all, and
that is a real answer rather than a polite one.

### Does an AI chatbot make things up about my site?

It can, and this is the honest weakness of the category. A retrieval system that
finds no good passage will often answer anyway from general knowledge, confidently
and wrongly. The defence is a confidence floor and a visible source: the bot answers
only from passages that scored above a threshold, shows the page it used, and
declines below it. Ask any vendor what happens under the floor.

### How long does it take to set up an AI chatbot?

Installing takes minutes and is not the work. The work is deciding which pages it
may read, excluding the ones it must not, and checking what it does with a question
your site does not answer. Budget an afternoon for a small site and a week for a
shop with policies scattered across ten pages, most of it spent reading the bot's
answers rather than configuring anything.

## Sources

- [WordPress.org plugin API, the install and rating figures](https://api.wordpress.org/plugins/info/1.2/)
- [AI Engine on the WordPress.org plugin directory](https://wordpress.org/plugins/ai-engine/)
- [OpenAI: embeddings, the retrieval mechanism underneath these products](https://platform.openai.com/docs/guides/embeddings)
- [MDN: using shadow DOM, how a widget avoids colliding with your theme](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)
- [GDPR Article 28, processor obligations that apply to a chat vendor](https://gdpr-info.eu/art-28-gdpr/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*