WordPress PHP Upgrade Readiness Checker
Last updated:
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.
We fix this
We upgrade & secure WordPress sites, safely.
Backups, PHP upgrades, plugin compatibility checks, rollback safety. You saw the problem above; fixing it is literally our day job.
Stack looks healthy. Want it kept that way?
Our WordPress care plans handle updates, security, backups, and PHP upgrades from $49/mo, so it stays healthy.
Want us to act on this result? Fix these findings →
Prefer the partnership route? Refer clients to us, earn 10% →
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:
- Parse your own Site Health export. It extracts versions, plugin inventory, theme details, PHP memory, HTTPS, debug mode, and multisite signals when present.
- Check WordPress core against the official compatibility matrix. A target PHP version that WordPress core does not support is treated as a blocker.
- 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.
- Weight operational risk. Missing staging, an untested restore, custom PHP, existing errors, checkout, memberships, and background integrations all change the recommendation.
- 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 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 confirming your current runtime with the PHP Version Checker, then use 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.
| Evidence | What it tells you | What it cannot prove |
|---|---|---|
| WordPress core matrix | Core is officially listed with the PHP branch. | Themes, plugins, custom code, or production workflows. |
| Declared minimum PHP | The plugin refuses or does not support versions below that floor. | That it works on every newer PHP release. |
| Vendor confirmation | The vendor claims support for a target branch. | Your exact plugin combination and configuration. |
| Automated code scan | Known syntax, removed APIs, or standards violations may be found. | Runtime behavior, integrations, and unexecuted edge cases. |
| Production-like staging test | Your 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
- Inventory WordPress core, the active theme, mu-plugins, snippets, all active plugins, server extensions, and critical business flows.
- Update and clean up the existing stack before changing PHP. Replace abandoned components rather than carrying them forward blindly.
- Create a complete, current files-and-database backup and prove the restore process.
- Clone production to isolated staging, including realistic configuration and safe sandbox credentials for external services.
- Change only the staging PHP version, clear caches, and exercise the report’s test checklist while reviewing PHP and WordPress logs.
- Fix root causes, repeat the tests, schedule the production change during a low-risk window, and keep rollback access ready.
- After deployment, verify uptime, forms, payments, cron, email, analytics, search visibility, and logs—not merely 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.
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.
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—not the pasted report—are sent through Web Aloha to the free WordPress.org Plugin Info API.
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 48-Hour Website Audit
Not sure what to fix first on your own website? We'll review it and tell you, in plain English. Free & non-obligatory.
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.