App Router: returning notFound() from generateMetadata does not change the response status code to 404 if there's a loading.tsx component

[felipedeboni]

Link to the code that reproduces this issue

https://github.com/felipedeboni/next-404

To Reproduce

Go to: https://next-404-ten.vercel.app/with-loading

• not found is rendered
• response status is 200 OK.

Go to: https://next-404-ten.vercel.app/with-parent-loading

• renders the page as expected.

Go to: https://next-404-ten.vercel.app/with-parent-loading/children

• not found is rendered
• response status is 200 OK.

Current vs. Expected behavior

When returning notFound from generateMetadata I would expect the response to have a 404 Not Found status in order to allow pages to be removed from Google Index and others...

The alternative is awful, in middleware:

• Check if it's a bot. If not just continue.
• Check if resource exists. If it does continue.
• Send 404 Not Found.

However this is going to make things slower for bots, making the web vitals score lower given there's no fetch cache on middleware and fetch calls made on middleware aren't shared (cached) with the page itself.

For regular access I it's fine to have 200 OK and just show not found component (or default), however for bots we need the proper status.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 18:56:34 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.21
  pnpm: 9.4.0
Relevant Packages:
  next: 15.1.6 // Latest available version is detected (15.1.6).
  eslint-config-next: 15.1.6
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Loading UI and Streaming, Metadata

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

Additional context

No response

[samcx]

@felipedeboni Thank you for submitting an issue!

The 200 status code is expected and is ok for bots/SEO because we also send a robots meta tag which lets them know to not index the page.

• https://vercel.com/guides/does-streaming-affect-seo#do-status-codes-matter-for-streaming
• https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming#status-codes

[felipedeboni]

@samcx thank you for replying, I have not noticed the meta and some previous version of next the status returned was 404.

Regarding robots meta, it's being duplicated :)

[samcx]

some previous version of next the status returned was 404

Which previous version? All versions of App Router should be returning a 200 since streaming has been present since the beginning for App Router.

Regarding robots meta, it's being duplicated :)

👁️

[felipedeboni]

I have a few concerns I'd like to share. While the current approach does successfully remove items from the index, it may inadvertently disrupt tools that check for broken links, such as Google Search Console's "Not Found (404)" page tracking, as well as various 3rd party services. Even when 500 error occurs, the response is still being returned as 200 OK.

I believe there's an opportunity for improvement here. I recall a ticket from some time ago that proposed allowing custom status codes to be returned from generateMetadata or a similar function. Unfortunately, I haven't been able to locate it again.

What concerns me most is that we've long advised new developers to use the proper status codes. With the current setup, it feels as though we're defaulting to a "modern" version of 200 OK with a body indicating an error (i.e., { status: 'error' }).

Which previous version? All versions of App Router should be returning a 200 since streaming has been present since the beginning for App Router.

Oh, I would have to check when it actually broke, I was writing some tests to not found resources when I noticed it was "broken". I will get back to you with an answer for that.

[kmsomebody]

The same goes for using redirect or permanentRedirect in generateMetadata.

If there is a redirect, the metadata for the page will not work properly. E.g. Discord does not show any embed for pages using redirect. Redirects breaking metadata should at least be documented imo.
The reason for that is how streaming works. The metadata is placed in a script inside the body of the page. After redirecting, the page seems to expect that it can reuse already generated metadata. However, since generateMetadata never terminated due to redirecting, this data is missing from the URL.

It would be better if Next.js just used the HTTP status codes (307, 308, 404, etc) in this case instead of trying (and failing) to stream. Since generateMetadata seems to be awaited even when streaming (since the returned data is included in the document), it does not make any sense to not use the correct status code. The response can still contain the same HTML and it would be up to the client to decide whether to follow the redirect according to the response header or to render the HTML.