Website security checklist for small business owners
Ten checks you can go through in an afternoon, each with a way to confirm it is really done. You need a browser, access to your hosting panel and, for a few items, a terminal.
How to use this checklist
Work through the items in order: the first ones prevent the most common problems. Each item ends with “How to check”, which tells you how to confirm the result, not only how to set it up. Go through the list again after a redesign, a hosting move or a new plugin.
1. Keep software updated
Old software with published flaws is the easiest way into a small site: the CMS, plugins, themes, PHP and the server itself. Updates close those flaws.
- Turn on automatic minor updates where your CMS supports them. WordPress has had automatic background updates since version 3.7.
- Delete plugins and themes you do not use instead of only deactivating them: their files stay on the server.
- Stay on a supported PHP branch. php.net keeps a list of supported versions with the date each branch stops getting security fixes.
How to check: the updates page in your CMS admin should show nothing pending, and the PHP version in your hosting panel should belong to a supported branch.
2. Use HTTPS everywhere, then add HSTS
Every page should load over HTTPS with a valid certificate, and every http:// address should redirect to https://. HSTS then tells browsers to use only HTTPS for your domain for a set time.
Example header: Strict-Transport-Security: max-age=31536000; includeSubDomains. Add includeSubDomains only when every subdomain works over HTTPS.
Browsers ignore the header when it arrives over plain HTTP, and the very first visit is unprotected until the browser has seen the header once. The HSTS preload list closes that gap; it requires a max-age of at least one year and includeSubDomains.
How to check: open http://your-site.example and confirm you end up on https://. Then run curl -I https://your-site.example and look for the Strict-Transport-Security line.
3. Do not leave admin areas open
Login pages of the CMS, the hosting panel and database tools such as phpMyAdmin or Adminer are the first addresses automated attacks try.
- Turn on two-factor authentication for every admin account.
- Do not use
adminas a username, and keep the number of administrators small. - Limit login attempts. Restrict database tools and hosting panels by IP address or VPN where you can.
How to check: from a phone on mobile data, open your CMS login, /phpmyadmin, /adminer.php and your panel address. A database tool that shows a login form to anyone should be restricted.
4. Keep backups you have restored
Backups decide whether an incident costs an hour or a week. Keep at least one copy outside your hosting account, so a compromised or closed account does not take the backups with it.
Never keep backups in the public web folder. Files such as backup.zip or dump.sql in the site root can be downloaded by anyone who guesses the name.
How to check: once a quarter, restore a recent backup to a test copy and open it. Then try https://your-site.example/backup.zip; you should get a 404 or 403.
5. Protect your domain’s email
Even if you rarely send email, your domain can be used in forged messages. Publish SPF, DKIM and a DMARC policy; our guide to DMARC explains each record and a safe order of steps.
How to check: send yourself a message from your domain, open the original headers and look for spf=pass, dkim=pass and dmarc=pass.
6. Add basic security headers
A few response headers make common browser attacks harder:
| Header | Typical value | What it does |
|---|---|---|
| X-Content-Type-Options | nosniff | Stops browsers from guessing file types |
| Content-Security-Policy | Start small, for example frame-ancestors 'self' | Controls where scripts load from and who may embed the page |
| X-Frame-Options | DENY or SAMEORIGIN | Older way to block embedding (clickjacking) |
| Referrer-Policy | strict-origin-when-cross-origin | Limits what your URLs reveal to other sites |
Also remove version numbers from the Server and X-Powered-By headers; OWASP recommends removing X-Powered-By altogether. How to check: run curl -I https://your-site.example or look at the response headers in the browser developer tools.
7. Publish a security.txt file
A security.txt file (RFC 9116) at /.well-known/security.txt tells people who find a problem on your site how to reach you. Without it, a helpful report may land in a generic inbox or nowhere.
A minimal file has two lines: Contact: mailto:security@your-domain.example and Expires: 2027-10-01T00:00:00Z. Both fields are required. RFC 9116 recommends an expiry date less than a year ahead, so set a calendar reminder to renew it.
How to check: open https://your-site.example/.well-known/security.txt in the browser.
8. Remove leftovers
Development and site moves leave files behind: .env, the .git folder, phpinfo.php, old copies of configuration files, debug logs, test pages. Each of them can reveal passwords or configuration.
How to check: list the files in the web root with the file manager of your hosting panel, make a backup, and delete anything you cannot identify as part of the live site.
9. Look after DNS and the domain
- Turn on auto-renewal for the domain and protect the registrar account with two-factor authentication.
- Delete DNS records that point to services you no longer use. A forgotten CNAME to a deleted cloud resource can let someone else take over the subdomain.
- Consider a CAA record, which names the certificate authorities allowed to issue certificates for your domain.
How to check: export the DNS zone from your provider and go through each record with the question “do we still use this?”.
10. Watch the site, at least lightly
You will not look at the site every day, so let tools do it: uptime alerts from your host or an uptime service, login alerts from the CMS, and an external check after every larger change. ZNIMOK does not monitor sites continuously, so run the check again yourself after changes.
What an external check can confirm
Several items on this list are visible from outside. The free ZNIMOK website security check looks at the HTTP to HTTPS redirect, the TLS certificate, HSTS, Content-Security-Policy, protection against embedding, X-Content-Type-Options, cookie flags, version numbers in headers, security.txt, CAA, DNSSEC, dangling CNAMEs, the domain expiry date and the email records (SPF, DKIM on common selectors, DMARC, MTA-STS, TLS-RPT). It also matches the software versions your site reveals with public vulnerability and end-of-life data.
It cannot check backups, passwords, two-factor settings or anything behind a login. Those items stay on your own list. The full list of checks shows what is covered and what is not.
Questions
How often should I go through this checklist?
Fully once or twice a year, and the relevant items after every hosting move, redesign or new plugin. Updates and backups need their own regular schedule.
Is an external check enough?
No. It shows what anyone on the internet can see, which is where automated attacks start, but it cannot see inside your server or admin area.
Does this replace a penetration test?
No. A penetration test is a manual, authorized attempt to break in. This checklist covers the basics that should be in place before such a test is worth paying for.
Sources
- RFC 9116: security.txt rfc-editor.org
- RFC 6797: HTTP Strict Transport Security (HSTS) rfc-editor.org
- MDN: Strict-Transport-Security header developer.mozilla.org
- OWASP: HTTP Security Response Headers Cheat Sheet cheatsheetseries.owasp.org
- WordPress handbook: Hardening WordPress developer.wordpress.org
- WordPress handbook: Brute Force Attacks developer.wordpress.org