A business website rarely fails because nobody knows how to add a page or change an image. Problems usually appear in the less visible parts of running a website: software becomes outdated, integrations stop communicating, backups exist but cannot be restored, forms silently fail, performance deteriorates, administrator accounts accumulate, tracking breaks after an update, or nobody is quite sure who is responsible when something goes wrong.
That is why website support should mean considerably more than having somebody available to make occasional content changes.
For a business that depends on its website for enquiries, sales, bookings, applications, donations or customer information, ongoing support should be treated as operational maintenance. The aim is not simply to repair problems after they appear. Good website support should reduce the likelihood of those problems occurring, identify issues before customers report them and provide a clear route to recovery when something does fail.
The UK National Cyber Security Centre recommends that organisations maintain backups, protect important accounts, apply updates and prepare for incidents. Its current guidance for small organisations also specifically identifies company websites and domain-hosting accounts as important online accounts that businesses need to secure.
So what should you actually expect from a website support arrangement?
The answer depends on the complexity of your website, but a useful support service normally covers six areas: maintenance, security, backups and recovery, monitoring, performance, and ongoing technical assistance.
Website support and website maintenance are not quite the same thing
The terms are often used interchangeably, but there is a useful distinction.
Website maintenance is mainly preventative. It includes recurring work intended to keep the website healthy: installing updates, checking backups, reviewing errors, monitoring uptime, testing important functionality and keeping the underlying software in a supported state.
Website support is broader. It includes maintenance, but also covers the assistance required when something changes or breaks. That could include investigating a failed contact form, fixing a layout problem, updating tracking, resolving an integration error, changing website content, restoring a backup, helping with hosting or diagnosing why a previously fast page has become slow.
A website can technically be “maintained” while still receiving poor support.
For example, an agency might update WordPress plugins once a month but never test your enquiry form afterwards. The website would be receiving software maintenance, but there would still be a significant business risk.
The better question therefore is not simply:
“Does this package include updates?”
It is:
“Who is responsible for making sure the website continues to perform the jobs our business needs it to perform?”
That shift in perspective changes what a sensible support agreement should contain.
Work through the guide
Known position
Document the current journey, evidence and owner before changing a live process.
Observed position
Compare the result against the question you set, and record any limits or follow-up work.
1. Software, CMS, plugin and dependency updates
Most modern websites depend on multiple software components.
A WordPress website might contain WordPress itself, a theme, dozens of plugins, analytics scripts, form software, payment integrations, APIs and hosting services. A bespoke application may depend on frameworks, libraries, packages and external services instead.
Those components change.
Updates may introduce new functionality, compatibility improvements and bug fixes, but they also frequently address security vulnerabilities. The NCSC recommends keeping systems patched and says management and maintenance plans for online services should include a regime for updating the software used to deliver them.
WordPress itself also recommends regularly maintaining and updating sites, while its documentation advises backing up the website before significant updates.
However, “automatically update everything” is not always a complete maintenance strategy.
Updates can occasionally create conflicts. A plugin may no longer work correctly with another plugin. A theme update might affect custom code. A JavaScript dependency might behave differently after a release.
For business-critical websites, the maintenance process should therefore consider both speed and control.
Security fixes may need rapid deployment, while larger updates may justify testing first on a staging environment. After important changes, key customer journeys should also be checked.
A support provider should be able to explain how updates are managed rather than simply saying that updates are “included”.
2. Backups that can actually be restored
A backup is useful only if it allows the website to be restored.
That sounds obvious, but it is one of the most important distinctions when assessing website maintenance.
Many businesses assume their hosting provider is “doing backups” without knowing what is being backed up, how frequently it happens, how long backups are retained or what would happen if the website needed to be restored immediately.
The NCSC recommends backing up business-critical information and specifically warns organisations not to rely solely on recovery mechanisms within the same cloud service. It recommends keeping an independent copy in another safe location or service.
Its wider guidance also recommends testing backups and making sure the organisation knows how to restore data before recovery becomes necessary.
For a website, a backup strategy may need to include more than files.
A typical content-management-system website can contain:
website files, the database, uploaded media, configuration information and sometimes external data or settings associated with third-party services.
WordPress documentation, for example, distinguishes between the site's files and its database and recommends maintaining recent backups in more than one location.
The appropriate backup frequency depends on how often your website changes.
A brochure website updated once a month has very different requirements from an ecommerce site receiving orders throughout the day.
If your website takes payments, receives bookings, creates user accounts or records leads, ask what would happen if the website had to be restored to yesterday's backup.
Would you lose ten minutes of data?
One hour?
Twenty-four hours?
The answer helps determine the right backup schedule.
It is also worth asking who is responsible for restoration. Some support packages include automated backups but charge separately for recovery work. That is not necessarily unreasonable, but the responsibility should be understood before an emergency occurs.
3. Security monitoring and access management
Website security is not something that can be completed once and forgotten.
The technology changes, vulnerabilities are discovered, staff leave businesses, contractors are given temporary access and new integrations are added.
Ongoing support should therefore include sensible access and security practices.
The NCSC recommends protecting important business accounts using stronger authentication and specifically includes company websites and domain-hosting accounts among the systems organisations should secure.
For administrative and maintenance access, the NCSC also recommends multi-factor authentication where possible.
This has practical implications for website support.
If five previous employees, two freelancers and an old agency still have administrator access, the website may be technically up to date while access management remains poor.
A sensible support process should periodically review who has access to:
the CMS, hosting account, domain registrar, DNS provider, CDN, analytics platforms, advertising accounts, source-code repositories and any service capable of changing the website.
Permissions should also match responsibilities.
Someone who only writes blog articles usually does not need the same level of access as the person responsible for installing software or changing payment settings.
Security support may additionally include vulnerability monitoring, suspicious activity review, firewall configuration, malware scanning or security-header checks depending on the website and hosting architecture.
The exact controls vary considerably between websites, so be cautious of maintenance packages that reduce security to a single “security plugin installed” checkbox.
Work through the guide
Set the guardrails first
Turn on the controls you need to consider. This does not change your systems.
No safeguards selected yet.
4. Uptime and availability monitoring
Your website can stop working at 2:00am just as easily as it can at 2:00pm.
If nobody monitors it, the first indication may be a customer sending an email asking why the website is unavailable.
Uptime monitoring periodically checks whether the website or important endpoints can be reached. More advanced monitoring may also identify server errors, SSL certificate issues, unusually slow responses or failures in important application services.
However, there is an important difference between monitoring and response.
A monitoring system can send an alert within minutes.
That does not necessarily mean somebody is contracted to investigate the problem within minutes.
This is where response expectations become important.
For a small informational website, resolving a non-critical issue during normal working hours may be perfectly acceptable. An ecommerce store or booking system losing transactions may require much faster escalation.
A support agreement should therefore make clear what is monitored, when alerts are reviewed, what counts as an urgent issue and what response arrangements exist outside normal hours.
5. Contact forms, bookings, payments and other critical journeys
One of the most damaging website problems is a failure that leaves the website looking completely normal.
Imagine a contact form that displays a successful submission message but no longer sends the enquiry into the CRM.
Customers think they have contacted you.
Your marketing team sees traffic.
Your website remains online.
But leads disappear.
The same problem can affect booking systems, payment gateways, newsletter forms, quote calculators, account-registration systems and external APIs.
Traditional uptime monitoring may not detect this because the website itself is technically available.
Good support therefore requires some attention to functional monitoring.
That might involve scheduled checks of important forms, reviewing application logs, monitoring API errors or testing conversion journeys after updates.
The more commercially important the website function, the more important this becomes.
A business generating most of its leads through three website forms should treat those forms as operational systems, not merely page elements.
6. Performance and Core Web Vitals
Website speed is another area where performance gradually deteriorates rather than suddenly “breaking”.
New scripts are added.
Marketing teams install more tracking.
Images become larger.
Plugins accumulate.
A redesigned component loads another JavaScript library.
Third-party widgets appear.
Eventually the website feels slower than it did when originally launched.
Performance monitoring should therefore be part of website maintenance, particularly for sites where organic search, paid advertising or conversion rate matters.
Google recommends that site owners provide a good overall page experience and says Core Web Vitals are used by its ranking systems, while also cautioning that good scores alone do not guarantee strong rankings.
That distinction is important.
Website maintenance should not become an endless exercise in chasing a perfect performance score.
The goal is to keep the site reasonably fast and usable for real visitors while identifying technical regressions that can affect experience and conversion.
Useful monitoring may include Core Web Vitals, page-load behaviour, large images, JavaScript execution, caching, server response time and unusually heavy third-party scripts.
More importantly, performance should be reassessed after significant changes.
A website that achieved good performance six months ago may not still achieve it today.
7. Hosting, SSL, DNS and domain oversight
Businesses often think of the website as one system, but several independent services may be required to keep it online.
These can include:
the domain registrar, DNS provider, web host, CDN, SSL certificate, email provider and application hosting platform.
A failure or configuration mistake in any of these areas can cause website downtime.
This creates an important support question:
Who actually owns each account?
The business should ideally retain appropriate ownership and visibility rather than having essential infrastructure registered entirely under a supplier's personal account.
You should know where your domain is registered, how DNS is managed, where the website is hosted and who can access those systems.
This becomes especially important when changing agencies.
A support provider should not create avoidable dependency by making it difficult for the business to regain control of its own infrastructure.
Good support is partly about technical maintenance and partly about maintaining clear operational ownership.
8. Website fixes and troubleshooting
Even well-maintained websites develop issues.
Browsers change.
Devices change.
External APIs change.
Plugins change.
Hosting environments change.
Users find edge cases nobody anticipated.
Website support should therefore include a defined way of reporting and resolving problems.
The key question is how support requests are prioritised.
A spelling correction on an About page is not equivalent to an ecommerce checkout failure.
A sensible process distinguishes between critical operational problems and routine tasks.
It should also identify whether development work is included in the support allowance or quoted separately.
For example, repairing a form that stopped working may reasonably fall within maintenance. Building an entirely new booking system probably does not.
Ambiguous support packages frequently cause disagreements because phrases such as “unlimited website support” sound broader than they actually are.
Clear scope is generally preferable to unlimited-sounding language.
9. Content and website changes
Website support often includes a certain amount of ongoing content work.
That could involve updating text, replacing images, publishing articles, creating landing pages or changing team information.
Whether this should be included depends on the organisation.
Some businesses have an internal marketing team comfortable working in their CMS and only need technical support.
Others prefer one provider to handle both.
What matters is separating content support from technical maintenance.
If a package includes five hours per month, you should understand whether installing security updates consumes the same allowance used for adding new pages.
Otherwise a maintenance package can appear generous until routine upkeep consumes most of the available time.
10. Analytics and conversion tracking checks
Your website can remain visually perfect while its measurement becomes inaccurate.
A redesigned form can stop firing a conversion event.
A cookie-consent change can alter tracking behaviour.
A developer can replace a button and accidentally remove a Google Tag Manager trigger.
A payment provider can change the way users return to the website.
These are website-support issues because changes to the website frequently affect analytics.
Not every maintenance provider needs to manage your entire analytics strategy, but support arrangements should at least define who is responsible for checking measurement after significant website changes.
For businesses spending money on Google Ads, Meta Ads or other acquisition channels, broken conversion tracking can influence much more than reporting. Automated advertising systems increasingly depend on conversion signals when optimising campaigns.
The cost of a tracking problem can therefore extend well beyond the website itself.
Work through the guide
Map the moving parts
Tap a point to see the question it raises.
Select a point in the route.
11. SEO checks after technical changes
Routine website work can also create search problems.
A developer can accidentally apply a noindex directive.
A staging configuration can reach production.
A redirect can disappear.
A canonical can point to the wrong page.
Navigation changes can remove important internal links.
An old URL can return a 404 after a page is renamed.
Website maintenance and SEO are therefore connected.
A maintenance service does not necessarily need to provide full SEO management, but technically significant changes should consider their effect on crawlability, indexing, redirects, metadata and internal links.
This is particularly important during redesigns, migrations and major CMS changes.
12. Staging, testing and controlled deployment
Businesses sometimes imagine website maintenance as a choice between “make the change” and “don't make the change”.
A better process often contains a middle step: test the change somewhere safe before releasing it.
A staging environment is a non-public version of the website used for development and testing.
It can be especially valuable when making significant software updates, changing integrations, modifying checkout behaviour or deploying custom development.
Not every tiny website requires an elaborate deployment pipeline. But business-critical sites benefit from separating experimentation from production.
A support provider should be able to explain how risky changes are tested and how the previous version can be restored if deployment causes a problem.
13. A documented recovery process
Backups answer the question:
“Do we have a previous copy?”
A recovery plan answers:
“What exactly do we do now?”
The distinction becomes obvious during a serious incident.
Suppose a website is compromised on Monday morning.
Who has authority to take it offline?
Who contacts the hosting provider?
Which backup is considered safe?
Are DNS credentials available?
Who can reset administrator accounts?
Where are recovery codes stored?
How will customers be informed if necessary?
The NCSC's incident guidance recommends preparing before an incident and ensuring that relevant people know how to restore from backups.
Even a small business should have a basic answer to these questions.
The recovery document does not need to become a hundred-page disaster-recovery manual. A concise record of systems, owners, credentials, escalation routes and restoration steps can make a major difference when something goes wrong.
14. Reporting that explains what was actually done
A monthly maintenance report should tell you more than:
“Everything updated successfully.”
Useful reporting might identify software that was updated, backups completed, security issues found, uptime incidents, performance problems, unresolved technical risks and recommended future work.
This creates accountability.
It also allows technical maintenance to feed into business planning.
For example, if a plugin causes repeated compatibility problems, replacing it may be more sensible than continuing to repair it.
If the website regularly approaches hosting limits, infrastructure may need to change.
If forms frequently attract spam despite repeated fixes, the underlying approach may need reviewing.
Good support does not simply close tickets. It identifies patterns.
What should you ask a website support provider?
Before agreeing to ongoing website support, ask enough questions to understand exactly what happens both during normal operation and when something goes wrong.
A useful checklist is:
- Which parts of our website and infrastructure are included in the support scope?
- How frequently are CMS, plugin, framework or dependency updates reviewed?
- Are updates tested before or after deployment?
- What is backed up, how frequently, and how long are backups retained?
- Are backups stored independently from the live website?
- When was the restoration process last tested?
- Is uptime monitoring included?
- Are critical forms, payments, bookings or integrations monitored?
- Who receives monitoring alerts?
- What response applies to critical incidents?
- Is multi-factor authentication required for administrator access?
- Are old administrator accounts periodically reviewed?
- Does support include malware, vulnerability or suspicious-activity monitoring?
- Are performance and Core Web Vitals reviewed?
- Who is responsible for analytics and conversion tracking after website changes?
- Are redirects and technical SEO implications checked during structural changes?
- Is a staging environment available for risky updates?
- Is content work included, and does it use the same allowance as maintenance?
- Who owns the hosting, domain, DNS and other important accounts?
- What happens if we decide to change support providers?
The objective is not to find a provider that answers “yes” to everything.
Different websites need different levels of service.
The objective is to remove uncertainty.
Work through the guide
Ask before acting
Open only the question you need.
Is the information current?
NCSC: small organisations guide to cyber security
Does it change a real journey?
List the systems that can affect the live website, including hosting, domain, DNS, CMS, forms and analytics.
What is a safe first test?
Identify the journeys that would cause business harm if they silently failed.
How much website support does a small business actually need?
There is no universal maintenance package that works for every business.
A five-page brochure website with no integrations can require very little ongoing intervention.
A website connected to advertising campaigns, CRM software, booking systems, payments, customer accounts and external APIs is operationally different even if the number of pages is similar.
The right support level is better determined by business dependency than by website size.
Consider what would happen if the website stopped working tomorrow.
If the main consequence would be inconvenience, basic scheduled maintenance may be sufficient.
If the business would immediately lose leads, revenue, bookings or customer access, stronger monitoring and faster support become easier to justify.
Similarly, consider how frequently data changes.
An informational website may tolerate restoration from a relatively old backup.
An ecommerce store receiving orders continuously may not.
Website support should therefore be proportionate to the commercial impact of failure.
Preventative support usually costs less than emergency recovery
Website maintenance can feel optional when everything is working.
That perception often changes immediately after a failure.
Emergency technical work is difficult because the priority is restoring service rather than choosing the most efficient long-term solution.
The business may also lose enquiries or sales while the website is unavailable.
Staff may need to stop normal work.
Advertising campaigns may continue sending paid traffic towards broken pages.
Customers may encounter errors.
Preventative maintenance cannot eliminate every failure, but it can reduce avoidable ones.
Keeping software supported, maintaining tested backups, reviewing administrator access, monitoring critical functionality and identifying performance problems early all improve resilience.
This is why website support is best viewed as risk management rather than a collection of small technical tasks.
Cheap website maintenance can become expensive when responsibilities are unclear
Price comparisons between support packages are difficult because providers may include very different things under the same label.
One £50-per-month package might provide automated updates and an automated backup.
Another service might include manual testing, performance monitoring, security review, form checks, developer support and incident response.
The second service is not simply an expensive version of the first.
It is a different service.
Businesses should therefore compare scope and responsibility, not just monthly price.
Ask what the provider actively checks.
Ask what is automated.
Ask what happens when automation reports a failure.
Ask what happens after a plugin update breaks the site.
Ask whether restoring a backup is included.
Ask how quickly somebody will respond when your main enquiry form stops working.
Those answers are usually more informative than a list of twenty features on a pricing page.
Website support should evolve with the website
The support arrangement you needed two years ago may no longer be appropriate.
Perhaps the website originally existed mainly to provide information.
Now it generates leads through Google Ads.
Perhaps you have added HubSpot, ecommerce, online booking, an AI chatbot or a customer portal.
Every additional system introduces dependencies.
That does not mean businesses should avoid integrations. Integrations can create substantial operational value.
It means support needs to reflect the website you have today rather than the website that originally launched.
A useful maintenance review should periodically ask:
What has changed?
Which functions are now business-critical?
Which third parties does the website depend on?
Who owns those systems?
How would we know if one stopped working?
How would we recover?
Those questions become increasingly important as websites shift from digital brochures into connected business systems.
The difference between reactive and proactive website support
Reactive website support waits for somebody to notice a problem.
Proactive support tries to identify predictable risks before they become customer-facing incidents.
Both are necessary.
There will always be unexpected problems that require investigation.
But if every support interaction begins with somebody inside the business saying “a customer told us the website is broken”, monitoring is probably insufficient.
Proactive support typically includes recurring maintenance, backups, access review, monitoring, technical testing and recommendations.
Reactive support then provides a safety net for problems that still occur.
Together, they create a more reliable operating model.
What good website support should ultimately provide
The purpose of website maintenance is not to generate reports about plugin versions.
It is to help keep the website available, secure, recoverable and useful to the organisation.
For most business websites, that means having clear responsibility for software maintenance, reliable backups, recovery procedures, protected administrator accounts, monitoring, performance, technical fixes and critical customer journeys.
More complex websites may also need deployment processes, application monitoring, integration monitoring, security testing, analytics support and closer response arrangements.
The correct level depends on risk.
But every business should be able to answer four basic questions:
Who is responsible for the website?
How do we know when something is wrong?
Who fixes it?
How do we recover if the fix is not enough?
If those answers are unclear, there is probably a gap in your website-support arrangement.
For businesses that rely on their website for leads, enquiries, bookings or sales, ongoing maintenance should therefore be treated as part of operating the website rather than an optional extra added after launch.
London Digital Works provides ongoing website maintenance and technical support covering updates, fixes, performance, backups and continuing website improvements. If your current arrangement is unclear, reactive or spread across several suppliers, reviewing ownership and support responsibilities can be a useful starting point.
Sources
Primary and authoritative guidance
National Cyber Security Centre — Small organisations guide to cyber security. NCSC small organisations cyber security guidance
National Cyber Security Centre — Secure your important online accounts. NCSC account security guidance
National Cyber Security Centre — Back up your organisation's critical data. NCSC backup guidance
National Cyber Security Centre — Building and operating a secure online service. NCSC secure online service guidance
WordPress.org — WordPress site maintenance. WordPress maintenance documentation
WordPress.org — Backups. WordPress backup documentation
Google Search Central — Understanding page experience in Google Search results. Google page experience guidance
Relevant service
Need help applying this to your own setup?
Our web application development service can help you review the current position, decide what is proportionate and plan a clearly scoped next step.
Explore Web application development