Website Maintenance & Support Services

Website maintenance is the work that keeps a site safe, available and recoverable after the launch applause has faded: updates, tested backups, someone watching uptime, and a clear path for the small fixes that show up every month. A site that made money on day one becomes a liability the quarter nobody patched a plugin, the disk filled up, or the only backup turned out to be a copy of an already broken database.

At CodeWiz we look after WordPress and WooCommerce sites, Laravel and other PHP applications, and Node.js services. We update cores, plugins and dependencies on a staging copy first, keep backups that we have actually restored, watch uptime and the obvious security signals, and fix bugs that are too small for a project and too important to leave in a ticket for six months. The scope is written down before the first update, including what is not included.

This is for businesses whose site takes orders, bookings or leads and has no one whose job is to watch it, for agencies that would rather not be the on-call person for every client install, and for anyone who inherited a site and is no longer sure when it was last updated. If the last change was a hurried plugin update straight on production, maintenance is the cheaper conversation to have before the next one.

Website Maintenance: Core, Plugin and Dependency Updates

Most incidents we get called for start as a skipped update. WordPress core, a WooCommerce release, a PHP version, a Composer package or an npm dependency sits still until a security release makes the update urgent and untested. Website maintenance turns that into a rhythm: a staging copy, a short checklist of the paths that matter, then production, with a way back.

What gets updated

• WordPress: core, plugins, themes and translations. Premium plugins are included when you can give us a licence key. We read the changelog for anything that touches checkout, login or custom code.
• PHP, Node.js and system packages: language runtimes and security updates of the operating system, coordinated with the application so a PHP bump does not land on the same afternoon as a major plugin.
• Composer and npm: lockfiles updated in Git, with composer audit and npm audit in the loop. A dependency update is a commit, not a folder someone edited over SFTP.
• The platform around the app: the web server, TLS, Redis or the database version, when the hosting setup is in our hands.

Staging is not optional for a site that takes payment or leads. We click through checkout, login, forms and one or two pages that use the plugins just updated. Visual oddities and PHP warnings get fixed before production sees the change. Major version jumps are scheduled, not batched in with a quiet security patch. WordPress documents the mechanics in Updating WordPress; the judgement about what to update this week is the part we add.

JavaScript dependencies deserve extra suspicion. A malicious or hijacked package does not look like a normal bug, which is why we have written separately about protecting a development environment from malicious npm packages. Production installs come from a lockfile, not from whatever npm install resolves on the day.

Backups and Disaster Recovery

A backup is a restore you have done, not a file you hope is valid. We back up the database, uploaded files and the configuration that would be painful to recreate, send copies off the server, and restore them on a schedule we agree. A panel snapshot of the whole machine can be part of that. It is not a substitute for a database dump you can load somewhere else, because a snapshot often dies with the same disk or the same account.

• What “recovered” means is agreed up front. How much recent data you can afford to lose, and how quickly the site has to answer again, changes the design. We write those two numbers down with you. We do not invent a universal promise.
• Shops include orders. A file backup that misses the database, or a database backup that misses uploads/, is not a recovery. For stores, the thinking overlaps with how we treat orders that have to stay recoverable.
• Restores are rehearsed. The first time you discover a backup is truncated should not be the day the server is gone. A restore to staging is the test.
• Access is limited. Backup credentials are not the same keys as the deploy user, and the backup store is not world-readable.

Uptime and Security Monitoring

Updates close the holes you already know about. Monitoring tells you when something is wrong anyway: the site does not answer, the certificate is about to expire, a login is failing in a pattern that looks like guessing, or a file changed that nobody was supposed to change. Uptime is checked from outside the server. A check that runs on the machine itself stays silent on the day that machine is the problem.

For a small site that check can be deliberately small. We have described one approach in a self-hosted uptime monitor, an open-source Node.js alternative for when a commercial status page is more product than you need. Alongside it we watch certificate expiry, disk space, failed admin logins and the list of components that are behind on security releases. Hardening the WordPress install itself follows the practices in the official hardening guide: fewer admin users, no unused plugins, and files that the web server is not allowed to write except where uploads belong.

Bug Fixes and Small Improvements

Between updates, sites accumulate small defects: a form that stopped emailing, a button that overlaps on a phone, a shipping rate that rounds the wrong way, a plugin setting that an editor changed by accident. Bug fixes and small improvements are the reason a maintenance arrangement is more useful than a calendar reminder to click “update”.

• We agree an hour budget, or a short list of included tasks, so “small” does not silently become a new feature.
• A broken checkout, a broken form or an error that visitors see is in scope even when the hour budget is tight. A redesign of the homepage is not.
• Each fix is small enough to review and to reverse. Changes land in Git when the site has a repository, which is the first thing we add if it does not.
• You get a short note of what changed, not a silent edit on production.

Support Plans and SLAs

A support plan is a written scope: what we update, how often we restore a backup as a test, what we watch, how small fixes are counted, and how fast we respond when something is down. An SLA here means that response window and the definition of “down”, agreed for your site. It is not a published price list and it is not a universal uptime percentage we paste onto every brochure site.

Response and resolution are different. Responding means a person has looked and told you what they see. Resolving a compromised site or a failed host can take longer than the first reply, and we will say so rather than promise a clock time we do not control. Business hours are the default. A tighter window is something we agree when the site earns money outside those hours, and it is written into the plan.

What Sits Outside a Maintenance Plan

Maintenance keeps the site you have in good condition. It is a poor container for a new product. The following stay separate projects, quoted on their own, unless we have explicitly pulled a small piece into the hour budget:

• New pages, new integrations, a redesign, or a feature that did not exist last month.
• A move to a new host, a PHP upgrade across a major version, or a replatform. Those can be scheduled alongside maintenance, but they are not “the monthly update”.
• Writing your content, running ads, or answering your customers. We will fix the form. We will not pretend to be your inbox.
• An outage whose cause is a third party, a registrar or a payment provider. We still diagnose it and tell you where it stopped being your server.

Common Website Maintenance Mistakes We Fix

• Updating production directly, on a Friday, with no copy to roll back to.
• Automatic updates switched on for every plugin, including major versions that change database tables.
• A backup that has never been restored, stored on the same disk as the site.
• No external uptime check, so the first report is a customer.
• An admin user still named admin, unused plugins left active, and a theme from 2019 that cannot take a current PHP.
• “Unlimited small changes” with no boundary, until maintenance has become an unscoped development contract.
• Dependencies updated on the server by hand, so the Git repository no longer matches what is running.

What Affects the Cost of Website Maintenance

We price after looking at the site, not from a grid in a PDF. The factors are stable:

• How many sites, and whether each has staging or we have to create it.
• WooCommerce, custom plugins and old PHP cost more attention than a quiet brochure site.
• How far behind the site is on day one. A catch-up of two years of updates is a project. The monthly rhythm after that is smaller.
• The response window you actually need, and whether someone must be reachable outside business hours.
• Whether backups, uptime and the server are in scope, or only the application.
• A single site on a sensible host is often the whole story. Where the hosting itself is the expensive part, an open-source hosting panel is sometimes the larger saving, and we will tell you if maintenance alone is not the point.

How We Work

1. Audit: versions, plugins, access, where backups go today, and the last time anything was updated or restored.
2. Agree: scope, hour budget, response window, and the list of paths we test after an update.
3. Make it safe to touch: staging, an off-site backup, a successful restore test, and an uptime check, before the first production change.
4. First cycle: updates on staging, fixes, then production in a window you know about, with a rollback ready.
5. Rhythm: the agreed cadence after that, plus a short note of what changed and what we are watching.
6. Stay: the plan continues until you stop it. Larger work is quoted beside it, not hidden inside it.

Why CodeWiz

• We build the sites we maintain: WordPress, WooCommerce, Laravel and Node.js, so an update is judged by someone who can read the error, not only by someone who can click the button.
• Open-source first: staging, restic or equivalent backups, and a self-hosted uptime check before a bundle of proprietary agents.
• Written boundaries: included fixes and separate projects are distinguished before the work, which is how a plan stays fair to both sides.
• Fair pricing: premium development without premium prices, from Banja Luka, working remotely with clients locally and internationally.
• The surrounding work is already ours: hosting, performance, security and the application. More on the about CodeWiz page.

Frequently Asked Questions

How much does website maintenance cost?

It follows the site. A small WordPress site with monthly updates, daily backups and an uptime check is a modest retainer. A shop on old plugins, with a same-day response window, is not the same engagement. You get a scope and a price after the audit, before anything is changed.

What is included?

The plan lists it: which updates, how backups are tested, what is monitored, how many hours of small fixes are included, and how we respond when the site is down. New features are quoted separately. The table above is the shape of that conversation, not a menu with hidden lines.

How often should WordPress be updated?

Security releases should not wait for a quarterly cleanup. Feature releases can wait until they have been tried on staging, which for an active site usually means a monthly pass plus anything urgent in between. Automatic major updates on production are how quiet sites get broken.

Can you maintain a site you did not build?

Yes. The audit is there to find out what we are taking on: custom code, licences, the host, and whether a staging site exists. If the site is in a state where maintenance would only paper over a rebuild, we will say that.

What if an update breaks the site?

That is why staging and a tested backup exist. We roll back the change or restore the last good copy, then work out the conflict on staging. Production is not where a major plugin is debugged.

How fast do you respond?

As fast as the plan says. A brochure site is usually next business hours. A shop that cannot take orders is a different agreement, written down, with a response window rather than a guess. Response means we have looked and replied. It is not a promise that every possible failure is fixed in that same window.

Ready to Stop Treating Updates as an Emergency?

Tell us what the site runs and when it was last updated or restored. Contact us and we will propose a maintenance scope, or browse the rest of our services.