A practical website security checklist
The handful of specific, checkable things that account for most of what a secure website setup actually needs, in the order to do them.
Website security is not one big, complicated undertaking. It is a short list of specific, unglamorous things, most of which take minutes to check and cost nothing to fix. This works through them in a sensible order, starting with the ones that prevent the most common problems.
1. HTTPS is active and enforced everywhere
A free certificate is included with every hosting plan and is issued automatically once a domain points at the account, so this is usually already done. Confirm it is actually working, and that every request is redirected to the secure version rather than the plain HTTP version also remaining reachable. How to install an SSL certificate and how to force HTTPS on your site cover both halves of this.
2. Every password is strong and unique
Control panel, CMS admin, database, FTP, and email — none of these should share a password with any other account anywhere. A password manager removes the need to remember a different long password for each one. How to choose passwords worth having covers what actually makes a password strong versus what merely looks strong.
3. Two-factor authentication is on for anything that offers it
This is the single highest-value addition on top of a strong password, since it means a leaked or guessed password alone is no longer enough to get in. Prioritise your control panel, CMS admin, domain registrar and email accounts specifically. How to turn on two-factor authentication covers setting it up.
4. Software is genuinely kept up to date
An outdated CMS, plugin or theme with a known, published vulnerability is one of the most common routes attackers actually use, because the vulnerability and how to exploit it are both already public. Updating promptly, rather than leaving updates pending indefinitely, closes this route as it becomes available rather than after something has already gone wrong.
5. File and folder permissions are correct
Folders at 755, files at 644, and never 777 anywhere. How to set safe file permissions covers what these numbers mean and how to check and correct them without needing command-line access.
6. Backups exist, are recent, and have actually been tested
A backup you have never restored from is an assumption, not a safety net. Regular, automatic backups mean a compromise or a bad update can be resolved by restoring rather than rebuilding from nothing, and confirming a backup actually restores correctly before you need it removes an unpleasant surprise at the worst possible moment.
7. Login attempts are limited
A limit on repeated failed login attempts makes automated password-guessing tools take drastically longer against your specific site, to the point of no longer being worth running. How to stop brute-force login attacks covers this alongside the other layers that work well together with it.
8. Security headers are set
A handful of response headers — Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and, with more care, Content-Security-Policy — close off entire categories of attack for a small amount of configuration. How to add security headers to your site covers each one and the exact syntax.
9. Anything genuinely private is actually restricted, not just hidden
A staging copy of a site, an internal tool, or anything not meant for the public needs actual access restriction, not just being left off the site's navigation or excluded from search results. How to password-protect a folder covers doing this properly.
10. You know what to do if something does go wrong
Even a well-secured site is not immune to every possible problem, and having a plan before you need one changes how the situation actually plays out. Know in advance where your backups are, how to reach support, and the general order of operations covered in what to do first if your website is hacked, so a bad moment does not also become a confused one.
Work down the list in order over whatever time you have available. Each item stands on its own and improves your position independently of the others — there is no requirement to complete the whole checklist before any single item starts helping.
Revisiting the list, not just completing it once
Security is not a state you reach once and leave alone. New vulnerabilities are found in widely used software on an ongoing basis, a plugin installed a year ago may no longer be maintained by its author, and an account added for a former employee or contractor can be forgotten about long after it should have been removed. Set a routine — even a brief one every few months — to work back through this list rather than treating it as a single task completed at launch and never revisited. Checking whether backups are still running, whether every admin account is still one you recognise, and whether software updates have actually been applied recently takes only a few minutes and catches the kind of drift that accumulates quietly over time.
What this checklist deliberately leaves out
This covers the foundational layer relevant to essentially every website. It does not cover platform-specific hardening — securing a particular CMS in more depth, for instance — or infrastructure-level protections relevant mainly to larger or higher-risk sites, such as a dedicated web application firewall or dedicated DDoS mitigation. Those are worth layering on top once the basics above are solidly and consistently in place, not before.
Related reading
Length beats complexity, reuse is the actual weakness, and a password manager quietly solves both problems at once.
How to turn on two-factor authenticationA second, independent check beyond the password, so a leaked or guessed password on its own is no longer enough to get in.
How to set safe file permissionsThe two numbers that cover almost every case on a website: 755 for folders, 644 for files, and why 777 always creates a worse problem.
What to do first if your website is hackedA calm, ordered checklist for the first hour: contain it, change every credential, restore clean, then find how it got in.