What does website maintenance include?

What does website maintenance include beyond the obvious? Most people think of content updates and broken links. That's part of it. But the real maintenance challenge sits deeper. It's the software that powers your website, and keeping it healthy, compatible, and secure takes more work than most people realise.

This is the first in a series of posts where I break down the specific maintenance tasks I deal with regularly. I'm starting with the technical stack, because it's the layer most site owners never think about, and the one most likely to cause problems when neglected.

What "technical stack" means in plain English

Your website runs on layers of software. For sites I build, that typically means PHP (the programming language), Laravel (the framework), Statamic (the CMS), and a collection of smaller packages that handle specific jobs like form processing, image handling, or search.

Each of these is maintained by a different team. Each releases updates on its own schedule. And each depends on specific versions of the others to work properly.

Think of it like a car. The engine, gearbox, electronics, and software all need to be compatible. A firmware update to one system can affect the others. Your website works the same way.

Coordinating version updates across the stack

PHP, Laravel, and Statamic all release major updates on staggered schedules. Laravel typically ships a new major version annually. Statamic follows its own timeline (Statamic Release Schedule & Support Policy). PHP has its own release cycle and eventually drops support for older versions.

A site left for 12 to 18 months without updates can end up several major versions behind across the whole stack

When one piece updates, the others need to be checked. A new version of PHP might deprecate functions that Laravel or Statamic still use. A new Laravel release might require a minimum PHP version your server doesn't run yet.

The coordination matters because you can't update one piece in isolation. Every update needs testing to confirm nothing breaks. Skip the updates for long enough and upgrading becomes a major project rather than routine maintenance.

I see this regularly. A site left for 12 to 18 months without updates can end up several major versions behind across the whole stack. At that point, you're not doing a simple update. You're doing a migration.

Managing dependencies without breaking things

Statamic uses a tool called Composer to manage its packages. Think of it as an app store for the code your website depends on. Each package handles a specific job, and your site might rely on dozens of them.

The challenge is that each package declares which versions of other packages it works with. When you update one, it might need a newer version of another, which in turn might conflict with something else your site depends on.

This is not the kind of task you want to rush on a Friday afternoon

In practice, a routine update can produce a chain reaction. Package A needs version 2 of Package B, but Package C only works with version 1 of Package B. Your site can't satisfy both requirements at the same time.

Resolving these conflicts takes experience. You need to understand what each package does, which ones can be safely updated together, and which need to wait. Getting it wrong can break your site. Getting it right takes careful, methodical work.

This is not the kind of task you want to rush on a Friday afternoon. It benefits from someone who knows the codebase and understands how the pieces fit together.

Keeping content and data in sync across environments

Most professionally maintained websites run in three environments: a local development environment where changes are tested, a staging environment that mirrors production, and the live production server where your visitors see the site.

Every site I build (check out some case studies) uses Statamic's flat-file approach, where content is managed through Git and syncs cleanly across all three environments. Depending on the project, a site might also use a database for things like user accounts, or other dynamic features.

That's where things get more involved. Unlike flat files, databases don't just sync on their own. When I update a site's software locally, test it, and deploy the changes to the live server, I need to make sure database migrations run in the right order and nothing gets overwritten or lost. Content changes made by your team on the live site need to be preserved too.

It's manageable with good processes and the right tools. But it's another reason why maintenance is a skilled task, not a box-ticking exercise.

What this means for you

You don't need to understand Composer, PHP versioning, or database migrations. That's my job. But knowing these challenges exist helps explain why website maintenance is more than clicking an update button.

A well-maintained website has its stack monitored, updated methodically, and tested after every change.

A well-maintained website has its stack monitored, updated methodically, and tested after every change. The alternative is a site that slowly drifts out of date until something breaks or a security vulnerability forces an emergency intervention.

Planned maintenance handles all of this quietly, on a regular schedule, before problems develop. If you'd like to understand what that would look like for your site, get in touch.