What Actually Happens After Your Website Launches

Launch day can feel like the finish line. The site goes live, everyone is pleased with it, the final invoice is paid and the project closes.

A website isn’t a brochure you’ve had printed, though. It’s software, running on a server, connected to the internet, built on code that other people wrote and continue to change. It needs looking after from the day it goes live until the day it’s replaced, and the businesses that discover this the hard way tend to discover it at the worst possible moment.

Looking after live websites is a core part of what we do at Hush. We host, monitor, update and support the sites we build, and a good number that we didn’t. This is what’s actually happening underneath a live website, and how we keep ours running.

Hosting: what you’re paying for

Hosting is a computer that holds your files and delivers them to anyone who asks. What you’re buying is how much of that computer is yours, and how much of it you’re sharing with everybody else.

Entry-level shared hosting puts your site alongside hundreds of others. It’s adequate for a small brochure site with modest traffic, but you’re exposed to your neighbours. If one of them takes a surge of traffic or misbehaves, your site slows down alongside it. A VPS or a managed platform gives you dedicated resources, better and more consistent speed, and someone watching when things go wrong.

The cost of getting this wrong rarely shows up on the hosting invoice. It shows up when you send an email campaign to four thousand people, they all open it within the hour, and the site struggles during the only window that mattered. Or when your busiest trading month underperforms because the server can’t keep pace.

How we do it: We match the hosting environment to what the site actually has to handle, based on traffic patterns, peak periods and whether the site is transactional. For seasonal businesses that’s a specific conversation, because the right question isn’t what the site needs in February, it’s what it needs on the busiest weekend of the year. We manage the hosting ourselves, so when performance dips there’s no three way conversation between you, us and a support queue somewhere else.

Updates: the part that can’t be skipped

A site running on a CMS such as WordPress has four things requiring regular updates: the CMS itself, the theme, the plugins, and the version of PHP everything runs on.

These are not optional improvements. They are largely fixes for problems identified since the previous release. Leave them long enough and the situation compounds, because software several versions behind often can’t be updated in a single step. It has to be moved forward in stages, and every stage carries a risk of something breaking.

The opposite approach doesn’t work either. Switching on automatic updates and hoping for the best is how contact forms quietly stop sending and layouts break on pages nobody checks. Plugins conflict with one another. A theme written against an older version stops behaving. The damage is often invisible from the homepage.

How we do it: Updates go onto a staging copy of the site first. We check the pages and forms that matter commercially, confirm nothing has shifted, and only then push the changes live. If an update does break something, it breaks on staging where it costs nothing. That testing step is the difference between maintenance and simply pressing the update button and walking away.

Security patches: not the same as updates

An update might add functionality. A patch closes a vulnerability somebody has found.

The assumption we hear most often is that nobody would bother targeting a business of this size. Nobody is targeting you specifically. Automated bots scan vast numbers of sites looking for known vulnerabilities, and they make no distinction between a national retailer and an independent business in County Durham. Once a vulnerability in a widely used plugin is published, scanning for it begins almost immediately.

That’s why timing matters more than most people expect. The large majority of compromised websites were running software with a known problem and an available fix, often published weeks or months earlier. The hole wasn’t discovered by whoever got in. It was announced publicly, and nobody applied the patch.

The real cost of a compromise is seldom the cleanup work. It’s the warning attached to your listing in Google results, the browser alert telling visitors your site is unsafe, the damage to email deliverability if your server is used to send spam, and the enquiries you don’t receive while it’s all being resolved.

How we do it: We track published vulnerabilities affecting the software our clients’ sites run on and patch on that basis, rather than waiting for the next scheduled visit. Where a fix isn’t yet available, we mitigate at server level until it is.

Backups: the question worth asking

Most people ask whether they have backups. That’s the wrong question, because the answer is usually yes and it usually isn’t sufficient.

The questions that matter are how frequently backups are taken, and whether that matches how often the site changes. An ecommerce site on daily backups can still lose a day of orders. Where they’re stored, because a backup sitting on the same server as the website will be lost alongside it. How far back the retention goes, since a compromise or a bad edit often isn’t noticed for a fortnight, by which point a rolling seven day backup is no help at all.

Then there’s the question that separates a real backup from a theoretical one, which is whether anyone has ever restored from it. Restores fail for a range of unremarkable reasons, and the moment you need one is not the moment to find out.

How we do it: Backups are held off site, separate from the server running the website, with retention long enough to cover a problem spotted late. We test restores rather than assuming them, so when a client needs a page or a database rolled back, it’s a routine job rather than an anxious one.

Monitoring: knowing before your customers do

The worst way to learn your website is down is a customer telling you. The second worst is discovering it yourself on a Monday morning, having been offline since Friday evening.

Uptime monitoring checks the site every few minutes from outside your own network, so an outage is flagged immediately. Alongside that, a few things fail silently and are worth watching closely. Contact form submissions are the main one, because a form that has stopped sending looks entirely normal from the front end and can cost months of enquiries before anybody notices. SSL certificate expiry turns a working site into a full page browser warning overnight. Error pages and broken links accumulate after content changes.

How we do it: Uptime, forms and certificates are all monitored, and the alerts come to us rather than to you. Form testing is the one we’d insist on for any site we look after. We’ve picked up websites where the enquiry form had been failing for an entire quarter, and the only symptom was a disappointing few months that everyone had put down to the market.

The things that get forgotten

• Domain renewal, which seems trivial until the payment card on file expires, the reminder goes to an address nobody checks, and the site disappears.
• SSL certificates, where they aren’t set to renew automatically.
• Third party integrations. If your site draws availability, stock or pricing from another system, the owners of that system will change how it works at some point, usually with limited notice. Somebody needs to be reading those emails and acting on them before the deadline rather than after it.
• Licence renewals for premium plugins, because once they lapse the updates stop arriving, which quietly returns you to the security problem above.

How we do it: We keep a register of renewals, licences and integration dependencies for every site we support, and we chase them. Nothing on that list should ever be the reason a website goes down.

What deferring it actually costs

The tempting alternative is to leave all of this and deal with problems as they appear and that can hold for a year or two.

What usually happens is that everything falls due at once. The site is several major versions behind, the theme has been abandoned by its developer, the PHP version is out of support and the host is pushing you to move, and the plugins won’t update cleanly. What would have been routine maintenance has become an unplanned rebuild. A good proportion of the rebuild enquiries we receive are, in practice, deferred maintenance bills.

What our support retainers include

Everything above is covered by a single monthly arrangement rather than a series of separate line items. Managed hosting matched to the site’s actual demands. CMS, theme, plugin and PHP updates tested on staging before they go live. Security monitoring with patches applied as vulnerabilities are published. Off site backups with tested restores. Uptime, form and certificate monitoring. Renewals tracked and chased.

You also get support from a full team when something goes wrong.

In short

A website is a live piece of software with a running cost attached, not a one off purchase. Maintenance isn’t something added to the end of a build to increase its value. It’s what determines whether you’re replacing the site in three years or in eight.

If you’d like us to take a look at your website and tell you where it stands, or you’d like to talk about moving it onto a monthly support retainer, get in touch.