Don't Bolt RAG Onto Your CMS: Build It In

by Josh Oransky

Every vendor is now selling a chatbot you can drop onto your existing site. Most of them are a small JavaScript snippet that opens an iframe and runs a retrieval pass against an index they built from your sitemap. They work, and they feel bolted on, because they have no model of how your content is organised.

The CMS already holds what a retrieval layer needs.

Why bolt-on RAG feels off

Bolt-on retrieval has three structural problems. First, the index is built from rendered HTML rather than from the content model, so block boundaries, fragment includes, and structured metadata all get flattened to text. Second, the bot doesn't know which content is authoritative versus draft versus deprecated, because the sitemap doesn't carry that signal. Third, when authors edit, the index is stale until the next crawl, which is usually overnight.

Authors notice. They write a new page, ask the bot about it five minutes later, and get an answer from the page they wrote in 2022. That's the moment they stop trusting the AI.

What "built in" actually means

If RAG is part of the CMS, the index is built from the same source-of-truth content the page is. The chunks are sections and blocks, not arbitrary text slices. Authors can mark content as authoritative, draft, or archival, and the index respects those signals because they're authored, not inferred. When a page is published or unpublished, the index updates at publish time, not on a nightly crawl.

For Edge Delivery specifically, the pattern looks like this:

• Index at publish. The publish webhook fires an embedding job for the changed page. Authoring loop closes in seconds.
• Chunk by block. A block is a semantically meaningful unit. Use it as the chunk boundary instead of a fixed token count.
• Carry the metadata. Title, section path, category, and last-modified all ride with the embedding. Filters at retrieval time get sharper.
• Serve from edge inference. Embedding queries and re-ranking can live on Cloudflare Workers or a self-hosted endpoint inside your perimeter. Don't round-trip user queries to a third-party retriever.

The author-experience win

Authors are the primary beneficiary of well-built RAG. A reporter writing the next piece in a series uses on-page assistive search to find what the team already covered. A support writer building a new article gets a summary of what's already in the help centre. A campaign editor asks "what's our position on X" and gets the actual brand-approved answer, not the marketing team's best guess.

The customer-facing chatbot is the visible deliverable, and the internal assistant is the one that changes how the team works. Build retrieval into the CMS and you get both.