WordPress Maintenance: What Agencies Should Include After Launch

A useful WordPress maintenance plan defines who keeps the site current, how it can be recovered, which customer journeys are checked, and what happens when something breaks. For a design agency, it should also separate ongoing care from new development so you can explain the service to your client and price it against a clear scope.

“Updates included” is not enough to settle those questions. Before offering a monthly plan, write down the work, the evidence the client receives, and the limits of the arrangement. The checklist below is our recommended scoping approach, not a claim that every support package includes the same services.

Start with the site you are actually maintaining

Two WordPress websites can need very different support. A small brochure site with a contact form has a different operating risk from a store taking orders or a membership site changing records throughout the day.

Before quoting, collect a short inventory:

• Hosting, domain, DNS, and the people who control each account.
• WordPress, theme, and plugin versions, including paid license renewal owners.
• Custom code, its repository, and the instructions needed to build and deploy it.
• Forms, payment services, email delivery, and other external connections.
• The business actions that must work, and when the client needs support available.

Ask the incoming developer to identify existing problems separately. Repairing an abandoned integration or taking over undocumented custom code is onboarding work, not an invisible obligation hidden inside a routine maintenance fee.

For a custom theme, a dashboard login may not be a complete handover. The maintenance team also needs the source files and build process. Establish that before the first update exposes a dependency nobody knows how to change.

Define what happens before and after an update

WordPress recommends keeping the installation current and backing up before an update. Its update documentation also describes automatic background updates. Automation helps apply changes; it does not establish that your particular form, theme, or integration still works.

We recommend agreeing on an update process with these checkpoints: review the change, confirm a usable backup, test relevant changes in a separate environment, release, and verify the live site. Decide which updates can run automatically and who investigates a failure. Give urgent security fixes their own escalation route rather than assuming every change can wait for a monthly appointment.

Be specific about the tests. For a lead-generation site, an example acceptance check is: submit a clearly labeled test inquiry, confirm it reaches the intended recipient or CRM, and check the visitor’s confirmation message. Opening the homepage would miss that failure.

A staging copy also needs boundaries. Prevent test emails and payments from reaching real customers, restrict access appropriately, and avoid copying personal data unnecessarily. For a site with live orders, do not replace its production database with an older test copy just to deploy a theme update.

Ask for a recovery demonstration, not only a backup badge

A typical WordPress recovery needs both files and the database. They contain different parts of the site; downloading the theme alone is not a complete backup. WordPress explains this distinction in its backup guidance.

Our suggested scope should answer four questions: how often copies are made, how long they are retained, where they are stored, and who can restore them. Choose those settings around how much recent work the business could tolerate losing. A daily copy may leave a substantial gap for a site receiving orders all day.

Ask the provider to demonstrate a restore into an isolated environment and record the date, backup used, and result. That provides better evidence than a green “backup completed” indicator alone. Agree on how often to repeat the exercise and whether recovery work is included in the plan.

Recovery is not always a single rollback button. If new orders arrived after a deployment, restoring an older database could discard them. The response plan should make someone responsible for evaluating that risk before acting.

Distinguish uptime from a working customer journey

A page responding successfully can still have a broken form, missing product options, or a failed connection to another service. Our recommendation is to pair availability monitoring with a small list of functional checks tied to the client’s business.

A fictional agency client might have three checks: an inquiry reaches its destination, an editor can publish a service update, and a visitor can follow the main booking link. A store would need a different list, including an agreed method for testing checkout. These are examples for scoping, not reports of client outcomes.

For each check, record its frequency, owner, and escalation route. Name the person who receives alerts, including when the agency’s main contact is unavailable. “Monitoring included” should describe a response arrangement, not just software that sends messages.

Keep deeper evaluations distinct. An ongoing functional check does not replace a complete accessibility review or a performance investigation. Our accessible booking checklist and PageSpeed guide explain those separate workstreams.

Draw the boundary between hosting, maintenance, and development

A hosting subscription and an application maintenance service can overlap, but the label alone does not tell you who fixes a plugin conflict or custom integration. WordPress’s hardening guidance distinguishes infrastructure responsibilities from application responsibilities and describes security as reducing risk rather than eliminating it.

For the agency’s proposal, assign each responsibility to a named party: host, development partner, agency, client, or external vendor. Include license renewals and access changes when team members leave. Avoid promising that a security product makes the site immune to compromise.

Then define the boundary around new work. Updating existing software, investigating a failed scheduled task, and building a new product configurator are different commitments. Content changes can be included, but specify what counts as a routine edit and what needs a separate estimate.

Make support terms useful to the person reporting a problem

“Fast support” leaves too much open. Agree on coverage hours and time zone, the reporting channel, severity definitions, and the initial response target. Distinguish acknowledgment, active investigation, a temporary workaround, and final resolution.

For example, a completely unavailable site should not enter the same queue as a request to change a photo next month. The plan should state who can authorize emergency work and any additional cost. A response target is not a promise that every incident will be resolved within that period.

If your agency stays in front of the client, define how the developer updates you. If direct client communication is authorized, define its scope and who approves additional work. This avoids turning an urgent technical conversation into an unexpected commercial commitment.

Price the agreed responsibility

A useful maintenance estimate starts with the inventory, the checks, the recovery requirements, and the support coverage. A universal price based only on “it’s WordPress” ignores the differences that determine the work.

Our recommendation is to document the recurring scope and its price, list exclusions, and agree on changes before carrying them out. For an inherited site, assess its condition before committing to ongoing care. A recurring fixed fee still needs boundaries and a way to revise the scope when the website changes.

Give the client a concise service record: changes released, checks completed, recovery tests performed, unresolved issues, and decisions needed. The purpose is to show what was maintained and what remains open, not to sell a timesheet.

Frequently asked questions

Is managed WordPress hosting enough?

It depends on the specific service. Read what the host covers, then assign anything left over, such as custom code, integrations, functional testing, and client communication. Do not assume two providers mean the same thing by “managed.”

Should plugins update automatically?

Choose an approach based on the site and the ability to detect and recover from problems. Automatic updates can be useful, but someone still needs responsibility for failures. Avoid treating either “everything automatic” or “never update” as a complete maintenance plan.

Does maintenance include new pages and features?

Only when the agreed scope says so. Define routine content edits separately from new templates, features, and integrations. Price additions before implementation so the agency and client can make an informed decision.

Can a development partner support a site it did not build?

Potentially, after reviewing access, code, dependencies, and existing issues. An assessment establishes what can be maintained, what needs repair first, and which limitations must be accepted or removed.

What should we send when asking for a maintenance estimate?

Start with the site URL, platform details, known issues, important integrations, and the support coverage you need. Share credentials later through an agreed secure channel. ROAR works with agencies on maintenance and technical support as well as full builds; see how we collaborate or send us your scope.