How to Train a Chatbot on Your Website Content (No Code)

Most chatbots that embarrass their owners were trained correctly. The crawl worked, the pages were indexed, and the bot answers confidently — with last year's pricing, a support email that bounces, and a returns window that changed in March.

The bot is not wrong. Your website is, in three places you had forgotten about, and now those three places have a voice.

You can train a chatbot on your website content without writing a line of code, and the crawl takes minutes. What separates a bot that deflects real support volume from one that generates apologetic follow-up emails is the twenty minutes of review afterwards. Here's the whole job, in order.

What "Training" Actually Means Here

The word is misleading, and the misunderstanding causes real decisions to go wrong.

Nothing about the AI model changes when you point it at your site. What happens is closer to building a private search index:

1. Your pages are fetched and stripped down to their readable text — navigation, cookie banners and footers discarded.
2. That text is split into short passages, a couple of hundred words each.
3. Each passage is converted into an embedding, a numerical fingerprint of its meaning, and stored.
4. When a customer asks something, their question is converted the same way, the closest passages are pulled back, and a language model is asked to answer using only those passages.

This is retrieval-augmented generation, the standard architecture for website-trained bots, and what it gives you is operational. Answers are grounded in your text rather than the model's general knowledge, so the bot can cite where an answer came from, and updating it means re-crawling a page rather than retraining anything. The longer comparison is in RAG vs fine-tuning for a business chatbot.

The practical consequence: your bot's quality is a content problem, not an AI problem. No model choice compensates for a pricing page that hasn't been touched since 2024.

How to Train a Chatbot on Your Website: Four Steps

1. Crawl, but know what the crawl catches

Paste your URL. The crawler starts there and follows internal links breadth-first, staying on your domain.

SahayBot caps a crawl at 30 pages with extractable text, three link hops deep, 15,000 characters per page, with a four-minute hard stop on the whole job. Those limits exist because they match how support questions actually distribute — the answers people need live on your pricing, FAQ, shipping, returns, and contact pages, which are all within two clicks of your homepage. A 5,000-page crawl mostly adds blog archives that dilute retrieval.

What a crawler cannot read, on any platform:

• Text inside images — including the pricing table someone exported as a PNG
• Content behind a login — your customer portal, your help centre if it's gated
• PDFs linked from a page — these are separate files, not page text
• Anything rendered only after a JavaScript interaction — accordion FAQ panels are the usual casualty
• Pages the crawler can't reach — orphan pages with no internal link pointing at them

That last one catches people out. If your refund policy is only linked from a checkout email, no crawler will find it.

2. Review the pages before you save them

This is the step everyone skips, and it's the one that pays. A crawl returns a list of pages with the text it extracted from each. Read the list. You are looking for three things:

• Pages that shouldn't be there. Careers listings, press releases, the 2023 Diwali offer. Every one of these is a passage that can be retrieved instead of the right one.
• Pages that came back empty or garbled. A page rendered entirely in JavaScript, or one where extraction grabbed the cookie banner and nothing else.
• Pages that are missing. Compare against your own mental list of what customers ask about. Anything absent is a gap you'll fill in step three.

Nothing is saved until you approve it, which is deliberate — a review step is cheap before launch and expensive after.

3. Fill the gaps by hand

The crawl gets you most of the way. It does not get you all the way, because some of what customers ask has never been written down publicly.

Source	What it covers well	What it misses
Website crawl	Product, pricing, policies, company info	Anything undocumented or gated
Uploaded documents (.pdf, .docx, .txt, .md, up to 5MB)	Manuals, spec sheets, internal policy docs	Nothing, if the doc is current
Written Q&A pairs	The exact wording of your top 20 questions	Anything you didn't think of
Support ticket history	The questions customers really ask	Requires cleaning before use

Two additions are worth the effort every time.

Your top 20 questions, written as Q&A pairs. Pull them from your inbox or live chat history. Write each answer in one short paragraph, in the words customers use rather than your internal terminology — customers ask "how do I get my money back", not "what is your refund remediation policy". These are the highest-value passages in the whole knowledge base because they match how questions are actually phrased.

The documents nobody publishes. Your shipping matrix, your warranty terms, the onboarding guide you email new clients. Upload them directly.

4. Set the boundaries, then launch quietly

Before the widget goes live, decide two things. What the bot should refuse: anything involving account changes, refunds, medical or legal specifics — these escalate to a human. And how it hands off: a visible route to a person, with the transcript carried across so the customer doesn't repeat themselves.

Then launch on one page rather than site-wide. A week on your FAQ or pricing page generates enough real questions to show you what's missing, with limited exposure if the answers aren't right yet. The setup walkthrough in the docs covers the widget embed, which is one script tag on WordPress, Shopify, Webflow, Wix or any site where you can edit the template.

Why Passage Size Matters More Than You'd Think

One technical detail leaks into the customer experience.

Passage size is a real trade-off. Too small, and a passage loses the context that makes it meaningful — "This does not apply to orders placed before the 15th" is useless without knowing what "this" is. Too large, and retrieval gets vague: a 2,000-word page is about twelve things, so it matches everything weakly and nothing strongly.

Published retrieval benchmarks put the useful range at a few hundred words per passage, with Chroma's evaluation of chunking strategies finding recall in the 85–90% band for straightforward recursive splitting at around 400 tokens. SahayBot splits at roughly 200 words with a 40-word overlap between adjacent passages, so a sentence that straddles a boundary appears in both and never gets orphaned.

You don't configure any of this. What you can control is the shape of your content, and that's where the gain is: write in short, self-contained sections with descriptive headings. A page with clear H2s splits cleanly along meaning. A wall of text splits arbitrarily.

The Content That Makes a Bot Worse

Adding more is not always better. Four categories reliably degrade answers:

• Marketing copy. "Industry-leading solutions that empower your business" answers no question and competes with real content for retrieval slots.
• Old blog posts. A 2023 post describing a discontinued feature will be retrieved with the same confidence as your current documentation. Nothing in the system knows which is newer unless you tell it.
• Near-duplicate pages. Three regional variants of the same shipping policy means the bot picks one, and it may not be the one that applies to the person asking.
• Legal boilerplate. Terms of service are written to be complete, not to be answered from. They retrieve well against almost any question and give unusable answers.

Between 40 pages of mixed quality and 15 current, well-written ones, take the 15.

When Your Website Isn't Enough

Two honest cases where this approach won't carry you.

When your answers depend on the individual customer. "Where is my order", "how much do I owe", "when does my plan renew" — none of these live on a web page. They live in your order system, and answering them needs an integration, not a crawl. A website-trained bot handles the general and escalates the specific, and the ticket-reduction economics still work, because general questions are the bulk of the volume.

When your website genuinely doesn't document your business. Some companies sell through conversation, and their site is a brochure. Training a bot on a brochure produces a bot that talks like a brochure. The fix isn't a better platform — it's writing the answers down first. That's worth doing regardless of whether a bot ever reads them.

After Launch: the Twenty Minutes a Week

Training isn't a one-off. Two habits keep a bot accurate:

1. Read the unanswered-question log. Every question the bot couldn't handle, in the customer's own words, ranked by frequency. It's the most useful output the system produces and the most commonly ignored. Add answers for anything that appears more than twice.
2. Re-crawl after any content change. The stored copy is a snapshot from crawl time. Editing the live page doesn't update it. Pricing, hours, policies and contact details are the ones that cause real damage when stale.

Both live in the agent dashboard, and both are on the free plan — a bot you can't inspect is a bot you can't fix. SahayBot is built by NoCubical.

Get the content right and the rest of it is a script tag.

Frequently Asked Questions