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       19 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       14 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       18 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 Review

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.
   
   
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       21 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

Get Reviewed by This Blog 

Posted by Tom on Tuesday, May 22, 2007 to Online Marketing, Seablick News, SEO

If you have not heard about ReviewMe yet, it’s a service that brings bloggers and advertisers together in an almost unique way. Advertisers request reviews from bloggers of their choice through the ReviewMe website.

You may be skeptical about pay-per-post blogging, but ReviewMe gives bloggers substantial freedom in regards to what and how to write about a given subject. That means that all reviews do not have to be positive as long as they are at least 200 words in length (about as long as this post, will most likely be much more for me though) and contain a disclaimer that points out that the review post is being sponsored.

It works nicely for advertisers as well. Let’s assume you are a DNN module vendor or you sell DNN skins. A review from a DotNetNuke centric blog such as this one will create community buzz more quickly than a lone post in the dotnetnuke “Announce It!” forum. And you get the added SEO benefit of a one-way link back to your website.

The current ReviewMe fee for this blog is a steal of $30 and will only go up as traffic increases and more RSS subscribers come onboard. So I suggest you take advantage of this deal and order a review today!

 Permalink       0 Comments       RSS feeds       Email updates

Search Engine Friendly 301 Redirects Without Touching IIS 

Posted by Tom on Friday, April 27, 2007 to DotNetNuke, SEO, Reviews, DNN Tips and Tricks

Most websites are configured to serve the same content (the home page) for www.mysite.com and mysite.com, but technically a web server could return two different pages for both urls. Why is this important? It could hurt your ranking and you are making Google and other search engines guess what page to index if there are numerous choices to choose from. Google calls this process of selecting one URL over another “canonicalization.”

So what can you do to ensure that Google picks your preferred URL?

For one, be consistent when forming your internal links. In other words, “don’t make half of your links go to http://example.com/ and the other half go to http://www.example.com” as renowned Google engineer Matt Cutts points out.

Secondly, implement a 301 permanent redirect from the non-www version of your site to the www version or vice versa, which is what I would like to focus on in this post.

While the web is full of examples on how to setup a 301 redirect on the all so popular Apache web server, IIS walkthroughs are rather scarce. And even if you do find them, most are on-page scripts that won’t solve the www vs. non-www dilemma and won’t work in DNN’s “one page” model.

Let’s say you want to permanently redirect the non-www version of your asp.net based website to the www version. The most straightforward way to do this in IIS is to actually set up two IIS web sites for your web site. Sounds confusing? See the screenshots below.

Set up your www version as you would any other website. Include the www portion when entering the host header value and point to the DNN web files on your server.

Now create a second IIS website and enter the host header value without www and point “the content for this resource” to your www URL like this:

Notice the two variables ($S$Q) at the end of the URL, which ensure that all other pages besides the home page redirect correctly as well. Also make sure to have “the exact URL entered above” and “a permanent redirection for this resource” checked.

If everything went well, your browser will now redirect mysite.com to www.mysite.com. Another option is to install a component such as ISAPI_Rewrite, which emulates Apache's mod_Rewrite for IIS, but that’s food for another post.

Both of these approaches obviously require full IIS access, which is not an option in a shared hosting environment. But even with unrestricted IIS control, if I were to set up two IIS websites for every client on my web server, IIS would get messy very soon.

This leads us to the most elegant solution that does not involve IIS at all - UrlRewritingNet.UrlRewrite. With this open source component (HTTP module on steroids I guess) you upload a .dll into the bin directory of your website and add a few lines to web.config and you are done. Now you have a search engine safe redirect from mystite.com to www.mystite.com or vise versa without touching IIS. I’ve prepared a DNN 4.5.1 web.config with all three UrlRewritingNet.UrlRewrite settings in place for your reference. Download it here.

Best of all, this only scratches the surface of what UrlRewritingNet.UrlRewrite is capable of. With full regular expression support and the ability the plug in your own provider, the “rewrite opportunities” are endless. As an example, I’m currently trying to figure out how to shorten my permalink URLs, removing the tabid/53/articletype/articleview/articleid/xx/ part.

In closing, whatever method you prefer, make sure your redirects are configured correctly (301 and not 302) with a tool such as the Search Engine Friendly Redirect Checker.

As always, I appreciate your comments and if you like this post, then consider subscribing to my full feed RSS.

 Permalink       68 Comments       RSS feeds       Email updates