How to build a SharePoint site: a complete guide to team sites, communication sites and a simple company intranet

SharePoint is deceptively easy to start and surprisingly easy to get wrong. Anyone with permission can click New Site and have something live in under a minute. The problem shows up 18 months later, when an organisation has 40 sites nobody remembers creating, three of them called roughly the same thing, half of them shared with 'Everyone except external users', and no one is sure which one is actually the source of truth for the HR policy document someone is quoting in a meeting.

This guide covers how to build a SharePoint site properly, from choosing the right site type through to permissions, navigation and a basic company intranet, so the site is still useful, secure and easy to find in two years, not just on the day it launches.

Team site, communication site or hub: choosing the right type

The single most common SharePoint mistake is picking the wrong site type at creation. It's not usually fatal, but it means fighting the platform's defaults for the life of the site. There are three building blocks and each has a specific job.

Team site

A team site is built for a working group, a department, a project team, a committee, that needs a shared place to store and collaborate on documents. Every Microsoft 365 Group and every Microsoft Teams team has a team site behind it automatically. It's read-write by default for its members, organised around a document library, and it's where day-to-day collaborative work happens: co-authoring, version history, task lists, a shared calendar.

Use a team site when the audience is a defined group of people actively working together, Finance, a project team, a regional office, and the content changes often.

Communication site

A communication site is built for broadcasting to a wide audience that mostly reads rather than edits. It has no Microsoft 365 Group behind it by default, its permissions default to read-only for most visitors, and its page layouts (banner, hero, news) are designed for polished, one-to-many content: company news, policy hubs, a project status page for stakeholders who aren't doing the work.

Use a communication site when the audience is broad (the whole company, or a large cross-functional group) and the content is curated by a small number of owners rather than co-authored by everyone who can see it. A company intranet home page should always be a communication site, never a team site.

Hub site

A hub is not a third kind of site with its own content, it's a role that gets applied to an existing team site or communication site to make it the anchor for a family of associated sites. Once a site is registered as a hub, other sites can be associated with it and inherit its top navigation, its theme, and a common search scope. A hub is how an organisation avoids having 30 unrelated sites with 30 different navigation bars and no way to search across them as a group.

Use a hub when there are, or will be, multiple related sites that should feel and navigate like one connected space, department sites under a division, project sites under a client, regional sites under a country.

Creating a site: self-service versus the SharePoint admin center

There are two paths to a new site, and which one is available depends on tenant configuration. Self-service creation lets any licensed user click New Site from the SharePoint start page or create a team in Microsoft Teams (which provisions a team site automatically) without IT involvement. It's fast, and for a small organisation with a handful of staff it's often fine.

The alternative is provisioning through the SharePoint admin center, where an administrator (or a designated site collection administrator) creates the site from a template, sets the owner, applies a sensitivity label or sharing policy at creation, and optionally associates it with a hub straight away.

As an organisation grows past roughly 50 to 100 staff, self-service site creation becomes a liability rather than a convenience. The pattern is consistent: duplicate sites with near-identical names, sites created for a single project that are never archived, and no consistent naming or governance applied at creation because there was no one gate to enforce it through. Restricting site creation to a managed process, either turned off entirely in favour of a request form, or gated through a Microsoft Entra ID group that limits who can create sites, is one of the highest-leverage governance decisions a growing business can make, and it costs nothing to implement.

Document libraries: folders versus metadata, and views

Every SharePoint site is built around at least one document library, and how that library is structured decides whether the site is still usable once it holds a few thousand files.

Folders are familiar and they work, but a folder is a single, rigid way of organising files. A document can only live in one folder at a time, so if a file needs to be found by client and by year and by document type, folders force a choice about which hierarchy wins, and everyone has to know it to find anything.

Metadata columns solve this by attaching structured information to a file, client name, document type, status, review date, as fields rather than folder position. The same file can then be filtered, grouped or sorted by any of those fields without ever being moved. This is the difference between a library where finding a document means remembering which of six nested folders it's in, and one where a saved view filters straight to it.

• For a small, simple library with a handful of predictable categories (by year, or by department), folders are still a reasonable, low-effort choice
• For any library that will grow past a few hundred documents, or where people need to find files by more than one attribute, add metadata columns and build views instead of adding folder depth
• Views let different audiences see the same library differently, a 'my documents' view filtered to the current user, a 'pending review' view filtered by status, a 'by client' grouped view, without duplicating any files
• Content types, a step up from plain columns, let a library enforce that a 'Contract' document always carries a client name and expiry date while a 'Policy' document carries a review date and owner, keeping metadata consistent as more people add files

Permissions done properly

Permissions are where most SharePoint sites quietly go wrong, and the failure mode is almost never a dramatic breach, it's a slow accumulation of one-off exceptions that nobody can account for eighteen months later.

SharePoint groups: Owners, Members, Visitors

Every SharePoint site is created with three default groups, and the entire permission model is designed to work through them rather than through individuals.

• Owners, full control, can change permissions, add or remove members, and delete the site. Should be two to three named people, never one (a single owner who leaves the business orphans the site) and never everyone on the team
• Members, edit access, can add, change and delete content but can't change permissions or site structure. This is the group almost everyone on the working team belongs to
• Visitors, read-only access, can view and download but not change anything. Useful for stakeholders who need visibility without editing rights

The discipline that keeps a site manageable is adding people to one of these three groups and controlling access to the whole site through group membership, rather than granting permission to individual files or folders directly.

Why breaking inheritance causes sprawl

By default, every library, folder and file inherits its permissions from the site above it. 'Breaking inheritance', setting unique permissions on a specific folder or file so it behaves differently to the rest of the site, is available everywhere in SharePoint, and it's tempting the first time someone needs a folder that only three people should see.

The problem is that unique permissions are invisible from the site's main permission settings. Six months later, nobody reviewing site access can see, without checking every folder individually, that a Finance sub-folder has a different access list to everything else. Multiply this across a few dozen one-off exceptions granted over a couple of years, and a site access review becomes archaeology rather than a five-minute check. This is the single most common finding in the SharePoint sharing reviews Frontrow runs as part of a quarterly Microsoft 365 health check: sites where the top-level permissions look clean and several buried folders don't match them at all.

The better pattern in nearly every case is a second, separate document library or a dedicated sub-site for content that genuinely needs a different audience, kept at the top level where its permissions are visible, rather than a folder with broken inheritance buried inside a library everyone else can see.

Sharing links

Sharing a file or folder directly, rather than through group membership, creates a sharing link, and the link type matters. 'Specific people' names exactly who has access and is auditable. 'People in your organisation' opens it to every signed-in staff member regardless of whether they should see it. 'Anyone with the link' creates an anonymous link that needs no sign-in at all, effectively taking the file outside the tenant's access controls entirely.

Tenant and site-level sharing settings should cap what's available before anyone gets the choice, most growing businesses have no legitimate use for anonymous 'Anyone' links as a default option, and Frontrow generally recommends turning that option off tenant-wide rather than relying on individual users to choose the tighter setting each time.

Navigation, and using a hub to tie sites together

A single site's navigation is edited directly, the left-hand quick launch for a team site, or the top navigation bar for a communication site, and should stay short, a handful of links to the areas people actually use, not a mirror of the full folder structure underneath.

The bigger navigation problem shows up once an organisation has more than a couple of related sites. Without a hub, each site's top navigation is set independently, so a staff member moving from the Finance site to the Marketing site sees a completely different navigation bar with no obvious way back to anything else. Registering a communication site as a hub and associating the related team and communication sites with it fixes this in one step: every associated site inherits the hub's top navigation and theme, and search from any associated site can be scoped to search across the whole hub family, not just the one site the user happens to be on.

Building a simple company intranet

A basic company intranet doesn't need a dedicated product or a large project, it's a communication site combined with a hub, and it can be built in an afternoon.

1. 1Create a communication site as the home page, using the Topic or Showcase design depending on how visual the content is; this becomes the front door for company news, key links and policy documents
2. 2Register that communication site as a hub
3. 3Associate each department's team site (Finance, Operations, HR, and so on) with the hub, so they share the same top navigation and theme
4. 4Use the News web part on the home page for announcements, and the Highlighted Content web part to surface recently updated policy documents automatically rather than manually maintaining a link list
5. 5Set the intranet's own permissions to Visitors (read-only) for the whole organisation, with a small named Owners and Members group who actually publish to it, since a communication site is meant to be curated, not open for anyone to edit
6. 6Add a global search box scoped to the hub so staff can find a policy or a document without knowing which underlying site it lives on

This gets an organisation a genuinely useful intranet home page without needing SharePoint Syntex, a custom-built solution, or an intranet-in-a-box product, all of which are reasonable next steps once the basic hub-and-communication-site pattern outgrows its usefulness, but are rarely justified as a starting point.

Syncing a library to File Explorer, and 'Add shortcut to OneDrive'

Staff who want SharePoint files available in File Explorer, rather than only through a browser, have two options and they behave differently.

• Sync, available from the library toolbar, downloads a full local copy of the library through OneDrive and keeps it synchronised in both directions. This is the right choice for a library someone works in daily and needs available offline, but it does mean a local copy of every file, which matters for large libraries and managed-device storage limits
• Add shortcut to OneDrive adds a pointer to the library inside the user's own OneDrive, visible in File Explorer and on the OneDrive web app, without downloading every file. Content only downloads locally when a specific file is opened, and it's the better default for a library someone dips into occasionally rather than lives in

Both routes are the reason IT should restrict OneDrive sync, as covered in the tenant hardening baseline, to domain-joined or Intune-compliant devices. Either sync method effectively creates a local copy of tenant data on the syncing device, and an unmanaged personal laptop syncing a Finance library is a real data control gap, not a theoretical one.

Sharing externally, safely

External sharing, giving a client, contractor or partner access to a site or file, is a legitimate and common need, and SharePoint supports it at both the tenant level and the site level. The safest pattern is to share a specific site or folder with a named external guest, who then appears in Microsoft Entra ID as a guest account, rather than generating an anonymous link that needs no sign-in at all.

• Scope external sharing to specific sites where it's genuinely needed (a client collaboration site, for instance), rather than leaving it enabled tenant-wide by default
• Prefer guest accounts with expiring access over anonymous links; a guest account can be reviewed and removed, an anonymous link circulated by email cannot be tracked once it's out
• Set an expiry on external sharing links where the platform allows it, so access to a client project site doesn't quietly outlive the project
• Review the guest account list periodically, an external user with no sign-in activity in 90 days and no active project is a housekeeping item, not a decision to defer

Governance from day one

Almost every SharePoint governance problem Frontrow is asked to help untangle traces back to decisions, or non-decisions, made when the first few sites were created and nobody expected the platform to end up hosting the whole organisation's document estate. Setting a handful of conventions before the second or third site exists costs very little and prevents most of it.

• Naming convention, a short, consistent pattern (department or project name, not a personal name or an internal project codename that means nothing eighteen months later)
• Named ownership, every site has at least two named owners recorded somewhere central, not just inside the site's own permissions where nobody checks unless something breaks
• A lifecycle policy, a defined point at which a project site is archived or deleted once the project ends, rather than left live indefinitely; Microsoft 365 Groups can be configured with an expiration policy that forces this review automatically
• A site request process, even a simple form, so new sites get a name, an owner and a decision about hub association before they're created, rather than fixed up after the fact
• A periodic access review, quarterly is reasonable for most organisations, checking site permissions, external guest accounts and sharing links against what's actually still needed