Website maintenance: define your freelance service

A maintenance service starts with selection, not a price. For a freelancer working alone, the most manageable starting point is usually a small business website with familiar components, a contact person you can reach and straightforward user journeys. This guide uses a self-hosted WordPress website as its running example. It is not a maintenance procedure for every platform.

An online store taking orders continuously, a medical portal or a business application brings additional risks and skill requirements. Do not squeeze these into a small business website package just because their homepage looks like a tradesperson’s site. The number of pages tells you very little about how difficult a restoration might be, which data must be preserved or how dependent the site is on an external provider.

Define three onboarding decisions: accepted, accepted after remedial work, or out of scope. A site whose domain owner is unknown belongs in at least the second category. An infected site, or one that depends on an abandoned plugin, may need a specialist before you can offer an ongoing service. Discovering a problem does not oblige you to fix it within the price you quoted.

The aim is to explain to the client what you know how to do, what needs investigation and what you do not cover. This clarity also protects beginners: it is better to maintain a small, consistent set of sites properly than to promise universal support you cannot deliver.

Your first look at a website is not routine maintenance. Allow for a separate inventory phase, with its deliverable and any fee stated before you begin. You are establishing a reliable starting point: who owns what, what condition the site is in and which commitments are already in place. Never ask for a password in an ordinary email; agree on an appropriate way to access the site with its owner.

Record the domain, hosting provider, CMS, theme, plugins, licenses and services connected to the website. Add its forms, recipient email addresses, booking tools and essential content. For each item, note the account holder, the person responsible for renewal and where the documentation is stored, without copying secrets into the client record.

WordPress provides a Site Health screen with configuration information and reported issues. It can inform this inventory; it is neither a complete audit nor proof that every user journey works. Also browse the site as a visitor would, on a phone and a computer.

Finish with a list of gaps: missing access, an expired license, a form submission that was not received or an unverified backup. Assign a decision and an owner to each one. Have the client agree to the starting condition and priority fixes before the package begins. Ongoing maintenance should not silently absorb several years of technical debt.

Your central tool fits on one page. It should let a nontechnical person understand what they are buying and how to ask for help. Use the checklist below to prepare your offer, then have the contractual commitments reviewed if your circumstances require it. This is a framework for discussion, not a legal contract ready to sign.

• Website covered: address, environment, accepted components and initial condition.
• Recurring work: checks, controlled updates, backup verification and reporting.
• Frequency: what is checked on every visit and what follows a different schedule.
• Included requests: type, maximum number or duration, counting unit and rules for exceeding the allowance.
• Support: one contact channel, service hours and how to report an incident.
• Authorization: actions already agreed, changes requiring approval and the authorized contact person.
• Exclusions: redesigns, new features, cleanup of an existing infection, a third party’s services or any other work not included.
• Exit arrangements: documentation handed over, access management and the end of renewals you manage.

Avoid “unlimited small changes.” Replacing an approved sentence and reorganizing a sales page are not the same amount of work. Prefer an observable definition: changing supplied text on an existing page, without altering its structure, within the agreed allowance. Specify what happens when several requests arrive together.

Finally, ask the client to explain the offer back to you: what would they expect to be included if their form stopped working on a Sunday? Their interpretation often reveals an ambiguity your technical document does not show. Clear up that ambiguity before calculating a margin.

The official WordPress backup documentation distinguishes between files and the database: both are needed to restore a typical WordPress website. A media archive is therefore not a substitute for a complete backup. That distinction alone gives you a precise question to ask the hosting provider: what exactly does the service being sold cover?

Next, ask what data loss the client could tolerate. A business website that rarely changes and a site receiving orders every hour do not have the same needs. Backup frequency and retention should follow from that discussion, the technical capabilities and the budget, rather than a standard setting applied to every client.

Prepare a restoration test in a separate, authorized environment, never by overwriting the public website to “check.” Before testing, disable live messages and integrations that could contact customers or trigger operations. A copy may contain personal data: restrict access and retention according to the applicable requirements.

Keep a concise record: the backup date, test environment, observed duration, user journeys checked and any issues. A successful test today does not guarantee every future restoration. It can, however, reveal a missing file, unavailable access or a misunderstood procedure before an incident occurs. If you do not know how to run this test safely, arrange for a qualified professional rather than selling guaranteed recovery.

An update is not finished when the button stops spinning. In its update instructions, WordPress recommends backing up the site before you begin. Your service must then specify the checks to perform and what to do if the site’s behavior changes.

Prepare a short list of the user journeys that matter to this client: opening a service page, submitting a quote request, downloading a document and checking mobile navigation, for example. Repeat the same journeys before and after an intervention. This helps distinguish an existing problem from an issue introduced during the change.

For risky changes, use a suitable test environment and define how to return to the previous state. This depends on the site: an old copy must not erase recent inquiries or orders. Identify what has changed since the backup before performing any restoration. Rolling back is a decision to prepare for, not an automatic response to every issue.

Automatic update settings must be known and documented. Do not present either “everything automatic” or “everything manual” as a universal solution. The components, testing options, alerts and your availability determine how the work is organized. When a security alert arises, follow a procedure appropriate to the actual urgency and involve the necessary expertise; a monthly maintenance appointment is not a substitute for incident management.

Cybermalveillance.gouv.fr recommends applying security updates promptly. Define who receives alerts and who takes action between scheduled maintenance visits.

A website can display its homepage while its form has stopped forwarding inquiries. Build your checks around actual business use. Ask the client: what path does an important inquiry follow, who receives it and how do we know it has been handled? That conversation turns abstract monitoring into understandable tests.

For a simple business website, your sheet might contain five checks: access to essential pages, navigation on a small screen, checking that the telephone link shows the correct number without placing a call, opening the form and receipt of an agreed test message. Add booking or payment links only if they are in scope and testing is authorized. Do not make a real transaction to prove that a button exists.

Distinguish three levels of evidence: the page loads; the action can be performed; the expected result actually reaches the person responsible. A check that stops at the second level must be described that way. “Form displayed” is not the same as “inquiries received.”

Keep a small, stable set of tests rather than a long list that never gets run. After the website changes, update that set with the client. If the service only includes periodic checks, do not call it continuous monitoring. You can offer broader coverage separately, provided you have the technical and human resources to deliver it.

Avoid copying a monthly price you found elsewhere without knowing what it covers. Build your estimate from recurring work time, communication, tools attributable to the client and a capacity allowance. Separate the initial takeover, licenses, hosting and exceptional work so the client can understand each line item.

Here is an entirely fictional example, not a recommended rate or an observed income. A freelancer estimates 45 minutes a month for checks and updates, 15 minutes for reporting, then 30 minutes for communication and simple requests: 1.5 hours. At a chosen labor value of 60 euros per hour, that amounts to 90 euros. They add 12 euros in direct costs and 18 euros as a capacity allowance: the hypothetical budget reaches 120 euros per month, before applying the relevant tax treatment.

If the client’s work ultimately takes three hours, the same calculation gives 180 + 12 + 18 = 210 euros. The initial amount no longer holds up. These calculations show why time must be measured and requests bounded, not why every website should cost a particular amount. Your own model must account for your pay, contributions, leave, overheads and risk.

To consider the choice between time-based, fixed-fee and value-based pricing, supplement this approach with our guide to hourly billing in the age of AI. A tool that speeds up a task does not remove your responsibility to check its result.

The danger in a portfolio of recurring clients is simultaneous demand. Several sites may need attention at once, while you also have a website build to deliver. Calculate your capacity in available hours and actual service windows, not just the number of subscriptions sold.

In a second fictional scenario, eight clients at 1.5 hours each represent twelve planned hours a month. If two clients each need three additional hours, the total rises to eighteen hours. Setting aside exactly twelve hours therefore leaves six hours with nowhere to go. This scenario does not predict how often incidents will occur; it tests your organization before you accept another website.

Plan for absences, out-of-hours requests and an explicitly authorized stand-in provider. Another provider should not be discovering the access arrangements and context in the middle of an outage. If you have no one to cover for you, state your coverage honestly and decline commitments that assume round-the-clock availability.

When comparing website-building solutions, also consider how they are operated. A hosted service may shift some responsibilities to the provider without removing your own commitments to the client. Our website builder comparison helps distinguish the platforms; do not automatically transfer a WordPress package to a managed tool whose infrastructure you do not control.

A single channel prevents the same change from arriving by message, phone and email without shared context. This can be a dedicated email address or a tool already in use. What matters is being able to find the request, the person who approves it, its scope and its status. Do not add complicated software just to look professional.

Ask for four things: the page concerned, the expected result, what currently happens and the requested deadline with its reason. A screenshot may help if it does not reveal confidential information. Never ask for login credentials in a ticket. Separate perceived urgency from observable impact: a typo and the inability to receive any inquiries do not require the same response.

Then classify the request: included, needs clarification, outside the package or an incident to diagnose. For work outside the package, describe the additional work and wait for approval before doing it. For an incident, confirm only what you have observed. “We reproduced the error on this user journey” is more useful than a premature assurance that it will be resolved.

A good reply can be very short: “Changing the supplied text is within scope. Adding a new form requires a separate quote. Which email address should receive the inquiries?” The client then knows what is moving forward and which decision is still needed, without having to learn your technical vocabulary.

The report should help the client make their next decision. A list of updated versions may be useful as an appendix, but it does not explain the state of the service on its own. Highlight the checks performed, problems observed, actions taken and decisions needed. No incident detected does not mean no risk exists.

Use five short blocks: period covered; interventions and verified results; backups and the latest restoration test; limitations or unresolved issues; next action and owner. If a test could not be run, explain why. Do not write “everything works” when you have only checked a few pages.

Time spent communicating and making corrections must also be tracked internally. At the end of an observation period defined at the outset, compare planned and actual work by category. Repeated requests for new pages may indicate a need for editorial support, not a bad client. You can offer a separate service instead of piling up free exceptions.

Finally, keep the evidence proportionate. A dated log and a few test results are worth more than a pile of screenshots containing private information. Avoid uptime percentages if you have neither a complete measurement method nor an explained scope. The quality of a report comes from its precision, not a spectacular chart.

Start with clients whose websites and responsibilities you already understand. Offer to clarify what happens after delivery: who monitors inquiries, renews services and steps in when a change breaks a user journey? This approach addresses a need for organization without claiming the website is vulnerable or poorly maintained.

For a new prospect, stick to public facts you have actually observed. A page loading slowly on your connection does not prove a widespread outage; an old date in the footer does not prove updates are absent. Do not perform intrusive tests or explore access without authorization. Offer a conversation or a clearly defined diagnostic first, rather than a sales scare.

If your targeting involves identifying local businesses and keeping track of the next action, the SprintLead for freelancers page presents its search and sales follow-up features. Use that information to prepare your qualification process, then check the need with the business. SprintLead is not presented here as a backup, maintenance or security auditing tool.

Here is an example wording to adapt to the context and authorized channel: “Who currently handles follow-up on your website after changes are made? I offer a defined maintenance scope, with checks and a report. If that follow-up is already covered, there is no need to add another service.” The possibility of a clear no is part of a serious offer.

An ongoing service must remain transferable. Distinguish between accounts belonging to the client, the provider’s tools and licenses whose terms may restrict transfer. Document who pays for each renewal. Do not improvise these arrangements on the day the client changes agency.

Your handover pack can include the updated inventory, recent interventions, unresolved issues, how backups work and upcoming deadlines. Transfer access through an appropriate channel and only to authorized people. Agree on when your own access should be removed and how retained copies will be handled, according to the applicable obligations and agreements.

Before launching the service, run one final check: can you explain which site you have accepted, perform the promised checks, find a backup, test restoration without unwanted real-world effects, count requests and prepare a handover to another provider? An empty checkbox does not mean you have to abandon the business. It simply shows what needs to be done before you sell that commitment.

Start with a scope you can demonstrate on an authorized pilot client. Measure the time, ask the client whether the report helps them and clarify ambiguous limits. Building sustainable maintenance means making the service predictable and understandable, not accumulating monthly payments that nobody knows what they cover.