SharePoint hub sites: intranet navigation, site hierarchy, and permissions

How can many SharePoint sites be connected into a comprehensible intranet without building a rigid subwebsite hierarchy? SharePoint Hub Sites form a logical container around independent sites. They can provide a shared hub navigation, a coordinated look and feel, and hub-related content or search results. The assigned sites remain independent security and administration areas. A hub assignment does not automatically inherit the hub's permissions to all connected sites.

Thus, SharePoint Hub Sites are primarily a tool for information architecture: they structure how users find content and recognize connections. They do not replace a permissions model nor the decision of which content belongs to which site. Whoever first attaches all existing sites to a hub and then thinks about navigation, owner, and search boundaries merely shifts the existing chaos into a new interface.

What SharePoint hub sites are and how they differ from normal sites

Every modern team or communication site is initially an independent SharePoint site with its own URL, its own site administrators, its own groups, and its own content. A permitted administrator role can register a suitable site as a Hub Site. Other sites are subsequently assigned to this hub.

The hub connection can provide the following shared elements:

• a hub navigation across the assigned sites,
• a shared hub design,
• news, event, or content aggregation from connected sites,
• a search area focused on the hub and its assigned sites,
• a clear business connection, such as Unternehmen, Standorte, Qualitätsmanagement, or Projekte.

The assignment does not automatically change:

• members and visitors of the connected sites,
• library or folder permissions,
• sensitivity and sharing settings,
• retention rules,
• ownership or operational responsibility.

This separation is an important security feature. For example, a personal site can belong to the corporate hub visually and navigatively without all intranet visitors gaining access to personal documents. Conversely, a site can be visible in the hub navigation even though a user has no access when opening it. Visibility and permission must therefore be consciously coordinated.

Before configuration: plan the intranet structure as a business model

A robust hub architecture does not begin in SharePoint administration but with a list of business teams and usage scenarios.

Answer five questions per area

1. Who owns the content? Name a responsible role and at least one substitute.
2. Who should read? Entire organization, individual locations, departments, project teams, or external parties?
3. Who may publish? Editorial group, site members, or only a few owners?
4. How long does the area last? Permanent intranet, time-limited program, or single project?
5. How is the content found? Navigation, search, audience targeting, linking, or a combination?

These answers determine whether content belongs in the same site, separate sites, or even separate hubs.

Hubs are not classic tree levels

SharePoint hubs form a flat, flexible connection between sites. They should not be understood as an exact copy of an organizational chart. Organizational charts change frequently; information needs are often more long-lasting. A site Arbeitssicherheit can be relevant for multiple business teams and should not need to be rebuilt with every organizational change.

A suitable structure therefore aligns more with stable information domains:

Domain: Corporate intranet

Possible sites: Start, News, Services, Locations

Typical audience: all employees

Domain: Business teams

Possible sites: HR, IT, Procurement, Quality

Typical audience: company-wide or business-specific

Domain: Collaboration

Possible sites: Projects, Programs, Communities

Typical audience: defined teams

Domain: External spaces

Possible sites: Partners, Customers, Suppliers

Typical audience: internal and external participants

Domain: Confidential areas

Possible sites: Personnel files, Legal, M&A

Typical audience: highly restricted roles

Not every domain needs to be its own hub. Too many hubs create new navigation breaks and additional administrative effort.

Hub connection: which sites fit and which should remain separate

Suitable candidates

A site fits a hub if it shares the same information context, a similar audience, or requires common navigation. Typical examples are location sites under a corporate hub or business team sites under a knowledge hub.

Before assignment, check the following:

• Is the site modern and technically supported?
• Are there active owners?
• Are the title, description, and logo clear?
• Does the external sharing match the hub context?
• Are there confidential contents that could become unintentionally visible through navigation or aggregation?
• Are search results for authorized users domain-specific and meaningful?

Consciously separated areas

Separation is sensible when the security model, lifecycle, or target audience differ significantly. This often includes:

• external B2B portals,
• strictly confidential HR or legal areas,
• short-term project sites,
• sites with their own regulatory retention rules,
• test and development areas,
• personal or experimental team sites.

Separation does not mean that links cannot be set. It only prevents a shared hub navigation or aggregation from suggesting an organizational connection that does not exist from a security perspective.

Multiple levels with hub assignments

Microsoft supports hub relationships and, depending on the respective configuration, also connections between hubs. A deeply nested hub landscape should still be avoided. Each additional level makes it harder to determine which navigation, search, and editorial function is currently most relevant.

A practical rule is: A user should be able to reach the goal from any important page in a few understandable steps, without needing to know the technical site model.

Navigation: let hub navigation and local navigation work together

Distinguish global, hub, and local navigation

In an intranet, multiple navigation layers can occur:

• global navigation for organization-wide main goals,
• hub navigation for content within an information domain,
• local site navigation for libraries, pages, and features of a single site,
• contextual links within pages, cards, or web parts.

Each level should serve a different purpose. Repeating identical links across all levels creates no orientation, but visual noise.

Create a navigation model

For each navigation point, document the following:

Links to individual files are usually unsuitable as permanent main navigation. A landing page can provide context, the responsible party, and alternative paths.

Do not confuse audience control with security

Navigation can be shown or hidden for target audiences. This function improves overview but does not replace access checks. A hidden link does not deny any user permission; a visible link does not grant access. Security is managed at the site, library, folder, or item level.

Permission inheritance and isolation: what hub sites share and what they do not

The most important rule

A site does not automatically receive the same users and groups as the hub when assigned to one. Each site's permission model remains independent. Microsoft provides features that allow hub visitor permissions to be synchronized with assigned sites. However, this feature must be deliberately planned and activated; it does not replace the review of local exceptions.

Before a synchronization, the following questions should be answered:

• Should every connected site really be accessible by the same reader group?
• Are there sites with confidential libraries or different visitors?
• How are external guests handled?
• Who is allowed to add local members?
• How is an accidental interruption of inheritance detected?

Groups instead of individual permissions

Assign access preferably via Entra ID or Microsoft 365 groups or clearly named SharePoint groups. Individual permissions complicate audits and offboarding. Particularly problematic are many individually shared files and folders, because they increase the number of unique permission areas and can hardly be documented clearly anymore.

A simple role model per site can look like this:

• Site-Owner: technical and business responsible persons,
• Site-Mitglieder: persons who edit content,
• Site-Besucher: reading audience,
• additional business roles only when justified.

Owners should be reviewed regularly. An orphaned site without active responsible persons is an operational risk, regardless of the hub assignment.

Search integration: properly assess hub-related results

SharePoint search considers permissions: users should only see results they have access to. A hub-related search can focus the context on the hub and assigned sites. This improves relevance if sites are assigned clearly according to business needs and content is clearly labeled.

Search needs metadata and editorial quality

A hub assignment does not fix unclear titles, empty page descriptions, or inconsistent file names. For findable content, the following are important among others:

• understandable page titles,
• consistent terms and synonyms,
• maintained metadata,
• appropriate content types,
• clear publication statuses,
• no unnecessary copies of the same document.

For extensive knowledge areas, a targeted search interface can be useful. How search fields, filters, and result display can be set up in SharePoint is shown in the article FAQ and Knowledge Base with SharePoint and PnP Search.

Test security-trimmed search

The statement "Search is security-trimmed" must not be assumed only theoretically. Test with multiple roles:

1. company-wide reader,
2. business team member,
3. site owner,
4. external guest,
5. user without access.

Search for unique test terms in public and confidential documents. Check results, preview, link target, and possible aggregation web parts. Note that indexing and permission changes are not always immediately visible in all search interfaces.

Implementation in controlled steps

Step 1: inventory

Export or document active sites with URL, template, owners, members, external sharing status, storage usage, and last activity. Mark duplicates, orphaned sites, and sensitive areas.

Step 2: draw target architecture

Create a simple map with hubs, assigned sites, target audiences, and main navigation. Avoid technical detail depth before the business assignment is clarified.

Step 3: select pilot hub

Select an area with a manageable number of sites, active owners, and low external risk. Build navigation, design, search, and permission checks completely.

Step 4: assign sites gradually

Do not assign all sites at once. Check after each group:

• navigation,
• design,
• search area,
• news aggregation,
• visitor access,
• mobile display,
• existing direct links.

Step 5: define the operating model

Document who can register hubs, assign sites, change navigation, and control owners. Define a review cycle and a process for archiving or moving sites.

Typical errors and concrete fallback paths

Error: the hub is explained as the permission container

Symptom: Responsible parties assume that a hub assignment grants or revokes access.

Correction: Check permissions for each site separately; document optional visitor synchronization and validate it with test accounts.

Fallback: Disable synchronization, restore local visitor groups, and reassign access based on a shared matrix.

Error: the navigation mirrors the organizational chart one-to-one

Symptom: Restructuring efforts constantly lead to new sites, links, and names.

Correction: Align navigation with stable tasks and information domains.

Fallback: Use redirects and transition pages before changing URLs or sites.

Error: too many hubs

Symptom: Users switch between several nearly identical navigation bars and do not know which area is authoritative.

Correction: Consolidate hubs and merge shared target audiences or content.

Fallback: Gradually remove site assignments; decommission old hubs only after link and search tests.

Error: aggregation shows inappropriate content

Symptom: News or events appear in the wrong context.

Correction: Control sources, sharing status, target audiences, and editorial processes.

Fallback: Temporarily limit the aggregation web part to selected sites.

Error: a site has no active owners

Symptom: Navigation or permissions cannot be validated from a business perspective.

Correction: Assign at least two responsible individuals or a clearly defined functional role.

Fallback: Remove the site from the active Hub navigation until ownership and content are verified.

Acceptance test for a SharePoint hub

A Hub is considered production-ready only when at least the following tests are documented:

• Hub navigation functions on desktop and mobile devices.
• Local navigation remains clear and does not conflict with Hub navigation.
• Users without access do not see confidential search results.
• Audience targeting was not used as a substitute for permissions.
• News and events originate only from approved sources.
• Site owners and deputies are designated.
• External guests receive only designated content.
• Archived or moved sites do not create broken main links.
• Permission changes and search index delays are addressed in the operations manual.
• A rollback of the site assignment was verified during the pilot.

For project-specific repositories with clear site boundaries, the article Central Project Repository in SharePoint Instead of Paper Planning provides additional architectural context.

How to keep intranet architecture manageable despite growing user and content counts

A robust Hub architecture connects sites through navigation, design, and search context without blurring their security boundaries. Key elements are a few, business-understandable Hubs, active owners, documented assignment, group-based permissions, and recurring tests with real user roles. This allows the Intranet to grow without needing to be rebuilt with every organizational change.