Inconvenient getting a specific item using SharePoint 2013 Search
More than just search
SharePoint 2013 Search is an enterprise-class search engine. It contains advanced language and query processing features and ranking models all of which are meant to understand what you are looking for and to find the most relevant content for your query.
For a long time search was the thing that you went to whenever you needed to find something. With the release of SharePoint 2013 this situation has changed. Capabilities such as search-driven publishing, recommendations and the overall scalability of Search make it very appealing to build search-driven solutions.
One thing that search-driven solutions in SharePoint 2013 have in common is the fact that they don’t necessary wait for the user to enter a search query and retrieve content from the search index using predefined queries. Those queries vary from retrieving a number of items to looking up a specific item in the search index. Particularly the latest turns out to be challenging.
Finding a specific item using search
There are a number of ways in which you can use SharePoint 2013 Search to find a specific item. In search-driven publishing scenarios those ways often involve matching a specific string of text such as the title or the slug.
Whenever a search query is executed against SharePoint 2013 Search it will process the query and do its best to understand what you are trying to find. One of the pieces of this process is linguistic processing of the query, such as breaking it into words, verifying that there are no spelling mistakes, checking if they are similar forms of those words that might be a better use for in the query, etc. As a result the query that you have used to search might not necessarily be the query that is executed in SharePoint 2013 Search to find the results.
Exact match in SharePoint 2013 Search
If up until now you’ve worked with CAML-based solutions this behavior might be surprising to you. In the past, whenever you said
<Eq>some text here</Eq>, SharePoint would do exactly that and find the item that exactly matched this value. With Search things aren’t this easy and using a phrase like
Title="some text here" will still break up your query and have it processed by the Search linguistic components. Luckily there is a way to tell Search that what you are really interested in is a complete match against the provided value.
If you have built a search-driven solution that retrieves items by matching the title, slug or some other similar value, you should ensure that the Managed Property used in comparison has the Complete Matching property checked in its configuration.
If you’re using PowerShell to deploy your solution in a structured and repeatable way you can set it through the ManagedProperty.NoWordBreaker property:
$ssa = Get-SPEnterpriseSearchServiceApplication $property = Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity RefinableString00 $property.NoWordBreaker = $true $property.Update()
Changing this setting has a big impact on how SharePoint 2013 Search matches values, so instead of changing it for a property that might be used elsewhere it might be a better idea to use one of the empty Managed Properties (such as RefinableStringXX) and be sure that everything will work as expected.
SharePoint 2013 Search contains rich capabilities that help you find the relevant content. Search-driven SharePoint solutions often use predefined queries to retrieve results or specific items from the search index. Unfortunately, due to the advanced linguistic capabilities of Search, in some cases wrong results are returned. By enabling Complete Matching on the Managed Property used in the query you can ensure that the complete phrase will be used for matching the value and that Search will return exactly the item that you need.