Responsive Web Design v Device Channels in SharePoint 2013

With the introduction of Device Channels in SharePoint 2013, and 2013 having been dubbed the ‘Year of Responsive Web Design’, the question is often posed which method is the right one to enable a mobile experience on your SharePoint-hosted public facing website.

This post will briefly explore what both options entail and run through some of the benefits and limitations of using either method. By the end you should be confident in choosing a road forward for your mobile-optimised implementation.

Responsive Web Design (RWD)

RWD at its core relies on grid layouts, media queries and CSS to alter the display of a web site based on the width of the browser accessing that site. Depending on the number of widths targeted via the queries, a web site’s display can be made to differ on large desktop screens, tablets and mobile devices so they render in an optimal fashion no matter the viewing platform.

The main benefit of RWD is that no matter what the device width, the site will display in its optimal (or nearest-to-optimal) form. Given the large number of device widths that already exist, and this likely to only exponentially grow in the future, the method can be considered largely future-proof.

The method is also search engine friendly. Search engines prefer a URL to always render the same HTML and utilising RWD achieves this.

RWD however does not come without its faults. Its biggest drawback is what enables that SEO-friendly approach – the fact that the HTML served is the same. This means that while images or sections may be hidden in the CSS, the resources will still be served to the device which is not an optimal approach when targeting low-bandwidth mobile devices. It also provides a less flexible approach to targeting a given device allowing less options for modifying the display.

On top of this, RWD can often be costly to implement in terms of the number of tweaks and regressions required when targeting different browser widths. Todd Baginski and Michael Sherman in their SharePoint Conference session SPC390 stated that they anecdotally noted that 25% of developer time was spent dealing with such requirements.

Device Channels

Device Channels in SharePoint 2013 rely on targeting the device accessing the page and serving up customised HTML based on the device which will be rendering the content. This ensures that you can provide a completely customised user experience depending on whether the user is on a desktop, tablet or phone. You could even go as far as serving up different content depending on the type of device (iPad, Surface, Android for instance).

This option therefore comes with a number of advantages. It negates the main drawback of the responsive designs – HTML can be served in a manner which completely optimises the page load for the device being targeted. A desktop version could be highly interactive and visual, serving large images where the mobile experience could be lightweight for improved performance.

It also offers far greater flexibility in terms of the designs you can render to the different devices. Rather than relying on the same HTML and grid-based flows, you have the opportunity to structure the HTML rendered in any manner you desire, providing the capability to have far more interactive experiences on the desktop compared to mobile devices.

The disadvantages of this approach again mirror the advantages of the responsive approach. As has been previously stated, search engines prefer the HTML being rendered at a given URL to be identical, however device channels serve up different content at the same URL for different devices.

There is also a limit to the number of devices which can be targeted, meaning the coverage of designs would be less compared to the potentially limited coverage of a responsive design.

Another drawback of the device channel approach is that it is even more limited when it comes to hosting public websites on Office 365. Only 2 device channels are available there, a default channel and a mobile ‘catch-all’ channel, meaning the flexibility to target different devices is reduced greatly.

For an example of how device channels can be used to implement a mobile site on SharePoint, view my previous post How my latest mobile-optimised site was built using SharePoint 2013.

Which is the best option for you?

As should be becoming clearer, there is no ‘best practice’ approach when it comes to making the decision between responsive designs and device channels in SharePoint 2013. There are advantages and disadvantages to both and a number of other factors may end up affecting the decision.

If you’re dealing with a design company to provide the site design, particularly if this process happens before the SharePoint team gets involved, the decision may be made for you. It is common for design companies to provide completely different HTML templates for standard sites and mobile-optimised sites and that immediately lends itself towards device channels. It could also be more cost effective to receive one responsive design from a design company rather than multiple device-targeted designs which could also impact the decision.

If you’re dealing with a team that will be responsible for both the design and implementation, then the decision may come down to the flexibility required for the site design and weighing up the approaches outlined above to choose the one that best suits the goals of the site.

The Hybrid Approach – a better way forward

There is an option available which provides the best of both worlds and is particularly appropriate when hosting public sites on Office 365 – the hybrid approach. This involves utilising device channels to target particular devices, but ensuring the designs within them (or at least some of the smaller devices) are responsive for the different browser widths which may be encountered. It may not be the most cost-effective approach available however it would definitely be the most effective from a user experience point of view.

 

Note – As this post was written in a very different manner to my usual blogging style, I failed to properly work in the references I had read in researching this topic into the post itself. As such, i’ve included them below for prosperity:

Device channels v/s Responsive web design by Prashanth BS

Responsive Web Design vs. Device Channels by Jean Paul

Responsive vs. Adaptive Web Design – What about Device Channels? by Stefan Bauer

Digital Design Shift: From Mobile to Multichannel by SiteCore (must register)

Advertisements

Implementing redirects when upgrading a site to SharePoint

Late last month we launched the best site i’ve ever had the pleasure of working on, Education + Training International (ETI). The pure size and scope of the site, particularly everything which drives it behind the scenes, is something which everyone who has worked on (and will continue to work on) it should be proud of. Having taken the site from inception to launch, the number of hurdles we came across along the way would be enough to fill this blog for the year. This post will touch on just one small aspect of it – ensuring that the URLs from the old site accurately redirected to those in the new.

I actually touched on this topic in some sense a couple of years ago in my post 301 vs 302 Redirects in SharePoint so it was good to get the opportunity to revisit it again, explore options and implement a solution. This post is quite long, so I’ve broken it up into headings outlining what is being discussed – feel free to skip ahead to what interests you.

Requirements and Caveats

There were 2 main considerations for requiring the redirects (and we wanted all URLs redirected – there wasn’t a ridiculous number we’d need to handle – around 130 or so). First and perhaps most importantly was user experience. The last thing I wanted was for our users to be consistently hitting a generic 404 page. The other consideration was for Search Engine Optimisation – ETI had previously invested in SEO on their existing site and we did not want to lose those search engine gains which had been realised.

There was a caveat to the decision making process (isn’t there always). The infrastructure team was not prepared to take on the burden of managing the redirects and had reservations anyway around the feasibility of managing them at the reverse proxy level.

I also personally wanted to avoid any manual deployment steps both out of principle and for disaster recovery and future maintenance reasons – those kinds of steps are often lost over time as people leave and documentation becomes outdated and ignored.

Finally, ideally the process would be able to be managed down the track, preferably through a SharePoint list within the site.

Rejected Solution #1 – custom web part on PageNotFound

My first investigation centred around the concept of placing a custom web part on the 404 PageNotFound page (having easy, editable access to this page from within SharePoint is a great improvement over previous versions). The idea was that a list would exist which managed the old URLs and the mapping to the new URL, if the ?requestUrl= found a match, we’d serve up a 301 redirect to the new URL, otherwise we’d provide the next best thing – perhaps a search within the site for some of the terms within the URL. The user experience was actually seemless with this approach, however a quick look at Fiddler showed that the 404 response was still served before my code hijacked it and served up the 301, meaning the search engines would assume the pages were gone. Back to the drawing board.

Rejected Solution #2 – storing URL rewrite mappings in a separate file

It was at this point that I gave up on my desire to have a user-editable list of redirects (perhaps prematurely). Our specific requirement was simply to redirect the old URLs to the new, future redirections were more of a nicety I was trying to provide. I knew a bit about managing redirects in IIS (I referenced Jeremy Thake’s post How we did it: 301 Redirects in IIS 7.5 on Windows Server 2008 R2 in my previous blog post) so figured I’d explore that track (I did have some reservations about blowing out the web.config particularly in relation to the 250kb file size cap, so I intended to use Ruslan’s Storing URL rewrite mappings in a separate file – I figured this would also allieviate the ‘adminstrative burden’ of managing them through IIS). The approach worked great – I could manage a set of old URL/new URL pairs in a separate configuration file, but to avoid the manual deployment steps I’d want it managed and deployed via our solution.

Unfortunately, that separate file had to exist along side the web.config in the IIS virtual directory for the site. I wasn’t able to reference an absolute path and deploy my configuration file somewhere within the SharePoint layouts directory. I investigated the ability to Deploy Files to SharePoint Web Application Virtual Directories At Feature Activation via Brian Jackett but the noted flaws in that system and the complexity around it quickly turned me off. Back to the drawing board.

Implemented Solution – writing URL rewrite mappings to web.config via feature

My next approach was to take a look at managing the redirects within the web.config itself. I did have concerns regarding blowing out the file and the maximum size limit for it – but tests soon proved that we wouldn’t even get close to that figure, so it wasn’t as much of a concern as I had made it out to be. So this approach worked fine too, the challenge was to remove the manual administration/deployment steps out of the process. Enter Using SPWebConfigModification to Update the Web.config in SharePoint 2013. I think i’ve explained how to do that reasonably well in that post (which i’ve also now updated to include some new information) so i’ll jump straight into some code snippets you can use in combination with that post.

            SPWebConfigModification modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer";
            modification.Name = "rewrite";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<rewrite />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite";
            modification.Name = "rewriteMaps";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<rewriteMaps />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rewriteMaps";
            modification.Name = "rewriteMap";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<rewriteMap name='Redirects' />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rewriteMaps/rewriteMap";
            modification.Name = "redirect-1";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<add key='/eti-overview/profile-of-education-training-international.html' value='/about-eti' />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite";
            modification.Name = "rules";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<rules />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rules";
            modification.Name = "rule";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<rule name='Redirect rule1 for Redirects' />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rules/rule";
            modification.Name = "match";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<match url='.*' />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rules/rule";
            modification.Name = "conditions";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<conditions />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rules/rule/conditions";
            modification.Name = "add";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<add input='{Redirects:{REQUEST_URI}}' pattern='(.+)' />";
            webApp.WebConfigModifications.Add(modification);

            modification = new SPWebConfigModification();
            modification.Path = "configuration/system.webServer/rewrite/rules/rule";
            modification.Name = "action";
            modification.Sequence = 0;
            modification.Owner = "ETIWebConfigModifications";
            modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
            modification.Value = "<action type='Redirect' url='{C:1}' appendQueryString='false' />";
            webApp.WebConfigModifications.Add(modification);

The only concerns I had left were around the performance implications of managing so many redirects within IIS/the web.config, but they were soon allayed via How to check for performance in URL Rewriting and IIS Rewrite Module rewrite map performance.

Was there a better option?

In the end I was pretty happy with the end result. I managed to take the burden off the infrastructure team (activating a web-app scoped feature is no significant task), managed to take the manual administrative steps (such as deploying files to specific locations which would need to be repeated if new WFE’s were added to the farm) out of the process and provided a seemless experience for the users while maintaining good SEO practices. The only thing I didn’t achieve was providing the user the ability to manage the redirects and I couldn’t help wonder if that was possible.

Thankfully I have the pleasure of working with someone who’s seen it all before and had a chance to try a few different approaches to this problem over time! Faced with this same challenge (but at a much larger scale), his solution was to create a custom IIS module which inspected the 404 requests going to the redirect page and converted them to 301’s, then a custom web part on that page did another 301 if it found an item in the old-new URL list, otherwise it wrote 404 to the response header for the nicely branded 404 error page.

The only downside to this approach I could see was the need to install the custom IIS module on each server – however is that really worse than having to install the IIS rewrite module on each server? Probably not. The approach also had a significant unexpected upside – by monitoring the analytics on the 404 page they were able to identify legacy links which were still being used across the web, and had the ability to redirect those to a new URL on the fly and provide ongoing functionality to redirect merged/renamed/moved pages on the ever evolving web site.

So hopefully this post has given you a few ideas regarding how to implement your redirects when upgrading a legacy site into SharePoint. As always there are pro’s and con’s to each approach but there are definitely options available to achieve a decent result to meet a number of different requirements.

Thoughts on the Salem™ Certified Practitioner Online Course

It’s been a while since I’ve completed a course for SharePoint, generally sourcing new knowledge myself from where ever I can get it. I recently however had the great opportunity to undertake the Salem™ Certified Practitioner online course and thought it worthwhile jotting down my thoughts on both the content and the course itself. In the interests of full disclosure it’s important to note that I was given this opportunity complementary for my contributions to the SharePoint community, particularly my writings around Governance in SharePoint, however it in no means came with the promise of a favourable (or any) review so I can assure you the following is written with an open and unbiased point of view.

I first came across Salem™ as a company when I stumbled across Step By Step Search Engine Optimization for SharePoint Internet Sites while reviewing existing material for my own series on Search Engine Optimisation (SEO) for SharePoint Sites. I was highly impressed that a lot of the content that I already knew and wanted to communicate through my writings was so well structured into a complete and sequenced approach to implementing the topic – its a book that I’ve recommended to a number of people already. It motivated me to read through all 150 pages of SharePoint Governance & the Seven Pillars of Wisdom (which it now seems is only available through taking the practitioner course) that I came across during my readings for the Governance series I mentioned previously – this again left me highly impressed with the methodical approach to the topic.

It’s therefore no surprise that I now find out that the whole premise behind the name Salem™ is that it represents a Structured and Logical Enterprise Methodology to approaching SharePoint implementations. To be honest it couldn’t have come at a better time for me personally – I was consuming a lot of great information but was struggling to identify how it could all be applied at a client (read: sell the ‘complete’ message rather than always approaching tasks with a specific focus). All of the presentations in this area tend to focus on a specific topic (for instance governance, adoption) which while they all have merit tend to be harder to sell to an organisation individually.

I’d go as far as saying that was the most valuable take away I received from completing the course. Even though Salem™ is a great delivery methodology and logical in its approach, more importantly it serves as a vehicle to sell the story of approaching SharePoint implementations as a complete and business-focused programme of work.

I found the framework itself to be very solid. From looking at it initially it wasn’t obvious how all the pieces would fit together, however after taking the course I’m comfortable that every piece to the puzzle is justified and covers the wide breadth of what SharePoint has to offer as a platform.

Salem™ is essentially broken up into 15 different business service modules which are often inter-related and positioned in the framework diagram for specific reasons. While I’d love to be able to show the diagram to better explain the process, you’ll have to take the course yourself to see how succinctly it encapsulates a complete body of work. The modules are divided into different channels which also have a logical separation, supported by a number of layers which remove the focus of technology and supporting concepts from the business services themselves (while still emphasizing their importance to the ‘whole’) – allowing you to focus in on a particular service and break them down through various workshops.

As you can probably tell, i’m quite a fan of the framework and find it hard to fault, so i’ll turn my attention to the course itself and the certification it enables. I’d highly recommend if you have an interest in these topics that you take the course yourself and discover what it has to offer.

There is a bunch of information regarding the course which is worth a look if you have an interest in taking it or finding out a bit more about what it is all about. The Genius! website has a short synopsis and video which explains what the course will contain (it is the introduction video to the course so you get a feel for what the video material will be like, and if you have super human eyes you may even be able to gain a sneak-peak into what the Salem™ diagram will end up looking like!) while if reading is more your thing then take a look at the course summary at The Independent which contains a great deal of information.

I found the course content to be well structured in terms of breaking up a huge amount of information into consumable parts. Most sections within the course contain an introduction text, slides, a video and associated study reading material – you’re then required to take a short multiple question test. I did have a number of suggestions to improve the overall aspects of the course (for instance including contextual notes in the slides, not providing the answers to the tests until they’re passed and explaining why particular answers within the tests were right or wrong) which was all taken on board and thoroughly explained – some was even already known and in the process of being adjusted. From what I could gather the small number of improvements I could see were already well on the way to being improved before I had mentioned them which is testament to the quality of the course in that it will continually improve.

I found the length of the course suitable – it covered off the information you needed to know in enough forms for it to sink in. I was also highly motivated at the start to consume the information which never faded throughout, also testament to the quality of the content. I’ve read that the course is meant to take roughly 40 hours however I managed to do it in less than half of that (granted I had already read the Governance book which shaved some time).

The one thing I did find is that the course left me craving more – particularly its minimal focus on breaking down each individual business service into separate workshops. Of course this is where the Master course comes in so it’s no great surprise this is the case – but i’d just warn that you should be prepared for the same desire and/or strongly consider purchasing one of the packaged course offerings for a cheaper price! I’m looking forward to the opportunity of completing both the Master course and the Presenting the Salem™ Framework Workshop Masterclass in the near future.

After completing the course you’re granted full membership of the World Association of SharePoint Business Strategists. I love the idea of the group and particularly as a way of grouping like-minded individuals, disseminating information and providing a code to work by, however i’m unconvinced such a group should be associated with one particular proprietary framework and also feel it would be given further significance if it was backed by Microsoft themselves. Those points aside, I admire the entrepreneurial mindset that identified the gap in the market and filled it initially and still consider myself a proud member!

If you’re left with any doubt about the quality of Salem™ then it’s worth having a read of Gartner’s Competitive Landscape: Microsoft SharePoint Consulting and Implementation Services, North America and Western Europe. While it is discussing it in the context of consulting services, it does give a strong insight into how a company like Gartner rates the framework itself. For another opinion on the Salem™ Certified Practitioner Online Course you can have a listen to Dell’s Simon Farquharson discuss his experiences with the course.

So that about covers it. I’d be happy to answer any questions anyone has about the framework or the course itself, and i’m sure Ian himself would be more than happy to do so as well going by how generous he has been with his time and replies to the questions I had – so feel free to fire away.

Building public facing websites on SharePoint 2013 – Part 2

Following on from my slides discussion at Building public facing websites on SharePoint 2013 – Part 1, this article will dive into the 4 demonstrations which accompanied the session.

Branding with the Design Manager

Before I started, I had performed the following steps:

  1. Took the home page template, moved all resources into the same directory and adjusted the links (resources could be stored anywhere really, this is how the examples generally have it)
  2. Removed any ‘form’ elements and replaced them with DIVs (these could be made functional later)
  3. Ensured the template was XHTML compliant
  4. Created a new web application with a site collection using the Publishing template

Using the Design Manager to create a custom branded Master Page:

  1. Click on the Design Your Site link on the welcome page or access it via the ‘cog’ which represents site actions and select Design Manager (this page gives you a wizard type interface to complete the process – however a lot of the steps are just information regarding how to carry out a particular step)
  2. The first step we’re interested in is uploading our design files and to achieve this we need to map the network drive
    1. Open File Explorer
    2. Right click on ‘Network’ and click ‘Map network drive’
    3. Connect to the Master Page catalogue (which is linked to on that page)
    4. Copy the entire design folder in there
  3. Once we’ve done that we want to publish all the files in SharePoint either by going to the Master Page gallery in Site Settings or using Manage Content and Structure (which has been removed from the Site Actions, you now have to go to Content and Structure in Site Settings or just type in the address manually)
  4. Back to Design Manager and Convert an HTML file to a SharePoint Master Page (select our html file and click insert)
  5. Click on the link to the new master page to open it up and see if there are any issues – note that the content placeholder is placed at the bottom of the HTML file
  6. Open up the HTML file again via the mapped drive and move the snippet to the right location – we can grab the placeholder main snippet and paste it where we want it to be, removing the temporary display div (you can see that a number of snippets have been inserted into the HTML file so it’s important not to mess around with them if you’re not sure of what you’re doing)
  7. Save the changes – that automatically updates the master page, we can now publish it and assign it to be the master page for our site
  8. View the home page – the master page has been implemented

A few other features I showed but didn’t delve into:

  1. You can create a linked page layout by going to Edit Page Layouts in the Design Manager and clicking on Create a page layout (if we go into our mapped drive we can see that the HTML has been created and can then edit that like we did the master page which will automatically update the layout)
  2. We also have the snippet generator which we can get to by opening one of our master pages and clicking the Snippets link (there’s a bunch of pre-defined snippets which you can customise and copy into your master page or layouts – you can also use the custom ASP.NET Markup snippet to insert pretty much anything you can think of including references to custom controls you’ve deployed)

A couple of things worth mentioning:

When I was first looking into the suitability of the design manager I weighed it up against the starter master pages Randy Drisgill creates (he has 2013 versions). I ended up going down that path for a number of reasons:

  • for highly customised sites the whole snippet generator function didn’t seem efficient
  • the source control and deployment story for the branding elements is less than optimal, even though you can export packages it’s easier to keep everything together in one solution
  • editing the HTML with all the snippets in there seemed more confusing, particularly for page layouts which are generally much more simple in VS
  • my general impressions were that the Design Manager was great for designers and that was its purpose – if you’re a SharePoint developer, the standard VS method of development was more efficient

However later when I was figuring out a bug which existed in an earlier version of the starter master pages (and still appears to be there), it became apparent that the master page generated from that process was almost identical to the starter master page – so in future I would use the Design Manager to create the initial Master Page, bring it into Visual Studio and take it from there.

Another thing worth mentioning is that if you are trying to peel back the Master Page to make it as minimal as possible, you may be tempted like I was to remove the AjaxDelta elements which exist for the Minimal Download Strategy which is unfortunately not available for Publishing Sites. SharePoint however relies on the one surrounding the main content placeholder to insert the web part property editing toolbar so make sure you at least leave that in (that was actually the bug in the early version of the starter master page). I also wouldn’t advise on removing the DIVs with the IDs s4-workspace and s4-bodyContainer unless you want to lose your scrollbars.

Managed Navigation & Friendly URLs

  1. Firstly you need to ensure that the Managed Metadata Service application is available for your web application as it is what drives the friendly URLs
  2. You also need to ensure that a default Managed Metadata Service has been selected – you do this in Central Administration (if this has been done before the web application is created then the site will use managed navigation by default)
    1. Go to Manage Service Applications
    2. Click on the Managed Metadata Service connection (the proxy) and click Properties
    3. Check the ‘This service Application is the default storage location for column specific term sets’ checkbox
  3. If your site is still defaulting to the /Pages/Page.aspx URL then you need to set up Managed Navigation as the default in site settings
    1. Go to Site Settings and the Navigation link
    2. Select the Managed Navigation options and create a term set and click OK (the Add new pages automatically and create friendly URLs automatically are selected by default – this can be changed if desired)
  4. Go back to the site and see that the URL is now in a more friendly fashion
  5. Add a new page from the site actions menu to see that it is automatically given a friendly URL to access the page by
  6. Go back into the Navigation settings where we can open the Term Store Management Tool and configure our managed navigation – if we select our managed navigation term set there are a few useful options which will come in handy for setting up the managed navigation for a site
    1. Custom Sort is particularly useful if you want a navigation order different to the default alphabetical
    2. You can move the terms around if you want a particular navigation structure other than what was created by default
    3. For a term which is acting as a container rather than a page itself you can select the Simple link or header navigation node type
    4. You may also want a particular page to not appear in the navigation – particularly pages like disclaimers and copyright statements etc – you can uncheck the Visibility in Menus options in these cases
    5. You have the ability to customise the friendly URL if you weren’t happy with the default value automatically assigned via the pages title
    6. If you’re creating the navigation structure after the fact for pre-existing pages, or if you create additional duplicate navigation for a page, you can set the Target Page for this Term to associate the term with the relevant page

3 major points I’ve come across when working with Managed Navigation:

  • If you’re creating a custom navigation control or using something like Waldek Mastykarz’ Templated Menu you’ll need to access the Global or Current NavigationTaxonomyProvider rather than the Global or Current NavSiteMapProvider. One issue to consider here as well is that because you can access the page via the friendly URL or the standard structured URL the taxonomy provider will only work if you accessed it via the friendly URL
  • If you’re editing content and want to link to your page, you should no longer use the Link from SharePoint option and browse to the page you want to link to, because it will use the structured URL in the link. Even though the page will load at this URL you lose the friendly URL when you visit the page and you also cause search engines to think there is duplicate content on your site if it can hit the page from 2 different URLs – so unfortunately you should only use the Link from address option
  • The third point is more of an annoyance than anything else, but I’ve noticed a lot if you do particular actions on a page such as editing the page properties, when you’ve finished that task you’re taken back to the structured URL rather than the friendly URL, so I think there are still a few kinks to iron out

Content by Search & Display Templates

In the network connection to the Master Page Gallery set up earlier there is a folder called Display Templates – depending on what sort of template you want to edit or create, in general you’ll find that for content by search web parts you’ll need to edit within the Content Web Parts folder and for search results you’ll need to edit within the Search folder.

You’ll see both HTML and JavaScript files within there – this is similar to the link between the Master Pages and the HTML files we saw before – you only need to edit the HTML file and the JavaScript will automatically be updated. Similarly so if you are creating a new display template then you just need to drop the new HTML file in there and the JavaScript will be automatically created.

The best technique I’ve found to work with these templates is to grab an existing HTML file, edit it to suit your needs then drop it back in to the folder. This will automatically create the JavaScript which you can then take and deploy in your solution.

What is important in this process is how you define the template within the feature – I’ve identified a subset of data that if you happen to leave out then your display template won’t appear for selection in the various web parts (this subset was discovered after some research following reading the thread How to deploy display templates via feature).

 <Module Name="SearchDisplayTemplates" Url="_catalogs/masterpage/display templates/search" Path="Display Templates" RootWebOnly="TRUE">
    <File Url="Item_ETI.js" Type="GhostableInLibrary">
      <Property Name="Title" Value="ETI Item" />
      <Property Name="TemplateHidden" Value="FALSE" />
      <Property Name="TargetControlType" Value=";#SearchResults;#" />
      <Property Name="DisplayTemplateLevel" Value="Item" />
      <Property Name="ManagedPropertyMapping" Value="'Path'{Path}:'Path','Title'{Title}:'SeoBrowserTitleOWSTEXT','ETIDescription'{ETIDescription}:'ETIDescriptionOWSMTXT'" />
      <Property Name="_ModerationStatus" Value="0" />
    </File>
    <File Url="Control_ETI_HelpAndAdviceSearchResults.js" Type="GhostableInLibrary">
      <Property Name="Title" Value="ETI Help and Advice Search Results" />
      <Property Name="TemplateHidden" Value="FALSE" />
      <Property Name="TargetControlType" Value=";#SearchResults;#" />
      <Property Name="DisplayTemplateLevel" Value="Control" />
      <Property Name="_ModerationStatus" Value="0" />
    </File>
  </Module>

When taking a look at the elements file snippet above which deploys the templates you can see the subset of data which is required. The target control type and display template level are both quite important fields as they determine where the template is available to select within the web parts, for instance a SearchResults Item template will be available from within the search results web part at the item level. The only difference among these entries is the managed property mapping property which is required if the template is dealing with non-standard fields – anyone familiar with editing XSL for the content query web part to display managed properties will see this as being a fairly familiar process.

Aside from the obvious use cases of determining the display of both content by search and search results web parts the other use I’ve found for editing these templates is to modify the hover over effect from within the search results – for anyone who’s not seen it basically when you hover over a search result you get a hover item come up to preview the document or page similar to how current web search engines respond and then there are some link options available such as open, share, alert and so forth – however on public facing sites it may not make sense to show some of these links, particularly for alerts where the anonymous user won’t be able to sign up for them, so you can create a new template which hides those links and associate the new template with the particular file type via the manage result types interface in site settings.

SEO features in SP2013

This one was nice and quick. As a prerequisite you need the publishing feature activated to access the SEO properties.

For any given publishing page across your site you can edit the page, go to the Page tab in the ribbon, drop down Edit Properties and select Edit SEO Properties.

The main features here are the ability to set a browser title, the meta description and keywords. We also have the ability to exclude a page from the generated XML site map if we don’t want it to be crawled.

Once we’ve entered in those values, we can view the source of the page and see that the page title is the Browser title and the meta description and keywords exist on the page.

Funnily enough the Browser Title feature (which seems almost redundant) had an unintended benefit for a current site I was building – the design included a heading structure whereby the largest title was one reflected on a parent node (could be many levels deep) and the sub-heading was the title of the page – I was able to set the Browser Title to be that of the page and set the page title to be that of the parent’s title which needed to be shown and rendered that through a field control without fear that the incorrect title would affect the Browser bar’s title or have any SEO implications.

The other SEO features are in Site Settings under Search Engine Optimization Settings which allows you to do a couple of things:

  • Firstly, you can enter in other meta fields which will be inserted onto your page
  • Secondly, you can list Canonical URLs which are basically where a given page would display the same content even if the query string was different – you can get the search engines to ignore those query elements

Another SEO feature requires you to activate a Site Collection Feature being the Search Engine Sitemap feature – this ensures SharePoint generates a Sitemap.xml and robots.txt file for the site. That feature exposes another link in Site Settings called Search Engine Sitemap Settings where the robots.txt entries can be customised. Your site is required to have anonymous authentication enabled for the sitemap feature to work.

Building public facing websites on SharePoint 2013 – Part 1

Yesterday I had the great opportunity to present at the Perth leg of SharePoint Saturday for 2013. Overall the event was a resounding success – the turnout was reasonable considering it was the day of the state election and while the numbers may have fluctuated across the entire day, a number of sessions were well attended in all of the time slots. I had roughly 25 in my session which didn’t reach the great heights of my user group session on Harnessing Client-Side Technologies to Enhance your SharePoint Site however seemed a decent turnout considering there were 2 other quality sessions on at the same time and the overall numbers would have been less than the many which attend the monthly UG sessions.

After having some success with my previous session linked above I decided to follow the same presentation format – half an hour dedicated to slides and theory and another half hour dedicated to demonstrations. At the end of the day I probably whipped through the slides a little quicker than I expected which guaranteed I had enough time to finish off the 4 demo’s I had hoped to get through.

This post will run through the background to each slide shown below, then part 2 will give a run through of the steps and comments associated with each demonstration performed.

Building public facing websites on SharePoint 2013

The cover slide gave me an opportunity to thank everyone for supporting SharePoint Saturday in Perth and particularly choosing my session for the time slot – it’s definitely something I appreciate and is worth repeating in this post. I covered off a little bit about myself and explained my public facing website journey on SharePoint starting at Tourism on the now infamous westernaustralia.com website and various partner sites to my more recent experiences at the Department of Training and Workforce Development on various departmental and TAFE institution web sites – the most recent being developed on SharePoint 2013.

Agenda

There were 2 main things I wanted to get out of my session – firstly I wanted to generate some excitement on the possibilities that existed around building public facing websites on SharePoint 2013 but also transfer some knowledge around the key areas which are often neglected when building an internet facing site. I wanted to cover off how each version of the platform performed in each area then explore the new and exciting features which exist for web content management on SharePoint 2013, backed up by a number of demonstrations on my favourite features.

Branding & UX

Most people think branding SharePoint is all about slicing and dicing images into Master Pages and Page Layouts – and while this is a large part of it, there are a number of other factors which should be considered for a successful site. Implementing Custom Error Pages is one factor which is often forgotten about and can make the difference between your site looking professional or incomplete. The client-side and search experience is another area which can transform your site from something which looks good to something which performs great.

Search Engine Optimisation

SEO is often neglected or considered as an afterthought once the website has already gone live and traffic is not up to expectations – it is a crucial factor to consider to maximise the number of visitors to your public facing site. The topic is worthy enough of a presentation of its own however I have a 3-part blog series on Search Engine Optimisation for SharePoint Sites and Ian McNeice has written a great global SEO strategy book which cover the details. The main takeaway from this slide was that effective SEO requires a 3-phased approach – identify the keywords and phrases which are most effective to optimise for, optimise your site for those keywords and phrases and finally think outside the box for ways in which you can drive traffic to your site – rating well in the search engines in merely one component to an overall strategy.

Performance Optimisation

If SEO is all about bringing people to your site then Performance Optimisation is all about keeping them there. There are some great statistics and studies on the web which link bounce rates to page performance so it is most definitely an important factor to consider when building a site. There is a common misperception that SharePoint is inherently slow but that’s not a theory I subscribe to – a poorly developed and optimised site will perform badly on any platform – it’s just that SharePoint is easy to blame. Again this is another area in which an entire presentation could be dedicated and while I have another 3-part series on Performance Optimising SharePoint Sites the main takeaway was that while there are a number of generic and SharePoint-specific tasks you can target to optimise a site, there are also a number of great free tools available to benchmark and measure the performance of your pages including webpagetest.org, ySlow and Google Page Speed.

Accessibility

From a couple of topics which are often neglected or postponed to one which is often discarded completely. While it’s understandable how accessibility sometimes falls by the wayside due to its at-times difficult and time consuming implementation on SharePoint it’s interesting to note the time often dedicated to cross-browser compatibility for browsers with a lower percentage of use compared to the numbers that would benefit from an accessible site. This is particularly important for WA Government Organisations who have a mandate to ensure all websites are WCAG 2.0 compliant by the end of 2013. Vision Australia has written a great whitepaper on Achieving Accessibility in SharePoint 2010 which should be read for more information.

SharePoint 2007

So how does each version of SharePoint fare in these areas? Before I start it’s important to point out that any discussion on Licensing is generic and ballpark – I’m no licensing expert and the numbers have been taken in US dollars and at the time they were relevant – see the hyperlinks for the source.

Licensing: MOSS was fairly expensive to host public facing sites. At roughly 40k per internet server plus external connector licenses and with best practice guidance recommending a staging server with content deployment to production you can quickly see how even with a small web farm of 2 front end web servers and an application server how costs would add up.

Branding: Nothing to write home about here – we had ASP.NET 2.0 Master Pages and Page Layouts but that’s about it. Guidance was low in the early days, the starter master pages had yet to become mainstream. Custom Error Pages (other than 404) were particularly difficult to implement. jQuery had yet to take hold which left us with the AJAX toolkit and UpdatePanels which unfortunately required a number of manual web.config modifications to get working. MOSS for internet sites required an enterprise license, so at least we had enterprise search.

SEO: Practically non-existent. Even targeting the most basic of generic techniques generally required custom development.

Accessibility: If SEO was bad then accessibility was worse. View source of a MOSS-hosted site and you’ll see table hell – I pity anyone who had the task of getting MOSS 2007 accessible.

SharePoint 2010

Things were a little better in 2010, this is generally how it measured up:

Licensing: While we were no worse of in 2010, we weren’t really much better off either. Enterprise internet servers were still around the 40k ballpark although the external connectors were a bit cheaper. We did have the ability to purchase Standard licenses for internet sites which would be about 25% of the price – however there were a few caveats which often meant this wasn’t feasible, particularly the inability to host multiple domains on the server.

Branding: The Master Page and Page Layout story was the same, however there was far more information available plus the starter master pages had become widely used. jQuery had taken off and there were a number of blog posts regarding how to include it in SharePoint and a number of plugins which could be leveraged, and if you were still stuck with the AJAX toolkit then at least it was supported out of the box. We had the option of using FAST search for internet sites (for an additional license cost) which gave some flexibility around search. The custom error page story was much better – far easier to implement across the board compared to SharePoint 2007.

SEO: Unfortunately much the same – custom development was still required.

Accessibility: Thankfully much better – SharePoint 2010 launched with the goal to being WCAG 2.0 AA compliant and while it didn’t quite get there, the HTML rendered was much cleaner (aside from the tables generated by web part zones) and there was guidance around making 2010 completely compliant via the whitepaper I’ve mentioned above.

SharePoint 2013

Definitely the best of the bunch which is no surprise considering I dedicated an entire presentation to it.

Licensing: While there may be no official licensing details available, a number of sources suggest that the licensing for 2013 will be far more affordable. No longer do we need internet server licenses – an enterprise license with internal CALs will suffice. FAST search is now also inbuilt rather than being an additional licensing requirement.

Branding: Has changed completely in 2013. While we can still use the tried and true method of Master Pages and Page Layouts in our VS solutions, we now have the Design Manager which puts the power into the Designer’s hand and removes the need to have SharePoint developers implementing branding. There is also webdav support to connect to the master page gallery directly with an ability to edit linked HTML files which will automatically update the associated master page. A custom 404 page is provisioned and editable straight out of the box in 2013 and the other error pages are just as easy to implement as 2010.

SEO: Finally the platform has treated SEO with the respect it deserves – a number of generic SEO requirements being available straight out of the box.

Accessibility: The HTML markup is cleaner again, web part zones no longer rendering out tables. I’m unsure if 2013 is completely WCAG 2.0 compliant however if it is not, it would definitely take less effort to ensure that it was.

New Features for WCM in SP2013

A large number of new features exist for web content management in SharePoint 2013 however these are the ones I believe will be the most useful for building public facing sites.

Pasting content directly from word: Previously the experience of pasting content directly from word was a painful one – embedded styles would remain and cause certain pages to look completely different from the rest of the site’s style. This new ability will remove the need to use notepad as a go-between when pasting content from word to SharePoint.

Image renditions: This feature is getting a lot of airplay currently over the web and for good reason – it’s a great new feature. Essentially allowing you to upload one larger image and create different ‘renditions’ of the image at different dimensions, this feature will be great for mobile versions of websites which will allow a smaller file-sized image to be downloaded for rendering. Requires the BLOB cache to be enabled.

Cross-site publishing: Another highly useful feature in SP2013. Allows content to be published from one site collection to another. Many practical uses include separating editing/publishing environments, variations and particularly relevant for myself and government departments who host multiple sites – being able to share content between them while maintaining the individual branding of each department’s site.

Managed navigation / friendly URLs: My favourite feature of the lot – managed navigation is a step away from the structured navigation we’ve grown accustomed to. Allows you to define a taxonomy hierarchy which will drive navigation. Most importantly it allows you to implement friendly URLs which users have been crying out for for some time but also allows you to decouple structure from navigation ensuring you no longer have to create numerous sub-sites just to position a particular page at a given URL.

Search driven content: Used significantly for the purposes of cross-site publishing, it also has other uses including amalgamating content. Similar in theory to the content query web part however uses search as its content source – necessary if you want your friendly URLs to be rendered via the query. The best part is that XSL is no longer required to style the output – we can now use HTML and JavaScript via Display Templates.

Design Manager + Device-specific targeting: While I mentioned the Design Manager previously, another great feature is device-specific targeting. This allows you to use the same pages and content but recognise the device accessing it so you can use different master pages and styles to render that content – highly valuable for mobile sites.

SEO features: Some search engine optimisation techniques are now available out of the box which is fantastic news for those building public facing websites on SharePoint 2013.

WCM Feature Demos

Refer to Building public facing websites on SharePoint 2013 – Part 2 for a run through of the demonstrations which were performed in this session and some of the comments surrounding them.

Questions? Comments? More info..

While no questions were asked on the day it probably had as much to do with the session running its full hour and lunch having already been served rather than the presentation being so comprehensive that no questions were necessary! If anyone has any questions or comments feel free to leave them on this post or get in touch with me directly.

Thanks for listening

And thanks for reading! It was a pleasure being able to present this session on such a great day at such a well organised event, Brian Farnhill and the team did a great job putting everything together, the sponsors came on board to offer a great venue, food and prizes for the day and I look forward to being a part of it sometime again in the future.

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.

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

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. This part of the series will focus more on how content can be manipulated to improve search rankings and other factors that can be leveraged from within SharePoint. Finally, Search Engine Optimisation (SEO) for SharePoint Sites – Part 3 will take a step outside the SharePoint box into how you can boost rankings and traffic to your SharePoint site using other methods.

Optimise the Load Time of your Pages

This one works on a couple of levels. Firstly, there is some benefit in terms of SEO for faster loading pages. Take a read of Geoff Kenyon’s article Site Speed – Are You Fast? Does it Matter for SEO?. The reality however is that it isn’t a huge factor. More importantly though is that the time it takes to load your pages has a huge impact on bounce rates and visitors wanting to return to your site, and for that reason it is a critical task to undertake. SharePoint, especially MOSS 2007, doesn’t have the fastest load times therefore anything you can do to reduce the load time of your pages is paramount. I intend on writing a post on this in the future so i’ll leave it at that for now, but it’s definitely something to keep in mind when creating your site.

Maximise your Content to Markup Ratio

There’s a number of articles available discussing the importance (or lack thereof) of maximising your content to markup ratio. Whether you believe it’s a factor or not is largely irrelevant – there are a number of benefits to gain from minimising the amount of markup on a page for both performance and structural reasons. It’s also important to ensure the text content appears as high on the page as possible and this can be affected by manipulating the markup structure of the page. SharePoint is notoriously bad in this regard. Improvements were made from MOSS 2007 to SharePoint 2010 but it’s still not perfectly clean HTML. There are things you can do to improve the situation – using controls instead of webparts in MOSS will minimise the number of tables used on the page. Control Adapters can be used to manipulate the HTML rendered by controls. You can ensure your Master Pages and Page Layouts structure content higher on the page and adjust their location using custom CSS. Often a lot of effort is required when focussing on this SEO technique so unless it’s of critical importance sometimes it’s best to do whatever you can and just live with the rest.

Optimise your Images and Anchor tags

Images and anchor tags are 2 elements within the page content that can be slightly adjusted to provide an extra SEO boost. Images provide the benefit of also being indexed in the Google Images search engine which can provide extra traffic. ALT text is essential when optimising an image. It should be short, sharp, relevant and if possible keyword-rich. File names can also provide some extra juice and should be similar to the ALT text and hyphen-delimited. The Title attribute is unlikely to hold much weight but it can’t hurt and should match the ALT text. Anchor tags are another which can make use of the Title attribute. The other important aspect of anchor tags, particularly intra-site linking which you have control over, is to ensure the text which is hyperlinked is descriptive and keyword rich – preferably matching the key phrase that the page is optimising. In terms of SharePoint there are 2 features you can utilise to reap the rewards – the ALT text field for images and the Tooltip field for hyperlinks. If you want to utilise the Title of an image you’ll need to delve into the code-behind which may not be worth the effort.

Use 301 redirects over 302

As I mentioned in my post 301 vs 302 Redirects in SharePoint there are a number of reasons why 301 redirects are preferred to 302 from an SEO perspective. Rather than going over everything again I’d encourgage you to read through that post and the associated links to understand the benefits and potential solutions around it. It’s significant in a SharePoint context because when accessing a site by its URL directly rather than the specific page URL, a 302 redirect is used to take you to the Welcome Page. The Redirect Page layout in SharePoint also uses 302 redirects.

Don’t Destroy Old Content

No matter how old a page, article or news item is, it still has the ability to appear in the search results and drive people to your site. In fact, the age of a site often has a positive affect on its ranking. Why would anyone want to simply discard all the effort that went into optimising the page in the first place because it was deemed somewhat out of date? Archives are a great and suitable alternative which maintain the content online and hence the rankings of the page. SharePoint makes this quite easy to do – simply filter a Content Query Web Part to return all out of date pages on an ‘Archive’ page and you’re set. The process can either be automated by scheduling an end date for the page, or by manually configuring a custom column of the page. You could also move it into an ‘Archived’ sub-site, however if this option is chosen, keep in mind the redirect that will be required and the fact that will be a 302 redirect by default.

Avoid Flash and Silverlight if you can

It’s common knowledge that using Flash or Silverlight on a website in place of indexable content is a search ranking destroyer. Flash has made SEO improvements to the format but this is still only limited. With HTML5, CSS3 and jQuery taking off and able to achieve a lot of the rich interactive functionality provided by Flash and Silverlight, you’d have to question the use of it on your search engine optimised site. This goes for SharePoint as much as any other platform – leveraging the jQuery library in SharePoint in particular is easy to do and leaves the site more SEO friendly than a Flash or Silverlight equivalent.

Create an XML Sitemap Automatically

I’m not sold on the benefits of XML Sitemaps to be perfectly honest. I tend to agree with an article written by Matt McGee titled XML Sitemaps: The Most Overrated SEO Tactic Ever in that all an XML Sitemap is really doing is masking and potentially even causing problems. There are many more however that argue the opposite, such as Bruce Clay’s XML Sitemaps in SEO – Part 1. If you’re going to go down the XML Sitemap path, and i’m not going to categorically say it’s something you shouldn’t do, I’d suggest that you ensure that it is constructed automatically so it is completely up to date. In SharePoint one way this can be achieved is via Waldek’s Imtech XML Sitemap or Mavention XML Sitemap for 2010.

Include a Robots.txt File

Having a Robots.txt file for your site is not so much about improving the rankings of pages in your site but more about ensuring pages you don’t want appearing in search results aren’t indexed. For more information about Robots.txt have a read of Robots.txt: All you need to know. This is particularly important for SharePoint because often there are a number of pages you simply wouldn’t want indexed – list views and the like – which can sometimes end up being crawled. I’d definitely suggest including this file for your SharePoint site as part of your overall SEO strategy.

Structure your Content with Heading Tags

Using header tags (H1 through to H6) to structure content is another tool at your disposal to infer importance on particular terms and phrases. Header tags are easily applied in SharePoint via the content editor so its important to stress 2 main concepts. Firstly – use them only for the keywords or phrases. Too often heading tags are used unnecessarily throughout the page or on sub-headings which really convey no SEO benefit to the page. Secondly – use them for the keywords and phrases rather than styling DIVs or SPANs to achieve the same visual effect – it’s the tag which is recognised, not the size of the text on the page. You can have the desired visual effect on the page by using heading tags where appropriate and styling other text with CSS if the term or phrase is not a targeted keyword for the page.

Externalise your JavaScript

This one ties in to maximising your content to markup ratio – the less text on the page with no SEO benefit the better. There are also performance trade-offs however – you don’t want to be creating a bunch of extra page requests to pull down each individual JS file that contains your page’s code. There are also development implications – sometimes it’s easier to code the relevant JavaScript directly within a control rather than having to find it and work on it seperately. Ultimately it comes down to what is more important to you. In a SharePoint context i’d recommend using one file to hold all JavaScript functions that will need to be called from various pages, reference it via the SharePoint:ScriptLink control and make the call to the function from within your control. This minimises the amount of JavaScript text on the page and minimises the page requests.

Add ‘Strength’ to Keywords

This one I think would be extremely minor if it has any influence at all – but I guess you never want to miss an opportunity so it’s something worth discussing. Take a read of Traian Neacsu’s article Bold or Strong Tag and SEO – Complete HTML Reference Guide for SEO for more information on the topic. The main take away is that styling via CSS won’t have any affect, while bolding keywords with the STRONG element may be recognised. It’s something worth considering anyway.

In Search Engine Optimisation (SEO) for SharePoint Sites – Part 3 of this series I’ll take a step outside the SharePoint box into how you can boost the rankings and traffic to your SharePoint site using other methods.