Picking the correct search provider for your project can be an arduous task. Episerver comes bundled with a ‘basic search’ out the box, but, depending on your requirements this can be too limiting. Episerver also has a third-party search add-on that lives in the cloud and provides a lot more power and functionality. In today’s post, I’m going to review the main search provider options that I’ve come across when architecting an Episerver project.
Which Search Provider Should I Use With Episerver?
Deciding on which search provider to use on a project, mainly depends on these criteria:
- Do you want to self-host, or, cloud host?
- Is all your search content in Epi?
- Will your site be in a load balanced environment?
- How important is searching in terms of your websites aim? If most of your website’s traffic comes from Google, will a basic search suffice?
- Do you need to index different types of content? If you sell/have products you sell to your users, will you need to index this specifically and be able to filter on specific product attributes
- Will you search combine data from multiple sources?
Based on your websites requirements will determine which provider is most appropriate to your project.
EpiServer provides a free search addon, EpiSearch that is based on the Lucene search provider. Lucene is pretty much the standard ‘basic’ search provider for the majority of the big CMS boys, Episerver, Sitecore and Umbraco all have Lucene compatible searches.
With a Lucene index, you can create and define an index via config files and then use an API to add/retrieve items from it. Lucene indexes are stored on disk (which makes load balancing a pain at times) as the indexes are stored on disk this makes it less favorable for a loud hosting approach.
- Lucene is widely used
- More customisable than some other offerings (like Google Site Search)
- Load balancing needs thinking, having separate indices on each individual node in your cluster can cause
- Can be a pain to clear out data in the index, due to file locking
- Cloud hosting need consideration, you wouldn’t have access to the index files
Find is basically an integrated Episerver search provider based on Elasticsearch. Find is cloud based so you don’t need to worry about index files living on a server, re-indexing etc.. so for load balanced environments it’s pretty good. Personally, the bits I like about Find is that faceting (which hurts my head) is done out the box and the API to use it is pretty simple., search results always seem pretty relevant and you can even add weightings to things from the admin panel. Weighted searches always seem like a biggie that’s needed on this project.
- Find manages complex things like facets out the box
- Find can search and index multiple types os content, you can throw a load of C# classes it into, let find do all the searching and ordering and then change your displays based on the object at runtime.
- Free development index available to try before you buy
- Find isn’t the cheapest of options. If the website only requires a simple content search, this cost could make it overkill
Elasticsearch is the search provider EpiFind uses under the hood, so in theory, if Find can do something you like, using Elasticsearch directly can do the same. I’ve personally never gone down this route so I’m not 100% sure technically everything you would need to do to integrate an Elasticsearch index, but other people companies have created their own bespoke Epi Elastic API’s successfully, so it is definitely possible. Getting a hosted Elastic search is cheaper than Find, but you won’t get Epi’s unified Search and also the automatic content indexing part, so you need to take the extra development costs into account.
- Uses the same underlying tech as Find but with less Episerver integration
- Will take longer to implement
- No Episerver integration admin screens
- Needs elastic search skills
- Have to pay for your own cloud services if required
Google Site Search
Google does what it does. It can index a website and can return content, you don’t have much control over results, ordering, styling. Ordering and different rendering of content are definitely requirements in the FSDs, so not sure if this rules this option out completely. I think if you want a generic search that looks similar to Googles, all you content lives on the website and you don’t care about weighting then this would be the option, not sure in this instance
- Quick to integrate
- Provides the power of Google to your site quickly
- Very rigid and can’t be customised that much
- No custom index filtering
- Can’t filter on different types of content, all or nothing approach
Although I’ve had little experience with Solr, I know a few companies use it. Solr is Sitecore’s choice for their advanced search provider and as a lot of agencies work on Episerver and Sitecore projects, companies that are experienced with Solr tend to stick with what they know. When I’m choosing the tech to use on a website, my preference is to pick technologies that are well traveled. Lucene/Google are both great options for simple searching, and Find does a great job for an advanced search. If you decided on Solr then there will definitely be less documentation and support available to you. If you decided to use Solr, you will also run into the same issue of implmenting elastic directly, you will also have to do all the custom development work yourself.
Below lists the main search providers that the majority of websites I’ve worked on in the last 10 years have used. This isn’t a definitive list and there are other alternatives available on the market which might meet your business goals so feel free to explore more. The aim of this post isn’t to provide one recommendation that will work for everyone, the aim is to try and share some of the consideration you should consider before picking an option. If you run an e-commerce site, then having a search that provides relevant results and recommendations will likely mean the company is willing to invest more in the search. If your project is a simple brochureware website, then Google or Episearch will usually suffice.