Website security checklist 2026
Fifteen practical steps you can run through in an afternoon to make your small-business website meaningfully harder to hack — with plain-English fix instructions for each one.
A website that’s a hard target is rarely the most secure website in the world. It’s just enough above the fence-line that an attacker’s automated scanner moves on to the next one. This is the checklist for “above the fence-line”.
Fifteen items. Most you can knock out in 15-30 minutes. Skip the ones that don’t apply to your stack. Don’t skip the ones that do.
To navigate, every item below has its own anchor link — useful if you want to jump back to one mid-fix.
Quick wins (an afternoon’s work)
1. Force HTTPS on every page
Modern hosts and content-delivery networks (Cloudflare, Netlify, Squarespace, Shopify, etc.) do this by default. Older self-managed sites often do not. The fix is a server-side redirect from http:// to https:// on every request, plus a small server setting (called a Strict-Transport-Security header) so browsers remember.
How to verify: visit http://yourdomain.com — you should be redirected to https://yourdomain.com within one hop.
2. Set the three core browser-protection headers
Three small server settings (called HTTP headers) do most of the heavy lifting:
Strict-Transport-Security: max-age=31536000; includeSubDomains— tells browsers to always use the secure version of your site.Content-Security-Policy: default-src 'self'(start tight, loosen as needed) — stops injected scripts from running.X-Frame-Options: DENY— stops your site being embedded inside another site to trick visitors.
How to verify: SecurityHeaders.com grades your headers from F to A+. Aim for at least an A.
3. Update everything
Every plugin, every theme, every CMS, every dependency. If you run WordPress, that includes the core. If you run a Next.js or Laravel app, that includes the framework. Set a calendar reminder for monthly minor updates and a 7-day window for security-flagged updates.
4. Remove plugins and themes you don’t use
A deactivated plugin is still installed code. Deleted is the only safe state for code you don’t use. Same goes for unused themes, unused CMS users, and unused subdomains.
5. Strong, unique admin passwords + 2FA
A password manager makes this painless. 2FA on every admin account is the single most effective control you can add. Most CMSes support TOTP (Google Authenticator, Authy, 1Password) out of the box.
6. Restrict admin URLs
Where possible, put /wp-admin, /admin, /dashboard, and the like behind an IP allow-list, a VPN, or HTTP basic auth on top of the application’s own login. Even a brittle extra layer slows automated scans dramatically.
7. Turn on brute-force protection
WordPress: Wordfence, Limit Login Attempts Reloaded, or your host’s built-in rate limiter. Every CMS has equivalents. Set it to lock the account for 15 minutes after 5 failed attempts.
8. Take down dev/staging/test subdomains
If dev.example.com exists and isn’t actively in use, delete the DNS record and decommission the server. If it’s in active use, put it behind a VPN or IP allow-list. Forgotten subdomains are one of the most common entry points.
9. Backups that you’ve actually restored from
A backup you’ve never restored from is just a feeling. Once a quarter, restore your latest backup to a staging environment and verify it works. Most “we’ve got backups” stories end with “but the backup didn’t actually contain the database”.
The middle layer (this weekend’s work)
10. Security headers on every response, not just the homepage
Most CMSes and frameworks let you set headers globally. If you’re setting them per-page, you’ll forget one. Aim for global.
11. Remove information disclosure
Strip the Server: and X-Powered-By: headers that announce which web server and framework you run. Disable directory listings. Make sure .git/, .env, phpinfo.php, info.php, and backup.zip aren’t accessible from the internet. (One terrifyingly common finding is /wp-config.php.bak reachable on a WordPress site.)
12. Anti-forgery tokens on every form that changes data
Forms that take an action (submit a contact request, change a password, place an order) need a small hidden token that proves the request actually came from your site, not a malicious one tricking a logged-in visitor into clicking. Modern content management systems and frameworks do this for you. Custom-built forms often do not. If you have any, check them — or replace them with the built-in form helper.
13. Rate-limiting on contact forms and login pages
A contact form without rate-limiting will eventually be abused for spam at minimum, credential stuffing or denial-of-service at worst. Most CMSes have plugins; most CDNs (Cloudflare, AWS WAF) include rate-limiting rules out of the box.
The standing layer (continuous, not one-off)
14. Continuous monitoring
Anchor: #continuous-monitoring
Everything above is a snapshot — true the day you do it, possibly less true a month later. New vulnerabilities are disclosed every day; new attacks are weaponised the day after that. Continuous scanning tells you when something has changed.
A free public scanner gives you a snapshot. A continuous scanner like AuraWatch runs the full toolkit on a schedule (weekly on Free, daily on Starter, hourly on Pro, continuously on Enterprise) and tells you what’s different from last time. Every finding includes a plain-English explanation of what it is, why it matters, and how to fix it.
15. An incident-response plan you’ve written down
Two pages. Who to call (web developer, hosting support, CMS vendor, payment processor, insurer, lawyer if you handle confidential information, the team at Elemental Concept if you’d rather hand it off). What to take down. Where the backups live. The credentials for the most important systems.
Print it. Put it in a folder. The day you need it, you don’t want to be searching for it.
How long does this take, realistically?
If your site runs WordPress on a modern host, an experienced web developer can do items 1-9 in an afternoon. Items 10-13 add another half-day. Item 14 is a 5-minute setup if you let a service like AuraWatch run them for you on a schedule. Item 15 is a 30-minute writing exercise.
The whole list is about a day’s work for a developer. It’s the difference between “we hope nothing happens” and “we’d see something happen”. Most small-business sites that get hacked were missing at least three items off this list.
Helpful follow-on reading:
- How to tell if your website has been hacked
- What an SSL warning actually means
- What hackers look for on small business websites in 2026
For continuous monitoring on your sites, see how AuraWatch works or the pricing.
Try AuraWatch free.
Continuous web security and performance monitoring with plain-English findings. One target, weekly scans, no card.
Try AuraWatch free →