Website security splits into two buckets: things a developer builds in once during the build, and things that keep expiring or drifting on their own after launch. Certificates are the clearest example of the second kind — as of March 2026, no new TLS certificate can be issued for longer than 200 days, a limit the industry is stepping down further, to 100 days in 2027 and 47 days by 2029. A checklist is only useful if it says which bucket each item belongs in.
Most "website security checklist" advice mixes the two together into one flat list, which is how a business ends up assuming everything is handled because the developer said it was — when half of it was only ever handled at the moment the site went live.
What gets built in once, and shouldn't need revisiting
These are decisions made during development that, done correctly, keep working without ongoing attention: HTTPS enforced across the entire site, not just a login page; database queries written so user input can't be interpreted as a command, the specific failure our own security code review guide walks through in more depth; passwords stored hashed and salted rather than in plain text; and login attempts rate-limited so a script can't just guess its way in. None of this is exotic — it's closer to wiring a building to code than to hiring a security guard. If it was skipped at build time, it's a rebuild, not a checklist item you can tick later.
What keeps expiring whether anyone notices or not
The second bucket is different in kind: nothing was done wrong at launch, the item simply has a shelf life. The TLS certificate is the most literal case, and the one getting shorter — a certificate issued today already has to be renewed inside 200 days, and that window keeps shrinking on the schedule above, which makes a manual "renew it once a year" habit obsolete faster than most businesses expect. Third-party plugins and CMS versions are the same pattern on a slower clock, covered in more detail in our guide on how often a website should actually be updated. Staff access drifts the same way — someone leaves the company, their login doesn't get revoked, and eight months later nobody remembers it exists. And a backup that was taken but never test-restored isn't really a backup; it's an assumption.
The six-item version
- HTTPS everywhere — built in, verify it once after launch.
- Input handled safely (no raw queries from user data) — built in, verify during any code review.
- Passwords hashed, logins rate-limited — built in, verify once.
- TLS certificate renewal automated, not manual — ongoing, check now given the shrinking renewal window above.
- Plugins, themes and framework versions current — ongoing, monthly.
- Access list and backups reviewed — ongoing, quarterly at minimum.
Frequently asked questions
If I hire a developer to build the site, does security become their responsibility entirely?
Only the built-in half. A developer sets up HTTPS, input validation, and safe defaults once, during the build. What happens after launch — renewing certificates, updating plugins, revoking access for people who've left — depends on whoever is running the site day to day, whether that's an in-house team or a maintenance contract.
How is this different from a security code review?
A security code review is a developer-facing process that checks how the application handles untrusted input, authentication, and data — see our guide on what a security code review actually checks. This checklist is the business-owner-facing version: the handful of things worth checking even if you never read a line of code.
Why do TLS certificates need renewing instead of being set once and forgotten?
Certificate authorities cap how long a certificate can stay valid, and that cap keeps shrinking. As of March 2026, no new TLS certificate can be issued for longer than 200 days; the industry-wide schedule set by the CA/Browser Forum drops that to 100 days in 2027 and 47 days in 2029. A certificate that used to need a once-a-year reminder will soon need renewing roughly every six weeks — worth automating now rather than waiting for it to lapse.
How often should this checklist actually get reviewed?
The built-in items only need re-checking after a major change to the site. The ongoing items — patches, access, backups — fit the same monthly cadence covered in our guide on how often a website should be updated, since they're driven by the same maintenance clock.
Does working through this checklist replace a formal penetration test?
No — this is baseline hygiene, not a substitute for a dedicated security assessment. It's the set of things that should already be true before a deeper review is worth paying for.