# Redirects
> Leaving a page from inside the render, and what that costs.
```tsx title="src/app/products/[slug]/page.tsx"
import { redirect } from '@rsc-kit/core/redirect';
import { findProduct } from '../../../data';
export default async function ProductPage({ params }: { params: Promise<{ slug: string }> }) {
const { slug } = await params;
const product = await findProduct(slug);
if (!product) redirect('/products');
return
{product.name}
;
}
```
`redirect` never returns — it throws, which is what stops the component. The
default status is `307`, because it preserves the method: a redirect out of a
`POST` does not silently become a `GET` of the target.
A redirect during a navigation stays a navigation. The document does not reload,
the layouts you are inside stay mounted, and only the part below them changes.
The url that redirected replaces its history entry rather than adding one, so
Back does not land on it and redirect you again.
## With a query string
`search` is typed to the destination page's own `searchParams` schema, the
same check `Link` puts on its `search` prop — a key the page never reads, or
a number written as text, does not compile:
```ts
redirect('/', { search: { auth: true } }); // → /?auth=true
redirect('/search', { search: { q, page: 2 } }); // checked against /search's schema
redirect('/old', { status: 308 }); // a permanent one
```
A bare second argument is still the status: `redirect('/old', 308)`.
## Where you call it matters
This is the part worth understanding, because it is also the security-relevant
part. Headers flush early on purpose — that is what makes the first paint fast
— so a redirect decided late has no status line left to use. There are two
windows, and nothing you write chooses between them:
| Called | Answered with | What the browser saw first |
| --- | --- | --- |
| Above every `` boundary | A real `3xx`, or `X-RSC-Redirect` on a navigation | Nothing at all |
| Inside a boundary | The shell, then the redirect | Layouts, and the fallbacks standing in for what never arrived |
Neither buffers the response. Before anything is written the host is still
waiting on the shell, so a component that redirects instead of rendering is
caught there. After that, React already carries an error digest to the client
and the destination rides along in it, and the browser performs it as a
navigation — the layouts above stay mounted, the url being left is replaced
rather than kept in history. An `error.tsx` on the route never sees it: a
redirect is the page's answer, not a failure, whether it is thrown by the
page, by a component under its own ``, or by a parallel route slot.
## Where to put an authorization check
In order of preference:
**In `middleware.ts`.** A file beside the layout, run before anything at or below it
renders, on every path. This is the one built for the job.
**At the top of a page with no `loading.tsx`.** Runs on every render of that
page, so it is not skippable the way a layout is — but fragile in a different
way: adding a `loading.tsx` later silently moves the check into the second
window, and nothing warns.
## From a server action
An action is not a render, so there is no shell to be on either side of. Throw
from the action — a plain `"use server"` function or one built from
`createActionClient()` — and the client follows it as a navigation: the
layouts stay mounted and the history entry the form was on is replaced, so
Back does not return to the submitted form. A `