WordPress PHP Upgrade Readiness Checker

Last updated: What’s new

Turn a WordPress Site Health export and plugin inventory into an honest upgrade-risk report. See core conflicts, unknown compatibility, evidence gaps, and the exact staging tests to run before changing PHP.

Local-first risk triage

Build your upgrade-readiness report

Your pasted report stays in this browser. The optional public-metadata lookup sends only Site Health plugin slugs and names.

🔒 Report stays local
1

Core and PHP versions

Paste Site Health below or enter the versions manually.

2

Paste WordPress Site Health info

Tools → Site Health → Info → Copy site info to clipboard. You can review and remove lines first.

3

Add theme and plugin evidence

Optional, but useful for custom code, premium dependencies, and documented staging results.

Accepted source labels: public, premium, custom, bundled, or unknown. Evidence is user-supplied; this tool does not verify vendor claims.

The theme name and version come from Site Health. A version number by itself is not compatibility proof.

4

Production safeguards and complexity

These often matter more than a plugin’s marketing claim.

Critical functionality to test

How the WordPress PHP Compatibility Check Works

This is a decision-support tool, not a source-code scanner. It combines evidence that a browser can evaluate honestly:

  1. Parse your own Site Health export. It extracts versions, plugin inventory, theme details, PHP memory, HTTPS, debug mode, and multisite signals when present.
  2. Check WordPress core against the official compatibility matrix. A target PHP version that WordPress core does not support is treated as a blocker. A combination the table does not list yet, such as a newer WordPress release, is reported as not listed: neither a pass nor a fail. Our copy of the table was last reviewed on 17 October 2026.
  3. Separate evidence from assumptions. A declared minimum PHP version does not prove compatibility with a newer target. Unverified public, premium, and custom code stays marked unknown.
  4. Weight operational risk. Missing staging, an untested restore, custom PHP, existing errors, checkout, memberships, and background integrations all change the recommendation.
  5. Generate a controlled test plan. The result prioritizes blockers, inventory gaps, and the workflows your staging test must exercise before production.
What it does not do: execute PHP, inspect plugin ZIP files, read private server logs, or guarantee that an upgrade will work. Only when you opt in, it can look up public plugin slugs and exact plugin names on WordPress.org for maintenance and minimum-requirement signals; those signals are not compatibility proof.

Why PHP Upgrade Readiness Is More Than a Version Lookup

WordPress core can support a PHP branch while one payment gateway, abandoned add-on, theme function, or private integration still fails. That is why a URL-only detector and a green core matrix cell are not enough.

  • Security lifecycle: PHP branches leave active and then security support on the official PHP support schedule. Staying on an end-of-life runtime leaves newly discovered PHP issues without upstream fixes.
  • Ecosystem uncertainty: WordPress.org metadata commonly states the lowest PHP version required. It rarely proves the highest version tested across every code path.
  • Conditional failures: a homepage may render while checkout callbacks, scheduled exports, admin editors, image processing, or emails fail.
  • Recovery readiness: a complete files-and-database backup is only useful when the team knows where it is and can restore it within an acceptable window.

Start by checking for a publicly exposed runtime clue with the PHP Version Checker, then confirm the actual version in Site Health or your hosting panel before using this report to plan a production-like staging test. If long-term PHP and plugin upkeep is the underlying problem, compare the site against our WordPress to Astro migration assessment.

Evidence Levels Used in the Report

Compatibility evidence is not binary. The tool keeps stronger observations separate from weak signals so that an unknown is never presented as a pass.

EvidenceWhat it tells youWhat it cannot prove
WordPress core matrixCore is officially listed with the PHP branch.Themes, plugins, custom code, or production workflows.
Declared minimum PHPThe plugin refuses or does not support versions below that floor.That it works on every newer PHP release.
Vendor confirmationThe vendor claims support for a target branch.Your exact plugin combination and configuration.
Automated code scanKnown syntax, removed APIs, or standards violations may be found.Runtime behavior, integrations, and unexecuted edge cases.
Production-like staging testYour actual stack and workflows ran on the target branch.Every future input or traffic condition, so monitoring remains necessary.

A Safe WordPress PHP Upgrade Sequence

  1. Inventory WordPress core, the active theme, mu-plugins, snippets, all active plugins, server extensions, and critical business flows.
  2. Update and clean up the existing stack before changing PHP. Replace abandoned components rather than carrying them forward blindly.
  3. Create a complete, current files-and-database backup and prove the restore process.
  4. Clone production to isolated staging, including realistic configuration and safe sandbox credentials for external services.
  5. Change only the staging PHP version, clear caches, and exercise the report’s test checklist while reviewing PHP and WordPress logs.
  6. Fix root causes, repeat the tests, schedule the production change during a low-risk window, and keep rollback access ready.
  7. After deployment, verify uptime, forms, payments, cron, email, analytics, search visibility, and logs, not just the homepage.

WordPress itself advises creating a complete backup before upgrades. For version-specific context, read our WordPress 7 PHP compatibility guide and required PHP extensions for WordPress.

Turn Unknown Compatibility Into a Test Plan

Illustrative review: an authenticated report identifies the web PHP branch, but a premium plugin has no compatibility evidence. Keep that plugin unknown until you obtain vendor guidance and test its critical workflow on staging. A current-looking version number alone does not make the upgrade ready.

Record the target PHP version, backup restore check, staging results and rollback path. For the dated PHP 8.2 support deadline and planning sequence, read our PHP 8.2 end-of-life guide.

What’s new

  • Site Health plugins now match WordPress.org even when the directory title adds a tagline, as with Yoast SEO: 92 of the 100 most popular plugins match, up from 46.

  • Plugins with no WordPress.org update in over two years are now flagged, and plugins you mark premium, custom or bundled keep that label instead of being looked up on WordPress.org.

  • Core compatibility now follows WordPress’s official table, so WordPress 6.7 with PHP 8.4 counts as supported. Versions the table doesn’t list yet are marked “Not listed yet”.

Next steps

WordPress PHP Upgrade Checker related tools and articles

Continue with the closest follow-up checks and guides based on this tool's topic, crawl intent, and optimization workflow.

Recommended PHP version for WordPress

WordPress PHP 8.5 compatibility

PHP Version Checker

PHP 8.2 End of Life (Dec 31, 2026): WordPress Upgrade Plan

WordPress 7.0 PHP Requirements and Compatibility

WordPress vs Astro: Which Is Better for Business in 2026?

WordPress PHP Upgrade Readiness: FAQ

Can this tool prove that my WordPress site is compatible with a newer PHP version?
No. A Site Health export and plugin inventory cannot execute your theme, plugins, custom code, checkout, forms, cron jobs, or integrations on the target PHP runtime. This tool identifies known core-version conflicts, missing evidence, operational risk, and the safest next test. A successful staging test with clean logs is still required.
What should I paste from WordPress Site Health?
In WordPress, open Tools, Site Health, Info, then use Copy site info to clipboard and paste the result here. The parser looks for WordPress, PHP, active theme, active and inactive plugin, memory, HTTPS, multisite, and debug-mode fields. Review the detected values before using the report.
Does the Site Health export contain passwords or database credentials?
The standard copied Site Health report is designed to omit sensitive values, but you should still review anything you paste. Do not include passwords, API keys, private customer data, database credentials, license keys, or full error logs. The report is analyzed in your browser. If you explicitly enable WordPress.org enrichment, up to 30 public plugin slugs or plugin names from Site Health (not the pasted report) are sent through Web Aloha to the free WordPress.org Plugin Info API. A name is accepted only when one WordPress.org plugin clearly fits it (the same slug, the same title, or that title with a tagline added). Your browser then sets the match aside if its latest release is older than your installed version, and shows the matched slug so you can confirm it.
Why are many plugins marked unknown?
WordPress plugins normally declare a minimum PHP version, not a maximum version they are guaranteed to support. A minimum requirement is not proof that the plugin works on PHP 8.4 or 8.5. Premium, custom, abandoned, and renamed plugins also have incomplete public metadata. Unknown means test required, not incompatible and not approved.
How do I add compatibility evidence for a plugin?
Add one plugin per line using name, version, source, and evidence separated by a vertical bar. Evidence must apply to the selected target branch: “staging passed 8.4” can support an 8.4 assessment, while “fails on 8.5” blocks only an 8.5 target. Unversioned conflicts apply to any target. Keep the supporting test record or vendor link because the tool does not independently verify that statement.
Which PHP version does WordPress recommend in 2026?
WordPress.org currently recommends PHP 8.3 or greater as a modern baseline. The best target for a particular site still depends on WordPress core compatibility, plugin and theme maintenance, hosting availability, and staging results. PHP project lifecycle support and WordPress core compatibility are separate questions.
Why are staging and a restore-tested backup treated as hard gates?
Compatibility failures can be conditional: a checkout callback, scheduled task, editor screen, or rarely used form may fail even when the homepage works. Staging lets you exercise those paths without harming production, while a complete files-and-database backup with a verified restore path limits recovery time.
What should I test after changing PHP on staging?
Test public templates, login and admin editing, media uploads, search, every form, transactional email, scheduled tasks, API or CRM connections, multilingual paths, and, where applicable, product, cart, checkout, payment, refund, account, subscription, and membership flows. Review PHP and WordPress logs rather than relying only on visible pages.
How is the readiness score calculated?
The score starts at 100 and deducts transparent risk weights for a core-to-PHP conflict, unsupported current software, missing staging or rollback, reported errors, custom code, critical transactional features, and plugins with negative or missing evidence. The separate evidence-coverage score shows how complete the submitted information is. Neither score is a certification.
Can I use this on a WooCommerce or membership site?
Yes, for planning, but those sites receive extra risk weight and a larger test checklist. A browser-based inventory review cannot validate payments, webhooks, stock, taxes, subscriptions, access rules, or background jobs. Use a production-like staging copy and test with sandbox credentials.
How does the checker assess my active WordPress theme?
Site Health identifies the active theme and version, but that inventory alone is not target-PHP evidence. Add evidence for the selected PHP branch, such as a production-like staging pass with clean logs or an applicable vendor statement. Child themes, custom functions, templates, and theme-bundled plugins still require direct testing.

Free Website Audit

Not sure what to fix first on your own website? We'll review it and tell you, in plain English, within 48 hours. Free and non-obligatory.

Get my free website audit 💪

Want the PHP Upgrade Tested and Handled Safely?

We audit the full WordPress stack, test critical flows on staging, review logs, complete the production switch, and keep a rollback path ready.

See WordPress Care Plans 🤙