The multi-property content stack: how teams running 5 to 20 sites structure content

Running three websites and running thirteen are different jobs, even though the tooling looks identical from the outside. Somewhere between the fourth and sixth property, the cost of duplication stops being an annoyance and starts setting a ceiling on what your team can attempt.

This is a field guide to how teams running 5 to 20 distinct web properties structure content. What belongs in one shared place, what has to stay local to each brand, and where the boundaries should fall so the structure survives the next launch.

Why the fifth property is usually the breaking point

With two properties, copying things works fine. By the fifth, copying has produced five slightly different versions of the same content model, and nobody can say which one is correct.

Three specific failures show up at that point:

1. A field was renamed on one property and not the others, so no query works across brands.
2. An editor can publish on one property and has no account on the other four.
3. A design system change has to be implemented five times, because each property owns its own components.

None of these is dramatic on its own. Together they mean every cross-brand initiative needs a project plan, a kickoff, and an engineer.

Decide what is shared before you decide what is different

The most useful exercise here takes an afternoon. Draw a line down the middle of your content and put every type on one side of it.

Shared across every property:

• Taxonomy: categories, tags, topics, product classifications
• Media: one library, one CDN, one set of image transformations
• Author and contributor profiles, if anyone writes for more than one brand
• Design tokens and shared component definitions
• Legal, compliance, and boilerplate copy
• Anything you will ever want to report on across brands

Local to each property:

• Editorial calendar and publishing schedule
• Navigation and site structure
• Brand voice fields, disclaimers, and regional legal copy
• Permissions: who can publish on this specific property
• Localization: which locales this property actually ships
• Integrations: analytics IDs, commerce endpoints, form handlers

The rule of thumb is simple. If two brands would ever need to answer the same question with the same data, that data is shared. If a change on one brand should never affect another, that data is local.

Most teams get this backwards in one specific way: they share the things that are easy to share (templates, components) and duplicate the thing that hurts most when duplicated (the content model).

Where the boundary falls in practice

In Cosmic, the hierarchy is a Workspace that holds Projects, and each Project holds Buckets.

• One Project per property. Each brand, client site, or location gets its own content, its own models, its own API keys, and its own permissions.
• Buckets inside a Project separate environments or closely related sub-properties: a production and staging pair, or a main site plus a microsite that shares the same team.
• The Workspace is the layer where billing, team membership, and cross-property administration live.

That structure exists because the two obvious alternatives both fail, in opposite directions.

The pattern that fails first: one Bucket, ten brands, one brand field

This looks elegant on a whiteboard. Every property lives in one place, every query filters by a brand field, and there is exactly one content model.

It breaks on permissions. An editor for brand three can technically read and edit brand seven's unpublished content, because they are the same objects with a different field value. Every guardrail you want has to be built in the application layer, and it has to be perfect. A single API key leak exposes every property at once. Publishing a change to shared taxonomy hits all ten sites at the same moment, whether or not all ten were ready.

The pattern that fails later: ten unrelated accounts

The opposite approach gives every property its own subscription and its own admin panel. Isolation is genuinely solid. Everything else degrades.

You now have ten invoices, ten sets of user accounts to provision and deprovision, ten security reviews, and ten content models that will drift apart. Onboarding an editor who works across three brands means three separate invitations. Nobody can answer "what did we publish across all properties last week" without opening ten tabs.

The reason the middle path works is that isolation and administration are separate concerns. Content and permissions want to be isolated per property. Billing, team membership, and tooling want to be shared.

Reading content across properties

Once every property shares the same model, cross-brand reads become boring, which is the goal. One client per property, one query shape everywhere:

import { createBucketClient } from '@cosmicjs/sdk';

const properties = [
  { name: 'Brand A', bucketSlug: 'brand-a', readKey: process.env.BRAND_A_READ_KEY! },
  { name: 'Brand B', bucketSlug: 'brand-b', readKey: process.env.BRAND_B_READ_KEY! },
  { name: 'Brand C', bucketSlug: 'brand-c', readKey: process.env.BRAND_C_READ_KEY! },
];

const clients = properties.map((property) => ({
  name: property.name,
  cosmic: createBucketClient({
    bucketSlug: property.bucketSlug,
    readKey: property.readKey,
  }),
}));

// The same query against every property, because the model is the same everywhere.
const recentAcrossProperties = await Promise.all(
  clients.map(async ({ name, cosmic }) => {
    const { objects } = await cosmic.objects
      .find({ type: 'posts' })
      .props(['title', 'slug', 'metadata.published_date'])
      .sort('-created_at')
      .limit(5);

    return { property: name, posts: objects };
  })
);

Notice what makes this work. Not the code, which is trivial. It works because type is posts on every property and metadata.published_date means the same thing everywhere. The moment one property calls it publish_date, this function needs a special case, and special cases are how a shared model quietly stops being shared.

What breaks at fifteen properties that was fine at eight

Three things scale worse than teams expect:

Media duplication. The same product photo uploaded eleven times, cropped eleven ways, with eleven different filenames. One shared media layer with URL-based transformations solves this permanently, and it is worth doing before you need it.

Editor onboarding. At eight properties, a new editor gets a walkthrough. At fifteen, the walkthrough is a full week and it is different for every property, because each one has its own quirks. Uniform models make onboarding one conversation instead of fifteen.

Reporting. "How much did we publish, where, by whom" is trivial when field names match and impossible when they do not. This is the question executives ask first and the one most multi-brand stacks cannot answer.

The goal is editors who do not need engineers

The structural work above has one practical payoff, and one of our customers described it better than we could:

"Cosmic is: us never having to ask a developer to change anything on the backend of our website."

Maximilian Wuhr, Co-Founder at FINN

Multiply that sentence by ten properties and you have the whole business case. Every content change routed through an engineer is a change that waits for a sprint. Across ten brands, that is ten queues and a content team whose velocity is capped by somebody else's backlog.

A checklist before your next property launches

Run through this before brand number eleven, not after:

• Is there one canonical content model that a new property starts from, stored somewhere a person can find?
• Does the same field mean the same thing on every property today?
• Can an editor who works across three brands be provisioned once?
• Is media shared, or duplicated per property?
• Can you answer "what shipped across all properties last week" in one query?
• When a property is retired or handed to a client, what exactly has to happen?

If you cannot answer the last one, that is the one to fix first. It gets harder every quarter.

Where to start

If you are running five or more properties today, the structure matters more than the feature list. Cosmic Workspaces are built for exactly this shape: one Workspace, one Project per property, one bill, one team.

The Large Workspace plan covers 10 Projects, 30 Buckets, and 30 team members at $2,999/month. Small Workspace covers 5 Projects, 10 Buckets, and 10 team members at $999/month. Both include a 30-day free trial, so you can model your real structure before committing to it.

• See how Workspaces are structured: cosmicjs.com/workspaces
• Start a free 30-day trial: app.cosmicjs.com/signup
• Talk through your specific property count and team shape with our CEO: book 30 minutes

If your models have already drifted apart, start there instead. We wrote about how that happens and how to fix it in content model drift.