Find out why a route you expected to be static is rendering dynamically on every request

You are diagnosing why a specific route is rendering dynamically on every request when it was expected to be static or ISR-cached. Rendering mode in the App Router is determined by what a route actually does, not by an explicit setting alone, so the fix has to name the specific code responsible, not just restate that the route "is dynamic."

ROUTE
/pricing

EXPECTED RENDERING MODE
Fully static — pricing content is the same for every visitor and rarely changes

BUILD OUTPUT EVIDENCE
The build output marks /pricing with the dynamic symbol instead of the static one, and Next.js's route info logged 'Dynamic server usage: cookies' during the build

CODE INVOLVED
app/pricing/page.tsx plus app/layout.tsx, which reads cookies() unconditionally in a top-of-tree A/B test check

DIAGNOSIS RULES
Search the route's component tree, including every layout above it, for a call to a dynamic API: cookies(), headers(), a direct read from searchParams, connection(), or a fetch call with cache: 'no-store' or an explicit revalidate: 0. Any one of these, called anywhere in the tree that renders for this route, including a shared layout the route doesn't own directly, forces the entire route to render dynamically — a static-looking page component can be made dynamic entirely by something in its layout, which is exactly the kind of cause that's easy to miss when the search only looks at the page file itself. Check whether a component is unconditionally calling one of these APIs when it's actually only needed conditionally — a component that reads cookies() to personalize content for logged-in users, but calls it unconditionally even for anonymous visitors who could have gotten a static response, is forcing dynamic rendering for a case that didn't actually need it. If a third-party library or internal utility is the actual source, name that specific import, not just the file that happens to import it, since the fix is either replacing that dependency's usage in this route or accepting the dynamic rendering it requires as a deliberate tradeoff rather than an accidental one. Distinguish between something that must genuinely force dynamic rendering, given what the route actually does — a page that shows the signed-in user's own data has to read a cookie or a session to know who that is — and something that's forcing it unnecessarily where a narrower fix, such as moving the dynamic read into a smaller, isolated Server Component wrapped in its own Suspense boundary, would let the rest of the route stay static or cached while only that one piece renders per-request.

OUTPUT FORMAT
A table: File | Dynamic trigger found | Is it a genuine requirement or an avoidable cause | Fix if avoidable. Then one paragraph confirming whether, after any recommended fixes, the route would actually render statically or with ISR, or whether it should stay dynamic on purpose given what it does — state that conclusion plainly rather than leaving it implied by the table alone.