Question

I am developing a company website/portal in SharePoint, and am trying to figure out the best way to organise it into site collections, sites and subsites -- I'm confused by the terminology I think.

The site has a public-facing Internet presence which is to be managed via the Publishing WCM features of SharePoint. Behind the scenes there will be some portal features, such as personalised dashboards and a collaborative wiki.

For the public-facing content, the site structure is as so:

  • Home
  • Company
    • About Us
    • Testimonials
    • ...
    • ...
    • etc
  • Products
    • Product 1
    • Product 2
    • ...
    • ...
    • etc
  • Support
    • a support section for customers requiring a login
  • Contact Us
    • one web page with contact details

The top-level sections in my hierarchy, i.e. Home, Company, Products, Support, Contact Us would share the same master page and top-level navigation, and Company and Products will each have a left-placed submenu to go to each page in their section. I'm wondering how to structure this in terms of sites/subsites/site collections.

My initial thoughts is to have a site collection where the top-level site for the collection is the public-facing publishing side of things.

But then I'm not sure whether 'Company' and 'Products' should be subsites of the top-level publishing site, or simply pages within the top-level publishing site. As Company and Products are just collections of basic HTML content, to have each one as a 'subsite' feels like overkill, but that may just be because I'm not used to the terminology. I would ordinarily just think of them as subsections of a website.

The 'Support' section is essentially a set of embedded mini-applications such as issue tracking. As it is more substantial, and is not viewable by anonymous users, it feels like it would warrant being at least a subsite, or maybe it should be a separate site collection?

I would guess that the 'behind-the-scenes' portal, only accessible by employees, with features such as dashboards/collaborative wiki, would again be in a separate site collection.

I guess my general question is, what are the rules of thumb for when to use a site, when to use a subsite, and when to use a site collection?

Was it helpful?

Solution

This blog post When to use a Site Collection over a Sub-Site by Joe Shepherd helped me a lot when I had similar questions.

OTHER TIPS

A more authoritative source for site planning is from Microsoft itself - Plan sites and site collections (SharePoint 2010). The approach calls for a thorough requirement analysis in the planning (see the Site Planning data worksheet in the link above).

It's not clear from above question what version/edition is being used. There is also a reference for SharePoint Server 2010 - Plan for sites and solutions (SharePoint Server 2010).

I am presuming above that links from Microsoft do not readily disappear & are updated as required.

This similar post helped me:

Some of the reasons that I might pick a Site Collection

  • I have a branded new site and I want it created with no relation to any other site. If you are creating a new site and it's not related to any other sites that you have in your existing site hierarchy or SharePoint farm then you chose a site collection.
  • If you require a dedicated URL to your site. You want your client to access and upload documents so you want to create a URL for your partner at http://partner.mycompany.com . You can bind this URL to a site collection. This URL cannot be bound to a sub site of an existing site collection.
  • You want to create a managed path called divisions and you want to create a site for each division you your organization. Each division wants complete control over their site and sub sites and want to be found at URL divisions/divisionName.
  • Where you require to have a quota set on a site created you will need to use a site collection as only site collections can have quotas assigned to them.
  • If you need a dedicated Content Database for your site as you expect to have vast amounts of data and documents and you require it to be more secure that normal, you can can configure a dedicated site collection with a dedicated content database attached to it.
  • If you were purchasing hosted environments from a hosting provider then you would also see the difference in a site collection and a sub site in the cost model offered by the hosting company. You will notice that getting a site collection provisioned with have a higher admin cost than just creating a sub site. Sub site creation can be carried out by a member of the owners group of any site or site collection. Whereas site collection creation has to be completed by Farm Administrators unless there is a mechanism provided though web wizards.
  • As part of a backup and recovery policy you want your data to be very quickly restored if there are any problems or if there has been content that has gotten deleted that you need to retrieve. A site collection is better in this case because you can restore the site collection more easily than you can restore a site or a sub site of a site.

Some of the reasons why you should select a sub site:

  • You want to inherit the same security for the new sub site as its parent site & the security model for your organization already exists. You want to create a new site but you don't want to change or move away from the existing security model implemented already.
  • There has been a team in your organization unit that created many new site columns and site content types that you would like to use throughout your site and its sub sites -- as parent sites can contain site content types, these can be used in all subs sites of the site hierarchy -- Site Collections break this functionality.
  • You want to allow the Site Owners and Designers to manage all sites that get created without any overhead of having to log a support call for a new site collection.
  • You want to aggregate data throughout your site hierarchy using Web Parts like the Content Query Web Part, Data View Web Part and other data aggregation Web Parts.
  • You have a site template that you want to apply to the new site that creates a couple of lists and libraries as part of the template -- an example may be you want a Tasks Manager Site Template where a site can maintain and manage all your tasks using tasks lists and to have them integrate with Outlook.
  • If your site is going to be a short lived site and it's only going to be used in the process of creating some other content. An example might be a meeting site where you create a site that is created from a Meetings Templates. You can record and schedule meetings regarding the production of a catalog of products for your organization. This site is short lived and won't be in existence after the production of the catalog is completed.
Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top