301 vs 302: which redirect should you use?

Both redirect families do the same visible thing: send the browser somewhere else. The difference is what they tell a crawler about the old URL, and one of these messages is very hard to take back.

The four codes

Code	Meaning	Keeps request method	Old URL stays indexed
301	Moved Permanently	No (POST may become GET)	No
308	Permanent Redirect	Yes	No
302	Found (temporary)	No	Yes
307	Temporary Redirect	Yes	Yes

The two axes are permanence and method handling. Choose permanent when the old URL will never serve again; choose the 307/308 pair when a request body or method has to arrive intact at the destination.

Why permanent matters

A 301 or 308 tells crawlers the old URL is retired. They transfer the indexing to the destination and consolidate the signals there, so a single permanent hop is the clean end state of a migration.

A 302 or 307 says the opposite: the move is temporary, the old URL is still the real one, so keep it in the index and keep checking back. That is exactly right for a maintenance page and exactly wrong for a site migration, because the destination will never be treated as the canonical home of the content.

When temporary is the correct choice

• Maintenance windows. The page returns when the work is done.
• A/B tests and experiments. The decision is not final, and the URL must stay in place.
• Geo or device splits. Different users get different content from the same URL.
• Short-lived campaigns. A landing page that will be removed.

In every one of these the old URL remains the real address, which is why the temporary code is correct rather than a compromise.

Writing the rule

# 永久迁移：老 URL 不再对外提供服务
location = /old-product {
  return 301 https://example.com/new-product;
}

# 临时维护：老 URL 仍是正牌地址
location = /checkout {
  return 302 /maintenance.html;
}

Prefer 308 over 301, and 307 over 302, whenever the endpoint receives POST requests. The method-preserving codes guarantee the body arrives at the destination instead of being dropped.

Recovering from a wrong choice

The two mistakes are not symmetric.

302 used where a permanent move was meant. This is easy to repair: the crawler was never told the old URL is gone, so simply change the rule to 301 or 308. The next crawl treats it as a permanent move.

301 used where a temporary move was meant. This is the painful one. Browsers cache 301 responses aggressively and may keep sending users to the destination long after you have changed the rule — the browser never asks the server again. Recovery:

1. Serve the intended content from the destination too, so cached users still land somewhere correct.
2. Change the rule back, ideally from a new URL shape, and expect a slow rollout as caches expire.
3. For an experiment you expect to reverse, never use 301 in the first place.

Common mistakes

Using 302 for a migration. The destination never becomes canonical, and the old URL lingers in the index.

Using 301 for an A/B test. The browser caches it, and you lose the ability to switch back on demand.

Ignoring the method-preserving pair. A redirect in front of a POST endpoint that drops the request body is why 307 and 308 exist.

Assuming a 301 can be reverted instantly. It is cached by clients you do not control. Plan for the cache, do not fight it.

Mixing codes across a migration. Some URLs on 301 and others on 302 produce an inconsistent index. Decide the permanent ones once.

Not verifying the live code. The intended 301 may be overridden by a CDN or framework default. Trace the response to confirm what is actually sent.

Where this tool fits

The redirect chain checker reports the status code at every hop, so you can confirm a rule returns the 301 or 302 you intended rather than the one a framework applied on top of it.