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

Search Engine Optimisation is a topic that i’ve always had a keen interest in. One of my first if not fleeting jobs fresh out of University was at an SEO company, albiet in a sales-based role. It still gave me an insight into something considered somewhere between an exact science and black magic and immediately peaked my interest. Since then i’ve read numerous articles on the subject, provided advice to friends, worked on projects both as the lead consultant and as the implementer for SEO consulting agencies’ recommendations. Not all have been for SharePoint sites, however the concepts applied are often not SharePoint specific. The information available on the web is extensive – it surprises me how SEO companies even manage to exist when the information is so freely available.

When deciding how to differentiate this article from the masses i’ve leant towards applying the concepts with a SharePoint flavour. I by no means claim to be an expert on the subject – merely a keen follower. I won’t claim that everything on here is correct. I may suggest something that has no positive effect on your search rankings whatsoever. In general though, i’ve noticed that applying the majority of these techniques have had a positive affect to the rankings of the sites, so there must be some truth to them.

Part 1 of this series will focus on what you can do in regards to the content, naming, metadata and structure of your SharePoint site. Search Engine Optimisation (SEO) for SharePoint Sites – Part 2 will delve a little deeper into 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.

Before I get started I just want to clarify one thing. This article series doesn’t touch on perhaps one of the most important factors in regards to search engine optimisation for a site – the initial research required before any of these steps are even considered. One must know the keywords and phrases that are going to be targeted before they actually can be, and this should be carefully deduced via research into the types of natural language searches your target audience are doing and the competition those terms and phrases have to optimise against. It’s something that definitely needs consideration before you start. But for now, on to the implementation.

Content is King

I love this saying. I’ve heard and read it hundreds of times. It’s a great way to describe how content is key to attracting and keeping visitors returning to your site. It’s also spawned a bunch of posts playing devils advocate such as Derek Halpern’s The ‘Content is King’ Myth Debunked. In a purely SEO sense however, the saying rings true. Content is the most critical element to improving site rankings. The more quality content that exists on the site, the more pages that will rank highly for different search terms and phrases. This isn’t exactly tailored towards SharePoint, however it is too critical to leave out. Content should be keyword and phrase rich – especially in the first and last paragraphs. Each page on your site should target something different – it is easier to optimise for one specific phrase rather than multiples which just leaves you with conflicting goals and spreads the optimisation power too thin. Take a look at the Infographic / Why Content for SEO? and read the links by Google engineer Matt Cutts and Bing’s Duane Forrester if you’re left with any doubt.

Page Titles are Important

Not only are page titles valuable from an SEO perspective, but they’re also what’s used when identifying the pages within the search engines and therefore serve a dual purpose. Not only is it important to use keyword-rich titles, but they need to be visually engaging to invite the user to want to click the link. From a strictly SEO perspective, page titles should begin and perhaps end with a key phrase, and be 6-12 words long. From a visual sense they should attract attention and interest and be no more than 67 characters to prevent Google chopping them short. Page titles should be unique and relevant to both the page content and phrase being targetted. SharePoint already contains the Title column for pages – your master page should contain a ContentPlaceHolder for the title and each page layout should render the page’s title via the SharePointWebControls:FieldValue control. It’s important to ensure the titles are set with optimisation in mind.

Set Page Description and Keywords Metadata

The general consensus is that meta keywords no longer play a part in SEO. Whether the meta description does or not seems to be debated – most sources suggest it is important, however Jill Whalen argues they may not affect your page’s ranking in The Meta Description Tag. My opinion on both is that it can’t hurt. Description is also important for other reasons – it is often the call out text used in either search results or other situations including extended site links or social media links such as when you type a link into facebook. It therefore, like the title, not only needs to be keyword or phrase rich but inviting and attracting to the target audience. The strategy i’d use here is to use the Description page column for both the meta description and keywords and use the same technique identified above for the page title (take note that the internal name of the Description column is actually Comments). It appears Office 365 makes this even easier via Add keyword meta tags to pages to improve search and it is believed SharePoint vNext will do the same. A little side note for the metadata specified above – it should be well structured in the head element of the page and appear towards the top of the page – before any other metadata, script or CSS references.

Name your Pages Appropriately

Page names are another way you can add weight to your page for a given search term or phrase. The important take-away from a SharePoint perspective here is to not rely on the default. The page name is generally auto-populated depending on the Title entered and essentially concatenates the words together. Some authors will modify this title, but do so either by using CamelCase or underscores to seperate the individual words. Neither are ideal from an SEO perspective. Search engines read both as one big word, however read hyphens as a sentence, thus it is important to name your pages accordingly. This can either be done manually or by using a feature developed by Waldek Mastykarz highlighted on Optimize Publishing Pages for search engines using the Imtech SharePoint SEO Slugs Feature.

Directory Structure and Naming Deserves Attention

Directory structure can assist as an optimisation tool. Take a look at Stoney deGeyter’s How to Create a Directory Structure Search Engines Rock To. In my opinion, having a solid structure driven by information architecture requirements is more important than the potential SEO benefits that could be gained – however if it’s possible to consider both then it’s worth doing. One thing to keep in mind is that the further down the chain a page is, the less weighting it will have in a search sense and the harder it will be to find. Keeping SharePoint in mind, there are 2 things to consider here. Firstly, it’s too easy to just spawn multiple sub-site chains when trying to seperate content – this may be done for no logical structural reasons, rather to seperate lists or functionality into different sub-sites – this should be avoided. The other issue from a SharePoint perspective is the frustrating ‘Pages’ directory. This obviously serves no SEO benefit, it in fact acts as a hinderance. There are potential ways around this – Waldek’s Semantic URL’s in MOSS 2007 is one of them, others involve virtual directories and redirects, URL-rewriting components or HTTP handlers. Waldek also has a solution for IIS7 in his Friendly URLs for SharePoint post however it is unsupported and only works in particular scenarios. To be honest, I don’t really like any of the options and for now would just cop the hit. I’m hopeful that SharePoint vNext makes this easier to get around, perhaps leveraging off the URL Routing in ASP.NET 4 functionality. It is believed that SharePoint vNext will provide some form of friendly URLs which would be a welcomed addition.

Your Domain Name Counts

Domain names are an essential component of optimising a site. Often these are forgotten due to the desire of a lot of companies or organisations to use their brand name as their domain name. Unfortunately, this isn’t hugely desirable when trying to optimise a site. It’s no coincidence that when you search for a number of search terms, many of the top results will have included it in their domain name. Many would assume that it’s a trade off, either use the brand name or choose a search-optimised domain name, however as Ian McNeice identifies in his book Step by Step SEO: Search Engine Optimisation for SharePoint Internet Sites (a read I highly recommend) this doesn’t need to be the case. This isn’t entirely in my realm of expertise so I won’t try and explain in detail how to achieve it, but SharePoint does provide Alternate Access Mappings to handle that side of multiple addresses so that would play a part in the process. Another little-considered factor in choosing a domain name for SEO purposes is the domain extension. It’s widely believed that the main domain extensions such as .com, .net etc carry more weight. I also believe however that if you are targetting a particular country for your audience then you’re better off using the domain extension for that country, for example for Australia.

In Search Engine Optimisation (SEO) for SharePoint Sites – Part 2 of this series I’ll delve a little deeper into how content can be manipulated to improve search rankings and other factors that can be leveraged from within SharePoint.


Error Logging in SharePoint

As identified in my post Exception Handling in SharePoint it is important to determine the most appropriate form of logging for your situation and use it. My original intention for this post was to create more of a how-to for each possibility but in my research discovered that the number of quality resources on this topic is extensive. This being the case, the focus for this post will instead discuss the different options available, point out some of the best resources I found on the subject if appropriate and summarise what I think is the best overall option to use in most instances.

The forms of logging I identified and will discuss below include logging to the SharePoint ULS, to the Event Log, via email, a database, CRM or a SharePoint list.

SharePoint ULS

Logging to the SharePoint ULS is arguably the most logical option when it comes to logging exceptions in your custom code. It is most appropriate for developers or support staff if they have access to the files and are able to monitor them consistently. Ideally, the ULS should be monitored regardless to ensure the ongoing health of the site but under some scenarios the files may not be made available and hence logging here would go unnoticed – in this situation an alternative logging option should be considered.

The difficulty with logging to the ULS surrounds the different options available depending on what version of SharePoint you’re using. SharePoint 2010 makes this task a breeze with its SPDiagnosticsService functionality which is available in both the free (SPF) and licenced (SPS) versions of the product. The best articles I found on this topic were Tobias Zimmergren’s article on SP 2010: Developing for performance Part 4 – Logging and Waldek Mastykarz’s extension of this in Logging to ULS in SharePoint 2010.

The task is more difficult in SharePoint 2007. MOSS at least provides some functionality to write to the logs via Microsoft.Office.Server.Diagnostics.PortalLog.LogString (briefly documented in Clayton James’ post Log errors to SharePoint Log file) but that is not available in WSS. There are some examples listed including Eli Robillard’s SharePoint Trace Logs and the Unified Logging Service (ULS) however a number of links in that article are broken now. Gunnar Peipman’s SharePoint: Writing messages to ULS (Unified Logging System) is another quality post however a reasonably complicated solution. There is also a Codeplex SharePoint Logging Library by Ayman El-Hattab that may be able to be harnessed. As you’re probably appreciating now, logging to the ULS in WSS was not made easy.

There is however one saving grace for any version of SharePoint when it comes to logging to the ULS and that is the
patterns & practices SharePoint Guidance Library which i’ll discuss in more detail later.

The other possible qualm about logging to the SharePoint ULS is the difficulty in reading them. This is made easier in SharePoint 2010 by Microsoft’s ULS Viewer or Stefan Gordon’s SharePoint ULS Log Viewer on Codeplex. Tools also exist for SharePoint 2007 including Florin Muntean’s SPTraceView and Stuart Starrs’ WSS / MOSS Log File Reader – both on Codeplex.

Event Logs

The other logical place to log exceptions is the Event Log. It is most suitable for system administrators or developers and support staff who have access to the server (hopefully this isn’t the case in production environments!). Much like the ULS it is reliant on the logs being monitored on a consistent basis and also on the system administrators reporting any issues back to the development or support teams.

Again SharePoint 2010 steps up to the plate with it’s SPDiagnosticsService class, also documented in Tobias’ post outlined previously. SharePoint 2007 has to rely on core functionality in the System.Diagnostics namespace called EventLog.WriteEntry briefly documented in SharePoint King’s Event Log Access Denied : Sharepoint /.NET. As that article points out (to a degree), you need to ensure that access to write to the Event Log is granted to the relevant accounts.

One thing to point out here is, like the ULS logs above, the patterns & practices SharePoint Guidance Library provides the ability to write to the Event Logs as well.


Logging exceptions via email is an interesting one. In my opinion, email should only be used hand in hand with another logging option primarily for the purposes of notification. It is mostly required if the primary log store isn’t checked on a regular basis. There are 2 options available here; either use the in-built SharePoint emailing capability of SPUtility.SendEmail or using .NETs SmtpClient class – both documented in Mohd Sukri At’s post Send Email in SharePoint via .NET SmtpClient Class and SharePoint SPUtility Class.


I’m not a huge advocate of using a database logging mechanism in a SharePoint context however it may be appropriate if there is a need to aggregate exceptions from multiple (and non-SharePoint) applications across an organisation. If database logging is desired then a library should be used such as log4net or the Enterprise Library Application Block. There is a good article on Configuring Enterprise Library 4.0 for Exception handling and Logging by Suleman Ibrahim and some potential issues in Cory Roth’s How to get Enterprise Library working with SharePoint if you choose to go down this path. While on the topic of the Enterprise Library it may be worth pointing out that it is also possible to use it to log to the ULS logs demonstrated in Madhur Ahuja’s post Implementation of Logging and Instrumentation Application Blocks in MOSS 2007.


My opinions on logging to CRM are similar to that of a database. The most appropriate reason for this however would be in a tightly integrated SharePoint and CRM application where interaction mostly takes place on the CRM side. I’ve actually been involved in projects like this where logging exceptions to CRM was deemed more appropriate than SharePoint as it would aggregate issues from both systems and be more closely monitored. At the risk of exposing my lack of CRM knowledge and in lieu of providing a link to an example, the premise would be to have a log entity in CRM and have a library code-side which creates a dynamic entity of that type, populates the relevant fields, creates a TargetCreateDynamic object binding the dynamic entity and a request binding the target, then executing the request via the CrmService. Sounds easy, is relatively easy, but will leave this to the CRM experts.

SharePoint list

I find it interesting that I have yet to see an implementation of exception logging to a SharePoint list. It’s a highly visible and accessible location to monitor issues within a SharePoint site. Another plus to logging to a SharePoint list is that it is sandbox-friendly and hence a viable option for SharePoint 365. Timmy Gilissen identifies this in his post SharePoint 365 logging and the example is not restricted to just sandboxed solutions (note that if you’re going to take the code from that page you may also want to read Rob Garrett’s post Efficient way to add a new item to a SharePoint list).

On the topic of sandboxed solutions it is something worth pointing out in terms of the other logging mechanisms. It essentially makes them far more difficult to implement, for instance logging to the ULS or Event Logs in a sandbox requires a full-trust proxy due to the Microsoft.SharePoint.Administration namespace not being available in a sandboxed environment. The patterns & practices SharePoint Guidance Library however includes a full trust proxy which enables the use of it’s SharePoint Logger within the sandbox.

The patterns & practices SharePoint Guidance Library

I’ve been a little coy throughout this post regarding the patterns & practices SharePoint Guidance Library solely for the reason that I think it’s worthy of it’s own section in this post. The library is amazing on a number of fronts and this is no different when it comes to Logging. In fact, it is my most recommended option for logging exceptions assuming logging to the ULS and/or the Event Logs is suitable for your circumstances. I highly recommend you visit the page and read what the library offers both from a SharePoint 2007 and 2010 perspective. Another post worth reading in regards to the library is Alex Angas’ Intro to SharePoint 2010 patterns & practices – Logging.

As you can see there are a number of options when it comes to logging exceptions in SharePoint and depending on your circumstances, different ones may be the most suitable. The important part is that you use some form of exception logging and do it in a best practice manner.