Edge Caching for Search and Category Pages That Change Prices Often
Cache search and category pages at the edge with a short TTL of 30 to 120 seconds, serve stale while revalidating, and purge by tag when prices or inventory change. Most catalog changes do not need instant global accuracy, and a brief window of staleness is far cheaper than sending every shopper to the origin.
Category and search results pages are usually the most visited pages on a store and the least cached. Teams look at how often prices, badges, and stock labels change on them and decide the only safe option is a full origin hit for every shopper. The result is predictable: the highest traffic pages get the slowest treatment, and the origin spends its capacity rebuilding near identical listings all day.
The fear is understandable but the math does not support it. A category page that is 60 seconds stale shows, at worst, a price that changed a minute ago, and the product page and checkout still show the authoritative price. What shoppers actually notice is speed. A listing that loads in 300 milliseconds converts better than a perfectly fresh one that takes three seconds.
Pick a TTL that matches how fast the catalog really changes
Start by measuring change, not by guessing. Log how often prices and inventory states on a typical category actually flip during a day. For most stores the answer is a handful of changes per hour across thousands of products, which means a 60 second TTL leaves the vast majority of cached copies accurate for their entire life. Flash sale days are the exception, and they can get their own shorter TTL or an event driven purge.
Use stale while revalidate on top of the TTL so no shopper ever waits for a rebuild. The first request after expiry gets the slightly old copy instantly while the edge refreshes it in the background. Combined with stale if error, the same cache becomes insurance: if the origin stumbles during a traffic spike, shoppers keep browsing listings instead of seeing error pages.
Purge by tag, not by URL list
Tag every cached listing page with the product IDs it contains, plus its category and search term. When a price or stock update lands, purge the tag and only the affected pages drop out of cache. This is the piece that makes short TTLs feel safe to merchandising teams, because a change they care about can be forced live in seconds without flushing the whole catalog.
Keep the purge path boring and tested. A webhook from the commerce platform on product update, a small queue, and a purge call per changed tag is enough. The failure mode to avoid is a purge system nobody trusts, because teams respond to doubt by shortening TTLs until caching barely helps. Log purge latency and sample live pages after big updates so trust is based on evidence.
What to keep out of the shared cache
Anything personal stays out. Cart counts, recently viewed rails, loyalty pricing, and location specific banners should load as separate fragments or client side calls, never baked into the shared listing copy. Cache the anonymous shell that every shopper shares and personalize around its edges. Stores that mix personal data into listing HTML end up bypassing cache entirely, which is how this pattern gets its bad reputation.
Sort order and filters belong in the cache key, but keep the key space under control. Every distinct filter combination is a separate copy, and low traffic combinations waste memory without helping anyone. Cache the first page of popular sorts aggressively, let deep filter combinations pass through or cache briefly, and review the key list monthly against real traffic.
Related reading
Readers working through this topic often find these earlier guides useful as well: How Edge Personalization Works Without Slowing the Storefront Down, Storefront Latency Budgets: How to Set and Enforce One.
Frequently asked questions
How stale can a category page be before shoppers notice?
Most shoppers never notice staleness under a few minutes because the product page confirms the current price before they commit. Problems start when a sold out item keeps appearing for a long window, which tag based purging on inventory changes solves directly.
Does edge caching search pages hurt SEO?
No, as long as the cached copy is the same HTML a crawler would get from the origin. Search engines care about content and speed, and a fast cached page is strictly better than a slow uncached one with identical markup.
What TTL should a store start with?
Sixty seconds with stale while revalidate is a safe starting point for most catalogs. Measure origin offload and price accuracy for a week, then lengthen or shorten per category based on how often each one actually changes.
Can I cache listing pages during a flash sale?
Yes, and that is when caching matters most. Shorten the TTL, lean on stale serving during origin stress, and wire inventory purges so sold out products drop quickly. The cache absorbs the spike that would otherwise hit the origin at its busiest moment.