Blog · WebJi® India

How to Check Website Vulnerability

Quick answer: Check website vulnerability only on a site you own or have written permission to test. Use the public URL, not a bare IP. Run a malware and blacklist check, confirm the CMS, plugin and PHP versions, then grade TLS. Send active test payloads only after those checks, and only against your own site.
✓ In business since 2005✓ INR + GST billing✓ 24/7 Email Support — avg reply < 60 min
Small Indian startup team gathered around a laptop discussing their email inbox — how to check website vulnerability

How to check a website for vulnerabilities online

Check a website for vulnerabilities online by testing the public URL of a site you own. Start with a malware and blacklist lookup, then the CMS, plugin and PHP versions, then the TLS grade. An active scan, which sends test payloads, comes last and only with permission.

Small Indian startup team gathered around a laptop discussing their email inbox — how to check website vulnerability

A bare IP is the wrong target. The web server picks the site from the hostname, so an IP-only probe can hit a different account on the same machine. Website status, meaning uptime or an HTTP code, is a different check: a site can return 200 and still run a plugin with a known flaw.

  1. Confirm you own the site or have permission in writing. Do not run an active test against a customer, a competitor, or any host you do not control.
  2. Copy the exact public URL, including https and the www form visitors actually use.
  3. Run Sucuri SiteCheck on that URL. It reports known malware, injected spam links and blacklist status. A clean result is a first screen, not a full test.
  4. In the hosting panel, note the PHP version and the CMS. On 30 October 2026, PHP 8.2 and newer still receive security fixes. PHP 8.1 ended security support on 31 December 2025.
  5. If you still need injection and configuration tests, run a passive crawl first with OWASP ZAP or another scanner you are allowed to use. Turn on the active test only in a window you control.

You can do the version, file and TLS checks yourself. Clicking through the site will not prove SQL injection or cross-site scripting. Those need an active test you are allowed to run, or a code review, and they are out of scope for a casual online form.

Why outdated software creates website vulnerabilities

Outdated software creates website vulnerabilities because the flaw is already public. Attackers match a plugin, theme or PHP version to a known bug. They do not need a new exploit written for your domain.

  • WordPress core, plugins and themes with a published flaw stay exposed until you update or remove them.
  • A deactivated plugin is still code on disk. Delete it if you do not use it.
  • A public .git folder, .env file or backup archive leaks source and passwords with no plugin bug at all.
  • PHP 8.0 and 8.1 no longer get security fixes. On 30 October 2026, use 8.2 or a newer branch.

Shared hosting does not hide an old plugin. The account still serves the files you installed. Updating or removing that component is what clears the finding.

What a website vulnerability scan checks

A website vulnerability scan checks the live site in layers: malware and blacklists, known-bad components, exposed files, headers and cookies, TLS, and injection flaws only when you have permission. A single score hides which layer failed.

CheckWhat it looks forPassive or active
Malware and blacklistKnown malware, spam links, blacklist listingsPassive, on the public URL
Component versionsCMS, plugins, themes and libraries tied to known flawsMostly passive
Exposed files.git, .env, backup archives, open directoriesPassive discovery
Headers and cookiesMissing HSTS, weak cookie flags, mixed contentPassive
TLSHostname match, expiry, weak protocolsPassive, separate SSL test
Injection and access flawsSQL injection, cross-site scripting, open redirectsActive, permission required

Passive tests read responses and versions. Active tests send payloads into forms and parameters and can fill your logs. Run the passive checks on the production URL. Use a staging copy for the active pass when you have one.

Treat serious rows as OWASP Top 10 classes: broken access control, injection, vulnerable components and security misconfiguration. Clear the known-bad plugin and any public backup file before you chase informational header notes.

For hosting-side fixes after the report, see website security services. WebJi® does not publish a vulnerability scanner.

How to scan a WordPress site for vulnerabilities

Scan a WordPress site for vulnerabilities from wp-admin first, then with a plugin-vulnerability listing, and only on a site you administer.

  1. Open Dashboard, then Updates. Apply core, plugin and theme updates. Remove plugins and themes you do not use, including ones that are only deactivated.
  2. From your own computer, WPScan can list plugins with known flaws: wpscan --url https://yoursite.com --enumerate vp. Do not point it at a site you do not own.
  3. In the hosting panel, confirm PHP is 8.2 or newer while that branch still receives security fixes.
  4. If the report is malware in the files, stop and follow cleaning a hacked website before you trust the next scan.

Login policy and update habits after this check sit under WordPress security services.

How to test SSL and TLS while you check the site

Test SSL and TLS on the same URL you scanned. A valid certificate does not mean the application is safe, and a failed certificate is still the first failure your visitors hit.

Use the Qualys SSL Labs server test and aim for an A or A+. The certificate name must match the hostname, the dates must be current, and the page must not load HTTP scripts or images on an HTTPS page.

Free and paid certificates both clear the browser warning when the hostname matches. The grade comes from protocol choices and that match, not from the price of the certificate.

How to fix the vulnerabilities a website scan finds

Fix the vulnerabilities a scan finds in this order: public secrets and known-bad components first, informational header notes last. Run the same check again and confirm that row is gone.

  1. If a backup, .env or .git path was public, take it offline, then rotate every password and key that file contained.
  2. Update or delete the plugin, theme or library the report named. Do not leave a copy you plan to fix later in the plugins folder.
  3. Correct the TLS hostname or expiry if the grade failed.
  4. Re-run SiteCheck, the plugin listing and the SSL test. A finding that still appears is not fixed.
  5. On a WebJi® account, a PHP version change is a support task. Email support@webji.services. Do not use the office phone as a support line.

How WAF, 2FA and backups limit the next vulnerability

A WAF, two-factor authentication and backups limit the damage of the next flaw. None of them patches an old plugin. The update still has to happen.

  • A web application firewall can block some exploit traffic. It does not change the vulnerable file.
  • Turn on two-factor authentication for WordPress administrators and for the hosting panel.
  • Keep automated backups with one copy off the server. The 3-2-1 backup rule is the recovery path when a scan is late.
  • A file-change or malware watch tells you if a cleaned site is edited again. It does not replace the version check.

Repeat the check after plugin updates, after a restore, and at least once a quarter.

Website vulnerability checklist

Use this website vulnerability checklist after every scan, and again after you apply the fixes. Stop on the first failed row and fix it before you continue.

  1. You have permission to test this hostname.
  2. CMS core is the current release.
  3. Every plugin and theme is current, or deleted. Deactivated code does not count as removed.
  4. PHP is on a branch that still receives security fixes: 8.2 or newer on 30 October 2026.
  5. TLS grades A at SSL Labs, and the certificate name matches the site.
  6. Sucuri SiteCheck is clean, with no blacklist entry.
  7. The plugin vulnerability listing shows no known-bad plugin.
  8. Admin usernames are not obvious, passwords are unique, and two-factor authentication is on.
  9. Backups run on a schedule, with one copy off the server.
  10. No public .git directory, .env file or backup archive.

Frequently Asked Questions

How can I test for website vulnerabilities?

Test a site you own. Use the public URL for a malware and blacklist check, then confirm the CMS, plugin and PHP versions, then grade TLS. Use an active scanner only with permission, because it sends attack-like requests.

How do I know if a website is vulnerable?

A site is vulnerable when a check shows a known-bad component, a file that should not be public, or an input that accepts an injection payload. A normal homepage is not proof. Update or remove the item the report named, then run that check again.

How can I check if a website is secure?

Confirm HTTPS, a current CMS and plugins, a PHP release that still gets security fixes, unique admin passwords with two-factor authentication, and a clean malware check. Security is that set of results, not one score.

Can I scan my website for vulnerabilities online for free?

Yes, if you own the site. Public malware checkers and SSL graders run in the browser with nothing to install. A deeper active scan is often limited or paid. Free output still needs a fix and a second scan.

How do I scan my WordPress site for malware?

Run a public malware check on the exact URL, then review updates in wp-admin and delete unused plugins. WPScan can list plugins with known flaws: wpscan --url https://yoursite.com --enumerate vp. If files are already infected, clean them before you trust a new scan.

What are the most common website vulnerabilities?

On small sites the usual findings are outdated plugins and themes, PHP with no security fixes, a public backup or .git folder, weak TLS, and an old WordPress core. Injection flaws appear when an active scan is allowed to send payloads.

How do I know if my plugins are vulnerable?

Compare each plugin version with the current release and with a vulnerability listing such as WPScan. A plugin with a known flaw is unsafe even when the site looks fine. Update it or delete it, including plugins that are only deactivated.

What is the OWASP Top 10?

The OWASP Top 10 is a public list of the most serious web application risk classes, including broken access control, injection, vulnerable components and security misconfiguration. A useful scan maps its findings to those classes instead of printing only a score.

Need help with this?

WebJi® support does it for you — free. Talk to our Jaipur team →