Call Us 203.687.6053

Blog with a focus on DotNetNuke news, tips and tricks, DNN SEO, and insights and opinions about the DNN community at large.

DNN as a Search Engine Friendly CMS

Posted by Tom on Sunday, March 09, 2008 to DotNetNuke, SEO

SEOmoz mastermind Rand Fishkin recently voiced his opinion on "choosing the right CMS platform for your Website from an SEO perspective" and sparked a healthy discussion mostly driven by people familiar with PHP-based frameworks and content management systems.

The big question that comes to mind for us obviously is how DNN stacks up when it comes to features and capabilities in support of SEO. So let's look at the "12 basic SEO issues that frequently plague content management systems" according to Rand Fishkin.

  1. Title Tag Customization & Rules
    DotNetNuke makes it straightforward and easy to specify title tags on a "page-specific level" as long as the page is a traditional DNN page, meaning it's listed under Admin > Pages. Beyond that, things get a little more dicey as the responsibility shifts to the module that's driving the page. Multi-page modules such as Ventrian's News Articles provide some control over page titles while others such as Active Module's Active Forum allow no control over title tags at all.

  2. Static, Keyword-Rich URLs
    Even though DNN now features "human friendly" URLs, that's not nearly enough. Basic requirements such as hyphen separated words are still not met out of the box let alone custom URL creation. Luckily, the community has stepped up in the form of custom URL rewriting providers.

  3. Meta Tag Customization
    Along the lines of the title tag, DNN won't make you sweat over meta description tags or robots tags for conventional DNN pages, but I've only come a across very few modules that allow you to control descriptions and other meta tags in their page hierarchies. Bottom line, choose your modules wisely or build your own.

  4. Enabling Custom HTML Tags
    This is a no-brainer, as it's fairly safe to say that all DNN rich-text editors in use today allow manual editing of HTML simply by switching into "Source" view. You may even go a step further by customizing a variety of drop-down boxes found on editor toolbars.

  5. Internal Anchor Text Flexibility
    You are safe with DNN on this one as well, as there are a plethora of ways to optimize internal linking. Everything from the rich-text editor just mentioned to the good old, very flexible Links module comes to mind (just stay away from link tracking and logging.)

  6. Intelligent Categorization Structure
    While fairly limited out of the DNN box, "customizable navigation panels" as Rand calls them, are well covered by component vendors such as Telerik who've turned their navigational controls into DNN providers. DNN module developers such Snapsis Software and others have stepped up as well to offer flexible menu and navigation systems.

  7. Pagination Controls
    DNN does not concern itself with pagination controls as all content is managed by modules. So again, take SEO into account when researching modules. For instance, while I consider News Articles templates to be the module's best feature, there is currently no easy way to nofollow the pagination links.

  8. 301-Redirect Functionality
    You are on your own when it comes to redirects as there is currently nothing build into the DNN core to manage content redirection. I've come across modules that claim to handle proper redirection, but I have not tested any of them. Instead, I prefer the approaches described here. However you implement your redirects, make sure to test for the 301 http status code.

  9. XML/RSS Pinging
    While most modules these days (including the "core modules") provide some form of content syndication, "accurate pinging" is not as widely supported. In fact, I've only seen it in commercial modules, but then again, I have not investigated much in the is area. Please educate me on this topic.

  10. Image-Handling & Alt Tags
    Alt tags are handled well by the rich-text editor. If you use other, more elaborate modules or components to manage images or image galleries, make sure alt tags have been considered during module or component design.

  11. CSS Exceptions
    Most DNN rich-text editors easily allow for "manual exceptions" to the styles defined in skin.css or any other style sheet. This is definitely a boon to educated users and content editors, but in my experience, most average users are not aware of "proper semantic markup" nor do they care.

  12. Static Caching Options
    With the 4.0 release, DNN has been optimized for performance and we now have multi-level caching as well as compression to our disposal. However, "extraneous database connections" are still a concern, especially when using features such as the DNN Site Log, which in my eyes is much better handled by 3rd party analytics providers.

Considering that there is still no member on the DNN core team dedicated to SEO, I think the framework fares fairly well. I hope Cambrian will further address XHTML compliance as well as URL rewriting and content redirection. Everything beyond that is pretty much the responsibility of modules.

What do you think? Do you consider DNN a SEO-friendly CMS? Please share in the comments below.



Permalink Permalink      Comments 18 Comments      RSS feeds RSS feeds      Email updates Email updates

Technorati tags
DotNetNuke, SEO
 

Comments

Comment By Ismet Dumlupinar on Sunday, March 09, 2008 at 6:19 PM

Another great blog post.
I think DNN has a lot to go for SEO purposes, i have to make a lot of core changes to make it seo friendly and user friendly but after your efforts it worth all

Comment By Tom Kraak on Sunday, March 09, 2008 at 6:22 PM

Thanks Ismet. What specific "core changes" do you usually make in regards to SEO?

Comment By Ismet Dumlupinar on Sunday, March 09, 2008 at 6:32 PM

For example, DNN does not provide SEO Friendly Character Replacements for Foreign Languages. I have to modify and rebuild source for each relase to handle Turkish characters in urls.

Comment By Tom Kraak on Sunday, March 09, 2008 at 6:35 PM

That particular issue has been addressed with 4.8, no?

Comment By Lance on Sunday, March 09, 2008 at 6:55 PM

I would like to add two from my own experience.

1) Lack of integrated sitemap/structure. DNN takes the visitor to the root of a module but the structural tie is broken from there. It requires special SE sitemap generators to expose the whole site to the SEs via the sitemap.xml file. This has proven very important in getting information indexed in a timely manner. (This may be an extension of your Intelligent Categorization Structure point.)

2) Lack of 404 handling (related to 301). I have look at Bruce Chapman's friendly URLs which should be a good start in dealing with renamed or moved content. Beyond that however, a good 404 function captures the request for analysis, redirects according to any preset rules, or presents alternative content. The simplest alternative is a sitemap but better would be to suggest closely matched pages based on keywords in the URL. All DNN sites (and their visitors) would benefit greatly from a formal 404 handler.

Comment By Lance on Sunday, March 09, 2008 at 7:03 PM

...
3) Lack of per-portal robots.txt docs. I currently write the doc by hand but found its value limited on a multi-portal DNN instance. Having a per-portal method for creating the robots.txt doc (filled by default to hide DNN back end) would allow management of duplicate content for instance.

Comment By Tom Kraak on Monday, March 10, 2008 at 10:11 PM

Those are all good points Lance. In fact, most of them have been raised on seomoz.org as well.

I'm particularly interested in the 404 handler. Are there any other requirements that you can think of besides the ones above?

Comment By Darnell on Wednesday, March 12, 2008 at 9:56 AM

<quote>Considering that there is still no member on the DNN core team dedicated to SEO.</quote>

Why don't you nominate yourself for the post. I'm sure they would welcome the help.

Comment By Tom Kraak on Wednesday, March 12, 2008 at 10:29 AM

I would love to, but as far as I know there is no formal "nomination" process and core team membership is entirely handled internally.

Core team membership is certainly not the only way to support the project, but in regards to usability and SEO, I believe it's about the only way to raise awareness and drive real change.

Comment By Lance Long on Thursday, March 13, 2008 at 6:57 PM

I started spec'ing out a 404 module but never had the time or resource (same thing?) to get one done. I would be a client of someone if they did it right.

Here is the stuff I created so far...

1) App should trigger after normal DNN procedures finish to keep resources down.

2) All 404s are captured to a data base and can be cleaned out by the scheduler

3) all redirection are 301 (permanent) by default but a 302 can be use in special occasion. A 302 would be handy if you close a section down: create a temp page explaining the closure, rename the root tab id (all sub tabs are now 404), recreate a 301 to the temp page for all requests to tab or children.

4) Admins can review the frequency of the 404 errors and make individual rules on how a link should be redirected. (reactive administration)

5) Admins are able to make Regex rules to redirect entire directory trees (active administration)

6) If the above rules fail, a predefine tabID is used as a custom 404 page. Normal administration of the page is possible. It should be hidden from the menu but publicly accessible. A "no-index, no-follow" meta attribute would keep SEs from labeling the content as "duplicate".

7) A supplemental module or enhance feature search tabs names for close match to the wrong URL. The visitor is given a list of the five closest contenders including nodes on the breadcrumb path.

8) An email once a period outlining the 404 issues would help admins keep on top of issues.

Ps, I think the robots thing is a great idea too but would require a change to IIS so not really financially rewarding as a module.

Comment By Tom Kraak on Friday, March 14, 2008 at 10:26 PM

Much appreciated Lance! I'll discuss this with our developers and will most like be in touch with you during development and testing.

Thanks again.

Comment By Bruce Chapman on Monday, March 17, 2008 at 4:45 AM

Tom

As I posted in your other blog entry (sorry to comment-spam, I didn't see this entry at first), I'm at the Beta testing stage for my newest module, which I'm calling 'Url Master'. This is a DotNetNuke friendly Url Provider + Url Rewriter which does the following and more:
- Friendly Urls based off the DNN page name
- Replacement of spaces and special characters with any character you choose
- Support for non-ascii diacratic characters such as German Umlauts - no more encoding in the address bar if the browser supports it
- 'Freedom of Extension' (I borrowed your term!) meaning the .aspx can be replaced with anything, including removing it entirely
- Custom defined Urls for any DNN page - allows you to define what you would like the Url to be, instead of accepting the default value
- Custom redirects for any Url to a DotNetNuke page - 301, 302 or 404. This allows people replacing Non-DNN sites with DNN sites and handle all the 'old' links OK
- Automatic 301 redirects where the non-friendly version of the Url is used
- GUI Based configuration for all options (no web.config editing)
- 'Standard' DNN module install (no ftp of binaries)
- option to 301 redirect for mixed case to lower case version of Url's
- option to 301 redirect to a set subdomain (including www) or no subdoman (ie seablick.com if www.seablick.com requested)
- Ability to exclude DNN pages from having Friendly Urls generated (will generate 'standard' DNN friendly Urls) - this helps when module developers use their own, proprietary Url handling instead of the DNN Core provider.

This module is a ground-up rewrite of my Friendly Url Provider (which I will continue to support). The module is in Beta test at the moment, and will be available shortly. I'm pretty confident it will be the solution for anyone who is serious about SEO for their DNN install.

You can read more about it in my blog at http://www.ifinity.com.au/Blog/Technical_Blog/EntryID/33/

-Bruce

Comment By Tom Kraak on Monday, March 17, 2008 at 8:24 AM

Thanks again Bruce. I can't wait to take the new provider for a test drive.

Comment By matt on Monday, April 14, 2008 at 12:59 PM

Thanks Bruce - were looking for independent confirmation on a few of those. DNN has some way to go since the developers seem almost peeved at questions about SEO issues with the CMS.

Do you know offhand of any post that will autolink within content based on occurrence of a particular word? Wordpress has a few such plugins so I know it can be done, just a matter of how long it is until someone codes it in .NET for DNN.

thanks!

Comment By Tom Kraak on Monday, April 14, 2008 at 1:17 PM

Matt - ideally, this should be a "plugin" to an existing module such as the core blog module or Ventrian's NA, correct?

Comment By Bruce Chapman on Tuesday, April 15, 2008 at 8:26 PM

Matt,

I'm not sure exactly what you mean - can you give a more specific example - maybe describe the wordpress plugin you are talking about?

-Bruce

Comment By Hernan Chiosso on Wednesday, April 30, 2008 at 11:13 AM

How about the Solpart menu (the default option, after all) using mostly JavaScript to display the links?
Does this not hurt SEO as well?

I think this could be improved in further versions (there seem to be some solutions out there like the SEO Menu module, or the House Menu).

What was your experience with this?

Comment By Tom Kraak on Wednesday, April 30, 2008 at 12:20 PM

You are absolutely correct Hernan. And even though Solpart has improved over the years, we still prefer to use 3rd party menu providers as mentioned in #6.

Add a comment
Add to Technorati Favorites

Email Updates

Enter your email address below and find our blog updates in your inbox.