Multisite vs. Separate Installs: The Two-Person Marketing Agency’s Real Decision
This is not a “best WordPress architecture” ranking — those exist everywhere and answer the wrong question. This is a fit assessment: what actually works for your budget, timeline, and technical comfort.
If you’re running a two-person marketing agency, you’ve already felt the pressure. Client five becomes client twelve. Someone asks about white-label hosting. You’re updating plugins at 10 PM because three sites hit the same vulnerability the same week. The multisite question surfaces in every agency Facebook group, usually answered by someone running fifty sites who swears it “saves hours.” What they rarely mention is the single point of failure they’re accepting. You deserve a decision framework built for your actual situation, not theirs.
Step 1: Deconstruct Your Actual Situation
Before you touch any architecture decision, map these five variables honestly. Most two-person agencies skip this and chase the wrong problem for months.
| Variable | What to Ask Yourself |
|---|---|
| Client count growth trajectory | Are you at 5 sites and plateaued, or 8 sites with 3 more signed? |
| Dev vs. content split | Who pushes code, who publishes posts, and can either of you handle a database restore? |
| Hosting budget | Are you reselling hosting profitably, or are clients on their own cheap shared plans? |
| White-label requirements | Do clients know you host them, or does your brand need to disappear entirely? |
| Disaster-recovery bandwidth | If a site goes down at 7 PM Friday, who’s fixing it and how long until you sleep again? |
Be ruthless here. If your “dev person” is you with three YouTube tutorials and a prayer, that constraints every choice below. If your hosting budget is $50/month total, that constraints every choice below. There is no shame in this — there is only shame in pretending you’re a ten-person DevOps team when you’re not.
Step 2: Segment Into Real Sub-Decisions
The multisite vs. separate installs question is actually five sub-decisions wearing one mask. Most content skips straight to the first one and misses the others entirely.
Sub-decision 1: Multisite network vs. separate installs
This is the visible one. Multisite runs multiple sites from one WordPress core, one database (with table prefixes like wp_2_posts, wp_3_posts), and one super admin dashboard. Separate installs are fully independent WordPress instances, each with their own database, file system, and admin login.
Sub-decision 2: Shared hosting vs. reseller/VPS
Are you throwing clients on a single cheap shared plan, reselling through a white-label host, or running your own VPS? This determines whether you can even implement multisite securely, or whether you’re stacking risk on top of risk.
Sub-decision 3: Single builder license vs. per-site
Your page builder choice has licensing implications. Beaver Builder, for example, offers agency licenses that cover unlimited sites — but that license lives differently in multisite vs. separate installs. (Disclosure: I have an affiliate relationship with Beaver Builder; I will note when a recommendation favors them commercially.)
Sub-decision 4: Centralized update workflow vs. client-managed
Who updates plugins? If it’s you across twelve sites, you need automation. If clients self-manage, you need isolation so their negligence doesn’t burn you.
Sub-decision 5: Done-for-you maintenance vs. self-service handoff
Are you selling care plans at $100–$300/site/month, or are you handing sites off and hoping? This determines whether architecture choices pay for themselves or bleed you dry.
Step 3: Diagnose Your Actual Bottleneck
Here is where most agencies derail. They assume multisite is the hard choice, spend weeks debating it, and miss that their real pain is update coordination across scattered client logins. Or they fear separate-install overhead when their actual vulnerability is client isolation for security incidents.
The real bottlenecks, in order of how often I see them:
| Bottleneck | The Symptom | What You’re Actually Solving |
|---|---|---|
| Update coordination | You have 8+ sites with different plugin stacks, no automation, and you’re logging into each wp-admin weekly | You need a management dashboard (MainWP, ManageWP, WP Managify), not necessarily multisite |
| Security incident isolation | One client’s site gets malware and you panic about lateral movement | You need container isolation or separate installs, not multisite’s shared database |
| White-label hosting margin | You’re paying retail hosting and reselling at cost | You need a reseller program or VPS, not an architecture change |
| Deployment confidence | You edit live sites and hold your breath | You need version control and staging, not multisite |
| Disaster recovery | You don’t know where yesterday’s backup lives | You need backup automation with off-site storage, not a network dashboard |
According to WP Care Team’s 2024 analysis, 96% of all WordPress vulnerabilities discovered in 2024 were in plugins rather than WordPress core. This matters because multisite centralizes plugin management — one bad plugin update hits every subsite simultaneously. Your bottleneck might be update speed or update testing, not update location.
Pantheon’s security documentation notes that in multisite, “data isolation is logical rather than physical, meaning that one breach can compromise the entire network.” Security researcher Ben Ryan adds: “A single compromised subsite becomes a pivot point to shared databases, file systems, and user tables.” If your clients include anyone with compliance requirements — HIPAA-adjacent, financial services, even strict GDPR interpretations — this is not abstract risk. This is a contract-termination event.
Step 4: Prescribe a Specific Path
You need a prescription, not “it depends” left unresolved. Here are two specific paths with named trade-offs.
Path A: Multisite Network
Choose this if:
– You control all site content (no client logins publishing independently)
– Your sites share a unified plugin stack and theme base
– You need granular role control across a membership or publishing network
– Your clients do not require independent SSL certificates or compliance-grade data isolation
What you’re giving up: Physical data isolation. Shared database means shared fate. Per Pantheon’s analysis, logical isolation is not container isolation. If one subsite admin installs a vulnerable plugin or gets phished, the attacker has access to the network’s underlying infrastructure.
Multisite is wrong for you if: Your clients need independent SSL certificates with full domain validation, have compliance requirements requiring physical data separation, or expect to install their own plugins. The SSL limitation is real — while wildcard and multi-domain certificates exist, they introduce what SSL documentation calls “risk of single point of failure” where one certificate issue impacts all covered domains. DNS validation complexity increases with each additional domain, and some hosting control panels don’t permit the required validation methods.
Commercial note: WP Engine supports multisite on higher-tier plans. I have an affiliate relationship with WP Engine; their Startup plan at approximately $25/month (pricing as of 2026, verify current rates) does not include multisite support. You need at least Growth tier. This is not the highest-commission hosting recommendation available to me — I disclose that plainly.
Check WP Engine’s current hosting plans
Path B: Separate Installs with Centralized Management
Choose this if:
– Your client count is growing unpredictably
– Clients need independent hosting accounts, SSL certificates, or plugin autonomy
– You lack time to become a multisite network administrator
– You can invest in update automation tools
What you’re giving up: The fantasy of “one dashboard to rule them all.” You will have multiple logins. You will pay for management tooling. But you gain container-grade isolation and the ability to fire a client without database archaeology.
Separate installs are wrong for you if: You have no deployment pipeline or update automation and refuse to build one. Logging into twelve separate wp-admin panels to update the same plugin twelve times is not a workflow — it’s a slow-motion emergency. Without tools like MainWP (core free, agency add-ons with backup and white-label starting at approximately $147/year according to 2024 DEV Community analysis), ManageWP, or WP Managify, you will drown in overhead. Custom development for fixes when automation fails runs $50 to $250/hour per Freshy’s 2024 pricing data.
Commercial note: Beaver Builder offers agency licensing that covers unlimited sites. I have an affiliate relationship with Beaver Builder; their Standard license covers unlimited sites on your own domains. For separate installs, this is straightforward. For multisite, licensing lives at the network level — verify current terms, as they have shifted across versions.
Check Beaver Builder’s current pricing
The Prescription for Most Two-Person Agencies
After reviewing 200+ builds, my direct recommendation for the typical two-person marketing agency at 5–15 client sites:
Start with separate installs on a reseller or managed VPS host, plus a centralized management tool.
This is the path that matches most agencies’ actual technical comfort and disaster-recovery bandwidth. It costs more per month than multisite on shared hosting. It requires learning a management dashboard. But it eliminates the existential risk of one client’s negligence or one plugin vulnerability taking your entire revenue base offline simultaneously.
The trade-off you are accepting: higher recurring tooling costs and slightly more complex initial setup. The trade-off you are rejecting: the hidden cost of network-wide incidents that consume weeks of unbillable recovery time.
If you are genuinely running a content network — same owner, unified editorial control, no client autonomy — multisite is defensible. But rename it honestly: you are not a marketing agency managing client sites. You are a publisher with multiple verticals. The architecture fits that model, not the client-service model.
Final Protective Notes
On “saving hours”: Any vendor claiming multisite “saves hours” without disclosing the single point of failure is selling you risk dressed as efficiency. Hours saved on plugin updates are hours lost tenfold during incident response.
On compliance: No plugin, no hosting configuration, and no architecture choice guarantees ADA/WCAG compliance or exempts a small business from ADA Title III requirements. This is vendor overclaim I see constantly. Accessibility is an ongoing process, not a checkbox.
On affiliate relationships: I have disclosed my relationships with WP Engine and Beaver Builder at first mention. When I recommend tools without affiliate relationships — MainWP, ManageWP, container-based hosts like SpinupWP or GridPane — I do so because they fit the architecture, not because they pay me nothing. My incentive is your sustainable operation, not my single commission.
Your architecture decision is not a loyalty test. It is a risk allocation choice. Choose with your eyes open to what you’re accepting and what you’re protected against.
This post contains affiliate links. If you purchase through our links, we may earn a small commission at no extra cost to you.
