DNN SEO and Beyond: An Interview with Tom Kraak 

Posted by Jeff on Tuesday, August 19, 2008 to DotNetNuke, SEO, DNN Tips and Tricks, Podcasts, Interviews

Today I'm catching up with our very own Tom Kraak, owner of Seablick Consulting. Tom talks about his passion for DotNetNuke search engine optimization and elaborates on 2 specific pieces of SEO advice every webmaster should know about.

This show is meant as a springboard for additional audiocasts, albeit shorter ones, in which Tom will highlight 1 SEO tip at a time to help anyone overhauling an existing DNN website or starting from scratch with best practices in mind. If you have DNN SEO related questions or issues you would like us to discuss, feel free to post them in the comments below.

Click the Play button above (16 min) or download the audiocast (5.6 mb) for offline listening.

Links from the Interview

• DNN SEO Quickstart Guide
• Best Practices for Title Tags
• Local Search - to the Top of Google in Days

 Permalink       2 Comments       RSS feeds       Email updates

Assessing DNN Modules for SEO 

Posted by Bruce on Thursday, July 31, 2008 to SEO, DNN Tips and Tricks

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.

1. Proper internal linking and Urls
2. Use of standard-compliant Html and CSS
3. No JavaScript, Ajax or Flash for content delivery
4. Control over Html Meta Tags
5. 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.

 Permalink       7 Comments       RSS feeds       Email updates

Understanding 301 Redirects 

Posted by Bruce on Wednesday, June 25, 2008 to DotNetNuke, SEO, DNN Tips and Tricks

From Tom:
Please welcome Bruce Chapman as a seablick.com guest blogger. If you are a “regular” around here, Bruce won’t need much of an introduction as he has made a name for himself in the DNN community as a developer of SEO-focused modules and components. In upcoming blog posts, Bruce will shed light onto the technical side of DNN, SEO, and DNN SEO and I’m thrilled to have him on board … welcome Bruce!

The most important piece of advice for obtaining and maintaining a high position in search engine result pages for your website is to get relevant, one-way, inbound links from other respected websites. Relevant in that the link originates from a page with content related to yours, and the link anchor text preferably contains the keywords you wish to rank highly for. Respected websites are those not involved in shady practices such as link farms, and, ideally, represent an authoritative source.

This advice is given just about everywhere - and for good reason. It's good advice, and quality inbound links will have a greater effect on your search result placement than any other optimization technique. However, there's a problem with collecting inbound links that may not be obvious straight away. The problem appears down the road when you decide to change your site in some way. You may need to reorganize your content into a new structure, or perhaps you want to change the platform the site runs on (not that you ever want to move away from DNN :)- You might wish to change the URL scheme, or simply change the URL of a given page. All of these actions have the same effect: the location of the page has changed.

Here's an example:

You set up a page called http://mydomain.com/myverycoolthing.html.

It's an interesting page, and someone submits it to a social news site. As a result, you get plenty of inbound links to it, and you start to rank well in the search results for searches of 'very cool thing.' But after reading a few articles, you decide the URL would be better if it separated out the keywords with a hyphen. So you rename the page 'my-very-cool-thing.html.'

Once you change the URL of a page in any way, here's what happens:

1. visitors following that link from the source page will arrive at a page that no longer exists ('page not found' error)
2. visitors who have bookmarked that page will return to find the page no longer exists
3. search engine robots will revisit the link to discover it no longer exists and remove it from the search index
4. search engine robots following the link from the source pages will discover it no longer exists, and the "vote" of those incoming links is removed from your site

You'll start to slip down the search engine results pages, and soon enough you'll disappear from it altogether. You've undone all of that hard work by renaming the page URL.

Enter the Redirect

The solution, of course, is to redirect all requests for 'myverycoolthing.htm' to 'my-very-cool-thing.htm.' A redirect means that if anyone requests the 'old' URL, they will get forwarded to the 'new' URL. Redirects are nothing new - in fact they are as old as the World Wide Web itself.

The most common redirect you see on websites is called the '302' redirect. 302 refers to the Http status code (see sidebar), and it will temporarily redirect the request to the specified new location (the new location is supplied along with the status code.)

A 302 redirect will ensure that people requesting the Url will get to see the content they expected (points 1 and 2 above). It will also direct search engine robots to the new page and ensure it doesn't get removed (point 3). However, search engine bots will vary in how they treat the weighting of the link (point 4).

It's like when you go away from your house for a while, and get the mail forwarded. Should people update their address books to your new address? Not really, because forwarded mail generally means you'll be back at the original address at some point. A 302 redirect is equivalent to telling the post office to send your mail to a beach house for the holidays, and to stop when you return.

Part of the problem with using a 302 redirect is that it is has been misused by people trying to trick search engines, and it indicates a temporary shift in the URL. So some search engines will update their index to the new URL, others won't, and the end result is not what you are after.

Matt Cutt's blog (Matt works for Google) has an interesting post on the difficulties in interpreting 302 redirects. It's well worth a read for more details on the issue.

A 301 Will Do

A 301 redirect (again, 301 refers to the Http status code) means a permanent redirect, as in 'the resource has permanently moved.' Reverting to the mail metaphor, if you move into a new house, you get the mail redirected to your new location, and at least where I live, the post office takes care of informing your bank, insurance company and government agencies that you have permanently changed your address. A 301 is equivalent to this scenario : we've moved and we're not coming back.

When search engines receive a 301 redirect status code, they know the URL in question has permanently changed, and they will go and investigate and index the new page. They will also assign any link weighting from incoming links over from the old URL to the new URL. This means your page, even if it has completely new content and a new URL, will retain the Google PageRank of your old page. Your page has permanently moved to a new location.

If you search around the Internet long enough, you'll find all sorts of conflicting information about using 301's and search engines. But I'm here to tell you this: it works, and it works well. I've changed the URL on many, many pages on websites, and without exception, it works well.

An Example Using 301 Redirects

I'm always tinkering with my own site, ifinity.com.au. I read my search keyword statistics and make adjustments to URLs and site structure based on what people are actually searching (and finding) the site with.

Originally, I set up a section / subsection in my website called 'What We Do.' I thought this title sounded more personable. But really, I found that people never search for 'what we do.' They search for things like 'products', 'services', 'consultants' and keywords like that. I made the decision to change 'what we do' to 'services.' It's the sort of language that people actually use, and as people speak, so do they search.

The menu structure before the change is shown on the image at the left. Because my site is built with DNN, the URLs are based on the page names, which are also used to generate the menu items. This resulted in a URL of 'What_we_do/Software_Development' for the page.

You can see a screenshot of the Google search results for 'ifinity software development' below. (the fact that Google assumes I mispelled the name - we'll just skip over and cover another day).

The screenshot was taken on May 21, 2008, the day I made the change to the site structure. The relevant URL for the page has been highlighted in red.

The menu structure after the change is shown in the image on the left. The new URL looks like this 'services/software_development/.' It's important to note that I also changed the entire content of the page, rewriting the copy for the page to better reflect what I think people are looking for when they find this page. In terms of search engines, the page is completely different - different URL, different content.

When I changed the page over, I also created a 301 redirect from the old URL 'What_We_Do/Software_Development' to the new page 'Services/Software_Development.' I then monitored search engine bots visiting the new page and whether or not the Google index was properly updated. Within a week, I had my answer from the Google:

This screenshot was taken a week later, for the same search term. As you can see in the red-highlighted area, the page URL was updated, and the page maintained its position in the search results (overall, the site jumped one position, which may or may not be related.) The 301 redirect did its magic, and did so within a week of being issued. Now, you can't rely on 'a week' as the time it takes to get updated. It certainly isn't instantaneous, and it can take much, much longer. There are still some links (a month later) in the index which haven't been updated since my reorganization - these are links which rank low in search results. However, the higher ranked your page, the faster the index will get updated.

Incidentally, you can see my change in the page meta description field, with my 'new' copy intended to encourage more click-throughs from the search results. I'm interested in feedback which seems more 'clickable.'

Checking the Logs

If you're the technical type, like me, you might want to check your website log files to see if the redirect is working as intended. Here is an excerpt from the log files of ifinity.com.au:

 2008-05-22 17:22:25 GET /What_we_do/Software_Development/ - 80 HTTP/1.0 Mozilla/5.0+(compatible;+Yahoo!+Slurp;) - www.ifinity.com.au 301 0 0 473 267 250 2008-05-22 17:22:26 GET /Services/Software_Development/ - 80 HTTP/1.0 Mozilla/5.0+(compatible;+Yahoo!+Slurp;) - www.ifinity.com.au 200 0 0 27433 215 1015 

The first line is the Yahoo bot reading the old URL it expects : 'What_We_Do/Software_Development'. It receives the 301 status code (shown after the domain name) and, 1 second later, returns looking for the new Url of 'Services/Software_Development.' This is the page that ultimately gets indexed and kept, and all old references in the search index are updated. You can see the '200' status code returned after the second URL to indicate that all went OK.

Note: I took some detail out of the log lines for simplicity.

301 Redirects as Repair Strategies

We all make mistakes, and I make quite a few with my own website as I often try out new ideas and software before releasing it to anyone else. One of those mistakes in the past was somehow making the IP address available as domain name. This resulted in a complete, duplicate indexing of my site with associated dilution of ranking and all sorts of other dramas. Once I realized this had happened, I need to correct the index by removing the 'wrong' domain name (the IP address.) You can go through removal tools, but there was a chance that someone had linked to my site using the IP-based domain name. And besides, the site was in the index, I might as well try and merge the sites (ifinity.com.au and the IP address) together.

You can see the problem in the Google result on the left. You definitely don't want this to happen to your site, and if it does, you do want to correct it as quickly as possible.

Again, the 301 redirect is the answer. I built a custom tool which intercepted the IP address based domain, and issued a 301 redirect to the equivalent page using the www.ifinity.com.au domain - in effect, telling search engines that the old domain of 202.60.91.201 no longer exists, and to find all that same information at www.ifinity.com.au'.

The results were successful, a short time after putting in the fix, all of the old IP address indexing had been migrated across to the correct domain name. Although it's not without problems as are still a few references to the IP address still floating around in the search indexes. At least the 301 redirect does put the visitor onto the right page if they click on it, though.

Other Popular Uses of 301 Redirects

Now that you have a basic understanding of using 301 redirects to update search engine indexes, it's time to discuss other applications of the 301 redirect. Mostly, these center around creating 'canonical URLs.' A canonical URL is one that is the 'best' URL for a page - or, if you like, a single URL to unite all the different ways pages can be represented. You absolutely want to encourage canonical URLs for your pages, so that each page in your site only has one single representation. For this it's important to think of a 'page' as a unique piece of content, referenced by a unique URL. So, while /products.aspx?productid=45 and /products.aspx?productId=46 refer to the same physical .aspx page, as far as search engines are concerned, they are two different pages of content.

Taking the products.aspx page a step further, perhaps that same page can be access through additional URLs such as : /products/productid/45.aspx or /products/45/my-cool-product.aspx. These might all show the same content, but the problem is that a search engine might index the first, 5 people link to the second one, and 3 other people link to the third version. You've got the potential for three separate pages to show up in the index, and probably one or more of them will show up in 'supplemental results', otherwise known as 'duplicate content.'

In this case, what needs to happen is for a canonical URL to be chosen by you, and all requests for the page end up at the same URL. The end result is that search engines index a single URL, and anyone linking to your content does so through the same URL. That way, all the value from the incoming links is concentrated onto a single page, giving it a much greater chance of ranking success.

Again, Matt Cutts' blog has a very informative post on this topic : SEO Advice Url Canonicalization.

Having a canonical URL means a single URL for each page of content, no exceptions. When I ended up with an IP address for a domain name, it was the absolute opposite of having canonical URLs. Every single page in my site was available as a duplicate URL.

While you may not have this problem with your own site, you may have another, more common problem : www vs no-www. It's really your choice as a web administrator whether you want to advertise your site as domain.com or www.domain.com. Certainly it makes little difference from a search engine point of view, but what you should be doing is redirecting all the 'www' to no-www, or the 'no-www' to 'www' URLs.

You can take this as far as you want - right down to forcing all versions of a URL to be in the same case (Domain.com -> domain.com) and adding/removing forward slashes (domain.com -> domain.com/). Personally I don't bother with this level as it is my belief that search engines are smart enough to know that 'domain.com' and 'Domain.com' are the same thing. Sure, some Web servers allow content to be differentiated by different case URLs, but most of the time websites will give you the same content, regardless of what case it is requested in. But it's up to you as the website owner and person ultimately responsible for search traffic to make sure it functions the way you would like.

301 Redirects and DotNetNuke

How does all this apply to DotNetNuke-based websites you ask? For a start, there isn't any 301 functionality 'baked' into the DNN core framework. But that's OK, because DNN runs on top of IIS, and IIS has plenty of functionality for forwarding and redirecting. For those in a shared hosting environment without direct access to IIS there is the option of installing third-party products to set up custom redirects.

The three biggest problems with DNN URLs and search engine optimization, as I see them, are:

1. No canonical URL functionality:
   The home page is typically available on the site root (/), /default.aspx?tabid=36, /tabid/36/default.aspx, /home/tabid/36/default.aspx, home.aspx and just plain old /default.aspx.
2. No separation of keywords in the generated Page URLs"
   'My Cool Thing' ends up being 'mycoolthing.'
3. No redirection of deleted or changed pages:
   Once you delete a page, it won't forward you on or show any content.

These three issues can all be remedied by using 301 redirects. There are many ways to do this - either by setting up individual redirects in IIS, using a third-party IIS tool for setting up redirects, or using a dedicated DNN 301 module, of which there are multiple available.

Of course, now is the right time to plug my Url Master DNN Url Redirecting and Rewriting module. This DNN module provide a solution to all of the above problems, and many more. It features automatic 301 redirects to enforce canonical URLs, plus the ability to add custom redirects to handle all types of situations where content has been moved or deleted.

Summing Things Up

With any luck, you have learned what a 301 redirect is, and why you should be using them to maintain and increase your position in the search engine results pages. Once you have established yourself in the indexes, it's important you manage your URLs effectively otherwise all your hard work might just be undone.

Do you disagree with anything? Do you have more to add? Submit your thoughts using the comments field below.

 Permalink       3 Comments       RSS feeds       Email updates

Minimize Duplicate Content by Avoiding DNN's LinkClick.aspx 

Posted by Tom on Wednesday, May 14, 2008 to DotNetNuke, SEO

Almost a year ago in my DNN SEO quick start guide I talked about minimizing duplicate content by crafting “well-formed internal links” and over the last few months many of you wrote in to ask what exactly I meant by that.

We’ll get to the bottom of the issue in a moment, but first let’s refresh the idea of “duplicate content” again. Ideally, every URL of your website should correspond to exactly one unique page within your website. And that’s generally how it worked back in the day when most sites were made up of static HTML pages. That all changed though as larger sites started moving their content into databases and pages were assembled “on the fly.” And as ecommerce and content management systems gained in popularity, multiple URLs leading to the same page became quite common. That in turn did not sit well with Google and other search engines as it undermines the quality of web search results, which sparked rumors of search engines coming down on webmasters with “duplicate content penalties.”

Today, according to Google, there is no need to lose sleep over duplicate content as long as you try to minimize it by reasonable means. One way of doing so is to pay attention to the internal links you create within DotNetNuke. Our number one enemy here is the DNN URL control (also known as LinkClick.aspx), which facilitates link building in modules such Announcements, Links, Text/HTML and others.

 

 

As you can see in the above screenshots, when you go through the steps of creating a link the “point and click” way in the FCKeditor, you’ll end up with an anchor tag that looks like this:

<a href="/LinkClick.aspx?link=53&amp;tabid=56">DNN SEO Blog</a>

Technically this link obviously works, meaning it will take your visitor to the intended page on your site. However, you’ve just produced a piece of duplicated content in the eyes if search engines as you’ve now 2 URLs leading to one and the same page. Furthermore, and maybe more importantly, you are wasting “link juice” or “votes” for the page you are linking to by referencing it via multiple URLs. Here is what the anchor tag should look like instead:

<a href="/blog.aspx">DNN SEO Blog</a>

As a general rule, follow the URL structure as laid out in your main menu. If you have to rely on creating links via FCK’s Insert/Edit Link button, then typing or pasting the URL from the browser address bar is your only option:

And if you think that switching to a different WYSIWYG editor will solve the problem, think again. Telerik’s editor, for instance, creates URLs such as this one when picking from the Custom Links dropdown:

<a href="/Default.aspx?TabName=Blog">DNN SEO Blog</a>

Hardly any better.

The very same problem arises when using the Links and the Announcements module with link counter turned on:

Simply unchecking “Track Number of Times this Link is Clicked?” takes care of the issue here. I like to argue that link tracking is better handled by your web analytics provider instead of DNN itself.

Starting with version 4, DotNetNuke has considerably cut down on duplicate content issues, but the dreaded LinkClick.aspx is still with us to this day. Fortunately, a heightened awareness of what’s going on behind the UI and a basic understanding of what constitutes a well-formed link is all it takes to minimize duplicated content and maximize link equity when linking between pages in DNN.

As always, I’d like to hear from you. Do you consider LinkClick.aspx your friend or foe? What other duplicate content issues have you run into in your daily DotNetNuke adventures?

 Permalink       18 Comments       RSS feeds       Email updates

Search Engine Optimization with ASP.NET Review 

Posted by Tom on Wednesday, April 23, 2008 to DotNetNuke, SEO, Reviews

The DNN module developers and web application programmers that I work with can usually be categorized as follows: SEO unaware, SEO aware, and SEO proficient. Unfortunately and traditionally, the vast majority of them fall into the first two categories, meaning it either never or only rarely crosses their minds that their multi-page modules will be scrutinized by Google and company just like any other web page.

Now Professional Search Engine Optimization with ASP.NET: A Developer's Guide to SEO by Cristian Darie and Jaimie Sirovich aims to change all that. This is the first book on search engine optimization that I’ve come across that “delves at all into the meaty technical details” of SEO and therefore speaks to developers as opposed to only marketers. But then again, SEO is a team effort and I believe tech-minded marketers will appreciate the book as well even without the need to fully grasp every code snippet or regular expression. The exposure to the technical side of SEO helps me as a marketer to effectively communicate with technical folks. Sounds like a “win win” for everyone.

The book starts off with “a primer in basic SEO” for web developers and touches on fundamental concepts such as link equity, Google Page Rank, usability and accessibility. The introduction also looks at search engine ranking factors and distinguishes between visible on-page factors, invisible on-page factors, time-based factors, and external or off-page factors. Search engine penalties such as Google’s supplemental index and duplicate content are also discussed. The intro closes with a listing of resources and tools including web analytics, market research, browser plugins as well as SEO forums and blogs. Concise and to the point – pretty much all developers need to know to start their journey into the uncharted waters of SEO.

Then the book spends 2 chapters on a favorite topic of mine: search engine-friendly URLs and content relocation, also known as 301 and 302 redirection. If you have full control over your web server, you will appreciate the numerous code samples for ISAPI_Rewrite. If you are “stuck” on a shared hosting environment without access to ISAPI filters, the coverage of URL rewriting with UrlRewriter.NET comes to the rescue. The main lesson that I’ve learned from these 2 chapters though is that no matter what method you deploy for URL rewriting, you won’t go very far without at least basic knowledge of regular expressions. No need to worry though as the book does a nice job of “regex hand-holding” whenever applicable and even provides an appendix teaching simple regular expressions. For seasoned ASP.NET developers this won’t be an issue anyway as regular expression are commonly used for string matching and parsing chores besides URL rewriting.

Next up is fairly detailed discussion of duplicate content, which is a common dilemma for database-driven web applications such as DotNetNuke. The authors touch on causes and effects of duplicate content and discuss utilizing the robots meta tag as well as robots.txt pattern exclusion. More interestingly, a code sample and walkthrough is provided for generating robots.txt files programmatically. That way, for instance, all DNN printer-friendly pages could be disallowed “automatically” and on-the-fly!

The remainder of the book devotes chapters to search engine-friendly HTML and JavaScript, web feeds and social bookmarking, sitemaps, link bait, and foreign language SEO among others. A basic case study on “building an e-commerce store” summarizes the main concepts covered in the book and offers a feel for how these SEO-related principles may be applied in the real world.

Without going into further detail, I wholeheartly recommend the book to any ASP.NET programmer and selfishly to any DotNetNuke module developer. I do realize that the more technically folks may never look at SEO as religiously as I do, but that’s not the point. The ultimate goal in my mind is to unite our efforts behind building websites and web applications that perform on the server as well as on the client.

Oh, and in the unlikely event that you are a PHP developer reading a DNN blog, the same author team also published a PHP version of the book.

I have a number of DNN developers on my “blog to email” list and I’d love to get their input. Do you consider SEO at all during module development? If so, what challenges do you face by doing so?

 Permalink       15 Comments       RSS feeds       Email updates

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       19 Comments       RSS feeds       Email updates

DNN URL Rewriter on Steroids 

Posted by Tom on Wednesday, January 16, 2008 to DotNetNuke, SEO, DNN Tips and Tricks

While fighting and ultimately losing an uphill battle against a commercial URL rewriting module last week, I came across Bruce Chapman's blog. To make a long story short, Bruce picked up Scott McCulloch's Friendly URL's slack and vastly build on it and improved it.

Back in August 2007, Bruce first tackled an issue commonly seen in more complex DNN modules: an abundance of URL query string parameters (see any permalink on this blog for example.) Next, Bruce implemented the ability to "automatically" 301 redirect DNN legacy URLs so that established DNN-based websites who have already been indexed by Google and company won't be penalized for duplicated content while taking advantage of the more "human friendly" URLs provided by Bruce's rewriter. This feature alone means a big leap forward for the world of DNN SEO.

More recently, Bruce took things even further and added, among other things, functionality such as "freedom of extension" (.aspx, .page, or whatever else makes your heart beat faster) or my favorite: no extension at all (who said we can't have those nice WordPress URLs, eh?) Due to popular demand, Bruce also put effort into replacing spaces in tab names with dashes and forcing all generated URLs to be lower case. Most features are configurable via web.config.

I still very much appreciate Scott McCulloch's pioneering in this area, but with Bruce Chapman, DNN finally has the attention of a talented developer with an SEO mindset, which in my opinion is an essential prerequisite for success when working on the "search engine facing" parts of our beloved web application framework.

Free downloads including source and sample web.config files are located here (scroll way down.) And don't hesitate to ask installation and configuration questions here or over on Bruce's blog.

 

 Permalink       6 Comments       RSS feeds       Email updates

Performance Tuning DNN with PageBlaster 

Posted by Tom on Wednesday, August 22, 2007 to DotNetNuke, SEO, DNN Module Reviews

Thanks to John Mitchell of Snapsis Sofware, you are reading my first ReviewMe review. And to play by the rules, I hereby disclose that this is a paid blog post and I made a whopping $15.

The timing of John’s request to review PageBlaster for DotNetNuke could not be better, as I’ve come across the module numerous times in my DNN SEO efforts, but I’ve never taken the time for a closer look. We’ve also considered the module internally here at Seablick Consulting to achieve valid XHTML of DNN based websites.

What is PageBlaster for DotNetNuke?

At its core, PageBlaster acts as a performance booster of dynamic asp.net-based websites by compressing, caching, and saving static “copies” of dynamically created web pages to memory and/or disk. Once a page has been saved, it will be served from disk on subsequent page requests as opposed to being assembled “on the fly” over and over again. This decreases page load times and improves the overall performance of a given website or web application.

But there is more. Implemented as an HTTP Module, PageBlaster for DNN touts itself as a “Content Delivery Engine,” which “makes it possible to get complete control over all of the output of all your website’s dynamically generated pages (quoted from the module’s manual.) The module features a powerful replacement engine and is capable of pulling content from the file system and another website. It also has the ability to transform XML feeds.

Module Installation and Configuration

I found the installation instruction rather confusing (especially for the beginning DNNer) and out of order for what is a fairly straightforward process.

Installation step number two asks to “copy the Snapsis.PageBlaster.config file (located in DesktopModules\Snapsis\PageBlaster\Config) to the root of your site and change the settings if needed.” Well, at this point I don’t even have a Snapsis folder in my DesktopModules directory since I have not uploaded the private assembly (PA) via DNN Module Definitions | Install New Module yet, which according to the installation instruction is step number three. So either switch step number two and three or upload the Snapsis.PageBlaster.config that comes “outside” the PA to your website root.

As mentioned above, we are dealing with an HTTP Module here and it therefore requires an entry into web.config’s <httpModules> section. Also make sure to remove or comment out DNN’s native compression HTTP Module in the same section.

Once the module is installed correctly, it goes to work right away according to the default settings for caching and compression specified in Snapsis.PageBlaster.config. Up until this point I’ve only tested the module on a fresh install of DNN with a few test tabs, but I did notice faster loading pages almost immediately.

For finer control and to take advantage of additional features such as virtual paths (friendly URLs) you’ll have to drop the module on every page of your website that you would like to configure. The Ajax-like configuration interface is clean and intuitively laid out. It is divided into “Page Setup” and “Replacements.” The page-specific settings are fairly self-explanatory. Where the module really shines is the build-in replacement engine, which works similar to the “find and replace” function that you may be used to from application such as Microsoft Word or Excel. Replacement rules that you create are broken down and saved into “Page Rules” and “Saved Rules” and make heavy use of regular expressions. No need to feel intimidated though, as the “Saved Rules” folder comes stuffed with the most commonly used rules for a variety of goals such as making a page XHTML compliant. The ability to combine replacement rules is where the real power comes from tough and essentially creates a “scrubbing filter,” which ultimately “cleans” your pages from non-compliant markup.

For details on everything I’ve touched on above and numerous other features I did not mention, I recommend the PageBlaster reference manual and the Snapsis support forum. As a former core team member, John Mitchell is a recognized figure in the DNN community and one of the most active participants on the DotNetNuke forums.

So far I’ve only scratched the surface of what the module is capable of and I’m looking forward to implement it here on seablick.com. Please share your experience with Snapsis Software and PageBlaster for DotNetNuke in the comments below.

 Permalink       5 Comments       RSS feeds       Email updates

DNN SEO Quickstart Guide 

Posted by Tom on Monday, July 09, 2007 to DotNetNuke, SEO, SEM, DNN Tips and Tricks

This post is meant as a springboard for consultants, designers, programmers and end-users who are well-versed in DNN, but who may have some catching up to do when it comes to search engine optimization and search marketing. While I make some DNN-specific recommendations, most tips given here are applicable to any website, build on DotNetNuke or not. So here are my top ten SEO tips in order of priority. Actually, forget the order, it's not worth the fight. Just try to implement as many of these suggestions as you can.

1. Take care of your meta tags, especially the page title and description. Include your most important keywords, but limit your titles to 65 characters including spaces. Choose modules with SEO in mind, such as Ventrian's News Articles, which writes the article title into the page title for you. Furthermore, write unique page descriptions for all your pages.
2. Start attracting relevant links to your website. Note the word "relevant", meaning that some links are more valuable that others. If you are running a business around DNN as we do, then one link from dotnetnuke.com is much more beneficial than all the links in footers of client sites. As attractive links are hard to come by, consider submitting your URL to industry specific directories.
3. Don't skimp on quality copy and content. That's what search engines live off. Use a free tool to do some basic keyword research and then sprinkle them around your copy. Don't forget the spell and grammar check, you are targeting (mainly) people after all. In my opinion, a professional copywriter is the most overlooked member of most web teams.
4. Create an XML sitemap of your website and submit it to all major search engines. I prefer a tool such as xml-sitemaps.com to build my sitemaps over DNNs dynamically created sitemap file. Don't confuse this with a sitemap page, listing links to all of your pages, which is beneficial as well.
5. Place a robots.txt file into the root of your site to guide search engine spiders. Take a look at the robots.txt file of the mothership for a DNN-centric example.
6. Get into the game of local search if your websites promotes a "brick and mortar" business. Many searchers include some kind of local identifier such as the town, city or zip code, which catapults you to the top of the organic search results with minimal effort.
7. Write well-formed, standard compliant HTML to improve accessibility and "crawlability." Consider excessive in-page JavaScript, HTML layout tables and frames junk food for search engines spiders. I'm well aware that strict XHTML remains a challenge with DNN, but let's make an effort to move away from quirks mode by adhering at least to XHTML transitional.
8. Seek an alternative to DNN's default solpart menu and lead spiders deeper into and around your site with well-formed internal links (don't use tracking or logging with the announcement module and pay attention to how your editor of choice "builds" links.)
9. Make DNNs friendly URls even friendlier with 3rd party URL rewrite providers such as this one or that one. These providers do have their limitations though, which is why I recommend them only for small to mid-size websites.
   
   Update: Url Master has overcome the majority of the limitations mentioned above and is now the de facto standart for DNN Url rewriting.
10. Cut down on duplicate content by implementing a 301 redirect from non-www to www or vice versa. I also recommend going as far as hard-coding your login and register links into your skin to further minimize duplicate content created by the "returnurl" querystring parameter.

So there you have it, a high-level overview of search engine optimization techniques geared towards DotNetNuke based websites. Don't be fooled though, SEO and SEM have grown into vast fields with search engines constantly refining and tweaking their ranking algorithms. Another important point I would like you to carry close to your heart is that you are designing and building websites primarily for people and not for search engines. As long as you strive to serve your visitors well, search engines will follow.

 Permalink       26 Comments       RSS feeds       Email updates

The Skinny on Meta Description Tags 

Posted by Tom on Tuesday, May 29, 2007 to DotNetNuke, SEO

In conjunction with my post on the importance of title tags back in March I promised to elaborate on the remaining two fields – Description and Keywords – in the Page Settings and their relationship to SEO.

As I did for title tags, I would like to refer you to a post on SEOmoz.org in order to understand what role the meta description tag plays in your search engine optimization efforts. Rand Fishkin spells things out nicely and there is really nothing for me to add.

One point I do would like to reiterate though. A common misconception is that meta descriptions will help you rank or rank better. This may have been the case in the early days of the Web, but it’s certainly not the case in today’s search engine landscape, especially with Google. Some people do think that Yahoo! still ranks on meta descriptions, I don’t.

Think of it more along the lines of writing a pay-per-click ad (as Rand points out, that does not mean the same copy works for both though.) Your main goal is to entice people to “click through” to your website once you made it onto relevant search engine result pages.

As far as the Keywords field is concerned, I would not waste any time on it. DNN 4.5.x even does some “auto fill” now based on the Page Name field. Just leave that and move on.

What's your take on the meta description tag? Let me know in the comments.

 Permalink       3 Comments       RSS feeds       Email updates