How to Check Which WordPress Plugins Are Outdated on a Site, Without Logging In
If you look after WordPress sites you can't log in to every week (client sites, a partner's site, a site you're about to quote on), you can still see a lot from the outside: which plugins the site loads and, for many of
If you look after WordPress sites you can't log in to every week (client sites, a partner's site, a site you're about to quote on), you can still see a lot from the outside: which plugins the site loads and, for many of them, which version is installed. Here's how to do it by hand, and which signals to trust.
1. List the plugins the site loads
Open the home page, view the page source, and search for /wp-content/plugins/. The folder name after it is the plugin's slug, for example /wp-content/plugins/contact-form-7/. The slug is also the plugin's address on WordPress.org: wordpress.org/plugins/contact-form-7/.
This only finds plugins that load files on that page. Plugins that run only in the admin area, or only on other pages, won't show up.
2. Find the installed version from a reliable source
Two public signals are dependable:
-
The plugin's readme.txt. Many sites still serve
/wp-content/plugins/<slug>/readme.txt. ItsStable tag:line normally matches the installed release. -
A generator meta tag. Some plugins print their own version in the page head, for example
<meta name="generator" content="Elementor 4.2.3">. Elementor, WooCommerce, Site Kit by Google and Slider Revolution do this.
If both are present they should agree. If they don't, treat the version as unknown.
# readme.txt Stable tag
curl -s https://example.com/wp-content/plugins/contact-form-7/readme.txt | grep -i "stable tag"
# generator tags in the page head
curl -s https://example.com/ | grep -io '<meta name="generator"[^>]*>'
3. Don't trust ?ver= numbers
Script and stylesheet links often end in ?ver=1.2.3. That number is frequently the version of a bundled library, a theme setting or a cache-buster, not the plugin release. It's a hint at best. Reporting it as the installed version is how people end up telling a client a plugin is outdated when it isn't.
4. Compare with the latest release on WordPress.org
The plugin's WordPress.org page shows the current version. For scripting, the public plugins API is quicker:
curl -s -g "https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=contact-form-7" \
| python3 -c 'import json,sys; print(json.load(sys.stdin)["version"])'
(-g stops curl from treating the square brackets as a URL glob.) If the installed version is lower, the plugin is outdated. Premium plugins that aren't on WordPress.org can't be compared this way.
5. Check WordPress core and PHP too
Core often shows in a generator tag (WordPress 6.9) or in the RSS feed at /feed/. Some servers send an X-Powered-By: PHP/8.1 header. php.net lists which PHP versions still get security fixes.
Checklist
- [ ] Plugin slugs collected from
/wp-content/plugins/paths in the page source - [ ] Installed version taken from readme.txt
Stable tagor a generator tag, never from?ver=alone - [ ] Both signals agree (or the version is marked unknown)
- [ ] Latest version taken from WordPress.org
- [ ] Core and PHP checked where they're exposed
By hand this takes a few minutes per site, and plugins update constantly, so it's worth scripting if you do it for more than a handful of sites.
Originally published on WP Update Radar by Swift Labs, which runs these same outside-in checks on a list of sites each week.
This article was created with the help of AI and checked for accuracy before publishing.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.