You mostly do not train an AI chatbot on your own data. You index it, and the difference is the whole answer. Training, in the sense of fine-tuning, teaches a model how to sound rather than what is true, so a model fine-tuned on your support transcripts will still invent a delivery window when somebody asks. Indexing is the other thing: your pages are split into passages and each passage becomes a list of numbers, 1,536 of them for one of the common OpenAI embedding models, so a question can be matched against them at the moment it is asked.
Almost everybody asking the first question wants the second one.
What does training actually mean here?
Three different mechanisms get called training, and they change three different things. Picking the wrong one is the most expensive mistake in this area, because fine-tuning costs real money and time and does not do what the person paying for it expected.
| Approach | What it changes | When it is right |
|---|---|---|
| Prompt instructions | How it behaves in every reply | Always. This is the cheapest lever and the first one |
| Retrieval | What facts it can use | Whenever the answer lives in your own content |
| Fine-tuning | Its tone, format and style | When output shape matters more than output facts |
The middle row is the one you want and the bottom row is the one people buy. A model fine-tuned on a thousand of your past support replies will answer in your house voice, open with your greeting, and confidently state a returns window it has no way to check. It learned the shape of your answers, not the contents of your site.
Facts change. A trained model does not. That single sentence decides the architecture.
How do you point it at your own content?
In two steps, and both of them have a detail that gets skipped.
Split, then embed. Your pages are cut into passages, usually a few hundred words each, and every passage is converted into a numeric representation by an embedding model. The detail here is where the cuts fall. Splitting on a fixed character count slices sentences in half and produces passages that answer nothing; splitting on headings and paragraphs produces passages that stand alone, which is what you actually want, because a retrieved passage is read out of context by definition.
Match, then instruct. At question time the visitor’s question is embedded the same way, the closest passages come back, and those go to the model with an instruction to answer from them and to say so when they do not contain the answer. That last clause is not decoration. It is the difference between a system that declines and one that guesses, and it belongs in the prompt whether or not the vendor put it there.
On WordPress the content usually arrives through the REST API, which is also why a plugin can do this without you exporting anything.
What should it never read?
More than you would guess, and getting this wrong is how a chatbot ends up quoting a policy you retired two years ago.
| Page type | Index it | Why |
|---|---|---|
| Published pages, posts, products | Yes | This is the material the whole thing runs on |
| Drafts and scheduled posts | No | Unpublished means not yet true |
| Password-protected or members-only | No | Indexing it makes it public through a side door |
| Checkout, cart, thank-you pages | No | No answers live there, and they can carry order details |
| Retired campaign and old policy pages | Judgement | Usually no, and this is where the old returns window hides |
The last row is the one that bites. Every site that has traded for a few years has a page somebody forgot to delete, stating terms that were true once. Nothing links to it, so nobody thinks about it, and a retrieval system does not care whether a page is linked. It will find that page, quote it accurately, and you will hear about it from a customer.
If the exclusion control a product offers is a list of URLs you type in by hand, you will forget one. Ask for pattern matching, and ask whether it respects noindex automatically.
What happens when you edit a page?
The passages built from it have to be rebuilt, and when that happens is a real difference between products rather than an implementation detail.
Re-indexing on edit means your correction is live in seconds. Re-indexing nightly means the price you fixed this morning is wrong to every customer until tomorrow, and nothing anywhere reports that gap. Neither approach is dishonest, but only one of them matches what a shop owner assumes when they hit update.
Deletion is the same question wearing a different hat. When a page goes, its passages have to go with it. A bot answering from a page that now returns a 404 is citing a source the reader cannot open, which is worse than declining, and it is the kind of fault nobody notices until somebody quotes it back at you.
Ask both questions in these words: is re-indexing triggered by an edit or a timer, and what happens to a passage when its page is deleted. Both are cheap to answer honestly.
How does this work on a multilingual site?
Each language is indexed and retrieved separately, and the failure when it is not looks exactly like success, which is why it survives so long.
Point an indexer at a whole multilingual site without telling it about languages and it builds one pool of passages in several languages. A Dutch visitor asks a Dutch question, the closest passage happens to be the English one, and the model obligingly answers in Dutch from English source material. The answer reads fluently. The customer cannot check it, because the page it cites is in a language they did not ask in. And nothing in any dashboard reports a problem, because from the system’s point of view retrieval succeeded.
The correct arrangement is dull: every passage carries its language, retrieval filters on the language of the question, and a question in a language with no matching content gets a decline in that language rather than a translated answer from another one. On WordPress the multilingual plugins already model translations as separate posts, so the language is sitting there on each page waiting to be carried through.
There is a related temptation worth naming. Machine-translating your English pages to fill the gaps in other languages produces an index that answers everything and is trusted by nobody who reads it properly, because translated policy text goes subtly wrong exactly where precision matters: cancellation windows, liability, sizing. If a language matters enough to answer in, it matters enough to write in.
Two questions settle this with any vendor. Does retrieval filter by language, and what happens when a language has no page covering the question. An answer of “the model handles it” means no.
How do you know it is working?
By asking it things you already know, and reading the answers properly rather than skimming them.
Write down twenty questions your customers actually ask, with the correct answer beside each one, before you test anything. Then ask all twenty. This takes an hour and it is the most informative hour in the whole project, because it turns a vague impression of quality into a list of specific failures you can fix.
Score three things per answer. Is it correct. Does it cite a page, and does that page actually say it. And for the questions your site genuinely cannot answer, does it decline or does it invent. That third column is the one that matters most and the one nobody checks, because you have to deliberately ask something unanswerable to see it.
Then keep sampling. A standing half hour a week, reading twenty random conversations rather than the escalated ones, finds the quietly wrong answers. The escalated ones were already visible.
When is your own data not enough?
When the answers are not in it, which is a more common situation than the tooling implies.
A retrieval system can only find what exists. If your delivery cutoff lives in one person’s head, if sizing guidance is something your team says on the phone, if the returns policy is three sentences in an email template, then there is nothing to index and the honest outcome is a bot that declines a lot. That is the system working correctly and reporting a content problem.
The fix is writing, not configuration. Three pages cover most of what a shop is actually asked: delivery, returns, and sizing or compatibility for whatever you sell. Writing them properly is an afternoon and it improves your site for every visitor who never opens a chat window.
The other case is contradiction. If two of your pages disagree, retrieval will find both and the model will pick one, and which one is not something you control. Before indexing, search your own site for the phrase that matters most, the returns window or the delivery cutoff, and see how many different answers come back. That search is free and it is usually uncomfortable.
The free option worth starting from is AI Engine, and OpenAI’s own retrieval guide covers the mechanism if you are building it yourself. What our version reads and refuses to read is on how it works, with the specifics in the docs. For the category as a whole, start with what an AI chatbot for a website actually is, and the interface in front of it is in making a widget that fits your site.
Quick answers
How do I train an AI chatbot on my own data?
In almost every case you do not train it, you index it. Your pages are split into passages, each passage is converted into a numeric representation, and at question time the closest passages are handed to the model with an instruction to answer from them. That is retrieval, and it is what makes a bot answer about your business. Training, in the sense of fine-tuning, is a different tool for a different job.
What is the difference between fine-tuning and retrieval?
Fine-tuning changes how a model writes: its tone, its format, the shape of its replies. Retrieval changes what it can say anything true about. If you fine-tune on your support transcripts you get a model that sounds like your support team and still does not know today’s stock. The facts have to arrive at question time, every time, because facts change and a trained model does not.
What file formats can I use as training data?
For retrieval, the format matters far less than people expect: HTML pages, Markdown, PDFs and plain text all reduce to passages of text in the end. What matters is whether the content is current and whether one fact appears in only one place. A PDF price list from last year is a worse input than a well-written page, whatever the file extension.
How often should the chatbot re-read my site?
When a page changes, not on a schedule. A nightly rebuild means a price you corrected this morning is wrong to customers until tomorrow, and the gap is invisible because nothing reports it. Ask any vendor whether re-indexing is triggered by an edit or by a timer, and treat a timer as a real limitation rather than an implementation detail.
Can the chatbot read my PDFs and documents?
Usually yes, and you should think twice before letting it. Documents accumulate in a way pages do not: superseded price lists, an old terms file, an internal note that was never meant to be public. A retrieval system will quote any of those with equal confidence. Index documents deliberately, one at a time, rather than pointing it at a folder.
Will my data be used to train somebody else’s model?
That depends entirely on the arrangement and it is a question worth asking in writing. If you hold the model key you are working under your own agreement with the provider and can check the terms yourself. If the vendor holds it, you are relying on their contract and their configuration, and the honest version of that answer appears in a data processing agreement rather than on a pricing page.
