Process 6 min read

Website maintenance: what actually needs doing, and how often

A real maintenance schedule — weekly, monthly, quarterly and yearly — what happens to a neglected site, and the two jobs everybody skips.

Written by Soumitra GhoshFounder & Lead Developer

A terminal listing projects and which of them are out of date.
On this page
  1. What actually happens to a neglected site
  2. A real schedule
  3. The two everybody skips
  4. Testing the restore
  5. Submitting your own contact form
  6. Updating without breaking things
  7. If you have already neglected it
  8. Does every platform need this?
  9. Do it yourself or pay somebody

A website is not a brochure you print once. It is software, connected to the internet, depending on half a dozen other pieces of software that keep changing underneath it.

Left alone it does not stay still. It degrades quietly, and the first visible symptom is usually something bad.

What actually happens to a neglected site

Not all at once. Roughly in this order.

  • Months 1–6. Nothing visible at all. Updates accumulate. Some of them are security fixes for holes that are now publicly documented, which is the part people miss — a published fix is also a published description of the weakness.
  • Months 6–12. Small breakages. A form stops sending. A layout goes wrong in a browser that updated. Nobody tells you, because the people affected simply leave.
  • Year 1–2. Updates can no longer be applied safely one at a time, because too much has changed at once. The host starts warning about an unsupported PHP version. Every change now carries risk.
  • Year 2 onwards. Something gets compromised, or an update is forced and breaks the site, and the catch-up costs more than two years of maintenance would have.

Compromised sites are rarely targeted. Automated scanners work through known vulnerabilities across millions of sites. Being small is not protection — it just means nobody chose you personally, and the bots do not care either way.

A real schedule

How oftenWhatWhy
ContinuouslyUptime monitoringYou should find out before a customer does
ContinuouslyOff-site backupsA backup on the same server is not a backup
WeeklyApply updates, then check the site still worksThe checking is the part people skip
WeeklySubmit the contact form yourselfSilent form failures are depressingly common
MonthlyTest restoring a backupAn untested backup is a hope, not a plan
MonthlyCheck Search Console for errorsBroken pages and indexing problems surface here first
MonthlyReview user accountsOld logins from people who left are a standing risk
QuarterlyPerformance check on a real phoneSites get slower by accretion, never all at once
QuarterlyRemove plugins nobody usesEvery one is a door; unused doors should be closed
QuarterlyFix broken linksOther people’s sites move without telling you
YearlyConfirm domain renewal and ownershipThe one failure you genuinely cannot undo
YearlyReview content for accuracyPrices, people, services, the copyright year
YearlyCheck the PHP version is still supportedHosts drop old versions with limited notice
YearlyRenew licences for premium pluginsA lapsed licence stops the security updates

The two everybody skips

Testing the restore

Plenty of businesses discover their backups have been failing silently for eight months at precisely the moment they need one. A backup you have never restored is a belief, not a safeguard.

Restoring to a staging site once a quarter takes twenty minutes and converts the belief into a fact. It also tells you how long a real restore would take, which is worth knowing before the day you need it.

Submitting your own contact form

Forms break for reasons that have nothing to do with the form. A mail setting changes. A spam filter gets more aggressive. A plugin update alters a redirect. A caching layer serves a page with a security token that has since expired.

Enquiries then vanish with no error message anywhere, and the first you know is a customer asking why you never replied — or, far more often, nothing at all, because they went elsewhere.

Send yourself a test every week. It takes ten seconds, and it has saved more businesses more money than anything else on this page.

Updating without breaking things

The reason people avoid updates is that updates sometimes break sites. The answer is not to avoid them — it is to make breaking safe and cheap.

  • Back up immediately before, every time, without exception
  • Apply significant updates on a staging copy first
  • Update in small batches, so you know what caused a problem
  • Afterwards check the homepage, a content page and the contact form
  • Never update on a Friday afternoon

That last one is not a joke. The cost of a broken site is mostly the time it stays broken.

If you have already neglected it

Most sites we are asked to take on are somewhere in that timeline already, and the instinct is to update everything at once on a Monday morning. Do not. A site that has not been touched in two years is one where several things will break, and doing them together means you will not know which did what.

The order that works:

  • Take a full backup and verify you can restore it. Before touching anything. If this step fails, stop — you have found the most urgent problem.
  • Copy the site to a staging environment and do everything there first. Most hosts provide this free.
  • Delete what is not used before updating it. There is no point carefully updating a plugin nobody has opened since 2021.
  • Update the platform core first, then plugins in small batches, checking the site between each.
  • Deal with PHP last, once everything else is current, because old plugins are usually what blocks a newer PHP version.
  • Then go live, and check the contact form before you tell anyone you are done.

Budget real time for this. A two-year catch-up is a day’s work if it goes well and considerably more if a plugin has been abandoned and needs replacing — which is the usual reason these jobs overrun.

Does every platform need this?

Less so on hosted platforms. Squarespace, Webflow and Framer handle their own updates, security and hosting — that is a large part of what the subscription buys, and a perfectly good reason to choose one.

You still need to check forms, fix links, keep content current, review who has access and own your domain. The list gets shorter; it does not disappear.

Self-hosted platforms like WordPress trade that convenience for control. Both are reasonable — the difference is simply where the work sits, and it is one of the real deciding factors in four platforms, honestly compared.

Do it yourself or pay somebody

Either is fine. What does not work is assuming it is happening when nobody has been asked to do it — which is, by a distance, the most common arrangement we find when a new client’s site arrives in a bad state.

Put a name against it. If that name is ours, this is what our maintenance work covers. If it is yours, the table above is the whole job — print it and work down it.

Written by

Soumitra Ghosh Founder & Lead Developer

UitoCode is run by Soumitra Ghosh, a frontend developer and UI/UX designer with 5+ years of experience building websites for startups and growing businesses.

Let’s talk

Have a website project in mind?

Tell us what you’re building and what it has to achieve. You’ll get a straight answer on whether WordPress or Webflow fits, and what it would take to do it properly.

What happens next

  1. Send a short brief through the contact form
  2. Hear back personally within two working days
  3. Get a written proposal with scope, timeline and cost