Keeping the AI Chatbot Knowledge Base Up to Date: Crawl Cadence, Sources, and QA

An AI chatbot knowledge base is not a one-time import of a few FAQ pages. It is an ongoing operational process. As soon as prices, services, opening hours, product limits, privacy texts, or support processes change, a chatbot with outdated sources can provide well-formulated but incorrect answers. This is exactly where it is decided whether a website chatbot builds trust in everyday use or merely acts like a pretty search box.

For website operators, the good news is: you don't immediately need a massive AI governance program. First, you need a clear list of approved sources, a realistic crawl cadence, technical checks for indexing, and a small QA routine for typical user questions. This article shows how teams from marketing, support, and product can operate their knowledge base so that answers become more current, traceable, and less prone to hallucinations.

Why currency is more important than the initial import

Many chatbot projects start with the question: "Which files do we upload?" This is too narrow a view. The more important question is: "Which source will be the truth in the future, and when does the chatbot notice that it has changed?" A PDF brochure updated once a quarter requires different treatment than a pricing page, a help center article, or a status notice in support.

Retrieval-Augmented Generation, or RAG, combines a language model with external knowledge sources. Google Cloud describes RAG as context enrichment, where proprietary data provides the model with additional context so that answers are better grounded and more accurate. Microsoft simultaneously points out that RAG quality depends heavily on content preparation, chunking, multilingual search, semantic ranking, and appropriate retrieval logic. For website teams, this means: the chatbot does not automatically get better just because more content is indexed. It gets better when the right content is current, structured, and discoverable.

What belongs in a verified knowledge base

A verified knowledge base contains only sources that are professionally approved and whose owners are known. This may sound bureaucratic, but it saves a lot of corrective work later. If no one knows whether an old blog post, an offer PDF, or a landing page is still binding, the chatbot should not derive definitive statements from it.

Suitable sources

Well-suited are stable pages with clear responsibility: product and service pages, current FAQs, help articles, shipping or appointment rules, integration documentation, verified pricing logic, onboarding documents, and public guidelines. Internal documents can also be useful if they contain no sensitive data and access rights are accurately mapped. Microsoft calls granular access and security trimming a central RAG challenge, because users and systems should only retrieve content for which they are authorized.

Sources that should be checked first

Caution is advised with old PDFs, campaign landing pages, legal drafts, unverified blog posts, automatically generated transcripts, and historical support tickets. Such content can be useful if curated. Without approval, however, they easily mix old phrasing, special cases, or individual opinions into answers that sound binding to current customers.

Crawl cadence: not every page should be crawled with the same frequency

A good crawl cadence is based on the risk of change and the impact on the user. A contact page or pricing page should be updated faster than an evergreen guide. An FAQ on delivery times or support availability needs more frequent checks than a basic article. Teams can divide sources into three classes:

• Critical: Prices, availability, opening hours, security, privacy, contract terms, support channels. Update daily or after every release.
• Operational: Help center articles, product features, integration guides, onboarding processes. Update several times per week or based on releases.
• Stable: Basic articles, general industry content, historical announcements. Update monthly or upon manual change.

Technically, a clean change signal helps. Google Search Central recommends absolute URLs in XML sitemaps and explains that <lastmod> can be used if the value consistently and verifiably reflects the last significant change. Importantly: <lastmod> is not a decorative field. A changed copyright year is no reason to present a page as professionally new. For the chatbot crawler, the logic should be similarly strict: only relevant content changes should trigger reindexing.

RAG QA: Which answers should be checked regularly

After the crawl, the actual quality work begins. Microsoft's RAG evaluators separate, among other things, retrieval quality, groundedness, relevance, and response completeness. Translated into website daily business, this means: Does the chatbot find the right sources? Does the answer stick to these sources? Does it answer the question completely? And does it avoid omitting important restrictions?

A small QA set is sufficient for the start. Collect 30 to 50 typical questions from support, sales, and website search. Each question is assigned an expected source and an acceptable answer outline. After major content changes or releases, let the chatbot answer these questions again. Check not only grammar, but above all:

• Is the correct source used, or a similar but wrong page?
• Are restrictions, deadlines, prices, or exclusions correctly adopted?
• Does the answer invent details that appear in no source?
• Does the answer link to the appropriate page instead of a general home page?
• Is it clear when a human should take over?

The last point connects knowledge base QA with support design. If a question cannot be answered with certainty, the chatbot should not continue talking confidently. A clean Human Handoff protects users and the support team better than a speculative answer.

Risks: Prompt Injection, Data Quality, and Overreliance

A website knowledge base is also a security surface. OWASP lists Prompt Injection, Training Data Poisoning, Sensitive Information Disclosure, and Overreliance as risks for LLM applications. For a website chatbot, this does not mean every FAQ is dangerous. It means that untrusted content, foreign HTML fragments, old customer data, and overly broad access should not blindly belong in the retrieval corpus.

Practical protective measures are straightforward: crawl only approved domains, clean HTML, ignore hidden instructions in sources, separate internal documents by permissions, remove sensitive data before indexing, and do not formulate answers as legal or medical advice unless explicitly verified. NIST's AI Risk Management Framework is voluntary but emphasizes the integration of trustworthiness aspects into the design, development, use, and evaluation of AI systems. This exact approach is also sensible for small website chatbots: risks belong in the operational process, not in a later damage analysis.

Practical checklist for website teams

The following checklist can be started without extensive tooling and automated later:

1. Create a source register: Record URL, type, responsible person, criticality, last professional review, and desired crawl cadence.
2. Maintain approval status: Only include sources with the status "approved" in the chatbot corpus.
3. Prioritize changes: Crawl critical pages immediately or daily; update stable content in batches.
4. Create a QA question set: Document typical support, sales, and product questions with expected sources.
5. Measure answers: Regularly check groundedness, completeness, link quality, and handoff cases.
6. Feed back errors: Do not just fix wrong answers in the prompt, but correct the underlying source, structure, or retrieval rule.
7. Control multilingualism: If the website has multiple languages, translated pages must not lag behind the original source.

Anyone who has already trained a chatbot with FAQs, documents, and website content should view this process as the next stage. The basic article on training with FAQs, documents, and website content explains the setup. This article complements the ongoing operation: currency, QA, and responsibility.

Which metrics show if the knowledge base is working?

For management, technical index sizes alone do not count. Metrics showing user impact are more relevant: share of correctly grounded answers, share of answers with a matching source link, repeat questions after a chatbot answer, handoff rate for uncertain questions, correction time after a content change, and the share of unverified sources in the corpus. These values fit well with existing AI chatbot KPIs, because they explain why solution rates or lead quality rise or fall.

It is important not to pretend to have false precision. A score can support an editorial team, but it does not replace a professional sample. Especially for prices, compliance, support promises, or technical limits, a human should regularly compare the sources and the answers generated from them.

Conclusion: The knowledge base is a product, not an appendix

A website chatbot remains useful only if its knowledge base is operated like a small product: with ownership, change logic, QA questions, source links, and clear boundaries. Those who only import content get a short-term demo. Those who maintain currency and answer quality get a support and sales channel that users are more likely to trust.

Start pragmatically: Choose the ten most important website sources, define a crawl cadence, test 30 real user questions, and correct the cause of every error. This way, you avoid many of the common AI chatbot mistakes on corporate websites, without burdening your team with unnecessary complexity.

Sources

• Google Cloud: RAG Engine overview
• Microsoft Learn: Retrieval-augmented generation in Azure AI Search
• Microsoft Learn: RAG evaluators
• Google Search Central: Build and submit a sitemap
• OWASP: Top 10 for Large Language Model Applications
• NIST: AI Risk Management Framework