The ability of defining user- and search engines-friendly URLs for content published from Catalogs in SharePoint 2013 is a great advantage from the web content publishing perspective. There is however one thing that you have to take into account for the URL rewriting for Catalog Items to work.

Catalog Items and Cross-site content publishing in SharePoint 2013

One of the new capabilities of SharePoint 2013 is the search-driven publishing model where the published content is served from the SharePoint 2013 Search index. A particular scenario of search-driven publishing is cross-site publishing, where the content is stored in one or more Catalogs and made available for publishing on one or more sites.

From the SharePoint perspective every List or Document Library can become a Catalog and with that there are no restrictions as to the type of content that you would publish using the cross-site publishing capability. You can for example publish your product catalog but also more informational content such as press releases or blog posts.

Publishing on the web and the importance of human-readable URLs

When publishing content on the web one of the most important considerations are the URLs.

First of all, from the search engine optimization perspective, URLs are one of the most important factors for ranking pages in search results. If the URL of your page contains the keyword used in the search query, this page is more likely to be rated more relevant than other pages with similar content but without the keyword in the URL.

Additionally many people perceive readable URLs as more trustworthy and simple and readable URLs are more likely to be shared without including any mistakes or typos.

When leveraging the cross-site publishing capability, SharePoint 2013 offers us the ability to specify how we want to build up the URL of every Catalog Item. This can be done when publishing the Catalog and can be tweaked for the need of the particular site later when connecting to the Catalog.

Publishing content from Catalogs on public-facing websites in SharePoint 2013

When connecting to Catalogs in SharePoint 2013 there are two ways in which you can have the content published. You can either choose to just make the content from Catalog available on your website or you can truly integrate it making it a part of your website.

When you choose to connect to a Catalog but not to integrate it, all links point to the original Catalog Items. This approach might be useful in scenarios when you want to build a publishing portal around content that is published elsewhere and where it is also accessible by your visitors. Integrating a Catalog with your website on the other hand, will embed its contents in your website and as a result your visitors won’t be able to tell the difference between the content published directly on the website and content surfaced from Catalogs.

URL rewriting for Catalog Items in SharePoint 2013

URL rewriting for Catalog Items is available only for Catalogs that are integrated in your website. The idea behind URL rewriting for Catalog Items is that whenever a URL of a Catalog Item is requested, SharePoint translates it to the type and identifier of the requested Catalog Item and with that it is able to retrieve the requested content from the search index. To illustrate how it works let’s take a closer look at a sample scenario: publishing blog posts on mavention.com.

How URL rewriting for Catalog Items works

The mavention.com website consists of two Site Collections: authoring (authoring.mavention.nl), where the content Catalogs are stored, and publishing (www.mavention.com) where the content from Catalogs is published.

In cross-site publishing scenarios content is stored in a Catalog which is a flat SharePoint List or a Document Library. If the content is hierarchical (like different kinds of cameras, computers, or press releases) you can denote the location in the hierarchy using a single-value Managed Metadata field. On the authoring site of the Mavention website all of the content is stored in a single Pages Library. The type of the page is denoted with the single-value Item Type Managed Metadata Field which contains Terms such as News, Case or Blog. Every single page in the Pages Library is provided with the Item Type value. For all blog posts this field is set to the Blog Term (ID: 0ff8f49b-b684-4833-9337-6dd8e46de86f).

When publishing content from Catalogs one important architectural decision is defining the identifier for every Catalog Item – a kind of primary key that uniquely identifies each item within the Catalog. This can be a SKU for products, ISBN for books or slug for web content. In general your identifier will become a part of the rewritten URL so that you can retrieve each item from your Catalog. Additionally it should also be used as the identifier for SharePoint 2013 Search Analytics which requires it for building for example content recommendations.

To build a rewritten URL for a Catalog Item SharePoint needs the information from the following Managed Properties: Path (which originally contains the absolute URL of the catalog item located in the Catalog and which after URL rewriting contains the rewritten URL), Catalog Item identifier (SlugOWSTEXT for mavention.com), hierarchy identifier (owstaxidMvItemType for mavention.com), spSiteUrl and ListID. Following is how that information might look like typically:

Using the values from the Path, spSiteUrl and ListID Managed Properties SharePoint will try to retrieve the configuration of the Catalog from which the particular content item is published. The Catalog information contains different configuration data amongst which the CatalogUrlTemplate property which contains the template for building Catalog Items URLs and which for the Catalog on mavention.com looks like this:

/[Term.owstaxidMvItemType]/[SlugOWSTEXT]

When building a rewritten URL, SharePoint will parse this template and replace the parts of the URL with their respective values. First it will find the owstaxidMvItemType item which is denoted as a Term. Because of this SharePoint will try to retrieve the value of the owstaxidMvItemType Managed Property. Because this value has been denoted as a term, SharePoint will look for the value of the L0 property from which it will extract the ID (0ff8f49b-b684-4833-9337-6dd8e46de86f; see screenshot above).

Having retrieved this ID SharePoint will the try to find the first Friendly URL Term with this ID from the Navigation Term Set of the context site. This is the term pinned in the Navigation Term Set of the publishing site. When found, SharePoint will get the server-relative URL of that term and replace the [Term.owstaxidMvItemType] token with it.

Processing the URL template further, SharePoint will find the SlugOWSTEXT token. In this case it’s a simple property so SharePoint will try to get its value from the search result row and when found, it will replace the token with the retrieved value.

In the context of the mavention.com website a sample blog post with the slug of easier-working-size-based-image-renditions-sharepoint-2013 would have its friendly URL rewritten to /blog/easier-working-size-based-image-renditions-sharepoint-2013; see screenshot above).

Should the URL rewriting process fail for some reason the value of the Path Managed Property will be empty.

Exploring the ULS log you would find the following message in the Web Content Management Product:

RewriteTableUrls:Url [URL] belongs to a connected catalog but could not be rewritten to a friendly url. The Path property for this result will be removed. To see all data for these results, set the ‘DoNotOverwriteCatalogPath’ property in the KeywordQuery Properties to true.

Inconvenient URL rewriting for Catalog Items

Although URL Rewriting for Catalog Items is very powerful it has a few requirements in order for it to work. One of those requirements is the fact that the all pinned Navigation Terms must be visible in the Current Navigation.

When working with Managed Navigation, for every Navigation Term SharePoint offers us the choice whether that particular Term should be visible in the Global and Current Navigation.

If you choose to hide your Term in the Global Navigation everything will work as expected, but as soon as you hide it from the Current Navigation, the URL rewriting process will fail and the value of the Path Managed Property will become empty.

Luckily this process can be reversed and you choose to include the Navigation Term back in the Current Navigation, the URL Rewriting process will work as expected.

So why would you want to hide a pinned Navigation Term in the first place?

There might be many different reasons for which you would not want to display specific Navigation Terms in your navigation. It might be for aesthetic or clarity purposes or you just might want to structure the hierarchy of your website in a different way than how it is defined in the particular catalog.

One consequence of pinning and reusing Terms in SharePoint 2013 is that you cannot create new Terms underneath them. To overcome this limitation you might want to hide the pinned Term from the navigation and create a new one yourself copying all the catalog settings such as Category and Catalog Item Pages. As you have just seen however, this approach leads to breaking the URL rewriting process.

To keep the URL rewriting process for Catalog Items working correctly you would either stick with the information hierarchy from your catalog and design the hierarchy of your website around it, or you would create a custom menu control which might help you hide the unnecessary nodes from the menus keeping them included in the Current Navigation at the same time.

Summary

When publishing content from catalogs SharePoint 2013 allows you to define the URLs on which that content will be published. This allows you to optimize your website for Internet search engines and make the URLs more user-friendly. The URL Rewriting mechanism that SharePoint 2013 uses for generating friendly URLs for Catalog Items has a few requirements to work correctly, amongst which is the inclusion of the pinned Navigation Term in the Current Navigation.