In this blog post:

• Why synonyms matter when you search
• How to create a thesaurus 
• How to import a thesaurus

NOTE: Thesaurus is not available in SharePoint Online.

Why synonyms matter when you search
People are different. Not only do we look and dress differently, but when we communicate, we use different words to describe the same thing. The same applies to how we search for information. In a search engine, you might enter “flower image,” whereas I might enter “flower picture” or “flower photo.”  Even though we used different phrases, we were searching for the same information. 

And then there are acronyms. Acronyms are especially popular in organizations, but when you search for information, this can be a challenge. For example, if you want to see the Monthly Sales Report, you’ll most likely search for it by using the terms Monthly Sales Report. However, the people that create this report might use the acronym MSR. So, when you search for Monthly Sales Report, no search results are returned. 

In SharePoint Server 2013 you can easily create and upload a thesaurus that contains synonyms for search phrases and acronyms. In this blog post, I’ll use a simple example to show you how you can do this.

Imagine that you have two documents in a library:

• A Word document titled “Coffee.”
• A PowerPoint document titled “Cup of Joe.”

1. Open a text editor, for example Notepad.
2. In the text editor, enter the columns of your thesaurus: Key, Synonym, Language
3. Use commas to separate the words.

 

4. On a new line in the text editor, enter a term or a phrase, a synonym for that term or phrase and a two letter language code. Use commas to separate the phrases, for example Coffee,Cup of Joe,en

This means that when users search for “Coffee”, search results for both “Coffee” and “Cup of Joe” will be returned. 

5. Repeat step 3, but switch the order of Key and Synonym.

This means that when users search for “Cup of Joe,” search results for both “Cup of Joe” and “Coffee” will be returned. 

6. Save the file as .csv with UTF-8 encoding.

1. On the server where SharePoint Server 2013 is installed, open a SharePoint 2013 Management Shell.

2. At the command prompt, enter the following command:
   
   $searchApp = Get-SPEnterpriseSearchServiceApplication
   Import-SPEnterpriseSearchThesaurus -SearchApplication $searchApp -Filename <Path>
   
   where <Path> is the UNC path of your thesaurus file.

This is a blog post in the series, “How to set up a Search Center in SharePoint 2013”. 
In the previous blog post, I showed you how to add and configure refiners to you search results page.  In this post you’ll learn:

• Using a search vertical in an everyday situation
• About search verticals in SharePoint 2013
• Result sources – why setting limits is a good thing
• How to create a custom search vertical
• What you can do after you have successfully set up a Search Center

Using a search vertical in an everyday situation
You might not have heard the term “search vertical” before, but I’m pretty sure you’ve used them several times.  So let me show you what we mean by the term "search vertical."

I like to ski, so I often search for ski-related content. When I enter the word “ski” in a search engine, I get a wide variety of search results.

I am glad to see that there is much information out there on the topic of skiing, but many times I am just looking for great ski-pictures. And this is where search verticals come into play.

On the same search results page, I just click IMAGES, and in an instant my screen is filled with images of people in colorful clothing, racing down white slopes while bathing in sunshine from a clear blue sky.

When I click on IMAGES, I am using a search vertical. Bing has five search verticals: WEB, IMAGES, VIDEOS, MAPS and NEWS.

A search vertical filters search results so that only a certain type of search results are displayed. When I clicked on the IMAGES search vertical, the search results were filtered so that only images were displayed.

About search verticals in SharePoint 2013
In SharePoint 2013, search verticals are displayed in the Search Navigation Web Part.  There are four default search verticals: Everything, People, Conversations and Videos.

When users click on one of these search verticals, they are in fact navigating to a new page. For example, the default search results page, the Everything search vertical, uses the results.aspx page.

 When users click on the People search vertical, they are in fact navigating to the peopleresults.aspx page.

These are the default pages that are used for the four search verticals:

To view these pages, from the Site settings menu, select Site contents --> Pages.

The default vertical pages all use these Web Parts:

1. Refinement Web Part
2. Search Box Web Part
3. Search Navigation Web Part
4. Search Results Web Part

The difference between these pages is how the Search Results Web Part is configured. To be specific: the Web Parts are configured to use different result sources.

Result sources - why setting limits is a good thing
As I explained in an earlier blog post, a result source specifies the source from where your search results can come from. For example, imagine that your search index is the cube in the image below, where you have four result sources:

• Result source 1: search results can come from the entire cube.
• Result source 2: search results can come only from the Bs.
• Result source 3: search results can come only from the Cs.
• Result source 4: search results can come only from the Ds.

So, by limiting from where search results can come from, you can make it easier for your users to find what they’re looking for.

In my internal search center scenario, all search results are list items that represent a type of media file, for example an article, an image or a video. I wanted to create three custom search verticals for three specific types of media files:

• Art: list items that represent images
• Video: list items that represent videos
• Interop: items that represent interop articles (interop articles are a specific type of articles that we produce)

However, before I could start to create these search verticals, I had to create one result source for each custom search vertical. I showed you how to create a result source in an earlier blog article.

 This is how I defined the Art result source.

Remember, {searchTerms?} (contentclass:sts_listitem) path:http://<path> was the query text of the Article result source that I created earlier. To this, I added AND ContentType:Art

In our lists, we use the site column Content Type to specify the different media files. For example, all images have the value Art for Content Type.

 So, by adding AND ContentType:Art  to the query text, only list items that have the value Art for Content Type will be returned in search results.

 Here are the three new result sources I created.

Now that I had three new result sources, I could move on to creating the custom search verticals.

How to create a custom search vertical
When you create a custom search vertical, the first thing you have to do is to create a page that the search vertical will use. To create a new page, here’s what you should do:

1.  From the Site Settings menu, select Site contents.

2. Select Pages.
3. In the Pages library, select the FILES tab --> New Document --> Page.

4. On the Create Page page, enter a Title and a URL Name.
   
   In my scenario, I entered Art and art.

5. Click Create.

Your new page is displayed in your Pages library.

Now that you have a page for your custom search vertical, you can start to create the actual search vertical. Here’s what you should do:

1.  On the Site Settings page, click Search Settings.

2. On the Search Settings page, in the Configure Search Navigation section, click Add Link.

3. In the Navigation Link dialog box, in the Title field, enter the search vertical title. This text will appear as the “tab” name on your search results page.
   
   In my scenario, I entered Art.

4. In the URL field, select Browse and select a page for your search vertical.
   
   In my scenario, I selected the art page I just created.

5. Click OK to close the Navigation Link dialog Box.
6. On the Search Settings page, in the Configure Search Navigation section, select the search verticals that you don’t want to display, and click Delete.
   
   In my scenario, I deleted the People, Conversations and Videos verticals, so that I was only left with the Everything and the Art search vertical.

7. Click OK to save all changes.
8. In your Search Center, enter a query. On your search results page, your newly created search vertical is displayed.
   
   On my search results page, the Art vertical was displayed.

9. On your search results page, click on your newly created search vertical, and verify that the URL is the same as you specified in step 4.
   
   In my scenario, I clicked Art, and verified that the URL was <site>/articles/Pages/art.aspx. I also noticed that 13 search results were displayed.

10. On your new search vertical page, select to edit the page, and then to edit the Search Results Web Part.
11. In the Web Part tool page, click Change query. This will open a dialog box.

12. In the Build Your Query dialog box, from the Select a query menu, select the result source that you created for this search vertical (what we did in the previous section).
    
    In my scenario, I selected Art result source (Site Collection).

13. Click OK and save the page.

On your new search vertical page, enter a query to verify that the correct search results are displayed.

In my scenario, I entered united airlines again, and noticed that only 11 search results were displayed.  Remember, before I changed the result source in the Search Result Web Part, 13 results were displayed. So my new vertical was working. Nice!

In my scenario, I added two more search verticals, Video and Interop. And with that, I had completed the Search Center set up.

What you can do after you have successfully set up a Search Center
When you have successfully set up a Search Center, the first thing you should do is to congratulate yourself on a job well done. Nice job!

However, the job usually doesn’t end there. To make the Search Center even more user-friendly, you can change the way search results are displayed, for example to display information that is specific to your company or business. You can read about how to do that in the blog series How to change the way search results are displayed in SharePoint Server 2013.

This is a blog post in the series, “Set up a Search Center in SharePoint 2013”. 

In the previous blog post, I showed you how to identify refiners, and told you about refinable managed properties. In this post you’ll learn:

• How to map a crawled property to a refinable managed property
• How to initiate a reindexing of a list or library
• How to configure the Refinement Web Part to use custom refiners
• How to add counts to refiner values

How to map a crawled property to a refinable managed property
In my Search Center scenario, I knew that I wanted to use the following refinable managed properties:

The procedure to map a crawled property to a refinable managed property is the same for all refiners. In the procedure below, I’ll show you how you can do this. As an example, I’ll show you how I mapped the crawled property that represents Internal Writer to the RefinableString01 refinable managed property.

1. On your Search Center, on the Site Settings page, select Search Schema.

1. In the Managed property field, type the name of the refinable managed property to which you want to map a crawled property, and then click the arrow button.
   
   In my scenario, I typed RefinableString01.

1. From the Property Name field, select Edit/Map Property.

1.  On the Edit Managed Property page, click Add a Mapping.

1. In the Crawled property selection dialog box, use the Search for crawled property name field to search for the crawled property that you want to map to this refinable managed property.
   
   In my scenario, I knew that I wanted to use the site column called Internal Writer. Crawled properties don’t contain spaces, so I left the space out and entered InternalWriter.

         Two crawled properties were found: ows_q_USER_Internal_Writer and ows_Internal_Writer.

If you now look like a big question mark, trust me, I understand your confusion. This part is quite tricky. There are actually two crawled properties (very strange since we only have one Internal Writer site column), so which one should you choose to map to the refinable managed property?

OK, let's take a closer look at what’s going on. The difference between the two crawled properties is the prefix. One has a ows_q_USER_ prefix, and the other ows_. 
Now here’s the important part: When mapping a crawled property to a refinable managed property, you should select the crawled property with the ows_ prefix!

In another blog post I talk about the naming convention for crawled and managed properties. For more information, see From site column to managed property – What’s up with that?

1. Select the crawled property with the ows_ prefix, and click OK.
   
   In my scenario, I selected ows_Internal_Writer.

On the Edit Managed Property page, notice that the crawled property has been added to the Mappings to crawled property field.

1. In the Alias field, enter a name for the refiner.
   
   In my scenario, I entered InternalWriter.

It's important to understand that the alias that you enter here is not the refiner name that will be shown on your search results page. This alias is meant to make your life a bit easier when you’re configuring refiners in the Refinement Web Part (I’ll show you how to do this in the procedure below). Remember, you can't change the name of the refinable managed property, so when you do the configuration, you’ll have to deal with quite a few refinable managed properties that have similar names; RefinableString01, RefinableString02 etc.  So the alias is a good reminder of which value you mapped to the property.

1. To finish the mapping, click OK.

I repeated the steps from the procedure above for the remaining four refiners. The screenshots below show my final result.

How to initiate a reindexing of a list or library
When you’ve mapped all the rfinable managed properties that you want to use, you have to do a reindexing of your list or library. I showed you how to do this in a previous blog.

How to configure the Refinement Web Part to use custom refiners
By default, the Refinement Web Part is included on the search results page. In the previous blog post I showed you how to configure the Search Results Web Part to use a new result source. The two refiners Author and Modified date were also displayed. 

To display custom refiners, here’s what you should do:

1. On the search results page, click the Settings menu, and then click Edit Page.
2. In the Refinement Web Part, click the Web Part Menu, and then click Edit Web Part.

1. In the Web Part tool pane, click Choose Refiners.

1. In the Selected refiners section, select the refiners that you don’t want to display on your search results page, and click Remove.
   
   In my scenario, I removed all the default refiners.

1. In the Available refiners section, scroll down and select a refinable managed property.
   
   In my scenario, I selected RefinableString1. This is the refinable managed property that I mapped to the crawled property ows_Internal_Writer. Notice that sample values are shown (a good sign that we’re on the right path), along with the alias InternalWriter.

1. Click Add.

This moves the RefinableString01 property over to the Selected refiners section. When a refiner is moved over to the Selected refiners section, additional configuration options are shown (I'll go through them in steps 10 and 11).

1. Repeat steps 5 and 6 to add all the refiners that you want to use on your search results page.
   
   In my scenario, I added the five refinable managed properties I configured in the previous section. 

1. To preview the refiners, click Preview Refiners.

1. To change the display order of refiners, select the refiner you want to move, and then click the Move up or Move down button.
   
   In my scenario, I selected RefinableString04 (notice the Alias name), and selected Move up until it was the first property in the Selected refiners section.

1. To enable users to select multiple refiner values, from the Display template menu, select Multi-value Refinement Item.

I clicked Preview refiners again, and verified that the ContentType refiner (RefinableString04) was displayed first, and that it had checkboxes that would enable users to select multiple refiner values.

I repeated this step for the refiners RefinableString01, RefinableString02 and RefinableString03.

But I wasn’t quite satisfied with the way my RefinableDate01 refiner was displayed. Remember, this refiner represents Requested publish date. By default, the refiner values are shown in a list, which makes it difficult for users to see the date range.

To display the refiner values in a more user friendly way, in the Refinement configuration dialog box, from the Display template menu, I selected Slider with bar graph. In the Dates section, I selected Last day, week, month, six months and year.

When I now previewed my refiners, the values for the Requested Publish Date refiner (RefinableDate01) were nicely displayed as a graph.

But there was one more thing that I had to improve: the refiner display names. RefinableString01, RefinableString02 etc. does not make much sense to users.

1. To change the refiner display name, in the Display name field, enter the name you want to be displayed for each refiner.
   
   In my scenario, for the RefinableString04 refiner, I entered Content Type.

Repeat this step for all your refinable managed properties.

1. To save the configurations, click OK in the Refinement configuration dialog box, and then OK in the Web Part tool pane.
2. Save the page.
   
   In my scenario, the five refiners were now nicely displayed on the search results page.

However, there was one small detail that would make the refiners even better.  Right now users couldn’t see any numeric details for the refiner values. For example, I could see that I (Bella Engen) was a writer of articles that had to do with search configuration, but I couldn’t see how many articles.

To see this information, I need to add counts to the refiner values.

How to add counts to refiner values
To add counts to refiner values, you’ll have to edit a display template. When you work with display templates, you'll make life a lot easier for yourself if you map your network drive. By doing this, you’ll be able to work with display templates from Windows Explorer. I describe how you can map your network drive in this blog article.

1. In your mapped network drive, go to Display Templates --> Filters.
2. To add counts to refiners where it’s only possible to select one refiner value at a time, open the HTML file Filter_Default. To add counts to refiners where it’s possible to select multiple refiner values, open the HTML file Filter_MultiValue.
   
   In my scenario, I had configured the refiners so that users would be able to select multiple refiner values, so I opened the file Filter_MultiValue.
3. Change the value for ShowCounts to true.

1. Save the file.

To verify that refiner counts are displayed, enter a query in your search center.

In my scenario, I could now see that I (Bella Engen) was the writer of 5 articles that had something to do with search configuration. Nice!

Next blog article in this series
How to add a custom search vertical to your search results page

This is a blog post in the series, “Set up a Search Center in SharePoint 2013”. 

In the previous blog post, I showed you how to create a result source, and how to configure the Search Results Web Part to use this new result source. In this post you’ll learn:

• How refiners helped me plan my trip to Japan
• What you should look for when identifying refiners
• About making a managed property refinable
• About refinable managed properties

How refiners helped me plan my trip to Japan
Although the term "refiners" is new to you, there is a high chance you’ve already used them.  For example, have you ever bought a book online? Well, then most likely you’ve used refiners to find the right book.

I recently went online to my favorite book store to find a travel guide about Japan. I typed in "Japan," and as you can imagine, pages of search results popped up. Trawling through pages of results is not my idea of fun. Luckily for me though, the site designers had smartly provided a way to narrow down search results. On the left side of the page was a "Categories" list, containing entries such as "Cooking," "Geography," "History," "Travel" and so forth. I clicked "Travel," and in an instant, the search results showed only travel books containing the word "Japan."

However, turns out that there are quite a few travel books out there on Japan, so I needed to trim the results even further. I was looking for a paperback version (yes, I admit that there are still dinosaurs like me around who prefer the look and feel of a book made out of paper…). So, still focusing on the lists on the left side of the page, I spotted a category called "Format" containing terms like "Hardcover," "PDF," "Audio," Digital," and "Paperback. " So I clicked "Paperback" and got what I’d been after: results for travel books about Japan in paperback! Unfortunately, the number of search results was still too large for me, so I continued to use the different lists on the left side of the page until I’d drilled right down to five hopeful candidates; one of which made it over the finish line, and straight into my shopping cart.

Now, here’s the techy part to the tale: when I was clicking "Travel" and "Paperback" I was, in fact, using refiners. In SharePoint terms, a refiner is a managed property that has been made refinable. Refiner values are the values of a refinable managed property.  So in the case of my online shopping trip, "Categories" and "Format" were refiners, and "Travel" and "Paperback" were refiner values.

In another blog post, I explain how site columns are “transformed” into managed properties during a crawl. For example, in my Search Center scenario, I have a site column named "Internal Writer.” For each list item, this site column contains the name of the writer of an article (remember, each list item represents an article). To help user quickly narrow search results to articles that have been written by a particular writer, in the same manner that I narrowed search results when shopping for a travel book on Japan, I had to make the managed property that represents the "Internal Writer" site column refinable. There is, of course, a little bit more to it than that, and I will show you all these steps in later blog posts.

What you should look for when you identify refiners
This is a pretty easy one: to identify refiners, you should look for information that users will want to use to narrow down search results.

In my Search Center scenario, I wanted to use the following refiners:

• Manager
• Internal Writer
• Editor
• Content Type
• Requested Publish Date

About making a managed property refinable
The first thing you have to do when you configure refiners is to make the managed properties that you want to use, refinable.
Depending on your permission level, you can do this from two places:

There’s a reason why this can be done from two places. If you are working with content (let's say you’re a content manager), you’re not likely to have Search service application administration level rights, that is, you won’t have access to Central Administration. However, you’re very likely to have Site collection administrator permissions.

In the previous blog post blog I described how content managers can easily add content to the search index without having to pester Search service application administrators. So now that everyone’s happy, we don't want to jeopardize this happiness by making content managers dependent on a Search service application administrator to enable refiners.

In this blog post I’ll only describe the procedure as it can be performed by a Site collection administrator (content manager). For information on how Search service application administrators can make a managed property refinable, see Enable automatically created managed properties as refiners in SharePoint Central Administration.

About refinable managed properties
In the previous section I stated “The first thing you have to do when you configure refiners is to make the managed properties that you want to use, refinable." Well, turns out that Site collection administrators (content managers) can't do this because they don't have the required permission level. They do, however, have the permission level to map a crawled property to a refinable managed property.

Confused? I don't blame you, so let me try to explain.

Search service application administrators, who have access to Central Administration, can configure many things directly on a managed property. For example, the screenshot below shows how they can change the property named InternalWriterOWSUSER to be refinable by selecting either Yes – active, or Yes - latent from the Refinable menu.

If we look at the same property from the perspective of a Site collection administrator, who is configuring the property on the site collection level, not only is the property name grayed out, but the Refinable choice menu is locked (it might not be easy to see on the screenshot, but trust me; the field is locked).

Luckily, there are a large number of "empty" managed properties that are enabled as refiners by default. By "empty" I mean that a crawled property is not mapped to it. This means that Site collection administrators can map a crawled property to one of these refiner-enabled managed properties without having to depend on a Search service application administrator.

The table below gives an overview of the managed properties that are enabled as refiners by default.

In my Search Center scenario, I had already identified the refiners that I wanted to use. For each of these refiners, I defined which refinable managed property I would use:

So now that we have a plan for which refiners to use, the next step is to do the actual refiner configuration.

Next blog post in this series
How to add refiners to your search results page

This is a blog post in the series “Set up a Search Center in SharePoint 2013”. 

In the previous blog post, I showed you how to create a Search Center Site Collection and enable crawling of your content. In this post you’ll learn:

• How to turn off versioning for the Pages library
• Why you should consider creating a result source for your Search Center
• How to create a result source
• How to configure the Search Results Web Part to use a new result Source

How to turn off versioning for the Pages library
If you don’t want to check pages in and out when you configure the Search Results Web Part, you can turn off versioning for the Pages library.

To turn off versioning for the Pages library:

1. Go to Site settings --> Site contents.
2. On the Site Contents page, click the Pages library.
3. In the Pages library, click the LIBRARY tab and then Library Settings.
4. On the Settings page, click Versioning settings.
5. On the Versioning Settings page, in the Content Approval section, for Require content approval for submitted items, select No.
6. In the Document Version History section, for Create a version each time you edit a file in this document library, select No versioning.
7. In the Require Check Out section, for Require documents to be checked out before they can be edited, select No.

Why you should consider creating a result source for your Search Center
A result source specifies where your search results can come from.

For example, in my scenario, I did not want search results to come from all sites within the SharePoint farm. I only wanted search results from one specific site within the farm.

The default result source in a Search Center returns search results from the entire SharePoint farm. If you want search results from the entire SharePoint farm, you can skip to the next blog post in this series.  However, if you want search results from only a sub set within your SharePoint farm (in my scenario, one specific site), you should create a result source.

How to create a result source
Depending on your permission level, you create a result source on three levels:

To save space, I will only show you how to create a result source as a Site collection administrator.

1. Go to Site settings --> Search Result Sources.
2. On the Manage Result Sources page, click New Result Source.

3. On the Add Result Source page, enter a Name. Select values for Protocol and Type, and click Launch Query Builder. This will open a dialog box.
   
   In my scenario, I named the result source Articles, and kept the default values for Protocol and Type.

4. In the Build Your Query dialog box, define the result source.
   
   Remember, in my scenario, I only wanted search results to come from a particular site within the farm, so in the Query text field, I added the following:
   {searchTerms?} (contentclass:sts_listitem) path:http://<path>

Now, before we move on, let me break down what I entered:

• {searchTerms?} In my result source, I wanted to include the words that users type in the query box whey then search for something. Obviously I have no way of knowing what users will type, so I added the query variable {searchTerms?} By the way, you can tell it’s a query variable because it’s enclosed in curly brackets.  When users enter a query, this query variable will be replaced by the words the users have typed in the query box. The question mark at the end of the variable means that if no words have been entered, the variable should be ignored.
• (contentclass:sts_listitem)  This means that only list items will be included in my result source.
• path:http://<path>   This is the path to the site from where I wanted search results to come from.  

5. Test that the result source is working correctly by clicking on the TEST tab, and then Show more.

6. In the {searchTerms} field enter Query words to simulate a query entered by a user, and then click Test query.
   
   In my scenario, I entered search configuration.

Notice that 52 results were returned (I will tell you why this is kind of cool in the next section…).

7. Click OK to close the dialog box, and then Save.

So now that we have a result source for the Search Center, we can move on to configuring the Search Results Web Part to use the new result source.

How to configure the Search Results Web Part to use a new result source
By default, the Search Results Web Part is used on the search results page. In order to configure the Search Result Web Part, you have to navigate to the search results page.

1. On your Search Center home page (the default URL to this page is <site>/Pages/default.aspx), enter a query in the search box, and press Enter.
   
   In my scenario, I entered search configuration.

When you press Enter, you will be taken to the to the search results page (the default URL to this page is <site>/Pages/results.aspx).

In my scenario, 1,051 search results were returned.

Remember, by default you’ll get search results from the entire SharePoint farm. To change this so that only search results from your newly created result source are returned, here’s what you should do:

2. On the search results page, click the Settings menu --> Edit Page.
3. In the Search Results Web Part, click the Web Part Menu, and then Edit Web Part.

3. In the Web Part tool pane, click Change query. This will open a dialog box.

4. In the dialog box, from the Select a query menu, select your newly created result source.
   
   In my scenario, I selected the Articles (Site Collection) result source.

5. Click OK in the dialog box, OK in the Web Part Tool pane, and then save the page. To verify that the configuration is working, enter a query.
   
   In my scenario, I entered search configuration.

52 results were returned, which is the same number of items that was returned when I tested the query in the result source configuration. Cool, don’t you think?

Now that the Search Results Web Part displays the search results we are interested in, the next step is to make it easier for users to filter these search results. To do this, we'll use refiners, which is the subject of the next blog post. 

Next blog post in this series
Plan to use refiners on a search results page