Website maintenance and support after launch
Website maintenance covers four separate jobs that are often sold as one: keeping the software patched, keeping the site recoverable, keeping it working, and changing it when the business changes. Patching is the security floor — core, plugins, themes, server packages, applied on a schedule and tested before they reach production. Recoverability means backups that have been restored at least once, because a backup nobody has restored is a belief, not a backup. Keeping it working is monitoring plus the hours to act on what monitoring finds. And change — new pages, new forms, a price update, a section that has to move — is the part clients actually feel, and the part most often left undefined in the contract. A maintenance agreement that does not say how many hours of change are included, and what happens when they run out, will produce an argument in month three.
What does a maintenance plan actually include?
Ask for these seven lines by name. If a proposal is missing one, that is the line where the cost will reappear later.
- Updates: what gets updated, how often, and whether updates are tested on staging first.
- Backups: how often, where they are stored, how long they are kept, and — the line that matters — how often a restore is actually tested.
- Monitoring: uptime at minimum; ideally also error rates, certificate expiry, and form delivery.
- Security: vulnerability watch on the installed plugins, hardened logins, and a named procedure for when something is found.
- Response commitments: what counts as an emergency versus a routine request, and who decides.
- Included work: a number of hours or tasks per month, with an explicit rule for overflow.
- Ownership and exit: who holds the hosting, domain and repository, and what you receive if the agreement ends.
Point 7 is the one to settle first. It is trivial to agree at the start of a relationship and extremely awkward to agree at the end of one.
Why do WordPress sites break, and what prevents it?
Most breakage traces to one of four causes, all preventable by process rather than by skill:
- An update applied straight to production. A plugin update conflicts with a theme function and
the site errors on a live page. Prevented by staging plus a rollback path — not by delaying updates, which trades an availability risk for a security one.
- Updates deferred for months. The site keeps running until a known vulnerability in an outdated
plugin is exploited. The most common serious incident on WordPress, and the one that looks like nothing right up until it happens.
- PHP version drift at the host. The host upgrades PHP, an old plugin is incompatible, the site
breaks without anyone deploying anything.
- Certificates and domains expiring. Entirely mechanical, entirely preventable, and still a
recurring cause of a site being down for a day.
The pattern is that none of these are surprises. They are calendar events, and maintenance is mostly the discipline of treating them that way.
How do you know your backups actually work?
By restoring one. A backup is a claim until it has been used to bring a site back, and the failure modes are boring and common: the database is backed up but not the uploads directory, the backup is stored on the same server as the site, retention is short enough that a problem discovered on Monday predates the oldest copy, or the archive turns out to be unreadable.
The practical test is a restore to a staging environment on a schedule — quarterly is a reasonable floor for most sites. The check has an unambiguous outcome: the restored site either loads with current content, or it does not. Ask any maintenance provider when they last performed one, and for which site.
What is the difference between hosting and maintenance?
Hosting is the infrastructure: the server, the network, the platform's own uptime. Maintenance is your site running on it. A managed host may include server patching, platform-level backups and a firewall — none of which update your plugins, fix your broken form, or add your new page.
The gap between the two is where sites quietly rot. The site is "hosted somewhere good", so nobody is watching the application, and eighteen months later it is running an unsupported PHP version with a dozen outdated plugins. Worth writing down explicitly for each of the seven lines above: host, or maintenance provider, or nobody. "Nobody" is a legitimate answer as long as it was chosen.
How are maintenance agreements usually priced?
Three structures, each with a predictable failure mode:
- Fixed monthly fee with defined scope. Predictable for both sides. Fails when "small changes"
are undefined, because both sides remember the conversation differently.
- Retainer of hours. Flexible and honest. Fails when unused hours silently expire and nobody
says so up front.
- Ad hoc, pay per task. Cheapest per invoice and the most expensive over a year, because updates
and backups have no owner between tasks — so the incident, when it comes, is paid for at incident prices.
What decides the number is countable and can be established before talking to anyone: the number of plugins, whether the site has custom code, whether it takes payments or personal data, traffic, and how often the content actually changes. A brochure site with a dozen plugins and a quarterly text edit is a different agreement from a store with an integration and weekly promotions.
What should happen when something breaks at 2am?
The agreement should already answer three questions, in writing: what counts as an emergency, how it is reported, and what the provider is committed to doing. Vague reassurance here is the most expensive kind, because it is only tested on the worst day.
Two things distinguish a real arrangement from a stated intention. First, a named reporting channel that is monitored — not an inbox someone reads in the morning. Second, a rollback path that exists before the incident: a recent backup, a tested restore procedure, and a way to put the previous version back without rebuilding anything. Most emergencies are resolved by returning to a known good state and diagnosing afterwards; teams without that path debug live instead, which is slower and riskier.
Can maintenance be taken over from another agency?
Yes, and it starts with an audit rather than with the first invoice, because you are accepting responsibility for decisions you did not make. The handover list is short: access to hosting, domain registrar, DNS, the CMS admin, and the code repository; the current backup arrangement and the date of the last successful restore; the list of plugins with versions; any custom code and whether it is documented; and the current PHP and CMS versions.
Where documentation does not exist, it gets written during the first month — that is normal for an inherited site, and it should be scoped and priced as work rather than absorbed silently.
What do you need to get a proposal?
The site URL, the platform and version, the plugin list, where it is hosted, and an honest answer about how often content changes. Those five determine the scope; the rest is a conversation about how much change you want included.
Who does this: Toimi is a digital agency that maintains and supports WordPress sites after launch. We work in Russian and English and have been in business since 2017. Send the five details above and we will come back with scope, schedule and price.
Contact: info@toimi.pro