Managed WordPress Hosting vs Agency Maintenance: Who Does What?

Managed WordPress hosting is sold with reassuring words: updates, security, backups, support. Agency maintenance is sold with the same words. Owners therefore often assume that choosing either one means someone is looking after the whole website, and that choosing both means double protection. In practice, the two services cover different layers, and the gaps between those layers are where sites break.

WordPress's own security guidance puts the dividing line plainly. It says hosts are often responsible for the infrastructure on which a website sits, but not for the application you choose to install, and that when sites are hacked it is rarely attributed to the infrastructure and most often to the application itself. It also advises understanding where a host's responsibility ends and yours begins. This article turns that principle into a responsibility matrix you can use to compare a managed host, an agency maintenance plan and the combination of both.

We cite the WordPress handbook pages, the WordPress security and requirements pages, the WordPress releases page and the PHP project's support table, all opened in October 2026. Everything in the matrix columns about who should normally do what is our working practice, not a rule, and must be checked against the actual contracts you hold. If you want an agency view of your site, see our website maintenance service.

Think of a WordPress site as three layers, each with a different owner by default.

1. Infrastructure. The server, operating system, web server software, database engine, PHP runtime, network and physical hardware. This is the host's domain.
2. Application. WordPress core, the theme, plugins, configuration, user accounts and the database content. This is where most attacks land, and it is usually nobody's job unless someone is explicitly assigned.
3. Content and business logic. Pages, products, forms, integrations, redirects, tracking and legal texts. This belongs to the business, with an agency or in-house editor doing the work.

Managed WordPress hosts differ, but their strength is normally in the first layer and the edge of the second: they run a tuned server, may apply WordPress core updates and may offer backups and caching. The WordPress hardening guide lists qualities of a trusted host: it discusses your security concerns and the features it offers, provides the most recent stable versions of server software and provides reliable methods for backup and recovery. Those are infrastructure promises. None of them says the host will test your plugin update, rebuild a broken page or answer a customer complaint about a form.

An agency maintenance plan lives mainly in the second and third layers. It looks after plugin and theme updates, tests them, restores when something breaks, reviews users, and fixes things on the site. The best arrangements make the boundary explicit so each party knows what the other does.

This table shows a common split. For each task, check who is named in your contract. If the answer is "nobody" or "both", you have found a gap or an overlap.

Pay special attention to the plugin row. It is the most common gap and the most common source of incidents, because many hosts do not manage plugins and many owners assume they do.

The WordPress documentation describes four kinds of automatic background update: core, plugin, theme and translation files. For core, automatic updates for minor releases and translation files are on by default, and since WordPress 5.6 new installations also receive major core updates by default unless a version-control checkout is detected; existing installations keep the earlier behaviour unless changed. Plugin updates can be enabled per plugin from the Installed Plugins screen.

The WordPress security page adds a detail that affects planning: only the latest version of WordPress is officially supported, though the security team also backports fixes to older versions as a courtesy so that older sites receive critical fixes through auto-updates. The releases page likewise says only the most recent release in the current series is safe to use and actively maintained. In other words, staying current is not optional, and a site left alone for a year is running software the project no longer fully supports.

Who should do the work? Our suggestion is this. Let automatic updates handle minor core releases and translations, because that is the project's own default and its strongly discouraged exception is disabling them. For plugins and themes, choose per plugin: automate low-risk ones, and stage the ones that touch checkout, forms or layout. Whoever you choose, write down who checks the site after an update runs. A host that applies core updates automatically has not looked at your contact form afterwards; an agency that applies plugin updates weekly usually has.

The host controls which PHP and database versions are available. WordPress recommends hosts that support PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS, and it says WordPress also works with PHP 7.4 and above, though those versions are end of life and may expose a site to vulnerabilities. The PHP project's table shows security support for branch 8.2 ending on 31 December 2026, for 8.3 on 31 December 2027, for 8.4 on 31 December 2028 and for 8.5 on 31 December 2029.

This is a shared responsibility, and a classic point of friction. The host can switch the version, but if an old plugin or a custom theme fails on the newer PHP, someone has to fix or replace it. Ask both parties three questions. Which PHP version does the site run today? Who warns you before that branch loses security support? And who pays for the compatibility work? A managed host that forces a version upgrade on a fixed date, with no agency available to test, will break sites. An agency that tests but has no say over the server can only recommend.

The cleanest arrangement is a calendar entry shared by both: the date the current PHP branch loses security support, a test window six to eight weeks earlier on a staging copy, and an agreed switch date. The calendar is our recommendation; the dates come from the PHP project's table.

Hosts commonly offer backups, and agencies commonly offer them too. The mistake is treating one as a substitute for the other. The WordPress handbook says a typical site needs both files and database for a full restore, suggests weekly backups for smaller sites and daily for busy ones, and recommends keeping at least 3-5 recent copies in different places, such as the server, cloud storage and a local computer. Its hardening guide adds that a sound strategy could include regularly timed snapshots of the whole installation in a trusted location, with the example that if a compromise on 1 May is not noticed until 12 May, pre-compromise backups are what allow rebuilding.

The practical rule: a backup that lives only in the same hosting account as the site is one failure away from vanishing. Ask the host what its backups cover, how many days it keeps and how a restore is requested, and ask the agency to keep an independent copy elsewhere and to rehearse a restore. Two owners, two locations, one tested process.

Also clarify cost and speed. Some hosts include restores; others charge, or limit how many you can request. During an incident, a restore that takes a day to arrange is a different product from one that takes ten minutes.

Managed hosts typically advertise firewalls, malware scanning and DDoS protection. These are valuable and belong to the infrastructure layer. They do not remove the need for application care: removing unused plugins, reviewing administrator accounts, using strong passwords with two-step sign-in and keeping everything updated. The WordPress hardening guide frames security as risk reduction rather than risk elimination, and lists measures such as limiting access, containment and preparation, including backups and knowing the state of your installation at regular intervals.

The same guide stresses logs and monitoring: logs allow you to see what was done, and monitoring helps you react faster, find out what happened and recover when prevention is not enough. It also recommends monitoring files for changes, because an attack leaves traces. Ask each provider who reads the logs, how file changes are detected and who is alerted. A host will often see server-level anomalies; only someone who knows the site will notice a new administrator or an altered plugin file.

Finally, agree what happens in an incident. Who contacts whom, how quickly, who is authorised to restore, who talks to affected customers if data is involved, and who pays for investigation. A one-page incident note, agreed before anything goes wrong, is worth more than a feature list.

The right combination depends on how much the site matters and who on your side can act.

• Brochure site, low change, someone on your team can log in monthly. A good managed host plus clear internal habits may be enough: automatic core updates, plugin updates reviewed monthly, your own off-host backup copy. Be honest about who will actually do the monthly job.
• Lead-generation site where forms are the business. Host plus a light agency plan that monitors forms and applies plugin updates after testing. The cost of a silent form failure is higher than the plan.
• Shop, booking system or membership site. Host plus a full agency plan with staging, restore rehearsals, monitoring of checkout and written response times. The host handles servers; the agency owns the application layer.
• Site with bespoke theme or plugins. The agency that built it should be the maintainer, because nobody else knows it, and the host must allow the PHP versions the code needs.

Whichever you pick, put the matrix from section three into the contract or onboarding document, with a named person on each side. Ask each provider to state what they will not do. Clear exclusions are a sign of a mature provider.

If you would like us to review a hosting setup and propose a split of duties, contact us. Our WordPress development team can also take over sites built elsewhere, and pricing explains how simple sites are priced.

• Hardening WordPress (WordPress Advanced Administration Handbook)
• Security (WordPress.org)
• WordPress releases (WordPress.org)
• WordPress requirements
• Upgrading WordPress, including automatic background updates
• Backups (WordPress Advanced Administration Handbook)
• Manage plugins (WordPress documentation)
• PHP: Supported Versions