A maintenance plan is sold as one line on an invoice. This page identifies fifteen distinct jobs that the line can stand for, and most disagreements about maintenance turn out to be disagreements about which of the fifteen the word covered.
So this page does not use the word as a unit. It lists the jobs, and for each one asks the question that settles it: what record or written term would establish who holds this?
The bottom line
"Maintenance" is not one job. This page identifies fifteen distinct jobs, and a business can be paying for a maintenance plan while several of them have no named responsible party. The operating model suggests where to look; only the account records and the written agreement establish who holds the job. Work through the fifteen, get each one in writing, and ask what evidence would show it is being done.
- Best fit for
- Establishing which of the fifteen jobs your arrangement covers, and what record or written term settles each one.
- Avoid when
- Comparing two maintenance quotes on monthly price alone, before establishing what each one covers.
- Main tradeoff
- Assigning a job creates a visible cost or time commitment; leaving it unassigned means nobody is committed to perform it when it is needed.
Please note: This is editorial guidance for a general audience. It is not advice about your particular business, and nothing here guarantees that a site will stay available, secure, accessible or compliant.
Evidence: Editorial assessment Last verified
The one rule this page runs on
The operating model suggests where to look. Only the account records and the written agreement establish who holds the job.
That rule does most of the work here, and it rules out the two shortcuts people reach for first. You cannot read responsibility off the software -- hosted or self-hosted -- and you cannot read it off the type of provider. Both tell you where to look. Neither tells you who holds it.
Two consequences follow, and they are symmetrical.
Hosting is not maintenance. Hosting is where the site runs. Maintenance is the work of keeping it working. A host that never goes down has not thereby updated a plugin, tested a restore, or established that your contact form still delivers.
And self-hosted software does not mean the owner does everything. It means the software has not settled the question -- somebody may hold each job, and the agreement and the account records are where that is written down.
The fifteen jobs
| The job | On a hosted platform Wix, Squarespace, Shopify, WordPress.com -- what this setting alone settles | On self-hosted software WordPress or similar, on hosting you buy -- what this setting alone settles | If somebody is hired Freelancer, agency or managed service -- what the arrangement settles | Proof to ask for The records and written terms that establish it |
|---|---|---|---|---|
| Domain registration and renewal Registration is a record in a registrar account, not a property of your website software. | A platform may offer registration, and may hold the domain in its own account or in yours. The platform type does not settle who the registrant is. | The software has no bearing on registration. The registrar record does. | A provider may register, administer or pay for a domain. Each of those is compatible with the business being the registrant, and with it not being. | Four records together: the registrant on the domain record; who holds the registrar account login; the billing contact and payment method; and who is responsible for renewal. ICANN describes the registrant as the party who manages the domain through the registrar. |
| DNS control Three different things get called "control". Separate them before concluding anything. | DNS may be administered through a registrar, a platform, a host, a CDN or a provider account. Which one is authoritative is a fact to check, not one the platform type implies. | The same. Pointing a domain somewhere does not tell you which account now answers for the zone. | A provider may hold administrative access without holding ultimate authority, and may hold it inside the business account or inside their own. | The authoritative DNS provider; the account owner; the named administrators; and the documented recovery and transfer path. Distinguish OWNERSHIP OR ULTIMATE AUTHORITY from ADMINISTRATIVE ACCESS, and both from DELEGATED OPERATIONAL ACCESS. Being unable to edit a record yourself establishes only that you lack operational access today -- not that the business lacks control. |
| Hosting or platform subscription Who pays and who contracts are separate questions, and neither settles ownership. | The subscription buys the platform service on its published terms. Which plan, and what those terms cover, are facts to read. | A separate hosting service, on its own contract and renewal cycle. | Hosting may be contracted by the business, resold by a provider, or held inside a provider account. Each has a different consequence if the arrangement ends. | The service account and who holds it; the contracting party named on the agreement; who is billed and by whom; the renewal date and status; and what happens to the service on cancellation. A payment card establishes who pays -- not who owns, and not who is responsible. |
| Software and core updates Applying an update and answering for its consequences are two jobs. | A hosted platform maintains its platform software within its documented scope. Anything added on top -- apps, integrations, custom code -- may be maintained by the platform, by the component vendor, by another provider, or by nobody. | Self-hosted systems may apply some updates automatically. That does not establish responsibility for testing, for failures, for compatibility between components, or for components outside the automatic mechanism. | Established by the scope of the agreement, and only for what that scope names. | An update log showing what was updated and when, and alongside it the named party responsible for testing and for a failed update. |
| Themes, plugins, apps and integrations Priced as one line; maintained by several parties. | Each component may be maintained by its own vendor, by the platform, by a provider, or by nobody. The documented scope of the platform covers its own software. | The same: each component carries its own vendor and its own update mechanism, and compatibility between them is a further responsibility again. | Established by the agreement, component by component. "Updates included" does not itself identify which components. | An inventory giving, for each component: the component, its vendor, its update mechanism, the responsible party, and who is responsible for compatibility and testing. |
| Backups and restoration A copy reported as created and a copy proven to restore are different claims. | A platform may provide backups within its published terms. What they cover, how long they are kept, and how a restore is requested are facts stated in those terms. | A host may take backups for its own recovery purposes, for the customer, or both. Which applies is stated in the hosting terms; self-hosting does not imply it. | Established by the agreement. A commitment to back up is not by itself a commitment to restore. | Strongest: A DATED RESTORE TEST. Where none exists, ask instead for the backup scope, schedule, retention, storage location, responsible party, documented restore procedure, last reported successful backup, and known exclusions. A successful restore test is evidence that the tested copy and procedure worked at that time; it does not guarantee that a current or future backup will restore. |
| Security monitoring and incident response Protection within a defined scope is not the same as somebody watching your site. | A platform may provide infrastructure-level and site-specific protections within a defined scope. That scope does not establish monitoring or incident response for every account, integration or business process. | Not established by the software. Whatever is monitored is monitored because somebody configured it. | Established by the scope of the agreement. Ask what is monitored, what triggers a response, and who is called. | The written monitoring scope; where alerts are sent; a sample or test alert where one can be produced; the escalation procedure; the responsible party; and the incident record, if an incident has actually occurred. |
| Uptime monitoring Three different things can be monitored, and only one of them is your business. | Platform or infrastructure availability may be monitored and reported by the platform. That is distinct from monitoring your specific URL, and distinct again from monitoring whether a form, booking or checkout still works. | Not established by the software. Any monitoring exists because somebody set it up. | Established by the agreement. Ask which of the three levels it covers. | The monitor configuration and what it checks; who receives the alert; the status history; or a test alert. A naturally occurring alert is not required, and its absence establishes nothing either way. |
| Content changes The unit matters more than the number. | Not established by the platform. Content changes happen because somebody arranged them. | Not established by the software, for the same reason. | Established by the agreement, which may express a limit as hours, tasks, requests, incidents, pages, content items, service windows, or capacity that depends on availability. | The limit in writing, and with it: what counts as one unit, what is excluded, whether unused capacity carries forward, and what happens once the limit is reached. |
| Accessibility checks after changes Included only where the scope identifies it. | Not established by the platform. An accessible template does not establish that the site stays accessible after edits. | Not established by the software. | Included only if the scope identifies it. It is a distinct activity with its own method and criteria. | What is checked, when, by what method, against what standard or criteria, and what happens after an issue is found. None of this is a certification, and none of it establishes legal compliance. |
| Analytics and Search Console access Two services, two different access models. Do not merge them. | Both services are held in accounts outside the website platform, whatever the platform is. | The same. | A provider may hold named access in either service. That is compatible with the business retaining the owner or administrator path. | Search Console: confirm the business retains appropriate OWNER access to the property. Analytics: confirm the business retains ADMINISTRATOR access through a business-controlled Google account. The two mechanisms are documented separately and are not interchangeable. |
| Account and user access This row is a recommendation, and says so. | Recommended: the business retains an owner or administrator path appropriate to the service. | Recommended: the same, for the hosting account and for the administrative accounts of the site. | Recommended: helpers use named accounts carrying the access their work needs. Shared credentials should not be the default arrangement. | The account owner and administrator records; the named users and their roles; and the documented recovery path. Analytics identifies each user by their own Google Account, which is what makes named access checkable. |
| Forms, email delivery and third-party services Submission, processing and delivery are three steps with three possible owners. | That a form operates on the platform does not establish end-to-end delivery, nor responsibility for the third-party services it depends on. | Not established by the software, for the same reason. | Established by the agreement. Ask whether it covers delivery, or only the form. | A documented test covering submission, processing and delivery -- and the named party responsible when any step fails. |
| Support response and escalation Acknowledgement, assessment, workaround and resolution are four separate commitments. | Platform support on the published terms, hours and plan. | Whatever has been arranged, with whoever agreed to it. | Established by the agreement: the hours, what it commits to, and what happens outside them. | The commitments in writing, asked for separately: acknowledgement, assessment, escalation, workaround, and resolution. A response time ordinarily describes acknowledgement or an initial response unless the agreement defines it differently. It is not necessarily a resolution time. |
| Documentation, export and handoff Agree it while it is still hypothetical. | What an export contains is defined by the published terms and the selected plan. Check before you need it. | Holding files on a server is not the same as being able to reach them. | Established by the agreement, and worth settling at the start rather than at the end. | Establish who can access the files, the database, the configuration, the deployment process, the credentials, the documentation and the export tools. Then a written handoff inventory: what you would receive, in what format, how quickly, and who is responsible for providing it -- with access tested where testing is practical. |
A caution marks something that commonly surprises people later.
Evidence: Editorial assessment Last verified
THE OPERATING MODEL SUGGESTS WHERE TO LOOK; ONLY THE ACCOUNT RECORDS AND THE WRITTEN AGREEMENT ESTABLISH WHO HOLDS THE JOB. The first three columns describe what each setting does and does not settle. They are not assignments, and responsibility cannot be inferred from hosted versus self-hosted software, or from the type of provider. Where a cell says "not established", it means the setting alone does not settle the question -- not that nobody holds the job. The proof column is where an answer actually comes from.
Read the last column first. The first three columns narrow where to look; the fourth is what actually establishes an answer.
Caution: Caution: Three cells in that table separate a backup from a restore, and the distinction is worth stating precisely. A backup report shows that a copy was REPORTED AS CREATED. A successful restore test provides stronger evidence -- that the tested copy and the tested procedure worked at that time. It does not guarantee that every current or future backup will restore successfully. Restores fail for ordinary reasons: the copy was incomplete, the database was excluded, nobody had the credentials, or the procedure had never been tried.
What updating does, and what it does not
Many software updates address security problems. CISA puts it plainly: many updates are created to fix security risks, and critical ones should be installed as soon as possible.
What follows is narrower than the sentence sounds. Applying updates reduces known risk. It does not make a site secure, and no arrangement can promise that it will. A site that is fully up to date can still be broken into through a password, a third-party service, or a flaw nobody has published yet.
A second narrowing matters just as much. Holding the top role in the software is not the same as holding the jobs around it: the documented WordPress Administrator role does not itself establish responsibility for hosting, servers, databases, backups or security. What the role document settles is what the role covers. Who holds those other jobs is settled somewhere else -- in an agreement, or in an account record.
This matters when reading a proposal. "We keep your site secure" is not a description of work. "We apply core and extension updates monthly and send you the log" is.
Comparing maintenance arrangements
| What to compare | Owner-managed Work the owner performs or coordinates | Task-by-task help Separately scoped engagements, as needed | Recurring agreement A stated scope, billed monthly | Managed website service The site and its upkeep as one service | Platform-managed software Platform does its software; you do the business tasks |
|---|---|---|---|---|---|
| What is included In every model, the answer comes from the written terms, not from the model. | The work the owner chooses to perform or coordinate. | Each engagement is separately scoped. | What the agreement lists. | What the service terms and the selected plan define. | The platform software and infrastructure, within the published terms and the selected plan. |
| How any usage limit is expressed Limits are not always counted in hours. Establish the unit before comparing two offers. | Time, skills, tools and whatever routines are documented. | Set per engagement, alongside its price. | As the agreement expresses it: hours, tasks, requests, incidents, pages, content items, service windows, or capacity that depends on availability. | As the service terms express it. Establish the unit before comparing. | As the published terms state, for the work of the platform itself. Business-layer work is not covered by that limit. |
| Does unused capacity carry forward | Not applicable. | Not applicable unless an engagement states otherwise. | As the agreement states. Ask directly; it is not always addressed. | As the service terms state. | Not applicable. |
| What is excluded The list nobody reads until they need something on it. | Whatever is neither performed nor arranged. | Anything outside the scope of that engagement. | Whatever the scope does not name. | Whatever the terms do not name. Content, accessibility and third-party services are worth naming explicitly. | Whatever the published terms do not cover. Business-layer work and third-party integrations require separate verification. |
| Restrictions on who else may work on the site An ordinary commercial term with practical consequences. Read it before the day you want a second pair of hands. | There may be no maintenance-provider restriction. Platform terms, hosting terms or another connected-service agreement may still limit access or changes, so check the terms that apply. | Each engagement carries its own scope, and that scope may restrict access, changes, subcontracting or overlapping work. Check each engagement. | Ask whether the agreement restricts other people from working on the site, requires consent first, changes support coverage, or reallocates responsibility. | Ask whether the terms restrict third-party access or code changes, and whether consent is required first. | The published terms govern what code and what access are permitted. |
| Response time vs resolution time Acknowledgement, assessment, escalation, workaround and resolution are five separate commitments. | Set by the availability of the owner. | Established per engagement, if at all. | As the agreement defines it. Ask separately about acknowledgement, assessment, escalation, workaround and resolution. | As the service terms define it. Ask separately about acknowledgement, assessment, escalation, workaround and resolution. | Support on the published terms, hours and plan. Ask what those terms commit to beyond an initial response. |
| Preventive work vs requested changes Ask what happens in a period when you request nothing. | Whatever the documented routine covers. | Continuing responsibilities exist only where expressly arranged. | As the agreement states. | As the service terms state. | As the published terms state, for the software of the platform itself. |
| Cancellation and handoff Settle it at the start, when it is still hypothetical. | Not applicable. | Each engagement ends on its own terms. Ask what is handed over at the end of one. | As the agreement states: the notice required, and what you receive on the last day. | As the terms state. Check whether hosting or the domain is bundled into the same cancellation. | Export rights are limited to the published terms and the selected plan. Check what an export contains. |
| Ownership and access after termination Determined by the account records, in every model. | Unaffected, where the accounts are held by the business. | Unaffected, where the accounts are held by the business. | Verify against the account records rather than against the tone of the agreement. | Determined by which account holds the site, the domain and the data. Verify each. | Continued access to the account, content and any export is governed by the published terms and the selected plan. Verify what remains accessible after termination. |
A caution marks something that commonly surprises people later.
Evidence: Editorial assessment Last verified
Operating models, not vendors, and deliberately no price range: there is no defensible public dataset of maintenance pricing, and the candidates collected for the cost guide were priced against a BUILD scope, so reusing them here would compare unlike things. Nothing in this table follows from the size of a provider or from how it employs people. THE MODEL SUGGESTS WHERE TO LOOK; THE WRITTEN TERMS AND THE ACCOUNT RECORDS ESTABLISH THE ANSWER -- which is why most cells here name what to read rather than what to expect. The same verification standard applies to every model. Two arrangements at the same monthly price can cover different lists, which is why the rows are about coverage and exit rather than cost.
No price range appears on this page, and that is deliberate. There is no defensible public dataset of maintenance pricing, and the closest thing we have -- the provider offers collected for the cost guide -- were priced against a build scope, not a maintenance one. Reusing them here would compare unlike things.
Compare maintenance proposals on scope, limits and responsibility instead. Two arrangements at the same monthly price can cover different lists, and the cheaper one is sometimes the one that covers more.
What a limit is actually counting
A limit is not always counted in hours, and two agreements that both sound generous can be measuring completely different things. A limit may be expressed as:
- hours of work;
- tasks, however the agreement defines a task;
- requests, counted as they arrive;
- incidents, which may bundle several requests or split one;
- pages or content items changed;
- availability-dependent capacity -- "as capacity allows", which is a limit whose size is not fixed in advance;
- fixed service windows, where the constraint is when the work happens rather than how much of it there is.
None of these is better than the others. They are simply different units, and a monthly price tells you nothing until you know which one you are buying.
Whichever unit applies, establish five things before you sign:
- What counts as one unit. Is "a task" a single edit, or everything you sent on Tuesday?
- Whether related requests are combined, or counted separately.
- Whether unused capacity rolls over into the next period, and for how long.
- What happens after the limit -- billed at a rate, queued to next month, or declined.
- Whether emergencies come out of the same allowance, or sit outside it.
"Unlimited" is a statement about the count and nothing else. It does not mean unlimited scope -- the exclusions still apply -- and it does not promise priority or a resolution. An unlimited allowance for work that is out of scope is not an allowance.
Who else may work on the site
Agreements differ on whether anybody besides the provider may work on the site. An exclusivity or consent term is not automatically a warning sign. Providers may need to know what is changing where they are accountable. Equally, a business may need to bring in a specialist. The point is to identify the term before the question becomes urgent.
Four questions settle it:
- Does the agreement restrict who else may work on the website?
- Does outside work suspend support, void coverage, or change responsibility for anything that follows?
- Is consent required before another provider works on it, and how is consent given?
- What access, documentation and cooperation must be provided when specialists overlap, and in which direction?
These are questions about how a contract compares with another contract. They are not legal advice, and a term that matters commercially is worth putting to somebody qualified.
Settle the accounts before you settle the plan
Most maintenance arguments are really access arguments wearing a different hat. If the accounts are in your name, a bad arrangement is an inconvenience. If they are not, it is a hostage situation.
Website Ownership Check
Worth settling before any maintenance arrangement starts.
-
Area 01. Domain registration
-
Area 02. DNS control
-
Area 03. Website platform or hosting account
-
Area 04. Website files and portability
-
Area 05. Business email
-
Area 06. Analytics and Search Console
-
Area 07. Copy, photography, graphics and design
-
Area 08. Customer and operational data
-
Area 09. Cancellation, export and handoff
Working through the proof column
The fifteen proof requests in that table are an inventory to work through over time, not a list to send to a provider in one message. Fifteen simultaneous demands is a different object from fifteen questions asked as they become relevant, and it is the wrong way to open a working relationship.
A good deal of it never needs to be requested at all. Registrar records, DNS records, Search Console and Analytics access, platform user lists and billing history can be read directly from your own accounts, where you hold them. Check those yourself first; what you cannot see is what to ask about.
Start with these five
In this order. Each one changes what the next conversation is worth having.
- Domain and DNS control -- the registrant, the registrar account, the authoritative DNS provider, and the recovery path.
- Core accounts and billing -- who holds the platform, hosting, analytics and search accounts, who is contracted, and who is billed.
- Backup scope and restoration process -- what is copied, how often, where it is kept, and the documented procedure for getting it back.
- Support and escalation -- acknowledgement, assessment, escalation, workaround and resolution, asked about separately.
- Cancellation, export and handoff -- what you receive, in what format, how quickly, and who provides it.
Continue through the remaining ten, one at a time. The timing can be staged, but every job left unresolved remains a responsibility gap.
A checklist for an arrangement you already have
Work down the table with the agreement in front of you, and the account records open.
- For each of the fifteen jobs, write down who holds it, and what says so. Leave it blank if neither the agreement nor an account record settles it. The blanks are the finding.
- Ask for one piece of evidence per job that somebody does hold: the update log, the restore procedure, the user list, the monitor configuration.
- Separate the response time from what happens after the response. A response time ordinarily describes acknowledgement or an initial response unless the agreement defines it differently, and it is not necessarily a resolution time.
- Find the limit and work out what it counts: hours, tasks, requests, incidents, pages, content items, capacity as available, or a service window. Then ask what one unit is, what is excluded, whether unused capacity carries forward, and what happens once it is reached.
- Check whether the agreement restricts who else may work on the site, whether outside work affects support or responsibility, whether consent is needed first, and what access and documentation each side must provide when two providers overlap.
- Establish what you receive on the last day, and get it in writing while everybody is still getting along.
- Check the domain and the core accounts against the records, whoever administers them day to day.
What to do next
If several rows came back blank, that is not by itself a finding about a provider -- it is a finding about what was written down. It is a far easier conversation to have now than during an outage.