What Website Management Actually Includes

Maintenance is too small a word

Many website maintenance plans are lists of automatic updates. They promise to install new versions of WordPress, themes, and plugins, then send a report. That work matters, but it does not answer the question most organizations are trying to solve: who takes care of the website?

A managed website still needs content changes, publishing help, form checks, accessibility corrections, incident diagnosis, vendor coordination, release review, and an informed response to the next request nobody could predict when the contract was signed.

Website management is the ongoing ownership of that work. Software maintenance is one responsibility inside it.

The agreement should name the operating responsibilities

A useful agreement should make the recurring responsibilities easy to find.

• Content and page changes requested by authorized staff.
• Routine WordPress, theme, and extension maintenance.
• Monitoring for availability, security regressions, and visible failures.
• Diagnosis across the site, hosting platform, forms, and connected services.
• Accessible implementation and correction within the agreed scope.
• Staging, release checks, backups, and written records of completed work.
• Coordination with hosting and software vendors when a problem crosses systems.

Response time is not completion time

A response target says when the web team will acknowledge and begin triage. It does not promise that every request will be finished within the same number of hours.

That distinction protects both sides. A typo can often be corrected immediately. A failed integration may require evidence, vendor support, credentials, testing, and a safe release. Pretending those jobs share one guaranteed completion time rewards rushed work and vague excuses.

The agreement should state the acknowledgment target, business hours, emergency boundaries, and how the team communicates an estimate after it understands the request.

Tasks and projects need a visible boundary

Routine management works well for small changes that fit the existing site and can move through the normal workflow. Rebuilds, new integrations, migrations, and substantial new capabilities need their own scope, schedule, price, and acceptance criteria.

The boundary should not be a surprise invoice. When a request is larger than routine management, the web team should explain why, describe the next step, and provide a fixed proposal before project work begins.

Management should leave a record

An organization should not need to reconstruct its website history from email threads. Requests, decisions, completed changes, monitoring results, and unresolved dependencies should remain visible to authorized staff.

That record makes transitions safer and oversight easier. It also changes the management conversation from whether somebody remembers doing the work to what was requested, what changed, when it changed, and what still needs attention.

Nine questions for an incumbent vendor

A decision maker can evaluate a current arrangement without reading code. Ask these questions and look for specific answers.

• Who can publish an urgent correction?
• Who watches for failures and security regressions?
• Who owns the hosting, domain, and service accounts?
• Does every person use an individual account?
• Where are consequential changes tested?
• How are requests and completed changes recorded?
• What work is included in the monthly fee?
• What turns a task into a separately quoted project?
• Who coordinates the response when the source of a failure is unclear?