You run twelve client sites at your agency and each one has a blog, a team page, and a services section. When you improve the blog post content type — adding a reading time field or a related posts reference — you want that improvement on every site, not just the one you happen to be working on. Shared content type libraries make this tractable.
The Multi-Space Problem
ContentGrid gives each project its own space. Content is isolated per space, which is correct — you do not want client A's content appearing on client B's site. But schemas are also per-space, which means schema drift accumulates over time. The solution is to treat your shared content types as a package and push schema updates via migration scripts rather than manual dashboard edits.
- Define canonical content types in a shared schema-library/ repository or directory.
- Write migration scripts that apply changes to a list of target spaces.
- Run migrations against all spaces from CI when the shared library changes.
- Keep site-specific extensions separate from shared types.
Structuring the Schema Library
Organise your shared types in a dedicated repository that all client projects reference:
- Create a content-types/ directory with one file per shared content type.
- Each file exports a ContentGrid schema definition object — field names, field types, validations.
- Create a migrations/ directory for changes to shared types.
- Publish the schema library as a private npm package so client projects can install it as a dependency.
When a shared type changes, you bump the package version, update the migration, and run the migration against all registered spaces.
Running Migrations Across Multiple Spaces
Write a migration runner script that loops over your client space IDs:
- Store all client space IDs and API keys in a secrets manager or environment file, never in the repository.
- The runner reads the space list, initialises a ContentGrid Management client per space, and calls the migration up function for each.
- Log the result per space — success or failure — and send a summary to a Slack channel.
- On failure, the runner continues to the next space rather than stopping, so one problem client does not block the others.
Extending Shared Types Per Client
Clients often need site-specific fields on top of shared types. Handle this with an extension pattern:
- Shared types define core fields that apply everywhere.
- Each client space has a separate local migration that adds site-specific fields to the shared type.
- The shared library migration only touches fields it owns — it never removes or changes site-specific fields.
- Document which fields are shared and which are local so future developers know what to change where.
This setup takes a day to build but pays back quickly on teams managing four or more client sites. Schema changes that used to take a week across all sites now take an afternoon, and all sites stay consistent without manual copying.
Ready to start tracking your competitors?
ContentGrid automatically monitors competitor websites, emails, and social media — and delivers structured intelligence straight to your inbox.