42.91% of WordPress sites still run PHP 7.4, even though that branch reached end-of-life in November 2022 and no longer receives security updates, according to WordPress ecosystem statistics summarized by Blogging Wizard. That single number changes how agencies should think about a routine check. PHP version isn't housekeeping. It's a risk signal.
When teams ask how to check the PHP version of a website, they usually want a quick method. The solution is a workflow. You need one method for sites you control, one fallback when WordPress admin access fails, and a different standard entirely for third-party sites where you can't log in. You also need to know whether the version you found is the one WordPress uses.
For agencies managing multiple client sites, a PHP check belongs in the same category as plugin vulnerability review and backup verification. It helps you decide what needs attention now, what can wait, and what might break during the next host-driven upgrade. Teams that score and rank those issues move faster than teams that rely on memory and spreadsheets. That's why portfolio operators increasingly treat PHP as part of WordPress risk scoring, not as a one-off server detail.
Table of Contents
- Why Your Website's PHP Version Is a Critical Risk Signal
- Checking PHP from the WordPress Dashboard
- Finding the PHP Version with Server-Level Access
- Checking a Website's PHP Version Remotely
- How to Interpret Your PHP Version Results
- A Proactive Plan for PHP Version Management
Why Your Website's PHP Version Is a Critical Risk Signal
PHP version is one of the fastest ways to spot maintenance risk in a WordPress environment.
For agencies, this is not a housekeeping detail. It is a triage signal. An outdated PHP branch increases the odds of security exposure, slows down upgrade planning, and narrows your margin for error when a plugin, theme, or host changes its requirements. I treat it as an early indicator of how much hidden work a site is likely to create.
A key issue is that PHP version checks are often treated as a simple lookup. In practice, they are part of risk assessment. The version reported by a hosting panel is not always the runtime serving the actual site. On multi-site servers, custom stacks, or accounts with legacy configurations, the server default and the application runtime can differ. That gap matters because teams make update decisions based on the runtime, not on what the host advertises.
Security, performance, and upgrade pressure
An older PHP branch creates three operational problems:
- Security exposure: Once a branch reaches end of life, it stops receiving community security fixes. If the host is not backporting patches, you are carrying more risk than the dashboard suggests.
- Performance loss: Newer PHP versions usually run WordPress more efficiently, especially in wp-admin, uncached requests, and plugin-heavy sites.
- Update friction: Theme and plugin vendors raise minimum PHP requirements over time. A site left behind on PHP turns routine updates into compatibility testing and rollback planning.
Portfolio work changes the stakes. One outdated client site is a maintenance annoyance. Twenty of them become scheduling pressure, support load, and avoidable client conversations after something breaks. If your team is already using a WordPress risk scoring workflow, PHP version belongs near the top because it affects both security posture and update feasibility.
Why agencies should treat it as triage
The main question is not "what version is this site on?" The useful question is "how urgently do we need to verify the current runtime and plan an upgrade?"
That is especially important during onboarding and remote audits. A site may pass a visual review, load quickly behind cache, and still be running on a PHP version that limits safe plugin updates. That mismatch is common in agency work because you are often checking sites before you have full server access, and because hosts present PHP settings in different ways.
Use PHP version as a sorting signal. Sites on supported versions usually stay in the normal maintenance queue. Sites on older branches, or sites where the reported version is unclear, move up for verification and closer review. That approach saves time and catches the environments most likely to fail during otherwise routine work.
Checking PHP from the WordPress Dashboard
If you have admin access, use the dashboard. It's the safest and fastest way to check PHP version of website installations without touching files or server settings.
The most dependable method is the built-in Site Health screen. WP Engine's guidance notes that the Site Health route, found under Tools > Site Health > Info > Server, has a success rate of over 98% on WordPress 5.2+ without requiring server access, as explained in WP Engine's guide to checking the PHP version.
Use Site Health first
Use this order every time:
- Go to Tools in the WordPress admin.
- Open Site Health.
- Click the Info tab.
- Expand Server.
- Find the line that lists the PHP version.
That's the first check I trust when an agency has legitimate admin access. It avoids file uploads, doesn't expose server configuration publicly, and can be delegated to account managers or support staff with the right permissions.
If you're onboarding sites into a maintenance workflow, keep the access process simple. A documented admin connection flow prevents ad hoc credential chasing later. For teams standardizing setup, connecting WordPress installs in a repeatable way makes this much easier.
When a plugin is acceptable
Some teams prefer a plugin that surfaces server details directly in the dashboard. That's fine as a temporary convenience, but it's not my first choice.
Plugins can help when:
- The client needs visibility: A non-technical stakeholder may find a dedicated dashboard widget easier to read.
- You're already using diagnostics tooling: If a maintenance plugin includes server info, there may be no reason to add another layer.
- You need a short-term check: A temporary plugin can help on a site where Site Health is hard to use for the client.
What I avoid is leaving extra diagnostic plugins active without a reason. Every additional plugin adds overhead to a site that may already have too much of it.
A quick visual walkthrough helps if you're training a team member or handing this task to a client contact:
Site Health is the default choice because it answers the question with the least risk.
If the dashboard works, stop there. If it doesn't, move down a level and check from the server.
Finding the PHP Version with Server-Level Access
When WordPress admin access is unavailable, broken, or unreliable, server-level access becomes the fallback. It means you transition from comfortable checks to operational checks. The information is still easy to get, but the trade-offs matter more.
Use a temporary phpinfo file
The classic method is a temporary file named something like phpinfo.php placed in the site's root directory with this exact content:
<?php phpinfo(); ?>
Upload it through FTP or your host's File Manager, then visit the file in a browser. The page will display the server's PHP configuration, including the reported version.
This method is reliable, but it comes with a hard rule.
Delete the file immediately after checking. A public phpinfo page exposes server configuration details you don't want left open.
That file is a fallback, not a permanent tool. Use it, record what you need, remove it, then verify it's no longer accessible.
A clean server-side workflow looks like this:
- Create the file briefly: Add only the single line above. Don't add comments or extra code.
- Upload to the correct directory: Place it where the site's main entry files live, not inside uploads or random plugin folders.
- Open and verify: Load the file in a browser and read the PHP version.
- Remove it right away: Delete it from the server and confirm the URL no longer works.
Use SSH when you already have it
If you're comfortable with SSH and the host provides command-line access, the quickest check is:
php -v
That returns the PHP version available in the shell environment. For developers, it's fast and clean.
But there's a practical caveat. On some hosting setups, the shell's default PHP version may not match the version WordPress is using for the web application. That's why SSH is useful, but it shouldn't become a false sense of certainty. Treat it as one signal, not the only one.
A host's control panel can also help if you already have access. Many managed hosts and cPanel-based setups show the configured PHP version in the account interface. That's often enough for a first pass, especially during audits of older hosting accounts. If you're comparing hosts or trying to understand where PHP settings typically live, this broader guide to WordPress hosting decisions and environment controls gives useful context.
Checking a Website's PHP Version Remotely
Remote checks are where most "how to check php version of website" articles get too optimistic. They recommend a public header checker, suggest looking for X-Powered-By, and imply you're done. In real agency work, that approach fails often enough that it shouldn't be your primary process.
Why public header checks often fail
Many servers hide software signatures on purpose. That's basic hardening.
The verified data here is the important part: 68% of production servers hide X-Powered-By and Server headers to reduce exploit targeting. That means public header-checking tools are ineffective for most sites. They can still work occasionally, especially on loosely configured hosting, but they're not dependable enough for portfolio triage.
A remote checker can still be useful in one narrow situation: early qualification. If a public scan clearly exposes a version, you've learned something quickly. If it doesn't, that absence doesn't mean the site is secure or modern. It usually means the host isn't broadcasting internals.
Here's how the common remote options compare:
| Method | What it can tell you | Main limitation |
|---|---|---|
| Public header checker | Sometimes reveals exposed software headers | Often returns nothing useful |
| Browser dev tools | Lets you inspect response headers manually | Same exposure problem |
| cURL or terminal header checks | Good for technical verification of public headers | Still limited to what the server exposes |
What works better for agency triage
For agencies auditing prospects or client sites without direct access, the honest answer is that reliable remote PHP verification usually requires consent and installation, not passive scanning.
That changes the workflow:
- Ask for temporary admin access: Best option when a client wants a proper audit.
- Request a screenshot from Site Health: Lower friction, but still dependent on the client following instructions correctly.
- Use a consent-based monitoring setup: Best for ongoing maintenance, because you aren't repeating the same access request every quarter.
Public scans are fine for curiosity. They aren't enough for professional triage.
This is the gap many agencies run into during onboarding. You can assess plugin bloat, obvious front-end errors, and general site health from the outside. PHP version is different. Once hosts stop exposing headers, remote certainty disappears until the site owner participates.
How to Interpret Your PHP Version Results
Finding the version number is only the beginning. The value comes from reading that number correctly and understanding whether it reflects the environment WordPress runs on.
Read the version as a support status
When you review a PHP version, classify it in plain operational terms:
- Current and recommended: Suitable for ongoing maintenance and new plugin updates.
- Usable but aging: Still serviceable, but worth planning around before the next compatibility issue lands.
- End-of-life: Needs attention because it no longer receives support.
PHP 7.4 belongs in the third category. That's the easiest line to draw because support has already ended. If you see it on a client site, don't treat it as a cosmetic improvement request. Treat it as a maintenance risk that should be discussed before unrelated updates pile onto it.
Performance also matters here, but the practical takeaway is simple. Newer supported PHP versions generally make WordPress run better and with fewer compatibility headaches than aging branches.
Verify the runtime and not just the default
This is the part most guides miss.
A 2025 WordPress Foundation study found that 34% of WordPress sites run on a different PHP version than their server's default, often an older version held back by legacy constraints. That mismatch matters because a team can look at a host setting, see a modern version, and assume the site is safe when WordPress is still executing under something older.
Common reasons include:
- Per-directory overrides: Configuration files can apply a different PHP version to one app.
- Hosting control panel rules: A host may set one account default while individual sites use another.
- Legacy accommodation: Older plugins or custom code can keep a single install pinned behind the rest of the server.
If the server says one thing and the application runs another, trust the application runtime.
For agencies, this changes how you interpret every result. A control panel screenshot isn't enough. A shell response isn't always enough. You want the version the web application is using under real execution conditions.
That distinction is what turns a basic version check into actual risk analysis.
A Proactive Plan for PHP Version Management
Manual checks are useful. They don't scale well. Once you're responsible for multiple sites, PHP version management needs an operating rhythm, not a memory test.
Build a repeatable operating rhythm
The teams that stay ahead of PHP issues usually do three things consistently.
First, they test changes on staging before touching production. PHP upgrades affect the runtime for every plugin, theme, and custom snippet on the site. That makes staging the right place to catch incompatibilities before a client catches them for you.
Second, they communicate in terms clients understand. "Your site is on an unsupported PHP branch" means more when paired with plain consequences: higher maintenance risk, weaker security posture, and a greater chance that a future host or plugin update causes disruption.
Third, they monitor continuously instead of checking ad hoc. A one-time audit goes stale quickly. Host settings change. New sites enter your portfolio. Old sites get neglected.
A practical agency checklist looks like this:
- Standardize the first check: Use Site Health when you have access.
- Document the fallback: Use temporary server-level inspection when admin access fails.
- Record context, not just version: Note whether the version came from runtime inspection, host panel, or shell.
- Prioritize by exposure: Move unsupported PHP environments up the queue, especially on commerce or lead-generation sites.
- Review on a schedule: Re-check after host migrations, major plugin stack changes, or client handoffs.
A dedicated system like WP Triage is built for teams that need to monitor PHP, plugins, themes, core versions, and vulnerabilities across a portfolio, then rank what to fix first instead of drowning in scattered checks.
If you're managing multiple WordPress sites, WP Triage gives you a portfolio view of PHP versions, vulnerabilities, and update risk so you can see which sites need attention first and act in a clear order.