How do i get status code 404 for not-found page?

[rodzerjohn]

Summary

How can I ensure that a not found page returns a 404 status code? Dynamic pages return a 200 status code, but for pages not defined in the app router, it returns a 404.

Example from vercel repo:
Repo - https://github.com/vercel/next.js/tree/canary/examples/cms-sanity

Page not defined in app router - https://next-blog-sanity.vercel.app/pasdasd returns 404
Dynamic page with notFound() method - https://next-blog-sanity.vercel.app/posts/learn-hasdasd returns 200

Edit: Sorry, even though that repo is not using App Router, the problem is still relevant.

I understand that the 404 page is displayed correctly, but I also need to ensure that the server returns a 404 status code for SEO purposes.

Thanks in advance!

Additional information

No response

Example

No response

[votemike]

Is your page streaming in data? Streamed pages will still 200: https://nextjs.org/docs/app/api-reference/file-conventions/not-found
Vercel demo this here: https://demo.vercel.store/product/non-existent
While the page says 404, the status code is 200.

[karlhorky]

Vercel demo this here: demo.vercel.store/product/non-existent

This page returns a 404 HTTP status code now.

(maybe because of useCache: true? added in commit 7f8f9ff1a39fd4f2cf9ebecce3e28ac0f8ab5e36)

[karlhorky]

Oh, maybe it's because of loading states.

Status codes are mentioned in the not-found docs:

Along with serving a custom UI, Next.js will return a 200 HTTP status code for streamed responses, and 404 for non-streamed responses.

• https://nextjs.org/docs/app/api-reference/file-conventions/not-found#:~:text=Along%20with%20serving,non%2Dstreamed%20responses

Status codes are also mentioned in the docs for Loading UI and Streaming:

When streaming, a 200 status code will be returned to signal that the request was successful.

The server can still communicate errors or issues to the client within the streamed content itself, for example, when using redirect or notFound. Since the response headers have already been sent to the client, the status code of the response cannot be updated. This does not affect SEO.

• https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming#status-codes

The vercel/commerce example doesn't include any loading states:

[wesleyjanse]

Just had the same issue, I had a 'use client' provider wrapping the app that was also importing a component using next/dynamic. This caused all not-found() to return 200 since the data was streamed in by the next/dynamic

[ZowWeb]

make sure you have app/not-found.tsx which handles notFound(), non-existing routes and /404

few solutions I came up while encountering this issue:

• in middleware.ts file, return NextResponse.rewrite(new URL('/404', req.url))
• redirect('/404')
• check if in file app/layout.tsx, child components are wrapped in <Suspense> – if yes, remove global Suspense

[v-karbovnichy]

remove global Suspense

this was the issue for me! thanks!

[KirDontsov]

Oh, thx a lot! I've spend a couple of weeks searching the problem

[grevzi]

Hi there,

I hope this helps someone resolve the issue faster than I did — I spent quite a bit of time figuring it out.

The key takeaway: make sure you don’t start streaming anything before calling notFound().

Here are my overall findings.

Next.js App Router – Reliable 404/500 Headers Checklist

1. Do all data-fetching inside the page component (or its children)

• Parent layouts and loading.tsx must not await data that can fail.

• They should render only structural markup and {children}.

2. Call notFound() / throw before streaming starts

• Once any HTML is flushed, the status code is locked.
  ➜ Fetch, validate, then immediately call notFound() if needed, and only then return JSX.

3. Beware of loading.tsx

• A route-level loading.tsx streams a skeleton immediately → status = 200.

• Instead, use <Suspense fallback> within the page when a loader is needed.

4. Layouts may await, but must not stream JSX to the client prematurely

• If a layout needs to fetch data, it should await that data first, and only then render {children} — no early streaming.

5. Middleware considerations

• Returning NextResponse.next() too early locks the response status to 200.

• Use middleware selectively (via matcher).

• You can mutate headers but avoid sending a response body.

6. Static/ISR vs Dynamic

• generateStaticParams → unknown slugs never hit the React tree → automatic 404.

• ISR (export const revalidate) works as long as rule 1 is followed.

• If you must fetch data at runtime in a layout, use export const dynamic = 'force-dynamic' to prevent early HTML flushing.

6. After code changes, restart dev server or rebuild

• Stale compiled output may preserve old streaming behavior.