Knowledge base chatbot: how it works, tools compared, and how to prepare your docs

What a knowledge base chatbot is, and is not

It is a chat widget on your site connected to a set of pages you choose. A visitor asks in their own words; the bot finds the relevant passages and writes an answer from them. Good ones show which pages they used.

It is not a replacement for your support team, and it knows nothing that is not in your pages. If your docs are silent or out of date, the bot will be too, or it may guess. Treat it as a faster way to reach your documentation, not as a new source of truth.

How retrieval with source links works

1. Import. The tool fetches your pages, extracts the text and splits it into passages.
2. Index. Each passage is stored in a search index so it can be found by meaning, not only by exact keywords.
3. Retrieve. When a visitor asks a question, the tool searches the index for the passages most related to it.
4. Answer. A language model writes an answer from those passages, and the tool attaches links to the pages they came from.

An illustrative example: a visitor writes “my license key says invalid after I moved the site”. The tool may retrieve one passage from “Activating your license” and one from “Moving to a new domain”, then answer that the key must be deactivated on the old site before activating it on the new one, with links to both pages. If neither page exists, the honest answer is to contact support.

The source link is what makes an answer checkable. A visitor can open the page and follow the exact steps; you can see which page produced a wrong answer and fix that page. Without links, a wrong answer looks the same as a right one.

This also explains most bad answers: the right passage was never retrieved, because the page is missing, vague or buried inside a long page about something else, or the page itself is wrong.

Types of knowledge base chatbot tools

Most tools fall into four groups. Which one fits depends less on the AI model than on where your documentation lives and who answers when the bot cannot.

• AI agents built into a help desk. If your support already runs on a help desk platform, check whether it offers an AI agent that answers from the help center you already maintain. You keep one inbox for handoffs, but you usually need that platform for the rest of support too.
• General chatbot builders. Tools such as Chatbase, DocsBot and Chatling train a bot on many source types (websites, files, Notion and more) and embed it on any site. Flexible, usually priced by credits.
• WordPress plugins. MxChat or the BetterDocs AI Chatbot add-on read WordPress content directly. They are often cheaper up front, but you connect your own model key and pay that provider by usage.
• Narrow documentation assistants. Docapta, our product, answers only from public documentation pages you import, links the source of each answer, and sends account and billing questions to people.

Knowledge base chatbot tools compared

For installation, model costs, limits and handoff on WordPress, read our comparison of six WordPress chatbot options. If you are leaving Chatbase, see Chatbase alternatives for documentation support.

How to prepare your documentation

• One topic per page. A page called “Activating your license” is easier to retrieve than a long “Getting started” page that also covers installation, settings and billing. Split long pages where the topic changes.
• Clear, specific headings. Use the words customers use, such as “License key not accepted” rather than “Activation notes”. Headings help retrieval and the reader who follows the source link.
• Put the answer first. Start a section with the instruction, then explain. Name the exact menu path, setting and error message.
• Keep pages public and current. A tool can only import what it can reach. Docapta, for example, imports public HTTPS HTML pages only, so pages behind a login and PDF files are not read. Update or remove pages for old versions, and re-import after you change a page.
• Cover the common questions. Before launch, have pages for installation and updates, license activation and transfers, the main settings, known conflicts and troubleshooting, and how to contact support. Look at last month’s tickets: if a frequent question has no page, write that page first.
• Avoid contradictions. If two pages give different steps, for example for an old and a new version, the bot may mix them. Label the version clearly or remove the outdated page.

What to keep out of the bot

Some questions need a person, even when a bot could produce a plausible sentence:

• Account access, license transfers between sites or customers, and billing changes.
• Refunds and payment disputes.
• Bug reports that need logs or access to a site to reproduce.
• Anything involving a customer’s private data.

Configure the bot to point these to your support email or help desk, and say so in the widget. Docapta, for example, sends account, order, payment and refund questions to the support channel you configure and does not change customer accounts.

How to evaluate answers before publishing

1. Collect real questions. Gather 20 to 30 questions from your support inbox, forum or pre-sales email, in customers’ own words.
2. Include easy and hard ones. A direct installation question, one answered on a specific page, one that needs two pages, one your docs do not cover, and one account or refund question.
3. Check every answer against its source. Is the answer supported by the linked page? Are the steps complete? Is it the right version?
4. Check the unknowns. For the uncovered question, the right result is “I don’t know” with a route to support, not a confident guess.
5. Fix the documentation, not only the bot. When an answer is wrong, the fix is usually a clearer or new page. Re-import and ask the same question again.
6. Keep the list. Re-run the same questions after large documentation changes or plugin releases.

Testing usually counts toward usage. In Docapta, dashboard checks share the 500-question allowance with visitor questions.

After launch: keep the answers honest

• Read real conversations. Review a sample of visitor questions every week or two. Questions the bot could not answer are a list of pages to write.
• Watch your support inbox. If tickets about a documented topic keep arriving, the page may be hard to find, unclear, or not imported.
• Re-test after releases. When a plugin update changes a menu, setting name or requirement, update the page, re-import it and re-run your question list.
• Keep the support route visible. Visitors should always be able to reach a person without arguing with the bot.

When not to use a knowledge base chatbot

• Your documentation is thin or out of date. Fix the docs first; the bot will only repeat the gaps.
• Most questions are about accounts, billing or specific bugs. A bot cannot resolve those; a clearer contact form may help more.
• You get very few questions. If a handful arrive each week, answering them yourself may be simpler and shows you what to document.
• You need answers from private material. Some tools read internal wikis, PDFs or tickets; Docapta does not.
• You need the bot to take actions, such as issuing a license or a refund. That is a different kind of product.

Where Docapta fits

Docapta is a knowledge base chatbot for WordPress plugin teams whose documentation is published as public HTML. It imports up to 50 pages, links sources with answers and costs $39/month for 500 questions per trailing 31 days; usage stops at the limit. It does not import PDFs or private pages and has no free plan. See how it works, check pricing, or compare it with Chatbase and DocsBot. If you are choosing a tool for a WordPress docs site, read our WordPress chatbot guide.

Sources

Checked on 2026-10-18. Competitor details come from these official pages. Plans and features change; confirm on the official page before you decide.

• Chatbase pricing
• Chatbase docs: data sources
• DocsBot pricing
• DocsBot home page
• Chatling pricing
• MxChat home page
• MxChat on WordPress.org
• BetterDocs AI Chatbot
• BetterDocs docs: purchase the AI Chatbot