How to Fix WordPress Downloading Files Instead of Opening in Browser

TL;DR: If WordPress downloads index.php instead of opening your website, your server is usually not processing PHP correctly. Start by regenerating .htaccess, disabling caching plugins, and checking old AddHandler rules. If you are on Nginx or a VPS, check the PHP-FPM configuration because Nginx does not execute PHP by itself.

I have seen this issue on WordPress sites after migrations, PHP version changes, caching plugin problems, and broken server rules.

The scary part is that it looks like your site has disappeared.

But in most cases, the database is fine, the posts are fine, and WordPress is still there. The server is just sending the PHP file to the browser instead of executing it first.

In this guide, I will show you the exact order I use to troubleshoot this problem.

Important: Before touching .htaccess, plugins, permissions, or server configs, download a copy of the original file. One small backup can save you from turning a simple fix into a bigger problem.

What does the WordPress download file issue actually mean?

Short answer: your browser is receiving raw PHP instead of the finished HTML page.

When someone visits a normal WordPress page, the request usually hits index.php. Your web server passes that PHP file to PHP, WordPress runs, and the visitor receives HTML.

That is the normal flow.

When this bug happens, the flow breaks. Apache, Nginx, LiteSpeed, or your hosting control panel fails to pass the PHP file to the PHP processor. So the browser treats the file as something to download.

This is why the downloaded file is often named index.php, download, or something similar.

It is not a browser problem. Chrome, Safari, Firefox, and Edge are usually just reacting to the response your server sent.

Quick diagnosis: which fix should you try first?

Short answer: match the symptom to the most likely cause before changing random files.

My usual order is simple: .htaccess, plugins, handler rules, PHP version, then hosting/server configuration.

Do not start by restoring the whole site unless you already know the problem came from a bad update or migration. Restoring too early can waste time and overwrite useful recent changes.

Why does WordPress download index.php instead of opening?

Short answer: WordPress needs PHP, and your server is not handing PHP files to the right processor.

The common causes are:

• Corrupted .htaccess – rewrite rules are broken or overwritten by a plugin.
• Bad caching plugin rules – some cache plugins write aggressive rules into .htaccess.
• Old AddHandler or AddType lines – often copied from an older host or older PHP version.
• PHP version switch – the PHP version changed, but the handler/socket did not update cleanly.
• Nginx not connected to PHP-FPM – Nginx needs FastCGI/PHP-FPM to process PHP.
• Wrong file permissions – the server cannot read files correctly.
• Host-level configuration issue – the problem is outside WordPress and needs hosting support.

the official WordPress.org requirements page recommends PHP 8.3 or greater, MariaDB 10.6+ or MySQL 8.0+, Apache or Nginx with mod_rewrite, and HTTPS. That matters because old PHP and old handler rules are a common source of weird WordPress behavior.

If you are on shared hosting, you may not need to touch Nginx or Apache config yourself. If you are on a VPS, CloudPanel, RunCloud, CyberPanel, Plesk, or a custom stack, you may need to check the server configuration directly.

Method 1: Regenerate your WordPress .htaccess file

Short answer: this is the first fix I try on Apache or LiteSpeed hosting.

The .htaccess file controls Apache/LiteSpeed rewrite behavior for WordPress. WordPress also uses it for pretty permalinks. The official WordPress developer documentation for Apache and .htaccess says this file can be restored when a plugin or bad rule corrupts it.

Here is the safest way to reset it:

1. Open your hosting File Manager or connect through FTP/SFTP.
2. Go to your WordPress root folder, usually public_html, www, or the folder containing wp-config.php.
3. Enable hidden files if .htaccess is not visible.
4. Download a backup copy of .htaccess.
5. Rename it to .htaccess_old.
6. Open WordPress admin, go to Settings > Permalinks, and click Save Changes.

Now open the site in a private browser window.

If WordPress admin is not accessible, create a fresh .htaccess file manually with the current basic WordPress rules:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Save it as .htaccess in the WordPress root folder.

Quick note: If your site is on Nginx-only hosting, .htaccess will not control the site. Nginx does not read .htaccess. Skip to the PHP-FPM section.

Method 2: Disable caching plugins and remove cache rules

Short answer: if the issue started after cache changes, disable the cache plugin first.

Caching plugins can add rewrite rules, advanced-cache files, drop-ins, and server-level snippets. When those rules break, WordPress can behave in strange ways.

If you can access WordPress admin, deactivate your caching plugin from Plugins > Installed Plugins.

If you cannot access admin, do this from File Manager or FTP:

1. Open /wp-content/plugins/.
2. Rename the cache plugin folder first, such as wp-super-cache, w3-total-cache, wp-fastest-cache, or litespeed-cache.
3. If you are not sure which plugin is responsible, temporarily rename plugins to plugins_old.
4. Test the website.
5. If the site opens, rename the folder back and disable plugins one by one.

Also check these files if a cache plugin caused the issue:

• wp-content/advanced-cache.php
• wp-content/object-cache.php
• Cache-specific rules inside .htaccess

Do not delete these files blindly. Rename first, test, and only remove them after you confirm the plugin is the cause.

I have also written about showing dynamic content on WordPress without hurting SEO, and cache behavior is one of the first things I check there too. Caching is useful, but bad cache rules can make debugging painful.

Method 3: Remove wrong AddHandler or AddType lines

Short answer: old PHP handler lines are a common migration problem.

This happens when a site moves from one host to another, or when the host changes PHP versions. The old .htaccess may still contain handler rules for PHP 5, PHP 7, or a host-specific PHP setup.

Open .htaccess and search for lines like these:

AddHandler application/x-httpd-php5 .php
AddHandler application/x-httpd-php .php
AddType application/x-httpd-php .php

Do not delete them immediately. Comment them out first:

# AddHandler application/x-httpd-php5 .php
# AddHandler application/x-httpd-php .php
# AddType application/x-httpd-php .php

Save the file and test the site.

If this fixes the problem, keep those old lines removed or ask your host for the correct current PHP handler. If it breaks something else, restore your backup copy.

My rule: if the line mentions an old PHP version, a previous host name, or a handler you do not recognise, it deserves suspicion.

Method 4: Check the active PHP version in hosting

Short answer: if the issue started after changing PHP, switch carefully and ask the host to verify the handler.

In cPanel, Plesk, DirectAdmin, or your host dashboard, look for Select PHP Version, MultiPHP Manager, PHP Selector, or similar.

Check three things:

• The PHP version assigned to the domain.
• Whether PHP-FPM is enabled for the domain.
• Whether the same PHP version is used by the site and the handler rule.

If the site broke immediately after moving from PHP 8.1 to 8.3, you can temporarily switch back to confirm the cause. But do not treat downgrading as the permanent fix.

The better fix is to update the server handler, plugins, theme, and WordPress version so the site runs cleanly on a supported PHP version.

If you manage multiple WordPress sites, this is also why I prefer documenting server changes. The moment something breaks, you know exactly what changed.

Method 5: Fix Nginx and PHP-FPM configuration

Short answer: on Nginx, PHP files must be passed to PHP-FPM.

This is the part many WordPress users miss. Apache can process PHP through modules or handlers depending on the hosting setup. Nginx does not process PHP files by itself. It serves static files and passes PHP requests to a FastCGI backend, usually PHP-FPM.

If your Nginx server block does not include a working PHP location block, it may serve PHP as a download or fail in another way.

A typical Nginx PHP-FPM block looks similar to this:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Your socket path may be different. It could be php8.2-fpm.sock, php8.3-fpm.sock, a custom panel path, or 127.0.0.1:9000.

Check these items if you manage the server:

• The location ~ \.php$ block exists in the correct server block.
• fastcgi_pass points to the real PHP-FPM socket or port.
• The PHP-FPM service is running.
• The site root matches the WordPress folder.
• Nginx was reloaded after config changes.

sudo nginx -t
sudo systemctl status php8.3-fpm
sudo systemctl reload nginx

Do not paste random Nginx configs from the internet into a production server. Use your control panel’s generated config when possible, or test the change on staging first.

If you host on a VPS, my DigitalOcean CPU performance test may also be useful when choosing the kind of server you want to run WordPress on. Performance is one thing, but the stack still needs to be configured correctly.

Method 6: Fix file and folder permissions

Short answer: wrong permissions can cause server reading and execution problems, but do not use 777.

For most WordPress sites, the normal baseline is:

• Folders: 755
• Files: 644
• wp-config.php: often 600, 640, or 644, depending on the host

If you have SSH access, use commands like this from the parent folder after replacing the path:

find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

If you are using shared hosting, the File Manager usually has a permissions option. Apply it carefully, and avoid changing ownership unless your host tells you to.

Also check whether your files are owned by the correct user. On VPS setups, PHP-FPM may run as one user while files are owned by another. That mismatch can create confusing errors.

Security warning: Never set the whole WordPress site to 777 just because a forum comment suggested it. That can create a security problem while still not fixing the real PHP handler issue.

Method 7: Restore from backup only after isolating the cause

Short answer: backups are useful, but restoration should be the last move, not the first move.

Use backup restore if:

• The issue started after a bad migration.
• You deleted or overwrote important server files.
• A malware cleanup or failed update changed many files.
• You cannot identify the broken config and downtime is costing money.

Restore both files and database only if needed. If the issue is just a broken .htaccess file, restoring the full database is unnecessary.

After restoration, check what caused the problem before updating again. Otherwise the same issue can return the next time the plugin, PHP version, or hosting config changes.

What should you ask hosting support?

Short answer: ask them to check PHP processing, not just whether the site is down.

If you are on managed or shared hosting, send support a clear message. This saves time because many first-level replies start with browser cache advice, which is usually not the issue here.

You can send this:

My WordPress site is downloading index.php instead of rendering in the browser. Please check whether PHP is being processed correctly for this domain, whether the PHP handler/PHP-FPM service is active, and whether any old AddHandler or AddType rules are overriding the current PHP version.

If you use Nginx, add this line:

Please also verify that the domain’s Nginx server block passes .php requests to the correct PHP-FPM socket or port.

This gives support the exact area to inspect.

How do you prevent this issue in the future?

Short answer: treat server changes like code changes.

• Keep backups before changes – especially before PHP upgrades, migrations, and cache plugin changes.
• Use staging – test major plugin, theme, and PHP changes before production.
• Document PHP changes – note the old version, new version, date, and host panel setting.
• Do not copy old .htaccess blindly – especially after moving hosts.
• Use a reliable host – cheap hosting is fine until server configuration becomes your unpaid job.
• Monitor uptime – use any basic uptime monitor so you know quickly when the site breaks.

I also recommend keeping a simple text file with server notes. If you are on Mac, my guide on how to create a text file on macOS shows a few easy ways to do that.

For WordPress performance work, image and CDN changes can also affect caching behavior. My post on which image CDN I use and why covers that side separately.

Quick FAQ

Why is WordPress downloading index.php?

WordPress downloads index.php when the server sends the PHP file directly instead of processing it. The usual cause is a broken PHP handler, bad .htaccess rule, caching plugin rule, or Nginx/PHP-FPM misconfiguration.

Is this a WordPress problem or hosting problem?

It can be either, but the root is usually server-side PHP processing. WordPress plugins can trigger it by writing bad rules, but if PHP files are downloading, your server configuration needs to be checked too.

Will clearing browser cache fix this?

Usually no. Browser cache may show an old response for a short time, but it does not fix PHP processing. Clear browser cache only after fixing .htaccess, plugins, PHP handler, or server configuration.

Should I delete my .htaccess file?

Do not delete it first. Download a backup, rename it to .htaccess_old, then regenerate permalinks from WordPress. If the fix fails, you can restore the old file.

Does Nginx use .htaccess?

No. Nginx does not read .htaccess. If your WordPress site runs on Nginx, check the server block and PHP-FPM configuration instead of spending time editing .htaccess.

Can wrong file permissions cause PHP downloads?

Wrong permissions can cause processing problems, especially on VPS setups. But they are not always the main cause. Keep folders at 755, files at 644, and never use 777 across the whole site.

Summing Up!

The WordPress download file instead of opening in browser issue looks serious, but the fix is usually straightforward once you understand what is happening. The server is sending PHP as a file instead of processing it.

Start with the simple fixes: regenerate .htaccess, disable caching plugins, and remove old handler lines. If you are on Nginx or a VPS, check PHP-FPM before wasting time on WordPress settings that do not control the server.

My recommendation is simple: make a backup, change one thing at a time, test after every step, and contact hosting support if PHP processing is broken at the server level.

Which fix worked for your site: .htaccess, cache plugin, PHP handler, or hosting support? Tell me in the comments.