WP Super Cache Downloading a File Instead of the Page?

The short answer

If visitors get a download prompt or a screen of strange characters instead of your page, WP Super Cache is probably serving its compressed .html.gz cache file without the header that tells the browser it is compressed. Turn off the plugin’s own compression and let the web server compress pages instead. If the site is a WooCommerce store, also keep WP Super Cache in Simple mode, because Expert mode’s rewrite rules never look at WooCommerce’s cart cookies.

Simple mode and Expert mode

Both modes save a static HTML copy of each page. In Simple mode a request still starts PHP: WP Super Cache checks the visitor’s cookies and its own settings, then sends the saved copy. In Expert mode, Apache’s rewrite rules find the saved file and send it without starting PHP at all. That is why Expert mode does less work per page, and why anything the rewrite rules do not check is never checked. Both problems below come from that.

Problem 1: the gzip file is served as a download

In Expert mode, WP Super Cache serves cached pages straight from Apache with rewrite rules, before WordPress loads. With compression switched on, it also saves a gzipped copy of each page and writes these lines into wp-content/cache/.htaccess, so Apache labels the file correctly:

<IfModule mod_mime.c>
  <FilesMatch "\.html\.gz$">
    ForceType text/html
    FileETag None
  </FilesMatch>
  AddEncoding gzip .gz
  AddType text/html .gz
</IfModule>

On a server I manage, Apache did not apply them. The .gz file went out as application/x-gzip with no Content-Encoding header. A browser that gets that does not unpack it. It offers to download the file, or shows the compressed bytes.

Why quick tests miss it

A plain curl request does not say it accepts gzip, so the rewrite rule skips the .gz file and Apache sends the uncompressed copy, which looks perfect. The plugin’s own status screen says caching works. And a logged-in administrator never gets cached pages at all. You only see the fault when the request looks like a real visitor’s. Test like this:

UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/128"

curl -s -D - -o page.bin -H "Accept-Encoding: gzip" -A "$UA" \
  https://example.com/

head -c 2 page.bin | xxd

Read the two results together. If the body starts with 1f8b, the gzip signature, the headers must include Content-Encoding: gzip. If they do not, browsers are being handed a raw gzip file. If a CDN sits in front of the site, test the origin server directly, or the CDN may hand you an older copy.

The fix for problem 1

In WP Super Cache’s Advanced settings, turn off the option to compress pages, then delete the cache so the old .gz files go. Pages are still compressed: Apache’s mod_deflate compresses the cached HTML on the way out and sends the correct header. Run the same test again and confirm the response carries Content-Encoding: gzip. If it does not, ask your host to turn on compression on the server.

Problem 2: shoppers with a cart get cached pages

WP Super Cache has a rejected-cookies list, and WooCommerce’s cart cookies belong on it: woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_. In Simple mode that works, because PHP checks the cookies before it serves a cached page.

In Expert mode the cached page is served by Apache before PHP runs, so the only cookies that count are the ones written into the rewrite rules. This is the cookie condition the plugin writes:

RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$

The rejected-cookies list is not in it. So a shopper with items in the cart can be handed the same cached page as everyone else, with a stale cart count or mini-cart, depending on how the theme builds it. WooCommerce stops its cart, checkout and account pages from being cached, so checkout itself still works, but the rest of the store can look wrong to the person most likely to buy.

The fix for problem 2

Keep WooCommerce stores in Simple mode. It is still a full-page cache, and it respects the rejected cookies. Use Expert mode on sites with no cart. That is how I set it on the sites I run with WP Super Cache: brochure sites in Expert mode, stores in Simple mode.

The plugin also has a wpsc_add_cookie action, and cookies registered through it are written into the rewrite rules. I have not relied on it for stores. If you try it, test it like this:

UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/128"

curl -s -A "$UA" -H "Cookie: woocommerce_items_in_cart=1" \
  https://example.com/shop/ | grep -c "WP-Super-Cache"

With a cart cookie, the page should not carry WP Super Cache’s “Cached page generated by WP-Super-Cache” comment near the end of the HTML. If the count above is not zero, shoppers are getting cached pages.

After any caching change

• Delete the plugin’s cache, and your CDN’s cache if you use one.
• Test logged out, as a browser would, with Accept-Encoding: gzip.
• On a store, test again with a cart cookie.
• If you look after several sites, change one at a time and stop at the first failure.

Caching problems are among the most common reasons a site that worked yesterday is broken today. If yours is one of them, WordPress repair is where I start, and if it is a store, the WooCommerce developer page covers the rest of what I do for shops.

Frequently asked questions

Is Expert mode faster than Simple mode?

Expert mode skips PHP entirely, so it does less work per page. Simple mode is still a full-page cache and is fast. On a store, Simple is the safe choice.

Should I use WP Super Cache on a WooCommerce store?

It can work well in Simple mode, with the WooCommerce cookies in the rejected-cookies list. Test with a cart cookie after every change.

Why did my site look fine when I checked it?

Logged-in administrators never get cached pages, and simple tools do not ask for gzip. Test logged out, as a real browser would.

Do I lose compression if I turn off the plugin’s compress option?

Not if the server compresses pages. Most Apache hosts have mod_deflate on. Check the response for Content-Encoding: gzip after the change.

How do I know which mode my site uses?

WP Super Cache’s Advanced settings show the cache delivery method, Simple or Expert. Expert mode also adds a block of rules marked WPSuperCache to the .htaccess file in the site’s root folder.