This isn’t really a “whitepaper” in the literal sense, but rather a cheat sheet to help you identify all of the areas in DotNetNuke that you can take advantage of in order to effective leverage your Search Engine Optimization (SEO) strategies. Nearly all of these SEO settings and features have been around for a long time too.
Search Engine Optimization is simply a term used to describe the process of constantly optimizing your website to be indexed easier and faster – and better indexed than competitive websites. The exact methods and techniques you use will sometimes change from week to week, but the tools used to employ your strategy generally remains the same.
If your website is publicly visible, and if it has ANYTHING to do with your business making money – SEO SHOULD BE IMPORTANT TO YOU. Most companies that are serious about this have one or more people on-staff or contracted full time to get the most out of SEO.
DotNetNuke is well-known for many things – not the least of which being how extensible it is. In fact, many people refer to DNN as being their box of legos to build websites with. I haven’t heard a better analogy. With legos, you have various colors to work with that will help you build a better "thing.” DNN offers this to you as “features” – one of which being SEO-related. There is not another commercial or open source content management system (CMS) out there that even approaches how well DNN can be leveraged for SEO.
Here are the areas that I am going to talk about:
The menu systems in DNN are all dynamic. The menu itself is extensible – so you can switch out the menus as needed to get a better look. However, for SEO, you might be looking for menus with better (X)HTML markup. A great menu for this is the DDRmenu by DNNGarden.
Your menu should use the lowest amount of HTML, and be XHTML compliant. Also, it should use semantic mark-up to help the search engines determine navigational priorities of pages in your site.
The menus not only show you how to navigate throughout your DNN site, but the navigation you see is directly related to the URLs and the URL Provider (in most cases). More on that below.
The menu systems work in tandem with the URL Providers in DNN. The URL Provider creates and parses the URLs, and then various elements in DNN inherit the URLs, including the menus. How your URLs are created is extremely important. A URL that is human-readable is also search engine-friendly. That is, the URL gets indexed by search engines too, and it arguably one of the most important elements in your SEO strategy.
For example, if you create a page on the root of your site with the name About Us, the page URL will be http://yourdomain.com/AboutUs.aspx with the default providers in place. If you add another page as a “child” of About Us called Corporate Info, then the URL for the new page would be http://yourdomain.com/AboutUs/CorporateInfo.aspx. This how the page and URL structure will be begin to build. The menu system, like the URL, will continue to build this way, unless you customize the existing URL Provider, or install a 3rd party one.
The URL provider that ships with DNN is pretty good. However, there are three very good providers out there that you might want to look at as a possible replacement (in no particular order):
Whatever URL Provider you use should allow you to specify your own URL structure, handle URL duplicates, and help to manage many other URL-related SEO concerns, as needed. Your URLs should be as short as possible, contain contextual keywords, and not have any file extensions, if you can avoid it.
Each page in DNN has its own settings area that can easily be reached using the Control Panel at the top of the page. That is, if you’re authorized to see the Control Panel. Within the Page Settings, you can manage:
One of the cooler features that many people don’t find right away is that DNN comes with a pre-generated XML Site Map. This site map is dynamically generated using the context of the user currently logged in, so the majority of the time, it is populated only with pages that don’t require a login. You can find this page on any of your DNN sites, by simply adding /SiteMap.aspx to the end of the root of your site. Using the previous example, this might be http://domain.com/SiteMap.aspx.
XML Site Maps is a commonly adopted standard adopted by all major search engines, as a way for webmasters to tell the search engines what the structure is of their site, and what portions of the site are more or less important than the rest. This gives some very meaningful information to the search engines to help you properly index and weigh the various pages in your site.
The Site Settings is a page available to you that helps you set the high-level settings required for the site to function properly. This include visual elements, security, and more. It also includes a few critical SEO-related settings.
One of the newer SEO features in DNN is the Search Engine Sitemap page, found in your Admin menu. This allows you to manage how and if your page-level Site Map Priorities are being used.
There are a variety of settings to help fine tune how your XML Site Map is generated for you. This is especially useful for larger sites that have too many pages. If you go over a certain number of pages in your XML site map, some will be ignored and never seen or dealt with when the search engines parse the XML.
There is an additional benefit here though. You can also configure if the site map is cached, and for how long. This is a great feature for sites that are concerned about performance.
All editions of DNN (Community, Professional, Enterprise) have a Google Analytics (GA) Module included and installed by default. This helps you to easily include your code required for your site to begin generating SEO-related data. You can also use the URLParameter setting to help with campaign tracking.
Professional and Enterprise Edition both take this implementation a couple of steps further though. For example, they support advanced segmentation, and multiple URLs.
Telerik has long had arguably the most popular and feature-rich ASP.Net controls in existence. With over 70 controls included in the suite that are all top-notch, this continues to be more and more true with each release. This is for many reasons… They all:
For all of the reasons above, and more, the Telerik controls are now shipping with DotNetNuke, with a couple of conditions. In order to develop or design in DNN using the controls, you will need to purchase a developer license through Telerik ($999 each), or use the built-in wrappers that come with DNN’s API. Professional and Enterprise Edition customers get an unlimited number of Telerik developer licenses free as part of their DNN subscription.
The last bullet point above is the most important for the context we’re talking about right now. The controls all emit XHTML compliant mark-up, and in cases where the controls allow you to create mark-up, the resulting mark-up is also XHTML compliant. (There will be more on XHTML compliancy later.)
A great example of this is the RadEditor that is enabled by default in DNN. This editor allows you to not only create XHTML compliant code without knowing how to do it, but it also allows you to strip out unwanted or unnecessary mark-up using its toolbar.
These controls (or controls like them) should be an integral piece of your puzzle if your content will be managed or contributed by people who don’t know or care about SEO techniques.
One of the biggest strengths of the DNN platform since around version 2 is the robust skinning engine. It was built from the very beginning to be highly flexible and designer-friendly. This vision continues today. Designers can easily create compelling and interactive layouts and designs without knowing any .Net code, or how to create a “Master Page.” Building a skin in DotNetNuke is simply creating and defining the layout(s) for the entire site and its modules.
Designers can use any technologies and tools that they are comfortable with, including jQuery, Telerik, CSS, XHTML, Flash, Silverlight, and more. They can have Pure CSS/DIV-based designs, or Table-based designs. The tools that they use are up to them. You can use Notepad, Dreamweaver, Microsoft Expression Web, or any other HTML designer.
When a skin designer is planning how their skin will be put together, SEO should be a main component of their plan. For example, there are ways to put your content at the top of the page, and then move it down using CSS. Using this technique, you can have your search engines see the most relevant HTML content first, ignoring the other less-important portions of the HTML mark-up. However, when your visitors see your page, it looks just as you want it to.
The design should also be XHTML compliant. This is for many reasons, but I will talk about only a couple specifically. First, like your visitors, search engine spiders are impatient. DIV based designs that are XHTML compliant load faster than others. This is because there’s no additional overhead of trying to determine the DOCTYPE, or fix bad HTML. When Tables are used, the web browser has to wait for the entire table mark-up to load before the UI it is displaying will be loaded.
Pure CSS designs are also better for SEO. This technique allows you to not only have a highly customizable design (saving money in the long-run), but it also allows you to leave out a TON of mark-up from the static HTML portion of your design. Instead, it’s all defined in your cascading style sheet.
Your skinning strategy should be loosely defined by a simple principle... The less HTML the search engines have to parse, the more likely it is that your content will be the portion of the HTML that is indexed, and indexed thoroughly.
A skin widget can be added to a page and used by anyone with content editing authority on a DNN site. They can also be used quite extensively by skin designers to help with a variety of needs.
A great example for SEO, the built-in Relocation Widget (also called SEO Widget by some) will allow you to put your content even higher in your HTML design then is allowable by CSS alone. When the page is loaded, the content appears exactly where it should be when your site visitors look at the page. Ryan Morgan (Managing Partner at Arrow Designs) also blogged about how to use the Relocation Widget for this purpose in great detail.
You can see more examples of widgets that can help with a variety of needs in the Widget Suite for DotNetNuke.
One item that I don’t see much support for right now, but is incredibly important is the Robots.txt file. This is a file that tells search engines what they are and are not allowed to crawl. This can also be done at the page-level, but is generally best to be consolidated in this single file.
Since a single DNN installation can host an unlimited number of websites, this is a complicated topic and even more complicated of a proposition to manage from a technical perspective using DotNetNuke extensions.
On the surface, this sounds like an easy thing to fix, and in some regards, it is. But in a multi-portal environment (multiple sites hosted in the same instance of DNN), this is very difficult to manage – but not impossible. In most cases, this is a reason for some site owners to only host a single site per instance of DNN.
I only know of a single 3rd party extension right now that attempts to solve this issue, and it’s the Packflash Friendly URLs, SEO, and Sitemaps module. While this feature was lightly demo’d to me, I have not actually tried it myself.
I have said for a long time now, that DotNetNuke is the only commercially available and open source CMS that comes close to having a complete SEO-friendly solution out-of-the-box. Even though I have given some suggestions for alternative 3rd party solutions, this remains to be a true statement. Using this blog post as your guide, there should be nothing to keep you from getting serious about SEO with your DNN website.
Is this all that you can do with DotNetNuke to leverage your SEO strategies? The clear and definitive answer is, “No.” There are numerous other areas where companies that specialize in SEO-related websites take advantage of not only the UI elements I’ve described, but also several other areas of the architecture and API. The sky is the limit… Get creative!