This document contains information about obtaining relevant search results with the Apache Solr Search module.
Note
The Apache Solr Search module and related hooks are only available for Drupal 7.
Adjusting your website’s search result ordering and matching (often referred to as tweaking results) can be as complicated a topic as you want to make it. To help you with the process, the Apache Solr Search and Search API Solr modules provide several hooks and user interface options to tweak your website’s results. The combination of hooks and settings that works for you depends on your architecture, your site visitors’ behavior, and your real-world user testing.
Use the following methods to receive the best possible results, make small changes, and then test and obtain feedback. Consider what the most natural results are for searches, and then make modifications.
Here are some of the available options:
Use biasing options to tweak result ordering
Use the biasing options in the Drupal user interface either to tweak result ordering by newness or by entity type, or to give more importance to matches in taxonomy terms, titles, or other fields.
To view your website’s biasing options, sign in as an administrator, go to Configuration > Apache Solr Search > Settings, and then click Bias next to the search environment you want to edit. You can also read the Acquia Search documentation on Using bias to tune search results. For example, an easy way to bubble up items on search results is if you mark those nodes as sticky at top of lists. You must also work with your editors to understand when and how to configure this flag.
Use modules to help boost matching terms
By using modules such as the Apachesolr Term
Proximity
module, you can provide better results when users are searching for
phrases. For example, a search for parking permits
will boost
items having the exact phrase in their contents before items having the
words shown separately.
Create custom code that implements hooks
Using hooks like hook_apachesolr_query_alter()
can change the queries sent to Solr as those queries are being made. Hooks
can also introduce complex boosting or ordering commands onto the Solr
query.
Create hard overrides of the searching behavior
You can create these overrides by editing the following text files in your Solr configuration:
Note
Acquia recommends that you only change these files if you’re knowledgeable with Solr. Acquia Support cannot help you debug issues relating to changes to these files.
Acquia-hosted Solr instances (Acquia Search) contain limits to the files that can be changed. For more information, see Custom Solr configuration.
synonyms.txt
- Allows you to swap words
For example, a search for garage
can only match parking
,
or searches for both garage
and parking
can be equivalent
and match either garage
or parking
in content.
protwords.txt
- Allows you to force Solr to always take words
as they are and not cut them down to their root
This prevents Solr from
stemming words.
Normally, a search for parking
will match park
, parks
,
and parker
, but adding parking
to protwords.txt
ensures that searches will only match the exact term: parking
.
elevate.xml
- Allows you to force certain items to show up among the
first results for a specific search. To learn more read Configuring the
Query Elevation Component.
For example, modifying this file allows you to always display
parking
as the first result when website visitors search for
phrases like parking
or where to park
. The Solr best
bets module can
help you construct this file. Once you have created and tested a
version of this file, create a Support ticket to begin its placement on your
server.
stopwords.txt
- Allows you to tell Solr which words are not
meaningful and should be dropped from queries and indexing.
For indexing items that are not nodes, the Apache Solr Not a Node module can be useful.
You can use various tools to track searches and see what your visitors are looking for. Tracking low-result and no-result searches help you with an editorial strategy to put content into the hands of those visitors.
Due to Varnish® caching, Drupal-side logging of searches does not provide you all the data around what is being searched for on your website, while a client-based (JavaScript) option does. For example, the Apache Solr Statistics module does not properly log all searches while working under Varnish®.