Search Engine Optimization for SharePoint 2013 Sites (Part II)

searchengineoptimziation.xml

SEO features in SharePoint 2013 are bundled into a SearchEngineOptimization feature. Its feature.xml file references two element files - searchengineoptimization.xml(SEO.xml) and searchengineoptimization1.xml(SEO1.xml). SEO.xml defines elements that make up its UI by extending ribbon interface. It also registers few candidate web controls with AdditionalPageHead delegate control. Delegate control is a powerful mechanism to alter application behavior declaratively. One or more candidate controls are added to control tree dynamically based on the sequence number(lower sequence number will be added first) depending upon the configuration of a delegate control. All web controls are defined under Microsoft.SharePoint.Publishing namespace. SEO.xml also adds an SEOSettings application page(_layouts/15/SEOSettings.aspx) where you can configure canonical URL and verify site ownership.  SEO1.xml defines all SEO properties for page such as browser title, meta description, sitemap priority, sitemap change frequency as site columns. It means you can access these fields pragmatically like any other site columns. Note that "Sealed" property for all fields is set to true which means that they aren't extensible.

searchengineoptimziation1.xml

Another SEO feature, XmlSiteMap, adds XmlSiteMapSettings application page(_layouts/15/XmlSiteMapSettings.aspx) where you can specify paths not be crawled by search engines. Anonymous access must be enabled for the web application to generate Sitemap otherwise following message will be displayed on the page.

Sitemap Timerjob

     

When XmlSiteMap feature is activated, it registers the site collection with Search Engine Sitemap timer job which runs daily by default. Of course, you can run this timer job anytime like any other time job and configure its frequency. When run, it generates the XML site map for the site collection and adds it to robots.txt. In process, it reads sitemap priority, sitemap change frequency and other fields of pages and includes them in the sitemap.

Read More

Search Engine Optimization for SharePoint 2013 sites

SharePoint 2013 introduces several new WCM capabilities and one of the addition is native support for SEO(Search Engine Optimization). In absence of any native support for SEO in earlier versions, developer community relied on custom solutions. However with out-of-box SEO capabilities in SharePoint 2013, now you can

• Configure Canonical URLs
• Verify site ownership with web master tools of search engines
• automatically generate Sitemap for your site
• Add and edit SEO metadata for pages with SharePoint ribbon interface
• Add SEO properties for a manged navigation
• Alter priority and change frequency for individual page

Canonical URL Configuration and Site ownership verification

SEO capabilities are available only for publishing sites and activated during publishing feature activation. To configure SEO, go to Site Settings -> Site Collection Administration -> Search Engine Optimization Settings. Search engines often references the page content with its URL. This means if two URLs refer to the sam content, content will be indexed twice. SharePoint 2013 allows you to configure canonical URLs(In SEO world, the URL that uniquely represents a content is called Canonical URL) so duplicate indexing can be avoided. It also helps consolidate popularity of content represented by multiple URLs which would be tracked separately otherwise.
Sometimes the same URL can render different content depending upon the query string parameters present. The SEO settings page allows you to add such query string parameters into Filter Link Parameters list which essentially tells a search engine that parameters in this list can influence search results.

SEO settings page also lets you verify your site ownership with search engines. Typically you sign up with the web master tools of your search engine and copy provided meta tag and paste it on SEO settings page. There are several other methods to verify site ownership but this is the most popular among all and SharePoint supports it.

For instance, Meta tag for Bing  -  <meta name="msvalidate.01" content="... Meta tag for Google -  <meta name="google-site-verification" content="

Sitemap Generation

When XML Sitemap path is specified in robots.txt, search engines use it to further discover content on your website. In absence of native support in earlier versions, developers built custom solutions to generate Sitemap which will periodically iterate through all sites and pages. In case of small, less frequently changing sites, Sitemaps were manually created and maintained. In SharePoint 2013, automatic Sitemap generation can be turned on by activating Search Engine Sitemap feature at site collection level. Activating it registers a site collection with Search Engine Sitemap timer job which generates a Sitemap when run and updates robots.txt with its path.

SEO Properties

With SharePoint 2013 SEO, you can add SEO metadata to your page right from browser interface. Out of all most notable fields are, Sitemap priority - Not all pages in your site are of equal priority. You can specify priority on scale of 0.0(low) to 1.0(high) which will be taken into account when Sitemap is generated. Sitemap change frequency - some pages change frequently while others such as news release don't. This field like previous filed is used during Sitemap generation and allows you to set the frequency from hourly to never. This will help search engine learn how often content on the page changes. Exclude from Internet Search Engines - If set, exclude a page from Sitemap file.

Other fields you can set are,

BrowserTitle - Title in the browser title bar MetaDescription - Appears in search results as description next to the URL. However it is never used by search engine to calculate rank Keywords - Keywords are widely abused by traffic redirection web sites and never used by major search engines as they often don't represent the content on the page

SEO in Managed Navigation

SharePoint 2013 allows a term set representing logical hierarchy to be used as site navigation. When using manged navigation, you can specify SEO properties for a term. Manged  navigation yields SEO friendly URLs. A URL doesn't have .aspx extension and /Pages in it. Also accessing default page for the site doesn't result into HTTP redirection(HTTP 302) anymore.   Go to Site Settings -> Site Administration -> Term Store Management and select a term from the left to access its SEO properties under tab Term Driven Pages

      Please keep checking this space for the second and final part in SEO series where I will be discussing architecture and internals of SEO.

Read More

SharePoint 2013 - Farm and App level ECTs in BCS

SharePoint 2013 introduces the concept of App level External Content Type(ECT) which allows model representing external entities to be packaged along with app in single unit so later it can be accessed by app to understand and integrate external data without outer dependencies.

External Content Types(ECTs) and External List - BCS(Business Connectivity Services) is an umbrella term in SharePoint referring to functionalities and activities for modeling, management and manipulation of external data. Schema of an external entity or business concept is represented in SharePoint by an external content type much like a content type describes native SharePoint entities. External List can then hold items of specific external content type, again the way List can have items of one or more content types. The major difference is External list can contain items of only one external content type.

What is inside BDC model?
Business Data Connectivity(BDC) model primarily contains information about,

1. How to connect to external data source
2. How to translate credentials if the user has a distinct identity in external system
3. Metadata of one or more external entities

Farm and App Level External Content Types in SharePoint 2013

Farm Level vs App Level ECTs - In SharePoint 2010, model representing one or more ECTs, called BDC(Business Data Connectivity) model is stored in a relational database, called BDC Metadata Store. However this metadata store isn't directly accessibly and managed by BDC service application. Adminsitrator or someone who has an access to Central Administration web site must upload the model and then it is available to any web application configured to use that instance of BDC service application. ECTs represented in such a way are called Farm Level ECTs.   Farm level ECTs works great for farm solutions and sandboxed solutions but not for apps in SharePoint 2013 as app is an isolated, compartmentalized unit and all data that app accesses including BDC model must be packaged along with it in a single unit so later it can be deployed to catalog or SharePoint Store without any external dependencies. App level ECT in SharePoint 2013 solves that problem. Here is how it does: For Apps, model is stored in a file in a document library rather than in BDC metadata store. SharePoint then leverages less known feature FileBackedMetdataCataog, first introduced in SharePoint 2010, to read metadata from this file into in-memory BDC runtime which can be read by an external list. Like BDC server runtime, this BDC runtime can connect to variety of data sources through out-of-box connectors such as SQl Connector, Web services connector and OData connector. Custom connectors and .net assembly connectors cannot be used along with this runtime and hence with App level ECTs. This may sound limiting but actually it is consistent with overall App idea which doesn't allow any custom code to run on SharePoint server. App Level ECTs

• Allows granular isolation of external content types for an App
• An app can have only one BDCM file and that is referenced in ListInstance definition by MetdataCatlogFileName property.
• Doesn't need an access to BDC service application

App level ECTs empower a SharePoint App to access and manipulate publicly available data sources without any configuration on the consumer's part. App can work with external data right after it is installed.

Read More

Client data access with OData and CSOM in SharePoint 2013

SharePoint 2013 has improved OData support. In fact, it offers full-blown OData compliant REST based interface to program against. For those who aren't familiar with OData, OData is an open standard for querying and updating data that relies on common web standard HTTP. Read this OData primer for more details. The obvious benefits are: 1. SharePoint data can be made available on non-Microsoft platforms and to mobile devices 2. SharePoint can connect and bring in data from any OData sources

Client Programming Options: In SharePoint 2010, there were primarily three ways to access SharePoint data from the client or external environment.  

1. Client side object model(CSOM) - SharePoint offers three different set of APIs, each intended to be used in certain type of client applications.

• Manged client object model - for .Net client applications
• Silverlight client object model - for client applications written in Silverlight
• ECMAScript(JavaScript) object model - for JavaScript client applications

Each object model uses its own proxy to communicate with the SharePoint server object model through WCF service Client.SVC. This service is responsible for all communications between client models and server object model.

2. ListData.SVC - REST based interface to add and update lists.

3. Classic ASMX web services - These services were used when parts of server object model aren't available through CSOM or ListData service such as profiles, publishing and taxonomy. They also provided backward compatibility to code written for SharePoint 2007.

4. Custom WCF services - When a part of server object model isn't accessible through all of above three options, custom written WCF services can expose SharePoint functionalities.

Architecture:

In SharePoint 2010, Client.svc wasn't accessible directly. SharePoint 2013 extends Client.svc with REST capabilities and it can now accepts HTTP GET, POST, PUT, MERGE and DELETE requests. Firewalls usually block HTTP verbs other than GET and POST. Fortunately, OData supports verb tunneling where PUT, MERGE and DELETE are submitted as POST requests and X-HTTPMehod header carries the actual verb. The path "/_vti_bin/client.svc" is abstracted as _api in SharePoint 2013.

CSOM additions: User profiles, publishing, taxonomy, workflow, analytics, eDiscovery and many other APIs are available in client object model. Earlier these apis are available only in server object model. ListData.svc is still available mainly for backward compatibility. 

Atom or JSON response - Response to OData request could be in Atom XML or JSON format. Atom is usually used with managed clients while JSON is the preferred format for JavaScript client as the response is a complex nested object and hence no extra parsing is required. HTTP header must have specific instructions on desired response type otherwise it would be an Atom response which is the default type.

Read More