302 is one of the HTTP status codes, indicating that the requested resource is temporarily located at another address. When the browser receives this status code, it automatically redirects to the new address, but does not treat it as a permanent change.
When to use it
- Content is temporarily moved and may later move back to the original address
- During site maintenance, direct visitors to an explanation page
- Conditionally direct some visitors to different versions for comparison testing
What these scenarios have in common is that the change is temporary and reversible. If the address change itself is a long-term decision, a status code indicating a permanent redirect should be used.
Difference from 301
The two are almost identical from the user's perspective; the difference lies in semantics: 301 indicates a permanent move, and search engines will transfer the original address's authority and indexing to the new address; 302 indicates a temporary move, and search engines will not make this transfer and will still retain the original address.
For this reason, using the wrong status code has direct consequences: if an address that should be permanently migrated uses 302, authority will not be transferred, and the new page's performance may not improve over the long term; if a merely temporary adjustment uses 301, search engines may abandon the original address prematurely.
It should be noted that 302 does not pass the original address's authority to the new address. The reason for choosing it should be that "the change is temporary," not to retain authority.
How to set it up
There are two main ways to set up redirects: add redirect rules through configuration files at the server level, or directly return the corresponding status code in program code and specify the target address. The former is suitable for bulk, rule-based redirects, while the latter is suitable for redirects related to business logic.
Syntax varies considerably across server software and development languages. It is recommended to follow the respective official documentation to avoid rule conflicts caused by mixing examples.
A few considerations
- Avoid chained redirects: A redirects to B, and B redirects to C, which slows down access and affects crawling
- Confirm that the target address is valid; otherwise visitors will land on an error page
- After setup, visit it once to confirm that the redirect direction is correct
- Record temporary redirects and permanent redirects separately for easier cleanup later