Confused when to use cross site publishing? When does it bring you the most value? Or how does it fit in your content strategy and information architecture?
Cross site publishing has been around since the launch of SharePoint 2013. I’ve seen various implementations and variations of it over the years but never surprised when I see the reasons behind those implementations. Many a times it’s the coolness factor of utilizing this framework. I have had the honors (ha) of being an early adopter of this framework and during last few years have been exposed with the nuts and bolts of this feature. In this article, I’ll share my thoughts on why and when to use or not use cross site publishing with real world scenarios. Before we being let’s see what cross site publishing really is and how it works. According to TechNet, It lets you create and maintain content in one or more authoring site collections, and publish this content across one or more publishing site collections, by using Search Web Parts. Cross-site publishing (XSP) lets you store and maintain content in one or more authoring site collections, and display this content in one or more publishing site collections
Do you know what your problem is?
Understand your content authors and understand the process which brings the most value to your corporate publishing. This and the next two sections will help you decide if XSP is for you.
What scenarios does it fit?
- It makes a great candidate when you have articles which are tagged and categorized with topics. It allows you to separate content authoring from the display templates and page layouts used in the article presentation. So instead of ending up with hundreds of exponentially growing unique pages in a Pages library, the publishing site will contain only two dynamic pages: the CatalogCategory page and the CatalogItem page.
- If you are in a situation where your content authors need an environment to get a head start while you develop and construct the publishing portal, then XSP is a great candidate for you.
What scenarios are NOT a good fit?
This is where it gets interesting.
- If you can’t double or even triple your upfront design, architecture, and setup time in your build phase, then it is not for you.
- If you don’t love managed navigation and term sets, this is not for you. It adds extra complexity to your design by not allowing you to have one term for multiple categories. You will need to define a new term for each new product/article category.
- If you have multiple content authors in multiple geographical locations and no time for training, this approach is not for you. The tendency to look for content in libraries is hard to overcome. Also, when managed navigation is in play, vanity URLs can make it difficult to track down source content.
- Moving from DEV to TEST to PROD is extra effort. You’ll need to recreate all your catalogs or create a PowerShell script to do that.
- If you use a analytics product and wish to track unique visitors, and track page visits, it can get tricky and the product may not support this architecture. Check with your analytics vendor before implementing cross site publishing or possibly do a proof of concept.
