Component Library Sprawl and the Naming Audit
After a year, a Site Studio site has accumulated 60+ components. Editors complain they cannot find the right one: there are three "Card" components, two "Hero" components, and several near-duplicates with names like "CTA v2 final" and "CTA new." Some components are used on only one page; others are unused. The team wants to clean up without breaking live pages, and they want to prevent the sprawl from returning. They have a release window of one sprint and cannot afford a full rebuild.
1. How do you safely identify what can be removed or consolidated, given that pages are live?
Read the worked answer
Safety first: usage data before deletion.
- Inventory usage: query which components are referenced by live pages/templates (via the Site Studio entity references, database queries, or a usage report). Mark each component as used-once, used-many, or unused.
- Do not delete used components in this sprint; instead, deprecate them - hide from the editor picker and add a "do not use, use X instead" note.
- Consolidate near-duplicates only where their rendered output and editable fields can be reconciled; otherwise keep both and deprecate the loser.
- Delete only confirmed-unused components, and do it after a backup and on staging first.
The judgement: distinguish unused (safe to remove) from used but redundant (deprecate, don't delete), because deleting a used component breaks live pages you cannot fully test in one sprint.
2. What governance would you put in place to prevent sprawl from returning?
Read the worked answer
Governance:
- Naming convention enforced in review:
category-purpose-variant(e.g.,card-product-default), no version suffixes like "v2 final." - A component request/review step: new components require a reason the existing library cannot serve, reviewed by a maintainer.
- A living catalog (documented component library) so editors can see what exists before building.
- Deprecation policy: superseded components are hidden, documented, and removed on a schedule.
- Periodic audit (quarterly) using the same usage report to catch new orphans.
The tested judgement: cleanup is a one-time fix, but sprawl is a process problem - the durable answer is a lightweight governance loop, not just deleting duplicates this sprint.