How to manage multiple WordPress sites
Last updated
Looking after one WordPress site is a few minutes a week. Looking after twenty is a job: twenty sets of plugins to update, twenty backups to check, twenty places something can quietly break. The work does not grow in a straight line, because every site has its own host, theme, plugins and client expectations.
This guide covers how to choose the right approach for running many sites, and the routines that keep them healthy once you have chosen. It is written for freelancers, agencies and in-house teams, and it applies whichever tools you use.
Three ways to manage many sites
Before you pick tools, decide which of three approaches fits your sites. They solve different problems, and mixing them up is the most common reason people end up with a setup that does not scale.
WordPress Multisite
Multisite is a feature built into WordPress that runs many sites from one installation, sharing one set of plugin and theme files and one database. It suits networks of related sites owned by one organisation: a university’s department sites, a franchise’s location sites, a publisher’s brands. One update covers every site, and a network administrator controls which plugins each site can use.
It does not suit client work. Every site shares the same codebase, so one client cannot have a plugin another does not want; one bad update or one compromised site affects the whole network; and moving a single site out later is a migration project. If your sites belong to different clients, Multisite is almost never the answer.
A management dashboard
A management dashboard keeps every site as its own independent WordPress installation, on whatever host it already uses, and connects to each through a plugin. From one screen you run updates, backups, monitoring and security checks across all of them. This is the usual answer for agencies and freelancers, because each client keeps their own site and host while you get one place to work.
Your host’s tools
Many hosts give you a dashboard for the sites on their servers, with backups, staging and sometimes updates. That works well while every site lives with one host. It stops working the day a client insists on their own host, and most agencies end up with sites spread across several.
| Multisite | Management dashboard | Host tools | |
|---|---|---|---|
| Sites owned by | One organisation | Many clients | Anyone, on one host |
| Different plugins per site | Limited | Yes | Yes |
| One failure affects others | Yes | No | No |
| Works across hosts | No | Yes | No |
| Client reporting | No | Usually | Rarely |
| Moving one site out | Hard | Easy | Depends on host |
The rest of this guide assumes independent sites, managed from one place, which is how most people running many WordPress sites work.
Start with an inventory
You cannot look after sites you have not listed. Before changing anything, write down for every site:
- The client or owner, and who to contact when it breaks.
- The host, the PHP version and where DNS is managed.
- The theme, whether it is a child theme, and whether anyone has edited theme files directly.
- Every plugin, its version, and whether it is a premium plugin with a licence that needs renewing.
- Where backups go today, and when one was last restored successfully.
- What the client pays for: updates only, or monitoring, reports and fixes too.
A management dashboard builds most of this list for you once each site is connected, and keeps it current. The parts it cannot know, such as who the client contact is and what they pay for, are worth recording next to each site so anyone on the team can act without asking around.
Standardise what you can
Every difference between sites is something to remember. You will not make twenty sites identical, but you can reduce the variety:
- Pick a default set of plugins for common jobs (forms, SEO, caching) and use it on new builds.
- Keep custom code in a child theme or a small site plugin, never in a parent theme or a plugin you did not write, so updates do not wipe it.
- Remove plugins that are deactivated and not coming back. Inactive code still needs updating and can still be exploited.
- Agree one way to name sites, environments and clients, so a list of fifty sites is still readable.
Fewer distinct plugins across your sites means fewer changelogs to read and fewer surprises when an update lands.
Update without breaking things
Updates are where most multi-site trouble starts. Skipping them leaves known vulnerabilities open; applying them blindly breaks sites. The answer is a routine:
- Take a backup or snapshot immediately before updating, so there is something recent to roll back to.
- Apply security releases quickly, within a day or two. Batch ordinary updates weekly, and treat major versions of WordPress, page builders and WooCommerce with more care.
- For risky updates, try them on a staging copy first.
- After updating, check the site: does the home page load, are there PHP errors, does the main form or checkout still work?
- If something broke, roll back first and investigate second. A working site on an older version is better than a broken one on the newest.
Doing this by hand across many sites is where the hours go. A good tool takes the snapshot, runs the update, checks the site afterwards and rolls back automatically when the check fails, so you only spend time on the updates that actually went wrong. See how MaintainHQ handles safe updates.
Backups you have actually restored
A backup is only proven when you have restored it. For every site, know:
- How often it is backed up, and how many copies are kept. A busy shop needs more frequent backups than a brochure site.
- Where the copies are stored. At least one copy should live somewhere other than the server the site runs on.
- Whether you can restore one part (a single table or folder) without rolling back the whole site and losing today’s orders or form entries.
- When a restore was last tested.
Test a restore on a few sites every quarter, ideally onto a staging copy so the live site is not touched. More detail is in MaintainHQ backups.
Monitoring: hear about problems before clients do
With many sites, you will not notice a problem by visiting them. Set up checks that tell you:
- Uptime: is the site answering? Check every few minutes, and confirm a failure before alerting so one slow response does not wake you.
- Security: vulnerable plugin versions, changed core files, new administrator accounts and repeated failed logins.
- Performance: page speed and Core Web Vitals over time, so a slow plugin shows up as a trend rather than a complaint.
- Certificates and domains: expiring SSL certificates and domain renewals.
Route alerts to one place and agree who responds to them. Alerts that go to everyone tend to be read by no one.
Access: stop sharing passwords
Shared administrator passwords are the weak point of many agencies. When someone leaves, every password they knew has to change on every site. Instead:
- Give each person their own account, with only the access their role needs.
- Turn on two-factor authentication for every administrator account.
- Use a management tool where team members have roles and can be limited to the sites they work on, so nobody needs the WordPress admin password to do routine work.
- Review who has access every few months and remove people who no longer need it.
If you are evaluating tools, ask exactly what the connector plugin on each site can do and how its keys are stored. Our answers are on the security page.
Report the work to clients
Clients pay for maintenance they cannot see. A short regular report turns invisible work into something they value: updates applied, backups taken, uptime for the month, threats blocked and anything fixed. Send it on a schedule, keep it readable for a non-technical owner, and put your own brand on it.
A read-only portal or status page also helps, because clients can check for themselves instead of emailing you. See client reports and the client portal.
When a site breaks
Across enough sites, something breaks every week. A consistent process saves the most time:
- Confirm the problem and its scope: one page, the whole site, or the admin only.
- Check what changed recently: updates, new plugins, hosting changes or edits.
- Read the PHP error log before guessing. Most white screens and 500 errors name the file at fault.
- Fix on staging where you can, and take a backup before touching production.
- Write down what happened and what you changed, for the client and for next time.
This is the work that eats care plan margin. MaintainHQ’s AI engineer, Gus, does the first four steps: it reads the logs, finds the cause and prepares a fix, then waits for your approval and rolls back automatically if the site gets worse. See how Gus works.
Doing all of this with MaintainHQ
MaintainHQ is a management dashboard of the second kind above: each site stays on its own host and connects with a plugin. From one place you get safe updates with automatic rollback, scheduled backups, uptime checks every 5 minutes, security checks, team roles limited to chosen sites, client reports, a client portal and status pages, and Gus to diagnose and fix problems with your approval.
Plans are flat: Starter is $2.99 a month for 1 site, Starter Plus $29 for 5, Pro $79 for 25 and Agency $199 for unlimited sites, each with a 7-day trial. See pricing, all features, or how MaintainHQ compares with the best WordPress maintenance tools and ManageWP alternatives.