Building a SharePoint Hub Site Structure for a Company Knowledge Portal

A knowledge portal lives or dies by its structure. You can pour months of effort into polished pages, beautiful banners, and carefully written articles, but if employees cannot find what they need in under a minute, the portal becomes another forgotten intranet experiment. SharePoint hub sites give you a powerful framework to avoid that fate, but only if you treat the planning phase as the real project. Building comes later, and it should almost feel like assembly once the blueprint is right.

This walkthrough focuses on what happens before you click "Create site." It covers how to think about hierarchy, navigation, and content types so that the portal you build actually reflects how your company works, not how SharePoint defaults nudge you to organize things.

Starting With Intent, Not Architecture

Before sketching any structure, get clear on what the knowledge portal is for. A portal that exists to onboard new hires looks very different from one designed to surface policies during audits or one meant to centralize project documentation across departments. Most companies need a blend, but the dominant purpose should shape every later decision.

Spend time with a handful of representative employees. Ask them what they search for, where they currently look, and where they give up. Watch how they describe departments and topics. You will almost certainly hear language that does not match your org chart. That gap, between formal structure and how people actually talk about their work, is the most important input you have. Hub sites let you align with the second, which is usually the more useful organizing principle for a knowledge portal.

You should leave this phase with a written purpose statement, a short list of primary user journeys, and a vocabulary list of terms employees actually use. Without these, everything that follows is guesswork dressed up as design.

Why Hub Sites Change the Planning Conversation

In the old SharePoint world, you planned a site collection hierarchy with parent-child relationships baked in at creation. Moving a subsite later was painful, and permissions inherited downward in ways that constrained how you could restructure.

Hub sites flipped this. Every site is now a flat, independent site collection, and hubs are simply associations. You connect a site to a hub, it inherits navigation and theme, and you can disconnect or re-associate it later with a few clicks. This means your structural decisions are no longer permanent, but it also means you need to think about hubs as logical groupings rather than containers.

The practical implication for planning is that you should design around themes of content and audience, not around departments by default. A hub for Human Resources makes sense if HR is genuinely a destination for employees. A hub for Sales Enablement might cut across Marketing, Sales, and Product, because that is how the content is actually used. Let purpose drive the hub boundaries.

Designing the Hub Layer

Most mid-sized companies end up with somewhere between five and twelve hubs. Fewer than that, and each hub becomes a sprawling mess that defeats the point of grouping. More than that, and employees face decision fatigue trying to figure out which hub holds what they need.

A reasonable pattern for a company knowledge portal includes a home hub that acts as the front door, then functional hubs for major areas like People and Culture, Operations, Customer-Facing Teams, Engineering or Product, and Corporate Services such as Finance, Legal, and IT. You might also have a Projects hub if cross-functional project sites are a significant part of how work happens.

The home hub deserves special attention. It is not a hub in the same sense as the others, because it does not typically have associated sites doing work underneath it. It is a curated landing experience that points outward to the other hubs, surfaces company-wide announcements, and offers a unified search entry point. Plan it as a publishing destination, not a workspace.

For each functional hub, write a one-paragraph description of what belongs there and what does not. This sounds trivial but it is the single most useful artifact for keeping the portal coherent over time. When someone two years from now wants to create a new site, that paragraph tells them whether it belongs in this hub or somewhere else.

Site-Level Structure Beneath Each Hub

Once you know your hubs, plan the sites that will associate with each one. Resist the urge to create a site for every team, every project, and every initiative. The portal is not a workspace replacement, it is a knowledge surface. Operational chatter belongs in Teams or in collaboration sites that may not need to be part of the hub at all.

For a knowledge portal, the sites associated with each hub typically fall into a few patterns. There are reference sites that hold relatively stable content like policies, standards, and reference documentation. There are program sites that document an ongoing area of work such as a quality program or a compliance framework. And there are resource sites that aggregate templates, forms, and tools for a particular audience.

Think carefully about whether project sites should be associated with hubs. Active projects produce a lot of churn, and associating them with a hub means their content appears in hub search and rolls up into hub news. Sometimes that is what you want, often it is not. A common pattern is to keep active projects as standalone sites and only associate them with a hub once they reach a stable, reference state.

Navigation as a Promise to Users

Hub navigation is what users see at the top of every associated site. It is the single most visible artifact of your planning work, and it deserves obsessive attention. Bad navigation cannot be rescued by good content.

The guiding principle is that hub navigation should answer the question "where can I go from here" rather than "what is the org chart." Limit yourself to a small number of top-level items, ideally no more than seven, and use dropdowns sparingly. If you find yourself wanting three levels of nesting, that is a signal that the hub itself might be doing too much.

Label items with verbs and outcomes where possible. "Submit an expense" beats "Expense forms." "Find a policy" beats "Policy library." This is harder than it sounds because it requires you to know what users are trying to do, which loops back to the user research from the first phase.

The home hub navigation should provide a clear map of all the other hubs. Many companies use a mega-menu pattern here, where hovering over a top-level item reveals a structured set of links to the major destinations in that area. This gives users a sense of the whole portal without forcing them to drill into each hub individually.

Plan navigation on paper or in a simple diagram before configuring anything in SharePoint. Walk three or four real employees through the proposed labels and ask them to predict what they would find behind each one. If their predictions match your intent, the navigation is working. If not, relabel and try again.

Content Types as the Quiet Backbone

Content types are where most knowledge portal projects fall short, because they require thinking that feels removed from the visible result. But they are what makes content findable, filterable, and governable over the long term.

A content type is essentially a template for a kind of information, with its own metadata fields, layout, and behavior. For a knowledge portal, you will typically define content types for things like Policy, Standard Operating Procedure, Reference Article, Announcement, FAQ, and Template. Each one has a defined set of metadata such as owner, review date, audience, related topics, and effective date.

Plan your content types centrally and publish them through a content type hub or, in newer SharePoint environments, through the content type gallery. This ensures that a Policy created in HR has the same structure as a Policy created in Finance, which means you can build search experiences and dashboards that work across the entire portal.

Think hard about the metadata fields. Each one should answer a question users actually ask when looking for or filtering content. Owner answers "who do I contact about this." Review date answers "is this still current." Audience answers "does this apply to me." If you cannot tie a metadata field to a real user question, it will not get filled in reliably and it will not be useful.

Managed metadata, configured through the term store, is worth the effort for fields like topic, department, and audience. It gives you controlled vocabularies that prevent the slow drift toward inconsistency that kills search quality. Plan the term sets alongside the content types, because the two are tightly linked.

Permissions and Audience Targeting

Knowledge portals work best when most content is open to most people. Heavy permission walls create the exact friction that drives employees back to asking colleagues over chat, which is what the portal is supposed to replace.

Plan for openness as the default and identify the specific exceptions. Executive communications, legal matters under review, and certain HR cases genuinely need restricted access. Most operational and reference content does not. When you do restrict access, do it at the site level rather than at the item level, because item-level permissions become unmaintainable surprisingly quickly.

Audience targeting is different from permissions and often more useful for a knowledge portal. It lets you show different navigation items, news, or page content to different groups without restricting access. A new hire sees onboarding resources prominently, a sales engineer sees technical playbooks, a manager sees leadership communications. Everyone could still reach all the content if they searched for it, but the default experience is tailored.

Plan audience targeting at the same time as navigation. For each navigation item and each prominent piece of content on hub home pages, decide whether it should be universal or targeted, and to whom.

Governance Before the First Site Exists

The structure you design will only hold up if there is a clear answer to questions like who can create a new site, who decides which hub it joins, and who is responsible for retiring content. These questions will come up within weeks of launch, and answering them in the moment usually produces inconsistency.

Define a small site request process, even if it is just a form that routes to one or two owners. Establish a simple ownership model where every site has a named business owner and a named technical contact. Set expectations for content review, typically annual for reference material and more frequent for time-sensitive content.

None of this needs to be heavy. A two-page governance document that real owners have read and agreed to beats a forty-page policy that nobody references.

Testing the Plan Before Building

Before you create a single site in SharePoint, do a paper walkthrough with a cross-functional group. Take five real scenarios, such as a new hire looking for the parental leave policy or a salesperson preparing for a renewal conversation, and trace them through your proposed structure. Where do they land first? How many clicks to the answer? What labels do they read along the way?

This exercise will surface problems that no amount of solo planning can find. Adjust the structure based on what you learn, then walk through the scenarios again. When the walkthrough feels boring because everything is obvious, you are ready to build.

The Building Phase Becomes Almost Mechanical

If you have done the planning work well, building in SharePoint becomes a sequence of straightforward steps. Create the hub sites, configure their navigation from your diagrams, publish the content types from your central hub, set up the term store with your planned vocabularies, create the associated sites and connect them, apply audience targeting where you planned it, and migrate or create the initial content.

The reason this feels mechanical is that every decision has already been made. You are not designing while building, which is where most SharePoint projects accumulate the inconsistencies that frustrate users later.

A knowledge portal is ultimately a long-term commitment to the relationship between your company and its own information. The structure you put in place at the beginning will shape that relationship for years. Spending real time on hierarchy, navigation, and content types before building is not over-engineering, it is the actual work. The clicking comes after.