Almost every guide about chatbots covers installation. Almost none cover the part that decides whether it works: what you train it on.
Installing takes five minutes. Choosing sources well is what separates a chatbot that deflects real support volume from one that says "I'm not sure about that" forty times a day. This guide is about that choice.
Start from your inbox, not your sitemap
The instinct is to feed it everything. That is the wrong starting point.
Open your support inbox and read the last fifty messages. Group them. You will almost always find that five or six question types cover most of the volume: shipping, returns, pricing, compatibility, account access, and one thing specific to your business.
Those groups tell you which pages to add. Everything else is optional.
Pages worth adding
Policy pages. Shipping, returns, refunds, warranty. High question volume, clear factual answers, rarely change. Best value per page.
FAQ pages. Already written as question-and-answer, which is the format people ask in. The FAQ-writing guide covers how to make one that a chatbot can use well.
Product or service documentation. Specs, setup guides, compatibility. These generate the questions that take your team longest, because the answer is not on the product page.
Pricing pages. People ask constantly. One caveat below.
Getting-started or onboarding content. Deflects most new-customer questions.
Pages to leave out
Your blog archive. Blog posts are opinion, marketing, and time-bound claims. A chatbot answering a policy question from a two-year-old blog post is a real problem.
Marketing and landing pages. They are persuasive, not factual. Trained on them, the chatbot starts pitching instead of answering.
Careers pages. Unless you specifically want a hiring bot, this pollutes support answers.
Anything outdated you have not deleted. If it is stale on the site, it is stale in the chatbot, and harder to notice.
Rule of thumb: if a page's job is to persuade, leave it out. If its job is to inform, add it.
The pricing page problem
Pricing pages are high-value and high-risk. Prices change; a chatbot trained on an old page will quote an old number confidently.
Two ways to handle it:
- Leave pricing out and let the chatbot hand off to your team or point at the live page.
- Include it, and re-add it every time pricing changes. Put this on the same checklist as updating the page itself.
Option one is safer. Option two deflects more. Pick deliberately rather than by accident.
Mixing sources
Website pages are not the only input, and combining formats usually beats any one of them:
- Website pages + a product PDF: the site covers policy, the PDF covers detail
- Website pages + a walkthrough video: the transcript adds the practical explanation your docs assume
- Docs site + FAQ: official and practical together
One chatbot holds all of these. Someone asking a question does not know which format holds the answer, and with mixed sources they do not have to. The train on your own data page lists every supported source type.
Set up the handoff before you launch
This is the setting people skip and then regret.
During setup you add support contacts. When the chatbot cannot answer, it routes there instead of guessing. Without it, an unanswerable question is a dead end and a lost customer; with it, it is a normal support ticket.
Configure this before you put the widget on a live page, not after.
Test it like a customer, not like the person who built it
The mistake is testing with questions you know the answer to, phrased the way the source phrases them. Real customers do neither.
Run four tests:
- Exact. Something stated plainly on a page you added. Should be precise.
- Rephrased. The same fact, in your customer's words. "Do you deliver to Portugal?" rather than "What is your shipping coverage?"
- Multi-page. Something needing two sources. "If I return a sale item, do I pay return shipping?"
- Out of scope. Something you never added. It must say so and hand off.
Test four is non-negotiable. A chatbot that invents shipping timelines or refund windows creates disputes.
After launch
The first two weeks tell you more than any amount of planning.
Watch what people actually ask. You will find questions you never anticipated, and questions where the answer was thin. Both point at the same fix: add the source that answers it.
That is the whole maintenance loop. Read the gaps, add the page, re-test. The support ticket guide turns it into a weekly routine with numbers attached.
Keep it current
A chatbot answers from what you gave it, at the time you gave it. Change a policy on your site and the chatbot keeps quoting the old one until you re-add the page.
Put it on the same checklist as the page edit. It takes a minute and prevents the single most damaging failure mode: being confidently, specifically wrong about your own policy.
Frequently asked questions
Can I just point it at my homepage and let it crawl? You add pages deliberately rather than crawling, and that is a feature. Crawling pulls in the blog, the careers page, and every stale announcement. Five chosen pages answer better than five hundred discovered ones.
How often should I re-add pages? Whenever the page changes. Policies and pricing are the ones that matter; product documentation less often. A monthly review of the questions it could not answer catches the rest.
Does this need a developer? No. Adding sources is a dashboard task, and on hosted website builders the embed is a paste into a custom-code field. The platform guides show where.
