"Tested up to: 7.0" on a plugin page means the developer typed 7.0 into a text file. That is the entire mechanism. Nobody at WordPress.org tested the plugin, nobody verified that the developer tested it, and no automated check confirmed that it works. The field is a self-declaration, and the WordPress Plugin Directory documentation is straightforward about this: the directory relies on developer honesty rather than verification.
That does not make the field worthless. It makes it a different kind of signal than most people think it is, and reading it correctly changes what you do with it.
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.0 shipped 2026-05-20 and 7.1 is scheduled for 2026-08-19. Last verified 2026-07-30 against developer.wordpress.org and wordpress.org.
What the field is, in one sentence
Every plugin in the WordPress.org directory ships a readme.txt file, and that file has a header block. "Tested up to" is one line in that header. The plugin's public directory page displays whatever the developer wrote there.
That is it. There is no test suite behind it, no submission process that validates it, and no third party who checks it.
Who types it, and who checks it
The developer types it. Nobody checks it.
This is worth sitting with for a moment, because the field's placement encourages the opposite reading. It appears in a compatibility box, on an official WordPress.org page, next to information that genuinely is authoritative, like the last-updated date and the number of active installations. Everything around it is measured. The one thing in the middle is asserted.
The practical consequence is that "Tested up to: 7.0" and "we ran this plugin against WordPress 7.0 and it worked" are not the same statement, and the first one does not imply the second. A developer who updates the header without opening WordPress 7.0 at all has broken no rule that anyone enforces.
The one rule that does apply to the number
There is a rule, and it constrains the ceiling rather than the truth. The Plugin Directory's guidance is that a developer should never go above the current release candidate, or, if there is no release candidate, not above the active version.
So the field cannot be aspirational. A plugin cannot claim "Tested up to: 8.0" today, because 8.0 does not exist. If a plugin page says 7.0, then 7.0 existed when that value was written, which tells you something real about when the header was last touched.
That is the field's genuine information content: it is a timestamp in disguise. It tells you which era of WordPress the developer was thinking about most recently. It does not tell you what happened in that era.
"Untested with the most recent versions": what that notice really means
When a plugin's declared value falls behind the current WordPress release, the directory shows a notice saying the plugin has not been tested with the most recent versions of WordPress.
Two things about that notice:
- It is generated automatically from the header value. No human reviewed the plugin, and no test was run to produce it. It is arithmetic on a number the developer typed.
- It is not a statement that the plugin is broken. It is a statement that the developer has not claimed otherwise.
A plugin also does not get closed or removed from the directory for a stale value on its own. Plugins are closed for guideline violations and security problems, not for an out-of-date header. What a stale value does cost is visibility and confidence, which is why active developers keep it current.
The three headers, and only two of them can stop you
The header block contains three version-related fields and they behave completely differently. Confusing them is the most common misreading on the whole subject.
| Header | What it says | Is it enforced? |
|---|---|---|
| Requires at least | The oldest WordPress version the plugin supports | Yes. WordPress will refuse the install or activation if your version is older. |
| Requires PHP | The minimum PHP version the plugin needs | Yes. WordPress checks this and will block activation. |
| Tested up to | The newest WordPress version the developer claims to have tested against | No. It stops nothing. It is displayed and otherwise ignored. |
So the two fields that describe a floor are checked by software, and the one field that describes a ceiling is checked by nobody. If a plugin is genuinely incompatible with your WordPress version because it is too new, nothing in WordPress will prevent you from activating it. You will simply find out.
This is also why the fields are worth reading in a specific order. "Requires PHP" is the one most likely to affect you right now, because WordPress 7.0 raised its own PHP floor to 7.4 and ended support for 7.2 and 7.3, so PHP versions have been moving on a lot of sites in 2026.
What to read instead, in order
The field is a weak signal. These are stronger, and all four are on the same page you are already looking at.
1. The last-updated date. This one is measured, not declared. A plugin updated three weeks ago has a maintainer. A plugin updated three years ago has a decision waiting for you, regardless of what its compatibility box says.
2. The changelog. This is where the truth usually is. A changelog entry that says "compatibility with WordPress 7.0" or "fixed DataViews conflict" is evidence of actual work. A changelog whose most recent entry predates the WordPress release you care about tells you the header was updated without code changes, which is not the same as nothing being needed but is worth knowing.
3. The support forum's recent threads. Every WordPress.org plugin has a support tab. If a plugin broke on WordPress 7.0, that is where it was reported, usually within days of the release. This is the single most underused source on the page, and it is the closest thing to real-world testing you will get without doing your own.
4. The active installation count, read the right way. A widely installed plugin that broke on a major release gets loud fast. A plugin with a small user base can be quietly broken for a long time without anyone filing anything. The number is not a quality signal; it is a signal about how quickly problems surface.
When a stale number is genuinely fine, and when it is not
The field's usefulness depends almost entirely on what the plugin does, and this is the part that generic advice leaves out.
A stale value is often harmless when the plugin is small, does one thing, and touches nothing that changes between WordPress versions. A plugin that adds a single shortcode, sets a header, or redirects a URL is running on WordPress APIs that have been stable for years. A two-year-old "Tested up to" on something like that is a maintenance signal, not a compatibility warning.
A stale value is a real concern when the plugin touches an area WordPress actively rebuilt. On the 7.x generation that means anything that modifies the admin interface, adds columns or filters to the Posts, Pages or Media screens, or extends the editor, because 7.0 replaced those list screens with the new data views and moved the command palette out of the editor into the whole admin. A plugin in that category with a pre-7.0 declared version has a meaningfully higher chance of visible breakage.
And a current value is weaker comfort than it looks on exactly those same plugins, because "the developer typed 7.0" and "the developer rebuilt their admin integration for 7.0" are different amounts of work and the header cannot distinguish them. This is where the changelog earns its place above the compatibility box.
Reading the field for the version you are actually moving to
The question is almost never "is this compatible with what I run now". It is "will this survive the update I am about to do".
For that, the field has one specific use: as a filter to sort your plugin list by, so you know where to spend your research time. Pull the list from Tools > Site Health > Info, which gives you every active and inactive plugin with its version in one place and a copy-to-clipboard export, then check the declared value against the release you are moving to. Anything that lags gets the full research pass described in how to find out which of your plugins will break; anything current gets a glance at the changelog and no more.
That is the correct weight to give it: a sorting key, not a verdict. It is one of the steps in the twenty-minute pre-update checklist precisely because it is fast, not because it is conclusive.
What this field will look like around 2026-08-19
WordPress 7.1 is scheduled for 2026-08-19. Expect three things in the days after.
A large number of plugins will still say 7.0. That is normal and it is not evidence of abandonment. Developers update the header when they ship a release, and not every plugin ships a release in the same week that WordPress does.
Some plugins will say 7.1 on release day itself. That means the developer tested against the release candidate, which is a genuinely good sign about the team, not a guarantee about your site.
The "untested with recent versions" notices will appear in bulk, on plugins that were fine the day before, because the arithmetic changed and nothing else did.
The right response to all three is the same: read the changelog and the support forum, not the box. And if a plugin does break after you update, the triage path is in plugin not working after the WordPress update, which covers the fix-in-place options before it gets to rolling anything back.
For the wider view of what the 7.x releases actually changed and why the admin-facing plugins are the risky category this time, the site owner's guide to WordPress 7 is the overview.
