Home › Blog › WordPress Version Checker: Find Core, WooCommerce and Plugin Versions Before Pea

WordPress Version Checker: Find Core, WooCommerce and Plugin Versions Before Peak

Q: How do I check the WordPress version of a site I don't manage?

View the page source and search for generator, or open /feed/ and look for the line. If both are missing, you cannot get the version reliably from outside, and any tool that claims to is guessing.

October 13, 2026 · 11 min read

WordPress Version Checker: Find Core, WooCommerce and Plugin Versions Before Peak

You can check a WordPress version in three ways. If you can log in, open Dashboard > Updates in wp-admin. If you have shell access, run wp core version. If you have neither, look in the page source for <meta name="generator" content="WordPress x.y.z"> or open the site's RSS feed, which carries a <generator> line with ?v=x.y.z. An online "WordPress version checker" reads those same public markers, so it can only report what the site chooses to show.

For a store, the core version is only part of the answer. As of 13 October 2026 the current release is WordPress 7.1.3, WooCommerce 11.2 came out on 7 October, and an actively exploited flaw in a third-party WooCommerce extension was still in the news in September. To decide whether a store is safe to run through Black Friday, you need core, WooCommerce and every plugin version in one list, compared against what is current.

At a glance

Inside wp-admin, Dashboard > Updates shows the core version and pending updates. The Plugins screen shows each plugin's version.
wp core version and wp plugin list (WP-CLI) give the same data in a form you can export across many sites.
Public markers (generator meta tag, RSS feed) reveal core version only, and a theme or plugin can remove them.
WordPress officially supports only the latest version. Older branches get security fixes as a courtesy through auto-updates.
WooCommerce 11.2 ships with a documented fatal-error conflict with older PublishPress Future versions, so check plugin versions before updating WooCommerce.
Black Friday 2026 falls on 27 November. Do your version audit now, while you still have time to update and test before any code freeze.

Why version checks matter in October 2026

The WordPress core team shipped three security releases in under three weeks. WordPress 7.1.1 (17 September 2026) included 11 security fixes. WordPress 7.1.2 (22 September) fixed a critical vulnerability that let an unauthenticated attacker make page template resolution include a readable local PHP file, which could lead to remote code execution under some conditions. The team backported that fix to every branch back to 4.7. WordPress 7.1.3 (6 October) followed with 7 security fixes and 4 bug fixes. For both 7.1.2 and 7.1.3 the release posts recommend that you "update your sites immediately".

The WordPress security page says that "only the latest version of WordPress is officially supported", and that the security team backports fixes to older versions as a courtesy so that older sites receive critical fixes through auto-updates. In practice, a store on the 6.9 branch can still be patched if it reaches 6.9.10, the latest 6.9 release offered by the WordPress update API this week. A store with background updates disabled stays on whatever version someone last installed by hand.

On the WooCommerce side, the 11.2.0 release notes (7 October 2026) list a database update, several security hardening changes and one compatibility warning: PublishPress Future versions 3.0.0 to 4.10.3 "can cause a fatal error on sites running WooCommerce 11.2, because they load their own outdated copy of Action Scheduler." The fix is PublishPress Future 4.10.4 or later, installed before you update WooCommerce. You will only see that conflict coming if you know which version of the plugin each store runs.

Plugins carry their own risk. BleepingComputer reported in September that attackers were exploiting CVE-2026-27540 in the premium WooCommerce Wholesale Lead Capture plugin, an unauthenticated file upload flaw that allows PHP web shells. Versions 2.0.3.1 and older are affected. Version 2.0.3.2, released on 20 February, fixes it, and Wordfence reported blocking more than 100,000 attacks. Months after the patch, unpatched stores were still being hit.

How to check the WordPress version, step by step

Use the first method you have access to. Record the results in one sheet per store.

Log in to wp-admin and open Dashboard > Updates. The page states the installed WordPress version and whether a newer one is available. Note the date of the last update check shown at the top.
On the same screen, or under Plugins, note every plugin with an update available. Then go to Plugins > Installed Plugins and record name, version and whether auto-update is enabled.
Open WooCommerce > Status. The System Status report lists the WordPress version, WooCommerce version, PHP version, active plugins with versions, and template overrides in the theme that are out of date. Use "Get system report" to copy it as text.
With shell access, run WP-CLI from the site root: - wp core version --extra shows the version, database revision and package language. - wp core check-update --force-check asks the WordPress Version Check API for newer releases and skips the cached answer. - wp plugin list --fields=name,status,version,update_version,auto_update --format=csv exports the plugin inventory. - wp plugin list --update=available lists only plugins with an update waiting.
Without any access, view the page source of the homepage and search for generator. WordPress can print <meta name="generator" content="WordPress 7.1.3">. Also try /feed/, where the RSS output can include <generator>https://wordpress.org/?v=7.1.3</generator>. If neither appears, someone removed the markers. That hides the version from scanners and does nothing to patch the site.
Compare what you found with the current releases: the WordPress releases page and the WooCommerce developer blog. For each plugin, compare with the vendor changelog and check for open advisories.
Decide per store: update now on staging, update after the next sale window, or hold. Write the reason next to each held item.

Which method answers which question

Method	Shows core version	Shows plugin versions	Needs access	Use it for
Dashboard > Updates	Yes	Pending updates only	Admin login	Quick check on one store
WooCommerce > Status	Yes	Yes, active plugins	Admin login	Full snapshot to attach to a ticket
WP-CLI (`wp core version`, `wp plugin list`)	Yes	Yes, all plugins	Shell or SSH	Agencies auditing many stores
Page source / RSS generator	Yes, if not removed	No	None	Prospects, handovers, sites you cannot log in to
Online version checker sites	Same as page source	Sometimes guessed from public files	None	A second opinion when the markers are present

Pre-peak version audit: copy and use

Paste this into your ticket system for each store and fill it in. The thresholds are examples, so set your own.

STORE VERSION AUDIT  (date: ____  checked by: ____)

Store URL: ______________________
Access method used: [ ] wp-admin  [ ] WP-CLI  [ ] public markers only

CORE
  Installed WordPress version: ______   Branch: ______
  Latest release on this branch: ______   Latest overall: ______
  Background security updates enabled?  [ ] yes  [ ] no  [ ] unknown

WOOCOMMERCE
  Installed version: ______   Latest: ______
  Database update pending after last upgrade?  [ ] yes  [ ] no
  Outdated template overrides in theme (from Status report): ______

PLUGINS (from wp plugin list or Status report)
  Total active: ____   With update available: ____
  Any plugin listed in a current advisory?  [ ] yes -> name/version: ______
  Plugins that bundle their own libraries (e.g. Action Scheduler): ______
  Plugins not updated by vendor in 12+ months: ______

PHP
  Version: ______   Supported by host until: ______

DECISION
  [ ] Update on staging this week, then production
  [ ] Security-only updates now, feature updates after peak
  [ ] Hold (reason + owner + review date): ______________________

AFTER UPDATE (same day)
  [ ] Place a test order with a real payment method
  [ ] Confirm the order email arrived
  [ ] Check the error log for new fatal errors
  [ ] Check the order count over the next 2 hours against a normal day

Worked scenario (illustrative)

An agency maintains 30 WooCommerce stores. On Tuesday, a developer runs wp plugin list --update=available --format=csv across all of them and merges the output into one sheet. Four stores show WooCommerce with an update to 11.2 waiting. One of those four runs PublishPress Future 4.9, inside the range the WooCommerce release notes warn about.

The developer updates PublishPress Future on that store's staging copy, then WooCommerce, then runs the database update and places a test order. The site loads and the order goes through. Only then does the same sequence run on production. On the other three stores, WooCommerce goes first, because none of them has the conflicting plugin.

In the same sheet, two stores turn out to have background updates disabled and sit on an older 6.x release. They have not received the September backport. Those two get the core update first, before any WooCommerce work.

The numbers here are made up. The method holds: one export, one comparison against release notes, and an update order chosen per store instead of "update everything" on all 30.

Common mistakes

Trusting an online checker as the full picture. It reads the generator tag or guesses from public files, and it cannot see plugin versions reliably or tell you that a fix was backported.
Treating "no generator tag" as "secure". Removing the marker changes what scanners see. The installed code is the same.
Updating WooCommerce first and checking plugins afterwards. The 11.2 release notes describe exactly this trap with an outdated bundled Action Scheduler.
Forgetting the WooCommerce database update. The 11.2 release notes say it requires one, so schedule it for a quiet hour and confirm it finished before you close the ticket.
Leaving premium plugins out of the audit. They update through their vendor, not wordpress.org, so a dashboard that says "everything is up to date" can still be missing a premium plugin fix such as Wholesale Lead Capture 2.0.3.2.
Reading "the homepage loads" as proof the update worked. A fatal error can sit on checkout, an AJAX handler or a scheduled job while the homepage stays green.

The method has limits. Version numbers tell you what is installed. They do not tell you whether a store was already compromised before you patched it, and they do not catch conflicts that no vendor has documented yet. A version audit lowers known risk. Test orders, error logs and order monitoring after each change catch what the audit misses.

FAQ

How do I check the WordPress version of a site I don't manage?

View the page source and search for generator, or open /feed/ and look for the <generator> line. If both are missing, you cannot get the version reliably from outside, and any tool that claims to is guessing.

Is it enough to be on the latest version of an older branch?

It keeps you covered for the critical fixes the security team backports, as with the 7.1.2 fix that went back to 4.7. Only the latest version is officially supported, so plan the move to the current branch after your peak period.

Should I update WooCommerce right before Black Friday?

Apply security fixes when they are released, after a staging test. Feature releases can usually wait until after the sale if your current version still receives security updates. Our Black Friday code freeze guide covers how to separate the two.

Where Pingvera fits

The last block of the audit, checking orders after an update, is the step teams tend to skip under time pressure. Pingvera's WordPress connector sends WooCommerce order events (order.created, order.failed) in real time. Its anomaly detector compares order flow to an hourly baseline and alerts when the site is up but nobody is buying. Deploys and incidents appear on the same timeline as those order events, so an update that broke checkout shows up next to the drop in orders. The Free plan covers up to 5 sites.

Sources

Last reviewed: 13 October 2026

Know about problems before your customers do

Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.

Start free

← All articles · Privacy policy · pingvera.com