AI can build your website. It can’t secure it for you.

I’ve watched AI go from interesting experiment to genuinely useful tool in the time it takes most of us to develop a lunch habit. Claude, ChatGPT, and a dozen others can now write code that actually works: proper, clean, functional code. At Woodwise, we’ve embraced that. An AI can absolutely build you a website. What it won’t do is make that website safe to put in front of real customers.

That’s the gap this note is about. AI website builder security is not something the tooling handles for you by default. A working site and a secure site are two different things, and the difference matters more if your client is in the public sector, regulated industry, or handling any data worth protecting.

The honest thing about AI and code

Let’s get this straight first: Claude and similar tools are legitimately excellent at writing code. They understand architecture. They spot obvious mistakes. They’re faster and often cleaner than the first draft a human writes. We use them every week. But an AI has no operational context. It doesn’t know that your website will be running in production, on a real server, with real customers, and real people trying to break into it for profit or sport. A codebase can be beautiful and still be exposed.

AI website builder security: the seven things AI won’t handle for you

Here’s what needs doing after the code is written.

1. Two-factor authentication on admin logins

A password is no longer a complete lock. Anyone with your admin password can walk in. Two-factor authentication (2FA) requires a second form of identity: a code from your phone, a hardware key, or a passkey tied to your device. This is not optional anymore; it’s the difference between “our site got hacked” and “we locked the attackers out.”

For admin accounts especially, 2FA is essential. The web security standard OWASP’s multi-factor authentication guidance says so. So does every government cybersecurity agency. An AI won’t add this unless you ask it to, and even then, it will write the code but won’t configure it, won’t issue recovery codes, won’t set up a tested recovery path if an admin loses access. Those are operational tasks that need a human who understands risk.

2. Where your site is actually hosted

This one catches people off guard. Many AI tools or no-code builders will spin up your site on whatever cloud region is cheapest or fastest. For most small websites, that’s fine. For public sector work, regulated industries (finance, healthcare, legal), or any client bound by data protection rules, it matters where your data physically lives. UK-based organisations are strongly expected to use UK hosting. European clients often need European data centres. These aren’t technical preferences; they’re legal requirements for your client, and an AI won’t know them.

Your hosting decision is a human call. AI can build the website. You have to decide where it runs.

3. Rate limiting and brute-force protection on login

An attacker can guess passwords all day if there’s nothing stopping them. Rate limiting means “if you fail to log in five times, wait ten minutes before you try again.” Brute-force protection locks the admin area down after repeated failed attempts. Both are standard security practice. Neither is something an AI typically adds without explicit direction, and even then, the settings matter. Get the thresholds wrong and you lock out legitimate users or let in the attackers.

4. A web application firewall (WAF)

A firewall at the application level catches attacks that are already in your codebase. Common Vulnerability and Exposure (CVE) exploits, SQL injection attempts, cross-site scripting (XSS): a WAF blocks these before they even reach your code. Services like Cloudflare, AWS WAF, or Check Point sit between your visitors and your server and catch known attack patterns in real time. An AI will not suggest this. You have to know it exists and set it up.

5. Keeping everything patched and up to date

Your website doesn’t exist in isolation. It runs on a server, uses libraries, depends on frameworks, talks to databases. All of those have security updates. A vulnerability in a library you haven’t touched in six months can sink you. An AI can write code that uses a library, but it can’t patrol your dependencies for vulnerability patches, and it definitely can’t apply them. That’s an ongoing human job: monitoring what’s out there, testing updates, deploying them before something exploits the gap.

6. HTTPS and SSL certificates, properly maintained

HTTPS is no longer optional; it’s mandatory. Your traffic needs to be encrypted from visitor to server. But SSL certificates expire. They need renewal. If your renewal process is manual or forgotten, your site will simply stop working one day, and your visitors will see a browser warning that says “this site isn’t safe.” An AI can configure a site to use HTTPS. It can’t set up certificate renewal automation or monitor for expiry. That’s a human responsibility that recurs every 90 days or however often your certificate renews.

7. Secure, tested backups

A backup you’ve never tested is a backup that doesn’t exist. Industry best practice is the 3-2-1 rule: three copies of your data, on two different storage types, with one offsite. But it’s not enough to have the backup. You need to regularly restore it to a test server to verify it actually works. One copy should be immutable, stored in a way an attacker can’t encrypt it or change it even if they get into your network. An AI can help write the backup code. It can’t restore your site from backup when disaster hits. That’s a documented, rehearsed, human process.

A working site and a secure site are two different things. AI builds the first. Securing it for production is the part that needs experience.

The real cost of cutting corners

Skip 2FA and an attacker gets admin access. Skip hosting research and your public-sector client violates data residency rules. Skip a WAF and common exploits walk straight in. Skip patching and you’re vulnerable to known vulnerabilities anyone can search for. Skip backups and ransomware wins. Each one of these isn’t a “nice to have.” Each one is a thing that will happen, and when it does, it’s expensive: recovery costs, legal liability, lost reputation, downtime, and the work to actually fix it.

The businesses that stay secure are the ones that treat security as a system, not a feature. It’s the same lesson that runs through everything we do: the pieces only work when they’re connected on purpose. Security isn’t something you bolt on after launch. It’s something you design for, build into the process, and maintain continuously.

Where the experience comes in

This is why website design done for real production use needs a human who knows what they’re doing. Not to write the HTML; an AI can do that. But to make sure the infrastructure is sound, the operational practices are in place, and the backup when something goes wrong is already tested and ready.

An AI is a brilliant code-writing tool. It’s not a production operations manager. Those are different jobs, and conflating them is how sites get built right but secured wrong. It’s the same pattern we see across the board, which is why we think of AI as something that works alongside experienced people, not instead of them.

If your site is being built by AI, the important question isn’t whether the code is good. It’s whether the person deploying it understands what not being secure looks like, and has the experience to prevent it. That’s the work where growth really lives, in the difference between “the thing works” and “the thing works and is safe to trust.”