I've been extensively using the DNN's friendly url feature and it works great; but, it could be even more friendlier if the last ".aspx" could be dropped. Is it possible?
I am even ready for "redirect" kind of solution, wherein all links coming to my web server will get added a ".aspx" extn (if not present already) so DNN could take it further for its url resolutions.
Please understand that if this is implemented and turned on by default, every portals tabs pagerank will drop to 0 because none of the pages that used to be there, are there no more.
Not to mention, if the old urls still resolve, every portal will have duplicate set of pages with identical URLs for them...
Also, we don't really know how search engines handle default documents internally. All we have, is the public page rank for google, and that does only give us a small hint of the internal pagerank. And still, it's ONLY google and there's many more search engines
out there.
the basic reason for friendly urls is to take all the parameters after the "page" and move them as part of the path. This is done because search engines keeps track record of parameters. So /Default.aspx?tabid=36&ctl=login would be exactly the same for a search
engine as /Default.aspx?ctl=login&tabid=36
Now that we've moved the parameters as part of the path, I really hope the developers will keep them in order as search engines will not. This could make the developers create "black holes" into which the search engine robots falls into. A black hole is a module,
in which the developer doesn't keep record in which order the parameters will be shown from page to page. The module might have 10 url parameters and if they're not rewritten always in the same order, it may create virtually endless amounts of variations of
the url.
I dont think if DNN url rewriter automatically puts the parameters in alphabetical order. If it does now, I believe it should as that would count as much better improvement in the friendly urls than dropping 12 characters off the url just because it looks cool
but nobody really has knowledge if it'll make any difference. Except for fact, it'll hurt the existing site's rankings big time.
I commented in this post on friendly URLs and options (noting that there is still not a human and search engine friendly URL option available):
http://forums.asp.net/970390/ShowPost.aspx
However, Scott McCulloch has stated he is working on a friendly url prototype which I believe will offer human & seo friendly URLs. It's mentioned in various places on his site including by me. www.smcculloch.net
So perhaps this can help you find something 'friendly enough'.
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
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
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.
badri
Member
15 Points
3 Posts
Making DNN Friendly URLs even more friendlier
Nov 29, 2005 04:48 AM|LINK
I've been extensively using the DNN's friendly url feature and it works great; but, it could be even more friendlier if the last ".aspx" could be dropped. Is it possible?
I am even ready for "redirect" kind of solution, wherein all links coming to my web server will get added a ".aspx" extn (if not present already) so DNN could take it further for its url resolutions.
Any suggestions?
rgds
MobileNow
Contributor
5107 Points
1020 Posts
Re: Making DNN Friendly URLs even more friendlier
Nov 29, 2005 03:02 PM|LINK
PowerDNN Hosting is the best
Eliminate DNN Startup Lag
Codepic
Member
580 Points
116 Posts
Re: Making DNN Friendly URLs even more friendlier
Nov 29, 2005 03:51 PM|LINK
Not to mention, if the old urls still resolve, every portal will have duplicate set of pages with identical URLs for them...
Also, we don't really know how search engines handle default documents internally. All we have, is the public page rank for google, and that does only give us a small hint of the internal pagerank. And still, it's ONLY google and there's many more search engines out there.
For example, if we examine google alone, we might notice that for example:
http://www.domain.com = pagerank 7
http://www.domain.com/ = pagerank 7
http://www.domain.com/index.html = pagerank 7
http://www.domain.com/index.htm = pagerank 7
So what that'd look like, google would ignore default documents completely. The possibilities are that they ignore also Default.aspx
however,
http://www.domain.com/Default.aspx = pagerank null
that means they don't have such file, however if google finds one
http://www.microsoft.com/default.aspx = pagerank 8
http://www.microsoft.com/ = pagerank 8
It seems it ignores it.
Similarly:
http://www.skin3.com/ = pagerank 3
http://www.skin3.com/Home/tabid/36/Default.aspx = pagerank 3
links:
http://www.skin3.com/ = backlinks 16
http://www.skin3.com/Home/tabid/36/Default.aspx = backlinks 16
the basic reason for friendly urls is to take all the parameters after the "page" and move them as part of the path. This is done because search engines keeps track record of parameters. So /Default.aspx?tabid=36&ctl=login would be exactly the same for a search engine as /Default.aspx?ctl=login&tabid=36
Now that we've moved the parameters as part of the path, I really hope the developers will keep them in order as search engines will not. This could make the developers create "black holes" into which the search engine robots falls into. A black hole is a module, in which the developer doesn't keep record in which order the parameters will be shown from page to page. The module might have 10 url parameters and if they're not rewritten always in the same order, it may create virtually endless amounts of variations of the url.
I dont think if DNN url rewriter automatically puts the parameters in alphabetical order. If it does now, I believe it should as that would count as much better improvement in the friendly urls than dropping 12 characters off the url just because it looks cool but nobody really has knowledge if it'll make any difference. Except for fact, it'll hurt the existing site's rankings big time.
Jani Hyytiäinen
Codepic Solutions | skin3 Team | DnnGear.com
sbwalker
Star
10239 Points
2051 Posts
ASPInsiders
MVP
Re: Making DNN Friendly URLs even more friendlier
Nov 29, 2005 03:54 PM|LINK
CTO & Co-Founder
DotNetNuke Corporation
http://www.dotnetnuke.com
ikamiksok
Participant
1235 Points
247 Posts
Re: Making DNN Friendly URLs even more friendlier
Nov 29, 2005 09:36 PM|LINK
http://forums.asp.net/970390/ShowPost.aspx
However, Scott McCulloch has stated he is working on a friendly url prototype which I believe will offer human & seo friendly URLs. It's mentioned in various places on his site including by me. www.smcculloch.net
So perhaps this can help you find something 'friendly enough'.
Jason
Codepic
Member
580 Points
116 Posts
Re: Making DNN Friendly URLs even more friendlier
Nov 30, 2005 12:22 AM|LINK
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
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.
Jani Hyytiäinen
Codepic Solutions | skin3 Team | DnnGear.com
badri
Member
15 Points
3 Posts
Re: Making DNN Friendly URLs even more friendlier
Dec 01, 2005 04:07 AM|LINK
Shawn - I was expecting something like this was possible; kindly elaborate on this tweak so I could try this out.
thx