Shared cPanel clients: the four kinds and what they need

An agency lead in Rotterdam sent a Loom at 23:41 last Tuesday. The thumbnail showed a cPanel File Manager open on public_html, four nested WordPress installs sitting inside /old, /old2, /staging and /staging-final, and a Post-it on the corner of the desk that read 'do not touch'. The client had inherited the hosting from the previous web guy, who had inherited it from the agency before that. Everyone wanted out. Nobody wanted to be the person who took the site down on a Friday.

If you still do client work in 2026 you keep meeting these accounts. Not weekly, but often enough that a mental map saves an hour each time. There are roughly four kinds of clients living on shared cPanel right now, and once you can spot which one is on the other end of the email, the rest of the conversation gets shorter.

The corner-shop brochure site

Five pages, a contact form, a Google Map embed, and a footer that still reads '© 2018'. Built by someone's cousin who learned WordPress from a YouTube series. It loads in two seconds, ranks on the owner's name, and converts maybe one enquiry a week. Revenue from the website is real but not measured.

What this client thinks they need: a rebuild on Next.js, because the agency at the Rotary lunch told them WordPress is 'out'.

What they actually need: the brittle contact-form plugin replaced before the host force-upgrades to PHP 8.3 and breaks mail() in a way nobody will notice for six weeks. The rest of the legacy site is fine. PHP's own support calendar already lists 8.1 as out of security fixes; the host will move them when the host wants to, not when they do.

The right work is two hours. Swap the abandoned form plugin for something maintained, set up an SMTP plugin so mail actually leaves the building, and tell the owner the cookie banner is now a legal requirement, not a styling choice.

The WooCommerce shop that pays the rent

Annual revenue between forty and three hundred thousand euros, almost all of it through a WooCommerce install on a twenty-euro shared plan. PHP is pinned to 8.0 because the payment-gateway plugin breaks above that. The orders table has eighty thousand rows in it. wp_options is forty megabytes, mostly expired transients nobody has cleaned up.

What this client thinks they need: a migration to Shopify, because their accountant's nephew said so.

What they actually need: a pre-flight on what they already have. Which plugins are abandoned. Which custom function in functions.php is the reason a 'simple' upgrade keeps failing. Whether the gateway plugin has a successor or whether they are about to be stranded the next time the host force-upgrades PHP.

The first useful query takes thirty seconds and tells you most of what you need to know about the database:

SELECT option_name, LENGTH(option_value)/1024 AS kb
FROM wp_options
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

If the top row is a serialized blob from a plugin the client uninstalled two years ago, you have found your afternoon. The Magento 1 EOL wave taught everyone the same lesson: a quiet store on an old stack can run for years, right up until the host or the gateway forces a move on a timeline that is not yours.

The reseller plan with twenty mystery sites

A one-person studio you have known for a decade runs a reseller account at one of the bigger European hosts. Twenty cPanel accounts under it. Eight are live and billing fifteen euros a month. Six are abandoned but still serving. Four are staging copies of the same Drupal 7 site from 2017. Two are something nobody at the studio can identify.

What the studio owner thinks they need: a junior to take over hosting admin so they can finally take a holiday.

What they actually need: an inventory. PHP version, CMS version, last login, last file mtime, last backup. A spreadsheet, not a refactor. On most cPanel hosts the per-site PHP version is written into .htaccess by MultiPHP Manager, which means you can produce the first column over SSH in one pass:

for d in /home*/*/public_html; do
  ver=$(grep -hoE 'ea-php[0-9]+' "$d/.htaccess" 2>/dev/null | head -1)
  echo "$d => ${ver:-host-default}"
done

Half the accounts will be turned off once the owner sees the list. The other half become a small, billable maintenance line.

The inherited portfolio with no handover

The agency bought another agency, or the lead developer quit and took their head with them. Thirty to eighty cPanel accounts now sit in a folder labelled 'old client hosting' that nobody opens. Each site has a slightly different ACF version, a slightly different theme parent, a slightly different SMTP plugin, and a wp-config.php that almost works.

What the new owners think they need: to migrate everything to a 'modern stack' before the quarter ends.

What they actually need: triage and a kill list. Which sites still bill. Which sites the original client still believes they have. Which ones run a WordPress core version old enough to be a security incident waiting to happen. Then, and only then, a migration plan for the third of the portfolio that is worth the effort.

The pattern across all four kinds is the same. The client does not need a rebuild. They need someone who can open the existing stack, see what is actually there, change three small things, and leave a clear trail of what changed and why.

The common baseline

Read-only access first, then narrow write access. A working .htaccess that does not 500 the site when you save it. A way to edit a row in wp_options without relearning phpMyAdmin's quirks every six months. Version history on every text change, because the moment something breaks on a Friday the only question that matters is which line moved.

When we built Pier for this kind of work, we kept coming back to the MySQL editor. Most of the real damage on shared cPanel accounts is one careless update on wp_options or a serialized option that nobody can roll back, and versioning that with a one-keystroke undo turned out to be more useful than anything cleverer we tried.

The smallest thing to do today: open the oldest cPanel account in your portfolio and write down two numbers. The PHP version it runs. The WordPress or Drupal or Joomla core version it runs. That is the start of the audit you have been postponing since January.