locked
SharePoint URL naming convention RRS feed

  • Question

  • Are there any best practices regarding location of sites and URL naming conventions for sites?

    Our site collection is based on the corporate org chart. We are restructuring it based on operational function. This requires us to move many site. We are looking into implementing some sort of URL naming convention and organizing all sites, or as many as possible, at the top level. Or in specific groups without many multiple levels of subsites. The thought being that if sites need to be renamed, the URL won't change because it isn't based on the site name. Also, if a site's functional reporting changes, the site does not need to be moved, only the navigtaion changes.

    Wednesday, June 2, 2010 11:47 AM

Answers

  • I tend to recommend clients avoid custom navigation where possible. I have seen a number of them sink a lot of time and effort into creating a custom navigation system which hasn't really given them anything worthwhile in return. If there's a top ten list of SharePoint mistakes anywhere I'd bet custom navigation is right up there. 

    Although with that said, it can be very effective when implemented well, it's just it raises some side issues which many people don't allow for. A relevant example is breadcrumb trails, if you have a flat site structure with a hierarchy created by your custom nav, how will they be displayed? Another is aggregation, if HR for e.g. want to aggregate all of the tasks on their site and all it's subsites, how will this work if the sites are in fact siblings? Don't forget that site structure and hierarchy is a form of organisational metadata in it's own right, and it's something that SharePoint and users may expect to be in place.

     

     

    • Marked as answer by Lily Wu Monday, June 14, 2010 1:19 AM
    Friday, June 4, 2010 10:02 AM
  • If I understood your situation correctly, then I'm glad you're getting out of the business of organizing by corporate org charts early.  In my situation, the original implementer put everything in one site collection with a taxonomy based on corporate org charts.  When the organization changed, people got bent out of shape because the URLs were reflecting old names.  Not to mention the growth of the environment sky rocketed out of control and upgrading to MOSS 2007 came into the scopes.  The environment had to be painfully restructured.  It was then tossed to me to do the upgrade.  I've gained a lot of grey hair, frown lines, contusions, and concussions as a result of the original taxonomy. ;-)

    I'll tell you from first hand experience - please, PLEASE put good time and effort into planning your taxonomy with your process partners.  It's critical to spend the time in the early stages of your environment to define a strategic and sustainable taxonomy and map it to SharePoint best practices so it becomes easy to scale out SharePoint and upgrade in the future. 

    This post by Joel Oleson is a must read: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=147 He has investing a lot of time spreading the word that taxonomy is a key element in a successful SharePoint deployment. My favorite presentation is his SharePoint Governance: Chaos to Success in 10 Steps

    Good luck

    • Marked as answer by Lily Wu Monday, June 14, 2010 1:20 AM
    Saturday, June 5, 2010 4:41 PM

All replies

  • There really ins't any good support for this kind of thing (some times call "vanity" URLs).

    There are some blogs out there that address the topic.  I'd do a search for "vanity url sharepoint" or a combination of that.   You may turn something up.


    --Paul Galvin, Computer Generated Solutions (CGS)
      Microsoft MVP - SharePoint
      Blogging @ http://feeds.feedburner.com/PaulGalvinsSharePointSpace
      Twitter @ http://www.twitter.com/pagalvin
    Wednesday, June 2, 2010 1:29 PM
  • The only thing I would suggest is try to make the url as short as possible.  This is due to the fact that there is a hard limit on the length of this, and when you add list names (which should also be as short as possible), long file names, that limit is reached very quickly.

    For me, I try to make the url meaningful but short.  For example: the marketing site would have the url mkt, the projects site would have the url prjs


    Kevin
    Wednesday, June 2, 2010 2:22 PM
  • Good advice. We do try to keep URLs as short as possible as well as list names and also column names. It does help.

    Our problems occurs when the Marketing Department decides to change names to say the Commerce Department. Easy enough to change the name. But changing the URL causes broken links, etc. Worse if the Commerce Department now reports to a different parent and the site needs to move to a subsite under the new parent site.

    Before our site collection gets any more developed, we'd like to institute some sort of site structure that minimizes the potential.

    Thanks. Much appreciated.

    Wednesday, June 2, 2010 5:46 PM
  • Changing the name of a site doesn't actually change it's URL. So if your site title is "Marketing Department" and it's URL is http://SharePoint/Marketing/, you can change the site title to "Commerce Department" and the URL will remain the same. Any automatically created navigation links (such as in the top navigation bar) will be updated to display with the new title, but the actual URL they point to will remain the same, which will still be the correct URL for the site.

    Moving sites will out of necessity change the URL to reflect the site's new location, there's isn't really any way around this without some custom and complex URL rewriting.

    In terms of naming standards, the most important thing is to have one. It's not too important what it actually is as long as there's one in place. Some good tips are keeping them short as mentioned, and also not using spaces or special characters (ok in titles, just not in URLs).

     

     

     

     

    Thursday, June 3, 2010 11:05 AM
  • One thing tha you could consider doing would be to create a very flat site structure and then build a custom navigation that puts things in the right place based on the hierarchy.  Then if the structure changes you are just changing the navigation and you dont have to move the sites around.

    I think it really depends on the number of sites you are talking about and the number of times you think things will move around.  If you can plan your design to the most common scenarios then you only have to deal with the exceptions when they occur.


    ~Jennifer Mason ~My Blog~ ~SharePoint Support~ ~SharePoint Training~ ~Follow me on Twitter!~
    Thursday, June 3, 2010 12:53 PM
  • I understand. Our problem is that some will want the actual URL to change to reflect the new department name. So we are considering http://SharePoint/site0001/ and http://SharePoint/site0002, etc. That way it doesn't matter what the site name changes to. The URL doesn't reflect the name.

    And as Jennifer suggests below, we are considering a flat or almost flat structure with custom built navigation. When site "move" they don't actually move, we just mod the nav. Currently we have less than 400 sites in our collection. But it could grow a lot. Plus we have many site owners so a coordinated effort to follow specific proceedures will be important.

    I'm trying to find out what others may be doing. Thanks a bunch for the responses. All very good.

    Friday, June 4, 2010 2:58 AM
  • I tend to recommend clients avoid custom navigation where possible. I have seen a number of them sink a lot of time and effort into creating a custom navigation system which hasn't really given them anything worthwhile in return. If there's a top ten list of SharePoint mistakes anywhere I'd bet custom navigation is right up there. 

    Although with that said, it can be very effective when implemented well, it's just it raises some side issues which many people don't allow for. A relevant example is breadcrumb trails, if you have a flat site structure with a hierarchy created by your custom nav, how will they be displayed? Another is aggregation, if HR for e.g. want to aggregate all of the tasks on their site and all it's subsites, how will this work if the sites are in fact siblings? Don't forget that site structure and hierarchy is a form of organisational metadata in it's own right, and it's something that SharePoint and users may expect to be in place.

     

     

    • Marked as answer by Lily Wu Monday, June 14, 2010 1:19 AM
    Friday, June 4, 2010 10:02 AM
  • I tend to recommend clients avoid custom navigation where possible. I have seen a number of them sink a lot of time and effort into creating a custom navigation system which hasn't really given them anything worthwhile in return. If there's a top ten list of SharePoint mistakes anywhere I'd bet custom navigation is right up there. 

    Although with that said, it can be very effective when implemented well, it's just it raises some side issues which many people don't allow for. A relevant example is breadcrumb trails, if you have a flat site structure with a hierarchy created by your custom nav, how will they be displayed? Another is aggregation, if HR for e.g. want to aggregate all of the tasks on their site and all it's subsites, how will this work if the sites are in fact siblings? Don't forget that site structure and hierarchy is a form of organisational metadata in it's own right, and it's something that SharePoint and users may expect to be in place.

     

     

    Friday, June 4, 2010 10:02 AM
  • Issues like this are one reason I tend to preach that a SharePoint taxonomy needs to be built around process, not structure. While the structure of your business may often change, merge or migrate, process tends to remain constant. You might want to consider re-evaluating your overall taxonomy plan.
    Imagine what we could be...If we could just imagine. Daniel A. Galant
    Saturday, June 5, 2010 3:47 PM
  • If I understood your situation correctly, then I'm glad you're getting out of the business of organizing by corporate org charts early.  In my situation, the original implementer put everything in one site collection with a taxonomy based on corporate org charts.  When the organization changed, people got bent out of shape because the URLs were reflecting old names.  Not to mention the growth of the environment sky rocketed out of control and upgrading to MOSS 2007 came into the scopes.  The environment had to be painfully restructured.  It was then tossed to me to do the upgrade.  I've gained a lot of grey hair, frown lines, contusions, and concussions as a result of the original taxonomy. ;-)

    I'll tell you from first hand experience - please, PLEASE put good time and effort into planning your taxonomy with your process partners.  It's critical to spend the time in the early stages of your environment to define a strategic and sustainable taxonomy and map it to SharePoint best practices so it becomes easy to scale out SharePoint and upgrade in the future. 

    This post by Joel Oleson is a must read: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=147 He has investing a lot of time spreading the word that taxonomy is a key element in a successful SharePoint deployment. My favorite presentation is his SharePoint Governance: Chaos to Success in 10 Steps

    Good luck

    • Marked as answer by Lily Wu Monday, June 14, 2010 1:20 AM
    Saturday, June 5, 2010 4:41 PM
  • I would look into the multi-tenancy features in SharePoint 2010 (Site Subscriptions, Host header Site Collections etc).

    Host header Site Collections 
    Host header site collections have been around for a while now. It used to be called Scalable Hosting Mode when it wasn’t anything of the sort back in 2003. It’s been improved significantly in SharePoint 2010 and is a key piece of the puzzle. Host header site collections allow us to have multiple root level sites with independent top level domain names in the same Web Application. In SharePoint 2010 we can now also use them in combination with Managed Paths and furthermore they now work properly when terminating SSL on an external device such as a load balancer. All of these improvements together mean we can now deliver a consistent URL namespace. We can also “mix ‘n’ match” our URL namepaces within a single web application to suit even the most vain tenants!

    [Spencer Harbar, Rational Guide to Multi-Tenancy with SharePoint 2010]

    btw, even tough multi-tenancy is ment for the hosting industry, it can with success be deployed on premise where each department can be look upon as a tenant.

    Sunday, June 6, 2010 7:51 AM
  • You can also consider using SharePoint Short Url;

    All the shortcuts are stored in a regular SharePoint List which allows all the standard functionality of audit trails, workflow, security permissions, item approval and so on, to naturally dovetail with this new functionality. This is proving a popular solution for several large organizations.

    Visit http://sharepointshorturl.com to try the trial version (very simple install) and i’m sure this will address all requirements.

    Hope this helps?

    Tuesday, June 8, 2010 9:59 AM