Varnish can make a WordPress site feel dramatically faster, but only when it is configured as part of a clear cache stack. Many site owners hear that Varnish is “server cache” and assume it is either automatically working or impossible to understand. The truth is more practical: Varnish is a reverse proxy that can store public HTML responses and serve them quickly before PHP and the database get involved.
That makes it powerful for blogs, documentation sites, publishers, and marketing pages. It also means the rules matter. Varnish needs to know which pages are public, which cookies should force a bypass, which URLs must never be shared from cache, and when a page should be purged after WordPress content changes.
Where Varnish sits
In a common WordPress stack, the visitor reaches a CDN first, then the web server or reverse proxy, then PHP, then the database. Varnish usually sits in front of the origin web server. When a request is cacheable and Varnish has a fresh copy, it can return the HTML without asking WordPress to rebuild the page.
That is why Varnish often reduces time to first byte. The expensive part of WordPress is not downloading HTML; it is booting WordPress, loading plugins, running queries, rendering templates, and producing the response. A cache HIT skips most of that work.
What a healthy Varnish result looks like
A normal pattern is first request MISS, second request HIT. The first logged-out visitor warms the cache. The next visitor receives the stored response. Depending on the host, you may see Age increasing, X-Cache showing HIT, Via mentioning Varnish, or X-Varnish carrying internal request identifiers. Header names vary, so do not rely on one marker alone.
The most useful test is repeatable: open a public URL while logged out, request it twice, compare headers, then update the post and check whether the cached copy is purged. A cache that serves fast old content forever is not healthy. It is just stale.
Common WordPress mistakes
The first mistake is running Varnish and a full page-cache plugin without understanding which layer owns HTML caching. Sometimes the plugin is only needed for purge integration. Sometimes the plugin should not cache pages at all. Sometimes both layers are active and each believes it controls the final response.
The second mistake is letting cookies bypass everything. WordPress, WooCommerce, consent tools, analytics scripts, security plugins, and membership plugins can set cookies. Some cookies are harmless; others imply personalization. Varnish rules often err on the side of safety and bypass when cookies are present. That can make every public page uncached.
The third mistake is poor purge behavior. Editors update a post, WordPress changes the content, but Varnish keeps serving the old HTML. Good purge integration should clear the updated post, related archive pages, the homepage if needed, feeds, and other affected URLs.
Varnish and WooCommerce
WooCommerce needs extra care. Product pages can often be cached for logged-out visitors, but cart, checkout, account, and session-sensitive pages should bypass public cache. A fast checkout page is not worth the risk of showing one customer another customer’s state.
If a site has WooCommerce, test both safe public pages and private flows. The correct result is not “everything HIT.” The correct result is “public pages HIT, private pages BYPASS, and cart behavior remains accurate.”
How WPColt thinks about Varnish
WPColt Cache Inspector treats Varnish as one possible layer in a broader WordPress cache map. It is not enough to detect that Varnish exists. The report needs to explain whether the homepage and a post show cacheable behavior, whether headers support that conclusion, and whether another layer may be confusing the result.
If the report says Varnish cannot be verified, that does not always mean Varnish is absent. Some hosts hide headers. Some CDNs sit in front and mask origin behavior. In those cases the next step is to check host documentation, CDN response headers, and any plugin that controls purge events.
Verification checklist
- Test while logged out, not as an admin.
- Request the same public URL twice and compare headers.
- Look for Age, X-Cache, X-Varnish, Via, Cache-Control, and Set-Cookie.
- Update a post and confirm the old cached HTML disappears.
- Check that WooCommerce cart, checkout, and account pages are bypassed.
- Disable duplicate page-cache behavior before changing advanced VCL rules.
Bottom line
Varnish is not magic, but it is one of the strongest caching layers a WordPress site can use. The win comes from clear responsibility: Varnish serves public HTML quickly, WordPress triggers purges when content changes, private pages stay private, and other caching plugins do not fight the server. Once you can verify those facts, the cache stack becomes much less mysterious.