Use this website security checklist to audit your site for common weaknesses. Mark each item Pass, Fix, or N/A, then use the sections below to investigate anything that needs attention.
If your site runs on WordPress, the ShieldPRO Security plugin can help with several things on this list. That includes firewall and bot protection, login security, 2FA, malware and vulnerability scanning, file-integrity monitoring, security headers, activity logs, and user/session controls.
It won’t replace the full checklist because HTTPS, DNS, hosting access, backups, and recovery still need their own review. But it can reduce the manual work on the WordPress side.
1. Make sure HTTPS is enforced across the entire website
Start by loading your website with both http:// and https://. The HTTP version should redirect automatically to HTTPS.
Don’t test only the homepage. Check login screens, forms, checkout pages, account areas, subdomains, and other pages where visitors send or receive information.
Also look for mixed content. A page can use HTTPS while still loading an image, script, stylesheet, or other resource over HTTP.
Pass this check when: HTTP redirects consistently to HTTPS and your browser reports no insecure-resource warnings.
HTTPS encrypts traffic between the visitor and your website. It doesn’t secure the entire site by itself, but it removes an unnecessary point of exposure. If your browser is already showing a warning, our guide to why your website says Not Secure can help you narrow the issue to HTTPS, SSL, redirects, mixed content, or caching.
2. Check the SSL/TLS certificate
Click the security information beside your website’s address in the browser and inspect the certificate.
Check that it hasn’t expired, covers the correct domain, is trusted by the browser, and doesn’t produce certificate warnings.
Then verify automatic renewal. A certificate that works today can still cause an outage later if renewal fails after a hosting, DNS, or configuration change.
Pass this check when: the certificate is valid, covers the domains you use, and has a working renewal process.
3. Update your website software
Review every piece of software the website relies on.
That includes your content management system, plugins, themes, extensions, frameworks, libraries, web server, database software, and other dependencies you manage.
For WordPress, check WordPress core separately from every installed plugin and theme.
Security patches should be handled promptly. CISA, NIST, and the FTC all treat software updates as part of basic cybersecurity hygiene for small businesses.
Larger updates can be tested on staging first if there’s a reasonable chance they’ll create compatibility problems.
Pass this check when: no known security update is sitting uninstalled without a reason.
4. Remove software and accounts you no longer use
Inactive doesn’t mean harmless.
Delete abandoned plugins, unused themes, old extensions, forgotten test installations, and other components the website no longer needs.
Review user accounts at the same time. Temporary developer accounts, former employees, old agencies, and abandoned administrator accounts shouldn’t remain indefinitely.
Every component or account you remove is one less thing that needs to be patched, monitored, and protected.
Pass this check when: you can explain why every installed component and active user account still exists.
5. Check for known vulnerabilities
Being fully updated doesn’t automatically mean every component is safe.
Check your installed software against known vulnerability information. Pay closer attention when a vulnerability affects an internet-facing component or is known to be actively exploited.
OWASP’s 2025 Top 10 places software supply-chain failures among its major web application risks, including problems involving vulnerable or untrusted components and dependencies.
If a vulnerable component has a security update, patch it. If the developer has abandoned it or no fix exists, replacing or removing it may be the safer choice.
Pass this check when: you’ve identified the software your site depends on and there are no known, unresolved vulnerabilities requiring action.
6. Require MFA for privileged accounts
A password alone shouldn’t be enough to take control of your website.
Enable multifactor authentication for accounts capable of making major changes. Start with your website administrators, hosting account, domain registrar, DNS provider, cloud services, and other privileged systems.
CISA recommends MFA because it adds another barrier when a password has been compromised.
Prioritize accounts that can install software, change DNS records, create administrators, access customer data, or alter the site’s infrastructure.
Pass this check when: the accounts capable of taking over or materially changing the site require MFA.
7. Use a different password for every sensitive account
Check whether passwords are reused across your website, hosting account, registrar, email, database, CDN, analytics tools, or other services.
If one password appears in more than one place, replace it.
A password manager makes unique passwords easier to maintain because you don’t have to memorize each one.
Shared team passwords are worth reviewing too. Individual accounts give you more control over who has access and make it easier to remove someone later.
Pass this check when: sensitive accounts use unique credentials and old shared passwords aren’t floating around among people who no longer need them.
8. Review user roles and administrator access
Open your website’s user list and review every account with elevated permissions.
Ask two questions: does this person still need access, and do they need this much access?
A writer usually doesn’t need permission to install plugins. Someone processing orders may not need control over site configuration. A contractor who finished a project six months ago may not need an account at all.
This follows the principle of least privilege: give each user enough access to do the job without handing out permissions they don’t need.
Pass this check when: there are no unnecessary administrators, forgotten users, or accounts with excessive permissions.
9. Protect login, registration, and password-reset systems
Review more than the login page.
Check login attempts, registration forms, password resets, account recovery, and any other process that can create or access an account.
Repeated automated attempts should trigger some form of resistance. Depending on your setup, that may include rate limiting, bot detection, temporary lockouts, reputation checks, CAPTCHA challenges, or firewall rules.
Don’t treat a hidden login URL as your main security control. It may reduce some automated noise, but it doesn’t replace strong authentication and abuse protection.
If your site allows public registration, test how easily automated accounts can be created.
Pass this check when: automated systems can’t hammer account-related forms indefinitely without encountering controls.
10. Confirm that your backups can actually restore the site
First, verify that both your website files and database are being backed up.
Then check where those backups are stored.
Keeping the only backup on the same server as the live website creates a problem if that server is compromised, corrupted, or lost. Keep recoverable copies separate from the production environment.
The FTC, NIST, and CISA all point to backups and recovery planning as core protections. For a website owner, the useful question is whether the backups can restore the site when needed.
The practical step is to test a restoration. You don’t need to restore over the live site. A staging or temporary environment can confirm whether the backup contains what you expect and whether the recovery process works.
Pass this check when: recent backups exist outside the live environment and you’ve successfully restored one.
11. Scan for malware and unexpected file changes
Run a malware scan and review unexplained changes to website files.
You’re looking for more than an obvious defaced homepage.
A compromised site may contain injected scripts, hidden spam pages, redirects, malicious administrator accounts, backdoors, or altered files while appearing normal to most visitors.
File-integrity monitoring can help flag changes to files that normally shouldn’t be modified.
Treat scanner results as evidence to investigate, not simply a list of files to delete. Removing malicious code without fixing the weakness that allowed it in can leave the site open to reinfection.
Pass this check when: scans show no unexplained malicious code or file modifications and you have a way to detect future changes.
12. Review your HTTP security headers
Check the response headers your website sends to visitors’ browsers.
Depending on how your site works, useful protections can include Content Security Policy, HTTP Strict Transport Security, X-Content-Type-Options, controls against unauthorized framing, and an appropriate Referrer-Policy.
OWASP recommends security response headers as browser-level protections against problems such as cross-site scripting, clickjacking, and information disclosure.
Don’t copy an aggressive configuration from another website and assume it will work.
Content Security Policy, for example, needs to account for the scripts, fonts, payment systems, analytics tools, frames, and other resources your own site legitimately uses. OWASP recommends delivering CSP through an HTTP response header.
Test restrictive changes before applying them across a production site.
Pass this check when: appropriate security headers are present, correctly configured, and don’t block legitimate site functions.
13. Check cookies and authenticated sessions
If visitors can log in, review how the site handles authentication cookies and sessions.
Sensitive cookies should use the appropriate Secure, HttpOnly, and SameSite attributes for the way the application works. MDN recommends Secure for cookies sent over HTTPS and HttpOnly for cookies that don’t need to be accessed by JavaScript.
If you’re using a CMS or managed application, these controls may be handled by the platform. They’re still worth checking instead of assuming the defaults are right for your configuration.
Pass this check when: sensitive cookies and sessions use appropriate protections and don’t remain active longer than necessary.
14. Test every place users can submit information
Identify every place where visitors can send data to the website.
That includes contact forms, search fields, account registration, comments, checkout fields, file uploads, URL parameters, API endpoints, and custom forms.
Security checks need to happen on the server. Browser-side validation can improve the user experience, but a malicious request doesn’t have to use your browser interface.
OWASP recommends validating untrusted input and rejecting data that doesn’t match the expected format, range, length, or type.
Database queries should use safe parameterized methods rather than treating submitted input as part of an executable query. Data displayed back on pages also needs appropriate handling to prevent injected scripts from running.
Authenticated actions that change data should have protection against cross-site request forgery where the platform doesn’t already handle it. OWASP documents CSRF tokens and other defenses for requests that could otherwise be triggered from another site.
File uploads deserve their own review. Restrict permitted file types and sizes, validate uploads on the server, control where files are stored, and prevent uploaded files from becoming executable code. OWASP also recommends not trusting the user-supplied Content-Type header by itself.
Pass this check when: user-controlled data is validated and handled safely before the website stores, executes, queries, or displays it.
15. Look for sensitive files exposed to the public
Check whether the public web can reach files that were never meant for visitors.
Look for backup archives, configuration files, database exports, server logs, environment files, private keys, source-control directories, development files, and other sensitive resources.
Debugging deserves attention too. Production errors shouldn’t reveal internal file paths, database information, stack traces, credentials, or other details that make an attack easier.
Don’t rely on robots.txt to protect sensitive information. It tells cooperating crawlers what not to crawl; it doesn’t prevent someone from requesting the resource directly.
Pass this check when: sensitive files, secrets, logs, backups, and debugging information aren’t publicly accessible.
16. Review file permissions and server access
Check who and what can read, write, modify, or execute files on the server.
Permissions shouldn’t be broader than the website requires.
Also review FTP, SFTP, SSH, hosting, deployment, and server accounts. Remove access that belonged to old employees, agencies, developers, or services.
Avoid shared server credentials where individual accounts are available.
If you use managed hosting, you may not control every server-level setting. You should still know who can access the hosting account and what those users can change.
Pass this check when: files and directories aren’t unnecessarily writable and server access is limited to current authorized users.
17. Audit third-party scripts and services
List the external services that load code or interact with your website.
Common examples include analytics platforms, advertising networks, chat widgets, tag managers, payment services, social embeds, consent tools, fonts, APIs, and marketing software.
Remove integrations nobody uses anymore.
Third-party code becomes part of your site’s exposure even though you didn’t write it yourself. OWASP’s 2025 Top 10 recognizes software supply-chain failures as a major application-security risk.
Older websites deserve extra attention because they tend to accumulate abandoned tracking tags, integrations, accounts, and experiments over time.
Pass this check when: you know what external services the website depends on, why each one exists, and who maintains it.
18. Make sure security events are logged
A security incident is much harder to investigate if the website records nothing useful.
Check whether you can review events such as failed and successful administrator logins, account and permission changes, software installations, configuration changes, validation failures, security blocks, and other suspicious activity.
OWASP recommends application logging for security events and specifically includes authentication, authorization, input-validation, and other security-related failures among events worth recording.
Logs also need to be noticed, so set alerts for events serious enough to require attention instead of expecting someone to manually inspect every entry.
Pass this check when: useful security events are recorded and high-risk activity has a practical way of reaching someone.
19. Secure your domain registrar and DNS
Your website isn’t the only account an attacker could target.
Someone who gains control of your registrar or DNS provider may be able to redirect your domain, interfere with email, point visitors to another server, or disconnect the legitimate website.
Use unique credentials and MFA for both.
Review who has access and remove old users. Enable domain locking or equivalent transfer protections where appropriate.
Also make sure your domain’s contact and recovery information is current. Losing access to an old email address shouldn’t leave you unable to recover control of the domain.
Pass this check when: registrar and DNS access is limited, MFA is enabled, and unauthorized domain changes are difficult to make.
20. Review firewall, bot, and traffic protection
Check what happens before suspicious traffic reaches the website.
A web application firewall or similar security service can block or challenge malicious requests, exploit attempts, abusive bots, and traffic associated with known threats.
It shouldn’t be your excuse for leaving vulnerable software installed. A firewall is another layer, not a substitute for fixing the underlying weakness.
Also consider availability. A site that processes substantial revenue or is frequently attacked may need stronger protection against denial-of-service traffic than a small informational website.
Pass this check when: your traffic protection matches the website’s actual exposure and you aren’t relying on it to hide unresolved vulnerabilities.
21. Make sure you know how to recover from a compromise
Assume for this check that your website has already been compromised.
Could you quickly find the hosting credentials? What about the registrar, DNS provider, security tools, administrator accounts, and backups?
Who would investigate the incident? Who could take the site offline if necessary? Where is the last known-good backup?
Your recovery process should cover containing the problem, determining how access was gained, removing unauthorized changes, restoring data if required, fixing the original weakness, rotating exposed credentials, and monitoring the website afterward.
Restoring yesterday’s backup isn’t enough if yesterday’s website still contains the vulnerability that allowed the attack.
You don’t need a huge incident-response manual for a small business website. You do need enough information to avoid figuring everything out while the site is already compromised.
Pass this check when: you know who has the required access, where your recoverable backups are, and what the first recovery steps would be.
How often should you audit your website security?
Some checks on this list shouldn’t wait for a scheduled audit.
Backups, malware monitoring, certificate renewal, security alerts, and some vulnerability checks can run automatically. Security updates should also be reviewed as they become available instead of saved for an annual inspection.
Run a broader website security review periodically and whenever something meaningful changes.
A new hosting provider, major redesign, ecommerce system, membership feature, payment integration, developer, plugin, or third-party service can introduce security considerations that didn’t exist during the previous review.
A fresh audit also makes sense after suspicious activity or the disclosure of a serious vulnerability affecting software your website uses.
Don’t stop at security
Security is only one part of a healthy website.
A site can pass every security check above and still have performance problems, broken pages, SEO issues, accessibility problems, or conversion leaks.
If you want to check the rest of the site too, use our website health checklist for a broader review.
Or run the free Website Health Report. It checks more than 75 factors across security, performance, SEO, accessibility, and other areas, then shows you what needs attention first.
Frequently Asked Questions
How do I use a website security checklist?
Go through each check and mark it Pass, Fix, or N/A. Start with anything that controls access, handles customer data, exposes forms, affects backups, or could take the site offline. The goal is to find the highest-risk problems first, then work through the rest in a sensible order.
How often should a website security audit be done?
Run a broader website security audit at least a few times a year and whenever something meaningful changes, such as a new hosting provider, redesign, ecommerce setup, plugin, developer, or third-party service. Some checks, like backups, malware monitoring, certificate renewal, and security updates, should be watched continuously.
Does HTTPS mean my website is secure?
No. HTTPS protects the connection between the visitor and the website, which is important, but it doesn’t protect against every website security risk. A site can have HTTPS and still have outdated software, weak admin access, unsafe forms, exposed files, poor backups, or vulnerable third-party scripts.
What should I fix first if several items fail?
Fix problems that are public-facing, actively exploitable, tied to privileged accounts, or connected to recovery. That usually means patching known vulnerabilities, securing admin access with MFA, confirming backups can restore the site, protecting forms and uploads, and locking down registrar, DNS, and hosting access.
Is this website security checklist only for WordPress?
No. WordPress site owners can use it, but the checklist also applies to Shopify-style sites, custom websites, membership sites, ecommerce stores, and other business websites. The exact tools may change, but the checks around HTTPS, updates, MFA, backups, user access, forms, files, DNS, and recovery still apply.
We empower people to succeed through practical business information and essential services. If you’re looking for help with SEO, copywriting, or getting your online presence set up properly, you’re in the right place. If this piece helped, feel free to share it with someone who’d get value from it. Do you need help with something? Contact Us
