Basics

How can I tell whether a website uses PHP?

PHP Site Audit · Updated 2026-10-25

The direct answer

You can look for clues such as a .php URL, a WordPress or other PHP-based application, or a response header that names PHP. These clues are incomplete: URLs can hide file extensions, headers can be removed, and a site may use several backends. Treat a public check as a lead, then ask the hosting provider which runtime handles each relevant hostname and application.

Start with clues, not a verdict

Check the address bar and links for .php paths, and review publicly visible technology clues such as a familiar content-management system. These observations can suggest that PHP is involved, but none is a complete inventory. A site may rewrite every route to extension-free URLs, suppress identifying headers, or serve static files from a content-delivery network while a separate application handles forms or account pages.

A recognizable platform can be a useful clue when its documented server requirements include PHP. It still does not tell you which PHP build is running today, whether a different service handles a particular subdomain, or whether a vendor has applied a backport. Technology identification and version verification are separate questions.

If you manage several properties, do not extrapolate from one successful check. Different subdomains can point to different hosting accounts, and a company can move a site without changing its public address. Keep a small table with hostname, clue observed, service owner, runtime confirmation date, and any remaining question. This table gives a later patch request a reliable scope and prevents a result for one page from becoming an account-wide conclusion.

Use a small, safe observation process

Open the homepage and a few ordinary public pages, including a login or contact route if available without submitting personal data. Note the exact hostname and paths that appear to behave differently. Look at response headers with a normal browser developer panel or ordinary HTTP inspection tool; do not try exploit strings, guessed admin paths, or intrusive probing to identify a language.

A .php extension is a strong hint that a route may be implemented with PHP, but it does not prove every route uses the same runtime. Conversely, no .php suffix and no PHP header do not establish that PHP is absent. Modern routing often hides implementation details intentionally.

Ask the party that can see the deployment

If this is your site, check the hosting account's domain-specific PHP settings or ask the host to map the hostname to its web handler and package. Include subdomains, staging sites, API endpoints, and custom applications. A control panel may show a selected version, but ask whether it is the build currently serving production requests.

If a vendor or agency owns the site, ask who operates its origin and backend integrations. Request a dated statement of the technologies and services in scope. Avoid requesting shell access or credentials when a package/build identifier and responsible contact will answer the question.

Decide what evidence is enough for your next step

For a technology inventory, record each clue, where it was observed, and its confidence: ‘PHP suggested by public CMS marker’ is more accurate than ‘PHP confirmed.’ For a patch decision, ask the provider for the serving runtime, package or image identifier, vendor advisory, covered hostnames, and worker activation time. The public site rarely reveals those facts reliably.

PHP Site Audit checks a bounded sample of public same-host HTML pages and HTTP responses. It does not log in, inspect source code or server packages, enumerate private services, or prove exploitation or compromise.

Technology clues can also be stale. A site may have moved away from a PHP application but retain old assets or redirect paths; a vendor may serve a static cached copy of a page whose origin uses a different stack. Record the observation and the date, not a broad conclusion about the current system. If the purpose is to decide whether a patch request is relevant, the deployment owner can resolve the question more reliably than another pass over public HTML.

When contacting the operator, make the scope easy to check: provide each hostname, the pages or workflows that matter, and whether the service is production or staging. Ask whether the response came from a cache, a web server, or an application runtime if that distinction affects your inventory. A useful answer names the system and responsible team; it does not need to expose source code or credentials.

Owner checklist

List the exact domain and subdomains.
Record visible clues without treating them as proof.
Ask the host or application operator to confirm whether PHP handles each relevant route.
If PHP is present, request serving-build and vendor patch evidence.
Keep the technology finding separate from an incident investigation.

Common questions

Does a URL without .php mean the site does not use PHP?

No. Rewrite rules and application routing can hide extensions. Ask the operator what handles the route.

Does a PHP header confirm the installed build?

No. A response header is an external clue and may be changed, suppressed, or served by a different layer.

Can a public scanner identify every backend?

No. Public checks sample responses; they cannot inventory hidden services, private routes, deployed packages, or every hostname.