Can you exclude a field from search results for a specific search interface?
The scenario I have:
-We have multiple Coveo Hive search pages on a site
-Specifically we have a "Find a Doctor" results page, and a "Site Search" results page
-On the "Find a Doctor" search page we don't want to include matches in certain fields
-On the "Site Search" search page we DO want to include matches in those fields
I know we can wrap the HTML in NO INDEX and configure Sitecore to exclude those fields from search, but that removes the results/matches from both search interfaces. I think we need the fields in the Coveo index, but then the results will show on both pages.
Solutions I am considering:
A-Try to use boosting or manipulation of the ranking in a way that ignores the fields on the Find a Doctor page
B-If it were just traditional Sitecore/Lucene I would create a separate index for this specific page. Is this possible in Coveo - how do you create another coveo index, and how do you tell a specific search interface to use that index?
Any other ideas on solving this problem?
As @François Lachance-Guillemette mentioned, the Coveo search index defines fields that are free-text searchable before indexing happens, not at query time. Thus, you will have to hack something to get the desired result.
I do not think a ranking expression is the solution as the user query can have multiple keywords.
I propose to duplicate the doctors items in the index. The original version with the education field, a second version without this field.
I do not suggest creating a separate index as there is no easy way to tell the Coveo for Sitecore UI components to use a specific index. The choice is made by processors in a pipeline.
Instead, I suggest to create and add a processor to the `coveoPostItemProcessingPipeline`. This processor receives a `CoveoIndexableItem` object and returns a a collection of `CoveoIndexableItem` objects. So you can duplicate an item and add it to the collection when the original object is a doctor item. You would strip the undesired fields content, ensure the URI or this duplicate item is different, and set something unique on those duplicates to easily select them with a query filter in the doctors page.
You can find details about this processor in the documentation:
- Understanding the coveoPostItemProcessingPipeline Pipeline
- Example Processor Using the coveoPostItemProcessingPipeline Pipeline
In your new `CoveoIndexableItem`, you must ensure the `UniqueId` and `Uri` properties values are different from the original object and are unique in the Coveo source. A good solution is to append a suffix to the original values.
When you will have the doctors indexed twice, you can add a query filter to your doctors search page to only search for those duplicated doctor items that have stripped field values.
I hope this helps.
First, I wonder if what you need is a simple filter on this "Find a Doctor" page. If you don't want the field to match the keywords, should those items not be shown at all?
But let's still consider a solution for this problem.
The feature you are talking about is called Free-Text Search, and there is no way to change this directly for a specific field.
But I think you could simulate this behavior in the Coveo Cloud Platform by creating a pipeline, and ranking down the document if it matches the current query.
Get into the Query Pipeline section, then select your pipeline.
Select the "Ranking Expression" tab, and click on *Add Rule with code*.
Put the following code:
boost `@YOURFIELDNAMEHERE=$query` by -400
This will make so that if the field contains the current keywords, they will be ranked down a little, negating the score that index adds for the matching Free-Text search.
Now, all you need to do is change your pipeline in the Search Interface that needs this rule.
Creating a second index just to have one different field configuration seems overkill for me.
Since Coveo is a unified index engine, you would have to ensure that documents from only one index is returned.
I would rather try to mess a little with the ranking than bother with this kind of behavior.