Creating an AI chatbot for your website is five steps, and the install is the shortest of them. On WordPress the free route is a plugin with 100,000 installs, AI Engine, and getting it activated takes about five minutes. Every guide stops at that point, which is why so many people finish the guide and still do not have something they would show a customer. The first genuinely working version is an afternoon. The version that behaves well on a bad day is most of a month, and almost none of that month is configuration.
Here are the five steps in the order they actually happen, with what breaks at each.
What do you need before you start?
Four things, and only one of them is software. Gather them first, because discovering you are missing the third one halfway through is what turns an afternoon into a fortnight.
| What you need | Why | If you skip it |
|---|---|---|
| Pages that contain the answers | Retrieval can only find what exists | It declines constantly, or invents |
| A model key | Something has to do the answering | Nothing runs |
| A decision about exclusions | Some pages must never be quoted | It quotes a policy you retired in 2023 |
| Somebody who reads the answers | Quality drifts and nothing reports it | You find out from a customer |
The first row is the whole project in disguise. If your delivery cutoff lives in one person’s head and your returns window is three sentences in an email template, there is nothing to index. Writing three pages, delivery, returns, and sizing or compatibility for whatever you sell, is an afternoon and it improves your site for every visitor who never opens a chat window.
The fourth row is the one nobody assigns. It is half an hour a week and it cannot be bought with a bigger plan.
Which route should you take?
Three, and they differ by how much of the middle piece you write yourself. There is no arrangement where the browser talks to the model directly, because your key would be in the page and a key in a page is a key in public.
A plugin is right for most people. You install, connect a key, choose what it may read, and style the widget. You inherit the vendor’s opinions about retrieval, which for a first chatbot is a feature rather than a compromise.
A no-code connector, Zapier or Make, suits teams already living in those tools. It is slower per answer and priced per task, so it gets expensive at volume, but it is honest about what it is doing and easy to change.
Your own endpoint is a few hundred lines and the right call if you want to own the decisions or reach data a plugin cannot see. The Plugin Developer Handbook is where that starts on WordPress. You are now maintaining it, which is the part to be clear-eyed about before you begin rather than in month three.
How do you point it at your content?
Two steps, and the second is where products differ more than their marketing suggests.
First, index. Your pages are split into passages and each passage is converted into a numeric representation by an embedding model. Split on headings and paragraphs rather than on a fixed character count, because a passage gets read out of context by definition and half a sentence answers nothing.
Second, retrieve and instruct. At question time the question is embedded the same way, the closest passages come back, and they go to the model with an instruction to answer from them and to say so when they do not contain the answer. OpenAI’s retrieval guide covers the mechanism if you are building it.
Exclusions are part of this step, not a later tidy-up. Drafts, password-protected pages, checkout and thank-you pages, and anything marked noindex should never be in the index. Checkout pages in particular can carry order details, and a retrieval system does not know that a page was not meant for strangers.
What breaks at each step?
Predictably, and in roughly this order. Knowing the list in advance turns each one from a crisis into a Tuesday.
| Step | The usual failure | The fix |
|---|---|---|
| Indexing | It read the checkout and thank-you pages | Exclude by pattern, not by typing URLs |
| Retrieval | It answers from a page you retired | Find and delete the old page, then re-index |
| Refusal | It invents rather than declining | Put the instruction in the prompt and test it |
| Widget | It covers the sticky add-to-cart bar on a phone | Check on a real phone, not a narrow browser |
| Launch | The handoff lands in an inbox nobody reads | Decide who watches it before you switch it on |
Row two is worth a sentence. Every site trading for a few years has a page nobody links to, stating terms that were true once. Retrieval 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 quoting your old returns window back at you.
Row four is the one people skip because it is boring. A widget rendered inside a shadow root will not break your theme, but nothing stops it sitting on top of the one control your customer needs. Open your own site on your own phone and try to buy something.
How do you know it is ready for customers?
By asking it twenty things you already know, and reading the answers properly instead of skimming them.
Write the twenty questions down first, with the correct answer beside each, before you touch the bot. Doing it in that order stops you grading on a curve. Then ask all twenty and score three columns: is it correct, does it cite a page that actually says so, and for the questions your site genuinely cannot answer, does it decline or does it invent.
The third column is the one that decides whether you ship. A bot that declines and offers a person is safe to put in front of customers on day one. A bot that invents a delivery window is not, however good the other nineteen answers were, because the failure is silent and lands on your customer rather than on you.
Then keep sampling after launch: twenty random conversations a week, not the escalated ones. The escalated ones are already visible. You can see ours behaving on the demo, and the configuration detail is in the docs.
How should you actually launch it?
Narrowly, and this is the step almost every guide leaves out. The default is a switch that turns it on for every visitor on every page at once, and taking that default is how a small problem becomes a public one.
Start on one page where you already know the questions. A single product page, or the delivery page, where you can predict most of what will be asked and recognise a wrong answer immediately. Some products let you scope the widget to a page or a template; if yours does not, that is worth knowing before you buy.
If you cannot scope it, show it only to yourself first. A query string in the URL or a check for a logged-in administrator is enough, and a day of browsing your own site as a customer finds the things a test script does not: the panel covering the size selector, the answer that is technically right and reads as rude.
Watch the first fifty real conversations before you widen it. Not the summary, the conversations. Fifty is small enough to read in one sitting and large enough that the pattern in the failures becomes obvious, and the pattern is almost always one missing page rather than fifty bad answers.
Two practical things before you switch it on. Know where the off switch is and who can reach it, including at the weekend, because “we could not turn it off” is a much worse sentence than “it said something wrong”. And tell whoever handles support that this exists, before a customer does. A handoff arriving in an inbox from a system nobody mentioned gets ignored, and the customer was told help was coming.
None of this is slow. Scoped launch to full launch is usually a week, and it is the week that decides whether anybody in your company trusts the thing.
When should you not do this yourself?
Three cases, and none of them is about technical ability.
If your content does not contain the answers, building the chatbot is the wrong next step and writing the pages is the right one. This is the most common situation and the one most likely to be skipped, because installing software feels like progress and writing a returns page does not.
If nobody will own the checking, do not switch it on. A chatbot is not a thing you finish; it is a thing that drifts as your policies change, and the drift is invisible until a customer finds it. Half an hour a week is the whole commitment, and a team that cannot name who does it is a team that will not do it.
And if a wrong answer is expensive, in anything medical, legal, financial or regulated, the refusal behaviour is not the last thing you test. It is the first, and if it is not solid the correct decision is not to ship at all.
Set against those, the ordinary case is genuinely achievable in a weekend. For what this category actually contains, start with what an AI chatbot for a website actually is, and the interface half is in making a widget that fits your site.
Questions we get on this
How do I create an AI chatbot for my website?
Five steps, in this order: check that your pages actually contain the answers, pick a route between a plugin, a no-code connector and your own endpoint, index the right content while excluding drafts and checkout pages, decide what happens when it cannot answer, and test it against twenty questions you already know. Skipping the first step is the most common reason the finished thing disappoints.
How long does it take to set up an AI chatbot?
The install is minutes and the first working version is an afternoon. What takes longer is everything that makes it safe to show people: the exclusions, the refusal behaviour, the re-indexing, the widget on a phone, and reading enough of its answers to trust them. Budget an afternoon for a tidy small site and most of a month for a shop whose policies are scattered.
Do I need to know how to code?
Not for the plugin route, which is the right one for most people. You install, connect a model key, choose which content it may read, and style the widget. Coding becomes necessary when you want the chatbot to reach live store data such as order status, or when you want to own the whole path yourself, and that is a genuine project rather than an afternoon.
What do I need before I start?
Pages that contain the answers, a model key, a decision about what must never be indexed, and somebody who will read the bot’s answers. The last one is the one people skip and the only one that cannot be bought. A chatbot nobody checks drifts quietly from useful to confidently wrong, and nothing in any dashboard reports it.
Can I add an AI chatbot to WordPress without a plugin?
Yes, by putting a small endpoint of your own between the widget and the model, which is the right answer if you want to own the decisions or reach data a plugin cannot see. It also means you now maintain it. For most sites the plugin route gets you to the same place in a fraction of the time, and the free options are genuinely good.
How do I test the chatbot before launching?
Write down twenty real customer questions with the correct answers beside them, before you test anything, then ask all twenty and read the replies properly. Score three things: whether it is right, whether it cites a page that actually says so, and what it does with a question your site cannot answer. That last one matters most and is the one nobody deliberately tries.
