Drupal isn’t known as a particularly lightweight content management system and that is one of the reasons we love it, right? It is meant to handle large amounts of complex content. A problem occurs when you have a site that is just flush with content of different types, how do you get users to it? Navigation can only get you so far sometimes. We have personally seen this on everything from large-scale publishing sites to medical practice sites.
Having a site search of some sort can greatly improve user experience and has been a core part of the web for a long time now. It solves a few pain points that exist in sites from small to large. What are these pain points? Users don’t want to wade through navigation. You want to control what content is presented. (Meaning you aren’t leaving it to an external search engine like Google to get users to the right content) You want a pleasant experience for your users that they will actually use.
Don’t leave your content in a maze of navigation links
We can’t talk about search without getting into the search module that has been part of Drupal since version 4 ish. The vanilla search module in Drupal is a very passable solution for searching content and users in a Drupal site. It doesn’t take much to set it up either, so if you want to get to a working search experience very quickly, this might be your best bet.
The search page itself isn’t too configurable beyond that, but it does come with an advanced search built into the page. This gives users more control over how their search keywords are interpreted with things like changing the operator from contains to match their exact phrase. It will also allow them to search in whatever content types are configured on the site. If you want your users to have visibility of the different content types on the site and they have useful names, then this can be something that replaces a bunch of different search pages on the site. If that isn’t what you want, well, you are out of luck with the search module.
There are other search modules available for Drupal, of course. There are modules that can extend the usefulness of the search module, but they can’t change too much about the underlying architecture that has a few flaws that are difficult to overcome. It will slow down the site on large Drupal sites and it still won’t have a lot of configurability to the search. For a small site, the search module is a good fit, but it would be difficult to recommend it for larger sites or sites that want to have specific control over the search.
Using Solr for large sites can be a no brainer
So if having search on Drupal is a recipe for a slow site, what can you do? Drupal is known for being great at integrations and this is a good opportunity to leverage one of the more useful search technologies available. It would be a mistake to classify it as “easy-to-use”, but Apache Solr is powerful. It has a lot in common with Drupal if you think about it. It is meant for a large amount of content, has a steep learning curve, and incredibly scalable in the right hands.
If you aren’t familiar with Solr, then this doesn’t mean too much other than a fluffy description. Solr is search engine software that can provide indexing and search from a variety of sources. It allows for more in-depth analysis of the content that is indexed. It can translate content, exclude html, search against spelling errors, be case-insensitive, determine likeness between content, and a whole lot more. Some hosting providers, like Pantheon, provide this service as part of the their hosting infrastructure. If you manage your own server, then you can install Solr on that server or another remote instance. There are also a few cloud solr instances that are available out there that work pretty well also.
One of the more powerful things that becomes available when you use Solr is the ability to search within documents. That means you can extend the search into uploaded pdfs to provide even better search results. We’ve used this on a variety of sites to get users to information that would otherwise be unavailable to other searches. Features like this make it hard to compare a basic search to Solr. The searching is just a small factor in how search results are generated and processed before you hand them over to a user.
This is going to sound like we are cheaping out a bit, but there isn’t a one-size-fits-all sort of answer for a topic like this. With all web projects there are variables to consider and specific requirements that will drive decisions, so it would be impossible to say generically that you should always use one thing or another. What we can do is present the things that impact the decision the most. If the site needs search and it isn’t going to have thousands of pieces of content, then the search module will suit that need just fine. If there are more complex search needs, constantly changing content, high quantity of content, and a desire to have specific handling for different fields and content types, then you should really consider a tool like Solr.
Up Next: A deep-dive into our recent Solr integration.