SharePoint information architecture: get it right before anyone creates a site

A SharePoint deployment that goes off the rails almost always goes off the rails in the first month. Two new sites become twenty. Permissions break inheritance in ways nobody documented. The same document exists in three places. The team starts emailing attachments again, because nobody can find anything.

The platform is rarely the problem. The problem is that someone clicked “Create site” before anyone designed the information architecture.

What IA actually means in SharePoint terms

A SharePoint information architecture is three things:

• Site topology. What sites exist, why they exist, and how they relate. In modern SharePoint that means hub sites at the top, communication or team sites grouped under them, and a single intranet root that ties it together.
• Permission model. Who can see what. The default is inheritance from the hub down. Where you break inheritance, you should be able to write down the reason in one sentence.
• Naming and metadata conventions. What sites get called. What columns and content types are standardized across libraries. What is searchable and how.

The first month is when these decisions either get made deliberately or made by accident. Default behavior makes them by accident every time.

The starting questions

Before any site is created, answer these in writing:

1. What are the natural permission boundaries in your business? Departments are the easy answer. Project teams are the messy one (often cross-departmental, often time-bounded).
2. Who needs to find what content, and how do they expect to navigate to it?
3. What types of content live here, and which ones share enough metadata to benefit from a content type?
4. How will you retire content? SharePoint is good at growing and bad at shrinking unless you make retirement a deliberate part of the design.

If you cannot answer these, you are not ready to create sites yet.

A simple starting topology

For most mid-market businesses, this works:

• One intranet root as the home page. Branded, communication-site type. Read-only for most users.
• Department hub sites. One per department that has its own content and permission profile. HR, Finance, Operations, IT.
• Project team sites under the relevant hub, created from a template, time-bounded, archived when the project ends.
• A single document center for documents that genuinely need to live above any one department: company-wide policies, board materials, audit artifacts.

That is enough structure to start. Resist the temptation to design a five-level taxonomy on day one. The structure that survives contact with users is the one with as few levels as possible.

Permission patterns that work

Inherit by default. Break inheritance only when there is a specific justification, and document it on the site itself.

The patterns we see most often:

• Inherited from hub. Default for every site. Members of the hub can read content. Specific roles within the hub can edit.
• Restricted within hub. A folder or library that should be visible only to a subset (HR’s confidential personnel files inside the HR hub). Break inheritance, document the why.
• Cross-hub access via Microsoft 365 groups. When a project team needs members from multiple departments, do not break inheritance on the hub. Create a Microsoft 365 group, give the group access to the project site, and manage membership through the group.

The pattern that does not work: creating a flat list of sites with custom permissions on each. Within six months, nobody will remember why a given user has access to a given site.

Naming conventions

Lock these down before sites multiply.

• Site URLs. Lowercase, hyphenated, no abbreviations that the team will forget in a year. finance-board-materials, not fin-bd-mtrls.
• Site titles. Title case, no punctuation, no department names in the title (the hub provides the context).
• Library names. Singular nouns. Document, not Documents. Consistency across sites matters more than what you pick.
• Content type names. PascalCase, descriptive. PurchaseOrder, not PO Form.

These look picky. They are picky. They are also the difference between a SharePoint deployment that someone can browse intuitively in year three and one where everyone has bookmarked their favorite paths and the search results look like a junkyard.

The migration trap

If you are migrating from a file share or a previous SharePoint version, do not replicate the source structure into the new tenant. The temptation is huge because it feels safe. It is the single biggest predictor of a failed migration.

Take the migration as a forcing function for IA work. Map the existing content to the new topology. Retire what should not move. Restructure what survives.

This is uncomfortable, slow, and the right answer.

Where to start

Pick a calendar week. Cancel the meetings. Write down:

• The hub structure
• The permission inheritance pattern
• The naming conventions
• The retention or retirement rule for project sites

Have one person own each. Get sign-off from the people who will live with the result. Then create the first site.

You will save several months of cleanup later, and your team will actually use the platform.