Website maintenance: so that your site runs reliably

An update can close a gap or break something. Anyone who updates live sites blindly risks outages. A clean procedure turns the risk into routine.

1. Back up. Before every update, take a current backup of files and database, stored in a separate place.
2. Read the changes. Look at the notes on the update: a security fix, a new feature, a change that requires adjustments?
3. Use a test copy. Apply the update to a copy of the site (staging) first, not to the live site.
4. Check the key functions. Home page, menu, form, shop order, login, search, pages with special functions.
5. Go live. At a quiet time, not shortly before a campaign and not on a Friday late afternoon.
6. Check afterwards. Test the same functions again and look at the error log.
7. Keep a way back ready. If something breaks, it is clear how the previous version can be restored quickly, depending on the case.
8. Document. What was updated when, and from which version to which? This helps with troubleshooting later.

Large version jumps (a new major version of the system, a change of PHP version) need more lead time. They are planned as a small project of their own, with a test phase and a plan for the way back.

Most attacks are not targeted attacks but automated attempts. Programs scan the internet for known weaknesses and try out widely used login credentials. Anyone who closes the standard gaps is no longer a worthwhile target for the great majority of these attempts.

What you can do straight away

• Every person has their own account with only the rights they need. Shared logins are dropped.
• The default username “admin” is not used.
• The login page is protected by two-factor login and a limit on attempts.
• File permissions on the server are set restrictively, and directory contents cannot be viewed publicly.
• Error messages show visitors no technical details.
• The connection is encrypted, and the certificate is renewed automatically and monitored.

In an emergency, a prepared procedure helps. Print it out and put it, together with the access credentials (kept safely), where the people responsible can find it.

Fault 1: the site cannot be reached

1. Check whether only you are affected (another device, another network).
2. Check the domain and hosting: has the domain been renewed? Is there a fault notice from the host?
3. Look in the server logs for errors. Has an update or change taken place?
4. Restore the latest working backup if the cause cannot be found quickly.
5. Inform customers through another channel (phone, social media) if the outage lasts longer.

Fault 2: suspected hacker attack

1. Lock down access: change passwords, delete unknown accounts, and if necessary take the site offline temporarily (maintenance page).
2. Secure the suspicious state so that the cause can be established later.
3. Restore a clean backup from before the attack and update everything.
4. Find and close the gap, otherwise the incident will happen again.
5. Check whether personal data was affected. Reporting obligations may then apply; contact your data protection adviser. This is not legal advice; if in doubt, ask a solicitor.

Fault 3: the form does not work

1. Send a test enquiry and check your spam folder and inbox.
2. Check whether the sender address is accepted by your mail provider (setting up SPF, DKIM, DMARC).
3. Look in the server log for errors when sending.
4. Until it is fixed, offer a second route clearly visibly, for example a phone number or email address.

Fault 4: the browser warns “Not secure”

1. Check the certificate: expired, wrong domain, incomplete chain?
2. Renew it at the host or through the service you have set up.
3. Afterwards, check that all content (images, scripts) loads encrypted, so that no mixed-content warnings remain.

Most security incidents on small sites are not feats of hacking but access problems: an old password, the account of a person who left the company long ago, a login sent by email. Order in access is therefore the most effective and cheapest security measure.

Password manager. A program that generates and stores a separate long random password for every account. You only have to remember one strong master password. This is safer than any mnemonic rule, and more convenient.

Two-factor login. In addition to the password, a code from an app or a security key. Activate it for the admin area, hosting, domain account, email and cloud storage. If you lose the second factor, you need recovery codes, which are kept separately.

Roles instead of a shared account. Editors get editor rights, not administrator rights. Service providers get their own accounts, which can be deactivated. That way it is traceable who did what.

Secure handover. Login details are not sent in plain text by email or messenger, but shared through the password manager or transmitted separately (username and password by different routes) and changed after use.

Checklist for when a person or a service provider leaves

1. Deactivate or delete the account in the website's admin area.
2. Block access to hosting, domain, email and cloud, or transfer it to new people in charge.
3. Change shared passwords (where they exist).
4. Check and withdraw access to statistics, Search Console and advertising accounts.
5. Renew application keys (API keys) for services that this person knew about.
6. Have documentation handed over: structure, special features, open tasks.
7. Make a note in the access register, with the date.

An architecture practice (entirely invented) runs a WordPress site. On a Monday morning, a customer reports that a browser warning appears when the site is opened. This is how a clean procedure might look:

1. First finding: the service provider checks the site and finds injected code in a file and an unknown administrator login.
2. Containment: the site is redirected to a maintenance page, and all passwords (hosting, admin area, database, email) are changed.
3. Preserve evidence: logs and the altered state are saved so that the cause can be established.
4. Find the cause: a plug-in that had not been updated for a long time had a known vulnerability.
5. Rebuild cleanly: the system is restored from a backup taken before the tampering, on a new account, all components are updated, and the affected plug-in is removed.
6. Check: other sites and mailboxes are examined for anything unusual, and search engine warnings are reported and reviewed in the Search Console account.
7. Inform: affected customers are informed about the incident to an appropriate extent. If personal data could have been affected, the data protection adviser is brought in, because deadlines for reporting may apply.
8. Learn: the incident is logged and the maintenance plan is extended (plug-in inventory, security monitoring).

Anyone prepared like this loses hours instead of days. The damage is usually caused less by the attack itself than by missing backups and unclear access.

Staging

A test copy of the site on which changes are checked before they go live.

Backup

A safety copy of files and database.

SSL/TLS certificate

A digital certificate that enables the encrypted connection between browser and server.

Two-factor login

Login with a password plus a second proof, such as a code from an app.

Brute force

Automatically trying out many passwords.

Plug-in

An extension that adds a function to a system.

Patch

A small correction to software, often to fix a security vulnerability.

SPF, DKIM, DMARC

Settings with which mail servers check whether an email really comes from your domain.