Understanding Site Search — Part Four: Choosing the Right Solution

We’ve talked about the what. We’ve talked about the how.

Which brings us to the real question: what do you need? What functionality is necessary, and what will be underutilized? How do you balance the cost of complex implementation with the work that might need to be done to get your content ready?

This is part one of a four-part series on understanding how to plan for site search on your website:

• Introduction: Understanding Site Search
• Part One: How Does Search Work?
• Part Two: What Content Will You Search?
• Part Three: How Will You Organize Results?
• Part Four: Choosing the Right Solution

Requirements should match strategy.

First, document your requirements. The reasoning behind those requirements is important to communicate how search will work. If you have a need for a complex standalone provider search, buy-in will require an understanding of how it will provide better access to individual providers, but also an understanding of how they will be managed by the editorial team.

This is key: a search solution is a balance of programming and editorial work. The programming — development and integration of a search engine and its algorithm — takes time and budget. Similarly, the editorial work you’ll need to do to make your content work within the new algorithm — categories, manual weighting, relationships between pages — will also take a lot of time … not just during implementation, but far beyond.

Which means you’ll need to determine whether the technical budget will be maintained by the editorial budget. It will be difficult to sell leadership on an expensive curated search solution if you don’t have the team to supply it, just as it will be difficult to sell a tool to help aggregate and track user searches if you don’t have enough content to provide usable context.

At minimum, walk through these concepts above and determine what you need and what you want. Then, with your development team or CMS partner, talk through the level of effort that will go into search integration or upgrades.

Finally, understand that you will be tweaking things. The math equation within the search engine will return results no matter what — you just want to make sure those numbers match the needs of your users and your team.

Understanding maintenance.

When we talk about editorial maintenance, we’re not exaggerating — any best bets, synonyms, or categorical weighting is going to require someone to maintain the pages themselves. While most pages will fall into a “set it and forget it” model — you assign a term or two, confirm that the content mentions relevant terms, assign categories — there are others that will shift and adjust over time.

More than the actual editorial maintenance of site content, you’ll also need to watch site content. Make sure your analytics suite is set up to measure and track internal site search. The data you’ll pull from this reporting — from common search terms to misspellings and traffic — will provide a wonderful amount of information about how people use your site search.

What’s more, internal site search identifies usability issues. If certain terms are commonly searched, it’s worth looking into the reasons for those searches. Is a page hidden somewhere deep in the site? Are we using the wrong term in our navigation? Has a page disappeared? Are there secondary terms that we should add to our synonym library?

Solr? Episerver Find? Or something else?

Finally, the big question: what search engine do we use?

Well … that depends. It depends on the CMS you’re using, or the language your site is built in, or the level of complexity you require, or whether you want an open-source or paid solution. There are so many solutions out there, we can’t possibly answer these questions for each individual reader. But what we can do is walk through the differences between what we see on most projects.

To be clear, we get this question a lot. For Blend, however, the answer is focused specifically between two solutions — Solr and Episerver Find. Here are a few of the differences:

• Default indexing — Episerver Find, by default, indexes the entire site, after which you provide it with exclusions. In other words, it will assume you want every page included, and it’s up you or your development team to tell it what to exclude. Solr, on the other hand, begins with everything excluded — you need to build the inclusion list yourself. In other words, it makes no assumptions — you have to tell it specifically what sections to include.
• Cost — Episerver Find is included with an Episerver DXP install, thus making it free for cloud-based Episerver clients. (There is a cost for Episerver Find if you are hosting your own install). Solr, on the other hand, requires some costs to spin up — it requires its own server, which costs money, and because it’s not integrated with the content management system it requires a level of integration with your solution.
• Customizability — Episerver Find is deeply integrated with an Episerver site, as it’s literally a part of the base Episerver CMS. However, because of this, it’s also a bit more locked down, and deep customization can be a bit more of a technical weight. Solr is entirely separate from the content management system and, in fact, can be run on anything. Because of this, it’s much more customizable.

All of this is to say that, as far as base functionality goes, most search engines are going to get you the basics. Enter term. Get results. Find pages. The differences are on the edges. Ask smart questions about how you will use your search, and you should be able to make a choice between those that fill the right gaps.

Making a final decision.

There are dozens of additional search engines out there, all with their own pros and cons — ultimately, it comes down to being able to compare features and costs with what you actually want to do with your search solution.

What’s important is knowing that you’re not going to get everything you want with a base-level search. But sometimes, that’s okay.

An understanding in what is most often included with a base search solution helps frame expectations around what site search can be. From here, your strategic planning can review what might be needed to make search more usable for site visitors, your development team can adjust the base layer to come more complex, and your editorial team can tweak content to fit your needs.