Keeping your hosting up to date: who updates what, and what happens when nobody does

The six pieces of a hosting setup: the updated ones and the ones left behind

"Keeping your hosting up to date" sounds like one thing. It is six, each with a different owner. That is why, in practice, one of them always gets forgotten: nobody decided to neglect it, everyone assumed it belonged to somebody else.

It is worth laying the pieces out and saying who holds each one.

The six pieces, and whose they are

WhatWho updates it
Server operating systemThe provider
Web server and its modulesThe provider
Available PHP versionThe provider offers it, you choose it
DatabaseThe provider
CMS, theme, pluginsYou, or whoever looks after the site
SSL certificateThe provider, if it is the included one

The first two rows and the fourth are work you never see and should not have to remember: it happens underneath, and when it goes well you do not notice. There is a page on how our infrastructure is built if the detail interests you.

The fifth row is the one that gets forgotten, and it is also the only one we cannot do for you. Updating a plugin can change how a page looks or how a form behaves: that is a decision about your site, not about the server.

Security: the window that matters

When a flaw is found in widely used software, the problem does not begin when the fix ships. It begins when the flaw becomes public — and days pass between the two.

During those days the automated attacks are already running. They do not choose victims: they sweep the internet looking for installations exposing that version, and they take what they find. This is why "my site is small, who would attack me" is the wrong question, as we covered when writing about what happens when the site next to yours is compromised.

That window can be worked on from two sides, and you want both.

From the server side: when a vulnerability has not been patched yet, we apply a WAF rule straight away that blocks the threat regardless. The site is not updated, but the attack does not land.

From your side: update what lives in your space, and remove what you do not use. A deactivated but still installed plugin is a file that can be reached. The most effective way not to update something is not to have it.

Performance: where the gain actually is

Updates bring speed, but not all of them in the same measure, and it helps to know where to look.

The big jump comes from the PHP version. Between an old release and the current one the difference on a dynamic site is measurable, and it is not marginal. On our servers the default is the latest stable version available, and you can change it from the panel.

The second gain comes from caching, which is configuration rather than an update: on our plans it is on by default for static assets and for PHP output, and sites that query the database heavily can switch on Memcached or Redis from the add-ons.

The third, the one nobody talks about, is removing things. A site with forty plugins is not slow because of the server. If you have a WordPress database that has grown over the years, clearing it out pays better than any update.

SEO: what hosting has to do with it, and how far

Here it pays to be precise, because this is the subject people over-promise on.

Google measures how a page loads, and part of that measurement depends on the server: the time before the first response arrives feeds directly into the moment the main content becomes visible. A slow server puts a delay underneath everything else, and no amount of page optimisation gets it back.

But it stops there. Layout stability and responsiveness to input depend on how the page is built, not on where it is hosted. And ranking depends first of all on what the page says.

In short: slow hosting can hold back a good site; fast hosting does not lift an empty one. Anyone promising otherwise is selling something else.

What you can do, in practice

Five things, in order of payoff.

  1. Keep the CMS and plugins current, and test on a copy first. There is no clever way around it. There is a careful way to do it.
  2. Remove what you do not use. Themes never activated, plugins tried and abandoned, old installations in forgotten subfolders: all of it is exposed surface you have no use for.
  3. Move to the latest PHP version, without rushing. Try it, look at the site, and if a plugin is not ready go back from the panel. It is reversible.
  4. Check that somebody is watching. A site that goes down at night and comes back at eight is a site nobody is monitoring. Monitoring exists so you hear it before your customer does.
  5. Know where the backups are and how fast they restore. The serious question is not "will it happen", it is "how long until I am back". On ICBS plans the full backup is daily.

A note on how we put this

None of these points is exclusive to us, and we do not present them that way: a patched system, caching, backups and monitoring are what a serious host has to do. The difference is that they are written down and checkable, not that they sound special.

That is why what is included and what is not sits on a page of its own, with the conditions spelled out. If you are weighing up a provider — us or anyone else — that is the kind of page worth looking for before you sign.

Frequently asked questions

The operating system, the web server, PHP and the database are ours to keep current: they are part of the service. What stays yours is what lives inside your web space — the CMS, the theme, the plugins — because updating those can change how your site looks or behaves, and that decision is not ours to make for you.
It can, with an old plugin or with custom code written years ago. That is why the PHP version is changed from the panel and the change is reversible: you try it, and if something is off you go back in the same place. The advice is to try it on a copy before the live site.
Not that somebody targets you: that a bot finds you. When a flaw becomes public, automated attacks start within hours and sweep the internet without choosing victims. The stale plugin is the door; your site is just the address that came up.
Part of it, yes, but let us be precise: the server decides how long it takes for the first response to arrive, and that time feeds one of the metrics Google measures. Content, structure and links matter more. Fast hosting does not lift a site that has nothing to say.
No. The included certificate renews itself before it expires. If you use your own certificate, uploaded by hand, that one stays your deadline to watch — and it is the most common reason a site greets visitors with the browser warning.
Ask, and ask for answers with dates in them: which PHP version is available today, how often system patches are applied, what happens between a flaw being found and the fix shipping. A provider who answers those three precisely has already told you a lot.