Hi Alaa,

I’d separate the stale HTML document from stale /_next/static/... assets first.

For a Next.js app, old hashed JS/CSS files being cached with x-vercel-cache: HIT can be normal. The real problem is if the live domain’s HTML is still referencing old chunk hashes after the production alias points to the new deployment.

I’d compare the deployment URL and the production domain directly:

1
curl -sL https://your-new-deployment-url.vercel.app | grep -o '/_next/static/[^"]*' | head -20
2
curl -sL https://your-production-domain.com | grep -o '/_next/static/[^"]*' | head -20
3

4
curl -I https://your-production-domain.com
5
curl -I https://your-new-deployment-url.vercel.app
6

If the deployment URL shows the new chunk hashes but the production domain shows old ones, then the build artifact is fine and the issue is in the domain/proxy/cache layer.

Since Cloudflare is also in front, I’d temporarily bypass that as an isolation test: either pause/disable the proxy for the hostname or create a temporary DNS-only subdomain pointing to Vercel. If the DNS-only hostname shows the new deployment immediately, then Cloudflare is still caching or routing the old HTML even if the Vercel deployment/alias is correct.

I’d also check for any custom headers that accidentally cache HTML or route responses too long:

1
next.config.js headers()
2
vercel.json headers
3
middleware
4
route handlers
5
Cloudflare cache/page rules
6

Especially look for Cache-Control, CDN-Cache-Control, or Vercel-CDN-Cache-Control on page routes. Those are useful for APIs/static responses, but they can make debugging deploy rollouts confusing if applied broadly.

Vercel’s CDN cache docs are useful for checking the headers involved:

https://vercel.com/docs/caching/cdn-cache

If the production domain and deployment URL return different HTML after Cloudflare is bypassed, the next useful details would be the curl -I output for both URLs and the exact deployment URL currently assigned to the production domain.