DNN SEO and all that search engine friendly stuff
Since 2003, I started looking at friendly URLS because I came out of a DNN 1.0 build, through to DNN2, and the inclusion of more menu items saw users coming to upgraded sites, looking at new 'admin tabs' and therefore coming to a page requiring a login.
Originally we saw urls with DesktopDefault.aspx as being the primary url but as time progressed, a request to change to the standard default.aspx became a reality, and whether this was for security (eg, not being able to easily identify a dnn site) or simply practicality is probably not relevant, but you'll see in most dnn builds the DesktopDefault.aspx file redirects to default.aspx.
So, we have DNN progressing further, more menu items being available in the admin pages, so now a dilemma – our upgrade of DNN has now set us up to have our admin pages being requested. So our content on the site has been mixed up because originally tabID 36, which was the starting page for thousands and thousands of dnn sites no longer works.
And, the way we create our pages might not always be in the same order, so people keep getting redirected back to the home page which DNN does if it can't find the required page.
Take into consideration you've spent lots of time creating your pages and information, and wow, all gone each time you choose to redevelop the site, instead of upgrading and now people are going to the wrong pages, since the tab ids are mixed up.
And here's a little secret you might not know about the standard DNN urls – they are a bit strange in how they work.
let's have a look at this two urls –
http://shop.volleyball.com/Closeouts/tabid/183/Default.aspx – that takes us to the Closeouts page – but let's see what happens when we change the tabID to 187 – so the url looks like this –
http://shop.volleyball.com/Closeouts/tabid/187/Default.aspx
But now we're on another page, but Closeouts still shows – so in reality these urls don't work like they should or are a bit pointless in my opinion, afterall, what is the purpose of urls that can be changed and don't work? If you don't believe me try it on your own site if it's an out of the box DNN build.
Here are a couple of good options.
You can manipulate the URL output on the site using different third party products, including Snapsis PageBlaster – it has some powerful features, but is not a straigh URL rewriter in the sense many people think. It allows you to run multiple domains and display completely different urls within the site, but are in fact just pages to the site – so could be an excellent option for landing pages. Or if you have several domains with different topics you could use PageBlaster to output a site that has a different skin, different topic and still connected to your current domain.
Now, we have third party URL rewriters that don't require any access to IIS to modify, and behave slightly differently.
I have really only used the htp://www.inventua.com url rewriter- in both standard and IIS modified site structure and found it's worked for me, but does require some thought in the way the pages are named.
I found that on deep sites with hiearchial menu structure where there is a top level topic, with sub pages that named the same under it, you need to consider how the page name is written. But I think from an SEO perspective,you should be thinking of page names anyway- so in my opinion, it works well.
I use the Page Title extensively so that I can have an indpendent page name, but we utilise third party menus, which allow us to display the menu as page title, not name, and compensates for the way we name the page, and it's output in the address bar, and subsequently the way it's picked up by google.
Inventu HRef Exchanger does not use any folder path, every page in the site must have a unique name. And for some they think this is alot of work to maintain. You can't use page names that exist in the Admin/Host menus or any administration page. Even though we're using these friendly urls, it will still be looking through the TabID and an example I came across which caused some problems (easily fixed though) was with the Catalook store when I had an adminstration page for looking at orders and I had a registered users page for looking at orders. When the user logged in, the 'you don't have permission to view this page' text kept displaying and wouldn't let users view their orders.
What had happened was the orders page, for the store administrators had been setup first, therefore had a tabID that appeared first, the role was checked and of course was for store orders, not customer orders, and the custome couldn't ever view their orders until we renamed the page. That was the worst case scenario that occured using this type of url management. But the cool thing to remember is that duplicate named URLS always show as a tabID. It defaults back to the non friendly URL. Another thing to remember is that when logged in, friendly urls don't show – and when using the HRef exchanger, you need to turn OFF friendly URLs in the checkbox.
I have found this solution has been ideal for me and I implement and recommend on all our sites.
The down side to this is that if there is no page found it comes up with one that's not really good looking, but recently I was told I can use a custom page to make the output more friendly and intuitive.. why I hadn't looked at that earlier – I don't know but will be giving that a try.
Now, when it comes to using your own extension – like I have done
http://www.xd.com.au/home.xd
http://www.chalkartstudio.com/home.chalkart
http://www.style.net.au/home.hardware
It's a subjective thing here – How much real benefit has it been. You need to modify IIS and it does have a little overhead to it, but I suppose from a unique point of view, perhaps disguising it's dnn site, then it's an option.
I asked why we couldn't simplyl use html, but have been advised that it was not the ideal thing to do and might cause other issues that I can't remember, but once I was told by the developer it wasn't advisable, why perservere. Obviously they had their reasons.
I like using this as well when working with child portals – I hate that alias it puts in the address bar.. that to me is just horrible and as soon as I had a way to NOT use it, I thought – OK that's what I'll do.
Here's an example –
http://www.skinsforsale.com/Default.aspx?alias=www.skinsforsale.com/xflex how UGLY – but with the friendly urls – it doesn't take long to get a nicer looking extension in there –
http://www.skinsforsale.com/xflex/home.aspx – much nicer – and it's carried throughout the whole website -
http://www.skinsforsale.com/xflex/xflexbonus.aspx – this implementation is easy – it's a matter of adding the dll, making some changes to your config file (backup original one first of course) and then turning friendly URLS OFF in the Host/Settings area and you'll be on your way to having SEO friendly URLs for DotNetNuke.
I haven't explored the http://www.ventrian.com friendly URLS but it seems to also look pretty good. This method of URL management allows you to use a hierarchy structure – eg..
http://www.ventrian.com/Products.aspx
http://www.ventrian.com/Products/Modules.aspx
http://www.ventrian.com/Products/Modules/ChildLinks.aspx
As you can see – neat, clean navigation.
It uses the No Space between names for managing pages with more than one word in the page name.
HRef uses the 'replace space with a – or +' which looks great, is intuitive and easy to remember, and is in my opinion the first choice, with Ventrian, being the next one, however, my thoughts change based on the depth of the sites – and in some larger portals that requird alot of categories and sub pages, Ventrian might very well be the best way to go.
http://www.dnnsoft.com/SupportbrnbspnbspnbspnbspService/ReferencesLiveStores/tabid/74/List/1/CategoryID/3/Level/1/Default.aspx?SortField=ProductName,ProductName – (160 characters in this URL)
It stops long names like this – which, I think should have friendly URLs turned off, rather than show the flaws DNN has when it comes to managing friendly urls.
What is good about the DNN project is that it allows you to extend the url functionality further, so although I'm saying the DNN ones are not really worth much, the key factor here is – you have the power to change it, without being a developer, and marketers can benefit working the 'third party' solutions a little further to their advantage.
I hope you've learnt a little bit more about URLS and how to improve SEO rankings on your DNN site, but remember, content is King – you can have the worst urls and still improve your rankings if you have good content on your site. You need to consider this in the mix of site development and marketing.
Nina Meiers