If you run a franchise, dealer, or brokerage network and each location needs a real web presence, you will eventually face an architecture decision: dozens of separate WordPress installs, a proprietary platform that hosts everything for you, or one WordPress Multisite network. We build on Multisite, so you can guess where we land — but you should hear the case against it from us before you hear the case for it from anyone. A vendor who can't tell you where their architecture struggles hasn't deployed it enough.
What Multisite actually is
WordPress Multisite is a core WordPress feature — not a plugin, not a service — that runs many sites from one installation. Each site in the network is a full WordPress site: its own pages, its own admin users, its own subdomain or subdirectory (or its own mapped domain, like cincinnati.yourbrand.com or yourbrand.com/cincinnati). What they share is the underlying installation: one codebase, one plugin set, one place to update everything.
For a franchise network, the shape maps naturally: the main site is corporate's; each location gets a sitelet in the network; the network admin sees and manages all of it.
Where it genuinely fits
One update, every location. Core, theme, and plugin updates happen once, at the network level. Fifty separate installs means fifty maintenance schedules and, in practice, fifty different versions of everything within a year. One network means one truth.
New locations in hours, not projects. Adding a site to an existing network is an administrative act, not a build. For a network that opens locations regularly, this is the difference between web presence being part of onboarding and being a backlog item.
Real sites, not landing pages. Because every sitelet is a full WordPress site, each location gets everything a standalone site has — its own pages, its own metadata, its own sitemap. Your SEO plugins (Yoast, Rank Math) run natively at every location, per-location titles and schema included. That matters more every year: local search rewards genuinely local pages, and a paragraph on a store-locator page isn't one.
One bill, one host, one vendor surface. Consolidated hosting is cheaper than fifty small plans, and — less obviously — it's one security perimeter, one backup regime, one SSL story, instead of fifty of each administered by nobody in particular.
Where it genuinely doesn't
Setup is technical. Standing up a Multisite network — domain mapping, server configuration, network-level settings — is real WordPress work. It's well-trodden work, and it's done once, but a network without in-house WordPress competence should budget for help rather than improvise. (This is exactly why our Growth tier includes onboarding hours, and why every plan here starts with a guided setup call — but the point stands regardless of vendor.)
Shared infrastructure means shared fate. All sites share server resources. A traffic spike or a badly behaved plugin affects the whole network. Decent hosting and plugin discipline manage this in practice, but it's a structural truth: one install means one point of failure as well as one point of control.
Network rules bind everyone. Plugins and themes are installed at the network level. A location can't bolt on its own page builder or random plugin — which is usually exactly what a franchisor wants, but call it what it is: a constraint. If your model requires locations to run genuinely independent technology stacks, Multisite is fighting your model.
Extracting one site takes work. Moving a single location out of a network to a standalone install is a documented, standard-tools process — export, import, re-point the domain — but it's more involved than moving a standalone site. Worth knowing before you commit, and worth asking any platform vendor the harder version of the question: can we leave at all? On standard WordPress the answer is yes with effort. On proprietary platforms the answer is often no — the site was never yours.
Notice which drawbacks are architecture and which are governance. Multisite gives you the structure — shared install, per-location sites, central admin. It does not, by itself, decide who may edit what on those sites. That's a policy problem, and it needs its own answer: see Who Should Be Allowed to Edit a Franchise Location's Website?
The fit test
Twenty-five years and 60,000+ localized sites in, the pattern is consistent. Multisite is the right call when most of these are true:
- You operate roughly 4 to a few hundred locations under one brand (below 4, location pages on your main site are usually enough; the architecture earns its keep as the count grows).
- Corporate needs real control — brand, messaging, structure — not just a shared logo.
- Locations need real sites: their own pages, local content, local search presence.
- You have, or will hire, WordPress competence — in-house, agency, or vendor-provided.
- You want to own the infrastructure: your hosting, your data, your exit rights.
And it's the wrong call when the inverse holds: a handful of locations with thin local needs, sub-brands that genuinely require independent technology, or an organization that wants a fully hosted service and accepts the ownership trade that comes with it.
Where we come in — stated plainly
Sitelets is a plugin that adds the governance layer Multisite lacks: element-level content locking, brand and style locks, network publishing, cloning, and media governance — on your Multisite install, alongside your Elementor. We didn't replace the architecture; we made it governable. If the fit test above reads like your network, the architecture question is settled and the remaining question is policy and tooling.
Run your network through the fit test with us
Book a 30-minute discovery call. We'll assess your location count, current setup, and governance needs against the architecture honestly — including telling you if Multisite isn't your answer.
Book a Discovery Call Published pricing · No long-term contracts