A WordPress maintenance contract should do more than list technical tasks. It should establish who operates a business-critical website, how changes are controlled, how incidents are handled and what evidence demonstrates that the service was delivered.
The objective is not perfect or permanently guaranteed security. A proactive care process reduces known risk, limits unmanaged operating periods and prepares detection, containment and recovery. It cannot eliminate unknown vulnerabilities, compromised credentials or failures in software, hosting and the wider infrastructure.
Many proposals look similar at first: updates, backups, monitoring and support. Those headings can conceal materially different services. An automated backup is not the same as a tested recovery. A response target is not a resolution target. “Updates included” does not explain whether the journeys that generate inquiries, orders or member access are verified afterwards.
The short version
A dependable agreement answers seven core questions:
- Which systems, components and environments are in scope?
- Who owns updates, backups, monitoring and incident handling?
- Which checks take place before and after a change?
- How are backups tested for completeness and recoverability?
- Which response path applies during which service window?
- Which work, risks and third-party costs are explicitly outside scope?
- Which commitments concern process and reasonable care rather than a guaranteed outcome?
The purpose is not to make every offer identical. It is to make meaningful differences visible before a supplier is selected.
“WordPress maintenance” is not a standard unit of service
A live WordPress system is more than WordPress core. Themes, plugins, PHP, hosting, the database, caching, forms, email transport, integrations and scheduled jobs work together. Commerce adds product data, payments, shipping and order processing. Multilingual websites need important journeys checked in the relevant languages.
The agreement should therefore identify the operated estate:
- production, staging and any development environment;
- WordPress core, active themes and active plugins;
- ownership of hosting, PHP and database operations;
- forms, search, checkout and other business-critical journeys;
- external services, APIs and custom extensions;
- licences, access and technical contacts.
Without that inventory, an incident can become a debate about whether the host, agency, plugin supplier or internal team is responsible.
Ten service areas worth comparing
1. Technical takeover
Before recurring service begins, the provider should assess versions, access, hosting, components, known defects, security posture, backups and critical user journeys. Legacy risks belong in a visible takeover report. Remediation may be a separate stabilisation project rather than unpriced work hidden inside a monthly fee.
2. Update process
Official WordPress guidance recommends current versions and a backup before an update. A business agreement should go further by distinguishing security patches, routine releases, major version changes and updates with material compatibility risk.
Useful questions include:
- Which changes are automated and which require controlled manual handling?
- When is staging required?
- Which functions are verified after a change?
- Which rollback point is available if acceptance fails?
- How are blocked or abandoned components handled?
3. Functional verification
A successful login or HTTP 200 response does not prove that the site works for the business. Depending on the website, defined checks may cover navigation, forms, languages, search, checkout, payment methods, scheduled jobs and integrations.
The contract should distinguish automated monitoring, manual checks and tests triggered only by particular changes. It should also state the boundary: a technical functional check is not a complete commercial review of every page, product or data flow.
A test journey needs a defined starting point, steps and acceptance criteria. For a contact form, the agreed scope might cover required-field validation and a synthetic submission in an isolated test environment. Passing that check does not automatically prove delivery to a real inbox. An agreed test checkout should likewise be distinguished from real orders and payments.
4. Backups
WordPress documentation treats database and files as the two required parts of a typical full recovery. “Daily backup” is therefore not enough detail. The agreement should explain:
- what is included;
- frequency and retention;
- whether at least one copy is separated from production;
- who can access the backup;
- how failed backup jobs are detected;
- how much recent change could be lost.
The right frequency follows the rate of content, inquiry, order and configuration changes, and the amount of loss the organisation can tolerate.
5. Recovery
An archive is not recovery evidence. A dependable service explains how a restore is prepared, tested and documented. Files, database, configuration, access and post-restore verification all matter.
Before signing, ask:
- How often is a realistic restore test performed?
- Is the test isolated from production?
- Which criteria determine success or failure?
- Who selects the recovery point?
- Which recovery-time and data-loss objectives are actually committed?
RTO and RPO can be useful labels, but plain, contractually precise definitions matter more than the acronyms.
6. Monitoring and security operations
Site Health can expose information about WordPress, plugins, themes, PHP and configuration. Business-critical operations may also need availability, certificate, scheduled-job, error-log, resource, security-event and user- journey monitoring.
WordPress describes security as risk reduction rather than complete risk elimination. A credible supplier therefore does not promise an “unhackable” website. It defines controls, ownership, escalation and the handling of known vulnerabilities.
The same boundary applies to unknown or not-yet-remediated vulnerabilities, compromised credentials, plugin or theme supply-chain risk and weaknesses in hosting, operating systems, networks or the wider architecture. A care provider should specify the measures and dependencies within the agreed scope. Its own selection, configuration, checking and escalation duties remain in place. A third-party system or unknown vulnerability does not automatically remove responsibility for a breach of the provider’s own duties.
7. Incident intake and response
“Support included” is ambiguous until the channel, service window, priority and start of the response clock are defined. A useful agreement separates:
- acknowledgement: when the report has been received and recorded;
- response: when qualified investigation begins;
- restoration: when the critical service should be usable again;
- resolution: when the underlying issue has been corrected permanently.
Priorities should follow business impact. A complete outage of a revenue path is not equivalent to a cosmetic issue on a secondary page.
The starting scope at HEAVY CAMPAIGNS includes no fixed response, restoration or resolution time. A time target applies only when the service window, priority, reporting channel, required client cooperation, dependencies and fee are expressly defined in the individual proposal or agreement. Without that agreement, the service does not create 24/7 standby or a fixed restoration or resolution deadline. Statutory duties of care and notification remain unaffected. Where HEAVY CAMPAIGNS acts as a processor, it must notify the controller without undue delay after becoming aware of a personal data breach.
Automated checks, human review and handling of a report are different services. Check coverage and frequency should therefore be described separately from service hours and reporting channels. Automated monitoring does not mean a continuously staffed operations desk.
The next steps after a signal also need clear ownership: initial assessment, client notification and escalation are distinct from in-depth investigation, forensics and rebuilding. At HEAVY CAMPAIGNS, the first three steps belong to the starting scope within agreed service hours and agreed checking procedures. Further work is scoped separately unless included. Existing service commitments and statutory duties remain unaffected.
8. Content changes and improvement work
Maintenance is not automatically an unlimited development retainer. The agreement should say whether content edits, new features, design changes, tracking, SEO work or integration changes are included. Additional work needs a transparent approval and pricing route.
9. Evidence and reporting
A useful service report should support decisions rather than repeat automated notifications. It can show:
- changes completed;
- checks that passed or remained blocked;
- incidents and risks requiring attention;
- the status of backup and recovery evidence;
- the next recommended improvement.
10. Handover and termination
Exit conditions belong in the initial agreement. Notice periods, documentation, administrator access, source code, licences, backups, open risks and removal of obsolete supplier access should all be addressed. The client should retain control of its domain, data and business-critical accounts.
What an SLA should define
SLA is often used as a general quality label. A buyer should be able to answer these questions before signing:
- Which service windows apply on business days, weekends and public holidays?
- Which channel must be used to report an incident?
- When does measurement begin and when may it pause?
- How is priority tied to business impact?
- What do response, workaround, restoration and resolution mean?
- Which access and client cooperation are required?
- Which hosting or third-party failures are outside the provider’s control?
- Which escalation applies when a target is missed?
- How are performance and exceptions evidenced?
- Which remedies or service credits genuinely apply?
The right answers depend on the role of the website. A low-change information site needs a different operating model from a shop, member portal or international lead platform.
An organisation requiring continuously staffed standby or fixed recovery targets needs to assess the suitability of the actual proposal in advance. Those requirements are outside the HEAVY CAMPAIGNS starting scope and require a separate review of scope and genuinely available delivery capacity.
Proactive and continuous – without a security guarantee
WordPress Care & Security should be understood as ongoing preparedness. Its value lies in a current inventory, controlled change, observation of relevant signals, accountable escalation and prepared recovery procedures. That work may reduce the likelihood, impact or duration of certain incidents. It cannot guarantee that an attack will never succeed or that data loss will never occur.
The boundaries should therefore be explicit before engagement:
- no guarantee of complete security or uninterrupted availability;
- no promise to identify every unknown vulnerability or attack in advance;
- no fixed response, restoration or resolution time without an express individual agreement;
- clear responsibilities for the provider’s work, client systems and third parties; duties of care and statutory obligations remain in place;
- client responsibilities for access, licences, hosting, decisions and coordinated change;
- separate scoping of incident response, forensics, rebuilding and third-party work unless expressly included.
The service description, proposal and agreement should explain these boundaries clearly and consistently. The actual B2B liability provisions require specialist legal review. A website notice cannot replace that review.
What does a WordPress maintenance contract cost?
A defensible price needs a defined baseline. The number of environments, WooCommerce, languages, custom plugins, integrations, change frequency, service windows and response requirements all affect delivery effort.
HEAVY CAMPAIGNS WordPress Care & Security currently starts with onboarding from EUR 1,490 excluding applicable taxes, followed by ongoing service from EUR 790 per month excluding applicable taxes for business clients. The documented starting configuration covers one production and one staging instance, controlled updates, scheduled daily backup runs with outcome monitoring, technical monitoring and a documented quarterly recovery exercise. Whether a particular restore succeeds and how long it takes depends on the available recovery point, affected environment and incident cause. WooCommerce, multilingual operation, additional instances, custom plugins, extended service windows and further work are scoped separately.
The starting configuration includes no fixed response, restoration or resolution time. Where useful and realistically deliverable, such targets are agreed only in the individual proposal for a clearly defined service scope.
These figures provide initial orientation. Only the scope, fee, contracting entity and service level confirmed in the individual proposal or agreement are binding.
The takeover gives the client team a system inventory, findings and gaps in the review, a responsibility map and an agreed care plan. The plan specifies test journeys, backup retention and a separate copy, service hours, reporting channels and handover at termination. The monthly report records changes, test results, backup status and open decisions. The service page explains what the monthly report contains and how it supports decisions on outstanding issues.
Pre-signature checklist
- Production, staging and further environments are named.
- Core, themes, plugins, PHP, hosting and integrations have clear owners.
- Update classes, testing and rollback routes are described.
- Database and files are both included in the backup set.
- Retention, storage locations and access rights are defined.
- Restore tests have a frequency, scope and acceptance criteria.
- Critical user journeys are listed as functional checks.
- Service windows, priorities and the response clock are unambiguous.
- Third-party services, licences and excluded work are visible.
- Out-of-scope changes have an approval and pricing route.
- Reporting shows actions, findings, evidence and open risk.
- Handover, access and data control are covered for contract termination.
Choosing the next step
Review your website and care needs: describe your website and the care you are looking for. The next step assesses the starting position, suitable test journeys and open requirements. Please do not send passwords or confidential documents.
The Care service page sets out the starting scope, boundaries and the contents of the monthly report. The existing WordPress maintenance operations guide explains the operating model. Where a wider decision between maintenance, stabilisation and rebuilding is needed first, an appropriate assessment is scoped separately.
This article is a procurement guide, not a contract template or legal advice. It creates neither a security or availability guarantee nor a specific service level.