What Is a 302 Redirect? 301 vs 302, 307 and 308 Explained

What is a 302 redirect?
A 302 redirect is an HTTP status code that tells browsers and crawlers a page has moved to another URL temporarily. The server answers with 302 Found and a Location header. The browser then sends the visitor to the new address. Because the move is not permanent, the original URL stays valid.
This guide is for site owners, ecommerce teams and developers who manage their own sites. We cover how 302 differs from 301, 307 and 308, how Google treats it, and how to set it up in cPanel, .htaccess and nginx.
We are a digital marketing and web team, not a hosting company. So everything here rests on RFC 9110, MDN, Google Search Central and the Apache and nginx documentation. Your control panel may look different, depending on your hosting provider.
How does a 302 redirect work at the HTTP level?
For example, when a visitor opens the old URL, the browser sends a normal request to the server. Then the server skips the page content and returns a short response made of headers. In that response, the status code is 302 and the destination sits in the Location header.
HTTP/1.1 302 Found
Location: https://example.com/summer-sale/
The browser reads those two lines and requests the address in Location. The visitor barely notices, because the address bar changes within milliseconds. Googlebot receives the same response, but it reads the code differently. We explain that in the Google section below.
In other words, the redirect lives in the server response, not in the page itself. That is why the address you see in the browser never tells you which status code the server returned.
What is the difference between a 301 and a 302 redirect?
The core difference, in short, is whether the move is permanent or temporary. A 301 Moved Permanently says the page now lives at its new address for good. A 302 Found says the change is temporary. MDN adds that crawlers should not memorize the new URL for a 302.
| Code | Meaning | Duration | Request method |
|---|---|---|---|
| 301 | Moved Permanently | Permanent | POST may become GET |
| 302 | Found | Temporary | POST may become GET |
| 307 | Temporary Redirect | Temporary | Method is preserved |
| 308 | Permanent Redirect | Permanent | Method is preserved |
We summarized the table from the MDN redirect guide. For an ordinary page move, then, the real difference between 301 and 302 is the signal you send to search engines. The visitor sees the same page either way.
How do 307 and 308 redirects differ from a 302?
The 307 and 308 codes keep the request method intact. RFC 9110 says a client may change a POST to a GET after a 301 or 302. For 307 and 308, the client must not change the method.
MDN explains the history: some clients changed the method on a 302, which caused confusion. So 307 was created as the temporary version and 308 as the permanent version, both with a fixed method.
- Ordinary page move: 301 or 302 is enough.
- Form submission or API request being moved: 307 or 308 is safer.
- Permanent move where the method must survive: use 308.
- Temporary move where the method must survive: use 307.
For example, imagine a payment form that temporarily points to another address. The POST data must not disappear on the way, so we would pick 307 instead of 302.
Which redirect code should you use for forms and API calls?
This question matters most if you write code, so we start here. A browser visiting a page only sends a GET request, so the method ambiguity between 301 and 302 rarely shows up. Forms and API calls, however, use POST, PUT or DELETE.
If you redirect such a request with a 302, the client may turn it into a GET and drop the request body. RFC 9110 explicitly allows that behavior. Therefore, wherever the method has to survive, 307 or 308 is more predictable.
On the other hand, if you want to send a visitor to a thank-you page after a form submission, 303 exists for exactly that job. Also, we suggest testing how your own clients treat each code with a small request.
What does a 303 See Other redirect do?
A 303 tells the client to fetch the result from another address with a GET. According to MDN, it is used after a PUT or POST so that refreshing the result page does not repeat the operation. So a customer who submits an order form cannot create a second order by reloading the thank-you page.
However, this code is not about moving pages. So you would not choose 303 for a campaign or maintenance redirect. As a developer, you only need it for the redirect that follows a form submission.
Google groups 303 with the temporary redirects too. In other words, 302, 303 and 307 send the same signal to the search engine.
Do browsers cache a 302 redirect?
According to RFC 9110, a 301 can be cached by default and a 302 cannot. That said, the server can change this with explicit caching headers. So do not assume a 302 never lands in a cache.
The difference also helps during testing. If you try a new redirect rule with a 302 first, you lower the risk of leaving a lasting trace in visitors' browsers when you make a mistake. Then, once the rule works, you switch to a 301.
Still, caching depends on the browser, the CDN and your server headers. If you changed a rule but keep seeing the old behavior, test again in a private window and from the command line.
How does Google treat a 302 redirect?
Google Search Central describes two groups. A 301 and a 308 are permanent redirects. Googlebot follows them, and the indexing pipeline uses the redirect as a signal that the target should be canonical.
A 302, 303 and 307, on the other hand, are temporary redirects. Googlebot follows these as well, but the indexing pipeline does not use them as a signal that the target should be canonical. In short, Google tends to keep the old URL in its index for a temporary redirect.
In practice, then, 301 and 308 sit in one group for Google, and 302, 303 and 307 sit in the other. What matters is whether the move is permanent or temporary, not the number itself.
The same page does not say how long a temporary redirect may stay in place. It also gives no figure or rule about passing link value, so we avoid guessing. For that reason we do not guess; if the move is permanent, we pick a permanent code.
Does a 302 redirect hurt SEO?
Not when you use it in the right place. The trouble starts when you make a permanent move with a 302. Because a temporary redirect does not signal that the destination should be the main URL, the old URL can stay in the index, and the new page may not rise as fast as you expect.
Here is a hypothetical example: you permanently renamed a category, but a plugin created a 302. You may keep seeing the old URL in search results. Moreover, traffic in your reports can split between the two addresses.
The reverse is harmful too. For instance, if you point a campaign page to the homepage with a 301, browsers may remember that rule for a long time. Even after you remove it when the campaign ends, some visitors may still see the old behavior.
Another risk is noticing the loss late. A temporary redirect keeps the page open, so the site seems to work normally. Months later, you may find the new URL is not as visible as expected. So watch your reports for a few weeks after any move.
The rule is simple: permanent move, permanent code; truly temporary move, temporary code. Our SEO consulting service covers technical SEO more broadly.
When is a 302 redirect the right choice?
A 302 is right when the content will come back to its original address. MDN's own example is close to this: a page is temporarily unavailable for unforeseen reasons. Typical short-term uses are listed below.
- Sending visitors to an information page during maintenance or an update.
- Pointing a main URL to a campaign page for a limited time.
- Sending part of your visitors to an alternative page in an A/B test.
- Trying a new rule first, then converting it to a permanent one once verified.
- Sending a logged-out user to the login page.
In every item above, the old address will return, or a permanent decision has not been made yet. When the decision becomes permanent, you need to change the code too. Otherwise, a temporary rule can sit in production for years.
One warning about maintenance pages: if your site is down for maintenance, an error code such as 503 usually carries the right meaning instead of a redirect. We cover it in our 503 error guide. Use a redirect only when you want to move the visitor to another page.
When should you use a 301 instead of a 302?
Use a 301 or 308 whenever the address will never come back. In these cases you want the destination to become the main URL, and the permanent signal in Google's documentation says exactly that.
- Moving from HTTP to HTTPS, after you install an SSL certificate and send every page to the secure address.
- Choosing a single version between www and non-www.
- Changing your domain name or moving the site to another domain.
- Renewing the URL structure of a page for good.
- Replacing a deleted product with a permanent alternative.
However, a permanent move needs more than a redirect. We recommend updating internal links, menus and your sitemap to the new address as well. That is because a redirect is a bridge, and your own links should go straight to the destination instead of crossing it.
Big migrations need a step-by-step plan. Our website migration SEO checklist covers that plan; here we focus only on the redirect code.
Should you use a 302 on out-of-stock products and campaign pages?
If a product is only temporarily sold out and will return soon, keeping the page open without a redirect is often better. If the product is gone for good, you choose between 404, 410 and 301. We covered that decision in a separate guide on out-of-stock product pages and SEO.
Consider a 302 only when the temporary nature is deliberate. For instance, you might send a seasonal category to a general category all winter and reopen it in spring. In that case a temporary code makes sense.
Campaign pages follow a similar logic. If the URL stays the same every year, you can temporarily point it to the main category outside campaign season. Then you remove the rule on the start date, because the rule has done its job. As a result, the address never changes and the links it has earned stay on one page.
Redirecting products in bulk to the homepage, however, confuses visitors. A redirect to an unrelated target can also lead to problems like a soft 404 error. So the target page should be close in topic to the old one.
What are the most common 302 redirect mistakes?
The list below is a summary based on documentation and logic, not a statistic collected by our team. All of these mistakes come from a temporary code sitting in the wrong place or being forgotten.
- Making a permanent move with a 302 and leaving the old URL in the index.
- Leaving a temporary campaign rule live after the campaign has ended.
- Redirecting every old URL to the homepage regardless of topic.
- Pointing a redirect at a URL that redirects again, which builds a chain.
- Testing only in the browser without checking the status code.
- Pointing the redirect and the canonical tag at conflicting URLs.
Also, you can catch every one of these mistakes during testing. For that reason, we give a checklist at the end of this guide.
How does a wrong 302 redirect appear in the first place?
Most of the time it happens through default settings, not by choice. Apache's Redirect directive produces a temporary (302) redirect when you give no status. In nginx, the redirect flag of the rewrite directive also returns 302. So any rule where you did not write the status code yourself may be temporary.
Three more common sources exist, so check each of them:
- First, CMS plugins and themes may pick a temporary redirect by default.
- Second, you may have chosen the wrong value in the Type field of a panel form.
- Third, you may have left an old test rule live without making it permanent.
Therefore, always check the status code after you create a redirect. The next sections give the correct syntax for each environment, starting with cPanel.
How do you set up a 302 redirect in cPanel?
The Redirects screen in cPanel offers Permanent (301) and Temporary (302) as redirect types. According to the documentation, the Temporary (302) option indicates the site has moved temporarily. However, the screen name may vary a little by version.
- First, take a backup of your site and keep a copy of your .htaccess file.
- Open the Redirects screen under the Domains section in cPanel.
- Choose Temporary (302) from the Type list.
- Enter the domain and the old path, then type the full destination URL.
- Pick the www setting, tick the wildcard option if you need it, and click Add.
- Open the old URL in your browser and check the result.
According to the cPanel documentation, the panel writes the rule at the bottom of the .htaccess file. That can conflict with third-party applications that only read their own section. If WordPress rules already exist, do not leave the redirect untested.
The wildcard option redirects all files in a directory to the same filename in the new directory. So it helps if you moved a folder temporarily. But if the new folder lacks the same filenames, visitors land on a 404 page, so try a few URLs by hand first.
How do you write a 302 redirect in .htaccess?
According to the Apache documentation, the Redirect directive works inside .htaccess, but the server needs AllowOverride FileInfo. If you give no status, the redirect is temporary. In the examples below, replace example.com with your own domain.
# Temporary redirect (302 if you give no status)
Redirect "/campaign" "https://example.com/summer-sale/"
# The same rule with the status written out
Redirect 302 "/campaign" "https://example.com/summer-sale/"
# Permanent redirect
Redirect permanent "/old-page" "https://example.com/new-page/"
# Method-preserving temporary (307) and permanent (308) redirects
Redirect 307 "/checkout-test" "https://example.com/checkout/"
Redirect 308 "/old-form" "https://example.com/new-form/"
If you need a regular expression, use the RedirectMatch directive. You will find the details in the Apache mod_alias documentation.
First, copy the file before you touch it. A single typo can push the site into a 500 error, and if that happens you restore the copy. Keep these points in mind too.
- Write your rules outside the WordPress block or any other application's block.
- Do not write two rules for the same URL, because the first matching rule wins.
- Use the full destination address, starting with https.
- After every change, test with the browser cache bypassed or from the command line.
If you do not feel sure, or the file has lines you do not recognize, stop. We return to this in the section near the end. For example, if another security or cache plugin left rules in the file, leave them alone and add only your own lines.
How do you set up a 302 redirect in nginx?
According to the nginx documentation, the return directive accepts a redirect URL for the codes 301, 302, 303, 307 and 308. The redirect flag of rewrite returns 302, and the permanent flag returns 301. For a simple address, return is enough.
server {
listen 80;
server_name example.com;
# Temporary redirect
location = /campaign {
return 302 https://example.com/summer-sale/;
}
# Permanent redirect
location = /old-page {
return 301 https://example.com/new-page/;
}
}
After you save the file, test the configuration first and reload afterwards: sudo nginx -t and then sudo systemctl reload nginx. Command names can vary by distribution. For details, see the nginx rewrite module documentation.
How do the three environments compare?
The summary table below shows how you do the same job in three places. We took the default behaviors from the official documentation.
| Environment | Temporary redirect | Permanent redirect | What to watch |
|---|---|---|---|
| cPanel Redirects | Type: Temporary (302) | Type: Permanent (301) | Rule lands at the end of .htaccess |
| Apache .htaccess | Redirect 302 (the default) | Redirect permanent | Needs AllowOverride FileInfo |
| nginx | return 302 URL | return 301 URL | Test with nginx -t first |
If your hosting or server runs another layer, such as LiteSpeed or a CDN rule, the values may differ. In those cases, check your hosting provider's documentation.
How do you test that a redirect works?
Opening the address in a browser is not enough. A browser follows the redirect silently and does not show which code came back. To see the status code, ask only for the headers on the command line.
curl -I https://example.com/campaign
The first line of the output shows the status code, and the Location line shows the destination. To follow the redirect end to end, add the -L flag. That way you see every step of a chain separately.
If something goes wrong, the table below links a symptom to a likely cause. It is a diagnostic guide, so you still need the status code for a firm diagnosis.
| Symptom | Likely cause | What to do |
|---|---|---|
| Old URL still appears in search | A permanent move may have used a 302 | Switch to 301 or 308 |
| You changed the rule but see old behavior | Browser or CDN cache | Try a private window and curl |
| Too many redirects error | Two rules point at each other | Read the rules in order |
| Form data disappeared | Client turned POST into GET | Use 307 or 308 |
| Destination returns a 404 | Wrong destination URL | Check the Location value |
If the command line is not for you, our redirect checker tool does the same job in the browser. To match many old URLs to new ones, the redirect mapping tool speeds up the work.
Why are redirect chains and loops a problem with 302?
When a redirect points to another redirect, you get a chain. This mistake is common with 302 rules, because nobody reviews temporary rules regularly. Moreover, every extra hop adds loading time and raises the risk of failure.
We explained the fix in detail in our redirect chain guide, so we will not repeat it here. The short rule: the old URL should go straight to the final destination.
A loop, by contrast, happens when two rules redirect to each other. In that case the browser shows a "too many redirects" error. We cover the fix in a sibling article. To find the loop, read the rules in order and write down in a table which URL goes where.
Can a meta refresh or JavaScript redirect replace a 302?
If a server-side redirect is possible, choose it. Google's documentation says to use JavaScript redirects only if you cannot do server-side or meta refresh redirects. The reason is clear: Google tries to render every URL, but rendering may fail for various reasons.
For meta refresh, the documentation says an instant (0 second) meta refresh is read as a permanent redirect, and a delayed one as a temporary redirect. So even a redirect done in HTML carries a signal.
Also, some sites have redirect code buried in a theme or plugin file. In that case, a server-level redirect is cleaner. If you have no server access, however, meta refresh or JavaScript remains the last resort.
Our order of preference is this: server redirect first, meta refresh second, JavaScript last. If you cannot reach the hosting panel, ask your developer or your provider.
How do you monitor a redirect in Search Console?
After you set up a redirect, watch the page indexing report in Search Console for a few weeks. That is where you see whether the old URL stays in the index and whether the new URL gets discovered. We explain the report in our Search Console guide.
- Paste the old URL into the URL Inspection tool and look at the canonical URL Google selected.
- Inspect the new URL the same way and see whether it is in the index.
- Open the report again after a few weeks and check whether the status of the old URL changed.
- If a temporary rule is live, note its end date.
You can also suspect a clash with canonical tags. In that case, read our guide on the canonical tag.
If the result is not what you expected, check the status code first, then the chain, and the cache last. Those three steps solve most problems.
When should you leave a redirect to your hosting provider?
However, you do not have to do every redirect yourself. In the cases below, getting help from your hosting provider or server administrator is safer.
- You are on shared hosting and have no permission to edit .htaccess or the file is full of rules you do not recognize.
- A CDN, firewall or load balancer also redirects, because the rule may sit in more than one layer.
- You move the site to another server or domain, and email or DNS settings change as well.
- You need to change the main nginx or Apache configuration but do not manage your own VPS.
A wrong step in these jobs can take the site offline, so be careful. Even if you run your own server, take a backup first. For help with picking a provider, our hosting selection guide is a good start.
What is the final checklist for a 302 redirect?
The checklist below sums up the whole article at a glance. It helps most when several people on your team add redirect rules.
Before you publish a redirect, follow this order. That way you reduce the risk of a temporary code staying permanent by accident, or the other way around.
- First, decide whether the move is really temporary; if it is permanent, choose 301 or 308.
- If the method must be preserved, use 307 or 308.
- Then write the rule and verify the status code with the command line or a checker tool.
- Next, confirm that the destination matches the old page in topic.
- Also test that there is no chain or loop.
- Put a date in the calendar; when the temporary rule ends, remove it or make it permanent.
- Finally, watch the old and new URLs in Search Console for a few weeks.
We suggest turning this list into a template. If everyone follows the same order for every new redirect, temporary rules rarely become permanent by accident or get forgotten.
If you want help with technical SEO and site moves, you can reach our team through our SEO consulting page. This guide is general information; your provider's documentation and instructions come first for server settings.



