This is a blog post in the series “How to set up a product-centric website in SharePoint Server 2013.”  In this series, I'll use data from a fictitious company called "Contoso" to show you how to use search features to set up a website based on product catalog data.
Note: Most of the features described in this series are not available in SharePoint 2013 Online.

For an overview of the blog posts in this series, go to How to set up a product-centric website in SharePoint Server 2013.

Quick overview

In previous blog posts, I showed you how to create a category page and a catalog item page. I also showed you how to assign these two pages to terms within the Site Navigation term set.  When we browsed to the "Audio" category, we couldn't see any content. This was because when we created the category page, we didn't add any Web Parts. 

In this stage we will start to merge different pieces of what we have done in previous steps. In this blog post we'll learn:

• About the Content Search Web Part
• How to add a Content Search Web Part to a page
• How to configure a query in a Content Search Web Part on a category page
• About the query configuration
• How to view details of the query configuration

Start stage 9

To display content on our Contoso website, we'll use the Content Search Web Part.

About the Content Search Web Part

The Content Search Web Part (CSWP) uses, as its name implies, search technology.

Most of us use search technology on a daily basis. Think about how many times a day you enter query terms in a search box, for example on bing.com; how after pressing Enter, you scan search results that are almost immediately displayed on a search results page (by the way, how did you find this blog post?).

When visitors browse to a page that contains a CSWP, they're probably not aware of this, but they're actually issuing a query. However, the thing that differs with CSWPs is that instead of entering query terms in a search box, the query is contained within the Web Part itself. This means that when a visitor browses to a page that contains a CSWP, this query is automatically issued.

Another thing that is different from the bing.com search scenario is that search results aren't displayed on a separate search results page, but within the CSWP. In most cases, visitors won't even know that search technology is being used to display the content they're viewing. To them, it'll look and feel like any other webpage.

How to add a Content Search Web Part to a page

Browse to the page where you want to add the CSWP. In our scenario, let's browse to "Audio".

1. Click the Settings menu, and then click Edit Page.
2. In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
3. In the Categories list, click Content Rollup.
4. In the Parts list, click Content Search, and then click Add.

In our scenario, we'll add a CSWP to Zone 3.

The CSWP contains a default query, so it already displays some content (Audio, Cameras and Computers) -- but not the content we want to display. To make the Web Part display Contoso catalog content , we'll need to configure the query in the Web Part.

How to configure a query in a Content Search Web Part on a category page

1. In the Web Part, click the Web Part Menu , and then click Edit Web Part.

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

In the dialog box, notice that "Audio" is shown in the top left corner. This is the category which we navigated to and selected to edit the page from. Also notice, that in the RelevantResults section, the top three results, Audio, Cameras and Computers, are listed. These are the same three results that were shown in the Web Part when we added it.

3. From the Select a query list, select your catalog result source. In our scenario, it's catalog - Products Results.

A result source narrows the scope from which search results can be retrieved. When we connected our publishing site to our catalog, SharePoint Server 2013 automatically created a result source for our catalog. In our scenario, this result source is named catalog - Products Results. By selecting this result source, only search results from our catalog are retrieved.

For more information about result sources, see Plan result source and query rules.

When we selected this result source, the number of RelevantResults changed from 864 to 775. 775 happens to be the number of items we have in our catalog. Therefore, selecting this result source confirms that we're on the right path to configuring the query.

4. In the Restrict by tag section, select Restrict by current and child navigation terms.

A key phrase in this selection is navigation terms. This refers to the category in the site navigation the visitor is browsing. In this particular case, the visitor is browsing the "Audio" category. 

Remember, one of the first things we did in this series was to import catalog content into a list. We also imported terms into the term set Product Hierarchy, and associated each item in the list with a term from that term set.  When we connected our publishing site to our catalog, we specified that the full site navigation should contain terms from the Product Hierarchy term set. Because we have used the same term set to tag the items in our catalog and to build our site navigation, we can use a term from our site navigation to search for catalog items that have been tagged with that same term.

So, our query in the CSWP will therefore display search results for items that are in the catalog - Products Results result source, and that have been tagged with either "Audio", or any of the children of "Audio", for example "MP3 players" or "Speakers".

This selection reduced the relevant search results to 114, which happens to be the number of items in our catalog that belong to the "Audio" group.

Another key phrase from the selection Restrict by current and child navigation terms is "current." I'll talk more about the importance of this phrase in the next section.

5. Click OK, and save the page.

On the "Audio" category, the search results have changed to show different results.

If you browse to the "Cameras" category, you'll see three other search results displayed.

If you browse to the "MP3" category, you'll see three other different search results are displayed.

If you are now thinking "OK, I understand how we got the correct search results for the "Audio" category, because that is the category we clicked, and where we changed the query in the Web Part. But why do we see different search results when we browse the catalog? And shouldn’t we change the query for all the other categories as well?"

Well, let's take a closer look at what's going on.

About the query configuration

We only had to configure one query because the same page is used for all categories. Remember how in stage 8 we assigned the page ContosoCategoryPage.aspx to all terms within the Site Navigation term set? We assigned this page to all terms, so even though we edited this page in the "Audio" category, we could have edited it in any other category, and achieved the same result.

We only had to configure the query once, because the query issued from the Web Part differs depending on which category we browse to. Remember that the CSWP contains a query that is automatically issued whenever someone browses to a page that contains a CSWP, and that search results are displayed in the Web Part. Also, remember that we selected Restrict by current and child navigation terms when we configured the query in the Web part. The word "current" is very important, because it means that the query issued by the CSWP will change depending on the category the visitor is currently browsing. If you edit the Web Part from another category, you can see that the Web Part has changed.

For example, if I browse to the "Cameras" category and take a closer look at the CSWP, I can see that:

• "cameras" is included in the URL.
• "Cameras" is in the top right corner of the query configuration.
• The number of RelevantResults has changed to 118, which happens to be the number of items in the catalog that belong to the "Cameras" group.

So, when I browse to the "Audio" category, the CSWP issues a query for catalog items that have been tagged with "Audio" or any children of "Audio", and displays search results. When I browse to the "Cameras" category, the same CSWP (remember, we only used one page for all categories) issues a different query, this time for catalog items that have been tagged with "Cameras" or any children of "Cameras", hence different results are displayed.

How to view details of the query configuration

To view details of the query configuration, click on the TEST tab. The actual query issued by the CSWP, is shown in the Query text field.

In our example, the query that is issued by the CSWP from the "Audio" category looks like this:

(contentclass:sts_listitem OR IsDocument:True) SPSiteUrl:http://contoso/sites/catalog ListId:3a3f66cd-9741-4f15-b53a-b4b23c3187ea owstaxidProductCatalogItemCategory:#c771504f-6a2f-423f-98de-0e12fcfa08c9

If this doesn't make any sense to you, don't worry!  There is a logic to it, and I'll break it down to make it clearer.

• (contentclass:sts_listitem OR IsDocument:True) SPSiteUrl:http://contoso/sites/catalog ListId:3a3f66cd-9741-4f15-b53a-b4b23c3187ea
  is our catalog result source, catalog - Products Results 
• owstaxidProductCatalogItemCategory
  is the managed property for the site column Item Category (remember, our Product Hierarchy term set is tied to the Managed Metadata site column Item Category) 
• #c771504f-6a2f-423f-98de-0e12fcfa08c9
  is the GUID of the term in the current navigation, in this case "Audio"

In our Product catalog site collection, in the Product Hierarchy term set, you can see that the GUID represents the term Audio.

So now we have configured the query for the CSWP on our category page. We still have to do some configuration to make it display more than three search results, and also give it a "Contoso look." I will show you how to do this in a later post. The next step is to add a CSWP to our catalog item page, and configure the query to show individual catalog items.

Next blog post in this series
Stage 10: Configure the query in a Content Search Web Part on a catalog item page

Additional resources
Configure Search Web Parts in SharePoint Server 2013
Scenario: Create SharePoint sites by using cross-site publishing in SharePoint Server 2013

This is a blog post in the series “How to set up a product-centric website in SharePoint Server 2013”.  In this series, I'll use data from a fictitious company called "Contoso" to show you how to use search features to set up a website based on product catalog data.
Note: most of features described in this series are not available in SharePoint 2013 online.

For an overview of the blog posts in this series, go to How to set up a product-centric website in SharePoint Server 2013.

Start stage 1

When you use cross-site publishing, you use one or more authoring site collections to author and store content, and one or more publishing site collections to show this content.

In our scenario, we'll start by creating a Product Catalog Site Collection. We'll use this site collection to author and store information about the products that Contoso offer, for example, info about the MP3 player "Litware 2G E200", or the Laptop "Adventure Works 15.4W".

Along with this, we'll be creating a Publishing Portal Site Collection. We'll use this site collection to display product info about "Litware 2G E200", "Adventure Works 15.4W" and all the other products that Contoso offer.

Remember though, visitors browsing the Contoso website, which is the publishing portal, will NOT be able to view content in the product catalog! Visitors will only get to see content that has been added to the search index from the product catalog. When visitors browse the Contoso website, search technology displays content from the search index.

So, in the simplest of terms, our architecture will look like this:

Bear with me if this is a bit tricky to follow. I'll soon be using real examples, and it'll all become a lot clearer. But first things first: let's create the site collections.

To create a Product Catalog Site Collection, here's what you should do: Go to Central Administration --> Create site collections, and then enter details for the site collection. Here's what you need to enter:

1. A title for the website.
2. The website's URL.
3. Select 2013 for the experience version.
4. From the Publishing tab, select the Product Catalog template.
5. In the field Primary Site Collection Site Administrator, enter the site admin's user name.

Take a look at the screen capture below for some more guidance. 

Now, to create a Publishing Portal Site Collection, repeat the steps above, but with one difference, from the Publishing tab, choose Publishing Portal. The title of this site collection is Contoso.

Now that we've our site collections, it's time to start adding content.

Next blog article in this series
Stage 2: Import list content into the Product Catalog Site Collection

Additional resources

• For more information about creating site collections in SharePoint 2013, see the TechNet article Create a site Collection in SharePoint 2013.
• For more information about cross-site Publishing, see the TechNet scenario page Create SharePoint sites by using cross-site publishing 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 "How to change how search results are displayed." To demonstrate how you can customize your search results, I'll use examples from an internal Microsoft Search Center.

For an overview of the blog post in this series, go to How to change the way search results are displayed in SharePoint Server 2013.

In the previous blog post, I showed you a simple method for adding a custom icon and values from two custom managed properties to your search results. In this blog post, I'll show you a somewhat more complete method for changing the way your search results are displayed that includes if statements and hit highlighting. We’ll learn:

• Strategy for killing three birds with one stone - search results version
• How to display values from custom managed properties with hit highlighting, and get automatically improved relevancy

Strategy for killing three birds with one stone - search results version

First, let’s state what we want to achieve:

• Display values from two custom managed properties
• Apply hit highlighting to the two custom managed properties
• Get automatically improved relevancy for our search results

Before I show you how to do this, let's look at the strategy we want to follow to accomplish this.  If it gets a bit complicated, please try to hang in there. Hopefully it'll be clear by the end of this blog.

First, remember how we can think about hit highlighting:

1. The managed properties that are listed in the Hit-highlighted properties (JSON) section of the Search Results Web Part and the "magical summary" property are passed to the HitHighlightedProperties property.
2. All values of the HitHighlightedProperties property are passed to the HitHighlightedSummary property. 
3. A truncated version of the values in HitHighlightedSummary is displayed in the Search Results Web Part with three dots at the end.

Also remember that each item display template contains a reference to the Item_CommonItem_Body display template, and that this template contains an onlick method that will result in automatically improved relevance based on the end-user’s click behavior.

So our strategy is simply this: create variables in the item display template that will be passed on and rendered by the Item_CommonItem_Body display template.

Specifically, that means that we have to do the following:

• Add the custom managed properties that we want to display in our search results to the Hit-highlighted properties in the Search Results Web Part.
• Add the custom managed properties to an item display template.
• In the item display template, create a new variable that will be used by the property HitHighlightedSummary to display our two custom managed properties with hit highlighting.
• In the item display template, leave the reference _#=ctx.RenderBody(ctx)=#_ so that the Item_ComonItem_Body display template will render the search result. This ensures that we get automatically improved relevancy.

OK, now let’s take it step-by-step, with examples of how I did this for my scenario.

How to display values from custom managed properties with hit highlighting, and get automatically improved relevancy

First you have to find the managed property names that correspond to the custom site columns that you want to use. I showed you how to do this in a previous blog.

Then you have to do some configuration on the Search Results Web Part. Here's what you should do:

1. On the Search results page, choose the Settings menu, and then choose Edit Page.
2. In the Search Results Web Part, choose Web Part Menu --> Edit Web Part.
3. In the Web Part tool pane, choose to expand the Display Templates section and then select Use a single template to display items. This will allow you to make changes to the Hit-highlighted properties (JSON) field.

1. In the Hit-highlighted properties (JSON) field, use the following format to add the custom managed properties that you want to add hit highlighting to:
   "<Managed property name>"
   
   In my scenario, I wanted to apply hit highlighting to the ContentSummaryOWSMTXT and the owstaxIdTechnicalSubject managed properties.

1. Choose Apply to save the changes. This will close the Display Templates section.
2. Choose Display Templates to reopen the section, and choose Use result types to display items.

1.  Choose OK and save the page.

Then you need to add the custom managed properties to an item display template. Here’s what you should do:

1. Open the item display template that belongs to the result type for which you want to customize search results.
   
   In my scenario, this was TechNet content.
2. In the item display template, in the ManagedPropertyMapping tag, use the following syntax to add the custom managed properties that you want to display:
   '<Current item property name>':<Managed property name>'
   
   In my scenario, I wanted the values from the managed properties ContentSummaryOWSMTXT and owstaxIdTechnicalSubject to be displayed in the search result. To make the file easier to maintain, I named the current item properties the same as the managed properties.

Then you need to create variables in the item display template that will be used and rendered by the Item_Common_Item_Body display template.  Here's what you should do:

1. Because you have no guarantee that the values of your custom properties will contain any of the entered query words, that is, hit highlighting will not be used, you have to create variables that ensure that the value of your custom properties will be displayed regardless of hit highlighting.
   
   The following screenshots show how I created two such variables for my custom properties ContentSummaryOWSMTXT and owstaxIdTechnicalSubject.

1.  In addition, I added a similar variable for the Title property. If you don’t add this, the search results will not be rendered.

1. The last step you have to do in the item display template is to create a variable that will override the HitHighlightedSummary property used to display the values.

1. Save the item display template.
2. NOTE: You do not need to do this step if you are using SharePoint Online.
   Go to Site settings --> Search Result Types. Notice that a Property Sync alert is displayed.

This alert is displayed because we added managed properties to an item display template (what we did in step 9). To update the result types with the newly added managed properties, choose Update.

IMPORTANT! If you don't do this update, the newly added managed properties will not display in your search results.

After I made these changes, when users entered a query in the Search Center, the search result included:

1. A custom icon.
2. The value of Title with hit highlighting.
3. The value of ContentSummaryOWSMTXT with hit highlighting.
4. The value of owstaxIdTechnicalSubject. The query words did not match the property value, however because of the variable that I created in step 10, the value is displayed.
5. A link to the item in the list

I wanted to make one little change to how the value for owstaxIdTechnicalSubject was displayed. I wanted to give users a bit more context as to what this value represents, so I decided to add the text "Technical Subject:" before the value. Also, because this value is not always present for all list items, I decided that it should only display when a value was present.

To do this, I made a change to the variable that overrides the HitHighlightedSummary property:

Notice that I added a slightly different color to the text "Technical Subject:". With this addition, the final search result is displayed like this:

In our planning, we had decided that we wanted 6 different result types. After creating the TechNet content result type and display template, it was very easy to copy this work over to the other 5 result types. 

And here’s the result:

So now that we have changed the way search results are displayed, the next step is to change the values that are displayed in the hover panel.

Next blog post in this series
How to display values from custom managed properties in the hover panel

This is a blog post in the series “How to set up a product-centric website in SharePoint Server 2013”.  In this series, I'll use data from a fictitious company called "Contoso" to show you how to use search features to set up a website based on product catalog data.
Note: Most of the features described in this series are not available in SharePoint 2013 Online.

For an overview of the blog posts in this series, go to How to set up a product-centric website in SharePoint Server 2013.

Quick overview

As described in Stage 2: Import list content into the Product Catalog Site Collection, we've imported content about Contoso's product line into the Products list. To display this product information in our Publishing Portal (the Contoso website), we now have to enable the Products list as a catalog.

These are the steps we'll take to enable a list as a catalog:

1. Go to catalog settings page.
2. Enable catalog sharing.
3. Enable anonymous access.
4. Define website navigation hierarchy.
5. Define values to use in the URL to an individual product.

Start stage 3

1. On the Products list, from the LIST tab, click List Settings.

On the Settings page, click Catalog Settings.

 We'll define several things on the Catalog Settings page. I'm going to break all of this down into individual chunks.

2. For Catalog Sharing Select Enable this Library as a catalog.

By selecting this, we'll be confirming that content from the Products list should be added to the search index.

3. For Anonymous Access, click Enable anonymous access, and then click Make Anonymous.

By doing this, we'll be granting anonymous visitors, that is, visitors who aren't logged on to Contoso's website, access to view content from this list.

Note that we're not granting visitors access to the list itself. All we're doing is granting anonymous visitors access to view the catalog content from the search index. Anonymous visitors will never be able to see the actual Products list.

4. For Navigation Hierarchy (this section shows up after Catalog Item URL in the UI, but I prefer to tell you about this one first), select Item Category.

In my previous blog post, Stage 2: Import list content into the Product Catalog Site Collection, I showed you how the managed metadata column Item Category is tied to the Product Hierarchy term set.

By selecting Item Category here, we're in fact specifying that the navigation on our publishing site (the Contoso website) will be determined by the structure in the Product Hierarchy term set.

In the next screenshot, notice that the structure in the Product Hierarchy term set, matches the navigation on the Contoso website.

The terms from the Product Hierarchy term set will also be used to create a friendly URL for our category pages on the publishing site (the Contoso website). For example, the URL to the page displaying camcorders is http://www.contoso/cameras/camcorders, and the URL to the page displaying camera accessories is http://www.contoso/cameras/camera-accessories.

5. For Catalog Item URL Fields, select the list columns that should be used to create a unique URL to a product. For Contoso, we'll use Group Number and Item Number.

The URL to an individual product will be composed of the terms that we specify in Navigation Hierarchy (previous step), and the values from the fields we specify as Catalog Item URL Fields. When selecting these fields, we should use at least one field that contains a product unique value, because we want to use this unique value in the product URL. By doing this, the URL to the product Fabricam Home Movimaker M300 will be different from the URL to the product Fabricam Home Movimaker M400.

For Contoso, the unique identifier of a product is the value in the Item Number column. We also want to use the value of the Group Number column, so we'll add them both (I'll explain why I also want to use Group Number in a later post).

 Our final Catalog Settings page looks like this:

 So now that we have set all these specifications, it's time to crawl the catalog.

Next blog article in this series
Stage 4: Set up search and enable crawling of your catalog content

Additional resources

• For more information about enabling a list as a catalog, see Share a Library or list as a catalog on TechNet.
• For more information about cross-site Publishing, see the TechNet scenario page Create SharePoint sites by using cross-site publishing in SharePoint Server 2013.