How to Train a Client Chatbot on Website Content

TL;DR

• Do not treat the whole client website as ready chatbot knowledge. Audit pages before build or training work starts.
• Select source pages by visitor question, answer authority, freshness, and client approval.
• Clean thin, duplicated, sales-heavy, and outdated pages before they shape chatbot answers.
• Resolve contradictions before training. If two pages disagree, pick the approved current source or flag the issue.
• Write do-not-answer rules for unsupported pricing, guarantees, policy exceptions, sensitive claims, and account-specific questions.
• Log missing answers as content gaps so the chatbot does not guess from weak website content.

Your agency may already have the client's service pages, FAQ, policy pages, blog posts, and product copy. That does not mean you are ready to train chatbot on website content. The real work is deciding which pages are reliable enough to use, which need cleanup, which contradict each other, and which questions the chatbot should not answer until the client provides approved source material.

Key Takeaways

A chatbot knowledge set should be built from approved answers, not from every page a sitemap or CMS export can find.

Use visitor questions as the filter. A page is useful when it answers something a prospect, customer, or support contact is likely to ask and the client can stand behind the answer.

Content cleanup belongs before training. If a page is vague, duplicated, outdated, or written only as sales copy, it may create answers that sound confident but do not help the visitor.

Contradictions are content issues first. Do not expect the chatbot setup step to choose between two conflicting policy pages, two eligibility descriptions, or an old promotion and a current service page.

Missing answers should become a gap log. If the website does not explain pricing limits, next steps, support routes, or policy exceptions, the chatbot needs a boundary or routing rule, not a guess.

Start With The Pages Visitors Actually Ask About

The first selection rule is simple: include pages that answer real visitor questions and exclude pages that only add noise.

For most client websites, useful source candidates include service pages, product pages, FAQs, pricing or plan pages when approved, help content, policy pages, and current process pages. Some client projects may also use approved documents, videos, FAQs, and policies as knowledge sources. InsertChat's site describes knowledge sources in those terms: website pages, documents, videos, FAQs, and policies. Keep that framing careful. Approved materials can support a branded assistant, but the content still needs review before it becomes reliable chatbot knowledge.

Do not start with the sitemap and assume size equals quality. A large website can contain archived announcements, old campaign pages, thin location pages, duplicate service descriptions, and blog posts that no longer match the client's current offer. Including more pages can increase coverage, but it can also increase contradiction risk.

A useful first pass is to map pages to likely questions:

The tradeoff is coverage versus answer quality. If a page is likely to help visitors but has weak wording, keep it in the audit. If a page is irrelevant, obsolete, or not approved, remove it from the source set.

Score Each Page Before It Becomes Chatbot Knowledge

A page should earn its way into the knowledge set. Use a content readiness worksheet with one row per page and a small number of decisions.

Recommended statuses are:

• Include: the page is current, specific, approved, and answers likely visitor questions.
• Rewrite: the page has useful facts but needs clearer wording or missing detail.
• Merge: two or more pages overlap and should be consolidated into one approved answer.
• Exclude: the page is stale, risky, irrelevant, duplicated, or not useful for chatbot answers.
• Client decision needed: the page may matter, but the agency cannot choose the approved answer.

Use these criteria for each page: accuracy, specificity, completeness, freshness, answer authority, audience fit, and risk. A current support policy written by the operations owner has more authority than an old blog post about the same topic. A pricing page approved by the client has more authority than a sales deck snippet pasted into an old landing page.

A compact worksheet is enough:

This is not a full onboarding checklist. The agency should already have the initial client inputs, goals, and source materials. If those inputs are not collected yet, use an upstream AI chatbot onboarding checklist before this audit begins.

Clean Weak Pages Before Training

Weak website content creates quality risk because the chatbot can only work from the knowledge it is given. If the source page gives a vague answer, the chatbot may give a vague answer. If the source page makes a claim without limits, the chatbot may repeat that claim without the nuance a sales or support rep would add.

The most common cleanup targets are thin pages, duplicated service descriptions, sales-heavy copy, outdated tone, conflicting calls to action, and pages that answer only half of the question.

A thin service page might say the client offers "custom consulting for growing teams" without saying who qualifies, what the first step is, which services are included, or what the visitor should prepare. That page can support brand context, but it is not strong enough to answer operational questions. Mark it rewrite or gap, depending on whether the client can approve better content before training.

Duplicated pages need special care. Many client sites have a main service page, a location page, an industry page, and an FAQ that all describe the same offer in slightly different language. If the differences are harmless, merge the best parts into one approved answer source. If the differences change eligibility, pricing, timing, or responsibility, treat them as contradictions, not copy edits.

Sales-heavy pages often need translation into answer-ready copy. "We deliver premium strategy for ambitious brands" may fit a landing page, but it does not tell a chatbot how to answer "Do you work with local businesses?" or "What happens after I contact you?" Keep the brand voice, but add exact nouns, conditions, and next steps.

The caution is approval. Agencies should not quietly rewrite policy, pricing, service limits, legal claims, or security claims. If cleanup changes the meaning of an answer, send it to the client owner. If approval is not available, mark the answer as a gap or exclusion.

Resolve Contradictions And Freshness Issues Before Handoff

Contradictions are where website content breaks chatbot reliability. The assistant may be asked one simple question, but the website gives two different answers.

Common contradictions include:

• A service page says consultations are free, while the FAQ says they require a paid deposit.
• An old policy page says refunds are available within 30 days, while the current policy says 14 days.
• A product page says onboarding takes one week, while a help article says three weeks.
• A promotion page says a discount is active, but the offer expired months ago.
• A blog post describes a service the client no longer sells.

Use a source authority rule: current owner-approved pages beat older or less formal pages. If authority is unclear, do not choose by preference. Flag the contradiction and ask the client to select the approved answer.

Freshness review belongs in the same pass because stale pages often create hidden contradictions. Look for old dates, retired services, event pages, outdated screenshots, old process descriptions, past promotions, old staff references, and policy wording that no longer matches the client's current operations.

The output is a one-time update handoff for initial content preparation. It might say: "Update refund policy before training," "Exclude old campaign landing page," or "Confirm whether rush service still exists." That handoff can support later maintenance, but this article stops at the initial audit.

Write Do-Not-Answer Rules And A Gap Log

The content audit should decide what the chatbot should not answer. This is not a launch QA matrix. It is a source-based boundary list created before training or build work.

A good do-not-answer rule has three parts: the question category, the reason, and the safer response path.

Examples:

These rules should come from the audit, not from fear or guesswork. If the website has no source for a claim, the chatbot should avoid the claim. If a page supports a general answer but not a specific exception, the chatbot should state the general rule and route the exception.

A gap log captures the questions the website cannot answer yet. Useful columns include question, missing source, business owner, risk, needed content, and recommended next action.

Examples of gaps:

• The website explains the service but not the first step after a visitor asks for help.
• The FAQ mentions pricing but gives no approved range, plan, or qualification rule.
• The policy page covers standard cases but not exceptions visitors often ask about.
• The service page says "available nationwide," but another page mentions limited regions.
• The support page gives an email address but no urgent issue path.

The gap log separates content readiness from chatbot performance. If the source does not contain the answer, the chatbot should not be blamed for missing it. The agency can either get approved content, define a routing rule, or exclude the topic.

Scenario: Turning A Messy Client Website Into A Usable Knowledge Set

Consider a hypothetical home services client. The agency receives the main service pages, a general FAQ, several city pages, two policy pages, old blog posts, and a promotion page from last year.

The first pass maps pages to visitor questions. The current "Services" page answers what the company does, which property types it serves, and how to request an estimate. It is marked include. The city pages mostly repeat the same service copy with minor location references. They are marked merge because they add little unique answer value.

The FAQ has useful questions, but some answers are too vague. One answer says, "Rush appointments may be available depending on demand." The agency marks it rewrite because visitors will likely ask, "Can I get same-day service?" The client needs to approve the exact answer: available areas, cutoff times, fees, and routing path.

The audit finds two policy pages. One says cancellation requires 24 hours of notice. Another says 48 hours. The agency marks client decision needed and asks the operations owner to approve a single cancellation answer.

The old promotion page says new customers receive 20 percent off first service. The client confirms the promotion ended. The page is marked exclude. The chatbot should not mention the discount unless the client publishes a current approved offer.

The blog posts are mixed. A recent post explaining seasonal service preparation is useful and current, so it is marked include. An old post describes a service package the client no longer sells, so it is excluded. Another post includes useful general advice but no clear next step, so the agency marks it optional context, not a primary source.

The agency also writes do-not-answer rules. The chatbot should not quote discounts, promise same-day availability, interpret cancellation exceptions, or answer account-specific scheduling questions from public website content. Those questions should be routed or qualified.

The final gap log contains three items: approved rush appointment rules, updated cancellation policy, and urgent support routing. The client now has a clear content task list. The agency has a cleaner knowledge set.

Prepare The Content Handoff Before Build Or Training Starts

The final artifact should make the next step obvious for whoever builds or configures the assistant. Keep it narrow and content-specific.

Include these items:

• Approved source list: pages and materials cleared for chatbot use.
• Cleanup notes: pages rewritten, merged, or clarified before handoff.
• Exclusions: pages intentionally left out and the reason.
• Contradiction decisions: the approved answer or the unresolved client decision.
• Freshness updates: stale pages to update, remove, or ignore.
• Gap log: important visitor questions the website does not answer yet.
• Do-not-answer rules: topics the chatbot should refuse, qualify, or route.

This handoff does not need to explain platform architecture, vector databases, or exact ingestion steps. It should answer a simpler operational question: "What content can the chatbot safely rely on?"

For agencies, that is the practical difference between training from website content and training from website clutter. The better source set is usually smaller, clearer, and easier for the client to approve.

FAQ

How many website pages should an agency include?

There is no useful fixed number from the supplied context. Include pages that answer likely visitor questions with current, approved information. Exclude pages that are stale, duplicated, irrelevant, or not authoritative. A smaller approved set is usually safer than a broad set with contradictions.

Should old blog posts be used to train a client chatbot?

Use old blog posts only when they are still accurate, relevant, and approved for visitor answers. Exclude posts about retired services, past promotions, outdated policies, or advice the client no longer wants to support.

What should agencies do when two pages disagree?

Do not let both pages into the source set without a decision. Choose the current owner-approved source, or flag the contradiction for the client. The unresolved contradiction should go into the handoff, not into chatbot knowledge.

Can a chatbot answer questions that are not on the website?

Only if the client provides another approved source for that answer, such as a document, FAQ, video, or policy. If no approved source exists, create a gap entry and a do-not-answer or routing rule.

Where does content preparation stop and QA begin?

Content preparation stops when the agency has an approved source list, cleanup notes, exclusions, contradiction decisions, freshness issues, gap log, and do-not-answer rules. QA begins later, when those rules are tested in actual conversations before launch.