# 301 and 302 redirects | answer.cloud Docs > Canonical source: [301 and 302 redirects | answer.cloud Docs](https://www.answer.cloud/docs/hosting/redirects/) Redirect moved or temporary URLs with a deployed _redirects file, preserve query parameters, and verify real HTTP responses through staging, promotion, and rollback. guide 301 and 302 redirects Redirect moved or temporary URLs with a deployed _redirects file, preserve query parameters, and verify real HTTP responses through staging, promotion, and rollback. Reviewed November 1, 2026 Answer Cloud hosted sites support HTTP 301 and 302 redirects through a `_redirects` file included in the built site. Use redirects when a page moves, an old link needs a new destination, or a temporary campaign should point elsewhere. The hosting edge returns the redirect before serving a static file at that exact path. ## Create the redirects file For an Astro project, create `public/_redirects`. Astro copies it to `dist/_redirects`, at the root of the built artifact: ``` # Permanent page moves /old-page /new-page 301 /old-page/ /new-page/ 301 # A temporary destination on another website /sale https://example.com/current-offer 302 # Omitting the status defaults to 301 /docs/start /docs/getting-started/ ``` Each rule contains a source path, destination, and optional status, separated by whitespace. Blank lines and `#` comments are allowed. An inline comment needs whitespace before `#`; a fragment attached to a destination, such as `/new-page#details`, remains part of its URL. Include the file in the complete artifact you [deploy through MCP](https://www.answer.cloud/docs/hosting/deploy/) or [build from GitHub](https://www.answer.cloud/docs/hosting/github/). Sending `_redirects` alone through `deploy_files` would replace the website with an incomplete artifact. ## Choose a permanent or temporary response Use **301** for a permanent move, such as replacing an old article URL with its current location. Use **302** when visitors should temporarily go elsewhere and the original URL may return later. These are real HTTP responses with a `Location` header. They do not depend on browser JavaScript or an HTML refresh. Browsers can retain permanent redirects after the deployment changes, so choose 301 only when the move is intended to last. ## Match the exact source path Matching is case-sensitive and happens before directory-style paths are rewritten to `index.html`. These are three separate sources: ``` /old-page /new-page/ 301 /old-page/ /new-page/ 301 /old-page/index.html /new-page/ 301 ``` Add each spelling that must redirect. A rule for `/old-page` does not automatically cover `/old-page/`, its children, or `/Old-Page`. Sources must be root-relative paths without a query string or fragment. Wildcards, placeholders, regular expressions, query conditions, and rewrite statuses such as 200 are unsupported. Do not copy another host's redirect configuration without checking every rule against this format. ## Preserve queries and choose destinations Destinations can be root-relative paths or absolute HTTP(S) URLs. A root-relative destination keeps the visitor on the current host, which is useful when testing the same rules in staging and production. Use percent encoding for spaces and non-ASCII characters. URLs containing credentials and protocol-relative targets such as `//example.com/page` are rejected. Incoming query parameters are preserved when the destination has no query string. Repeated parameters and existing percent escapes are retained. For example: ``` # A request to /old?ref=newsletter goes to /new?ref=newsletter#details /old /new#details 301 # The destination query replaces the incoming query /offer /current-offer?campaign=summer 302 ``` Fragments stay after the resulting query string. A destination's own query replaces incoming parameters rather than merging with them. ## Deploy and verify Build and deploy the complete site, then poll `get_deploy` until processing finishes. Its `redirect_count` reports the configured rule count; validation failures appear in `error` with the affected line number. Test each moved URL on the selected destination and inspect its status and `Location` header. For example: ``` curl -I 'https://www.example.com/old-page?ref=docs' ``` Expect 301 or 302 with the intended destination and query. Also verify the destination page itself and an ordinary page that should not redirect. The configuration file is retained in downloads and repository exports, but a public request to `/_redirects` returns 404. ## Releases, limits, and recovery Rules belong to the deployment. [Staging, promotion](https://www.answer.cloud/docs/hosting/environments/), and [rollback](https://www.answer.cloud/docs/hosting/rollback/) select the corresponding artifact and its redirects. Each new deployment replaces the complete rule set. Omit `_redirects` from a new deployment to remove its redirects. The current limits are 100 rules, 64 KiB of UTF-8 configuration, 400 bytes per source path, and 1 KiB per stored destination/status rule. Duplicate sources, invalid URLs, reserved platform source paths, and local redirect loops fail validation. If redirect publication fails, the previous site remains live. Retry the failed deployment with the same rules. Once rule preparation has begun, start a new deployment to change or remove those rules rather than uploading a different configuration to the same failed deployment ID. See [deployment troubleshooting](https://www.answer.cloud/docs/troubleshooting/deployments/) for recovery steps.