SharePoint 2013 offers twomodelsfor building public-facing websites. On one hand youcanuseeverythingyouknowfrom SharePoint 2007 and SharePoint 2010. On the other hand there is the new search-drivenpublishing model.In the previousversions of SharePoint the only option we had was touse the structuralpublishing model where the physicallocation of the page woulddetermineits URL andlocation in the navigation. We wouldbuild content aggregationsusing the Content Query Web Part and the Site Collection was the boundarythat we had toworkwith.In SharePoint 2013 next to the traditional publishing model we canuse search-drivenpublishing. The first great benefit is, that we canuseManagedNavigationtodecouple the physicalstructure of the site fromitsnavigation. Withthat we can store the content wherever we want in the site and we can even publish content stored in other Site Collections. Tobuild content aggregations we canuse the new Content By Search Web Part whichnotonlyallowsustobuildstatic content aggregations but empowersustobuildtruly intelligent websites (more aboutthat in myothersessiontomorrowmorning).
Search-drivenpublishing offers great benefits for building public-facing websites.First of allitallowsyouto separate the authoringandpublishingexperience. This offers youadditional flexibility in configuringboth environments tooptimally serve theirpurpose. Additionallyitallowsyoutotrulyembrace content-centricpublishing: bycreating content catalogsyoucancentrally manage your content andpublishitto a number different sites.One of the greatstrengths of SharePoint 2013 Search are itsanalyticscapabilities. With search-drivenpublishingyoucanleveragethosecapabilitiesandbuildpersonalized websites where the relevant content is displayedto users.Finally search-basedpublishingscales way beyond the classic publishing model whatallowsyouto get more value out of your environment.
Although Search-drivenpublishing offers somegreatpossibilities, there are a few thingsthatyoushould keep in mind.Some new capabilitieslike cross-site publishing, friendlyURLs or XML Sitemaprequire search-drivenpublishing or someparts of ittowork. Whenworkingwith search-drivenpublishingyoucaneither have your content stored in separate catalogs or youcan have itstored in the same Site Collections. WhencombinedwithFriendlyURLs the latter case can have negative impact on SEO of your website as the same content willbeavailable via two different URLs (physicalandfriendly).Whenworkingwith Search-drivenpublishing the new way of building content aggregations is touse the new Content By Search Web Part. This Web Part by default uses new renderingmechanism, called Display Templates, which are based on JavaScriptand are different thananythingyoumight have knownfrom the past. ShouldJavaScriptbedisabled on the page or therewouldbe a JavaScript error the user wouldsee a blank page. Additionallywith Display Templates you have to take into account the browsers supportedby SharePoint 2013 andverifythatyouwon’texcludeany major group of visitors on your website.In somesituationsusing search-drivenpublishingmight introduce additionalchallenges, likewhentryingtoretrieverelated content based on some property on a page. Because the content of the page is retrievedby search it is knownvery late in the processwhatintroducesadditional impact on the performance of your pages.Althoughnotobvious at first glanceit is possibletouse server-side XSL-basedrenderingwith search-drivenpublishing. The challengewiththat is howeverthat in such case you are on yourown as everythingthat is available out of the box uses the standard JavaScript-basedrendering.
Although Search-drivenpublishing offers somegreatpossibilities, there are a few thingsthatyoushould keep in mind.Some new capabilitieslike cross-site publishing, friendlyURLs or XML Sitemaprequire search-drivenpublishing or someparts of ittowork. Whenworkingwith search-drivenpublishingyoucaneither have your content stored in separate catalogs or youcan have itstored in the same Site Collections. WhencombinedwithFriendlyURLs the latter case can have negative impact on SEO of your website as the same content willbeavailable via two different URLs (physicalandfriendly).Whenworkingwith Search-drivenpublishing the new way of building content aggregations is touse the new Content By Search Web Part. This Web Part by default uses new renderingmechanism, called Display Templates, which are based on JavaScriptand are different thananythingyoumight have knownfrom the past. ShouldJavaScriptbedisabled on the page or therewouldbe a JavaScript error the user wouldsee a blank page. Additionallywith Display Templates you have to take into account the browsers supportedby SharePoint 2013 andverifythatyouwon’texcludeany major group of visitors on your website.In somesituationsusing search-drivenpublishingmight introduce additionalchallenges, likewhentryingtoretrieverelated content based on some property on a page. Because the content of the page is retrievedby search it is knownvery late in the processwhatintroducesadditional impact on the performance of your pages.Althoughnotobvious at first glanceit is possibletouse server-side XSL-basedrenderingwith search-drivenpublishing. The challengewiththat is howeverthat in such case you are on yourown as everythingthat is available out of the box uses the standard JavaScript-basedrendering.
Whetheryou are goingtouse search-drivenpublishing or notdepends a lot on your case. Either way the choiceforusing search-drivenpublishing is one of the first choicesthatyouwill have to make as it has huge impact on the whole project.First of all, on the functional level, search-drivenpublishingdetermineshowyou are goingtoorganizeyour content: are yougoingto store the content in the same Site Collection or are yougoingtousecatalogsandifso, where are theygoingtobelocatedandhow the publishingprocess is goingto look like? Next you will have to decide for navigation and how that will be organized.From the technicalperspectiveyouwill have todecidehowmany Site Collectionsyouwillneedandhowitwill impact your solution architecture. Also, ifyouwillneedtodeploy files across the different Site Collectionshowwillyouensureforconsistencyonce in production?Search-drivenpublishing offers greatpossibilities but forthisitrequires proper configuration. Ifyou want touse search in your solution besurethat the environment will support the additional load comingfrom search.Last but notleast, SharePoint 2013 Search is verypowerful but it has tobeinstructedwhatyou want itto do. The easy stuff is self-explanatory. There is howevermuch more thatyoucanuse but first willneedtolearn.For the remainder of thispresentation we willassumethat we are using search-drivenpublishingtoillustrate different capabilitiesandchallengesrelatedtothat model.
A particular scenario of search-drivenpublishing is cross-site publishing:It is a content publishing model based on SharePoint 2013 SearchThe content is stored in list or librariesBecause the content is stored in a flat list in order todefineitshierarchyyou have touse a Managed Metadata field
Determine publishing method and architecture: Contains a decision flowchart to help determine which publishing method you should usePlan logical architecture for cross-site publishing: Introduces the different architectural components that you need to consider when using XSP: web application, authoring- and publishing site collections, assets libraries, searchPlan authoring sites for cross-site publishing: Introduces components that you need to consider for your authoring site: site structure, security, design & branding, tagging term sets, catalog content.Plan publishing sites for cross-site publishing: Introduces components that you need to consider for your publishing site: site structure, security, design & branding, catalog connections, navigation term sets, showing catalog contentPlan search for cross-site publishing: Introduces components that you need to consider for your authoring site: content sources and crawling, managed properties, refiners & faceted navigation, result sources & query rules, analytics & recommendations
Describes the elements involved, benefits, use cases and limitations of using managed navigation
Mobile devices overview: Describes mobility features and browsing experiencesPlan for mobile views: More detailed description of the browser esperiences
Describes how to identify the source and target variations sites, and how to decide how content should be synced on the target variations sites.
Team work: versioning, workingsimultanously on the sameassetsWorkingspace availability: deploying stuff to server bringsit down, search index resetPlatform hygiene: shared environment for building public-facing websitesIrreversible mistakes: creating a Site Collection in a wrong languageSyncing: consistent branding across the different languages
Consolidate: mavention.com homepage: 1 item of each type, but one search query
Estimate capacity and performance for WCM: Describes the number and type of computers needed for deploying SharePoint 2013 WCM solutions (includes a test results from a scenario that measured throughput, server response time and content freshness for a publishing web site with 5 million pages or items).