Short answer
Website maintenance is the ongoing work of keeping a site functional, supported and recoverable. Responsibility can be split between a host, developer and business owner. The important part is an explicit agreement covering updates, verification, recovery and support deadlines, not merely “someone looks after the site.”
One website, several maintenance jobs
A WordPress site can have separate updates for core software, themes, plugins, PHP, its database and an operating system such as Ubuntu.
A host might maintain the operating system but leave the application to you. A developer might update plugins but have no access to change PHP. A business owner may approve neither because nobody told them approval was needed.
There is the gap. Everyone has completed their part, and the website is still unpatched.
Ask for responsibilities, not labels
“Managed hosting” and “maintenance plan” are starting points for a conversation. Confirm what the agreement actually includes:
- Inventory: Which sites, subdomains, integrations and environments are covered?
- Monitoring: Who reviews advisories and support deadlines?
- Authority: Who can approve an urgent patch if the usual contact is unavailable?
- Deployment: Who applies application, runtime and system updates?
- Verification: Who tests forms, checkout and background work?
- Recovery: Who restores a failed change, using which backups?
- Migration: Who budgets and schedules work before support ends?
Agree on response expectations rather than assuming every provider supplies round-the-clock incident response.
What “done” should look like
A useful handoff records the advisory or change, fixed package or release, affected environments, deployment time and verification results. For vendor-maintained packages, include the vendor revision, not just the upstream number.
A PHP update, for example, adds its own decisions: current patch level, target branch and extension compatibility. These records also make a future handoff easier: a partner or incoming developer can see what changed without reconstructing the server’s history from invoices.
Maintenance versus a rebuild
Security patching addresses a known problem. A migration changes a dependency or platform. A rebuild changes much more. They can overlap, but should not become interchangeable sales terms.
A critical PHP advisory does not, by itself, establish that a working WordPress site needs replacing. Patch what can be patched, identify genuine compatibility blockers and scope the remaining work. That is a technical recommendation someone can inspect, not a pitch based on a frightening headline.