What Managed WordPress Hosting Actually Manages

In January a small store moved onto a plan advertised as managed and stopped thinking about maintenance. The feature list mentioned WordPress updates, daily backups and expert support. In April the host retired an old PHP version. The checkout plugin had not been tested against the new one, and the order confirmation page began returning a fatal error. Support replied within the hour, confirmed the error, and explained that plugin compatibility was the store's responsibility. Every word of that was true. It was also the sentence the word "managed" had been bought to prevent.

There is no villain in that story. The host patched its platform, which is what its engineers own. The plugin was the store's, and so was the decision to keep it running years past its last release. The confusion was in the word: "managed" describes a boundary, and each provider draws that boundary somewhere slightly different while putting the same word on the invoice.

What follows is not a ranking of hosts. It is an account of what sits on each side of that boundary, the four questions that reveal where a provider has drawn it, and the arithmetic that decides whether the premium is worth paying.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the situations where managed hosting is the wrong purchase are set out below in as much detail as the situations where it is the right one.

The platform is genuinely included, and it is more than the phrase suggests

The honest core of managed hosting is the machine. Someone else owns the web server, the PHP build, the database version, certificate renewal, the cache in front of the site, and the patching of all of it. That work is invisible when it goes well, which is why buyers undervalue it.

A PHP minor version lands every few months, a library underneath needs replacing when a vulnerability is published, and a certificate has to renew before a browser refuses the site. On an unmanaged server those are the owner's problems at the moment they appear, which is usually a Friday. On a managed platform they are somebody's ticket queue.

Usually included alongside: backups held off the machine, a staging copy cloned in a click, an object cache, a filtering layer that drops the worst automated traffic, and a support queue whose first responder knows what wp-config.php is. The stricter platforms add a curated plugin list, drop-in files installed as mu-plugins, and no root access. That last item is the trade in one line: less control, in exchange for not being the person who repairs the database at midnight.

None of this requires a provider. A competent operator can do all of it. The question is whether they will, every month, for years, including the months when nothing appears broken. Platform maintenance is the easiest work to postpone because skipping it has no visible symptom, and the most expensive to skip, because the symptom is a site that will not load.

What stays yours no matter what the plan page says

Plugins, themes and your own code. The host patches the platform. The plugin inventory belongs to the site, and no host knows which of forty plugins are load-bearing. Managed plans apply core updates on a schedule of the provider's choosing. Almost none will accept responsibility for a plugin update that breaks checkout.

Content, DNS and email. A managed plan does not write the pages, does not know which records in the zone point at something else, and usually does not provide mailboxes. Email hurts during a move: if the company's mail lives on the host, migrating the site does not migrate the mailboxes, and the export becomes its own project.

The speed of your own queries. A meta query over an unindexed table stays slow at any price. Hosting raises the ceiling; nothing in the plan improves the code underneath, which is a reason not to buy it as a performance fix.

And the gap where the two sides meet. A platform change is applied on Tuesday, a plugin breaks on Wednesday, and the host's position is that both facts are true and only one of them is theirs. This is the ordinary shape of disappointment with managed hosting: a process gap rather than a product defect. It closes only from the site's side, with a staging copy, a test before the change goes live, and a rollback that takes minutes. Some of the maintenance the premium was meant to remove cannot be removed by anybody outside the site.

Four questions to ask before you pay

The sales page will not answer these. Ask in a pre-sales ticket and keep the reply, because the answers differ between tiers of the same provider.

Who applies core updates, and does anyone apply plugin updates?

Two questions wearing one coat, and conflating them is how the April failure gets built. Ask for the maintenance window, whether core updates are staged first, and what happens when a core update disagrees with a plugin. Then ask the second half plainly: if a plugin update breaks the site on a Saturday, whose ticket is it? Most providers will say it is the site's, which is fine as long as it is known before payment rather than after.

Who is on call at three in the morning?

Support is the feature that cannot be tested until it matters. Twenty-four seven may mean an engineer with server access, or a triage desk that can read a status page and open a ticket. Ask three things: what the response time is and whether it is a target or an obligation; whether the rotation covers the site being broken or only the platform; and whether the queue answers in the time zone the site operates in.

What happens to the site if it is hacked?

Policy rather than engineering, and the answers vary enough to change a purchase. Does the plan include malware cleanup, or is cleanup billed hourly? Does the host suspend the account first and ask afterwards? If it restores, how old is the restore point, and will it hand over access logs from the period, which are what a person needs to find the entry point? A restore that leaves the entry point in place produces a site re-infected a fortnight later, on a second ticket. A host that suspends first and explains later produces a shop that is offline during its best week. Neither policy is unreasonable. Both should be known in advance.

What does it cost to leave?

Migration in is the easy direction, which is why the marketing covers it. Ask about out. Will the host produce a complete archive on request, in a format the destination can restore, or a control-panel export and a page of instructions? How long after cancellation is the data kept? Is there a fee for assisted migration out? And is the plan prepaid for a year, because a twelve-month term is a twelve-month exit fee whether or not it is described as one. The expensive part is rarely the file transfer. It is the mailboxes, the DNS records pointed at the host, and the discovery that the only complete copy of the site is a snapshot in the host's own format.

What the premium actually buys

Strip the marketing and the price difference has one component: attention. A managed plan usually costs several times what an equivalent VPS costs to rent, and the multiple pays for somebody else's hours on the boring, recurring parts of the job. The free alternative is an unmanaged VPS the owner maintains, and it is enough for a site whose downtime costs nothing.

The comparison that matters is not the managed plan against a bare server, but against the bare server plus the hours. Do the arithmetic with your own numbers: an hour or two a month when nothing goes wrong, an afternoon when something does, and the possibility of a night spent on a restore. Multiply by what an hour of that person's time is worth. In a small company the figure is often larger than expected, because the person doing the work is also the person who would otherwise be selling something.

Pressable, the managed WordPress host Automattic owns, publishes its plan tiers and migration terms, which makes it a reasonable place to test these four questions against real numbers: the tier table says what each level includes rather than what the brand does. Check the current price on that page rather than trusting a figure from anywhere else, this piece included, because they change it.

The honest case for paying is narrower than the advertising suggests and stronger than the price suggests. The multiple is worth it when the site produces revenue, leads or reputation that would be missed within an hour of downtime, or when nobody reachable at three in the morning can tell a PHP fatal error from a DNS failure.

What the money does not buy is a site that maintains itself. It converts an unpredictable failure into a predictable invoice, which suits some operators and functions as a subscription to anxiety for others. The premium also does not scale with competence: a site stable on the same stack for two years keeps paying the same rate for a problem that has stopped happening, which is how insurance works and occasionally the point at which it is worth dropping.

When managed hosting is the wrong purchase

A site with no traffic. A five-page brochure with a couple of hundred visits a month, no store, and a contact form that forwards to one inbox does not need a support contract. The premium is not the problem; the ratio is. That site is buying insurance against an outage nobody would notice. The free version is genuinely enough: the cheapest reputable plan the owner will actually log into, a backup written somewhere else, and a monthly habit of applying updates on a staging copy first. The WordPress documentation on administration and security covers the update and backup half of that without selling anything.

A site that needs a stack the host will not allow. Managed platforms are standardised on purpose, and standardisation is what makes the support desk competent. The cost is that some requirements are a hard no: root access, a specific PHP extension, an older PHP version a legacy plugin needs, an encoded plugin, a long-running daemon, a Node service beside WordPress, custom web server rules, or a plugin on the platform's do-not-run list. Buying the plan anyway and meeting the limit during the migration is the expensive sequence. A VPS with a written runbook is the right purchase there, and the maintenance burden is the price of the requirement.

A developer who will maintain it anyway. If a competent person is on retainer, with hours that include updates and being reachable, the managed premium pays twice for the same attention. The better arrangement is unmanaged compute with object storage for backups, a documented runbook, and a retainer that states what happens at three in the morning. The condition is that the retainer is real. "I will look at it when something breaks" is not maintenance, it is a hope, and managed hosting exists because that hope fails at the worst moment.

The decision rule

Write the four answers down for the host in use and for the one being considered. If both sets are the same, moving buys nothing. If the current host will not answer them, that is the finding, and it is a better reason to move than any speed comparison.

Buy managed when the site earns money, or when the hours of the person who would otherwise maintain it cost more than the monthly difference. Do not buy it for a site with no traffic, for a stack the platform will not host, or when a competent maintainer is already on the account. In between, the tie breaks on one question: if the site were down for six hours on a weekday, what would that cost? If the answer is smaller than a year of the premium, the premium is a donation.

That is what the word is really asking. Not whether the host is good, but who is responsible at the moment the site breaks, and whether that answer is written down somewhere other than a features page.