The 12-Point Website Security Checklist for Founders

Most websites are not attacked by someone who chose them. They are attacked by software that scans the whole internet for a known weakness — an old plugin, a default login page, a forgotten admin account — and breaks in wherever it finds one. That is good news, in a way: you do not have to outrun a determined adversary, you have to not be the easiest target on the block.

This checklist is for the person who owns the business, not the person who wrote the code. Every item has a plain-language test you can do or ask for. If you can tick all twelve, your site is safer than most of the web.

1. It is served over HTTPS, everywhere

Open your site. The address should start with https:// and the browser should show no warnings. Now try typing the http:// version and the www and non-www versions — all of them should redirect to one secure address. Certificates are free (Let's Encrypt) and every host offers them; there is no reason for a site to be unencrypted in 2026, and browsers and Google treat it as broken.

2. The software is current

If your site runs on WordPress, Shopify, Webflow or any platform: is the core software up to date, and are the plugins and themes? Outdated plugins are the single most common way small-business sites are compromised. Turn on automatic updates for security releases and delete any plugin you are not actively using — inactive plugins can still be exploited.

3. The admin login is not the default

The login page should not be at the platform's default address with a username of admin. Rename the account, use a generated password from your password manager, and turn on two-factor authentication for every administrator. If your platform supports it, limit login attempts so that guessing is slow.

4. You know who has access

List everyone with a login to the site, the hosting account and the domain registrar. Remove people who have left and agencies whose contract ended. The domain registrar is the one people forget, and it is the most dangerous: whoever controls the domain controls the site, the email and everything that trusts them.

5. The domain is locked and renews automatically

At the registrar: transfer lock on, auto-renew on, and a payment card that will not expire next month. A shocking number of business outages are a domain that quietly lapsed. Check that the contact email on the account is one that a real person reads.

6. Security headers are set

This is the one to ask your developer or host about. A handful of HTTP headers tell browsers how to treat your site and block whole classes of attack: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), and Referrer-Policy. Free online header checkers will grade your site in seconds; aim for an A or B. Most platforms let you add these without touching code.

7. Forms are protected

Any contact, sign-up or checkout form should validate what it receives on the server, not just in the browser, and should have some protection against automated abuse — a rate limit, an invisible challenge, or a honeypot field. If a form sends email, make sure it cannot be used to send email to arbitrary addresses; open contact forms are a favourite of spammers.

8. Backups exist and have been restored

Your host may back up the site; find out how often, how long they keep it, and whether you can trigger a restore. Then do one restore to a staging copy so you know it works. A site you cannot restore is a site you can lose to one bad update.

9. Error pages do not leak

Visit a page that does not exist on your site. You should see a friendly "not found" page, not a stack trace, a database error, or a software version number. Verbose errors are a map for attackers. Ask for detailed errors to be logged privately and shown never.

10. Uploads are contained

If users can upload files — profile pictures, documents, CVs — those files must be stored outside the web root or on a separate storage service, renamed, size-limited and type-checked. A site that lets someone upload a file and then run it is not a website, it is a remote control.

11. Third-party scripts are known and minimal

Every analytics tag, chat widget, font and embed is code from someone else running on your site with full access to what your visitors type. List them. Remove the ones nobody looks at. For payment pages in particular, keep third-party scripts to the absolute minimum; card-skimming attacks that piggyback on a compromised widget are common enough to have a name (Magecart).

12. Someone gets told when things change

Turn on the notifications your platform and host offer: new admin user created, plugin updated, login from a new location, certificate expiring. Route them to an inbox a human reads weekly. Most compromises are discovered months later by someone else; a small amount of attention turns "months" into "days".

Bonus: run a free scan once a quarter

Several reputable services will scan a public website for outdated software, missing headers and common misconfigurations at no cost. It is not a penetration test, but it catches the boring problems that cause most breaches. Put it in the calendar next to the backup restore.

If you can only do three

1. Updates on, unused plugins gone (item 2).
2. Two-factor on every admin, including the registrar (items 3 and 4).
3. A backup you have restored (item 8).

Those three close the doors that automated attacks walk through. The rest of the list is how you make sure they stay closed. None of it requires a security team — it requires an owner who asks the questions.