I think DNN is quite friendly already:
See example:
http://www.dnngear.com/
if you hover your mouse over the "Modules" link, you'll see the URL is
http://www.dnngear.com/DotNetNuke-Modules.aspx
if you drill down further down the modules, each of the modules, you'll notice the urls are:
http://www.dnngear.com/<modulename>/dotnetnuke-modules-<moduleid>.aspx
This is not the way how DNN normally writes the urls out. However, it offers the possibility of mapping the urls to parameters in the SiteUrls.config
In the page settings you can specify which URL you want to point the page to, this might be http://www.yoursite.com/anything-you-want.aspx and if you grab the url in the SiteUrls.config, you're done. You can pass even parameters through or hard code them in the siteurls.config
So it's NOT that DNN couldn't offer this. But most of the 3rd party modules do not offer the possibility to define how you want the modules to write out the urls.
Of course, if they use the FriendlyUrl provider of DNN, then it's the DNNs task to define how the urls are written out. But then again, a 3rd party module might have 6 or 7 url parameters to play with so how do you control the endless alternatives out there? So there must be some central way of doing the rewrite and as long as DNN is concerned, it has that in the core.
The rest is up to the modules to offer an override capability of how the friendly urls are written out.
However, application needs parameters to run. In most cases a 3rd party module in DNN needs 4 querystring parameters
tabid for DNN itself to know which page to show
mid to make sure we use the right module on the page
itemid to show the right item in the module
ctl to tell what we want to do with the item
So ultimately this might be as short as
www.somedomain.com/1/1/1/1.aspx (in case all the id's were 1)
But the human friendliness tells us to use words. Also some SEO experts suggest to use words as the engines use them
So we come up with
www.somedomain.com/home/articles/how-to-build-a-site/show.aspx
However, that is not meaningless for an application. Application needs to know which parameter is which. Or then we'd need really strict rules on querystring parameter creation and ordering for the developers to figure out how they should write out their urls. However, this isn't too flexible.
So, for the DNN itself, we need the keyword tabid to define which parameter is coming next, and we need to say ctl and mid to tell which module to pass what. And of course which article we want to view. So ultimately, as we want to have also the keywords in the urls, we'd come up with
http://www.yourdomain.com/home/tabid/91/ctl/view/mid/475/articleid/9/thearticletitle.aspx
Which is quite the way how DNN does it currently.
If I'd rewrite that, I'd do it:
http://www.domain.com/dotnetnuke-articles/TheArticleTitle-9.aspx
Then map on SiteUrls.config
<RewriterRule>
<LookFor>.*/dotnetnuke-articles/[^-]+(\d+)\.aspx</LookFor>
<SendTo>~/Default.aspx?tabid=91&ctl=view&mid=475&articleid=($1)</SendTo>
</RewriterRule>
In a way, I've just told DNN that I've reserved the string /dotnetnuke-articles/ for my use here and that I hardcoded all the other values except the article id which I pass in in the end of the url.
when I type the url, the article is shown without problem. Everything works. However, I need the source for the module to make the module write out these new urls too. Unless the module itself provided an interface to do this. (ie, set a tag '/dotnetnuke-articles/', hardcode tabid, ctl and mid to it and pass the articleid). After the module gives you this, it can surely write this to the SiteUrls.config and DNN will surely follow the rules in it.
I believe what you're talking about here is a 3rd party module issue, not a DNN issue.
I know, there's "researches" over
- shorter urls ranking better than longer ones
- keywords in urls making difference
There is a research that calculated the average lengths of urls in the beginning of the search engine results and came into conclusion that shorter urls rank better. However, this research largely ignored all the multiple other reasons why a shorter url might end up in the beginning of the search results more probably than a longer one. Mostly, they ignored the fact, that usually longer urls reside deeper in the site. And at the same time, deeper pages are less linked than the ones in the surface. So the obvious consequenses of this are, that while search engines value incoming links, the pages that are indeed on the surface and have shorter urls, appear on the top but NOT because of the length of the urls. At least, there's no single proof I've seen that would clearly show that shorter would rank better than longer.
There is though, one argument that is often being used to support short urls. The argument comes from google itself which advices webmasters to use short parameters in the urls. But if you think of this for a while, you'll realize they say this because a parameter '23k4h3k4j23h43j243h24k3j4h' will consume much more resources on their systems than a parameter like '1'. This is most probably true when their indexer sees a non-rewritten and non-friendly url, it keeps record on the parameters and ignores a second duplicate of a page which has the same parameters as another, although in a different order. This does not even apply for FriendlyUrls as there's no way for google (or any other engine) to keep record on parameters as we've hid the parameters from them with the FriendlyUrl implementation. So they will keep both copies in their index. Which might lower the value of the site if there's too much duplicate content or then chew the life out of your box if there's a black hole (a little warning here for the developers on FriendlyUrls)
Then the keywords in the urls.... hmm... Does anyone know a good research that proves this? Ok, I do that on my sites and try to keep keywords in the urls. But this is not because I would believe search engines would bother to examine the urls so deeply but for the fact that if I paste an url here:
http://www.dnngear.com/DotNetNuke-Modules.aspx
The search engines (indexers actually) will examine the link text to find keywords pointing to that page. And as they ignore punctuation, they'll see: 'www dnngear com dotnetnuke modules aspx' as the link text. All of the words appearing in the link text will add to the keyword relevancy of that page. But initially, it's not because of what the url is. It's because the url was carried here and now the words point back to my site from here in the link text.