Plan sites and site collections (SharePoint Server 2010)

Article
02/10/2015

Applies to: SharePoint Foundation 2010, SharePoint Server 2010

Microsoft SharePoint Server 2010 sites are made up of a site collection, which is a hierarchical structure that includes one top-level site and any sites below it. This article describes the process and important considerations for planning SharePoint Server 2010 sites and site collections, and it recommends a method for recording your site structure decisions. For information about sites and site collections, and the site templates that are used to create sites in SharePoint Server 2010, see Sites and site collections overview (SharePoint Server 2010).

In this article:

About planning sites and site collections
Determine types of sites
Determine site collections
Site planning data worksheet

About planning sites and site collections

In general, you plan your sites and site collections in the following order:

Determine the number and types of top-level sites and any sites below them in the hierarchy that are needed.
Determine the number and types of site collections into which the sites will be organized.

Determine types of sites

The first step in planning a solution that is based on SharePoint Server 2010 is to determine the types of sites your organization and its customers need. Determining the types of sites affects later planning decisions, such as where the sites will be implemented in your server topology, what features to plan for each site, how processes that span multiple sites are implemented, and how information is made available across one or more sites. This section contains information about how to plan different kinds of sites.

Plan sites by organizational hierarchy

Plan the basic sites that you need based on the scale and structure of your organization. Each of these sites can contain information that is needed for a project or division within your larger organization, and each will link to collaboration sites that are relevant to that project or division. Some sites for larger divisions or projects will also aggregate information that is found on all the smaller sites that are devoted to smaller divisions or projects.

Use the following guidelines when you plan sites that are based on your organizational structure:

Divisional or team sites Plan to create one site for a small organization or one site for every division or project of 50–100 people in a medium to large organization. In large organizations, there might be several levels of sites, with each site focusing on the content that is created and managed at its level of the organization.

You can design a site for members of your organization to collaborate on content related to your business or organizational goals. These can be self-contained or they can work with other sites as part of a publishing process. Often, these sites will have a mixture of collaborative content that is used internally and content that is intended for publication to an audience.

Rollup sites A rollup site contains general cross-organization content. It makes it possible for users across divisions to find information, experts, and access to organization-wide processes. It often contains sites that are related to the overall organizational information architecture and that are usually mapped to the structure of the divisional or project sites. For each organization, plan to create a centralized rollup site that uses an aggregated view of all related sites.

Plan application sites

An application site organizes team processes and provides mechanisms for running them. Application sites often include digital dashboards and other features to view and manipulate data that is related to the site’s purpose. The information that is presented in an application site usually comes from diverse sources, such as databases or other SharePoint sites.

For example, the human resources organization in an organization could design an application site to provide employees with:

Access to general information, such as employee handbooks and career opportunities.
Ways to do common tasks, such as submitting timecards and expense reports.
Dashboards to view personalized information, such as an employee's salary and benefits history.

As another example, the internal technical support group in an organization could design a Help Desk application site to provide technical support to members of the organization. Features of the application site could include the following:

Access to a knowledge base of past support incidents and best-practices documentation.
Ways to do common tasks, such as starting a support incident or reviewing the status of an ongoing incident.
Integration with communications features that support online meetings and discussions.
Personalized views of data. For example, support managers could view dashboards that provide views of their team members' productivity and customer satisfaction ratings. Support engineers could view their current unresolved incidents.

Plan Internet presence sites

Internet presence sites are customer-facing sites. They are usually branded and are characterized by consistent stylistic elements, such as colors, fonts, and logos in addition to structural elements such as navigation features and the structure of site pages. Although the appearance of an Internet presence site is tightly controlled, the content of the site can be dynamic and can frequently change.

For example, a corporate Internet presence site communicates important company information to customers, partners, investors, and potential employees. This includes descriptions of products and services, company news, annual reports, public filings, and job openings. As another example, an online news Internet site provides frequently updated information, together with interactive features such as stock tickers and blogs.

Because an Internet presence site represents your organization to an external audience, you might stage and test the site and then publish it — either based on a schedule or as needed — to its public "production" location. A staging site is a mirror of the authoring site that you use to test content before it is published to the production site. By using a staging site, you help ensure that published content meets strict standards. Staging sites also make it possible for content authors to work on servers that are located on your company's intranet while Internet users are using production servers in your perimeter network. A built-in content deployment feature makes it easy to move content from the authoring server to the staging server and then to the production server. For more information about content deployment, see Content deployment overview (SharePoint Server 2010).

Plan publishing sites

By using a publishing site, authors can create and modify content in the form of Web pages and documents, and they can use an approval process to make the content available to users who have the appropriate levels of viewing permissions. The publishing process involves creating content and then submitting it for approval. After content is approved, it is made available, or published, to the Web site for readers. This publishing occurs according to either a default schedule or a customized schedule, based on the needs of the project. Publishing sites can be used as intranet, extranet, or Internet sites, depending on the audience.

For example, you might use a publishing site for an Internet-facing site that publishes press releases. The public relations team creates press releases, uses the publishing workflow to approve new content, and specifies when it should be made available to consumers. As another example, you might use a publishing site for a corporate intranet site, where company news is made available to employees. Page authors can specify the target audience for their content, which makes the content viewable by only the members of the designated groups.

Like Internet presence sites, you can also use the built-in content deployment feature to move content from a staging site to a production site. The production site might be an Internet-facing site, or it might be another intranet site within your organization, depending on the size of your organization and the complexity of your publishing needs.

Plan other sites

You can plan to make it possible for site users to create additional sites. For example, you can plan to give a My Site to each team member who uses a site. A My Site is a team site that is based on Microsoft SharePoint Foundation 2010 and has public and private views. You can also make it possible for team members to create other sites, such as Document Workspace sites, when they collaborate on documents and other projects. You can also use Office 365 for document storage and collaboration.

Similarly, you can give users of an Internet site access to collaboration sites as part of a Web-based service. For example, you can give them permissions to create Meeting Workspace sites and participate in online meetings as part of their experience of using your site.

For information about the kinds of sites you can create, see Sites and site collections overview (SharePoint Server 2010).

Determine site collections

After you determine what types of sites your solution requires, the next step is to plan how these sites are implemented across site collections. A site collection is a hierarchical set of sites that can be managed together. Sites in a site collection have common features, such as shared permissions, galleries for templates, content types, and Web Parts, and they often share a common navigation. A site is often implemented as a site collection with the top-level site as the home page of the site collection.

In general, when you plan a solution that is based on SharePoint Server 2010, put the following kinds of sites in separate site collections:

Internet sites (staging)
Internet sites (production)
All team sites related to a divisional site or Internet site
Document Center sites
Records Center sites

All sites in a site collection are stored together in the same SQL database. This can potentially affect site and server performance, depending on how your site collections and sites are structured, and depending on the purpose of the sites. Be aware of the following limits when you plan how to allocate your content across one or more site collections:

Keep extremely active sites in separate site collections. For example, a knowledge base site on the Internet that allows anonymous browsing could generate lots of database activity. If other sites use the same database, their performance could be affected. By putting the knowledge base site in a separate site collection with its own database, you can make resources available for other sites that no longer have to compete with it for database resources.
Because all content in a site collection is stored in the same content database, the performance of database operations — such as backing up and restoring content — will depend on the amount of content across the site collection; the size of the database; the speed of the servers hosting the database; and other factors. Depending on the amount of content and the configuration of the database, you might have to divide a site collection into multiple site collections to meet service-level agreements for backing up and restoring, throughput, or other requirements. It is beyond the scope of this article to provide prescriptive guidance about how to manage the size and performance of databases.
Creating too many sites below a top-level site in a site collection might affect performance and usability. Limit the number of sites of any top-level site to a maximum of 2,000.
If you plan to use content deployment to move content between an authoring site collection and a production site collection, the site collections must be either in separate Web applications, or they must use separate content databases within the same Web application. For information about content deployment, see Content deployment overview (SharePoint Server 2010).

Site planning data worksheet

Download an Excel version of the Site planning data worksheet(https://go.microsoft.com/fwlink/p/?LinkID=167837&clcid=0x409). Use this worksheet to record your site structure.

Share via