A website security checklist for a small business covers seven areas: HTTPS and TLS, security headers, software and plugin updates, accounts and multi-factor authentication, backups, DNS and email protection, and monitoring. The 20 checks below each explain why they matter and how to verify them, and most can be tested from outside in a few minutes with free tools.
- Most small-site compromises come from outdated plugins, reused passwords and missing MFA, not sophisticated attacks.
- Turn on MFA for the CMS, hosting panel, domain registrar, DNS provider and email, not just the website login.
- A backup only counts if it is stored off the server and you have tested restoring it.
- Security headers, SPF, DMARC, DNSSEC and CAA are free to set up and easy to check from outside.
- External scans find configuration problems; they cannot prove a site is free of vulnerabilities.
For a fast first pass, run our website security scanner, which checks HTTPS, TLS versions, the certificate, headers, cookies, mixed content, DNSSEC and email records together and produces a graded report. Then work through the checks it cannot see, such as backups and accounts. For deeper application security, the OWASP Top 10 and the OWASP Cheat Sheet Series are the standard free references.
The 20 checks at a glance
| # | Check | Area | How to test |
|---|---|---|---|
| 1 | HTTPS everywhere, no mixed content | HTTPS & TLS | Redirect checker, security scan |
| 2 | Valid certificate that renews automatically | HTTPS & TLS | SSL checker |
| 3 | TLS 1.2 and 1.3 only | HTTPS & TLS | SSL checker, security scan |
| 4 | HSTS | Headers | HTTP headers checker |
| 5 | Content Security Policy | Headers | HTTP headers checker |
| 6 | Clickjacking and other protective headers | Headers | HTTP headers checker |
| 7 | Secure cookie flags | Headers | Security scan, browser developer tools |
| 8 | Core, plugins and themes up to date | Software | CMS dashboard |
| 9 | Unused plugins and exposed files removed | Software | CMS dashboard, browser |
| 10 | Forms and uploads validated | Software | Manual review |
| 11 | MFA on every admin account | Accounts | Account settings |
| 12 | Unique passwords, least privilege, offboarding | Accounts | User list review |
| 13 | Login page protected against guessing | Accounts | Plugin or server settings |
| 14 | Automatic off-site backups | Backups | Backup reports |
| 15 | Restores tested | Backups | Test restore |
| 16 | SPF, DKIM and DMARC | DNS & email | SPF and DMARC checker |
| 17 | DNSSEC and registrar lock | DNS & email | DNSSEC checker, WHOIS |
| 18 | CAA records | DNS & email | DNS lookup |
| 19 | Uptime and certificate expiry alerts | Monitoring | Is it down, monitoring service |
| 20 | Logs, alerts and an incident plan | Monitoring | Hosting and CMS logs |
HTTPS and TLS (checks 1–3)
1. Serve every page over HTTPS, with no mixed content
Why: HTTPS stops visitors' logins, form data and cookies from being read or altered in transit. A single script or image loaded over plain HTTP ("mixed content") weakens that protection and may be blocked by browsers.
How to check: enter http://yourdomain and http://www.yourdomain into our redirect checker. Each should reach the HTTPS version in one permanent (301 or 308) redirect. The security scan reports mixed content on the page.
2. Use a valid certificate that renews automatically
Why: an expired or mismatched certificate shows a full-page browser warning that drives visitors away and trains them to click through warnings.
How to check: our SSL certificate checker shows the issuer, covered hostnames and days until expiry. Confirm with your host that renewal is automatic, for example through ACME with Let's Encrypt.
3. Allow only TLS 1.2 and TLS 1.3
Why: TLS 1.0 and 1.1 have known weaknesses and were formally deprecated by RFC 8996.
How to check: the SSL checker shows the negotiated version, and the security scan tests which older versions are still accepted. Disable them in your server, CDN or hosting panel.
Security headers (checks 4–7)
Headers are instructions your server sends with each response telling the browser how to treat the page. You can see and grade them all at once with our HTTP headers checker.
4. Enable HSTS
Why: Strict-Transport-Security tells browsers to use only HTTPS for your domain, closing the gap on the first plain-HTTP request.
How to check: look for a header such as Strict-Transport-Security: max-age=31536000; includeSubDomains. Add includeSubDomains only once every subdomain supports HTTPS.
5. Add a Content Security Policy
Why: a CSP limits which sources may load scripts, styles and frames, which reduces the impact of cross-site scripting (XSS), a long-standing entry in the OWASP Top 10 under injection.
How to check: look for Content-Security-Policy. Because a strict policy can break third-party widgets, deploy it first as Content-Security-Policy-Report-Only and tighten it gradually.
6. Set clickjacking and other protective headers
Why: these stop other sites framing your pages to trick clicks, prevent browsers guessing file types, and limit what leaks in the Referer header.
How to check: expect frame-ancestors in your CSP or X-Frame-Options: SAMEORIGIN, plus X-Content-Type-Options: nosniff, a Referrer-Policy such as strict-origin-when-cross-origin, and a Permissions-Policy that disables features you do not use. The old X-XSS-Protection header is obsolete; do not rely on it.
7. Mark cookies Secure, HttpOnly and SameSite
Why: session cookies are the keys to logged-in accounts. Secure keeps them off plain HTTP, HttpOnly hides them from page scripts, and SameSite reduces cross-site request forgery.
How to check: the security scan lists cookie flags, or open your browser's developer tools, go to the storage or application panel and inspect the cookies after logging in.
Software and plugins (checks 8–10)
8. Keep core, plugins and themes up to date
Why: publicly disclosed vulnerabilities in popular plugins are scanned for automatically and at scale soon after they are published. Unpatched plugins are one of the most common ways small sites are compromised.
How to check: review the updates screen in your CMS weekly, or enable automatic updates for minor and security releases. Make sure your hosting runs a PHP, Node.js or Python version that still receives security fixes.
9. Remove unused plugins and exposed files
Why: deactivated plugins and themes can still be exploitable, and forgotten files such as .env, .git/, database dumps or backup.zip in the web root can leak passwords or source code.
How to check: delete anything you do not use. Try opening https://yourdomain/.env and https://yourdomain/.git/HEAD in a browser; both should return 403 or 404. Turn off directory listings.
10. Validate forms and file uploads
Why: contact forms, search boxes and upload fields are where injection and malicious uploads happen.
How to check: use your CMS's maintained form tools rather than custom scripts, restrict upload file types and sizes, store uploads where they cannot be executed, and add spam protection. For custom code, follow the OWASP input validation and file upload cheat sheets.
Accounts and MFA (checks 11–13)
11. Turn on MFA for every admin account
Why: a stolen or guessed password is enough to take over an account without a second factor. Whoever controls your registrar or DNS account controls your website and email too.
How to check: enable MFA on the CMS, hosting control panel, domain registrar, DNS or CDN provider, email admin and any payment dashboard. Prefer passkeys, security keys or an authenticator app over SMS.
12. Use unique passwords, least privilege and prompt offboarding
Why: reused passwords are tried automatically against login pages after other sites' breaches, and every unnecessary admin account is another way in.
How to check: review the user list in each system. Give editors and contractors the lowest role that works, remove people who have left, and keep credentials in a password manager. Our password generator creates strong random passwords.
13. Protect the login page
Why: bots constantly try common usernames and passwords against well-known login URLs.
How to check: enable rate limiting or temporary lockouts after failed attempts, avoid usernames like "admin", and if your team works from fixed locations consider restricting the admin area by IP address or putting it behind your CDN's access controls.
Backups (checks 14–15)
14. Run automatic, off-site backups
Why: backups are your recovery from ransomware, a bad update, a hacked site or a mistaken deletion. A backup stored only on the same server can be lost or encrypted with it.
How to check: confirm that both files and database are backed up on a schedule to separate storage, with several days or weeks of history kept. The widely used 3-2-1 rule suggests three copies, on two kinds of storage, with one off-site.
15. Test a restore
Why: backups can turn out to be incomplete, corrupted or missing the database, and you only find out when you restore.
How to check: at least a few times a year, restore a backup to a staging site or local copy and confirm the site loads and recent content is present.
DNS and email protection (checks 16–18)
16. Publish SPF, DKIM and DMARC
Why: without them, anyone can send email that appears to come from your domain, which is ideal for phishing your customers. Major mailbox providers also expect them from bulk senders.
How to check: our SPF and DMARC checker finds missing or broken records. Start DMARC at p=none with reporting, then move to quarantine or reject. A domain that never sends email should publish v=spf1 -all and a DMARC policy of p=reject. Our guide to SPF, DKIM and DMARC covers the details.
17. Enable DNSSEC and a registrar lock
Why: DNSSEC lets resolvers detect forged DNS answers, and a registrar transfer lock stops your domain being moved to another registrar without your approval.
How to check: test the domain with our DNSSEC checker, and look for clientTransferProhibited in a WHOIS lookup.
18. Add CAA records
Why: a CAA record (RFC 8659) names the certificate authorities allowed to issue certificates for your domain, reducing the risk of a mis-issued certificate.
How to check: query the CAA type in our DNS lookup. A typical record is example.com. CAA 0 issue "letsencrypt.org". List every CA your host or CDN uses, or renewals will fail.
Monitoring (checks 19–20)
19. Get alerts for downtime and certificate expiry
Why: downtime, unexpected redirects or a defaced homepage are often the first visible signs of a compromise.
How to check: use our Is It Down checker for a quick test from outside your network, and set up an uptime monitoring service that alerts you by email or phone, including certificate expiry warnings.
20. Keep logs, alerts and an incident plan
Why: logs show what happened and when; without them you cannot tell how an attacker got in or whether they are still there.
How to check: confirm your host keeps access and error logs, turn on login alerts for admin accounts, and write a one-page plan: who to call, where backups are, how to take the site offline, and how to rotate passwords and keys.
Frequently asked questions
How often should I check my website's security?
Review updates weekly, run an external scan monthly and after any significant change, check user accounts and test a backup restore every few months, and rely on automatic alerts for downtime and certificate expiry in between.
Is a free SSL certificate secure enough?
Yes. Free domain-validated certificates such as those from Let's Encrypt use the same encryption as paid ones. Paid certificates mainly add organisation validation, warranties or support, not stronger encryption.
Which security headers are most important?
For most sites, start with HSTS, X-Content-Type-Options, a frame-ancestors or X-Frame-Options rule against clickjacking, and a Referrer-Policy. A Content Security Policy gives the most protection but needs careful testing.
Do small business websites really get attacked?
Yes. Most attacks are automated: bots scan large numbers of sites for known vulnerable plugins and weak logins regardless of size, and a compromised small site is still useful for spam, phishing pages or malware hosting.