Client-Specific Configurations at Scale

Disclosure: This article may contain affiliate links, which means we may earn a commission if you make a purchase through our links. We remain committed to our independence

Every agency starts by building each client site the same way, then discovers within a year that Client A needs Gravity Forms and a custom SMTP relay, Client B needs WooCommerce with three payment gateways, and Client C insists on a specific caching config because their host flags aggressive plugins. The problem isn’t that clients have different needs — it’s keeping those differences from turning your standard build into 40 unrelated snowflake sites that nobody but the original developer can safely touch.

Separate your “always” stack from your “sometimes” stack

The fix starts with a hard split. Your always-stack is what every site gets regardless of client: a security plugin (Wordfence or Solid Security), a backup solution (UpdraftPlus or BlogVault), an SEO plugin (Rank Math is the common agency default now over Yoast, mainly for the free schema and redirect features), and your own white-labeled client-reporting plugin if you run one. This stack gets deployed via a must-use (mu-plugins) folder or a custom starter plugin so it can’t be accidentally deactivated by a client with admin access.

The sometimes-stack is everything client-specific: form builders, page builders beyond your default (Elementor vs. Bricks), booking systems, membership plugins, industry-specific schema. This is where configuration drift actually happens, and it’s where you need a system, not memory.

Use a config manifest per client, not tribal knowledge

The agencies that scale past 20-30 sites without chaos keep a per-client manifest — a simple Markdown or JSON file (stored in the client’s folder in your internal wiki, or as a custom post type in your own agency management site) listing: active plugins and why each was added, any child-theme customizations, any wp-config.php overrides (memory limits, debug settings, custom constants), DNS/CDN quirks, and hosting-specific notes (e.g., “Client is on GridPane, do not enable object cache page rule X, it conflicts with their membership plugin”). Without this, onboarding a new team member to maintain an existing client site means guessing why something was configured a certain way, which is how support tickets turn into half-day investigations.

Centralized management tools, compared

For actually applying and monitoring configuration across many sites, you need a multi-site dashboard. The three real options agencies use:

[AFFILIATE CTA: MainWP]

MainWP tends to win for agencies specifically because of its site-grouping model — you can bulk-update your always-stack across all sites in one click while still leaving sometimes-stack plugins untouched on a per-group basis. ManageWP is genuinely easier to onboard a junior team member onto, which matters if you’re not the only one touching client sites.

Where configuration drift actually bites you

The real risk isn’t the plugin list, it’s silent version drift. A client-specific plugin (say, a niche booking system with a small dev team) goes three versions behind because nobody wanted to risk breaking a client’s live booking flow with an untested update. Six months later it has an unpatched vulnerability and it’s the one site that gets flagged in a security scan. The practical fix: maintain a staging clone for any client site running non-standard plugins, and put those specific plugins on a manual-update-with-staging-test cadence rather than lumping them into your auto-update-everything policy for the always-stack.

wp-config and server-level overrides need their own record

Plugin lists get documented; wp-config.php edits and server-level rules (custom Nginx/Apache rules, PHP memory bumps, specific cron schedules) get forgotten because they’re invisible in the WordPress admin. If Client D’s site has define('WP_MEMORY_LIMIT', '512M'); because their import tool needs it, and you migrate them to a new host without carrying that constant over, the failure shows up as a vague white-screen ticket, not an obvious “missing config” error. Keep server-level overrides in the same per-client manifest, not just in the file itself.

The honest tradeoff

None of this is free — writing and maintaining manifests is real time that doesn’t get billed directly to a client. The payoff shows up later: when you lose a team member, when a client asks “why do we have this plugin,” or when you’re bidding on taking over someone else’s messy multi-site portfolio and need to actually understand what you’re inheriting before quoting a price. Agencies that skip this step usually pay for it once, expensively, during an emergency migration or a security incident on a site nobody remembers configuring.

Staging environments per client, not per agency

A shared staging server for the whole agency sounds efficient until two client projects need conflicting PHP versions or plugin combinations tested at the same time. Cloudways and WP Engine both include a one-click staging clone per site as part of their standard plans, which is the more realistic setup for client-specific work — you’re testing that specific client’s sometimes-stack against that specific client’s always-stack version, not a generic sandbox that may not reflect their actual environment. Push the staging-to-live workflow into your onboarding docs so every team member tests non-standard plugin updates the same way, rather than some testing live and some not.

A tagging convention that survives staff turnover

Beyond the manifest itself, tag every non-standard plugin inside the plugin’s own description field or a simple naming prefix (e.g., “[CLIENT-ONLY] Advanced Booking Calendar”) so it’s visually obvious in the plugins list which items are exceptions versus your always-stack. This single habit prevents the common mistake of a new hire assuming an unfamiliar plugin is dead weight and deactivating it during a routine cleanup, only to find out it was quietly running a client’s booking system.

FAQ

Should client-specific plugins be network-activated in a multisite setup?
No — network-activate only your always-stack. Client-specific plugins should be activated per-site so removing a client (or that plugin) doesn’t risk affecting others sharing the network.

How often should the config manifest be updated?
At minimum whenever a plugin is added/removed or a wp-config change is made — treat it like a changelog, updated at the moment of the change, not retroactively.

Is MainWP or ManageWP worth it for under 10 sites?
Marginal at that scale — most agencies find the real payoff starts around 15-20 sites, when manual per-site login checks start eating a meaningful chunk of a week.

Related reading: When Multisite Is the Wrong Choice · When to Fire a Client (Politely) · Backup Stack Across the Agency