How to structure sites in your SharePoint Intranet

If you are building an Intranet in SharePoint, then one of the first things you need to decide is the proper site hierarchy for your Intranet. With this post, I will explain the best practices and most common options, as well as the pros and cons of each. There is really no standard one-size-fits-all hierarchy, so your particular site hierarchy model will depend on the various factors listed below. Make sure to read the pros and cons for each and decide the best model that fits your vision and organization.

NOTE: December 2018 update

Since I originally published this post, there have been a few significant developments and changes to the site structure best practices. While the below advice still make sense, the evolvement of Office 365 Groups and Hub Sites led to flat SharePoint Architecture (Option 1 below). Please take this into the account when creating an architecture for your company.

Option 1: Each Department gets its own site collection

I really don’t like this option. And I am quite amazed when I see my clients go this route. Don’t get me wrong, a separate site collection allows for a scalable long-term solution, should your little company grow into the size of Walmart®, Bank of America® or General Electric®. But unless you have such big ambitions, you need to face the reality. Let me explain.

Any time you create a separate site collection in your SharePoint environment, you are drastically improving your job security. This is because each site collection has unique navigation, branding, security groups, metadata. So if you go this route, you will need to work extra hard to assure consistent look and feel and taxonomy across the whole organization. And no matter how hard you try, getting to one uniform navigation might be a project by itself. There is no easy way to inherit navigation from one site collection to another, so you either have to manually fudge it on every site collection or do tricks with SharePoint Term store (if you are using it to manage navigation).

It is not uncommon for a typical company to have 8-10 departments. That means you would need to maintain 10 separate site collections!
If you are a really large organization where each department consists of hundreds of employees and has nothing in common with other departments – this might be a decent option. But if you are a small or medium-sized company – I suggest you read on and choose one of the other 2 options below.

Here are some of the arguments I heard over the years from my clients on why they chose to go with separate collections option:

1. We wanted unique security for our department (site). This is a wrong reason to choose separate site collections method. You can set unique security on each subsite in the same site collection and not worry about it being found in navigation or search (everything in SharePoint is permission-driven)
2. We have lots of content to migrate, so we wanted to make sure we don’t run into limits. Another reason that does not make sense. The limit used to be 1TB for a site collection. Just a few weeks ago, Microsoft announced an increase to 25 TB of data for each site collection. I don’t believe most companies out there will ever hit this limit.
3. We thought that’s how you create different department sites. No, not really. That’s what the sites are for. Each site collection can contain thousands of sites. Sites are where you add web parts and store content in. You might want to read this post to learn more on the difference between the two.

Pros of this option:

• Great for very large organizations, with large departments, that have nothing in common or do not communicate to each other (which is often the case with large companies :-) )
• Allows for different site collection administrators for each department
• Great job security for IT folks – there will be 10-15 site collections to manage and maintain
• Scalable, if your firm ever grows to be the size of Walmart®

Cons of this option:

• Not a good option for small to medium size organizations – lots of effort required to manage all of the separate site collections
• No easy way to maintain common branding, metadata and security, as all are unique to separate site collections
• No easy way to have 1 global navigation for the Intranet. When you have separate site collections, each one maintains unique navigation. If you have subsites in the same site collection, you can easily inherit global (top link bar) navigation from site to site. Not easy to do with separate site collections.

Option 2: Single site collection. All department sites are subsites, just 1 level below the Homepage

This option is a total opposite of Option 1. Not only all department sites reside in a single site collection, but they all reside just 1 level below the Homepage (the root of the site collection). Yes, you can create subsites under subsites and build complicated hierarchies, but the whole point of this option (method) is that they all reside just under the Homepage. Need another department or team site? Just create one under the Homepage.

Pros of this option:

• Easily achieve common branding, inherited navigation, consistency with taxonomy and SharePoint groups just by virtue of using a single site collection. Create your global navigation at the root and then just make it available on all subsites by inheriting from the parent (I describe how to do this in this video). Create your site columns at the root and they are all available on all your subsites. Security groups also stay consistent across the board.
• Can easily see all your subsites by going to Site Contents under the Homepage (no need to go to different subsites and check out its Site Contents – everything is there, just at single level)
• This model also allows for easy re-organization. If there is restructuring in your organizations and certain departments/sites need to change hands (site owners), you can just easily make the adjustment by tweaking navigation and security of the sites. No need to physically move the sites to a different area within the site collection (as would be the case with Option 3 below).

Cons of this option:

• If sites are managed by separate (department-specific) site owners, it might be a bit overwhelming, as all department sites are mixed together.
• If each department chooses to create and inherit its own navigation, metadata and branding, this will be a challenge with this model, as each subsite will need to be done separately (the only inheritance that can be done is from the homepage). This limitation is addressed by Option 3 below.

Option 3: Single site collection. All departments are organized into a hierarchy of subsites according to function

The major downside of the previous approach was the fact that in certain cases it might get overwhelming for site owners. Say, you are a Marketing Department with like 10 marketing subsites, each serving a unique purpose. With the previous model, they would all reside on Level # 2 (just under the Homepage), mixed with other department sites. As a Site Owner, I want an easy way to organize my departmental assets, create and inherit my own navigation, branding and site columns (metadata). In that scenario, Option 3 might be the optimal solution. It allows for an extra level of subsites, that are all organized by the department or function. Thus, it also allows for department specific site column and content type definition and inheritance. Same applies to navigation inheritance. All (department-specific) metadata, security, navigation, and branding can be set up at the department homepage (Level 2) and inherited to departmental subsites below (Level 3).

You don’t need to use Level 2 sites if you do not want to – this could be just a way to organize all the department-specific subsites. That said, I always recommend putting “public” or “employee” version of the site on Level 2 – describing what the department is all about, posting documents and information that is meant for public consumption (i.e. HR policies, etc.). Then, any private stuff can be put on level 3 subsites (right under the “public” site).

Pros of this option:

• All the Pros of Option 2 + great way to organize the subsites by department or function

Cons of this option:

• In case you want to reorganize subsites, you might need a migration tool, but those types of situations are rare

Recommendation and Best Practices

• Stay away from Option 1 unless you are a large firm with really large departments or business units. For most of the other organizations, either Option 2 or 3 is the way to go.
• You cannot go wrong with Option 3 – in my opinion, this is the best option for most organizations – flexible and scalable. Besides, it is easy to understand, allows for a natural way to organize sites (via hierarchy).
• Do not create more than 2 levels of sub-sites. Yes, you can create more that 2 levels of subsites (subsites under subsites, under subsites). But because you can, does not mean you should. It will make site management very hard and messy (just like with complicated folder hierarchies). Keep it nice and clean with 2 levels max (3 levels if you count root/homepage)
• Do not confuse Site Hierarchy with Navigation and Security. Many mistake the Site Hierarchy with Navigation and Security. These are totally different things. It does not really matter where the site resides in your hierarchy – navigation and security access can be set for any site separately, no matter where it resides and what level in a hierarchy.

Should I always stay in a single site collection then?

No, absolutely not! There are some good reasons on why you should and must create a separate site collection within your organization.

• Create a separate site collection if you are doing external sharing. If you are sharing content externally, you will need to create a separate site collection, even if you are a mom-and-pop shop. You can learn more about it here.
• Create a separate site collection if you need to enable Publishing features. When you enable publishing features in a site collection, it disables the ability to save site as a template. So in case you need to enable Publishing features (for publishing-type sites), you might need to maintain separate site collections (one for collaboration, where you can save sites as templates, and another for publishing-type sites and pages)
• Create a separate site collection if you need to test things out. If you want to introduce new functionality in your organization, might be a good idea to create a separate site collection and not mess with the site collection where you have actual, live department and team sites.