Astro 5.7 and Netlify Cache API for Campaign Pages That Stay Fresh

On launch mornings, stale copy is expensive in a way engineers sometimes miss. A Google Ads campaign can burn through $500 before lunch, and one outdated “20% off” line on a UTM-specific landing page can send the whole team into screenshot archaeology. I have seen the same failure on Astro, Next.js, Webflow, and hand-rolled static sites: the CMS is correct, the page in production is wrong, and nobody wants to rebuild 1,200 pages to fix one approved offer.

Astro 5.7 and Netlify’s 2026 cache work give us a cleaner option. Astro 5.7 shipped on April 15, 2025, after Astro 5.0 made the Content Layer stable on December 3, 2024. The useful part for marketing sites is the loader model. A collection in src/content.config.ts can pull from local files with glob() or file(), or from a remote CMS through a custom loader. Netlify’s Cache API added full stale-while-revalidate support on February 27, 2026, and its cache controls now include durable cache, cache tags, query-aware variation, and on-demand purges through purgeCache or the https://api.netlify.com/api/v1/purge endpoint. Those details matter. They move freshness from “kick a full deploy” to “refresh this campaign object.”

The architecture I like is boring. That is the point. Keep the approved campaign copy in Contentful, Sanity, Storyblok, Hygraph, or whatever CMS your team already trusts. Load the canonical campaign records into Astro’s Content Layer at build time. Render the broad page shell statically. Put fast-changing pieces, like offer disclaimers, inventory counts, countdown copy, partner logos, or geo-specific proof points, behind a Netlify Function that uses the Cache API with tags such as campaign:q4-demo, offer:starter-2026, and utm:linkedin-ciso.

Astro’s loader pattern is the first half of the fix. The official Content Loader API docs say a loader can be a simple async function returning entries with unique id fields, or an object loader with load(), store, meta, and logger. For a campaign collection, I want the object form. The meta store is where I keep a CMS sync token, a lastModified value, or a Contentful sys.updatedAt timestamp. When only 9 records changed out of 480 campaign variants, the loader can update those 9 entries instead of pretending every landing page is new.

That pays off during build. Astro’s own 5.0 release notes said Content Layer made Markdown-heavy collections build up to 5x faster and MDX up to 2x faster, with memory use down 25% to 50%. Your CMS campaign records are not Markdown files, but the principle carries over: Astro wants a typed content snapshot, not 15 different fetch calls scattered across page components. In src/pages/campaigns/[slug].astro, getStaticPaths() can read getCollection('campaigns'), generate stable URLs, and pass the campaign entry as props. Your founder gets fast pages. Your marketing operator gets fields that match the approval workflow.

I would not put every UTM variation into the static build. That way lies pain. A realistic B2B launch might have 6 core offers, 4 personas, 5 channels, and 3 regions. That is 360 variants before you add retargeting, partner pages, or sales-led ABM paths for accounts like acme-industrial and northstar-health. Build the canonical route, then vary the runtime response only on the query parameters that change the experience. Netlify’s cache settings support vary.query, including named query parameters, so you can vary on utm_campaign and utm_content without letting every stray fbclid create a new cache object.

Netlify’s side is where the 2026 primitive matters. With @netlify/cache, fetchWithCache() can cache a CMS or offer-service response with ttl, swr, tags, durable, and vary. The February 2026 changelog says SWR now works fully in the Cache API: a stale response can return immediately while a fresh response is fetched and cached in the background. For a paid launch, I might set approved offer copy to ttl: 300 and swr: 3600. That gives a five-minute fresh window and a one-hour cushion where visitors still get a response if Contentful has a slow minute.

Use durable cache for Netlify Functions when the same campaign fragment is requested from multiple edge nodes. Netlify’s docs are clear that durable is for serverless function responses, not Edge Function responses. It reduces repeated function invocations because edge nodes can reuse a shared durable cache entry instead of invoking the function every time a local edge cache misses. For a microsite getting 80,000 paid sessions in 48 hours, that difference shows up as fewer cold starts, fewer CMS API hits, and fewer mysterious slow first views from regions nobody tested during QA.

Cache tags are the operational trick. When a CMS webhook says starter-annual-discount changed at 09:14 UTC, your webhook handler should purge offer:starter-annual-discount and maybe campaign:spring-demo-2026. Netlify supports tag-based purging through the purgeCache helper in a function or through the purge API with a personal access token. Its caching docs also note a rate limit of two purges per cache tag or site every five seconds. That is enough for editorial workflows, but it means you should batch noisy CMS webhooks. Do not fire 80 purge calls because one editor corrected a comma across localized entries.

The page contract can stay simple. Astro owns durable structure: route, meta title, hero layout, schema validation, legal fallback copy, and the default CTA. Netlify Functions own volatile fragments: approved offer, channel-specific headline, localized proof point, pricing footnote, or form routing hint. The CMS owns approval. Google Ads, Meta, LinkedIn Campaign Manager, and HubSpot only pass context through URLs and hidden form fields. Nobody in paid media should need to know whether getCollection() ran at build time or whether the offer fragment came from fetchWithCache().

I use three rules when splitting static and cached content. First, anything that affects SEO should be present in the Astro-rendered HTML for the canonical page. That includes the main H1, title tag, description, and default offer. Second, anything that changes after launch review gets a cache tag. A webinar date, speaker name, discount percentage, or regional compliance line needs its own invalidation path. Third, UTM-specific copy should degrade cleanly. If utm_content=linkedin-ciso-q3 misses the cache or maps to nothing, the page should show the canonical CISO page, not a blank headline.

The loader schema is your guardrail. Use Zod in src/content.config.ts for fields like id, slug, status, offerId, persona, channel, startsAt, expiresAt, and legalCopy. I like status: z.enum(['draft', 'approved', 'archived']) because it matches how marketing teams already talk. The loader can fetch from Sanity or Contentful, filter to approved, and write entries into Astro’s store. If a campaign expires on 2026-11-01T00:00:00Z, fail the build or route it to a fallback. Bad campaign state should break in CI, not in front of 3,000 visitors from a Monday Meta spend spike.

There is one catch people miss: Astro’s Content Layer snapshot is updated at build time. The Astro deep dive from September 18, 2024 says the deployed data store does not mutate in production. That is fine. Treat it as the approved baseline. The Netlify Cache API handles the parts you expect to change between deploys. If the product marketing manager rewrites the whole positioning page, rebuild. If legal changes “save 20%” to “save up to 20%” at 2:37 p.m., purge the offer tag and let the cached fragment refresh.

For observability, log the boring fields. I want campaign_id, offer_id, utm_campaign, cache hit state, CMS updatedAt, and the cache tag list in every function log. Netlify’s Cache API docs expose cache status helpers such as durable and edge hit information through @netlify/cache, and the base API has operation limits: 100 lookups and 20 insertions or deletions per invocation. Those limits are generous for a landing page fragment. They are not generous for a function that loops through a whole CMS collection because somebody skipped the loader.

A workable first version takes a day. Start with Astro 5.7, @astrojs/netlify, and one campaigns collection. Load 20 approved campaign records from your CMS into Astro. Add one Netlify Function at /.netlify/functions/offer-fragment that accepts campaign_id and the two UTM fields you actually use. Cache the CMS response for 300 seconds, give it a 3,600-second SWR window, tag it by campaign and offer, and purge those tags from a signed CMS webhook. Then test three paths: a fresh publish, an offer edit, and an expired UTM value.

This setup will not make sloppy campaign operations good. It will make good operations faster. The CMS stays the source of approved truth. Astro 5.7 gives you typed, build-time campaign structure. Netlify’s 2026 cache primitives give you runtime freshness without turning every click into a CMS request. For founders and marketing operators, that means fewer rebuilds, fewer stale paid pages, and fewer Slack threads that start with a screenshot and end with someone asking who owns the landing page.

Sources: Astro 5.7 release, Astro 5.0 release, Astro Content Loader API, Netlify Cache API, Netlify caching overview, Netlify SWR Cache API changelog.