When the AI assistant on your website tells a customer your delivery fee or cancellation terms, it isn’t remembering them. In a well-built set-up, it looked them up in your content a moment earlier and summarised what it found. That content is its AI knowledge base, and it decides whether the answer is right far more than the choice of model does.
In many businesses, that knowledge is spread across service pages written years apart, PDFs, saved replies and a few colleagues’ memories. An assistant reading that mix repeats the contradictions confidently.
New to agents? Start with what AI agents are and where to start.
The short answer
An AI knowledge base is the approved content an assistant searches before it answers, so its replies are grounded in your information rather than the model’s general knowledge. To prepare one:
- List what customers ask and check every answer is written down.
- Make the website the single source of truth, one current version of each fact.
- Write for retrieval: one topic per section, headings that name the subject, explicit facts and dates, nothing held only in PDFs.
- Keep every language in step, and keep confidential data out.
- Test with real customer questions before launch and after every change.
How retrieval-augmented generation works
Retrieval-augmented generation (RAG), a term introduced in a 2020 research paper from Facebook AI Research, is the usual way to make a language model answer from your content: the agent looks things up before it speaks.
RAG explained: index, retrieve, answer
- Index. The tool splits your pages and documents into short passages (chunks) and stores them in a search index, usually with an embedding for each: a numerical fingerprint of meaning, so “fees” can match “prices”.
- Retrieve. When a customer asks something, the tool pulls out the handful of passages that look most relevant.
- Answer. The model receives the question, those passages and its instructions (typically: answer only from these sources, cite them, say when they don’t cover it), then writes the reply.
In a typical set-up, the model doesn’t see your whole website, only a few fragments, often without the page around them.
Why the content matters more than the model
A stronger model writes more fluently from the same passages, but it can’t make a wrong passage right or find one that isn’t there. Many wrong answers trace back to one of four content problems:
| What went wrong | What the customer sees | The content fix |
|---|---|---|
| The answer isn’t written down | A guess, or a vague non-answer | Publish it |
| It exists but wasn’t retrieved | “I don’t have that information” | Give it its own headed section, in text |
| An outdated passage was retrieved | Last year’s price, stated confidently | Retire or correct the old version |
| The passage lost its context | The right number, wrong service | Name the subject in every section |
Grounding AI answers in your content reduces invented answers; fixing bad sources is content work, not AI work.
Audit what your AI knowledge base needs to cover
Start from the questions, not the pages: pull a few months of enquiries from your inbox, forms and chat, and group them by topic. AI customer service agents shows how to decide which ones an agent should answer at all.
Map every question to a written answer
For each common question, note where the answer lives, whether it’s current and who owns it. Gaps tend to cluster here:
| Topic | What customers ask | Where the answer often hides |
|---|---|---|
| Services | What’s included, who it’s for | A sales deck or a salesperson’s head |
| Prices | From-prices, what changes them, deposits | Old quotes, ended campaign pages, PDFs |
| Policies | Cancellations, refunds, warranties, payment terms | Terms nobody has reread |
| Logistics | Hours, service areas, lead times, holiday closures | Social posts, the phone greeting |
| Process | What happens after an enquiry | Saved email replies |
Publish every missing answer before any assistant goes live. The keep, rewrite, merge or cut inventory in preparing content for a new website works well here.
Write down what you don’t do
Customers often ask “Do you…?”, and if your content never says no, the model may infer yes from a nearby page. State the services you don’t offer and the areas you don’t cover. One sentence such as “We don’t install outside the areas listed above” prevents a whole class of wrong answers.
Make your website the single source of truth
Every fact should live in one place that everything else, the agent included, reads from. The website is the natural home, because customers, staff and search engines all see it.
Keep facts in content and rules in instructions
Every agent has instructions covering its role, tone and limits. It’s tempting to paste this season’s prices in too. Don’t: once someone updates the website but not the instructions, the agent quotes whichever it happens to read.
- Instructions hold rules: answer only from the sources, avoid certain topics, hand over in named situations.
- The knowledge base holds facts: services, prices, policies, hours.
- Live data comes from your systems. Stock, availability and order status belong behind a tool, not on a page; connecting an agent to your website, CRM and booking system covers that side.
Decide what’s in and what’s out
At the time of writing (July 2026), many agent platforms can crawl a website or take uploaded files as knowledge sources. Don’t hand over everything:
- In: current service, pricing, policy, FAQ, contact and location pages with an owner.
- Out: ended campaigns, closed job adverts, drafts, test pages and old news that mentions prices or policies.
Old news is the classic trap: a two-year-old post announcing a price rise reads like a price list. Leave the archive out or label dated posts as historical.
Remove the contradictions
Search the site for every place a key fact appears: each price, the refund period, the phone number. Where pages disagree, correct them; where two cover the same topic, merge them and redirect the old address. Check saved replies and brochures too, because staff keep sending them. Facts stay consistent only when every page has an owner and a review date, which website governance covers.
Write knowledge base content for retrieval
Content that retrieves well is content a hurried person can scan, so this work also helps visitors, and helps with getting cited by AI search.
One topic per page, one question per section
A “Useful information” page mixing delivery, returns and payment produces muddled passages. Give each policy its own page and each question its own section, under a heading that says what it answers.
Name the subject every time
A retrieved passage often arrives without its page title or the paragraph above. Under “Pricing” on a kitchen installation page, “It starts from [price] and includes two site visits” could describe any service. “Kitchen installation starts from [price], including two site visits” can’t be misread. Head it “Kitchen installation pricing”, and don’t open sections with “it”, “this package” or “as above”.
Make facts explicit, with dates and conditions
Vague brochure copy becomes a liability. Some rewrites for a fictional business:
| Vague | Explicit |
|---|---|
| “Prices went up this year.” | “From 1 March 2026, a site survey costs [price].” |
| “It usually takes a couple of weeks.” | “Made-to-order units ship 10 to 15 working days after you approve the drawings.” |
| “See our terms for details.” | “You can cancel free of charge up to 48 hours before your appointment. After that, the deposit isn’t refunded.” |
Avoid “currently”, “new” and “coming soon”: the agent can’t tell when the sentence was written. Show a “last reviewed” date on pricing and policy pages, and put exceptions next to the fact they qualify.
Use structured content types, not one-off pages
When every service page is laid out by hand, the price can end up somewhere different on each, and one quietly leaves it out. Structured content types give every page of a kind the same fields. In WordPress, that usually means a custom post type with custom fields.
| Content type | Fields worth making explicit |
|---|---|
| Service | Summary, who it’s for, what’s included and what isn’t, from-price, lead time, owner, last reviewed |
| Policy | Effective date, the rule, exceptions, how to request it |
A field entered once can feed the service page, the pricing table, the assistant and your schema markup, and an empty field is easy to spot.
Nothing held only in PDFs or images
Text extraction from PDFs can scramble columns and tables, a scanned file may hold only a picture of the text, and old versions linger at old addresses. Price lists saved as images fare worse. If customers need it, put it on a web page as text, with the PDF as an optional download made from the same content.
Keep every language version in step
If your customers use more than one language, every version is part of the knowledge base. Multilingual search can match a question in one language to a passage in another, so a stale price left in one version can reach customers asking in any language.
- Enter language-neutral facts once. Share prices, dates and phone numbers across language versions where your CMS allows it.
- Treat a change as unfinished until every language is updated, with an owner and a review date per version.
- Keep the structure parallel, the same pages and sections in each language, so gaps show. The multilingual SEO guide covers the search side.
- Have fluent speakers review anything contractual, rather than trusting unchecked machine translation.
What must never go into an AI knowledge base
Assume anything in the knowledge base can be quoted word for word to anyone who asks cleverly. Telling an agent to keep something confidential is a request, not a control, a point the OWASP Top 10 for LLM Applications also makes. Before launch, confirm none of these is in your sources:
A staff assistant can use internal documents, but should retrieve only what the person asking may see. AI agent risks and how to limit them covers the controls.
Test with real customer questions before launch
Use what customers actually ask, in their words, not questions the project team made up.
- Build a test set from your enquiries: common questions, awkward phrasings, every language you serve, and questions your content deliberately doesn’t answer.
- Write the expected answer and source page for each before running it.
- Score every reply: correct and cited, right but from the wrong source, incomplete, wrong, or should have handed over.
- Check what was retrieved. Many tools show which passages each answer used. A wrong answer from the right passage points to the instructions; from the wrong passage, to the content. Fix the cause, not the expected answer.
- Test the sync. Change something harmless on the site and time how long the agent takes to reflect it. If it re-reads the site weekly, a new price can be wrong for up to a week.
- Set the launch bar in advance, such as no wrong answers on prices, policies or safety, and a clean handover when the content runs out.
Re-run the set whenever the content, instructions or model changes. Every “I don’t know” in the logs is a request for content.
Get the content right, and the agent follows
For a customer-facing assistant, the AI knowledge base isn’t a separate project from your website. It is your website, read by software that takes every sentence literally, and the work that makes an agent accurate makes the site clearer for everyone.
If your key facts are scattered across ageing pages, PDFs and one-off layouts, a website redesign can rebuild the site around structured content types, so each fact has one home that customers, search engines and assistants all read. For an outside view first, a free website audit looks at how your key pages perform on phones and in Google. Or talk to us about what your website needs.