I recently started working in a new tenant, and one of the first questions I wanted answered wasn't "what's broken," it was simpler than that: what's actually here. What am I dealing with? Before you can fix anything, you need to know what you're looking at, is this a tidy environment with a real content model behind it, or is it a free-for-all.
Content types and the term store are two of the clearest signals for that question, and both are easy to get a misleading read on if you don't know what to filter out first. I built a script for each, and ran both against a real tenant.
Content types: global versus local
SharePoint gives you two ways to create a content type. You can publish one centrally from the Content Type Hub, syndicated out to every site that subscribes to it, consistent by design, one source of truth. Or a site owner with the right permissions can just create one directly on their own site, no approval, no central visibility, nothing stopping them from calling it whatever they like.
Both are legitimate, and a tenant's global content type count tells you how much is being centrally managed. Its local content type count tells you how much sprawl exists outside that control entirely, and sprawl is where duplication, inconsistency, and confusion tend to live.
Running the script against a real tenant produced a clear, if slightly sobering, picture.
Thirteen content types published globally from the hub. Zero usage of any of them, anywhere, on any list. The hub exists, but nothing in the tenant is actually built on it.
Three hundred and twenty-five local content types. That's the number that tells the real story here, this tenant's content model has been built entirely site by site, not centrally.
The most interesting detail wasn't the total, though, it was the shape of the duplication. Content type names like Guidelines, Policy, Tools, News, showed up frequently indicating that different sites were built on the same ideas, but weren't being managed in a coordinated fashion. There were also cases where the exact same content types had been deployed to multiple sites, a repeated setup process, the same site template or provisioning routine run twenty-three times, each run creating its own independent local copy of what's conceptually the same content type, rather than any of them ever pointing back to something shared.
Term store: the same question, a very different answer
I expected the term store to tell a similar story. It didn't, once I filtered it correctly, and getting that filtering right turned out to be the actual lesson worth sharing.
The first pass looked messy: nineteen term sets, eleven of them completely empty. Fifty-eight percent empty is the kind of number that makes you assume nobody's maintaining the taxonomy. But looking closer at exactly which sets were empty told a different story. Every single one of the eleven belonged to groups SharePoint provisions automatically behind the scenes, Search Dictionaries, System, and a handful of Site Collection scaffolding groups, none of it part of the tenant's actual working taxonomy.
Once those are correctly excluded, the real picture is the opposite of what the first pass suggested: every genuinely human-managed term set in this tenant has real terms in it, properly closed to open editing, no sprawl. A clean, well-governed taxonomy, the exact opposite conclusion the raw numbers implied before filtering.
One deliberate exception: I left the People group in scope rather than filtering it out with the other system groups. Many organisations use it genuinely, Department, Job Title, and Location terms driving profile-based tagging, so an empty People set is a real, worth-knowing governance observation, not scaffolding noise to hide. In this tenant, it does show up empty, which is a fair, specific thing to flag, this particular feature was never adopted, rather than a taxonomy problem.
Why both are worth knowing, even before deciding what to do about them
I want to be careful not to oversell either finding. Three hundred content types built site by site isn't a disaster, plenty of tenants run for years exactly like this without anything actually breaking. And a clean term store doesn't mean there's nothing left to improve, an unused People taxonomy is still worth a conversation.
What both audits give you is the same thing: an honest starting point, rather than an assumption. A migration, a redesign, a governance push, all of these land very differently depending on what's actually there. Guessing, or assuming a hub exists and is therefore doing its job, or assuming an empty-looking term store means poor governance, would have been actively misleading in both directions here.
The scripts
Both scripts are available in the scripts library:
- Content type analysis, produces four reports: the global content type inventory, where each one is actually used, the full local content type list with duplicate names flagged, and any list-level content type that's drifted from its parent. Full write-up.
- Term store analysis, produces a full inventory, empty term sets, terms with missing translations across configured languages, and term sets that appear unused anywhere in the tenant, with the system-scaffolding groups correctly excluded from the start. Full write-up.
Neither is a fix. Both are an honest inventory, which, on a tenant you're just getting to know, is usually the thing you actually need first.