How to Build a Knowledge Base: Articles, Search, Permissions and AI Answers

How to build a knowledge base or help centre: article structure, search that finds answers, public vs internal access, and AI answers.

Mythex Team · 2026-09-29 · 5 min read

A knowledge base is a searchable library of answers: how to do something, how to fix something, what the rule is. To build one you need articles grouped into a few clear categories, an editor your writers will actually use, search that finds the right article from the words people really type, and a decision about who can read what — the public, customers who are logged in, or staff only. An AI app builder can produce the structure, editor and search in a short session. What makes a knowledge base useful is the writing and the upkeep, so design for easy editing and for spotting out-of-date articles from day one.

Decide who it is for first

The same features serve very different sites:

Public help centre — for customers and prospects. Must be fast, indexable by search engines, and written in their words.
Customer-only docs — behind a login, for paying customers or partners.
Internal knowledge base — policies, processes, how-tos for staff. Must be private; search and freshness matter more than design.

Mixing public and internal articles in one site is where most leaks come from. If you need both, give each article a clear visibility setting, or run two separate sites.

What the app needs

Data

Table	Key fields
Articles	Title, slug, summary, body, category, tags, status (draft, published, archived), visibility, owner, last reviewed at, updated at
Categories	Name, slug, description, order, parent (optional)
Revisions	Article, body, author, saved at
Feedback	Article, helpful yes/no, comment, created at
Search log	Query, results count, clicked article, created at

Two fields do a lot of work: owner (who keeps this article accurate) and last reviewed at (when someone last confirmed it is still true). Together they let you list articles that nobody has checked in six months.

Permissions

Readers see published articles they are allowed to see. Editors create and edit articles, perhaps limited to certain categories. Admins publish, archive and manage users. For an internal knowledge base, everyone needs a login; for a public help centre, only the writers do.

Decisions and trade-offs

Editor: Markdown or rich text

Markdown is quick, portable and plays well with version history, but some writers find it off-putting. A rich-text editor with headings, lists, images, callouts and code blocks feels familiar. Whichever you choose, store content in a format you can export later.

Search

Basic database text search is enough for a few hundred articles if you search titles, summaries and bodies, and rank title matches higher. Beyond that, or if typos and synonyms matter ("invoice" vs "bill"), use proper full-text search or a hosted search service. Our guide to adding search walks through the options. Log every query that returns nothing: it is a free list of articles to write.

AI answers

An "ask a question" box that answers from your articles is now common. It works by retrieving the most relevant passages and asking a language model to answer only from them — see what RAG is. Always show the source articles, allow "I don't know", and remember that it will confidently repeat anything outdated in your articles. Build it after the articles are in good shape, not before.

Versioning and review

Keep revisions so you can see who changed what and roll back. For regulated content (HR policy, safety procedures), add an approval step before a change is published.

A first prompt that works

Build a public help centre for Parcelly, a shipping label app for small online shops. Home page with a large search box and six categories (Getting started, Printing labels, Carriers, Billing, Returns, Troubleshooting). Articles have a title, summary, body in Markdown with images and callouts, category, tags, status (draft, published, archived), owner and last-reviewed date. Article pages show a table of contents, related articles and a "Was this helpful?" yes/no with an optional comment. Search covers titles, summaries and bodies with title matches ranked first, and logs every query and whether it returned results. An editor area (login required, roles editor and admin) lists drafts, articles not reviewed in 180 days, and articles with low helpful scores, and keeps revision history. Each article has its own page title and meta description for search engines. Clean, calm, readable design. Mobile-first.

Build steps

List your first 20–30 articles from real support questions before building anything. That list shapes the categories.
Generate the site and check reading on a phone — line length, headings, images.
Editor and roles. Writers need to add and fix articles without asking a developer.
Search, then test it with the words customers actually use, including misspellings.
Feedback and search logging.
Stale-article report based on owner and last-reviewed date.
SEO basics for a public site: unique titles, descriptions, clean URLs, a sitemap. See SEO for AI-built websites.
Link it from your product and your support replies, then watch the no-results log weekly.
AI answers, once the content is solid.

Common mistakes

Organising by department instead of by what the reader is trying to do.
Long articles covering five tasks. One task per article, with a title that says what it solves.
No owner per article. Nobody updates anything, and trust drops after the first wrong answer.
Internal notes in public articles. Use separate visibility, and review before publishing.
Search that only matches titles. Readers type symptoms, not article names.
Screenshots without alt text or context. They date quickly; describe the step in words as well.

When a ready-made product is the better choice

If your team already lives in a documentation or wiki tool, an internal knowledge base there is usually the path of least resistance — our Notion vs Confluence comparison covers two common choices. If you use a helpdesk product, its built-in help centre links articles to tickets and suggests articles to customers, which is hard to reproduce. Docs-site generators are ideal for developer documentation kept alongside code.

Build your own when you need your own structure or permissions (articles per client, per location, per role), want the knowledge base inside your product rather than on a separate site, need review and approval steps a wiki doesn't enforce, or want AI answers over your content without another subscription. It pairs naturally with a custom helpdesk.

Building it with Mythex

On Mythex you describe the knowledge base in chat and it is built in a live preview; articles, revisions and feedback are stored in a Postgres database the agent adds when needed, and images go into the project's file storage. Editor logins use an auth approach you choose, since Mythex has no built-in end-user login. For AI answers, you use your own AI provider's API key stored as a project secret, and usage bills your provider account rather than Mythex credits (AI recipe). New Mythex apps default to a client-rendered React single-page app, which is weaker for search engines, so for a public help centre ask for a static-friendly or server-rendered setup such as Next.js (SEO recipe).

For a starting prompt, try the product knowledge hub or team docs app templates.

Questions

What is the difference between a knowledge base and a wiki?

A knowledge base is usually curated: a small team writes and maintains answers for a defined audience, often customers. A wiki lets everyone edit and tends to grow broader and messier. The same software can serve either; the difference is who writes and who reviews.

How should a knowledge base be organised?

By what readers are trying to do, not by your org chart. A few top-level categories, short task-focused articles with clear titles, and links between related articles work better than deep folder trees.

Can I add AI answers to a knowledge base?

Yes. The usual approach, called retrieval-augmented generation, searches your articles for relevant passages and asks a language model to answer using only those passages, with links back to the sources. It works best when the articles themselves are accurate and current.

Should a public help centre be indexed by search engines?

Usually yes. People search for how to fix a problem before they contact support, so each article should have its own page, title and description. Keep internal articles on a separate, login-protected site.