Search powered by Funnelback
At DrupalCon 2019, we heard a lot about how and why people love Drupal. There are so many good reasons - the community, the flexibility, the modules… The list goes on.
When we asked about the on-site search experience, we heard a consistent refrain. If you care about search on your Drupal site, you’re probably already familiar with the Drupal Search API module. It’s a well-maintained module for improving the (much-maligned) default Drupal search. It’s also easily configurable, giving end users a higher degree of flexibility than the out-of-the-box Drupal solution or more complicated, third-party alternatives.
As you’re considering Drupal Search API, it’s important to be aware of its limitations. If you’re managing a larger site, or find that more than 5% of your users are relying on search for navigation, you are likely to find the Drupal Search API solution sorely lacking.
Working with customers and the Drupal community, our team has identified some limitations specific to the Drupal Search API module. If you’d like to learn more about rectifying these challenges, get in touch.
Performance
Over time, your site will inevitably grow. And it’s very likely that you will start to run into performance issues with your search bar. When users are accustomed to Google’s millisecond response times, lag can become a real issue. If performance is bad enough, people may stop using your on-site search altogether. For any large site with complicated navigation, search is critical.
Drupal’s default search relies on database queries. Funnelback and similar search solutions, on the other hand, will query an index -- a much, much faster solution. By skipping a database query, your search solution will also lessen the impact on site performance.
The Drupal Search API only partially resolves this by creating a search index. Without additional configuration and modules, search results will still revert to a database query.
Ranking
Thomas Seidl, the primary contributor to Drupal Search API, reports that it simply uses a keyword frequency for its ranking. By default, it weights some keywords higher than others, including text in H1 tags.
This is an extremely basic ranking solution, however. With an audience trained by Google and Amazon to expect sophisticated rankings, it relies on something even simpler than the (much older) ranking algorithm found in Apache Solr. (Solr switched to a more advanced algorithm - BM25 - only a few years ago.)
Why does this ranking limitation matter? On smaller sites, ranking matters less because there are fewer similar documents. But search is most important when there is more content to search. When it’s necessary to differentiate between thousands (or millions) of documents, keyword frequency ranking isn’t going to cut it. A modified BM25 algorithm is probably going to be necessary to get the results you want and will likely outperform other algorithms. Search technologies like Funnelback have been using a modified version of BM25 since inception.
The algorithm is important. But what about search modifiers like quotation marks? Right now the Search API can’t handle search modifiers. This further eliminates critical context that could surface the right results for your users. Many search modifiers are natively available in search tools like Apache Solr and Funnelback.
Non technical user interfaces
The search API allows a fair amount of configuration, including changing node weightings.
There will always be interest in changing the rankings of specific items to meet a PR crisis or marketing campaign. But use of the Drupal Search API back-end may be extremely challenging for non-technical users like marketers.
Funnelback provides out-of-the-box tools like our marketing dashboard, accessibility auditor and easy-to-action analytics. These are designed to be used by technical and non-technical users alike to configure their search, including machine learning tools for improving ranking.
Multi-site and platform agnostic gathering
The default Drupal Search API is designed to search over a single site. However, one of the biggest advantages of search must be to aggregate data from many places.
Since the basic Drupal Search API module can’t support this, many move to the slightly more sophisticated Search API Solr Search module. While superior to the basic Drupal Search API module, it still does not provide many search-critical features. For example, it doesn’t natively support gathering data from non Drupal sites. Solutions like Funnelback can search across your social media, other sites (including non-Drupal sites), and even internal databases (like a staff or course directory).
Avoid complexity from additional modules or upgrades
Anyone who has used Drupal for any length of time knows that its great strength -- and weakness -- is the ability to install pre-built modules to add features. Modules package each solution into self-contained code. It’s not unusual for modules to have issues when combined or when Drupal core is upgraded. And we often hear about conflicts between installed modules and Drupal Search API features. For example, custom nodes and access modules can cause all sorts of issues with the Search API module.
Drupal is a great solution for many companies. But when it comes to search within Drupal, it may be time to lean on the experts.
