Adding an AI Chatbot to a Website You Already Have

Adding an AI chatbot to a site that is already live is mostly a content problem wearing an engineering costume. You are not building a brain. You are taking knowledge that already exists (scattered across pages, PDFs, a help centre and two people's heads) and making it retrievable in conversation. Six steps, in the order they actually matter.

1. Inventory the questions you actually get

Open the last two hundred support emails or chat transcripts and tally them. Not a workshop, not a survey. Just count. Almost every business we do this with finds the same shape: nine or ten questions account for most of the volume, and at least two of them are questions the website was supposed to have answered already.

That tally is the business case. If the top ten are all policy and product questions with written answers, a chatbot will do well. If they are all "can you quote me for this specific job", it will not, and you should spend the money on a better quote form instead.

2. Find out where each answer lives

Take the list and write the source next to each question. A URL, a document, or a person's name. Every item that resolves to a person's name is a gap, and gaps are the single biggest predictor of how the project goes.

3. Ground it in retrieval, not fine-tuning

This is the most common expensive mistake, and it usually comes from a vendor rather than from the client. Fine-tuning adjusts how a model writes. It is poor at teaching it facts, and a fine-tuned mistake can only be corrected by training again.

Retrieval works the other way round. Your content gets indexed, the relevant passages get pulled at answer time, and the model writes from those with a citation. Correcting a wrong answer means editing one page. Adding a new product means publishing a new page. Your marketing team can fix the bot without opening a ticket, which is the whole point.

4. Install it without wrecking your page speed

Here is the part that gets skipped, and it is measurable. Published measurements put the heaviest hosted chat widgets at 500 to 750 KB of JavaScript, with lighter alternatives under 155 KB, and put the average cost of adding one at 300 to 600 ms of extra main-thread blocking. A render-blocking widget has been measured doubling First Contentful Paint from 1.0 seconds to over 2.3.

That cost is paid by every visitor on every page, including the roughly 97% who never open the chat. It shows up in Interaction to Next Paint, which is a Core Web Vital, on a site you have presumably already spent money making fast.

The fix is not clever, it is just work somebody has to choose to do. Render a small static button in your own markup. Fetch the real chat bundle when that button is clicked, or during a requestIdleCallback after the load event once the page has done everything that matters. Measured this way, the Lighthouse cost of a chat widget drops from around 9 to 16 points to roughly nothing.

Whatever you install, run PageSpeed Insights before and after on the same page and keep both reports. If your vendor will not do that, do it yourself.

5. Design the refusal before you design the greeting

Decide in writing which questions the bot must never attempt: refunds, complaints, medical or legal specifics, anything about a signed contract, anything priced case by case. Then decide where each of those goes instead, and make that handoff land somewhere a human actually looks.

This is a legal control, not a stylistic preference. In Moffatt v. Air Canada, decided by the British Columbia Civil Resolution Tribunal in February 2024, the airline was held liable for a bereavement-fare answer its chatbot gave a customer. Air Canada argued the chatbot was a separate entity responsible for its own statements. The tribunal disagreed, finding the company responsible for all the information on its website regardless of which part of the site produced it. Damages were small, CAN$812.02, and the principle was not.

6. Measure resolution, not deflection

Deflection counts conversations no human touched. That total quietly includes the customer who gave up, the one who phoned instead, and the one who left. Resolution counts problems actually solved. A vendor dashboard reporting 80% on the first definition can be performing worse than one reporting 55% on the second.

Agree the definition before you agree a target. Then review the failed questions weekly and turn them into content, which is the loop that makes the thing get better instead of slowly rotting.

The mistakes we see most

• Indexing the whole site indiscriminately. Your blog archive, old landing pages and a careers post from 2021 will all come back as sources. Curate what gets indexed.
• No source links on answers. Without them you cannot tell a hallucination from a badly written page, and you will blame the wrong one.
• Launching straight to customers. A week of shadow mode, where the bot drafts and your team approves, finds problems no test script does.
• Hiding the human. A visible route to a person raises trust and, counter-intuitively, tends to reduce the number of people who take it.
• Nobody owning the content afterwards. A chatbot is not a project that finishes. It is a publication that needs an editor.

When not to bother

If your documentation is thin or out of date, fix that first. A chatbot over stale content produces confident wrong answers at speed, which is worse than the silence you have now. If you field fewer than about thirty repeat questions a month, a well-organised FAQ page will serve your customers better for a fraction of the money. And if the real problem is a checkout that breaks on mobile, fix the checkout.