iFinity

Written by:
Friday, May 23, 2008 11:39 AM 

SEO and DotNetNuke is a topic increasingly discussed with the growing awareness of site owners and webmasters of the need for building DNN websites that maximise the chances of being rated highly in search engine results pages.

In my previous work, I have concentrated on cleaning up the Urls for DotNetNuke, and implementing the correct Http status codes (mainly 301 redirects) needed to direct search engine spiders to where DNN administrators want them to go. With that work paying dividends on this site (and many others) in better Search Engine rankings and search-related traffic  I have now turned my attention to producing more SEO-enabled content modules, to clean up the remaining content on the site that still has sub-optimal Urls and SEO features.

With many people creating DotNetNuke modules for showing content, both as third-party resellers and just for their own use, I thought it was worth posting my thoughts on what you should do as a module developer to maximise the SEO aspects of your module. 

The Products/Free Downloads Page – a case study

One page on this site which quickly became an official disaster zone for visitors is the Free Downloads page. It’s far and away the most popular page on this site, scoring 15% of the traffic to the entire website. I guess everyone likes to get something for nothing – and that’s why the page is there. I enjoy helping people out with the free modules available, and I certainly enjoy when people trial and purchase one of the ‘premium’ modules.

However, with growth in the number of modules and downloads on the page, the page itself was too confusing, had too many different topics on it, and, because it was a mixture of the standard Documents module and Text/Html modules, was often out of date with respect to the latest versions of downloads.  

In addition to this, I was using the Ventrian News Articles module to display my product list. It wasn’t a good fit – the News Articles module is designed for chronological release of articles in categories, and doesn’t fit well in the paradigm of a more permanent list of Product information. This is nothing against the News Articles module, I was just putting a square peg in a round hole.

So I decided to create a new module, and with a client requesting something similar for their site, the ‘Master Detail’ module was born. As I was starting with a clean-sheet design, I decided to focus foremost on the SEO aspects of the design.   The ‘Master Detail’ module is ‘just’ a Html content display module, specifically designed to handle those situations where there is a group of related content that can be classified under a ‘Master’ record. In the case of the iFinity.com.au products page, it’s the list of products available.   It could be anything – projects a company wants to list, staff in the company, locations – anything that lends itself to ‘Master->Detail’ style of storage. 

The Master Detail module also has advanced file-download capability, where you can upload a file once and attach it to many different pages of content with the click of a checkbox, rather than trying to code many different links to a file, which lends itself to change control problems when the file is changed.

Note : I’m going to use the word ‘authors’ here, to indicate the content author. It could be the site administrator, webmaster, or person in a company charged with keeping the content up to date. It just means anyone who is going to have access to the ‘edit’ functionality of the page.

The 7 Features your DNN Module must have to be considered Search Engine Optimised

1. Allow customisation of every aspect of the Url for the page

The Url is so important for the page. It tells the user what is on the page by looking at it, and it’s one of the most important things you can put keywords into for your page.   For the Url Master and Friendly Url Provider modules, the most common request I get is ‘can I get rid of the ‘articleId/entryId/propertyId/categoryId’ from the ‘News Articles/Blog/Property Agent/Catalook’ module? This is because people are stuck with Urls like /articleType/viewType/articleId/3/my-article-name.aspx’, and they just want ‘/articles/my-article-name.aspx’ – or, in my case, they just want ‘/blog/blog-entry-name.aspx’ or similar. The point is, developers, you have wean yourself off just throwing in a database-id into the query string and calling it finished. It’s a lot more work, sure, but it’s the most important thing you can do to a module.

For the Master/Detail module, I have created it so you can customise the Url at every level. For example, in the Products page, I have configured it so that all these Urls work:

If you click on one of these Urls, you get the content. But how? There’s no database id encoded?! How can you have a one-parameter query string?

There is no database Id encoded. The value lives in a field called ‘Url Value’, and there is a large amount of code devoted to ensuring that it is unique across the module instance, so that you can’t define two Urls the same.

There is no key=value pair (which gets translated to Key/Value/ by the Friendly Url Provider). I’ll let you in on a little known fact – in ASP.NET, you can have a query string that looks like this : ?myvalue   There’s no absolute requirement to have ?mykey=myvalue – none at all.

If you’re writing a new module, do the work. You’ll be pleased with your results, and so will the people who use your module.

2. Don’t allow duplicate Urls for the same content

Duplicate content is something we must all watch out for. You don’t want the same page being accessed by more than one Url. If you do have more than one Url, you should have 301 redirects back to your chosen ‘canonical’ Url.    This means making sure, that in your code, if you are generating links between pages of content, you don’t generate multiple versions of Urls back to the same address.

In the case of the Master/Detail module, when you browse to a page with the module on it, you’re just going to get the base page Url – in this case /Products/. The first ‘Detail’ record on the Products page is the ‘Products Overview’ record. 

Now, with each detail record having it’s own, unique Url path, the contents of the first Detail record in the list could potentially have two urls :

This is not a good result. In this case, the module works out which of the detail records is the first on the page, and any Url generated for that detail record is just the base page value - /Products/. 

This means that the contents of the first detail are only known through one Url, eliminating duplicate content.

3. Allow customisation of the Page Title, Meta Description and Meta Keywords for the page

This is a very common problem. The base DNN page information allows the specification of the Page Title, Description and Keywords. Once you add a module displaying ‘dynamic’ content, driven by query string values, the content probably won’t match the ‘generic’ Title, description and Keywords.

The Title and Description are important, because of the Search Engine Result Pages, or ‘SERPs’. Everyone is familiar with the ‘clickable’ header on the SERP, and the short two or three line description.   In many cases, the Html Page title is the header, and the Html Meta Description tag is the two or three line description. It’s here where you need to convert people looking at a page full of results to actually click on your page – particularly if you aren’t ranked number 1 for the result.    By allowing crafting of individual Descriptions and Page titles separate to any other page content, you allow site authors to fine-tune their SERP results without affecting what the actual page looks like.

Many modules available just throw an automatically generated value into the Page description, and title, or, worse, don’t even change it from what the base page value is.

The Master/Detail module has customisable fields for Page Title, Page Description and Page Keywords at every ‘level’ of content.   Each piece of content lives in a hierarchy of Master (the module) -> Detail (individual record on the page) -> Pages (pages within each detail).

As such, there is a hierarchy of Master Page Title/Desciption/Keywords -> Detail Page Title/Description/Keywords -> Page Page Title/Description/Keywords. The logic of the module appends the three levels together, so the author can choose exactly at what level to have the information separate per record.    Every single piece of unqiue content within the module can be associated with a matching set of Page Title/Description/Keywords.

4. Don’t use AJAX for content display

I love using AJAX pages – where they are suitable.  If you’re displaying static content to a user (and 90% of all websites do exactly this) then don’t use AJAX. There’s no point. People expect to see a page refresh when they click on a link. Leave AJAX for more complicated editing tasks where it is really useful. AJAX has the ability to hide lots of good content behind postbacks and javascript, where search engine spiders won’t find it.

The Master/Detail module uses AJAX heavily for it’s edit pages, and has nice AJAX functions for uploading files, scrolling between records and all sorts of other functionality. But the content that anonymous web users see has absolutely no javascript links or postbacks hiding content.

5. Allow customisation of the anchor text for all links

This is something that most modules actually do a reasonable job of, but it’s worth repeating – if you are generating links to different parts of your content, allow the author to customise the text of that link. Perhaps there is a particular keyword they’d like to link with, which is different to the ‘title’ or ‘name’ or whatever. Let them customise the link text.

In the Master/Detail module, each detail has a separate field which is used for the link on the menu.   And, for each page of content, instead of just using ‘page 1’, ‘page 2’, the author can specify individual link text. Perhaps you might want ‘click here for page 2’. It’s important to give the choice.

6. Use simple layouts and CSS design

Early DNN was table heavy – and I’m not part of the crusading crowd that wants to run the sword through any website that dares to put a table in for display purposes. Sometimes a table is necessary, sometimes not.   But don’t force tables on your websites. Just keep it simple with div and span elements, and let CSS do the heavy lifting of organising the content. That way, skilled authors will be able to modify the CSS and change the layout quite easily. They’ll be thankful, but, most importantly, the Html will be cleaner and more likely to be indexed effectively by search engine spiders.

7. Use H1, H2 and H3 tags for headings, instead of the ‘Head’ class

Most people who have studied SEO techniques know that you need to use emphasis on the keywords of your content, so that the search engines know what the page is about. The search engines know that ‘h1’ and ‘bold’ and ‘em’ mean that the particular words inside are important to the overall meaning of the page.

So use the H1, H2, H3 tags where suitable. There is an in-built DNN CSS class called ‘Head’, and you should avoid it. That’s what ‘H1’ is for. 

8. If you must use LinkClick tracking, allow it to be switched off

A particular bugbear of mine – the LinkClick tracking links – appear on several DNN modules that I’m aware of. The standard FCK editor installation does this as well, but can be circumvented.   But you should never, ever, force all the links to be through the ‘LinkClick.aspx’ handler. Some people just don’t want to use them, and I know of several instances where a module was deleted from a website because it couldn’t provide links that didn’t hide behind ‘LinkClick.aspx’.

The Master/Detail module has the ability to enable LinkClick tracking on downloadable files. Indeed, it’s important on the product page so the number of downloads for each product can be tracked. But, if this is switched off, you get an ordinary Url pointing to the file – important for the file if it is indexable content, like PDF’s and other file types that search engines will happily index.

Side Note : I have a free DNN reports script so you can actually see from a portal-level the statistics from all link click tracking. If you use LinkClick tracking on your site for anything, you will find it very useful, and you can’t argue with the price!

Go Forth and Develop

I’ve been working to most of these principles for all the modules I have been developing, this list formalizes and ranks those factors. If you’re a DotNetNuke developer, I encourage you take a good long look at your code and think : Do I do it this way because it’s easier, or because it’s best for Search Engines?

This list to me, is a ‘must-have’ for any module wishing to be taken up by the community of people who have public-facing websites that want to be found via search engines.   Granted that’s not everybody, but it’s an important market.

What do you think? Did I miss something important? Do you disagree? Leave a comment below and share your thoughts.

Trackback Print

Tags:

Categories:

Location: Blogs Crafty Code

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Add Comment   Cancel