Making DNN Friendly URLs even more friendlier

Last post 12-01-2005 12:07 AM by badri. 6 replies.

Sort Posts:

  • Making DNN Friendly URLs even more friendlier

    11-29-2005, 12:48 AM
    • Loading...
    • badri
    • Joined on 06-28-2005, 12:27 PM
    • Posts 3
    Hi

    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
  • Re: Making DNN Friendly URLs even more friendlier

    11-29-2005, 11:02 AM
    • Loading...
    • MobileNow
    • Joined on 07-22-2004, 11:51 PM
    • Omaha, NE
    • Posts 1,019
    That might be feasible if you were to autoappend default.aspx to everything internally.
  • Re: Making DNN Friendly URLs even more friendlier

    11-29-2005, 11:51 AM
    • Loading...
    • Codepic
    • Joined on 04-08-2004, 4:11 PM
    • Finland
    • Posts 116
    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.

    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.

  • Re: Making DNN Friendly URLs even more friendlier

    11-29-2005, 11:54 AM
    • Loading...
    • sbwalker
    • Joined on 08-23-2002, 12:47 PM
    • Canada
    • Posts 2,047
    • ASPInsiders
      TrustedFriends-MVPs
    This would require an IIS tweak in order to get it to work ( ie. it is not something which DotNetNuke can accomplish on its own ).
    Shaun Walker
    Perpetual Motion Interactive Systems Inc.
    http://www.dotnetnuke.com
    DotNetNuke on SourceForge.Net
  • Re: Making DNN Friendly URLs even more friendlier

    11-29-2005, 5:36 PM
    • Loading...
    • ikamiksok
    • Joined on 11-12-2003, 7:08 AM
    • Posts 247
    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'.

    Jason
  • Re: Making DNN Friendly URLs even more friendlier

    11-29-2005, 8:22 PM
    • Loading...
    • Codepic
    • Joined on 04-08-2004, 4:11 PM
    • Finland
    • Posts 116

    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&amp;ctl=view&amp;mid=475&amp;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.


  • Re: Making DNN Friendly URLs even more friendlier

    12-01-2005, 12:07 AM
    • Loading...
    • badri
    • Joined on 06-28-2005, 12:27 PM
    • Posts 3
     sbwalker wrote:
    This would require an IIS tweak in order to get it to work ( ie. it is not something which DotNetNuke can accomplish on its own ).


    Shawn - I was expecting something like this was possible; kindly elaborate on this tweak so I could try this out.

    thx
Page 1 of 1 (7 items)
Microsoft Communities
Page view counter