Open the plugin list on five client sites built by the same agency over the years and you can usually date each one. The early sites use one form plugin, the middle years another, the most recent a third. One site has two SEO plugins because nobody removed the old one. Another runs a slider from a developer who stopped updating it. Every one of those choices made sense on the day, and together they turn routine maintenance into detective work.
A standard stack fixes that. It is a short, written list of the plugins, themes and settings your agency uses by default, with a reason for each and a process for exceptions. This post covers how to choose one, how to write it down, and how to bring older sites into line without breaking them.
What standardising actually buys you
The benefit is not tidiness for its own sake. It is that knowledge transfers between sites.
- Updates get safer. When the same plugin runs on many of your sites, you learn how it behaves after updates. A problem caught on one site warns you about the rest.
- Anyone can pick up a ticket. A developer who has never touched a particular client site still knows where the forms are configured and how caching is set up.
- Licences are easier to track. Fewer premium products means fewer renewals, fewer keys and fewer surprises. The sibling post on tracking premium plugin and theme licences across clients covers the admin side.
- Security exposure shrinks. Fewer distinct plugins across the portfolio means fewer vulnerability announcements to check against your sites.
- Quoting gets more accurate. When you know the tools, you know how long common tasks take on them.
Decide the categories before the products
Start with the jobs that nearly every client site needs done, and choose one default for each. A typical list:
- Theme or theme framework, and whether you build with the block editor or a page builder
- Forms
- SEO metadata and sitemaps
- Caching and performance
- Backups
- Security and login protection, including two-factor authentication
- Transactional email delivery (SMTP or an email service connector)
- Analytics or tag management
- Redirects
- Image optimisation
- Store, if the site sells, plus its payment gateway connector
Some categories may not need a plugin at all. The host may handle caching or backups, or WordPress core may already do enough. A deliberate “none, because the host covers it” is a valid entry, as long as you write down which host feature you rely on.
How to judge a plugin for the stack
For each category, compare a few candidates against the same questions. You will not get perfect answers for all of them, but writing the answers down is the point.
Maintenance signals
On the plugin’s page in the WordPress.org plugin directory you can see when it was last updated, roughly how many sites run it, which WordPress version it was last tested with and how the support forum is handled. A plugin that has gone a long time without an update, or whose support threads go unanswered, is a poor choice for a default, however good its features. For commercial plugins sold elsewhere, look for a public changelog and a clear support route.
Scope
Prefer plugins that do one job well over plugins that try to do ten. A plugin that bundles forms, sliders, SEO and security looks economical, but it means one update can break four things, and you cannot replace one part without replacing all of them.
Exit cost
Ask what happens if you need to remove it. Does it store content in shortcodes or its own blocks that turn into clutter when it is deactivated? Does it create database tables it never cleans up? A plugin that is easy to leave is a safer default than one that locks content in.
Licensing
Check whether the licence allows use on client sites, who should hold the licence (agency or client), and what happens to updates if the licence lapses. Never put nulled copies on client sites; our post on why nulled plugins carry malware explains why this is not a shortcut worth taking.
Performance and conflicts
Install the candidate on a test site with the rest of your proposed stack and look for clashes: duplicate features, scripts loaded on every page, admin slowness. It is much cheaper to find a conflict at this stage than on a client’s live site.
Do not forget the theme
Agencies often standardise plugins and leave the theme to each designer’s taste. The theme matters at least as much. A heavily customised commercial theme with its own bundled plugins, template overrides and options panel ties every site to that vendor’s update schedule. Pick one base you know well, whether that is a lightweight parent theme with child themes per client or a block theme you extend, and build on it every time. Keep client-specific code in a child theme or a small site plugin, never in the parent, so updates do not wipe it out.
Write the stack down
A stack that lives in one developer’s head is not a standard. Keep a single document, shared with everyone who builds or maintains sites for you, including any outside partner. For each entry record:
- Category and chosen plugin or theme
- Why it was chosen, in one or two lines
- Free or premium, and who holds the licence
- Default settings you always apply (and any you never change)
- Known quirks, such as “clear its cache after editing menus”
- The fallback if it ever has to be replaced
- Date the entry was last reviewed
Add a short “never install” list as well. It might include plugins with a poor security history, tools that duplicate something in the stack, or anything that edits files on the server in ways you cannot track. Saying no in writing is easier than saying no to a client in the moment.
Handle exceptions on purpose
Clients will need things outside the stack: a booking system, a membership plugin, a specific integration with their CRM. That is normal. What matters is that exceptions are chosen with the same care as the defaults and recorded.
A simple rule works well: any plugin outside the stack needs a one-line reason in the client’s site notes and a named person who approved it. When someone asks a year later why that plugin is there, the answer exists. This kind of record belongs in the per-site runbooks discussed in our post on documenting every client site.
Bringing older sites into line
The stack is easy to apply to new builds. Older sites are where it takes patience. Rushing a migration from one form plugin to another across twenty sites is a reliable way to lose enquiries.
- Inventory first. List every plugin on every site, with version and whether it is active. Inactive plugins still need updating or removing.
- Remove the obvious. Inactive plugins, duplicates and anything abandoned by its developer. Our post on dealing with an abandoned WordPress plugin covers how to tell and what to replace it with.
- Swap when the site is already open. The best time to replace a non-standard plugin is during work the client is already paying for, such as a redesign, a PHP upgrade or a big content change, when you will be testing everything anyway.
- Do it on staging. Replace, test the features the plugin provided, check that the old data migrated or was rebuilt, and only then deploy.
- Tell the client what changed. If their team logs in to edit forms, they need to know the screen looks different now.
Some sites will never be fully standard, and that is fine. A site that is mostly on the stack, with two documented exceptions, is far easier to look after than one with no pattern at all.
Review the stack on a schedule
A stack is not something you choose once. Plugins change hands, get bought by companies with different priorities, add features you do not want or stop being maintained. Put a review in the calendar a few times a year. For each entry, ask: is it still maintained, have there been security issues, has a better option appeared, are we still happy with support? Record the outcome even when nothing changes.
When an entry does change, decide whether the new default applies only to new sites, or whether existing sites should move too. Usually the first, unless there is a security reason.
Sharing the stack with a partner
If outside developers build or maintain sites for you, the stack is one of the most useful documents you can give them. It tells them what to install, what not to install and what to ask about. Ask partners to follow it on new builds and to flag, rather than quietly replace, anything they find on an older site that is not on the list. The broader setup for working with an outside team is laid out in our guide to outsourcing WordPress work for agencies.
A starting checklist
- List the categories every client site needs.
- Choose one default per category, with written reasons.
- Record licences, default settings, quirks and fallbacks.
- Keep a “never install” list.
- Require a reason and an approver for every exception.
- Inventory existing sites and remove dead weight first.
- Replace non-standard plugins during other planned work, on staging.
- Review the whole stack a few times a year.
Once the stack exists, updates are where it pays off most. If you want those updates tested and applied across your client sites by someone else, our page on white label WordPress updates explains how we run them for agencies.
Next in this series: Client Site Documentation: A Runbook for Every Site
