I often see advice offered about the ways to enhance intranet search which ignore the fact that the routes to enhancement, or replacement, are diverse. ‘Intranet Search’ is not a generic module. There are many options but there are also two constraints. The first is that no one defined exactly what they wanted from the search application. The second is that there may not have been a choice on offer – IT took the decision without a full understanding of the requirements and implications. All too frequently the intranet manager ends up trying to work with a search application that almost certainly is an order of magnitude more complex that the comparatively simple database on which the CMS is based.

Ten of the options include

• Use the search application that comes with the CMS/intranet product (Sitecore, Interact etc.) which usually cannot search anything other application
• Use a search appliance (Mindbreeze, Intrafind, Search Blox)
• Use a commercial search application (dTSearch would be one option)
• Use a cloud application (Amazon AWS, Swiftype)
• Build your own search application for your CMS in Lucene/Solr, which could support the option of searching other repositories
• Use the native search in SP2013/O365 if you are using SharePoint/O365 or an intranet product based on Microsoft technology
• Use the search application developed by the SharePoint/O365 product
• Use a search appliance on top of SP2013
• Use BAInsight on top of SP2013
• Use the enterprise search application to provide a customized search for the intranet

There are links to most of these third-party applications in Search Insights 2018. In the case of the first option the search application may well be based on the open source Apache Lucene/Solr stack. Although Lucene and Solr are open source that does not mean you are going to be able to modify the code, as the vendor will probably have added some proprietary code to support modules included as part of the product offering. Another problem is poor search analytics, especially when you need to integrate search logs and page click logs to understand why users are browsing when they should be searching, and vice versa. Life also gets interesting with SharePoint and O365 search, both of which have considerable functional power but which require substantial experience to optimise. Follow Agnes Molnar for the inside story.

Taking advantage of a corporate enterprise search application might seem like a good idea. The problem here is that intranets have a much higher percentage of HTML files than other file formats, and many of these HTML files will be perhaps only a page or so long. So an enterprise application optimised for document search may not surface intranet HTML files as being highly relevant. To end this litany of challenges there are the complications of searching the messages within enterprise social networks.

No matter what search application you are using, starting the process of enhancement requires gaining a clear understanding of what the cause is of poor search performance. It could be the technology, the content, the relevance tuning settings, incorrect installation or a lack of awareness of users about how to get the best out of the technology. Do not even consider changing the technology until you have total proof that the poor performance is a technology issue.

Martin White