Assessing DNN Modules for SEO
Just about every DNN site I've ever seen takes advantage of at least one third party module. The richness and depth of offerings in the skin and module ecosystem drives a big part of DotNetNuke's success.
In the DotNetNuke forums, I see threads appearing time and time again: which module should I use to do X. Often, people wish to evaluate a module based on performance, features, support, and aesthetics. To me, there is one other important criteria for a DNN module: how effectively it supports my search engine optimization (SEO) efforts.
5 Criteria to Judge a Module
I'm going to discuss 5 criteria by which you should judge a module in regards to SEO. Some of these are a pass/fail, while others are more subjective.
- Proper internal linking and Urls
- Use of standard-compliant Html and CSS
- No JavaScript, Ajax or Flash for content delivery
- Control over Html Meta Tags
- No Black Hat, No Gray Hat
Proper Internal Linking and Urls
The Url issue is the first in the list, because I think it's the most significant. The importance of placing keywords in Urls and using keywords in the anchor text of links cannot be stressed enough. Watch for simple, static Html links and stay clear of excessive use of JavaScript postback links to navigate around the content in modules as much as possible. As for Urls, you don't want to see module Urls looking like /myId/12355/anotherId/23455/default.aspx.
The most obvious example is putting search-friendly content into the Urls that the module generates. This is generally achieved by passing in a "custom" page name into the Friendly Url API for DNN. I recently detailed this in a blog post titled An open letter to the DotNetNuke developers of the world: Please start using the FriendlyUrlProvider API for custom page names! This is very simple to do for module developers and creates immediate benefits for end-users.
Ideally, you should also be able to specify the anchor text for internal links, so that, for example, instead of Next Page for a link, you can change that text to Next : My Interesting Content.
The other important point is that the module does not create duplicate content, meaning multiple Urls pointing to the same page. This was the case for earlier versions of the DNN Blog module, although Antonio's team has now corrected this with the latest release (well done, guys).
Bonus points: when the module allows you to specify what the text added to the Url is, instead of automatically generating it from a pre-determined field (as Ventrian's News Articles does from the Title field.)
No-no's: when the module uses a proprietary Url scheme to implement it's own friendly Url and rewriting scheme, eliminating the ability to use plug-in providers to improve the overall site Url scheme.
How to Check
Look for an example or demo of the module and see whether or not the Urls linking the internal content are generated by clean, plain old Html links. Inspect the Url behind links by hovering your mouse, or check the Html by viewing the page source.
Also check for keywords apparent in Urls. Any module using Friendly Urls will show keywords instead of /default.aspx at the end of the Url.
You might also want to run the demo site through the W3C Link Checker. This will highlight any internal JavaScript-driven links and poor linking techniques.
Use of Standard-compliant Html and CSS
Valid Html is indexed Html. Burying module content in endlessly complex layers of nested tables and badly written Html affects the ability of your content to be indexed. Nice, easy to read Html should make up the module, and CSS should control the layout of that Html.
The Html should also stick to the semantic structuring of text, such as using <h1>,<h2>,<h3> tags for headings, and <p> tags for paragraphs.
Bonus points : template-driven modules that allow full control over the Html and CSS.
No-no's: using invalid Html (invalid syntax like all capitals) and in-line styles extensively (like widths, colors and fonts.)
How to Check
Again, look for a demonstration site and view the source of the page where the module is located. You should be able to find the Html generated by the module, as it will be surrounded by the DNN container code. Search for tags like <div id="dnn_ctrxxxx_ModuleContent"> (where xxx is the module Id.) You should also see a module.css file in the installation package of the module.
No JavaScript, Ajax or Flash for Content Delivery
First, let me start by saying I enjoy interacting with richly-featured sites driven by Ajax and Flash. But if you're evaluating a module on its SEO merits, rather than its latest-features merits, these things are a drawback. Sure, Google is talking about being able to index Flash content, but it will be a long time before a blob of flash beats a couple of paragraphs of well written text for search results. JavaScript and Ajax are indistinguishable really, but the main thing you don't want is having content hidden away and only accessible by doing something with your mouse, like clicking to play, unhide or pop-up. Yes, sometimes these solutions can be search engine friendly, because the content is already in the page and only revealed by JavaScript, but it will take some work to be sure, and that's only after you've installed the module. We're here to evaluate, so no JavaScript and AJAX. Perfect places for these technologies are in the edit UIs for the module, where a bit of user-friendly technology goes a long way.
It's important to note here that the standard Solpart menu distributed with DNN fails this test (even in DNN 5 beta 6) as it is JavaScript dependent.
Bonus points: If you can operate the module using only your keyboard.
No-no's: Using popups to deliver content.
How to Check
If you can, check the output of the demo site in Lynx - it's a free download, and very revealing on how your site stands up to less feature-laden browsers. You may also run the module thru a site such as seo-browser.com. If the demo site is in the Google cache, check out the cached version and see if any of the content is hidden.
Control over Html Meta Tags
Your title and description meta tags are important to the control you have over the way your site appears in search engine results pages (SERPs.) You should be able to control what appears in the page title (the <title> tag of your <head> tag). You should also be able to control what appears in the meta description tag of the page where your module content is displayed. You don't want to have the DNN site description showing up, or just the DNN page description. This is especially important if you have 20 unique Urls of content, and they all show up with the same page description. Google in particular seems not to like this as they go as far as to notify you in webmaster tools if pages all have the same description.
Bonus Points: when you can also set the robots meta tags to control the indexing and caching of the page.
No-no's: Stuffing the same, generic information into the page title and description.
How to Check
Look at the demo site for the module, and pay attention to the titles at the very top of the browser window. If these don't from page to page, chances are you can't change it. Inspect the other meta information by looking at the Html, or via Tools > Page Info in Firefox.
No Black Hat, No Gray Hat
Black hat, for the uninitiated, is a label applied to practices which are explicitly against search engine guidelines. Its opposite is white hat, which is doing SEO work entirely within the rules. You're reading white hat advice right now. Black hat is anything that is trying to trick or game the search engines. Gray hat, then, is anything halfway in-between, where perhaps the website owner could attempt to defend their use of a particular tactic as within the rules. It's a bit like ethics : if you feel you have to ask the question, you're probably outside accepted practice.
You absolutely do not want to use a module that attempts to game the system by tricking search engine indexing and ranking. The most obvious red-flag in this case is if the module author boasts that the module contains some "secret" trick or technique to improve your ranking. If you don't understand what is going on, chances are it's not accepted by major search engines, and by doing it, you run the risk of being penalized or even outright banned.
By far the most common tactic being used today is "cloaking." Cloaking is a generic term which applies to the practice of showing a search engine robot one set of content, and showing human visitors another set. Cloaking can be as simple as setting keyword-rich text to the same color as the page background, or as complex as revealing / hiding content using JavaScript, which search engine bots can't execute. While there are arguments for and against this practice on various grounds, in general, don't get involved unless you really know what you are doing. Just stick to the tried-and-true practices of writing good content, using clear linking strategies and promoting your website. It works, and it keeps working, whereas with gray and black hat techniques - once the people writing search engine software figure out what you are doing, they will close the loop and possibly ban your site.
The most insidious examples of black hat SEO come to light when module authors promote themselves through modules they give away or sell, and the unsuspecting website owner isn't even aware that their website is using a technique considered by search engines to be outside the rules they set for inclusion in their SERPs. I read a forum post on dotnetnuke.com recently where a hosting company was secretly inserting links back to their own website into the Html of it's customers sites. I have also seen examples of free modules distributed for the purpose of building links back to the authors website by using hidden links that don't appear to regular users, and only appear to the search engine bots. There is nothing wrong with providing a free module in return for a link to the authors site, but this should be done with the prior knowledge of the customer, not by including sneaky JavaScript into the code.
Bonus points: The module does nothing but allow you to author quality content in valid Html.
No-no's: Using questionable redirects, malicious cloaking , and hidden links without the customers knowledge.
How to Check
Invariably, any black hat SEO usually involves inserting/hiding links in content, as links are what drives Google's PageRank. You can scan the output Html of the page the module is on for pieces of content you didn't expect. You can also use an external link tracking tool, like SEO Chat Site Link Analyzer. I'm not affiliated with them, I just picked it from a list of tools found in Google. With these types of tools, you just enter your site Url and it will scan the page and tell you how many external links there are on the page. It's a good idea to check to see if a third party module has put links into your site without you knowing about it. What you're looking for are external links that you didn't put in yourself.
Wrap up
After digesting this post, even experienced DNN admins may wonder why they can't think of a single module that would pass all 5 criteria. Heck, I doubt even some of my modules will pass. But this post is not meant to bash third party module developers, it's meant to educate and raise awareness of the DNN SEO space, which is a big part of what we do here on the Seablick blog. And as always, we would love to hear your thoughts so please chime in via the comments.
Name (required)
Email (will not be published) (required)
Website