Open your analytics and look at what people type into your AEM site's search box. Not the page views: the queries. It's the only place on your site where visitors tell you, in their own words and unprompted, what they came for.

Now look at what you give them back: ten blue links, ranked by whether their words happened to appear in your authors' words. If they used a synonym, a typo, or a full sentence, they got nothing, and then they left, and no one filed a ticket about it.

That gap is the subject of the page we just published: turing.viglet.org/aem-search: AEM search, reimagined with AI, without the ceiling. This post is the longer version: not the feature list, but what actually becomes possible on an AEM site when search stops matching strings and starts understanding questions.

Once your Adobe Experience Manager content is indexed into an enterprise search engine, the obvious next step is to move beyond keyword matching. A visitor who searches "places to stay near the mountains" should find a page titled "Alpine lodges and cabins", even though none of those words match. That's semantic search, and it's powered by embeddings.

This post builds on indexing AEM into Viglet Turing ES and shows how to add vector/semantic search and RAG on top, all open source, on your own infrastructure.

"Should we use Solr or Elasticsearch?" is one of the most common engineering questions when a search project starts. It's also slightly the wrong question. Solr and Elasticsearch are search engines: they index and rank documents. What most teams actually need is an enterprise search platform: connectors, facets, multi-language, semantic search, RAG, and an admin UI on top of that engine.

That's the distinction this post draws, and where Viglet Turing ES fits, because it's not a competitor to Solr/Elasticsearch. It runs on them.

If you run a large content portal (intranet, knowledge base, support site, or a public site on Adobe AEM), you have probably evaluated Coveo and Lucidworks Fusion. Both are mature, capable enterprise search platforms. This post compares them head-to-head with the open-source option, Viglet Turing ES, so you can see where each fits.

We covered the open-source alternatives to Algolia and Coveo for AEM broadly; this one zooms into the enterprise-portal end of the market.

If you run Adobe Experience Manager and need a real search experience, with facets, autocomplete, relevance, and increasingly AI answers, you'll quickly hit the limits of out-of-the-box Oak indexing and start evaluating a dedicated search layer. The usual shortlist is Algolia, Coveo, and Lucidworks: all excellent, all SaaS, all priced per document and per query.

This post lays out the trade-offs honestly, including where the open-source option, Viglet Turing ES, fits and where it doesn't.

Adobe Experience Manager (AEM) ships with Oak/Lucene indexing that is excellent for authoring and repository operations, but it was never meant to power a public-facing search experience: faceted navigation, autocomplete, relevance tuning, multi-language sites, and increasingly, conversational (RAG) answers over your content.

Most teams reach for a SaaS layer (Algolia, Coveo, or Lucidworks) and pay per document and per query, while their content leaves their infrastructure. This guide shows the open-source alternative: indexing AEM into Viglet Turing ES, an Apache-2.0 enterprise search platform you self-host, with semantic navigation and generative AI built in.