The Vercel Edge Cache Trap: Why force-dynamic Doesn't Always Work

We have autonomous AI agents publishing new stickers to Shilpiworks around the clock. But customers visiting the `/stickers` page weren't seeing them. We'd redeploy, wait, refresh — still the same stale catalog from days ago.

A quick `curl` diagnostic told us everything:

curl -sI https://shilpiworks.com/stickers | grep -E 'x-vercel-cache|age'
# x-vercel-cache: HIT
# age: 732000  # ~8.5 days stale

The page was being served from Vercel's edge cache — 8.5 days old. Our agents were publishing correctly. The database had the new products. But customers were never seeing them.

What We Tried (That Didn't Work)

Our first instinct was to add Next.js runtime directives to the page:

// Attempt 1: runtime directive
export const dynamic = 'force-dynamic';

// Attempt 2: unstable API
import { unstable_noStore } from 'next/cache';
unstable_noStore();

// Attempt 3: empty commit to trigger rebuild
git commit --allow-empty -m "force redeploy"

None of it worked. After every redeploy, `curl` still showed `x-vercel-cache: HIT` and an `age` in the hundreds of thousands of seconds.

The Root Cause

The issue is a layering problem. When Next.js statically pre-renders a page in a previous deployment, Vercel's edge network caches that HTML. On subsequent requests, the edge serves the cached HTML before Next.js even runs — which means runtime directives like `force-dynamic` and `unstable_noStore()` are never reached. They're Next.js instructions, but the edge doesn't speak Next.js.

A new deployment doesn't automatically purge the edge cache for previously-static pages. The edge keeps serving the old HTML until the cache TTL expires — which, for static pages, can be days.

The Fix

The fix is to set `Cache-Control` headers in `next.config.js`. Unlike runtime directives, these headers are applied at the infrastructure level — Vercel's edge reads them and respects them.

// next.config.js
async headers() {
  return [
    {
      source: '/stickers',
      headers: [
        {
          key: 'Cache-Control',
          value: 'private, no-cache, no-store, max-age=0, must-revalidate',
        },
      ],
    },
    // Repeat for other dynamic category pages
    { source: '/bookmarks', headers: [{ key: 'Cache-Control', value: 'private, no-cache, no-store, max-age=0, must-revalidate' }] },
  ];
}

After deploying this change, `curl` immediately showed `x-vercel-cache: MISS` and `age: 0`. New products appeared instantly.

Bonus: The www Redirect Loop

While debugging, we also discovered a related trap. Our Vercel project has `www.shilpiworks.com` configured as the primary domain, which means Vercel automatically redirects `shilpiworks.com` → `www.shilpiworks.com` at the infrastructure level.

We made the mistake of also adding a redirect in `next.config.js` pointing `www` → apex. The result: an infinite redirect loop that took down the site. The fix was to remove the code-level redirect entirely and manage the canonical domain exclusively in the Vercel Dashboard under Settings → Domains.

The Debugging Checklist

1. 1Check `x-vercel-cache` header — should be `MISS` for dynamic pages.
2. 2Check `age` header — should be `0` or very low.
3. 3If `HIT` with high `age`: the fix is `Cache-Control` headers in `next.config.js`, not runtime directives.
4. 4Verify the build succeeded in Vercel Dashboard before assuming it's a cache issue.
5. 5Never add host-level redirects in code if your infrastructure already handles them.

The mental model that unlocks this: Next.js and Vercel's edge are two different layers. Next.js runtime directives only work if Next.js actually handles the request. `next.config.js` headers work because they're compiled into the infrastructure config at build time. Know which layer owns your cache. See the live result at shilpiworks.com/stickers →