A small-business site rarely gets hacked the way owners imagine. Nobody guesses your password by hand or takes an interest in your price list. A bot walks millions of domains, checks a dozen known holes and moves on — and your site becomes a phishing host, a spam relay or a hiding place for somebody else’s links. What follows is a five-block checklist that closes most automated scenarios, a sample server configuration, and the order of actions if you are already inside an incident.

How small business sites actually get compromised

"Who would bother with me?" is the most expensive assumption in this field. Bots do not care what you sell — they are looking for a plugin version, an exposed admin panel or a forgotten subdomain. The owner usually hears about the breach from Google rather than the host: the search snippet turns into a malware warning and organic traffic drops to zero inside a day.

• Known vulnerabilities in plugins and themes — the most common entry point. One to two days pass between disclosure and mass scanning, while the average site is updated twice a year.
• Weak or reused admin passwords — with no login rate limit, a bot works through the ten thousand most common passwords in a few hours.
• Forms with no validation or rate limiting — from ordinary spam to an executable uploaded under an image extension.
• Forgotten access points — a staging subdomain, an old copy in /old, an exposed database manager, an API key that ended up in a public repository.
• A compromised contractor machine — malware steals passwords saved in an FTP client, and in the logs the intrusion looks entirely legitimate.

None of the five requires skill. It is an assembly line, which is exactly why basic hygiene pays off so disproportionately: you do not need to be unbreakable, only more expensive than the next domain in the queue. If you suspect something is already inside, it usually surfaces during a technical site audit — injected scripts and rewritten meta tags show up first.

Transport: HTTPS and the headers your server should send

Certificates are free and renew themselves, so the question is not whether to enable HTTPS but whether plain HTTP is fully switched off. A surprising number of sites still answer on http:// and on the www variant with no redirect — both a hole and a duplication problem for search. The next layer is headers: the server should tell the browser explicitly what it may do with your page.

# Baseline security headers for nginx
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'" always;

The hardest line there is Content-Security-Policy, and it earns the most. A tuned policy makes cross-site scripting pointless: even if a foreign script reaches the page, the browser refuses to run it. It is also the header most likely to break analytics, chat widgets and embedded video if you switch it on blind on a Friday evening.

Patching, accounts and least privilege

After plugins, the second most common way in is accounts. Nothing here is technically hard; it needs organisational discipline, which is usually the missing part. The five rules below go into the support agreement on every project we run.

1. 1

   Patch on a schedule, not when something breaks

   Monthly updates to the core, plugins and dependencies, applied to a copy of the site first. Critical security patches within 48 hours. One to two hours a month closes the largest single class of risk.

2. 2

   Delete everything you do not use

   Every inactive plugin, old theme, staging subdomain and copy sitting in /backup is a live vulnerability nobody updates. Delete rather than deactivate — deactivated code stays on disk and is often still reachable.

3. 3

   Two-factor authentication for every administrator

   No exceptions, contractors and yourself included. It is the only item here that still saves you after a password leaks, and passwords leak more often than people assume.

4. 4

   One account per person

   A shared login across five people means you cannot tell who changed what, and cannot revoke access when someone leaves. Use named accounts and close them on the person’s last day.

5. 5

   Minimum privileges by default

   A content manager does not need to install plugins; an external copywriter does not need database access. An editor-level role covers almost every real task and lowers the cost of a mistake.

Forms, uploads and everything the user sends you

Any field a visitor can type into is an entrance to your system: search, catalogue filters, the contact form, CV uploads, comments. The defensive logic is identical everywhere — trust nothing that arrives from a browser, and check it on the server.

Backups and a plan for the day it happens

A copy nobody has ever restored is not a backup, it is a hope. Half the incidents that reach us come with the phrase "backups were supposedly running": files exist, the database snapshot is four months old, the archive will not unpack. Verifying this takes an hour per quarter.

If the site is already behaving strangely — redirects to unfamiliar domains, unknown pages in the index, a sudden spike in server load — the response goes in this order, and the order matters.

1. 1Freeze the evidence: copy the site and database exactly as they are. It is the only way to work out later how they got in.
2. 2Take the site down behind a 503 holding page and cut public access to the admin panel.
3. 3Rotate every credential: hosting, database, SSH and FTP, admin accounts, domain email, third-party API keys.
4. 4Restore from a snapshot taken before the first suspicious change — not the latest one, which may already contain the backdoor.
5. 5Update everything before lifting the holding page, or the same vector puts you back where you started within a day.
6. 6Check the security issues section in Search Console, submit a review request, and inspect what is still sitting in the index.

Frequently asked questions about website security

In short

• Nearly every small-site breach is automated: the goal is not to be unbreakable, only more expensive than the next domain in the queue.
• Four actions carry most of the value — monthly patching, 2FA for all administrators, server-side form validation, security headers with a CSP.
• A backup without a quarterly restore test is not a backup, it is an untested assumption.
• Write the incident response order before the incident. During a breach there is no time left to invent one.