# How to create an AI chatbot for your website: the real steps

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

Five steps, an afternoon for something that works, and most of a month for something you would let a customer meet on a bad day.

**TL;DR.** Creating an AI chatbot for a website is five steps: check the answers exist on your pages, choose a route, index the right content and exclude the rest, decide what it does when it cannot answer, and test it against questions you already know. The install is five minutes. The first working version is an afternoon. The one you would put in front of a customer is most of a month, and almost none of that is configuration.

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](https://wordpress.org/plugins/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](https://developer.wordpress.org/plugins/) 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](https://platform.openai.com/docs/guides/embeddings). 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](https://platform.openai.com/docs/guides/retrieval) 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](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)
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](/demo/), and the configuration detail is in [the docs](/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](/blog/ai-chatbot-website/), and the
interface half is in
[making a widget that fits your site](/blog/ai-widget-website/).

## Quick answers

### 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.

## Sources

- [AI Engine on the WordPress.org plugin directory](https://wordpress.org/plugins/ai-engine/)
- [WordPress Plugin Developer Handbook](https://developer.wordpress.org/plugins/)
- [OpenAI: retrieval](https://platform.openai.com/docs/guides/retrieval)
- [OpenAI: embeddings](https://platform.openai.com/docs/guides/embeddings)
- [MDN: using shadow DOM](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM)

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