Two copies of the truth is one too many
Most on-site AI assistants are built on a separate knowledge base: someone exports the product docs, uploads them to a vector store, and wires a chat widget to it. It works on launch day. Six months later the site has changed, the export hasn’t, and the assistant is now confidently answering from stale data — worse than no assistant at all.
If a fact is worth the assistant knowing, it's worth publishing. If it's published, the assistant should read it from there — not from a copy.
Publish once, answer everywhere
Our approach on every AI-enablement project: the website’s own content is the knowledge base.
- One source — product specs, FAQs and guides live as structured content on the site; the RAG index is rebuilt from those pages on every deploy.
- No drift — an edit to a published page updates the assistant in the same release. There is no second pipeline to forget.
- Compounding returns — the same structure that makes pages quotable for AI search (see our GEO checklist) is what retrieval works best on: answer-first intros, real tables, consistent terminology.
What this looks like in production
On Sineng.wiki, the AI Q&A widget retrieves from an index generated at build time from the site’s 13 content sections. When the client updates a grid-code guide, the next deploy re-embeds it — the assistant and the page can’t disagree.
The architecture is deliberately boring: static site, build-step embedding, a small serverless endpoint for retrieval and generation. Boring is what keeps answers current.
Want this run on your site? A GEO audit is part of every probe report — structure, schema and citability, scored.