Pick a revalidation strategy instead of defaulting every page to revalidate: 60

You are recommending a revalidation strategy for a specific piece of content, grounded in how that content source actually behaves rather than a guessed round-number interval.

CONTENT TYPE AND SOURCE
Product detail pages, backed by a headless commerce CMS

UPDATE FREQUENCY
Prices and stock counts update several times a day; product descriptions and images rarely change after launch

TRAFFIC PATTERN
Most traffic goes to the top 200 best-selling products; the long tail of older listings gets occasional search traffic

WEBHOOK AVAILABILITY
Yes — the commerce platform supports a product.updated webhook

CURRENT REVALIDATION SETTING
revalidate: 60 is set at the top of every product page file, copied from an early prototype

DECISION FRAMEWORK
If the content source can fire a webhook on publish or update, prefer on-demand revalidation: call revalidateTag, tagged per content item rather than one tag covering the whole collection, from a Route Handler the webhook hits, instead of guessing at a time interval that will either be too slow for a real change or too frequent for a quiet week. This keeps pages fresh immediately on an actual change and avoids serving stale content for the length of an arbitrary time window between real updates. If no webhook is available, use time-based revalidation — the route segment's revalidate export or fetch's next.revalidate option — but size the interval to the stated update frequency rather than a round default; content that changes a handful of times a day doesn't need a 60-second check, and a 60-second check on content that changes weekly just refetches identical data on a schedule for no benefit. For pages with heavy traffic and rarely-changing content, a longer revalidate window combined with an on-demand revalidateTag or revalidatePath call for the rare actual update is usually a better fit than a short polling-style interval that spends most of its checks re-serving the same cached page anyway. Flag any content where staleness carries a real cost — pricing, live inventory counts, an account's current status — as a candidate for no caching at all, or a very short window scoped only to that specific field, rather than forcing ISR onto something that genuinely needs to be live on every request.

OUTPUT FORMAT
A recommendation with the specific revalidate value, or the revalidateTag/webhook design if on-demand is the right fit, one sentence justifying the choice against the stated update frequency and traffic pattern specifically, and a note on which cache tags to use, at what granularity, if on-demand revalidation applies here.