SearchResults Issue in SharePoint when search with wild card character *

Question

I am having SP 2013 SP1 on my server, thats on-premises. I have configured search on this with a search service application and ent.search center site collec. and performed search and am able to get the search results thats having "contains".

If i upload a doc called "bug_in_footer.docx" , "bug_in_checkin.docx" files into a document library and i search for documents thats having "bug" , it gave me the correct results.

The issue am facing is, when I search for a document bug* , am getting some 50+ results. When I see the number of results in the first page is mentioned as 15. when I do a pagination, am getting the number of search results documents as 25 .and when I paginate it to the 3rd page, am getting the number of search results as 40. its very strange that , search is providing me this kid of confused search results and customer has raised this as a bug in our application. so am facing this,number of search results were not counted as accurate.

We have promised to customer that, we are going to give only the OOTB search functionality and there wont be any custom search. So we are depending upon the default search and search results.

But here i am stuck with this strange issue, wanted to know how will I resolve this issue ? is there any powershell scripts that provides kind of trimming of results or with accurate num of search results?

Answer 1

The result count is an estimate. As the search results are paged through the estimate is re-evaluated each time. If you want an accurate count you would need to iterate through all the results to count them.

Your customer needs to understand that if they want an accurate count from the first search it will come at a performance overhead. You could if you wanted to use a script to iterate through the result set in the background and show an accurate count but I would not advise it unless you really have to.

Answer 2

Copied from the searchunleshed wodpress.com site :

About X results”: Sharepoint 2013 Search result counts keep changing

Posted on 2014/10/23 by Igor Veytskin

A question that’s asked fairly often is regarding the fact that Sharepoint Search seems to show inconsistent result counts from what is initially shown on the very first page and as you move along. Here is an example below:

About X results

Interestingly enough, this is pretty common for most search engines out there and I’ll start with showing a quick example of similar behavior with Google search. I’m going to run a search for “DocumentumConnector”, which you can see returns “About 13,000 results” on my first page.

DC_1

So what happens when I get to Page 10? There are now “About 12,800 results” shown, which means these numbers are just estimates and should get more precise as we move closer to the tail of the result set:

DC_2

Let’s get back to Sharepoint 2013 Search and explains what happens here. The “About x results” is presented when the total number of results is uncertain with Collapsing (i.e. duplicate detection in a typical case) enabled and the result set is partially processed.

With TrimDuplicates = $true(it is by default), Sharepoint Search uses a default CollapseSpecification = “DocumentSignature”. This means we are collapsing on what are considered to be duplicate documents. Processing all of the results is too costly in terms of quickly returning results, which is why an estimate is given. To recap, this means that a full result set isn’t processed for duplicates and the number returned as the Total number of hits after duplicate removal is an estimate based on how many duplicates were found in those results that were de-duplicated(based on collapsing done so far).

By default, your result page shows 10 results at a time. You may notice that for result sets with less than or equal to 10 results, you will always get an accurate number of results and thus “About” is omitted. For more than 10 results, you will get the “About x results” on the first page until you get to the very last page of results and only then we will actually know the exact number of results and can once again omit the “About”.