Verified against Claude Code · 2026-07-09
Pick a revalidation strategy instead of defaulting every page to revalidate: 60
Matches ISR revalidation to how content actually changes — time-based, on-demand via revalidateTag, or a mix — instead of a copy-pasted 60-second default.
The prompt
Ready to copy — highlighted parts are example details you can swap.
<context>
Content type and where it lives: Blog posts authored in a headless CMS
How often the underlying content actually changes, and who changes it: A handful of posts published or edited per week, at unpredictable times
Traffic pattern for these pages: Most traffic goes to the 10 most recent posts; older posts get occasional search traffic
Does the CMS/data source support outgoing webhooks on publish/update: Yes — the CMS supports a publish webhook
</context>
<task>
Recommend a revalidation strategy for this content — don't default to a flat time-based revalidate value without checking whether on-demand revalidation fits better.
</task>
<decision_framework>
- If the content source can fire a webhook on publish/update, prefer on-demand revalidation: call revalidateTag (tagged per content item, not one tag for the whole collection) from a Route Handler the webhook hits, instead of guessing a time interval. This keeps pages fresh immediately on change and avoids serving stale content between arbitrary time windows.
- If there's no webhook available, use time-based revalidation (the revalidate export or fetch's { next: { revalidate } } option), but set the interval based on the stated update frequency, not a round-number default — content that changes a few times a day doesn't need a 60-second check.
- For pages with heavy traffic and rarely-changing content, a longer revalidate window plus an on-demand revalidateTag/revalidatePath call for the rare actual update is usually better than a short polling-style interval that mostly serves the same cached page anyway.
- Flag any content where staleness has a real cost (pricing, inventory, live status) as a candidate for no caching at all (or a very short window) rather than trying to force ISR onto something that needs to be live.
</decision_framework>
<output_format>
A recommendation with the specific revalidate value or revalidateTag/webhook design, one sentence justifying the choice against the stated update frequency and traffic pattern, and a note on which cache tags to use if on-demand revalidation applies.
</output_format>Customize the highlighted detailsoptional — the prompt above already works
Why this works
A flat revalidate: 60 is the single most copy-pasted line in ISR examples, and it's usually wrong in both directions at once: too slow for content that just changed and needs to be live now, and too frequent for content that only changes a few times a week, which means most of those 60-second checks refetch identical data for no benefit. Framing the choice as a decision tree — webhook available means prefer on-demand revalidateTag, no webhook means size the interval to the actual update frequency — replaces a guessed number with a strategy grounded in how the content source actually behaves. Tagging per content item rather than per collection is the detail that keeps on-demand revalidation useful at scale: a single global tag means every update invalidates everything, which defeats the purpose of caching in the first place.
What you get back
Recommendation: on-demand. The CMS supports a publish webhook, so a Route Handler at /api/revalidate calls revalidateTag('post-' + slug) when that webhook fires, tagged per post rather than one 'posts' tag for the whole blog. Fallback revalidate: 3600 (1 hour) stays as a safety net in case a webhook call is ever missed — not the primary freshness mechanism.
Verified against
Claude Code Sonnet 4.6 · 2026-07-09
Cursor 2.1 · 2026-07-15
Changelog
- 2026-07-09 — Initial version, tested against Claude Code on a Next.js 16 blog with on-demand revalidation via a CMS publish webhook.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
