The Website Security Checklist Every Business Site Needs in 2026

Most business websites are not hacked by someone who chose them. They are hacked by automated tools scanning the whole internet for an outdated plugin, a reused password or an exposed admin panel. That is good news, because it means the defence is mostly routine rather than heroic. Here is the checklist I work through on every site I build or take over, grouped so you can hand each part to whoever owns it.

The basics: HTTPS and updates

• HTTPS everywhere. Every page and every asset, with plain HTTP redirecting to HTTPS. Certificates are free, and browsers warn visitors about insecure pages, so there is no excuse.
• HSTS. Send a Strict-Transport-Security header so browsers only ever connect over HTTPS. Start with a short max-age, confirm nothing breaks, then raise it to a year.
• Keep the platform updated. CMS core, themes, plugins and server software. Most of the compromised sites I have cleaned up were breached through a vulnerability that already had a fix available.
• Remove what you do not use. Deactivated plugins, old themes, test pages, staging copies on public URLs. Unused code is still attackable code.

If you run WordPress, how to audit your WordPress plugins walks through that clean-up in detail, and my WordPress security guide covers the platform-specific settings.

Accounts and access

• Least privilege. Give each person the lowest role that lets them do their job. Content editors do not need admin rights, and a freelancer who finished six months ago does not need an account at all.
• One person, one account. Shared logins make it impossible to remove one person's access or see who changed what.
• Two-factor authentication for every admin. On the CMS, the hosting account, the domain registrar, the DNS provider and the email account all of those reset to. An authenticator app or a security key is stronger than SMS codes.
• A password manager. Long, unique, generated passwords for everything, shared through the manager rather than email or chat.
• Quarterly access reviews. Put a reminder in the calendar and remove anyone who has left.

The domain registrar is the account people forget. Whoever controls the domain controls the website and the email, so protect it like the bank account.

Backups you have actually restored

• Automated daily backups of files and database, kept for at least 30 days.
• Stored separately from the server they protect, so one compromised or closed account cannot take out both.
• A test restore to a staging environment at least twice a year.

A backup you have never restored is a hope, not a plan. The first time you try a restore should not be the day you need it.

Security headers

A handful of HTTP response headers close off whole classes of attack for almost no cost. You can set them at your host, your CDN or in your framework's config.

• Content-Security-Policy tells the browser which sources scripts, styles and images may load from, which limits the damage injected code can do. It takes care to set up, because every third-party script has to be allowed, so start in report-only mode and tighten from there.
• frame-ancestors, a CSP directive, controls who may embed your site in a frame, which protects against clickjacking. It supersedes the older X-Frame-Options header, though many sites still send both.
• X-Content-Type-Options: nosniff stops browsers guessing file types, so an uploaded file cannot be treated as a script.
• Referrer-Policy limits how much of your URLs leaks to other sites; strict-origin-when-cross-origin is a sensible default.
• Permissions-Policy switches off browser features you do not use, such as the camera or geolocation.

If your site sits behind a CDN, that is often the easiest place to add them. I explain how that layer works in CDNs and caching explained.

Forms, spam and abuse

• Validate every form input on the server, not just in the browser.
• Rate-limit logins, contact forms and anything that sends email, so a single script cannot fire thousands of requests.
• Try a honeypot field or a privacy-friendly challenge on public forms before reaching for an intrusive CAPTCHA. The trade-offs for real users are in website form UX best practices.
• Restrict uploads by file type and size, and never serve uploaded files from a location where they can execute.
• Use a generic login error ("incorrect email or password") so attackers cannot confirm which accounts exist.

If you have added an AI assistant to your site, treat it as another public input: rate-limit it and never give it access to data it should not reveal. More on that in adding an AI assistant to your website.

Code, dependencies and secrets

• Keep dependencies current. Turn on automated dependency alerts in your repository and run npm audit or your ecosystem's equivalent as part of the build. Patch critical issues quickly and batch the rest into regular updates.
• Keep secrets out of the repo. API keys, database passwords and tokens belong in environment variables or a secrets manager, never in committed code. If a key has ever been committed, rotate it; deleting the file does not remove it from git history.
• Separate environments. Development, staging and production should use different keys and different databases.
• Do not leak server secrets to the browser. In Next.js, any environment variable prefixed with NEXT_PUBLIC_ ends up in the client bundle, so check what you are shipping.

Monitoring

• Uptime monitoring that alerts a real person, not an inbox nobody reads.
• Alerts for spikes in failed logins, new admin accounts and unexpected file changes.
• Server-side error logging, so unusual behaviour gets noticed.
• Certificate and domain renewal reminders. An expired certificate or a lapsed domain takes a site down as effectively as an attack.

Have an incident plan before you need it

When something goes wrong, panic makes it worse. Write one page, now, that answers:

1. Who decides what happens, and how to reach them out of hours.
2. How to take the site offline or put it into maintenance mode.
3. Where the backups are and who can restore them.
4. Which passwords and keys to rotate first.
5. Who needs to be told: customers, your host and, if personal data is involved, whether you have legal reporting duties.
6. How you will find out what happened, so it does not happen again.

Keep a copy somewhere that does not depend on the website or its hosting account being available.

Make it routine

Security is not a project you finish; it is part of upkeep. Fold this checklist into your regular website maintenance schedule, run through it again before any launch or redesign, and treat every new plugin, app or integration as something that has to earn its place.

Not sure how your site measures up? Get in touch and I will run through this checklist on your site and tell you what to fix first.