Managing Multiple Websites as One Estate, Not Five Separate Problems

When one website quietly becomes five separate problems

A single website is one relationship: one host, one login set, one person who roughly knows how the whole thing fits together. Add a second site — a new outlet's page, a sister brand, a subsidiary company — and something changes that has nothing to do with the extra pages. There are now two hosting bills on two different renewal cycles, two sets of admin credentials, possibly two different developers or agencies, each making their own small decisions about plugins, themes and naming. By the fourth or fifth site, most businesses aren't managing "websites" any more. They're managing a portfolio of unrelated relationships that happen to share a logo, discovered piecemeal whenever a domain lapses or a form breaks and nobody quite remembers who built it.

The alternative is to manage that portfolio as one estate: a single body of infrastructure with shared standards, rather than a set of sites that each get solved from scratch. This doesn't reduce the underlying work — five sites still need five sets of updates, five certificates, five backups. What changes is where the decisions get made. Instead of re-deciding how backups are taken, who has admin access, and which plugins are allowed on every new site, you decide it once and apply it everywhere a new site joins.

Write the standard down once

Most of the inconsistency across a multi-site estate isn't caused by bad choices — it's caused by the same good choices being made independently, five different times, by five different people, none of whom saw what the others decided. One site ends up on a different CMS version, another has a plugin nobody else uses, a third has no security headers configured because whoever built it didn't think to ask.

A shared standard doesn't need to be a formal document with a cover page. It can be a single page that states: which CMS or platform versions are supported, which plugins or extensions are pre-approved, minimum PHP or Node version, required security headers, and a naming convention for environments and repositories. The value isn't in the content being clever — it's in every new site starting from the same baseline instead of a blank page, and every existing site being auditable against something concrete rather than "however it happens to be configured right now."

One deploy process, one backup process

Five sites each running their own ad hoc update-and-hope routine is five separate ways for something to go wrong, and five separate places to check when it does. An estate approach collapses that down to one documented process: how updates are tested and rolled out, how backups are scheduled and where they're stored, and how a restore is actually verified rather than assumed to work. It's a genuinely different question from whether a given site has backups — it's whether the same, known process produced them, so that when something breaks on site three, the person responding already knows exactly where to look, because it's the same place they'd look on site one.

The one document that should never go missing

The single most common failure in multi-site management isn't a hack or an outage — it's a domain renewal notice going to an email address nobody checks any more, for a domain nobody remembers registering. A central inventory across the whole estate — every domain, its registrar and renewal date, every hosting account, the DNS provider for each site, SSL certificate expiry (most are now auto-renewing via Let's Encrypt or similar, but not all), and the accounts tied to analytics, tag managers and other third-party services — turns "does anyone know if this domain is still ours" from a scramble into a lookup. It needs an owner and a review date, or it decays exactly as fast as anything else nobody's assigned to maintain.

Access that scales without becoming a liability

With one site, shared logins are a bad habit. With five, they're a real liability, because the same reused password or the same person with standing admin access on everything means one compromised credential is a compromised estate, not a compromised site. Consistent access control means named, individual accounts rather than a shared "admin" login passed around by email; access scoped to what a person actually needs on a given site rather than blanket admin everywhere by default; and offboarding treated as an estate-wide action — when someone leaves, their access needs checking against every site on the inventory, not just whichever one someone happens to remember they worked on.

What actually changes, cost-wise, as the estate grows

The economics of an estate don't scale the way people expect. Some things get cheaper per site: a shared process for updates and backups means the fifth site doesn't cost as much incremental attention as the first one did, because the routine is already built. Other things scale in a straight line no matter what you do — a domain renewal, a hosting bill, an SSL certificate are per-site costs, and five sites will always cost roughly five times what one does on that front, regardless of how well-organised the estate is.

Risk moves in the opposite direction from cost. A single site that goes down is one outage. A shared plugin, a shared host, or a shared set of credentials across an estate means a single failure can, in the worst case, touch every site at once — the same efficiency that makes an estate cheaper to run also concentrates the blast radius of anything that goes wrong with the shared parts. That trade-off is worth making deliberately, not by accident: standardise the parts where consistency reduces risk (backup process, access control, security baseline), and keep enough separation between sites — separate credentials, separate hosting accounts where it matters — that one compromised site doesn't automatically become five.

For a growing estate where change requests come in unpredictably across several sites at once, some providers price for that directly with an unlimited-request tier rather than scoping every change individually — JagaWeb's Unlimited plan (RM4,500/month) is one example of that structure, though it's worth checking exactly what's included per site before assuming it covers a whole portfolio rather than one.

Where to start

None of this needs solving in one sitting. A reasonable first step for most multi-site businesses is simply building the central inventory — what exists, who has access, when each renewal falls due — before touching process or standards at all. Once that exists, the rest becomes a series of smaller, less urgent decisions rather than one large one.

If ongoing care for a single site in the estate is the immediate need rather than a full portfolio overhaul, JagaWeb Care (RM450/month) covers routine monitoring and maintenance, and Care + Changes (RM1,500/month) adds a working budget of content and fix requests — one option among several, worth comparing against what an estate of this size actually needs before committing.