What “Tested up to” does to your ranking
Oct 28, 2026
“Tested up to” is the line in your plugin’s readme that says which WordPress version you last checked it against. Most authors treat it as a label for users. WordPress.org’s plugin search treats it as one of the six numbers it multiplies your score by. It’s also the cheapest of the six to fix: a one-line edit, no code. This guide shows the exact curve, the slack that makes one branch behind harmless, and when that slack runs out.
How search reads the line
Search compares your “Tested up to” with the current stable WordPress branch, and turns the distance between them into a factor. The code is an exponential decay with an offset of 0.1, a scale of 0.4 and a decay of 0.6:
- Within 0.1 of the current branch, the factor is ×1.00.
- Beyond that, it falls by a further 40% for every 0.4 of distance.
Search only looks at the branch, so 7.1.3 counts as 7.1. WordPress.org’s readme documentation says the same: the field ignores minor versions, and it should contain numbers only, “4.9” and not “WP 4.9”.
The versions are compared as plain decimal numbers. Because WordPress goes from x.9 straight to the next major (6.9, then 7.0), every step between branches is 0.1, and the distance in branches matches the distance in numbers.
The curve
Say 7.1 is the current branch:
| Your “Tested up to” | Branches behind | Factor |
|---|---|---|
| 7.1 | 0 | ×1.00 |
| 7.0 | 1 | ×1.00 |
| 6.9 | 2 | ×0.88 |
| 6.8 | 3 | ×0.77 |
| 6.7 | 4 | ×0.68 |
| 6.6 | 5 | ×0.60 |
| 6.4 | 7 | ×0.46 |
| 6.2 | 9 | ×0.36 |
The factor multiplies your whole score, so ×0.77 costs as much as losing a quarter of your text match. Against a rival that is otherwise level, that is usually several places.
One branch behind is free, two is not
The 0.1 offset is the detail that matters most. A plugin tested up to the previous branch still gets the full ×1.00. TrackWP shows that state as “lagging”: behind, but not losing anything yet. Only from two branches behind does the factor drop, and TrackWP then marks the plugin “behind”, with amber cards and alerts.
The trap is that “lagging” turns into “behind” without you doing anything. Say you’re tested up to 7.0 while 7.1 is current: full score. The day 7.2 is released, you’re two branches behind and drop to ×0.88. Nothing in your listing changed; the origin moved.
Being ahead counts too
The decay measures distance in both directions. Writing a version one branch ahead of the current stable release, while it’s in beta, is fine: that’s still within 0.1. Writing one two branches ahead puts you 0.2 away and costs the same ×0.88 as being two behind. Only claim versions you have actually tested against.
How WordPress releases move it
Search takes the current branch from WordPress.org’s own setting for the stable release, so the origin moves on the day a new major version ships, for every plugin at once. A minor release (7.1.1, 7.1.2) doesn’t move it.
That gives you a simple routine:
- When a new major WordPress version reaches beta or release candidate, test your plugin against it.
- When it’s released, or as soon as you’ve tested, update “Tested up to” to the new branch.
- Never let the line fall two branches behind the current release.
If you follow step 2 at each major release, you’ll never sit lower than one branch behind, and you’ll never lose score to this factor.
How to update it
WordPress.org takes your listing from the readme in the folder your “Stable tag” points to. Its documentation says so directly: everything comes from the readme.txt in the version the Stable Tag points to. So editing “Tested up to” in trunk alone isn’t enough if your Stable tag points to a version folder such as tags/2.4.1.
Update the line in both places:
- trunk/readme.txt, so the next release carries it.
- The readme.txt inside the tag your Stable tag names, so the listing changes now.
This is a readme-only change. You don’t need to release a new version of your code to correct it. If your plugin really needs changes to work with the new WordPress, though, release them first; a “Tested up to” that claims compatibility you haven’t got will show up in your support forum soon enough.
How it compares with the other factors
“Tested up to” is one of two factors you can restore in a day. The other is freshness, which a new release resets. The rest move slowly. Active installs take months to change band, and the rating and the resolved-thread count depend on other people. So when a plugin is losing score to “Tested up to”, it’s nearly always the first thing to fix. How to rank higher in WordPress.org plugin search covers the other five.
Checking your plugins
The Readme Checker reads your published readme and fails a “Tested up to” that’s costing you score, with the factor it’s at. The Rank Simulator shows the factor’s exact value for any plugin, next to the plugins around it in a search. If you track your plugins in TrackWP, you’re alerted when a WordPress release pushes “Tested up to” far enough behind to cost you score, so you can fix it the same day.