What Is an OpenSearch CMS? Search as a First-Class Content Capability

Ask a platform team how search works in their CMS and you'll often get a familiar answer. The CMS manages the content. Something else handles search. A connector, a nightly job, or a webhook moves content from one to the other, and most of the time it works.

That pattern made sense when search meant a box in the site header. It doesn't hold up anymore. Search now powers faceted product catalogs, documentation portals, related-content components, and personalized listings. It also powers the retrieval step behind AI assistants and agents. When search is that important to the experience, putting it outside the content architecture stops being a tidy integration. It becomes a structural weakness.

This post answers a simple question: what is an OpenSearch CMS? It defines the category so enterprise buyers can evaluate it on its own terms. If you're looking for implementation patterns for search and AI experiences, our earlier post, OpenSearch and CMS: Building Modern Content Search and AI Experiences, goes deeper on that. Here we'll explain what an OpenSearch CMS is, how lexical, semantic, and hybrid retrieval fit together, why authoring search and delivery search are different problems, how OpenSearch supports retrieval-augmented generation (RAG) without a separate vector database, and what to ask vendors when you evaluate a search-native platform.

We build CrafterCMS, which runs OpenSearch natively across authoring and delivery, so we have a point of view. The architectural criteria below apply whichever platform you choose.

1. What Is an OpenSearch CMS, and Why Isn't Bolted-On Search Enough?

A working definition

An OpenSearch CMS is a content management system in which OpenSearch is a native part of the platform architecture, not an external service you add later. In practice, that means:

• Indexing is part of the content lifecycle. When content is created, edited, approved, or published, the platform updates the right index as part of the same workflow. There's no separate sync pipeline to build and run.
• Search serves both sides of the platform. Authors and editors use it to find, reuse, and govern content in the authoring tool. Delivery applications use it to query, filter, rank, and aggregate published content for sites, apps, portals, and AI.
• The content model shapes the index. Content types, fields, taxonomies, locales, and metadata become searchable, filterable attributes without hand-built mapping code.
• One retrieval engine handles keywords, vectors, and hybrid queries. The same OpenSearch infrastructure supports full-text search, faceting, vector similarity, and hybrid ranking, so AI retrieval runs on the same foundation as site search.

Put simply: the CMS stays the authoritative system for creating, structuring, governing, and publishing content. OpenSearch becomes the retrieval layer, optimized for finding that content quickly and in context. In an OpenSearch CMS, those two layers are designed together.

Why OpenSearch specifically?

OpenSearch is an open source, distributed search and analytics engine. It began as a fork of Elasticsearch and is now developed under the Linux Foundation. For content platforms, a few of its properties stand out:

• Mature lexical relevance. BM25 full-text scoring, analyzers, synonyms, boosting, and relevance tuning.
• Aggregations. Grouping and counting across fields and ranges, which is the basis of faceted navigation.
• Vector search. k-nearest-neighbor (k-NN) indexes for embedding-based semantic retrieval.
• Hybrid search. Combining lexical and vector scores in a single query pipeline.
• An open license and a broad community. It can run self-managed, in your cloud, or as a managed service, with no single vendor controlling access to your retrieval layer. That openness is one reason it pairs well with an open source stack; see our guide to the best open source headless CMS for the enterprise.

Together, those capabilities cover most of what an enterprise needs from content search today, including AI retrieval.

The problem with bolted-on search

Most CMS platforms in use today were not designed this way. Search was added afterward, in one of three common ways:

1. Database queries. The CMS answers search requests with SQL LIKE clauses or limited full-text features of its relational store. That's fine for a small site. It breaks down at scale, and it can't do relevance ranking, facets, or semantic retrieval well.
2. A third-party SaaS search service. Content is pushed to an external index through a connector or webhook. Relevance can be excellent, but you now own a sync pipeline, a second vendor contract, a second security review, and a second place where content can drift out of date.
3. A self-managed search cluster beside the CMS. You run Elasticsearch or OpenSearch yourself and write the indexing code. You get control, and you also take on all the integration work: mappings, reindexing, deletes, preview vs. live, permissions, and multi-site separation.

Each approach treats search as something that happens to content after the CMS has finished with it. That creates predictable failure modes:

• Index drift. Content is published but not indexed, or unpublished but still searchable. Deleted pages keep appearing in results.
• Lost structure. Connectors often flatten rich content models into a title and a blob of text. That throws away the fields that make filtering and faceting useful.
• Governance gaps. Workflow, approval, and permissions live in the CMS, and the search index knows nothing about them. Draft content can leak into results, or approved content can stay invisible.
• Duplicate cost. You pay for the CMS, the search service, and often a vector database for AI as well, with integration work between each one.

We made the strategic case for treating search as a core platform responsibility in Why Search Is a First-Class CMS Capability. The architectural point here is simpler: if retrieval decides what your users and your AI systems see, retrieval belongs inside the content architecture, governed by the same lifecycle as the content.

2. Lexical, Semantic, and Hybrid Retrieval for Sites, Portals, and AI

An OpenSearch CMS isn't defined by one search technique. It's defined by being able to use the right technique for each job on the same governed content. It helps to separate three retrieval modes.

Lexical search: precision when the words matter

Lexical (keyword) search matches the terms in a query against the terms in indexed content, usually ranked with BM25. It's fast, explainable, and very precise when the user knows the exact vocabulary.

Lexical search is still the right tool for:

• Product numbers, SKUs, and part codes
• Error codes and version strings
• Regulatory citations and policy identifiers
• Proper names, brands, and exact phrases
• Faceted filtering on structured fields such as region, product family, language, or date

Structured content makes lexical search much stronger. When the content model separates operatingTemperature, certification, and productFamily into typed fields, the index can filter and facet on them directly. A visitor searching "pressure sensor" can narrow by certification and temperature range in milliseconds. You can't build that from a page title and a body blob.

Semantic search: retrieval by meaning

People don't always use the same words authors do. A documentation article titled "Configuring Single Sign-On with SAML" may never contain the phrase "connect our corporate login," yet that's what a user types.

Semantic search addresses this gap with vector embeddings. An embedding model converts content and queries into numerical vectors that capture meaning, so items with similar meaning sit close together in vector space. OpenSearch stores these vectors in k-NN indexes and finds the nearest neighbors to a query vector, which returns content that is conceptually relevant even when the wording is different.

Semantic retrieval is especially useful for:

• Natural-language questions on support and documentation portals
• "More like this" and related-content components
• Discovery across large editorial archives
• Grounding AI answers in the most relevant passages (more on this below)

Hybrid search: keywords and meaning together

Neither mode is enough alone. Pure vector search can miss exact identifiers. Ask it for error code E-4012 and it may return conceptually similar errors instead of the exact match. Pure lexical search misses intent when the vocabulary doesn't overlap.

Hybrid search combines both. OpenSearch can run a lexical query and a vector query together, normalize their scores, and merge them into one ranked list. The result reflects both what the user typed and what the user appears to mean. For most enterprise content experiences, hybrid search should be the default rather than an advanced option.

One retrieval layer, many consumers

The value of an OpenSearch CMS is that these modes run against the same index, built from the same structured, published content. The same retrieval layer can serve:

| Consumer | Typical retrieval pattern | |---|---| | Marketing site search | Hybrid ranking with boosted fields and synonyms | | Product catalog / commerce | Lexical + filtering + aggregations (facets) | | Customer or partner portal | Hybrid search with per-user permission filters | | Documentation / knowledge base | Semantic + lexical for exact codes and versions | | Related content and recommendations | Vector similarity on embeddings | | AI assistants and agents | Hybrid retrieval of passages as grounding context |

When each consumer has its own search stack, relevance tuning, synonyms, and governance get duplicated and gradually drift apart. When they share one OpenSearch layer that is native to the CMS, improvements in content structure and relevance carry over to every channel.

3. Authoring Search vs. Delivery Search in a Decoupled Architecture

"CMS search" usually means two different problems, and confusing them leads to bad architecture decisions. We covered this distinction in Search Functionality For Your Headless CMS. Here's how it plays out in an OpenSearch CMS.

Authoring search: finding and governing content

Authoring search serves content authors, editors, and developers inside the authoring environment. Its job is operational:

• Find an existing article, component, or asset before creating a duplicate
• Filter by content type, a specific field value, workflow state, author, or last-modified date
• Locate every item that references a deprecated product name or outdated legal disclaimer
• Search across work in progress, including drafts and unpublished changes, not only live content

That last point is the key difference. Authoring search has to index content as it is being worked on. It must respect authoring permissions, and it must reflect edits almost immediately. A database-backed CMS often struggles here, because complex, field-level queries across large repositories are exactly what relational stores are worst at.

Authoring search is also becoming important for AI. When an agent is asked to "update every product page that mentions the old warranty terms," its first step is a search across the authoring repository. If that search is slow, incomplete, or ignores structure, the agent's work will be too.

Delivery search: serving experiences at scale

Delivery search serves site visitors, application users, and AI systems at runtime. Its requirements are different:

• Index only approved, published content
• Sustain high query volume with low latency
• Support facets, aggregations, geo and date filters, and relevance tuning
• Scale horizontally with traffic, often across regions
• Isolate sites or tenants from each other

Why decoupling matters

In a decoupled architecture, authoring and delivery are separate tiers with separate jobs. The authoring tier is where content is created, reviewed, and approved. The delivery tier is where published content is served. Search needs to follow that same split:

• Authoring indexes reflect work in progress and stay behind the authoring firewall.
• Delivery indexes reflect only what has been published to that environment, and they scale with the delivery tier.

When a platform uses a single shared index, or makes delivery nodes query a central authoring database, the boundaries blur. Draft content risks exposure, delivery performance depends on authoring load, and scaling one tier means scaling both.

How CrafterCMS implements this

CrafterCMS is built on this decoupled model, with OpenSearch native to both tiers:

• Crafter Studio, the authoring environment, uses OpenSearch to power authoring search, so authors and developers can query the Git-based content repository by type, field, path, and metadata.
• Crafter Deployer watches publishing activity and indexes published content into OpenSearch for each target environment. It keeps the index synchronized as items are added, updated, and deleted.
• Crafter Engine, the delivery runtime, executes search queries against OpenSearch and exposes them through APIs and templates for sites, headless applications, and AI services.

Because content is stored as structured files in Git and published to independent, shared-nothing delivery nodes, each delivery environment can be indexed and scaled on its own. Search is built into the publishing pipeline that moves content from Studio to Engine, so no separate sync service is needed. And because OpenSearch is bundled, teams don't need to procure and integrate a separate search vendor to get started. CrafterCMS remains API-first, so teams that need a different search tool for a specific use case can still integrate one.

4. How OpenSearch Enables RAG Without a Separate Vector-DB Tax

This is where an OpenSearch CMS turns into an AI CMS foundation rather than only a better site search.

The retrieval step decides AI quality

Retrieval-augmented generation (RAG) is the standard pattern for grounding large language models in current, authoritative enterprise content:

1. A user (or an agent) asks a question.
2. The system retrieves the most relevant content.
3. That content is passed to the LLM as context.
4. The LLM generates an answer grounded in that context.

The model provides language ability. Accuracy, freshness, and governance depend almost entirely on step 2. If retrieval returns stale, unapproved, or irrelevant content, the generated answer will be fluent and wrong.

The vector-database tax

Many AI architectures handle retrieval by adding a dedicated vector database next to the CMS and the existing search engine. On a whiteboard that looks harmless. In production it adds:

• Another system to run. Another cluster, backup strategy, security review, and on-call rotation.
• Another sync pipeline. Content has to be chunked, embedded, and pushed into the vector store, then updated and deleted in step with the CMS.
• Split retrieval. Keyword search runs in one engine and vector search in another, so hybrid ranking means merging results across systems in application code.
• Governance drift. The vector store has no native knowledge of workflow, publishing state, or permissions. Drafts and retired content can end up in AI answers.
• Duplicate spend. Licensing, hosting, and engineering time for a capability your search engine may already provide.

That's the vector-DB tax: the cost of putting AI retrieval in a separate system from your governed content.

OpenSearch as the vector store

OpenSearch supports vector fields and k-NN search alongside traditional inverted indexes. That means the same engine that powers site search can store content embeddings and serve semantic and hybrid retrieval for RAG. We go deeper into these capabilities in Leveraging OpenSearch for AI-Powered Content Management.

In an OpenSearch CMS, the RAG pipeline follows the content lifecycle:

1. Authors create and approve content in the CMS, with the usual workflow and review.
2. On publish, a deployment processor identifies what changed, prepares the content as documents suitable for embedding, generates embeddings through the configured model, and updates the vector index. It adds new vectors, updates changed ones, and removes vectors for deleted content.
3. At runtime, the orchestration layer embeds the user's query, runs semantic or hybrid retrieval against OpenSearch, and passes the retrieved context to the LLM.

The important detail is in step 2. Vectors are updated only when content is approved and published. Embedding generation happens out of band from delivery traffic, so AI retrieval sees the same governed, live content that the website does, and nothing else. The same publishing event updates both the lexical index and the vector index, which keeps them aligned.

We describe this architecture, including the orchestration layer and the deployer's role in RAG, in Technical Details of an AI CMS. In CrafterCMS, OpenSearch serves as both the search index and the vector store, and AI orchestration frameworks such as Spring AI coordinate retrieval, prompt augmentation, and model calls.

Beyond chatbots: retrieval for agents

RAG is often discussed in terms of chat interfaces, but the bigger change is agentic. AI agents need to find before they can reason or act. A delivery-side agent helping a visitor choose a product has to search specifications, filter by structured attributes, and retrieve supporting documentation before it responds. An authoring-side agent asked to refresh outdated content has to locate every affected item first.

In both cases, the agent depends on retrieval: lexical precision for identifiers, semantic recall for intent, and structured filters from the content model. An OpenSearch CMS gives agents that capability through the same governed index that serves people, and that's a big part of what makes an agentic CMS trustworthy.

5. Buyer Checklist: Evaluating Search-Native CMS Platforms

Search is now part of how content is delivered, not an add-on. That means it belongs in your CMS evaluation, not in a separate procurement handled later. If you're also comparing external search options, Choosing a Search Engine For Your CMS lays out the trade-offs between SaaS services like Algolia and Elasticsearch-class engines. Use the checklist below to test whether a CMS is actually search-native.

Architecture

• Is a search engine bundled and supported as part of the platform? Or do you have to procure, host, and integrate one yourself?
• Is it OpenSearch or another open engine? What happens to your indexes and queries if your vendor relationship changes?
• Is indexing driven by the publishing lifecycle? Or by a separate connector, webhook, or scheduled job you have to maintain?
• Are authoring and delivery indexes separate? Can draft content ever appear in delivery results?
• Does delivery search scale with the delivery tier, independently of authoring load?

Content model and relevance

• Do content types and fields map to the index automatically, including taxonomies, locales, and custom metadata?
• Can developers customize mappings, analyzers, and boosting when the defaults aren't enough?
• Are facets and aggregations available through delivery APIs, or only through the raw search engine?
• How are multi-site and multi-tenant indexes isolated?

Retrieval modes

• Is full-text (BM25) search supported with synonyms, stemming, and language analyzers?
• Can the same platform run vector (k-NN) search without adding a separate vector database?
• Is hybrid search supported, and can you tune how lexical and semantic scores are combined?

AI readiness

• Are embeddings generated as part of publishing, and are vectors updated or removed when content changes or is deleted?
• Does the vector index contain only approved, published content?
• Can you choose your embedding model and LLM, or are you locked into one provider?
• Is there an orchestration layer (for example, Spring AI-based) with RAG templates and tool or function calling?
• Can AI agents use the same search APIs for authoring tasks and delivery experiences?

Governance and operations

• Do search results respect permissions for authors, portal users, and AI consumers?
• Can you rebuild an index from the source of truth? In a Git-based CMS, the repository holds the full, versioned content history, so reindexing is a repeatable operation. (We compare repository architectures in Git-Based CMS vs Database CMS.)
• What does the vendor support and monitor? Is search covered by the same SLA as the CMS?
• What's the total cost? Count the CMS, the search service, any vector database, and the integration engineering between them.

Red flags

• "Search" means a database query with a text filter.
• The vendor's answer to semantic search or RAG is "integrate a third-party vector database."
• Draft and live content share an index, with filtering handled in application code.
• Reindexing depends on a manual export or a vendor support ticket.
• Search relevance is a black box that your team can't inspect or tune.

Putting It Together: CrafterCMS as an OpenSearch CMS

CrafterCMS was built on the principle that architecture matters more than bolt-ons, and search shows why. In CrafterCMS:

• OpenSearch is built in to both the authoring and delivery tiers. There's no separate search vendor to procure to get started.
• Crafter Studio uses OpenSearch for fast, structured authoring search across the Git-based content repository, including in-progress work.
• Crafter Deployer indexes content on publish and keeps each environment's index synchronized with additions, updates, and deletions. It can also generate embeddings so vector retrieval stays aligned with approved, published content.
• Crafter Engine runs lexical, faceted, semantic, and hybrid queries against OpenSearch on independent, shared-nothing delivery nodes that scale with traffic.
• OpenSearch doubles as the vector store for RAG and agent retrieval, which removes the need for a separate vector database and its extra cost.
• The platform stays open and composable. Search APIs can be decoupled from the backend search service, so teams can bring in other tools when a use case calls for it.

The result is a single, governed retrieval layer for every consumer of your content: authors, site visitors, applications, AI assistants, and AI agents.

Conclusion: Search Belongs in the Content Architecture

For years, search was treated as a feature to add after launch. That made sense when search was a box in the header and the only user was a person typing keywords.

Today, retrieval determines what customers find, what portals return, and what AI systems say on your behalf. Lexical precision, semantic understanding, and hybrid ranking all depend on structured content and governed publishing. RAG and agentic workflows depend on retrieval that only sees approved content. Those requirements point to the same conclusion: search belongs inside the CMS architecture, not beside it.

That's what an OpenSearch CMS is. The CMS manages, structures, and governs content, and OpenSearch makes that content retrievable for people, applications, and AI, with both layers working from the same lifecycle.

Next Steps

If you're evaluating platforms for your next content architecture, start with the checklist above. To see how this works in practice, the CrafterCMS technical documentation covers how Crafter Studio, Deployer, and Engine use OpenSearch for authoring search, delivery search, and AI retrieval. You can also start a CrafterCMS trial and see built-in OpenSearch running against your own content model.