Questions about Autocomplete and Related queries



I have a few questions about the Autocomplete and Related queries functionality.

I have used the code in the following pages and found that they only return items that have been editorially added:

For the autocomplete I can pass t in and get a single result of turtle, added editorially, however I have auto complete enabled for a search box (described at and using field SearchTitle$$string) and get several hits returned for te (lots of test pages). I would expect these results to be included when turtle gets returned as well as they start with 't'.

The help text in the CMS module suggests that autocomplete and related queries should be picked up based on previous searches but this does not seem to be happening - am I missing some configuration? I have added .Track() to my query and can see statistics in the CMS.

In addition, it's not clear how the JS autocomplete actually works. Am I correct that it performs a search of the search terms entered (as seen in the top queries panel) that have at least one match? For example if someone searches for sausage and returns no matches then using autocomplete would not return anything when passing in sa. Which is the most reliable field to search by? What do others use?

Any thoughts about any of the above appreciated as always.


Sep 29, 2014 11:19

Ok, well I've decided that for our requirements I need to combine the method described in with the method described in in order that I can provide a list of actual search terms submitted (where results are returned) along with any editorially added autocomplete options.

I'm using the code:


Yesterday this was working but only returning editorially added autocomplete options (I believe it should have included options recorded by the search as well) and I could prove this by passing in the URL to the browser and viewing the JSON. Today the same code is not returning anything even the editorially added items which I can see in the CMS admin interface.

It's as if the index is not working correctly or needs configuring somehow. Any thoughts?

By the way we are not using the hosted service we have an on premise install of Find.



Sep 30, 2014 10:30


Did you find anything regarding this

I have the same issue here, I get no registered searches in /find/rest/autocomplete/get/c?size=3 although I can see in EPiServer that a number of searches have been made for words starting with c. I also can also reproduce your issue regarding only editorial autocompletes registered in the CMS are returned.

This is the way I track searches: var unifiedSearch = SearchClient.Instance.UnifiedSearchFor(searchQuery).Track();

and apperently they get registered in the stats, but are not accessible via /find/rest/autocomplete/get/

Is this a bug perhaps?



Oct 08, 2014 16:38

Hi Emma,

Using Fiddler we have found that the underlying call is not correct it produces:


however this is not valid it should be:


It's missing & after tags= and adding this in returns both statistical and editorial results.

I've raised this with EPiServer support and am currently waiting for a response.

I hope this helps,


Oct 08, 2014 16:53
Hi Mark! Thank you, that seems to be the issue. However I would not like to expose the site index in js so I'd rather it worked as it is supposed to. Some time has passed, was wondering if you got any reply back? /Emma
Nov 13, 2014 15:02

Hi Emma,

No reply from support yet but you've reminded me I need to chase it up! I will update this when I have an answer.



Nov 13, 2014 15:28

Hi Emma,

In case this is still an issue for you we have found how to fix this. We recreated our index setting the default language and selecting as least one language from the languages list. In addition we are passing the language in to the query.

We're keeping the ticket with EPiServer open as it's still an issue but I hope this works for you.

Many thanks,


Dec 05, 2014 15:17


We're still having this issue. With the help of Wireshark we identified the issue to a missing &-sign in EPiServers internal request to Find (just as Mark mentioned).

Our possible workaround is to create a proxy for this, but it seems to be an easy fix for EPiServer. Any plans?

Best regards,


Jan 08, 2015 9:36

Hi Emma/Sebastian,

The response I had from EPiServer in December was:

This is related to the Bug 114702: Track() sends invalid (empty) siteid tag.

This is fixed in the following package PM> Install-Package EPiServer.Find -Version 7.5.453.109

I haven't tested this yet as we were able to get it working using the language workaround previously posted.

I hope it helps,


Jan 08, 2015 10:14

Thanks Mark,

Unfortunately we're running version, which should include the fix you mentioned. How did you solve it? Could you be a little more precise how you did it?

What did you mean with?

"We recreated our index setting the default language and selecting as least one language from the languages list"

Best Regards, Sebastian

Jan 08, 2015 10:23

Hi Sebastian,

Well we deleted our index and recreated it from scratch. When creating the index again we selected English for the default language and then selected English in the Languages list underneath default language.

Does that help?


Jan 08, 2015 12:12
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.