How does middleware interact with static pages? Does it run for SSG pages?

Yes — Middleware runs for ALL matched routes including SSG (statically generated) pages. However, the interaction is nuanced. Middleware runs at the Edge BEFORE the response is served, meaning it intercepts even cached static pages. But whether middleware can modify the actual HTML response of a static page depends on what it does — it can redirect, rewrite, or add headers, but it cannot change the static HTML content itself.

This is one of the most misunderstood behaviors in Next.js. Many developers assume that because a page is statically generated and cached, middleware is bypassed. This is incorrect. Middleware runs at the Edge before the cached response is delivered. It acts as an interceptor — it can allow, block, redirect, or rewrite the request before the static HTML ever reaches the browser. However, middleware cannot modify the static HTML payload itself — it can only control what happens to the request before the page is served.

Key Facts About Middleware and Static Pages

1
Middleware DOES run for SSG pages — it intercepts the request before the cached response is served
2
Middleware runs at the Edge — static HTML is served from cache AFTER middleware completes
3
Middleware can redirect away from a static page before the HTML is ever sent
4
Middleware can rewrite a static page request to serve a different static page
5
Middleware CANNOT modify the HTML content of a static page
6
Middleware can add/modify response headers on static page responses
7
On Vercel — middleware runs on the Edge network, static assets served from CDN after middleware
8
Self-hosted — middleware runs in the Next.js server before serving the static file

Request Lifecycle — Middleware with Static Pages

Middleware Protecting a Static Page

Rewriting Static Pages Based on Conditions

Adding Headers to Static Page Responses

The Edge Case — Middleware Does NOT Run for _next/static Assets

ISR Pages — Middleware Runs But Cache Behavior Differs

Common Pitfall — Middleware Not Running on Deployed Static Pages

Middleware and Static Pages — Summary of Behaviors

1
SSG pages (generateStaticParams) — middleware runs, can redirect/rewrite before HTML is served
2
SSG pages (output: export) — middleware does NOT run, pages served as plain files
3
ISR pages (revalidate) — middleware runs on every request before cached response
4
Static files (_next/static, public/) — middleware does NOT run, exclude via matcher
5
CDN cached pages on Vercel — middleware runs at Edge before CDN cache is served
6
Self-hosted SSG — middleware runs in Next.js server before static file is returned
7
Headers added by middleware — applied to static page responses ✅
8
HTML content of static page — middleware CANNOT modify it, only control routing

Key Takeaways

1
Middleware runs for SSG pages — it is NOT bypassed by the static cache
2
Middleware runs BEFORE the cached HTML is served — it is the first point of interception
3
Middleware cannot change static HTML content — only routing, headers, and cookies
4
Pure static export (output: export) is the only case where middleware does not run
5
Always exclude _next/static and public/ from middleware matcher for best performance
6
Middleware is safe to use for auth protection on SSG pages — it reliably intercepts requests
7
On Vercel, middleware runs at the Edge before even the CDN cache — giving maximum control