Checking Your Own Website's Security: What to Confirm First, with Free Tools

When vulnerability news keeps coming, clients ask us, “Is our site OK?” The honest answer is that nobody can say until they know what is actually running on it.

This article walks through what the person in charge can check on their own before hiring a professional assessment. Every tool here is free, but use them only on sites you manage. It is the first of four articles on website security basics; noticing a compromise, responding to one, and keeping software updated each have their own article.

First, write down what is running

Before checking anything, write things down. Which company is the domain registered with, when does it renew, and which account manages it? Is the site on shared hosting or in the cloud? Which CMS, and which version? Which plugins and themes are installed, including the ones nobody uses? Which versions of PHP or Node.js? Who holds the accounts for the admin screen, the server and FTP? Which outside services are connected, such as payments, forms or email delivery? Put it all on one page.

Any blank is your first piece of homework. Sites where the admin row stays blank very often still have accounts belonging to people who left.

Then compare each version with its official support period. Software past end of support gets no fixes when flaws are found, which makes it a top priority on its own. As of November 8, 2026, PHP’s official page lists 8.2 through 8.5 as supported, and 8.2 stops getting security fixes on December 31, 2026. Version 8.1 and earlier are off the list and already unsupported (PHP).

For other software, endoflife.date collects support periods in one place, but it is a volunteer project, so confirm on each vendor’s own page. On WordPress, open Dashboard, then Updates, to see whether you are current. The WordPress core flaw found at the end of October, exploited during updates, is covered in a separate article.

Check what can be seen from outside

Qualys’s SSL Labs grades your certificate and encryption settings once you enter the domain. If you don’t want the result listed publicly, tick the box under the input field that keeps it off the boards. A grade of A or A+, a certificate that isn’t about to expire, and no old protocols like TLS 1.0 or 1.1 are enough for now.

Mozilla’s HTTP Observatory checks the security settings the server sends to browsers (headers), such as the HTTP-to-HTTPS redirect, HSTS and CSP. Scan history is public, though, and it doesn’t look at outdated software, SQL injection or CMS plugins, so a good grade doesn’t mean the site is safe (Observatory FAQ). A low grade is fixed in the server or CDN settings. A wrong CSP can break the page layout, so talk to your developer rather than pushing it straight to production.

A surprisingly common problem is files left behind during development or a migration, still publicly reachable. Try opening these paths after your own domain in a browser.

/.git/HEAD
/.env
/wp-config.php.bak
/phpinfo.php
/backup.zip

Each should return “not found” (404) or “forbidden” (403). If you see contents or a download starts, delete the file or block access right away. Files like .env and config files often hold the database password, so if one was visible, change that password too.

How Google sees your site

Google warns people in search results and in the browser about sites it judges dangerous. You can check whether your site has been flagged by entering its URL in the site status tool of Google’s Transparency Report. If you are registered with Search Console, the Security issues report shows the same thing, with a green check when there are no problems. A review to remove a warning can only be requested through Search Console (Google), so if you haven’t registered yet, take this as the moment to do it.

While you’re at it, search Google for “site:yourdomain” and look through a few pages of results for anything you don’t recognize. Hacked sites sometimes get pages the owner never sees that show up only in search (web.dev).

Cut down the admin accounts

This check uses no tools, yet we think it does the most good. Open the user list in the admin screen, delete anyone you don’t know, anyone who has left and any unused accounts, and limit admin rights to the people who truly need them. Have every remaining admin turn on two-factor authentication. Find out who knows the server and FTP passwords, and change any that are shared.

On WordPress, the dedicated tool WPScan goes a step further and checks core, plugins and themes for known vulnerabilities. Its free tier is for non-commercial researchers and allows 25 API calls a day (WPScan). How to set up plugin auto-updates, and how to think about them, is in the fourth article, keeping software up to date.

Where to start if you find problems

If something turns up, delete exposed files today. Then plan the migration away from unsupported software, delete unused accounts and plugins, and finally fix the certificate and header settings.

Keep in mind that these checks only reach settings visible from outside and known vulnerabilities. Flaws in what was custom-built for the site, such as how login works, how each member’s data is separated, or how API permissions are checked, won’t show up. When member systems in Japan suffered a string of breaches in fall 2026, JPCERT/CC named abuse of app and system APIs as one of the methods (our article on member systems). If your site handles member data or payments, consider a professional vulnerability assessment.

What management should decide in advance is covered in our article on zero trust and security in the AI era. For a check of your own site or a vulnerability assessment, contact us.