WordPress downloads a PHP file instead of displaying the site: secure and repair it

When a page triggers an unexpected download

You open your WordPress site or its usual login page, and the browser offers to save a file instead of displaying the page. The name sometimes resembles index.php or wp-login.php. The aim is twofold: prevent possible distribution of internal files, then restore pages that PHP executes correctly.

PHP is the engine that executes WordPress code on the hosting server. Visitors should receive the result of that work, usually an HTML page, rather than the program that produces it. If PHP code has already been visible, treat this as possible exposure and contact the host immediately.

Stop repeated tests. Cancel new downloads and do not ask others to reproduce the problem. Do not run the received file, publish it on a forum, or send it to a public analyser. The observations already available are enough to open an incident.

Have the problem contained before looking for a repair

Contact support from the known hosting account, even if WordPress no longer opens. Report an unexpected download in place of a page, with possible disclosure of PHP source. Request a temporary block on public access to the affected site, implemented at the server or the service in front of it.

This protection must work independently of PHP. A maintenance plugin or setting executed by WordPress is no guarantee when the server no longer passes scripts to the engine. Have the provider specify the mechanism used and its activation time.

Ask the provider to cover the site’s paths, not just the homepage, as well as domain variants and origin access. The origin is the server hosting the files behind any intermediary. Protection on the main domain alone may leave another route accessible. Containment must also prevent an intermediate cache from continuing to serve the incorrect response.

Support must confirm containment through its own checks. If it cannot guarantee it, ask for escalation to the technical team and keep the incident open. Do not remove the restriction to check for yourself whether downloads continue.

Keep useful evidence without searching for secrets

Record the time with the time zone, observed address, proposed download name, and action that triggered it. Remove parameters containing a token or personal data from your working record. Also note when the page last worked and nearby changes: migration, an added domain, a PHP setting, or provider intervention.

If a file has already been saved, keep that original unchanged in a private location with restricted access. Do not open it to search for passwords or create a copy in the media library. Ask support how to send it only if examination is necessary, and use a secure channel.

Have available logs and the configuration state preserved before changes. The provider can retain technical material in its protected area; you do not need to download the entire installation. A backup with a different filename suffix inside the public directory could itself become accessible.

Record who intervenes and when. This preservation must accompany urgent containment without delaying it while a perfect case file is assembled.

Distinguish an intended download from PHP source served by mistake

A link to a document, invoice, or export can legitimately download a file. Its address may even end in .php: the script then prepares the document. Neither the address name nor the name proposed by the browser therefore demonstrates that server code was exposed.

An HTTP header, meaning information accompanying the response, can request saving with Content-Disposition: attachment. The content type stated by Content-Type also describes the expected handling. These indications are not enough to establish whether PHP executed the request.

Have support classify the response already observed: an intended document, an HTML page sent with incorrect headers, or a source file distributed without execution. It can use the configuration and the original retained privately.

Do not trigger new downloads to decide. Above all, do not try configuration-file addresses to see which are accessible. If the file’s nature remains unknown, retain the precaution of possible exposure until the provider reaches a conclusion.

Identify the environment and required access

This guide mainly concerns self-hosted WordPress. Corrections require hosting management access or support; being a WordPress administrator does not automatically grant those permissions. Use your authorised account without borrowing the provider’s credentials.

On WordPress.com or a fully managed plan, send the symptom to the service managing the site. Do not transfer a cPanel or Plesk setting to an interface that does not offer it. On a multisite network, involve the network manager: several sites may share the same engine and files.

Record known WordPress, PHP, and panel versions from information already available. If administration is inaccessible, let support confirm them. Interfaces and labels may vary by version; do not enable a neighbouring option simply because it contains the word PHP.

Choose between three approaches after containment

The first approach concerns the domain’s association with its hosting. It becomes relevant after adding a domain, migrating, or changing directories. Check that the request reaches the correct site with PHP enabled for it.

The second addresses routing scripts to the PHP engine. It applies when the domain and directory are correct but a handler or recent configuration appears responsible.

The third examines response headers and intermediaries: proxy, delivery service, and cache. It also applies when PHP works but the page is sent as an attachment. Choose it if results vary by route or persist after a confirmed correction at the origin. These differences must come from existing observations or support’s private checks.

These paths can complement each other, but they are not three mandatory consecutive changes. The provider chooses a correction supported by the facts and keeps the public restriction in place during the intervention.

Approach 1: check the domain and its directory

In the hosting panel, the authorised person selects the exact domain, then examines its document root: the directory whose content the server publishes. They compare that location with the expected installation and record the current value before any change.

A domain may reach an old server, a default site, or a directory intended for static files. Have the domain association, DNS destinations, and site configuration selected by the server compared. DNS information directs the domain name; changing it alone does not configure PHP.

Do not move WordPress folders to match an assumed path. Ask the provider to confirm the expected destination, aliases, and HTTPS behaviour. A change is applied only after this confirmation.

The expected result is a consistent match between the domain, correct directory, and intended PHP environment. If these elements were already correct, move on to PHP processing. If a correction fails, have support restore the documented value while maintaining containment.

Check the domain’s PHP support in Plesk

Plesk documentation describes this symptom when PHP support is disabled for the domain. With the necessary hosting access, open Domains, select the affected domain, then PHP Settings. The interface may use these English labels.

First inspect the PHP support option without changing the version or execution mode at the same time. Have the provider confirm that PHP should be active for this domain, that the directory is correct, and that temporary protection will remain in place.

After the provider agrees, enable only this option if it was disabled, then confirm with OK. Support then checks the site’s processing under protected conditions. If the option was already active, unticking and reticking it does not provide a diagnosis.

If the result remains incorrect, record the lack of improvement and let support examine the handler. Any restoration of the earlier setting must take place under containment; it must never reopen public distribution of PHP files.

Approach 2: restore PHP processing of scripts

The PHP handler is the association telling the server how to process a script. With Apache, directives such as AddHandler or SetHandler may be involved. With Nginx, the server may forward the request to a PHP service through FastCGI. An installed engine does not prove that this domain sends its requests to it; terminal PHP may also differ from the website’s PHP.

Required access for the following case: an authorised cPanel account, containment maintained, and a domain version shown to be incorrect. The target version must be maintained, available, and already validated for the components. This path corrects the domain’s association/version; it does not guarantee repair of a global handler or faulty server configuration. Before Apply, verify that the previous value remains selectable or that the administrator has another documented rollback. Without that possibility, have the administrator perform the intervention.

MultiPHP Manager for cPanel does not by itself control all PHP-FPM administration. Enabling or repairing it in WHM is the administrator’s responsibility. If several domains share a document root, the FPM scope may affect them together. Do not apply several competing PHP selectors or choose an old version at random.

Expected result: under the protected check arranged with hosting, the correct site executes PHP and displays its page. If this fails, do not repeat switches; return to the recorded version only under containment and have the effective handler examined. Restoring a value must never reopen public source distribution.

1. In cPanel, open Software, then MultiPHP Manager. Find the exact domain and record its current version and any inheritance.
2. Select only the confirmed domain. In PHP Version, choose the maintained version already validated, without changing other domains.
3. Click Apply and wait for confirmation. If the version is unavailable or a restriction prevents rollback, involve the administrator instead of using another manager.
4. Have the output checked under the protected conditions of containment. A version number displayed in the panel alone does not prove that PHP executes the request.
5. If the setting has no effect, retain the result and have the loaded handler, script path, and logs compared before another change.

Preserve existing .htaccess rules

On some Apache hosting, an incorrect handler in .htaccess may cause downloading. This does not justify replacing the whole file with standard WordPress permalink rules. It may also contain access restrictions and provider-specific settings.

Ask support to identify the incompatible directive, its origin, and the correct value for its environment. Support keeps a private copy of the original, then changes only what is necessary. Do not leave a backup of this file in the public directory.

When Nginx serves the site without Apache, it does not read .htaccess files: its configuration must be corrected at server level. If Nginx sits in front of Apache, Apache rules may still apply behind that proxy. Have this architecture confirmed before choosing the file to examine.

The check must demonstrate that scripts execute while existing protections remain intact. If the change fails, support returns to the saved state or prepares another correction under containment. A MIME-type change alone does not prove that the interpreter works.

Approach 3: examine headers, the proxy, and caches

If support confirms that PHP produced an HTML page but a header forces its download, have the layer adding that header identified: application, server, or proxy. Correct only the demonstrated setting, keeping its previous value. Changing PHP version does not resolve an incorrect header. This branch assumes that source distribution has been ruled out, not merely that the file has a reassuring extension.

A proxy receives the request before forwarding it to hosting. A cache stores a response to serve it again. Incorrect routing may reach the wrong site; a cached copy can also prolong distribution of an incorrect response after the origin is repaired.

The presence of a delivery service does not prove it stored this response. Cloudflare does not cache HTML pages by default, and .php is not among its automatically cached extensions. Custom rules may change this behaviour: have active rules and available traces checked.

The person responsible for these services compares their rules, logs, and the initial request’s details. They check which server responded and whether a copy was retained. Clearing only your browser cache does not remove a response held by an intermediate service.

After useful evidence is preserved and the route corrected, have the affected copies removed using the service’s features. On Cloudflare, URL purging has limitations when custom cache keys create several variants. The responsible person must therefore confirm the purge’s actual scope.

Do not disable the proxy globally to expose the origin publicly. Keep its access restrictions and HTTPS protection. If an incorrect response remains available, containment continues: the provider checks variants and rules again instead of asking visitors to refresh.

Read the headers of the response already captured

Required access for observation: a response already captured in the browser, or an authorised private check with the administrator after containment. Do not open a new public URL to recreate evidence. If Network recorded nothing, it cannot retrieve the response retroactively; use existing material and server-side examination.

The expected result is a record of useful headers, not proof of execution based on MIME type alone. This inspection does not change the server and needs no rollback. Keep the restriction in place until the nature of the response and the correction are established.

1. In developer tools, open Network and select the exact request already captured. During an arranged private check, select only the ordinary page designated by the administrator.
2. Open Headers, then Response Headers. Do not resend the request using a replay command.
3. Record Content-Type and Content-Disposition, with the proposed filename cleaned if necessary. An intentional download may use attachment and a .php URL without exposing code.
4. Record any cache indications present, such as Cache-Control or Age, and the advertised service. Their presence or absence does not replace logs or checking active rules.
5. Share only this cleaned excerpt through the planned private channel, without cookies, Set-Cookie, or a complete network export. Never use wp-config.php as a test URL.

Assess exposure without testing sensitive files

A repaired page does not establish that nothing was distributed earlier. Ask the provider to distinguish files actually served, those potentially affected, and remaining unknowns. The time you noticed the problem is not necessarily when it began.

Examination takes place on the hosting side using configurations, logs, and material already preserved. Do not request an HTTP download of wp-config.php, an archive, or another internal file. You do not need to prove exposure by retrieving new data.

If secrets were exposed or are considered potentially compromised, the responsible person must revoke and replace them promptly with the services concerned. The plan must account for dependencies so WordPress uses the new access. Restoring a value to repair a connection must not reactivate a compromised secret.

This intervention accompanies containment; it must not wait for the site to reopen. Deleting a public copy does not make an already disclosed secret confidential again. Keep the values themselves out of the report.

Verify the repair before reopening publicly

First ask support for validation under protected access, on existing ordinary, non-sensitive pages. It must confirm correct PHP processing, the correct domain, and removal of incorrect intermediate copies. An HTTP 200 status or a displayed image is not enough.

Do not create a public phpinfo() page or an additional diagnostic script. These files may expose configuration information and do not, on their own, validate the site’s entire request path. The provider has verification methods within its environment.

When the responsible person authorises reopening, check the homepage, an internal page, and the usual login form. The browser should display the expected pages without unexpected downloads. Once login is validated, open a normal administration screen without initiating a real payment or sending operation.

Have the intended domain and protocol variants confirmed separately. If downloading returns, stop testing and request immediate reinstatement of containment. Keep the check time to correlate this new event with logs.

Prepare a rollback that keeps protection in place

Before each correction, the provider records the setting, its scope, and how to restore it. Temporary protection remains separate from this rollback: restoring an earlier configuration must not make sources accessible again.

If several sites share the server or a handler, ask which may be affected by a reload or global change. The responsible person chooses the appropriate scope and checks. Do not restart all hosting solely on the basis of a tutorial.

A full WordPress restoration is not the first remedy for a misconfigured domain. It can overwrite recent content while leaving the server cause intact. If it becomes necessary for a demonstrated reason, preserve files and the database, and prepare recovery with support.

Any test copy must remain protected and isolated, with its own database and real payments, emails, and external automation disabled.

Provide a precise case and prevent recurrence

Keep a simple record: affected domain, observation time, last known working period, migration or PHP-change context, received filename, and measures taken. State what was observed and what remains assumed. A download named with .php does not justify announcing that every password was stolen.

Ask for a written response about the identified cause, containment, correction, caches handled, and reopening checks. If logs are incomplete, that limitation must remain explicit. Screenshots and excerpts sent to support must exclude cookies, tokens, and data unrelated to the problem.

For the future, keep the validated configuration and emergency contact outside the site. Before a migration or PHP-handler change, arrange checks of domains and page processing, along with containment independent of WordPress if validation fails.

Follow-up must cover the site’s operation and the consequences of any possible exposure. The host and site manager may close these two parts at different times.

Separate configuration validation from PHP validation

On a managed Apache server, the administrator has a syntax check available before applying a correction. This check belongs to hosting; it is not run inside WordPress and does not restore any handler by itself.

The command name and Apache environment must match the service actually used; the host may provide a distribution-specific variant. A Syntax OK result means that the examined configuration passes that check. It proves neither that the correct domain is selected, nor that PHP executes scripts, nor that public access remains contained. Do not authorise reopening on that result alone.

The administrator first retains the previous configuration in a private location, checks the correction, then performs the reload appropriate to the service. They then repeat the private output and protection checks described above. If validation fails, they correct the identified directive before any reload. In a rollback, they restore only the relevant configuration while keeping the public restriction.

On a plan without server administration, convey this distinction to support: no free or paid plugin replaces repairing PHP processing upstream of WordPress.

apachectl configtest