Website Security Checklist for 2027 (20 Points)

A good year end website security review is a 20 point checklist: update everything, remove old accounts, test your backups, renew what expires, and confirm your email is protected. Most of it takes minutes, and you can finish the whole list in an afternoon.

Who this is for and what you will get

This is for owners of small sites: a WordPress or Shopify store, an indie SaaS, a local business site, or a site you look after for clients. You do not need to be technical. Each item says what to check, how to check it, and what "good" looks like.

Think of it as the yearly service for your car. Nothing here is exotic. It is the boring maintenance that stops most avoidable problems. No checklist makes a site 100% secure, but this one removes the common easy openings.

Before you start (15 minutes)

• Write down everything you run: platform (WordPress, Shopify, custom), hosting company, domain registrar, email provider, and any paid plugins or apps.
• Take a fresh backup before you change anything.
• If you can, try changes on a staging copy first. Staging is a private duplicate of your site used for testing.

Want a quick outside view first? The free website security check looks at your public site and gives you a starting list.

Part 1: Software and updates (points 1 to 5)

Old software is one of the most common ways small sites get into trouble. The current OWASP Top 10 (OWASP is a nonprofit that tracks web security risks) includes a category called Software Supply Chain Failures. It covers the software your site depends on, including outdated and vulnerable components. Attackers scan the internet for sites running versions with known, published flaws.

1. Update your core platform. In WordPress, go to Dashboard > Updates. On a hosted platform like Shopify, the core updates itself, so move on to point 2.

2. Update plugins, themes and apps, then delete what you do not use. A deactivated plugin still sits on your server. Delete it. In WordPress, you can list pending updates with WP-CLI (a command line tool many hosts include):

wp plugin list --update=available
wp theme list --update=available

Check the plugin page for "last updated". If a plugin has not been updated in years and the author is silent, plan a replacement.

3. Check your PHP version. PHP is the language WordPress runs on. Each version gets security fixes for a limited time. In WordPress, see Tools > Site Health > Info > Server. Then compare it with the official PHP supported versions table. If your version is listed as end of life, ask your host to switch you to a supported one (most hosts have a PHP selector in their control panel). Test on staging first, because old plugins can break.

4. Check your Node.js version (if you run Node). Run node --version on your server. Only some Node releases are "LTS" (long-term support), and each one eventually reaches end of life. Compare yours with the official Node.js release schedule and move to a current LTS release if yours has expired.

5. Check the rest of the stack. That means your database, the server operating system and any control panel. On managed hosting, this is the host's job, so ask them in writing which versions they run and when they retire them.

Part 2: Accounts and access (points 6 to 10)

Stolen, shared or forgotten logins are a quiet risk. In the OWASP Top 10, weak or stolen credentials fall under authentication failures. Forgotten accounts and over-broad permissions fall under broken access control, which means people can act beyond what they should be allowed to do. Extra admin accounts also widen what an attacker can do if one of them is compromised.

6. Review every admin user. List them and ask, "Do I know this person, and do they still need this?" In WordPress:

wp user list --role=administrator --fields=ID,user_login,user_email

Or go to Users > All Users > Administrator. Remove or downgrade anyone unfamiliar or no longer working with you. In Shopify, check Settings > Users.

7. Turn on two-factor authentication (2FA). 2FA asks for a code from your phone as well as your password. CISA's guidance on multifactor authentication explains why it matters. Turn it on for your admin accounts, hosting, domain registrar and email first.

8. Use a password manager and unique passwords. Reusing one password means one leak somewhere else can unlock your site. Change any password that is shared in a spreadsheet or chat.

9. Remove old access. Check ex-staff, ex-freelancers and old agencies. Also check SFTP and hosting users, API keys, and any shared logins. If a shared login must stay, change its password now.

10. Give people the least access they need. A blog writer needs the Editor or Author role, not Administrator. Aim for as few admins as possible.

Part 3: Backups (points 11 to 13)

A backup is only useful if it works when you are stressed and the site is down.

11. Confirm automatic backups are running. Look for a recent date, not just a setting that says "on". Your host may offer backups, or you may use a plugin such as UpdraftPlus or Duplicator.

12. Keep a copy somewhere else. If backups live only on the same server, one failure takes both. A common rule of thumb is 3-2-1: three copies, on two kinds of storage, with one offsite. For a small site, that can be as simple as host backups plus a nightly copy to cloud storage.

13. Test a restore. Restore the latest backup to a staging site and click around. Can you log in? Do orders and images appear? Write down how long it took and the steps, so anyone on your team can repeat it.

Part 4: Things that expire (points 14 to 16)

Expired items cause outages, and sometimes real security trouble.

14. Check your SSL/TLS certificate. This is what puts the padlock and https on your site. Most hosts renew it automatically, but renewals can fail silently. To see the expiry date from a terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Replace example.com with your domain. The notAfter line is the expiry. If it is within a month and not renewing, contact your host.

15. Check your domain registration. Log in to your registrar and confirm the expiry date, that auto-renew is on, and that the payment card is current. Also turn on the registrar lock, which blocks unauthorized transfers. Make sure the contact email on the domain is one you still read.

16. List every other renewal. Include hosting, premium plugin licenses, DNS hosting, email, and any app subscriptions. Put them in one calendar with a reminder 30 days ahead. Expired licenses often stop security updates.

Part 5: Email protection (points 17 and 18)

If your domain can be faked, criminals can send emails that look like they came from you. Three DNS records (settings that live with your domain) help receivers tell real mail from fake.

17. Check SPF and DKIM.

• SPF lists who may send email for your domain. It is a TXT record at the root of your domain. For Google Workspace it looks like v=spf1 include:_spf.google.com ~all. You may only have one SPF record, so merge services into one.
• DKIM adds a digital signature to your email. Your email provider (Google Workspace, Microsoft 365, Mailchimp and so on) gives you the exact record to publish.

See your SPF record with:

dig TXT example.com +short

DKIM is not at the root of your domain. It lives at selector._domainkey.yourdomain, where the selector is a name your email provider gives you. To check it, replace selector with that name and run:

dig TXT selector._domainkey.example.com +short

Google Workspace uses google as its default selector, so you would check google._domainkey.example.com. Microsoft 365 publishes DKIM as CNAME records (usually selector1._domainkey and selector2._domainkey), so use dig CNAME selector1._domainkey.example.com +short instead. You can also send a test email to a Gmail inbox, open "Show original" and look for dkim=pass.

18. Publish a DMARC policy. DMARC tells receivers what to do when mail fails SPF and DKIM, and sends you reports. It is a TXT record named _dmarc. A safe starting value is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The rua address is where the reports are sent. Replace dmarc@example.com with a mailbox you actually own and read. p=none only monitors, so it will not block real mail. After you review the reports and confirm all your legitimate senders pass, move to p=quarantine and later p=reject. Check what you have with dig TXT _dmarc.example.com +short, or run our email spoofing tool. Some DNS panels add the quotation marks for you.

Part 6: Your public face (points 19 and 20)

19. Force HTTPS and add basic security headers. HTTPS is the secure version of HTTP, the connection your visitors use. To force it, look for a toggle called "Force HTTPS" or "Always use HTTPS" in your host's control panel, or in Cloudflare under SSL/TLS > Edge Certificates > Always Use HTTPS. In WordPress, also make sure both addresses under Settings > General start with https://. Then check that the old address redirects:

curl -I http://example.com

You want a 301 or 302 response with a Location line that starts with https://.

Headers are instructions your site sends to browsers. Three safe, common ones are:

Strict-Transport-Security: max-age=300
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

The first one, HSTS, tells browsers to use only HTTPS for your site for the number of seconds you set. A long value is a long commitment, and browsers will refuse plain HTTP for that whole time. If HTTPS later breaks, visitors can be locked out. So first confirm every page loads over HTTPS. Start with a short test value such as Strict-Transport-Security: max-age=300, then raise it to 31536000 (one year) once all is well. Add includeSubDomains only if every subdomain supports HTTPS.

You can set headers in your host's control panel, in a CDN such as Cloudflare, with a WordPress security plugin that has a headers option, or in your web server config. Some hosted platforms limit custom headers, so ask your provider what it allows. Test your current setup with the security headers tool.

20. Make sure private files are not public. Old backups, environment files and version control folders sometimes end up in the web root. Check that these return a "not found" or "forbidden" response, not content:

curl -I https://example.com/.env
curl -I https://example.com/.git/config
curl -I https://example.com/wp-config.php.bak

A 403 or 404 is what you want. Some sites return 200 with a normal web page for any URL (single-page apps and custom error pages do this), and 301 or 302 redirects are also common. If you see 200, run the same URL without -I (for example curl https://example.com/.env) and check whether you get the real file contents, such as passwords or keys, rather than a normal page or error screen. Only if you see real contents, treat it as urgent: remove the file, then change any passwords or keys it contained. WordPress owners can also read the official hardening guide.

A simple way to run this each year

1. Block two hours in your calendar in December.
2. Work through the 20 points, noting what you fixed and what you postponed.
3. Save your notes. Next year you will see what keeps slipping.
4. Set calendar reminders for each expiry date you found.

What a checklist cannot catch

This list covers the basics you can verify yourself. It will not find a flaw in how your checkout, login or custom code works. A person has to test those by hand. If you want that, Bug Circuit's Circuit audit is $49 one-time: a human security engineer audits your site and sends a written report with severity, evidence and exact fixes. It is a focused small-site audit, not a compliance certificate or an enterprise pentest. See pricing for details, or start with the free check.

Key takeaways

• Update platform, plugins and themes, delete the unused ones, and check that PHP and Node versions are still supported.
• Remove old admin users, give people the lowest access they need, and turn on 2FA everywhere that matters.
• Keep backups off the server and test a restore at least once a year.
• Put every expiry date (certificate, domain, licenses) in a calendar with a 30 day reminder.
• Publish SPF, DKIM and DMARC so nobody can easily fake your email.
• Use this list for the basics, and a human audit for what a checklist cannot see, like flaws in your login, checkout or custom code.