No IT Staff: Who Looks After Your Website?

1. What tends to break first when nobody is watching

In companies with no IT staff, websites fail for a strikingly repetitive set of reasons. Very little of it involves an attacker singling you out. Components go out of date, certificates expire, disks fill up, a card on file gets declined, and nobody is watching any of it. By the time the symptoms are obvious you are usually into the most expensive kind of repair.

The most common one is plugins and themes left unpatched for a long stretch. Publicly known vulnerabilities get tried machine by machine by automated bots, and one frequent outcome is gambling or adult links injected into your pages. You will not notice. Your customers or a search engine will notice first. The second most common is an SSL certificate that lapsed without being renewed, so visitors hit a red warning page and both your rankings and your enquiries drop together.

Then there is the category that breaks silently. The server disk fills with log files or old backups, the database can no longer write, and the site shows a connection error. The backup job actually started failing six months ago, nobody was notified, and this is discovered on the day something needs restoring. Or the domain renewal notice went to a mailbox belonging to somebody who left, and the website and the company email stop working at the same moment.

The costliest version is a compromise nobody deals with. The site gets flagged as harmful by search engines, or the host suspends the account outright. At that point what needs repairing is not just the website but the rankings you have lost and the trust your customers had.

2. What "website maintenance" actually covers

The word maintenance is vague enough that an owner cannot tell whether they are being served or not. Split it into six categories and it gets clear. Each one has a concrete output, and you can take the list straight to whoever looks after your site now and ask, for each line: who does this, how often, and how would I know it had been done?

Of the six, the two most often skipped are backups and monitoring, because neither produces anything visible. When they are done well you feel nothing at all. And yet whether you can recover on the bad day depends almost entirely on those two.

3. Three common approaches, and where the risk sits

Companies without IT staff usually land on one of three arrangements: give it to whichever colleague is best with computers, leave it alone and call the original agency when something breaks, or pay a fixed monthly fee for someone to look after it. All three work for somebody. The difference is where you are willing to put the risk.

The decision comes down to one question: if the site were down for a day, how many orders, enquiries or internal working hours would you lose? Put that figure next to the monthly fee and the answer is usually obvious. A static brochure site that barely changes is fine on a call-when-it-breaks basis. If the website and the enquiries it brings in are tied directly to revenue, and a day offline hurts, a retainer almost always pays for itself.

4. What you get from a provider, and what access to give them

Before handing anything over, write down two things: what gets delivered, and what gets opened up. It saves both sides trouble later. For WordPress maintenance the deliverables are usually six items. Core, theme and plugin updates, with compatibility tested first. Two off-site backups a month. Uptime monitoring with alerting. Performance tuning. Certificate upkeep. And finding and patching the way in after an incident. Server management works at whole-machine level instead, covering system updates, security patching, uptime monitoring and the same two off-site backups a month.

On access there is one principle to hold: ownership of and billing for the hosting, domain and payment accounts stay with your company. Whoever maintains the site works through a dedicated account you issue them, rather than being handed the master password. The benefit is that you can withdraw access unilaterally at any time, without needing their cooperation to do it.

In practice that means the master accounts at the host, the domain registrar and any cloud service are registered to a company mailbox, paid on a company card, protected with two-step verification, with the passwords held by you. Your provider gets a separate working account, for example a WordPress administrator login or a sub-account on the hosting control panel, one account per person and never shared. Ask them to keep an activity log as well, or to send a short monthly report saying what was updated, whether the backups succeeded, and whether anything unusual happened.

5. Working out whether you need to outsource at all

Not every website is worth a monthly fee. A purely static single-page brochure site on a hosting platform, with no login and no database, is low risk to begin with. What genuinely needs looking after are the sites that move, that touch money, or that store customer data. Answer these five questions for yourself first.

6. What it should cost

The market range is wide, and it tracks the scope (website only, or the whole machine), the backup frequency, whether incident response is included, and how fast the response is. As a reference point, LaiSecure charges from NT$3,000 a month for WordPress maintenance and from NT$5,000 a month for server management, either fully managed with hosting included, or maintenance only on a machine you already have.

When comparing quotes, put the same questions to every provider so you are comparing like with like. Backup frequency and how many copies are kept, where they are stored, how long a restore takes, and whether restores are inside the monthly fee. How often monitoring checks, who receives the alerts, and how quickly work starts once something is found. Whether cleanup and restore after a compromise is included or billed separately. And whether the fee includes the hosting itself, since a plan with hosting bundled looks dearer until you notice there is no separate cloud bill.

7. Handover and exit: getting your things back

Plan the ending at the point you sign. Maintenance relationships change eventually, whether because you hired internal IT or because the fit was wrong. As long as you kept ownership from the start, exiting is nothing more complicated than withdrawing access.

The contract should state that on termination all website files, the database, the backups and the configuration documentation are handed over in full, in a format you can actually use, for example a file archive plus a database export. Ask for an asset inventory too, listing server specification and provider, registrar and domain expiry date, where the certificate comes from, plugin licences, domain settings and scheduled jobs. You should hold a copy of that document all along, rather than requesting it on the way out.

There is not much to do on the day itself, but nothing on the list can be missed. Disable the provider's working accounts, change the master passwords, and revoke any remote login and access keys. Finally, check that the contact addresses on the domain and hosting accounts are company mailboxes and not a former employee's.

One step people skip: before the handover, pull a full backup yourself and actually restore it, locally or onto another server. Confirming that what you received really works is what makes the handover complete.