Did the redirect actually work as expected or did I use it wrong?

[yanghoxom]

Summary

In my Next.js 14 project using the App Router, I expected server-side redirects to happen cleanly—without rendering any content and with a proper redirect status (like 307 or 308).

However, what actually happens is:

The original request returns status 200.

The redirected request also returns 200.

Some content is still sent to the client before the redirect occurs.

This breaks the assumption of a clean, server-handled redirect and can cause flickering or unintended content exposure. I believe redirects should happen with no content streaming and with proper HTTP redirect status codes.

This is my implementation:

// app/some-page/page.tsx
export default async function Index(props: Props) {
  ...
  redirect('/some-page/test);
}

Additional information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Mon Apr 21 17:08:54 UTC 2025
  Available memory (MB): 64090
  Available CPU cores: 20
Binaries:
  Node: 20.19.1
  npm: 10.8.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.13 // An outdated version detected (latest is 15.3.3), upgrade is highly recommended!
  eslint-config-next: 14.2.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.5.2
Next.js Config:
  output: N/A
 ⚠ An outdated version detected (latest is 15.3.3), upgrade is highly recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue

Example

No response

[yanghoxom]

/**
 * This function allows you to redirect the user to another URL. It can be used in
 * [Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components),
 * [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers), and
 * [Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations).
 *
 * - In a Server Component, this will insert a meta tag to redirect the user to the target page.
 * - In a Route Handler or Server Action, it will serve a 308/303 to the caller.
 *
 * Read more: [Next.js Docs: `redirect`](https://nextjs.org/docs/app/api-reference/functions/redirect)
 */

This is document
looks like it has no way to redirect with 301 code in page.tsx
So is next really "SEO Friendly"? I feel like I was cheated when I used next for my project.

To fix the problem, I am having to use hard code in the middleware

[icyJoseph]

Hi,

I would just like to make a couple of precisions.

As you point out this because streaming kick in, if I have this root page, without a loading.js (or tsx), file:

import { setTimeout } from "node:timers/promises";

import { redirect } from 'next/navigation'

export const dynamic = 'force-dynamic'

export default async function Home() {
  await setTimeout(450)

  redirect("/home")
}

Then when I navigate with a browser, or even cURL my server, I get a 307.

❯ curl localhost:1234 -v 
* Host localhost:1234 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:1234...
* Connected to localhost (::1) port 1234
> GET / HTTP/1.1
> Host: localhost:1234
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 307 Temporary Redirect
< Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
< Location: /home
< X-Powered-By: Next.js
< Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
< Content-Type: text/html; charset=utf-8
< Date: Tue, 03 Jun 2025 07:42:59 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked

However, when a suspense boundary is somehow present, for example through a root loading file, streaming kicks in, and now even the same cURL command does:

* Request completely sent off
< HTTP/1.1 200 OK
< Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
< X-Powered-By: Next.js
< Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
< Content-Type: text/html; charset=utf-8
< Date: Tue, 03 Jun 2025 07:49:09 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked

I know this is not ideal, but what's happened here, is that streaming began, eagerly, and for that, headers are sent first, including the status of the request. Later on while rendering, a redirect is found, and now we need to "out of order" redirect to a new location. For that:

    <meta
      id="__next-page-redirect"
      http-equiv="refresh"
      content="1;url=/home"
    />

These sections in Google's Search Console docs:

• https://developers.google.com/search/docs/crawling-indexing/301-redirects#overview-of-redirect-types
• https://developers.google.com/search/docs/crawling-indexing/301-redirects#metarefresh

Hint that, it is OK, perhaps, not the most optimal/ideal, but ok anyway. I know that for a bot, or my cURL request, is not good enough, because at the end of the day, it didn't follow to the content

If a path can be potentially redirected, and it is important for bots/crawlers, from your point of view, try to keep the path to the redirect call, out of Suspense. I know, again, not ideal, not always possible, and prone to regressions, but it is a way out.

[yanghoxom]

@icyJoseph
hi,
Thanks for the reply.
As I understand your answer.
It seems like Next.js will not have a way to return the redirect code normally?

A related issue, even notFound has the same problem where it does not return 404 but returns a "soft 404", an issue that GSC will warn about and require fixing.