301 vs 302 Redirects: What's the Difference and When to Use Each

Use 301 when a page has moved permanently. Use 302 when the destination is temporary or you want people to keep using the original address. Both send visitors to another URL, but the status is only one part of the behavior: cache headers control response reuse, and search engines make their own canonical selection.

A 302 is not a promise of an uncached request, an instant destination update, or a recorded analytics event. This guide separates those decisions so you can choose and test the redirect you actually need.

First, what is an HTTP redirect?

For an ordinary browser GET request, a redirect response carries a status such as 301 or 302 and a Location header. The browser follows that location to request the destination. A cached redirect may let the browser skip a new request to the original server.

Redirecting a form or API request needs additional care. With 301 and 302, clients may change a POST to GET. If the request method must be preserved, consider 308 for a permanent move or 307 for a temporary one, and test the client.

301: Moved Permanently

A 301 says the resource has a new permanent address. It fits domain migrations, HTTP-to-HTTPS moves and replacing an old page with a relevant successor. Update internal links and sitemaps to the new address as well.

Google follows the redirect and uses it as a signal that the destination should be canonical. That is not a guarantee of immediate replacement in search results, preserved rankings, or a fixed amount of transferred “link equity.” Google considers other signals and needs time to crawl and process the move.

A 301 is heuristically cacheable: a cache may choose a freshness lifetime even without an explicit one, unless the method or cache controls prevent it. That can make a mistaken redirect persist for returning visitors, but “cached forever” is not a rule of the status code.

302: Found (Temporary)

A 302 says the resource is temporarily available at another address; clients should continue using the original URL for future requests. It suits temporary campaigns, maintenance detours and editable short links.

Google follows a temporary redirect but does not use it as a signal that the target should be canonical. The target may still be indexed based on other canonicalization signals. A 302 does not guarantee that only the original URL appears in search, nor that ranking signals are stranded there.

301 vs 302 at a glance

How each affects SEO and link equity

Choose the status that describes the move. For a permanent migration, use a permanent redirect to the closest relevant replacement, avoid unnecessary chains, and align internal links and canonical declarations with the new URL. For a temporary detour, use a temporary redirect and retain the original address.

Google's redirect guidance describes canonicalization signals, not a guaranteed ranking result. Search Console's URL Inspection tool can show which canonical Google selected and when it last crawled the page. A successful HTTP request alone cannot prove that a URL is indexed.

The caching gotcha: check the headers

A 302 with explicit freshness, such as Cache-Control: max-age=300, can be stored and reused while fresh when the other caching requirements are met. It need not contact the original server on every visit. A 301 can also have its caching behavior constrained by headers.

• no-store: tells caches not to store the response.
• no-cache: allows storage, but requires successful validation before reuse.
• private: prevents shared-cache storage; it does not by itself prevent a browser from storing the response.

Changing headers now cannot recall a redirect that a client has already cached and is still reusing without contacting you. Test a fresh request and a returning browser separately. Inspect the first response's status, Location and Cache-Control, then confirm the final page after following the redirect.

curl -sS -D - -o /dev/null 'https://go.example.com/campaign'

This is a placeholder URL for your own short link. The command inspects a GET response without following the redirect; it does not test a browser's existing cache.

Which one should you use?

• Permanent page or domain move: use 301, or 308 when method preservation is required.
• Temporary destination: use 302, or 307 when method preservation is required.
• Editable short link: choose a service that supports destination edits and has an appropriate cache policy; check its plan limits and propagation behavior.

Why an editable short link needs more than a 302

A stable short URL can keep the same printed QR code useful while its destination changes. Editing that destination is a feature of the link service, not something HTTP 302 implements. Shorteners can differ in redirect status, edit permissions, cache policy and analytics rules.

A request reaching the redirect server gives it an opportunity to record a click. It does not guarantee a recorded event: quotas, filtering, blocked tracking and processing failures can affect analytics. A cached redirect can also bypass that server entirely. Treat redirect availability and analytics coverage as separate promises.

How 302.sh handles it

Ordinary active 302.sh short links return 302 with Cache-Control: private, no-store and X-Robots-Tag: noindex, nofollow. Password prompts, expired links and cloaked links can produce different responses. The robots header expresses a crawler directive; it does not guarantee how every search engine treats the short URL or promise authority for the destination.

You can edit the destination while keeping the short URL, but service cache propagation can delay what a subsequent request sees. Our documented destination-edit check observed an old destination after saving and later observed the new one. That single check is evidence of the workflow, not an instant-update guarantee or a latency benchmark.

Recorded analytics are subject to the current plan allowance and retention. Reaching an analytics allowance does not stop the redirect, and anonymous guest links do not receive account analytics. Verify both the visitor journey and the events you need before relying on a campaign report.

Frequently asked questions

Is a 301 or 302 redirect better for SEO?

Use a 301 for a permanent move and a 302 for a temporary destination. Google uses permanent redirects as a signal that the target should be canonical; it does not use temporary redirects as that signal. Other signals still affect which URL Google selects. Neither status guarantees indexing or rankings.

Do 302 redirects pass link equity?

A 302 does not mean that all ranking signals are lost or permanently locked to the original URL. Google follows temporary redirects, and the target can still be indexed based on other canonicalization signals. For a permanent migration, use a permanent redirect rather than relying on a 302 to communicate the move.

Which redirect do URL shorteners use?

Redirect behavior varies by service. Ordinary active 302.sh short links use HTTP 302 with Cache-Control: private, no-store. Destination editing is a product capability, and cache propagation can delay an update. Recorded analytics depend on the plan allowance, filtering and successful processing; the status code alone does not guarantee a recorded click.

Will my browser cache a 301 or 302 redirect?

A 301 is heuristically cacheable unless the request method or cache controls say otherwise. A 302 can also be cached when explicit freshness information allows it. Cache-Control: no-store tells caches not to store a response; no-cache permits storage but requires validation before reuse. Neither status code alone means cached forever or revalidated on every visit.

Sources

Checked September 18, 2026. HTTP semantics and caching rules come from the specifications; Google's indexing behavior comes from its own guidance.

• RFC 9110: 301 Moved Permanently and 302 Found.
• RFC 9111: storing responses and response Cache-Control directives.
• Google Search Central: redirects and Google Search.