Published: 15 July 2026 | Category: Governance
You inherit a hub site with forty associated content types, six of which are used somewhere, and thirty-four of which nobody remembers creating. This is not a hypothetical. It is the normal end state of a SharePoint Online tenant that has been live for more than two years without anyone specifically owning content type governance.
What content type sprawl actually looks like
Content types in SharePoint Online exist to give structure to unstructured content: a set of columns, a document template, and validation rules bundled under a name like "Client Contract" or "Project Charter." Used well, they are one of the most powerful metadata tools Microsoft 365 offers. Used carelessly, they multiply.
A library owner needs one extra field, so they create a new local content type instead of asking for a change to the hub-published one. Another team copies a site rather than requesting a new one from a template, carrying forward every local content type the source site had accumulated. A migration project imports metadata from a legacy platform and maps each source category to a brand-new content type rather than reconciling with what already exists. None of these decisions is unreasonable in isolation. Together, over years, they produce a term store and a content type gallery that no single person understands end to end.
The content type gallery is one of the few places in SharePoint where deletion is genuinely dangerous, which is exactly why nobody prunes it. Admins default to leaving things alone rather than risk breaking a library they cannot fully trace.
Why it is hard to see
Unlike storage consumption or permission grants, content type sprawl does not show up on a dashboard. The SharePoint admin center has no view that lists every content type across every site, how many are local versus hub-published, or which ones are actually attached to items still in active use. Finding out requires opening site settings on a site-by-site basis, or writing a script that walks every site collection and every library within it.
The practical cost shows up sideways. A migration project takes longer than estimated because the source tenant has 200 distinct content types where three or four would have sufficed. A compliance audit stalls because nobody can say with confidence which content type governs which document category. A new admin inherits a tenant and spends their first month reverse-engineering a metadata structure that predates their employment.
Hub propagation adds a second layer
Content type hubs make the picture more complex, not less. A content type published from the hub propagates to associated site collections on its own schedule, not instantly. Sites that were unassociated at the time of a hub update, or associated late, can end up with a stale copy of a content type that has since changed. The result is multiple sites all claiming to use the same named content type while actually enforcing slightly different columns underneath. For the mechanics of how that propagation timing works, see the content type hub propagation reference.
The three questions worth asking
Before scheduling a full metadata cleanup project, three questions usually surface most of the risk:
- How many content types in this tenant are local to a single library rather than hub-published, and were any of them created to work around a governance gap rather than a genuine business need?
- Which content types are actually attached to items with real content, versus sitting unused since the site was provisioned from a template?
- Are there near-duplicate content types with different names doing the same job, created independently by different teams who did not know the other existed?
Bringing content types back under control
The fix is rarely a wholesale rebuild. It is closer to triage: identify what is duplicated, retire what is unused, and standardise the rest on the hub-published version. ShareMaster's Explore Master supports the mechanical part of this, letting an admin inspect hidden column properties on items across a library and bulk-update content types where a library has drifted onto a local variant that needs to be reset back to the shared standard. That does not replace the governance decision of which content types to keep, but it removes the tedium of applying that decision one item at a time.
The Report Master Excel export is a reasonable starting point for the audit itself: pulling version counts and storage utilisation per library gives a rough proxy for which libraries are active enough to justify the effort of reconciling their content types first.
A governance habit, not a project
Treat content type creation the way a mature tenant treats permission grants: something that requires a reason, gets recorded, and gets reviewed. A simple rule helps more than any tooling: before creating a new content type, check whether an existing hub-published one can be extended with an extra column instead. Most sprawl traces back to that single decision being skipped, repeatedly, over years.
Sites accumulate structure the same way they accumulate storage and permissions: quietly, and in the direction of more rather than less, unless someone actively pushes back. Content types are just the least visible of the three, which is exactly why they deserve a place on the same governance calendar as your version and permission reviews. For the broader governance cadence this fits into, see where to start with SharePoint governance.