Ten WordPress sites is not ten times the work of one, and it becomes so if each is managed as an individual. The difference is entirely in whether you standardised anything.
This is what to standardise, and what to leave alone.
Separate accounts, not one account with addon domains
The structural decision, and the expensive one to change later.
Sites sharing a cPanel account share a filesystem. One compromised site can reach its neighbours, and a single compromise becomes several. They also share the account's resource limits, so one busy site slows the others.
Separate accounts contain both problems. They also mean a site can be handed to its owner, moved, or terminated without touching anything else, which is the property you notice when a client leaves. Addon domains and duplicate content explains the other reason to avoid them.
Standardise the stack, not the design
Pick one caching approach, one backup method, one security plugin, one SMTP arrangement, and use them everywhere.
The gain is not tidiness. It is that a problem solved once is solved everywhere, and that you can answer "how do backups work on this site" without opening it.
Leave the design and content per site. Standardising those is a constraint on the work; standardising the infrastructure is a constraint on the chaos.
Keep an inventory
One document listing every site, and it is the single highest-value thing on this list.
Per site: the domain and where it is registered, the hosting account, who owns it, the PHP version, non-standard plugins and why, where backups go, and when it was last updated.
The reason is specific. When a vulnerability is disclosed in a plugin, the question "which of my sites run it" is a search instead of an audit, and the difference is minutes against a day, at a moment when speed matters. Vetting plugins goes into reducing how often that happens.
Updates need a policy, not a habit
Across a portfolio, "update when I remember" means some sites are current and others are two years behind, and you cannot say which.
A workable arrangement: automatic minor and security updates everywhere, major updates applied deliberately on a schedule, and one site updated first as a canary before the rest.
Enable automatic backups before automatic updates, so a bad update is a restore instead of an incident. Enabling automatic updates deals with the trade.
Backups: verify one, not all
Backups running is not the same as backups working, and checking every site every month is not sustainable.
Restore one site per month, rotating through the portfolio. Over a year every site has been proven, and each check is an hour in place of a project.
What that finds is the failure common to all of them. A job that stopped silently, an exclusion nobody noticed, a database too large to complete, and finding it on one site fixes it everywhere. Restoring from backup walks through doing it deliberately.
Monitor from outside, alert to one place
Uptime monitoring per site, certificate expiry per domain, domain expiry per registration.
All alerting to one destination that you actually watch, and not to an inbox on any of the servers being monitored. Uptime monitoring explains making the alert arrive.
The value of doing this centrally is that silence means everything is fine, rather than meaning you have not checked.
One admin account per person, per site
Not a shared login used across the portfolio.
A shared administrator account means a compromise anywhere is a compromise everywhere, and a person leaving requires changing credentials on every site at once, which is exactly the moment it does not get done properly.
Individual accounts also mean the audit trail says who did what, which matters when something changed and nobody remembers doing it. There is more on the same principle at the hosting level in securing your hosting account.
Staging: one arrangement, used every time
Pick a staging method and apply it consistently, rather than testing on live for the small sites because they are small.
The site where an untested update breaks something is not predictable, and the client whose site broke does not care that it was the low-maintenance one. Setting up a staging site walks through making one.
Decide what you actually maintain
The commercial half, and the one that causes disputes.
For each site, is somebody paying for maintenance? If not, updates are not happening, and that should be a stated position instead of a drift; a site nobody maintains is compromised eventually, and the owner will believe you were looking after it.
Write it down per site, and tell the owner which category they are in. That conversation is straightforward now and difficult after a compromise.
Review the list twice a year
Open the inventory and check each row is still true.
Sites that were retired but are still hosted. Domains renewing for projects that ended. Plugins nobody needs. Admin accounts for people who left.
An hour, twice a year, and it is what stops a portfolio becoming a collection of things nobody can account for.
Check them all with one command
The point at which a portfolio becomes unmanageable is the point at which you stop being able to ask every site the same question.
for d in site1.example site2.example site3.example; do
printf '%-22s %s\n' "$d" "$(curl -s -o /dev/null -w '%{http_code} %{time_starttransfer}' "https://$d/")"
done
Keep the list in a file rather than in your head, and run this weekly. It takes seconds and it finds the site that has been returning an error for a fortnight because nobody visits it.
Where the sites share a management tool, the same discipline applies to versions: one query listing what every site is running turns a vague plan to update into a specific list of which ones are behind.
Write down which sites you are responsible for
The most common failure in a portfolio is not technical. It is a site nobody was quite sure they were looking after.
Record, per site: who owns it, what you actually do for it, where the backups go, when the hosting and domain renew, and who to contact when something breaks.
The middle field is the important one. A client who believes you maintain their site, when you built it and left, is a dispute waiting for the first incident. Stating it in writing costs a sentence and settles it before it matters. What to include in your hosting terms covers the document.