Most website chatbots fail the same way: they sound confident and get your hours, services or policies wrong. A chatbot is only useful if it answers from your content and admits when it doesn't know.
I built HeshBot, the assistant on my own site, to work exactly that way. Here's what a site assistant actually needs, using HeshBot as the worked example.
1. A small chat widget
The part visitors see is a chat button and a panel. HeshBot's widget is plain vanilla JavaScript with no framework and no third-party chat platform. It loads quickly, matches the site's look, and sends questions to one endpoint on your own hosting.
2. One server endpoint
Behind the widget is a single PHP 7.4 endpoint that runs on ordinary shared hosting. It receives a question, adds the right context from your content, calls the model, and returns the answer. Because it runs on your server, the API key stays on your server too, stored outside the web root where a browser can't reach it.
3. A knowledge file built from your own pages
This is what makes an assistant grounded. HeshBot uses a Python build script that reads the site's public pages and turns them into a knowledge file. That's a small piece of workflow automation: when the site changes, re-run the script and the assistant knows about the change.
The rule is simple: the assistant answers only from that knowledge file. If the answer isn't there, it says so and points the visitor to the contact details instead of guessing.
4. The model
HeshBot runs on HeshLLM:20B, a model I build and fine-tune myself. For other projects, a hosted frontier LLM API can be the better fit. Either way, grounding matters more than model size: a well-grounded assistant on a fine-tuned model beats a giant model that's allowed to make things up.
5. Guardrails
A public chat box is an open door, so it needs locks. HeshBot uses:
- Per-IP rate limits so one visitor or script can't flood it
- Message caps on length and conversation size
- A same-origin check so other sites can't borrow your endpoint
- The API key kept outside the web root
Those come from 25+ years in technical support and my Google Cybersecurity certificate training: assume someone will try to misuse it, and plan for that from day one.
6. Try it, then read how it was built
Open the chat on trevorheshka.com/heshbot/ and ask about my services or projects. For the build story, read how HeshBot was built. The code is open source under the MIT licence: github.com/YardPhantom/HeshBot.
A version for your business
For a business, the same approach works on your own pages, FAQs and documents: an assistant grounded only in your content, so it doesn't make things up, with the same guardrails, on your hosting. See HeshBot for business and AI chatbots in BC.
I'm based in Nanaimo on Vancouver Island and work remotely across BC and Canada. Email me for a quote.
Originally published at trevorheshka.com.
Top comments (2)
Good point on answering only from the knowledge file and admitting when it doesn't know. Two small additions that have helped us: keep that file to a short fact list (hours, prices, policies) rather than the whole site, and log every question the bot couldn't answer so you can add those facts weekly. It also helps to say up front that it's an AI, and to have a clear human handoff that captures a name plus email or phone when it can't help, so after-hours enquiries don't get lost.
— Neil
Good point about the bot admitting when it doesn't know. One thing that helps in practice: write the fallback answer first, with a clear next step like a phone number or contact form, so a miss still ends in a lead rather than a dead end. I'd also keep a short list of the ten questions customers ask most, test the bot against them whenever the knowledge file is rebuilt, and read the real conversations weekly to spot gaps. Hours and pricing are the first things to go stale, so give them a single source of truth.
— Neil