Cache-Control in WordPress: Which Cache Headers Do You Need

Having an active page cache is only half the job. The other half happens in the visitor's browser: if your files don't arrive with the correct cache headers, every visit repeats downloads that could be avoided. This guide summarizes which headers matter and how to apply them in WordPress without breaking anything.

What Cache-Control does

The Cache-Control header tells the browser (and CDNs or intermediate proxies) whether it can reuse a response and for how long. The directives you'll see most often are:

• max-age=N: seconds the browser can reuse the file without asking the server.
• public / private: whether the response can be stored in shared caches or only in the user's browser.
• no-cache: forces revalidation before reuse (it doesn't mean "don't store").
• no-store: don't store the response anywhere.
• immutable: the file never changes while its URL lives.

A different rule for each file type

HTML pages

HTML changes when you publish or edit content, so a short max-age or revalidation is advisable. If your site serves static HTML, the speed already comes from the server responding without running PHP; the browser only needs to revalidate cheaply. You can see how this works on the cache.lat how it works page.

Images, fonts, and versioned files

Files that almost never change (logos, fonts, content images) allow long times, for example one year. WordPress adds a version parameter (?ver=) to many CSS and JS files, which allows long caching: when you update the plugin or theme, the URL changes and the browser downloads the new version.

Pages with sessions, carts, or administration

Everything that depends on the user (cart, my account, wp-admin, checkout) must not be cached publicly. If a session cookie reaches a shared cache, a visitor could see another's data. Also check that your cookies aren't avoiding the cache unnecessarily.

How to verify what your site sends

1. Open the browser's developer tools, Network tab, and reload the page.
2. Click a file and look at the response headers: Cache-Control, ETag, and Last-Modified.
3. From the terminal, curl -I https://yoursite.com/file.css shows the same headers.
4. Reload with the normal cache (not with Ctrl+F5) to check that "from cache" or a 304 appears.

Frequent mistakes

• Setting a long max-age on files without a version: visitors will keep seeing the old CSS after an update.
• Using no-cache believing it "doesn't store": it actually stores and revalidates; to prevent storage it's no-store.
• Duplicating headers between the server, a plugin, and the CDN, with contradictory values. Define a single source of truth.
• Forgetting fonts and icons: they're usually heavy and get downloaded on every visit if they have no header.

How to apply it

On Apache you can use mod_expires or mod_headers in .htaccess; on Nginx, location blocks with expires and add_header. Make the change gradually, test in a staging environment, and verify with the previous tools. If your hosting limits access to that configuration, a cache plugin can handle the headers for static files.

To understand the technical details of how pages are served, review the technical data and the documentation. If you want a hand with your specific case, write to us from the TuNegocioEnLinea.net contact page.

Conclusion

Good cache headers reduce repeated downloads, improve the perception of speed on recurring visits, and relieve your server. Start with the simple: long times for versioned files, revalidation for HTML, and nothing public for what depends on the user. Then measure and adjust.