When should a website use a 302 redirect instead of a 301?

What the two codes actually promise

A 301 tells every client that the resource has moved permanently: browsers may cache the redirect for a long time, and search engines treat the destination as the new canonical address, consolidating signals there and eventually dropping the old URL from their index. A 302 says the resource is temporarily found elsewhere: clients should keep requesting the original address next time, and search engines generally keep the original URL as the canonical one as long as the redirect looks temporary. Their siblings 307 and 308 carry the same temporary and permanent meanings but guarantee that the request method is preserved, so a form submission stays a form submission.

Two honest observations. First, search engines have stated that both codes pass ranking signals, so the old fear that a 302 throws away link equity is overstated, and a 302 left in place for a long time is generally interpreted as permanent anyway. Second, the practical difference that bites people is caching. A 301 cached by a visitor's browser is very hard to undo; a 302 is not. That single behavior explains most of the good reasons to choose one over the other.

Keep reading: When to Run a Full Link Audit, How a Site Crawl Actually Works, Reading a Redirect Chain Map. See how DeadLinkr helps you on demand link and redirect audits for seo.

Legitimate reasons to choose a 302

Use a temporary redirect whenever the original URL is expected to come back or the final destination is not yet certain. That covers maintenance pages, short campaign swaps where the regular page returns after the event, a product page redirected to its category while an item is out of stock, an experiment that sends part of the traffic elsewhere, and a page temporarily under repair. Sign-in flows should redirect to the login page with a 302 so the requested URL stays bookmarkable. Geographic or language routing that keeps a single canonical page also fits, although those redirects deserve care for other reasons. Related: Reading a Redirect Chain Map

A less obvious reason is reversibility during change windows. If there is a real chance you will undo a redirect within weeks, such as during a migration rehearsal or while a new section is being validated, a 302 avoids the situation where you remove the rule and visitors keep landing on the wrong page because their browsers cached a permanent redirect. Once the move is confirmed to be final, switch it to a 301 and let the caches and indexes settle.

When a 302 is a mistake

Any redirect that is not coming back should be a 301 or a 308. That includes domain and https migrations, URL restructures, merging duplicate pages, retiring a product in favor of a permanent replacement, and canonicalization rules such as www versus bare host and trailing slash policy. A useful test is age: a redirect that has been in place for more than a few months is permanent whether or not its code says so, and its code should be corrected. Many application frameworks default their redirect helpers to 302, which is how sites accumulate hundreds of accidental temporary redirects nobody intended. Related: Why does a redirect loop keep coming back after it was fixed?

The request method is a second trap. A 301 or 302 on an endpoint that receives form posts may turn the follow-up request into a plain GET, dropping the submitted data. Anywhere a form or an API is involved, use 307 for temporary and 308 for permanent so the method survives the hop. Framework defaults rarely get this right either, so it is worth checking the redirects that sit in front of checkout, contact, and login endpoints specifically.

Auditing the redirects you already have

Crawl the site and export every redirect with its status code, its final destination, and its hop count. Filter to the 302 and 307 rows and ask one question per row: will the original URL ever return? If the answer is no, convert it. Deployment history or the redirect manager's dates help sort by age, and analytics help sort by traffic so the busiest redirects are corrected first. While you are there, look for 302s buried inside longer chains and for 301s whose destination has since moved again; both send mixed signals and should be collapsed into a single correct hop. Related: When to Run a Full Link Audit

Then set a policy that keeps the list clean. A temporary redirect requires an owner and a review date when it is created, and the audit surfaces any that pass their date. Canonical rules for scheme, host, and slash live at one layer and are always permanent. After every batch of changes, recrawl and confirm the chain map shows single hops with the intended codes. Redirect hygiene is dull work, but it is far cheaper to keep a clean map than to untangle years of framework defaults during a migration. Related: Post Migration Audit: What to Check