A multisite CMS for agencies: every client site in a single instance.

The hidden cost of one installation per client

Many agencies start with a straightforward model: a new client means a new CMS installation. Each site gets its own hosting, its own database and its own plugins. Early on, this works well. Every project stands alone.

Once you reach twenty or thirty clients, the maths changes. Every maintenance task is multiplied by the number of sites:

• Updates: the CMS core, the theme and every plugin, tested and applied one site at a time.
• Plugins: different versions on different sites, some of them no longer maintained.
• Backups: one scheduled job per site to monitor, and one restore procedure per site to master.
• Security: every forgotten installation is a potential way in.

This time is rarely billed at its true value. Yet it eats into the margin on every maintenance contract, month after month.

What a multisite instance changes

A multisite CMS runs several sites from a single installation. You update once, back up once and monitor one hosting platform. Maintenance and hosting are shared.

Sharing is not the same as merging. With a good multisite tool, each site keeps:

• its own domain names;
• its own design, theme and stylesheets;
• its own languages, with a separate URL for each language;
• its own media library and content.

To visitors and to search engines, these are entirely separate websites. Multisite is about how you organise things internally, not how the sites look. For the technical side, see our page on multisite and multilingual.

Keeping clients separate

A client's first question is often: "Will other clients be able to see my site?" The answer must be no, and the tool must enforce it.

That relies on roles assigned per site. A user is given rights on one specific site, not on the whole instance. Typical roles include:

• media: uploading and organising images and documents;
• content: writing and editing pages;
• developer: working on layouts, the theme and code;
• administrator: managing the site and its users.

Your client gets an account on their own site only. Your team keeps the wider permissions. Check this during a demo before you choose a tool: log in with a client account and make sure it only sees its own site.

Standardise without making everything look the same

The trap with multisite would be to ship the same website to everyone. That is not the point. The aim is to reuse the structure, not the look.

• Reusable layouts and components: headers, footers, banners, article layouts. Build them once, then adapt them.
• Page cloning: a well-built "legal notice" or "contact" page becomes the starting point for the next client.
• Free design for each client: every site has its own CSS theme, whether you write it by hand or use a framework such as Tailwind.

You save time on what repeats and reinvest it in what makes each client distinctive. Our layouts and components page explains this approach in more detail.

Client autonomy, within limits

Clients want to change their copy without phoning you. You want to stop them breaking the layout. Both goals can coexist.

1. The client edits the content: text, images, news.
2. The agency keeps control of the layouts, the theme and shared components.
3. Changes go through drafts and are reviewed before publishing.
4. Revisions let anyone roll back to an earlier version after a mistake.

This setup cuts down on "I've broken everything" tickets and reassures clients: they can experiment safely.

Using AI to deliver faster

AI assistants can now work directly inside a CMS, through an API or an MCP server (a protocol that lets an agent use a piece of software's tools). For an agency, three uses stand out:

• From client brief to website: the agent reads the brief, the supplied copy and the brand guidelines, then proposes a site structure and creates the pages as drafts.
• Client feedback: "change this heading, add a pricing section". The agent applies the requests as drafts, and you approve them.
• Language versions: the agent creates translated variants linked to the original page, ready for a human to review.

The crucial point is that the agent works with the permissions of the person who connected it and only produces drafts. Publishing remains a human decision. In Plumixia, for example, this is how the built-in MCP server works.

Points to watch

Multisite is not the right answer in every case. These are the questions to ask yourself honestly.

Relying on a single tool

All your clients depend on the same platform. An outage or a failed update affects everyone. Insist on a test environment and a clear rollback procedure.

Reversibility

A client may want to leave. Check how you would retrieve their content and media in a usable format, for instance through an API. Plan 301 redirects too, in case URLs change during a migration.

Contracts and hosting

Spell out who hosts the sites, where the data lives, who owns the domain names and what happens when the contract ends. Settling this early avoids friction later.

When to keep a client on their current CMS

A highly bespoke site, an online shop built on a dedicated plugin ecosystem, or a client whose in-house team already knows its tool well: in these cases, migrating may cost more than it returns. Multisite suits brochure and editorial sites that you maintain yourselves.

In short

A multisite CMS lets an agency share maintenance while keeping sites distinct. The essentials are role-based separation, reusable layouts, a clear draft workflow and proven reversibility. To see how Plumixia fits your client portfolio, read the agencies use case or get in touch to discuss it.

Frequently asked questions