This week I ran a security check on my own website. I built it carefully, I check my own work, and I still found four things that needed fixing. None of them were dramatic. All of them were the kind of thing nobody notices until the wrong person does.

If you've had a website built with AI, here is the part worth knowing: the tools that build sites are very good at making things work and very quiet about making them safe. You describe a site, you get a site, it loads, everyone is happy. The protective layer is a separate job, and if nobody does it, it simply doesn't get done.

You don't need to be technical to check the basics. Here are seven checks, starting with the easiest.

1. Check the secure connection on every address

Open your site with and without the www, and try typing it with http:// at the start instead of https://. Every version should end up on the secure https:// one. Then click the small icon at the left of the address bar. Chrome and Brave show a little settings-style icon there now, not a padlock (Google dropped the padlock in 2023 because people read it as a stamp of trust), while Firefox and Safari still show a padlock. Either way, the message should say the connection is secure. If you see a warning, or Not secure beside the address, visitors and Google will both notice.

2. Test the security headers

Headers are short instructions your site hands to every browser, things like "never let another website display this page inside a hidden frame". Go to securityheaders.com, type in your address and read the grade. An A or B is fine. A D or F means nothing has been set. When I first ran mine, most of them were missing.

3. Type a nonsense address

Add something silly to the end of your address, like yourdomain.co.za/asdfgh. You should get a "page not found" message. If you get your home page instead, search engines think your site has endless pages and automated scanners can't tell what is real. Mine did exactly this.

4. Try to reach private files

On your own site only, add /.env to the end of the address, then try /.git/config. Both should say "not found". These are the places where settings and code history live, and if either ever shows you real content, treat it as urgent and call whoever built the site straight away.

5. Ask about passwords in the code

If your site's code lives on a service like GitHub, two questions matter. Is the repository private? And has a password or key ever been saved in it? Deleting a password later doesn't remove it from the history. I had a repository left public after a demo. It held code only, nothing secret, and I set it back to private within minutes of noticing.

6. Ask whether the parts are up to date

Websites are built from other people's code, and weaknesses are found in that code all the time. Ask your developer how often it's checked. For the technical readers, npm audit takes a few seconds and lists known problems.

7. Turn on two-step verification everywhere

This one beats all the others. Switch it on for your hosting, your domain registrar, your email and your code account. A perfectly built site is still lost if someone steals a password. While you're at it, ask whether your domain's email is set up so nobody can easily send mail pretending to be you.

Security isn't a feature you add at the end. It's a short list of boring checks that somebody has to actually do.

What I do about it

Every site I build is checked against this list before it goes live, and I'll run the same checks on a site you already have. You get the results in plain English, with the fixes made. Nobody can promise a site will never be attacked. The goal is to close the common doors, so you're not the easy target.

Book a free 20-minute chat