Skip to content

The Problem with Contextual Search Scopes


Contextual Search Scopes are a widely used feature in SharePoint deployments and while some question their value many users rely on them.  It also turns out that in certain situations contextual scopes pose a real design challenge.  But before we get into that let’s explain what contextual search scopes are for the uninitiated.

What are Contextual Search Scopes?

A contextual search scope is a scope that SharePoint creates for us automatically and provides the capability to scope searches to the current site or the current list.  Most SharePoint users will recognize the following screenshots depicting search boxes with various contextual scope configurations.

No Scopes Dropdown – default to current context

Show Scopes Dropdown – default to current context (list and site)

“This List” scope

Site collection administrators enable or disable contextual scopes at the site collection level as well as choose to display them as options in a scopes dropdown or default to the current context.

Here is the page where a site collection administrator would configure the settings.

How Contextual Search Scopes Work Out of the Box

Did you notice the last field on the Search Settings page?

This field determines which results page is used when a Contextual Search is selected.  The default is /_layouts/OSSSearchResults.aspx.

So if you have a site that utilizes regular, static  search scopes *and* contextual Search Scopes, those queries made using contextual scopes will utilize the OSSSearchResults.aspx results page while non-contextual scopes could be directed somewhere else and here is where the rub starts to happen.

The Problem

SharePoint 2010, especially when using FAST Search Server 2010 for SharePoint (FS4SP), truly now delivers world-class enterprise search.  Notice I didn’t say “SharePoint Search” but “Enterprise Search”.  Part of the promise of enterprise search is that users will have a singular location where they can go to search for everything in their organizations.  This typically warrants a dedicated Search Center.  I won’t go into details here, but a Search Center is a site template that contains pages, web parts and features that allow administrators to build search sites.  Here is a link to more about site templates.

To Explain the issue, let me walk you through a very typical scenario.

An organization develops a search strategy that includes a dedicated SharePoint application just for search.  Let’s call it

The search team brands the search site, customizes the search results XSLT and exposes lots of properties as refiners and sort-by options.

Now, their SharePoint Intranet is a separate application with lots of different site collections like the following:





The SharePoint administrator redirects search queries from each of these site collections to  Users type their queries in from the Intranet and are they are redirected to  The users are happy because SharePoint and FS4SP deliver great results and a rich experience.  At this point if the user performs a search and chooses “This Site” or “This List” as their search scope their search results are displayed on the OSSSearch page.  This creates sort of an uneven experience.  Users perform a Search using the “All Sites” scope and they get this great search center with custom look and feel, refiners, etc.  And when they do a search using “This Site” it looks totally bland.

One option would be to brand the OSSSearch page to look like the results page in our search center.  We could do that (or better yet, make a copy and edit that so we’re not being destructive).  However, that would mean that every time we changed the branding, added a refiner, added a sort-by property or anything else on the results page we would also have to make the same change on the OSSSearch page.  Now imagine we are a large organization with 50 to 100 or more search consumers, each with their own set of requirements.  It’s easy to see how this could become completely unmanageable.

Fortunately SharePoint allows us to forward contextually scoped queries to our site as well.  Problem solved, right?  Wrong.  When a user performs a contextual search the query is redirected and the scope is honored in our results but there are a handful of problems ranging from just kluge to unacceptable:

  1. There is nothing on the page to indicate to the user that there is a contextual scope being applied.  The only way they could tell is if they looked in the query string.
  2. If they perform a subsequent search from the results page using a different scope  there is no way for them to get back to the contextual scope (it disappears) other than using the browser’s back button.
  3. There is no way for the user to get back to the page that they executed the search from other than using the browser’s back button.
  4. They lose the navigation of their original site since they are now in a different site collection or application

So this is “the problem with contextual search” (as the antagonistic title of this article describes it).  In environments with a centralized search center, a highly customized search center or search is being provided as a service this is something that you may need to address and I personally have never seen  good answer for it.

A Solution

I recently faced this challenge at a client and, while there are obviously different approaches with various pros/cons, this is what we decided on.

  • All non-contextual queries redirected to one centralized search center.
  • Each search consumer (business group) has a dedicated results page in that search center.
  • Consumers have two options for their contextual searches
    1. If it is important to the consumer that they have a consistent search experience (same look/feel/UX for all queries) then contextual searches will be sent to the search center
    2. If it is more important that they maintain their navigation on the search results page then they will keep their OTB OSSSearch page for their contextual searches

Now, if they go with option “1” we have some problems to solve (as stated above).  Here is how we solved them.  I’ll warn you up front that I am able to post the code for this solution.  Instead I will explain the concepts and most developers will realize this is not an incredibly complex task.

Problem:  There is nothing on the page that indicates to the user that there is a contextual scope being applied.  The only way they could see it is if they looked in the query string.

Solution:  We extended the Search Box Web part (meaning we wrote a custom search box web part based on the OTB SharePoint search box web part) to grab the contextual search from the query string and add it to the dropdown box where users can select search scopes.

Problem:  If they perform a subsequent search using a different scope, there is no way for them to get back to the contextual scope (it disappears) without using the browser’s back button.

Solution: We had to make sure the contextual scope stayed in the dropdown – we called this making it “sticky”.  In order to make it sticky we needed the page to “remember” about the scope between page loads so that the scope remained no matter what the user clicks on the page.  There are a few options for this sort of thing in SharePoint (or any .NET application really).  You can use session       variables, cookies, or keep the value in the query string.  For governance/performance reasons the client would not turn on session.  We could have written a cookie but ultimately we were able to keep the scope in the query string by capturing the onclick event of the search button and using our own version of the JavaScript that is normally fired when you click on the search button.

Problem:  There is no way for the user to get back to the page that they executed the search from  (except for the browser’s back button).

Solution:  Surprisingly, this was the biggest challenge we faced.
At first I wrote some JavaScript that grabbed the document.referrer (the page we came from) and wrote it to a cookie.  Then I would dynamically change the href of the site icon to this value.  This was working nicely but it turns out document.referrer is not very reliable.  Some browsers do not populate it and it’s easy to turn it off or block it.

Then I had the idea to instead just keep track of the number of page loads (for instance if a user was paging through a results set) in a cookie and set the onclick of the site icon to history.go(n), where “n” is the number of page loads to go back.  This seemed to work fine, and I thought it was quite clever (if I do say so myself), however if the user clicked on the back button of the browser it would cause problems and it ultimately was not a resolvable problem.

Finally, we had the idea to just make an edit to the search.js (this is the farm-level JavaScript that is called when a user clicks on a search button).  We made a copy of it and added a couple of lines of code that simply add a rfr (referrer) query string parameter.  Then we can read this on the results page and add it to our back button.

We made this back button functionality part of the web part however there is no technical reason to couple this with the search box.

Problem:  They lose the navigation of their original site since they are now in a different site collection or application

Solution:  This we just solved by giving them the option to use the page in the layouts folder.

Again, there are different ways to skin this cat, but this solution is working nicely and has been a low-effort/high-reward solution for us.

I should also point out that this is a very relevant solution for those organizations considering a Search First migration (I’ll leave it at that as Search First could be a subject for a whole seperate blog series).

I hope this explanation/solution will help you navigate this potential headache.

Happy Searching!

From → FAST, SharePoint 2010

  1. Phillip Lyle permalink

    Thanks for the fantastic article.

    Any change you’d share the javascript & coding details of your disappearing contextual search solution?

    • Hey Phillip,

      Sorry for the delay in responding. Unfortunately I can’t share it as it was for a client. But let me know if you have any specific questions about approach and I can certainly try to give you a hand. I’ll send you my contact info by email as well.



  2. Keren Sar-el Tsur permalink

    I encounter the same and it’s really make a dillema whether to use or not the contextual search (which does have its advantages). Great article however 🙂
    BTW – I’m interested to explore how to leverage contextual search (if using it) and expand it to have a scope of “this folder” (=this path) and not only this document library.
    Windows Exploree enables that so why not in Sharepoint…
    if anyone did such a thing i’ll be glad to hear

  3. Thanks Paul.Good information here.

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: