EPiServer, Episerver 11, Episerver Find

Episerver Find, Track(), oops 404 when search result is clicked

This is a quick informative post about Episerver Find and tracking the search results link clicks. Your site users might get 404 not found error instead of the page or content they were trying to reach from the search results. So keep on reading to understand the background and solution for the issue.

Background for this post

It all begun a few months ago when we updated customers Episerver instance. At that time the latest EPiServer.Find.CMS package was 13.2.1. Smoke tests looked good and live we went. It wasn’t long that first reports came in that the site search was not working for anonymous users (we don’t use ASP.NET session on the site). Next week there was a fix to this issue, EPiServer.Find.CMS 13.2.2 was released (Aug 9, 2019). We quickly installed that version and all was looking great again.

But unfortunately we later discovered there were new issues with that release and this post is about the issue we unfortunately just now discovered.

EPiServer.Find.CMS 13.2.2 package issue

It fixed the issue FIND-5883 – Tracking does not work if sessions are disabled which we were affected by but it also included a new feature that was not mentioned anywhere.

When you use Track() in your searches and show the results to your users the Find tracking script in browser changes all the links to point ‘/find_v2/_click?xxxx’ where xxxx is a bunch of query string parameters. And when user clicks a link the tracking is done here and the users browser is then redirected to the actual content from this action.

So in the 13.2.2 package they implemented two additional checks: Ensure the redirect url is absolute url and VerifyCorrectRedirectLocation.

When user clicks the search result link there is query string parameter ‘_t_redirect’ which contains the url where the user is redirected to. So the first check checks that this parameter contains absolute url and if it doesn’t the controller will return 404 response. So as long your search results ‘hit.Document.Url’ is absolute url, everything just works.

The more problematic check that caused 404 responses to us is the VerifyCorrectRedirectLocation check. Basically what it does, is run the search again. It uses the ‘_t_q’ parameter which contains the query done by user and ‘_t_hit.pos’ parameter which contains the ‘search hit’ position in the search results done by user on your site. And here is the problem – how will it know what kind of query has been done, what has been filtered out and so on. The implementation uses the ‘hit position’ as the Take(hitpos+10) call and it also uses the redirect url in ‘.Include(pseudo-code: include items that match the redirect url)’. But this check can lead to a situation where the returned results don’t have the content where the redirect should happen – and then the click action will again return 404 not found.

How to reproduce with Alloy MVC site?

With the current Episerver Visual Studio extension version when you create a new Alloy MVC site using Episerver Find you actually get this problematic version of EPiServer.Find.CMS 13.2.2. So I’ll proceed with this. Add your Episerver Find demo index or developer index configuration to web.config. Run the site and setup your admin account as you would normally do.

In edit mode create a new ‘Standard page’ under ‘About us’ and name the page ‘Blog’. On the SEO tab enter title ‘Blog’, enter keywords ‘blog’ and enter description ‘This is a fake blog page.’. Switch to Content tab and enter some text to the ‘Main body’ and in teaser enter ‘This is an awesome blog page.’. Publish the page.

Next step is to upload images on the site where the image name starts with ‘blog’. You will need more than 10 of these images. I uploaded images blog_kuva_A.png, blog_kuva_B.png, … blog_kuva_Q.png 😀 These are needed to throw off the VerifyCorrectRedirectLocation check.


Next step is to navigate to Find -> Configure -> Boosting. Here you can change how the search results are boosted. Boost ‘Title’ to ‘Very high’ and all other options to ‘Very low’. Like in the following picture (don’t mind the ‘Best bets’ entry ‘Alloy Blog’ you can see in the image as the first result in the preview).


Next step is to browse the Alloy demo site and make a search for ‘blog’. You will get this kind of result page:


And now when you click that link you will get 404 not found like the image below:


So why do we get the above 404 not found page? The VerifyCorrectRedirectLocation uses the results ‘hit position’ which in this case is 2 and adds 10 to it => 12 and then uses that in the search it makes to take 12 hits from the search and also uses the ‘redirect url’ to include all content matching that url. And then takes the first hit which url matches the redirect url value. So in theory that should get the “page” and some extra result and happily do the redirect. The problem is in the fact that we don’t include images in our search result and we have boosted search to use the ‘Title’ property (the underlying index item SearchTitle$$string like “SearchTitle$$string”: “blog_kuva_A.PNG”). So when the check does its search it included also all the images and as we have more than 10 images that will match to ‘blog’ search the check gets all those images and the include result for the content url is not in the results. That is why it returns 404 not found because it can’t check the redirect url (because the result it got contains mainly images).

This same “issue” is also in the EPiServer.Find.CMS version 13.2.3.

How to fix this issue?

Update to EPiServer.Find.CMS 13.2.4 or newer where this extra checking is removed from the code 🙂 I looked at the 13.2.4 release notes but none of the entries ring a bell to fix exactly this issue.

So most likely if you are still using 13.2.2 or 13.2.3 version of EPiServer.Find.UI you should update it (as would be the answer from support if you report issues and are not on the latest version).

2 thoughts on “Episerver Find, Track(), oops 404 when search result is clicked

  1. Thanks a lot for posting this!
    Two days until site launch and we discovered this bug (running Find v.13.2.2). You saved us a lot of trouble.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s