Search Engine Optimisation (SEO) for SharePoint Sites – Part 3

In Search Engine Optimisation (SEO) for SharePoint Sites – Part 1 of this series I looked at the implications content, naming, metadata and structure of your SharePoint site can have on search rankings. Search Engine Optimisation (SEO) for SharePoint Sites – Part 2 focussed more on how content can be manipulated to improve search rankings and other factors that can be leveraged from within SharePoint. This article will take a step outside the SharePoint box into how you can boost rankings and traffic to your SharePoint site using other methods.

Link Back to your Site

Along with creating quality key-phrase rich content to be indexed, having a solid link building strategy is a major factor in terms of search engine optimisation. A link strategy should emphasise quality over quantity. It should be broad and diverse. It’s important to note that value is gained both by linking out to other high-value related sites and especially by having those sites linking back to your page. As far as SharePoint is concerned, this theory is fairly independent of the platform. Due to SharePoint’s nature however and the limitations which exist when optimising a SharePoint site for search engines, the traffic generated by backlinks should be as strongly valued as the SEO benefits gained. You need to think outside of the box when approaching this strategy. Often, having other pages linking back to you is largely out of your control, however other areas are well within it. Ensure your site or pages are listed in all relevant directories. If it makes sense to do so, ensure your location exists in Google Maps and link back to your site from there. Consider creating other content-rich sites such as specific (clean-cut HTML rather than SharePoint) search engine optimised sites or blogs to link back to your site. It’s also important that the phrases used to hyperlink back match that which you are optimising for, similar to the advice given in the section above.

Don’t Ignore Social Media as part of an SEO Strategy

Social Media is another area where you can gain an increase of traffic and some SEO benefits for your SharePoint site, although the concept is removed from the platform. Facebook, Twitter, Linked In – any relevant social media site should be harnessed to both link back to your site and drive traffic to it. The benefits of the latter probably outweigh the former – I’m not entirely sure that any SEO benefit is gained from having your links on these sites. Google+ however could be considered one social media platform that can be harnessed for the purposes of SEO as identified in Christian Del Monte’s post Google+ Plus SEO Benefits- Tips To Make It Work For You.

Create a Specific Mobile Site

Aside from being good practice to cater for the ever-increasing mobile device visitors to your site, it’s been noticed that the results returned from within search engines on mobile devices may be tailored to that device. This seems to be an area of contention – reading Ryan Jones’ article Mobile SEO is a Myth would lead you to believe it’s not important however Bryson Meunier’s How To Best Optimize Your Mobile Site For SEO argues it is worthwhile, and seeing Google is Introducing smartphone Googlebot-Mobile, it’s not something I’d want to discount.

Consider Paid Search Marketing

This is another debatable topic. It depends more so on the site in question and it’s purpose. It really only makes sense to use for a commercial site in my opinion. If your site is selling something and you can target a paid advertisement it is likely to be clicked. If you’re peddling information and you show up as a paid advertisement you’re unlikely to get the same response. For the benefits of paid search marketing have a read of the Top 10 Reasons to Use Paid Search Marketing by Vinny Labarbera. It may not have a lot to do with SEO, but its a method which can be leveraged to drive visitors to your site, especially if the site is new and not appearing in many organic search results.

Ensure you Submit your Site to ALL Main Search Engines

It should go without saying, yet a number of sites will only target the large search engines such as Google, Bing and Yahoo and forget about the others. A quick search for Search Engine Market Share at the time this article was written showed that search engines other than these big 3 had 12.2% of the market share. Granted the majority of that is a Chinese based search engine which would leave less than 1% market share but with over 2.2 billion internet users worldwide, you’d be discounting over 20 million potential visitors to your site. The logic may be flawed, but personally I think it’s not worth the risk – submit your site where ever a potential visitor may see it.

Use all the Tools at your Disposal

There are a tonne of free tools and sources of information available on the web to assist in optimising your site for search rankings. One such tool is the IIS SEO toolkit. Other resources include the infinite number of SEO specialisation sites and blogs available free of charge to garner a wealth of information from. By keeping track of the changes and trends in search engine optimisation you’ll always be one step ahead of the competition.

Monitor how Visitors are Reaching your Site

It’s important that SEO is not considered a one-time event. It should be an ever-evolving function of your site and needs to change with the times. One way to identify what works and what doesn’t is to use analytics on your site to determine how users are finding your site, where they’re coming from, what search terms they’re using and how they end up navigating around your site. The more information you have at your disposal to influence the direction of your SEO campaign the more likely it will be a success.

Returning Visitors are just as Important as New Ones

The final point I wish to make in this ‘outside the box’ look into SEO for SharePoint is a simple one. It’s one thing being able to attract visitors to your site in the first place, but of little worth if they fail to stay on the site or ever return to it. The user experience of the site is just as important as the quality of the SEO or campaign that drew them there in the first place and should not be lost in the quest for search ranking supremecy.

How the Career Centre mobile site was built using SharePoint

I’ve recently had the pleasure of working on a large public facing portal solution for the Career Centre. I came onto the project midway through so inherited a lot of branding and functionality, however early enough to create a number of components from scratch, having an input into the design and implementation decisions along the way. One such piece of functionality was the mobile site which can be accessed on your phones by clicking the link above, or in your browsers by accessing the mobile site directly.

The reason for this post is that it hasn’t been done exactly the way one would imagine. I thought I’d take the chance to explain the decision process behind the implementation and potentially open the lines of discussion on whether the decisions made were valid, based on false logic or whether there was a better solution available. For the purpose of context the Career Centre portal was developed on MOSS 2007 Enterprise Edition.

We’ll start with the requirements. The mobile site design had been provided to us so barring some minor tweaks, was not something that required a large amount of attention. The content of the site was to be a sub-set of the live site; a combination of landing pages which were to differ from the live site, content pages which mirrored the live site exactly, content pages which either differed from or didn’t exist in the live site, ‘multi-part’ content pages (based on a custom page layout) and functional aspects of the site (including but not limited to various search capabilities).

My thoughts were that with a custom master page, mobile-specific page layouts and mobile-specific controls and web parts, the majority of requirements would be easy enough to satisfy, and that largely turned out to be the case. My main concern was with content and ensuring the most efficient solution without resorting to content duplication, and the thought process behind that is what will form the basis of this post.

I had a fair understanding already that the ‘best practice’ way of implementing a mobile site in SharePoint was to leverage the variation capabilities of the product. Some initial research I performed backed up that presumption; the most impressive post I personally found for the topic was Jamie McAllister’s discussion on Exposing your MOSS WCM to Mobile Devices. I’d had some brief exposure to SharePoint variations from my time at TourismWA on westernaustralia.com. There, variations were used for the purposes of multi-lingual sites (the complexity of that implementation is definitely worthy of a post on its own!). I was therefore already hesitant to embrace this functionality for my purpose.

Some extra research I did around variations did little to calm my nerves. Some of the more relevant posts I read include Jamie McAllister’s Do MOSS Variations really SUCK, Alex’s Common Problems with MOSS Variations and Jeremy Jameson’s Dumping MOSS 2007 variations Part 1, 2 and 3. There were a bunch of other negative posts I read that escape me now. For the sake of balance, Stefan Goßner’s series on the Variation Feature should also be read.

My main concern however was that changing a page’s layout from the initial site’s to the mobile-specific layout would cause a variation and hence no longer receive content updates; funnily enough, this proved a non-issue. Through my experimentation however I did come up with a raft of other concerns including;

  1. A variation required the source to be a sub-web of the root – which means we couldn’t have careercentre.dtwd.wa.gov.au, it would have to be careercentre.dtwd.wa.gov.au/careercentre or something to that effect. The varied site would then also be a sub-site like careercentre.dtwd.wa.gov.au/mobile. This may seem like a small issue – but the URL of the site definitely was no small issue for the client.
  1. You can set up variations initially so that they auto-populate the varied site when new sites/pages are created, or you can set them up so they do not. We would have needed to turn that off considering the mobile site was to be a small sub-section of the main site. Problem being, once that feature was turned off we would then have to manually build up any new site structure to match. Once the variation hierarchy has been created automatically it can’t be done again.
  1. When I automatically created this hierarchy, it seemed to pick and choose which pages it recreated. I noticed only 2nd level sub-site pages where being brought across. I also noticed that for each site brought across, instead of recreating the default page it created a new default welcome page. This was obviously a huge concern, and would amount to a fair degree of manual labour to get it all up and running initially.
  1. Lists don’t get brought across and can’t be considered linked-up varied content. That means all the lists (that we needed for the mobile site) would need to be created in the mobile site manually and a process set up to copy content across in the event it was added or changed. This was more programmatic work that we were trying to avoid due to time constraints. (If this is a concern of yours have a read of another of Jamie’s posts)

For these reasons along with the research I had conducted and my own prior bias, rightly or wrongly I decided to turf the idea of using variations and proceeded to investigate an alternate solution.

Thanks to a huge degree of good fortune I had only days before been playing around with the Content Query Web Part along with CommonViewFields and styling with ItemStyle.xsl. I decided to leverage this functionality and the result was instant. I exported the Content Query Web Part and redeployed it under a different name to include the CommonViewFields of PublishingPageContent,HTML; and all fields associated with my ‘multi-part’ page layout. Important to note is that when used on the page and after pointing it to the relevant Pages library the page to copy exists in, an additional filter of Title equal to the current page’s title needed to be set – in hindsight I could have created a new web part overriding the content query web part to set this filter and the CommonViewFields automatically.

I then edited the ItemStyle.xsl file to include templates for all the fields listed in CommonViewFields:

<xsl:template name="PageHTMLOnly" match="Row[@Style='PageHTMLOnly']" mode="itemstyle">
    <xsl:variable name="DisplayTitle">
        <xsl:call-template name="OuterTemplate.GetTitle">
            <xsl:with-param name="Title" select="@Title"/>
            <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
        </xsl:call-template>
    </xsl:variable>
    <xsl:value-of disable-output-escaping="yes" select="@PublishingPageContent"/>
</xsl:template>

Only 2 issues remained; firstly, all in-content links pointed to the non-optimised pages regardless if a mobile-optimised page existed and secondly, users weren’t being warned if they were being taken to an un-optimised page within the site. jQuery to the rescue.

To ensure mobile-optimised pages were linked to appropriately, I included the attribute class=”mobilelink” on all hyperlinks that needed it. The following jQuery took care of the rest:

$('.mobilelink').attr('href', function (index, val) {
  var returnVal = val;

  if (val.toString().toUpperCase() == '/CAREERPLANNING/KNOWINGYOURSELF/PAGES/KNOWINGYOURSELF.ASPX')
    returnVal = '/mobile/careerplanning/pages/knowingyourself.aspx';
  else if (val.toString().toUpperCase() == '/PAGES/CONTACTUS.ASPX')
    returnVal = '/mobile/contactus/pages/contactus.aspx';
  else if (val.toString().toUpperCase() == '/HOWWECANHELP/PAGES/HOWWECANHELP.ASPX')
    returnVal = '/mobile/pages/howwecanhelp.aspx';
  else
    returnVal = '/mobile' + val;

  return returnVal;
});

It would have been a little neater had the mobile site structure mapped more accurately to the live site structure, but never mind.

To ensure users were warned if they were about to enter a non-optimised page, jQuery Dialog was harnessed:

<div id="dialog" title="Confirmation Required">
  You are about to leave the mobile-optimised site.<br /><br />
  Would you like to continue?
</div>
$("#dialog").dialog({
  modal: true,
  bgiframe: true,
  width: 280,
  height: 185,
  autoOpen: false
});

$("a").filter(function (index) {
  var theHREF = $(this).attr("href");
  return theHREF != undefined &&
  theHREF != null &&
  theHREF != "" &&
  theHREF.toUpperCase().indexOf("JAVASCRIPT:") == -1 &&
  theHREF.toUpperCase().indexOf("/MOBILE/") == -1 &&
  theHREF.toUpperCase().indexOf("TEL:") == -1 &&
  theHREF.toUpperCase().indexOf("MAILTO:") == -1 &&
  theHREF != "#" &&
  theHREF.charAt(0) != "#";
}).click(function(e) {
  var theHREF = $(this).attr("href");
  var target = $(this).attr("target");
  e.preventDefault();

  $("#dialog").dialog('option', 'buttons', {
    "Confirm" : function() {
      if (target != undefined && target == "_blank")
      {
        window.open(theHREF, target);
      }
      else
      {
        window.location.href = theHREF;
      }

      $(this).dialog("close");
    },
    "Cancel" : function() {
      $(this).dialog("close");
    }
  });

  $("#dialog").dialog("open");
});

The end result was a mobile site that needed to be created manually initially (but with little effort – my experimentation with variations concluded that I would have had to do the same if not more to get that working initially) but would largely be set and forget assuming the mobile site structure didn’t need to change. Content updates would be instant rather than relying on the synchronisation process between the source and varied page. We were also able to maintain the ‘root’ URL of careercentre.dtwd.wa.gov.au by not requiring the source variation site to be created.

The last remaining problem was getting there. Seeing we hadn’t harnessed variations, we didn’t have the VariationRoot page to direct browsers to the mobile version of the site. Instead I ensured the default page of the root site had a web part on it that contained the logic to perform the redirect courtesy of Detect Mobile Browsers.

So there we have it. A result not particularly conforming with stated best practices however one the client is stoked with and should prove easily maintainable and effective. I’d be particularly interested to hear about other ways in which mobile sites have been created in SharePoint and anyone’s experience using SharePoint variations for that purpose.

Follow

Get every new post delivered to your Inbox.