A few days before one online store we worked on was due to launch, everything looked ready. Products loaded, and checkout went to the payment gateway and back with a friendly "thank you for your order". The gateway was still in sandbox mode. Had it gone live like that, it would have happily accepted orders all day without collecting a single cent.
Nobody had been careless. The site just hadn't been checked by someone who knew where to look. That's what this website security checklist is for.
The short answer to "is my website secure?" is that you can't tell from the homepage. A secure site encrypts every page, keeps its configuration files private, locks down its admin, verifies every payment, keeps tested backups and handles personal information the way privacy laws require. You can check about half of that yourself in under an hour.
Why sites built with AI need this more than most
We use AI every day to write and test code. It's very good at producing code that works and noticeably worse at producing code that's safe. Veracode's 2026 GenAI Code Security Report found that AI models now write syntactically correct code almost every time, yet only about 56% of the generated code passed its security tests, barely changed from the year before. For cross-site scripting, the pass rate was 15%.
Live sites show the same. Security firm Escape scanned 5,600 live apps built on AI builders such as Lovable and Bolt.new and found more than 2,000 vulnerabilities and over 400 exposed secrets.
So if your site went up fast (a weekend with an AI builder, a nephew, a freelancer who disappeared), work through this list. The longer argument is in what separates AI-assisted development from vibe coding.
The 10-point website security checklist
Keep count of how many you can answer with a confident yes.
1. Every page loads over HTTPS, and the security headers are set
HTTPS encrypts traffic between your visitor and your server; it's the padlock in the address bar. Security headers are small instructions your server sends with each page, telling the browser things like "only run scripts from these places".
How to check: type your address with http:// (no s) and confirm it redirects to https://. Then paste your domain into securityheaders.com, a free scanner run by Snyk.
What bad looks like: a "Not secure" warning on any page, a certificate that expired last month, or a grade of D or F. Plenty of decent sites score an F here. Treat it as a to-do item, not a crisis.
2. Nothing private is downloadable
Some files should never be downloadable: .env files holding database passwords and API keys, .git folders containing the entire source code and its history, backup archives like backup.zip or site-old.sql, and debug scripts someone used once and forgot. The UK government's security guidance on exposed Git folders notes that an attacker who finds one can download your complete source code, credentials included.
One e-commerce site we audited worked perfectly, while leftover debug scripts in the web root exposed the live database password to anyone who knew the address. The cause was one character: the file meant to keep secrets out of version control was named gitignore instead of .gitignore, so it was silently ignored.
How to check: try yourdomain.com/.env, yourdomain.com/.git/config and yourdomain.com/backup.zip in your browser.
What bad looks like: anything other than a "not found" or "forbidden" page. If passwords appear, change them today. You can only guess a handful of file names, though. A proper audit lists what's actually on the server.
3. The admin login isn't an open door
Every admin panel gets hammered by bots trying common passwords. AI-built admin areas have their own classic failure too: the login page is protected and the pages behind it aren't.
How to check: is two-factor authentication on for every admin account? Does the login lock after several wrong passwords? Log out, then paste the address of an internal admin page (say, the orders list) into your browser.
What bad looks like: the page opens without a login. Anyone with the link can see your customers.
4. Forms reject spam and nonsense
Your forms are where strangers type directly into your system. Spam is the visible nuisance. The quieter risk is injection: someone types code instead of a name and your site runs it. That's the cross-site scripting category Veracode found AI getting wrong 85% of the time.
How to check: submit your own form with <b>test</b> as your name and see whether the email or admin panel shows the tags as text or turns "test" bold.
What bad looks like: bold text (the site runs whatever it's given), or daily spam burying real inquiries.
5. Payments are live, and every notification is verified
If you sell online, this is the point that costs real money. The gateway (Stripe, PayPal, Square, Authorize.net or whoever) must be in live mode, and your site must verify every payment notification before marking an order as paid.
That second part catches people. We took over a store where customers were paying successfully through the payment gateway, but not one order was marking as paid. The code that checked the gateway's notification signature was stripping out empty fields before calculating it, so every check failed. Money arrived in the bank; the store had no idea. The opposite mistake is worse: skip the check and your site will believe a forged "payment successful" message.
How to check: place a small real order with your own card. Confirm the money arrives and the order marks itself as paid. Then ask your developer, in writing, how payment notifications are validated.
What bad looks like: paid orders stuck on "pending", the word "sandbox" in your payment settings, or a developer who isn't sure what you mean.
6. Software, plugins and dependencies are up to date
Everything your site relies on eventually gets a security fix. On WordPress that's core, themes and plugins. On custom and AI-built sites it's the server's PHP version and the libraries the code pulls in.
How to check: in WordPress, open Dashboard, then Updates. Otherwise, ask your developer which PHP version you run and when the libraries were last updated.
What bad looks like: 23 pending updates, abandoned plugins, or a PHP version that no longer gets security fixes.
If you're keeping score, this is roughly where most owners stop being able to check things off themselves. That's normal.
7. Backups exist, live somewhere else, and have been restored
Almost every host says "we do backups". Far fewer clients have seen one restored.
Backups also carry their own risk. When we rebuilt one page-builder site into custom code, the old backup archives turned out to contain SSH keys and database credentials, stored where they could be reached.
How to check: ask your host how often backups run, where they're stored, and when one was last restored.
What bad looks like: "we think daily", backups on the same server, or nobody remembering the last restore. A good host answers without looking anything up, which is one reason we keep our hosting and server management with our own in-house Unix team instead of outsourcing it.
8. Your email is authenticated with SPF, DKIM and DMARC
This looks like an email problem until your quotes land in clients' spam folders, or a scammer sends invoices "from" your domain with new banking details.
SPF lists which servers may send mail for your domain, DKIM signs each message, and DMARC tells receiving servers what to do when a message fails. Google's email sender guidelines now require authentication for mail going to Gmail addresses, and Google says it began stepping up enforcement in November 2025, with non-compliant mail facing temporary and permanent rejections.
How to check: email a Gmail account from your business address, open the message, click the three dots and choose "Show original". Look for PASS next to SPF, DKIM and DMARC.
What bad looks like: FAIL, or no DMARC line at all. Your contact form sends mail too, so test that as well.
9. Your privacy basics are visible on the site
If your website collects a name, email address or phone number, you're handling personal information. In the US, which rules apply depends on where your customers are and the size of your business. State laws such as California's CCPA/CPRA apply to the businesses that meet their thresholds, and they expect you to tell people what you collect and why, and to protect it with reasonable security. So most of this checklist is a legal matter too, and not only a technical one.
If you're not sure which laws cover you, ask an attorney. The basics below are worth having in place whichever ones do.
How to check: is there a privacy policy that names your business and explains what you collect and why? Do your forms say what happens to the information, with an unchecked box for marketing consent? Do you know who you'd have to notify if customer data leaked?
What bad looks like: a privacy policy copied from another company, pre-checked marketing boxes, or forms that email Social Security numbers and other sensitive details around in plain text.
10. You know who has access, and everything is in your name
List everyone with a login to your website, hosting, domain, payment gateway and ad accounts. Include the developer from 2021.
How to check: look up your domain in the ICANN Lookup tool and see who is listed as the registrant. Those details are often redacted for privacy; if they are, log in to your registrar account and check whose name and email the domain is under. Then check that you, not a supplier, are the owner or primary admin on your hosting, Google Ads, Meta Business and Search Console accounts.
What bad looks like: the domain registered to a freelancer, ex-staff who can still log in, or a shared "admin@" password that six people know. Access you can't revoke is a security problem; ownership you don't hold is a business one, covered in who actually owns your website.
How did your site score?
All ten? Good. Book an audit once a year anyway, because sites drift. Six or seven is common, usually with gaps in points 2, 5 and 7, where you can only check the front door while the problem sits in a back room.
Under five, especially if your site takes payments or collects sensitive personal details, make it this month's priority. None of these fixes is expensive on its own. The week after a leak is: the breach notifications, the calls to customers, and the rebuild you pay for twice.
What a proper website security audit adds
This list is what an owner can test from outside. When we audit a site, we start on the server: every file in the web root, file permissions, what the database user is allowed to do, whether errors show to the public, and how payments are verified in the code rather than on screen. The code that handles money and personal information gets read line by line, by a person.
To be fair, a brochure site on well-maintained WordPress with good hosting can pass this list comfortably. The platform matters less than whether someone who knows where to look has looked.
Frequently asked questions
How do I know if my website is secure?
You can't tell from how it looks. Start with the free checks: HTTPS on every page, a securityheaders.com scan, the common exposed-file addresses, and a real test order if you sell online. Anything involving payments or personal information needs someone to review the server and code.
Are AI-built websites less secure?
Not automatically, but unchecked AI code carries real risk. Veracode's 2026 research found only about 56% of AI-generated code passed security tests, though nearly all of it worked. Use AI for speed, with an experienced developer reviewing anything touching payments or customer data.
Do privacy laws apply to my website?
If your site collects any personal information, even a name and email on a contact form, assume some do. Which ones depends on where your customers are and the size of your business; US privacy laws such as the CCPA/CPRA cover the businesses that meet their thresholds. At a minimum, have an accurate privacy policy, clear marketing consent and reasonable security, and ask an attorney which laws apply to you.
What is the most common website security problem you find?
Files that should never be public: database passwords in .env files, old backups, exposed .git folders and forgotten debug scripts. The site works fine with them there, so nobody notices until someone else does.
How often should a business website have a security check?
Check updates and backups monthly, and do a full audit at least yearly, plus after a developer handover or before a store goes live.
If you've worked through the list and you're not sure about a few answers, send us your site's address. We'll look at it and tell you honestly what we'd fix first, and what's fine as it is. We reply within one business day.