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

digRotate Case Study and Review 

Posted by Jeff on Monday, August 04, 2008 to DNN Module Reviews, Screencasts

A short case study on how we used the digRotate DNN module to create an ad rotator.

 Permalink       3 Comments       RSS feeds       Email updates

DNN Documentation for Developers 

Posted by Tom on Friday, August 01, 2008 to DotNetNuke, DNN Friday, DNN News

The lack of documentation, especially centralized, up-to-date documentation, has been ailing the DotNetNuke community ever since the project’s birth. To somewhat rectify the problem, at least for aspiring developers, Ernst Peter Tamminga recently scoured the DNN core, extracted all comments that do exists in the code, assembled it in CHM format, and put it up CodePlex. While this is certainly a step in the right direction, comments, or valid XML comments, are still utterly missing for most public methods in the DNN core.

Now on to documenting this week’s news.

• By the time you read this, DotNetNuke Websites Problem Design Solution by Tracy Wittenkeller will be available from a bookstore near you or your favorite online retailer. I’ll share my thoughts on the book as early as next week.
• A recent upswing in automated SQL injection attacks targeting ASP and ASP.NET based websites has caused concern and confusion for many DNN webmasters. DNN’s security expert Cathal Connolly addresses the issue here and Microsoft’s security advisory can be found here.
• XHTML compliance has been a hot topic lately and Timo Breumelhof sheds more light on the matter and explains what it means for DNN module developers and skinners as we move closer to Cambrian.
• Ever thought about getting your feed wet with DNN module development? Then check out Rafe Kemmis’ blog as he “screencasts” you through creating a DotNetNuke module from scratch.
• And speaking of screencasts / videos, Jason Kergosien of Ingen Systems takes a closer look at the skinning enhancements delivered by DNN 5 Beta 6. Be warned though as this 30 minute “NukeCast” may easily eat up your lunch hour.
• Robert Harriman of Webmazing.net releases AutoWebSuite / BrokerWebSuite 4.0, a set of DNN modules for handling vehicle and real estate inventories. Online demos are available and you may also try before you buy. I’ve deployed a number of previous versions of the modules and highly recommend Robert’s craftsmanship and support. Watch for a closer look at the latest version in an upcoming review on this blog.
• Hector Sosa of SystemWidgets put together a neat little Windows application to recover and reset DNN passwords. I haven’t had a chance to try it yet, but it’s evident that it makes a great addition to any DNN amdin’s tool belt.

What are your thoughts on the current state of DotNetNuke documentation? As any kind of documentation is not a small undertaking, how is it best addressed for a software application such as DNN? How much longer can DNN Corp. afford to cite limited resources as the main culprit for missing and out-of-date documentation?

 Permalink       3 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

10 DNN Admin Quick Tips 

Posted by Tom on Tuesday, July 22, 2008 to DotNetNuke, DNN Tips and Tricks

Here are 10 somewhat lesser known “quick tips” for DotNetNuke administrators described in no more than a sentence or two and implemented just as quickly.

1. Module Header & Footer Text

   Use the module header and footer text boxes (Module Settings > Advanced Settings) to inject short snippets of text and / or HTML above or below any given module. No need to drop additional text/html modules.

2. Registration Copy

   I still see way too many sites with the default copy of “Membership to this portal is Private / Public / Verified. …” Change it via the language editor at Admin > Languages > Global Resources > SharedResources.

3. Login / Register Links

   And while you have the language editor running, customize the anchor text of commonly used skin tokens such as Login, Register, Terms, and Privacy at Admin > Languages > Local Resources > Admin > Skins. Alternatively, most of these tokens support a “text” attribute for overriding the anchor text directly in skin.ascx:
   <dnn:login runat="server" id="dnnLOGIN" text="Sign in" />

4. Page Header Tags

   Tucked away in the advanced page settings is a field that allows you to specify additional meta tags on a page by page basis. For instance, to keep Google from archiving the page, enter <meta name="robots" content="noarchive">.

5. Installation Date

   Ever lost track of when you or your hosting provider installed DNN for your site? The “InstallationDate” key in the appSettings section of web.config will tell you.

6. Terms of Use & Privacy Statement

   The default terms and privacy notice are meant as a general guideline only. If you are running a “high profile” site, have the documents reviewed by a legal professional and edit accordingly via Admin > Languages > Global Resources > GlobalResources (message_portal_terms.text and message_portal_privacy.text.) Even if the default copy is sufficient for your needs, mask the email address in the last paragraph of the privacy statement to avoid spam.

7. Website Administrator

   You have entered a valid email address in your DNN profile and double-checked the SMTP server settings and still don’t receive admin notifications from DNN? In case of multiple users with admin rights, you need to set yourself as the site administrator at Admin > Site Settings > Advanced Settings > Other Settings.

8. Module Title

   The module title field accepts roughly 250 characters including HTML/CSS. That’s good enough for little tricks such as adding a small image, link or vary the font size of words in the module title. Just don’t overdo it.

9. Copyright

   Similar to the module title field, I often enter additional information such as contact details into the copyright field (Admin > Site Settings > Site Details), which then conveniently display in the footer of your pages or wherever else you placed the copyright skin token.

10. Module Installation Timeout

    As modules get more sophisticated and provide more features and functionality, the file size of private assemblies (PAs) naturally grows as well. This may lead to HTTP session timeouts when uploading PAs the conventional way (Host > Module Definitions > Install New Module.) While there are means to increase the session length in web.config, I prefer to simply FTP upload the PA zip file into the Install\Module folder on the web server and then change the file extension from .zip to .resources. Subsequently, the module is listed in the Available Modules section of the Modules Definition page and installation can resume from there.

At least half of the above suggestions should be applicable to any DNN version, while the other half is geared more towards DNN 4 and above.

As always, I encourage you to voice your thoughts in the comments below. But for this post, I would love to see you share additional DNN gems that you have discovered while working with the framework.

 Permalink       7 Comments       RSS feeds       Email updates

DNN OpenForce 08: Intro to SEO with DNN 

Posted by Tom on Wednesday, July 16, 2008 to DotNetNuke, DNN News, OpenForce 08

I'm happy to officially announce that I’ve been invited to speak at DotNetNuke OpenForce North America 2008. As last year, the 3 day conference is co-located with Microsoft’s DevConnections and held November 10 – 13 in Las Vegas.

Besides my DNN search engine optimization presentation, I will join forces with my good friend Vasilis Terzopoulos for a session on Advanced Skinning with DotNetNuke 5.0.

Intro to Search Engine Optimization with DotNetNuke will focus on the basics of on-page SEO such as HTML meta tags, quality copy, and standard-compliant skins. I’ll also touch on XML sitemaps, robots.txt as well as modules and tools used to impress Google and company. No previous online marketing and SEO knowledge required.

In Advanced Skinning with DotNetNuke 5.0, Vasilis and I will attempt to take your skinning skills to the next level by sharing advanced skinning concepts and techniques which we have deployed for clients like NYSE Euronext, the Georgia O’Keeffe Museum and our own sites. And in time for Cambrian, we will demonstrate how to take advantage of the new skinning capabilities introduced in DNN 5.

For further details including the entire speaker lineup, sessions, venue and registration info visit OpenForce08.com or DevConnections.com/openforce. OpenForce Europe 2008 info is available here.

Hope to see you on the Vegas Strip!

 Permalink       0 Comments       RSS feeds       Email updates

Cambrian (DNN 5.0) Beta 6 Out Now 

Posted by Tom on Friday, July 11, 2008 to DotNetNuke, DNN Friday, DNN News

Last Sunday, beta 6 of DotNetNuke Cambrian has been made available to a larger group than previous betas including DNN Marketplace vendors and project sponsors. According to DNN Corp, this release includes a number of significant bug fixes and provides a first glimpse at the enhanced skinning engine together with the initial release of a new default skin. I’ve just installed beta 6 and will share first impressions next week. Here are other noteworthy tidbits from around the DNN world.

• Speaking of DNN 5, Nina Meiers has blogged extensively about beta 5 in a 3 part series covering host settings, extensions, and the new skin uploader. Never shy of words, Nina does a good job of filling the usual documentation void left by DNN Corp.
• Cuong Dang launched dnnGallery “with the goal to create a one-stop resource for all business, designers, developers, and DotNetNuke experts to showcase their work.” Currently the site features mostly Cuong’s own creations, but over time it will hopefully grow into a rich collection of “DNN art.”
• Out of the same Engage camp comes Chris Hammond who officially launched DotNetNukeBlogs.com, which acts as an aggregator of DNN related blogs from around the Web. Assuming that Chris can convince relevant bloggers to sign on, the site has great potential to grow into a valuable resource especially for DNN newcomers.
• With the support of resident skinner and developer Vasilis Terzopoulos, MitchelSellers.com entered the month of July with an attractive new skin … it was about time Mitch :)-
  
  Mitchel also announced a book deal he recently signed with Wrox, a division of Wiley Publishing, Inc. Professional DotNetNuke 5 Module Development is anticipated to hit shelves at the end of 2008. Congratulations!
• The start of the summer also brought a few new DNN Project releases including Wiki, UDT, Repository, and Events. Get them here.
• AliCommerce announced the highly anticipated 2.0 release of its ecommerce module suite. I’ll publish a detailed review of the module later this month.

What did I miss this week? Feel free to contact me with suggestions or better, contribute via the comments below.

 Permalink       5 Comments       RSS feeds       Email updates

DNN Social Networking: An Interview with Will Morgenweck 

Posted by Jeff on Thursday, July 03, 2008 to DotNetNuke, Podcasts, Interviews

This is the first in a series of DNN audiocasts we have in store for you. Our goal is uncover the latest DotNetNuke trends while exposing a bit more of the human color lurking behind all this technology.

This show features Will Morgenweck, president of Active Modules, Inc. In this 20 minute interview, Will openly discusses his company, products, and development philosophy. Topics include:

• Will’s path to DNN
• The evolution of Active Modules, Inc.
• Reasons for choosing Active Forums over other Forum solutions
• Active Modules’ focus on the business market
• The impact of Web 2.0 on Active Modules' product line
• The recent acquisition of DNNFusion’s social networking modules
• Thoughts on social networking in Cambrian (DNN 5) and beyond
• Details on the next major release of Active Forums

Click the Play button above or download the audiocast for offline listening.

 Permalink       4 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

DNN 4.8.4 Released 

Posted by Tom on Sunday, June 15, 2008 to DotNetNuke, DNN Friday, DNN News

Shortly after attending OpenForce Connect Orlando, DNN Corp. released 4.8.4, which fixes 3 low-level security vulnerabilities (DNN 2008-8-L, DNN 2008-9-L, DNN 2008-10-L) that have been reported after the 4.8.3 release. Other news next.

• Half of the OF Connect Orlando speakers have made their session material available for download on orlando.dotnetnukeug.net. Event photos by Will Strohl have been posted as well. I don’t see anything on OpenForce08.com yet.
• Brisinger Group, Inc. released SCORM LMS Portal Online Training Edition, “a fully DNN integrated SCORM compliant online training system.” Demo here.
• Dave Bush has written a number of DNN-related blog posts and tutorials on his site at blog.dmbcllc.com. Go check’em out and leave comments as every blogger appreciates that.
• Shaun Walker blogs about DNN trademarks in a two-part series (post 1 here and post 2 here.)
• Team lead Antonio Chagoury sheds light on upcoming Blog module features including social bookmarks, SEO improvements, and gravatars in a three-part series of blog posts.
• Skinner and blogger Cuong Dang offers advice on how to buy a commercial DNN skin. A well compiled list.
• And finally, Bruce Chapman elaborates on 3 important on-page SEO factors (page title, description and URL) and how they impact click-through rates from search engine result pages.

Did I miss something or got something wrong? Comments are always appreciated.

 Permalink       2 Comments       RSS feeds       Email updates