HTTP 302 redirect: what it means and when it is used

A 302 response tells the browser “the resource you requested is temporarily located at a different URL, go there instead.” The browser follows the redirect, loads the new URL, and everything works. The key word is temporarily. A 302 means the original URL is still valid and should be used for future requests. The browser should not cache or remember the redirect because the original URL might serve content directly next time.

This is different from a 301, which means the resource has permanently moved and the browser should update its records. The distinction between 301 and 302 has practical consequences for SEO, caching, and how browsers and search engines handle your URLs. Using the wrong one is a common mistake that can silently hurt your search rankings.

How a 302 redirect works#

When a server returns a 302 response, it includes a Location header with the URL the browser should go to:

HTTP/1.1 302 Found
Location: https://example.com/new-page

The browser receives this, discards the original response body (if any), and makes a new request to the URL in the Location header. This happens automatically. The user sees the final page, not the redirect response. The browser’s address bar updates to show the new URL.

You can see the redirect happening in your browser’s developer tools (F12 > Network tab) or with curl:

curl -I http://example.com/old-page

This returns the headers without following the redirect. You will see the 302 status and the Location header. To follow the redirect and see the final destination:

curl -IL http://example.com/old-page

The -L flag tells curl to follow redirects. The output shows each hop in the chain, including any intermediate redirects.

302 vs 301: when to use which#

This is the most important distinction and the one people get wrong most often.

301 (Moved Permanently) means the resource has permanently moved to a new URL. The old URL should not be used again. Browsers cache 301 redirects aggressively, meaning they will go directly to the new URL on subsequent visits without even checking the old URL. Search engines transfer the ranking value (link equity) from the old URL to the new one.

Use 301 when:

• You changed a URL slug permanently
• You moved from one domain to another
• You consolidated duplicate pages into one canonical URL
• You switched from HTTP to HTTPS (the redirect from  http://  to  https://  should always be 301)
• You removed  www  or added it permanently

302 (Found / Temporary Redirect) means the resource is temporarily at a different URL. The old URL is still valid. Browsers do not cache the redirect (or cache it only briefly). Search engines do not transfer ranking value because they expect the original URL to come back.

Use 302 when:

• A page is temporarily under maintenance and you are routing visitors to a placeholder
• You are running an A/B test and redirecting a percentage of traffic to a variant
• You are redirecting users based on geolocation and the redirect could change
• A product is temporarily out of stock and you are redirecting to a category page
• You are doing a short-term promotion that redirects a URL temporarily

The common mistake: using 302 when you mean 301. If you changed a URL permanently and use a 302, search engines will keep indexing the old URL instead of the new one. The ranking value stays on the old URL. Over time, Google may figure out you meant a permanent redirect, but this can take months and there is no guarantee. Using the correct status code from the start avoids the ambiguity.

The other common mistake: using 301 when you mean 302. If you redirect a URL with a 301 during a temporary maintenance window and then remove the redirect, browsers that cached the 301 will continue going to the redirect target even after you removed it. Clearing a cached 301 requires the user to clear their browser cache, which most users will never do. Use 302 for anything temporary to avoid this problem.

302 vs 307 vs 308#

HTTP has additional redirect status codes that address an edge case with how browsers handle the original request method during a redirect.

302 (Found) technically means the browser should use the same HTTP method when following the redirect. In practice, virtually all browsers convert POST requests to GET when following a 302. This has been standard browser behavior since the 1990s, even though it violates the HTTP specification. If a form submits a POST to /submit and gets a 302 to /result , the browser follows up with a GET to /result , not a POST.

307 (Temporary Redirect) was introduced to fix this. A 307 explicitly requires the browser to preserve the original HTTP method. A POST that gets a 307 must follow up with a POST to the new URL. Use 307 when you need to redirect a POST request and the destination must also receive a POST.

308 (Permanent Redirect) is the method-preserving equivalent of 301. It means “permanently moved, and keep the same HTTP method.” Use 308 when a POST endpoint has permanently moved and the redirect target should also receive a POST.

For most WordPress and web hosting scenarios, 301 and 302 cover everything you need. 307 and 308 are relevant for APIs and form processing where preserving the HTTP method matters.

302 redirects in WordPress#

WordPress uses 302 redirects internally in several places, and plugins add more. Understanding where they come from helps when you are debugging redirect chains or loops.

WordPress core redirects

WordPress issues 302 redirects in these situations:

• After a successful login, WordPress redirects from  wp-login.php  to the admin dashboard (302 because the login page should not be cached as a permanent redirect)
• After saving a post or updating settings, WordPress redirects back to the editor or settings page with a success message in the URL
• When canonical URL redirect fires (WordPress redirecting from a URL with extra query parameters or trailing characters to the clean canonical URL)
• When a logged-out user tries to access wp-admin, WordPress redirects to  wp-login.php  with a  redirect_to  parameter

These are all correct uses of 302 because they are session-dependent or context-dependent, not permanent moves.

Plugin-generated redirects

SEO plugins like Yoast SEO and Rank Math include redirect managers. When you change a post slug, these plugins automatically create a redirect from the old URL to the new one. Make sure these are configured as 301, not 302, since a slug change is permanent.

Caching plugins sometimes use 302 redirects for cache misses or for routing requests through cache warming endpoints. These are typically invisible to users and do not affect SEO.

Security plugins that redirect visitors away from blocked pages (country blocking, IP blocking) should use 302 because the block is conditional, not permanent.

WooCommerce redirects

WooCommerce uses 302 redirects during the checkout flow. After adding a product to the cart, WooCommerce may redirect to the cart page. After completing checkout, it redirects to the order confirmation page. These are all appropriate 302 uses because they are session-specific actions.

If WooCommerce checkout is stuck in a redirect loop, the issue is usually a conflict between WooCommerce’s own redirects and a caching plugin, security plugin, or server-level redirect rule. See too many redirects in WordPress for the full diagnostic.

302 redirects in Nginx#

Nginx uses the return and rewrite directives to issue redirects. Understanding the syntax helps when you need to create, modify, or debug redirects at the server level.

Creating a 302 redirect

# Redirect a single URL temporarily
location = /sale {
    return 302 /promotions/summer-sale;
}

# Redirect with a regex pattern
location ~ ^/temp/(.*)$ {
    return 302 /archive/$1;
}

The return 302 directive sends a 302 response with the specified URL in the Location header. Nginx does not process the request further after issuing the return.

Rewrite with 302

rewrite ^/old-path/(.*)$ /new-path/$1 redirect;

The redirect flag on a rewrite rule issues a 302. The permanent flag issues a 301. If you see redirect in an Nginx rewrite and the intent is permanent, change it to permanent .

Common Nginx redirect patterns

# HTTP to HTTPS (should be 301, not 302)
server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

# www to non-www (should be 301, not 302)
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

# Temporary maintenance redirect (correct use of 302)
location / {
    return 302 /maintenance.html;
}

The HTTP-to-HTTPS and www-to-non-www redirects should always be 301 because they are permanent decisions. If you find these configured as 302 on your server, change them to 301. On Hostney, these redirects are handled automatically with the correct status codes when you enable Force HTTPS or configure your preferred domain format in the control panel.

How 302 redirects affect SEO#

Search engines treat 301 and 302 redirects very differently:

301 redirects transfer ranking value. When Google follows a 301, it updates its index to point to the new URL and passes the link equity (backlinks, PageRank) from the old URL to the new one. The old URL is eventually removed from the index.

302 redirects do not transfer ranking value (initially). When Google follows a 302, it keeps the old URL in its index because the redirect is marked as temporary. The new URL may be crawled and indexed separately, but the link equity stays on the original URL. If Google determines that a 302 is actually permanent (which it sometimes does after a long period), it may eventually treat it like a 301, but this is not guaranteed and takes time.

The practical consequence: if you moved a page permanently and used a 302, you are splitting your SEO signals between two URLs. The old URL keeps the backlinks and ranking value. The new URL has to build authority from scratch. This can cause both URLs to rank worse than a single consolidated URL with a proper 301.

Checking your redirects for SEO issues: use a crawler like Screaming Frog, Sitebulb, or the free Redirect Checker tool to scan your site for 302 redirects that should be 301s. Look specifically for:

• Old blog post URLs redirecting to new slugs via 302
• Domain or protocol changes (HTTP to HTTPS, www to non-www) using 302
• Category or tag URL changes using 302
• Any 302 that has been in place for more than a few weeks

If a 302 redirect has been active for more than a month and you have no plans to revert it, change it to a 301.

Redirect chains and their impact#

A redirect chain is when URL A redirects to URL B, which redirects to URL C, which finally serves the content. Each hop adds latency and loses a small amount of SEO value. Chains of three or more redirects are common on sites that have gone through multiple URL changes over the years.

# Check for redirect chains with curl
curl -ILs http://example.com/old-page 2>&1 | grep -E "^HTTP|^location"

This shows every hop in the chain. A clean redirect is one hop. Two hops are acceptable. Three or more should be consolidated.

Common causes of redirect chains:

• An HTTP-to-HTTPS redirect followed by a www-to-non-www redirect followed by a WordPress canonical redirect (three hops for what should be one)
• A 301 from an old URL to a second URL that was itself later redirected to a third URL
• A plugin redirect layered on top of a server-level redirect to the same destination

Fix chains by pointing every redirect directly to the final destination. If A redirects to B and B redirects to C, update A to redirect directly to C and remove the intermediate hop.

Redirect loops and 302#

A redirect loop is when URL A redirects to URL B, and URL B redirects back to URL A. The browser bounces between them until it gives up and shows the too many redirects error.

302 redirects are more likely to cause loops than 301 redirects because they are often conditional. A rule that says “if the user is not logged in, redirect to the login page” combined with a rule that says “if the user visits the login page without a specific parameter, redirect to the homepage” creates a loop. Each redirect is a 302 because the condition could change, but together they trap the browser.

Diagnosing redirect loops:

# Follow redirects and show each hop (curl stops at 50 by default)
curl -ILs -o /dev/null -w "%{url_effective}\n%{redirect_url}\n" http://example.com/page

# Or use verbose mode to see every redirect
curl -vL http://example.com/page 2>&1 | grep "< HTTP\|< location"

If you see the same two URLs alternating, you have a loop. Check both the server configuration and WordPress for conflicting redirect rules. The WordPress login redirect loop is a specific variant of this where the login page and wp-admin redirect between each other due to cookie or URL issues.

Diagnosing 302 issues#

Check the response directly

# See the 302 response and Location header
curl -I https://example.com/page

# Follow the full chain
curl -IL https://example.com/page

Check in browser developer tools

Open the Network tab (F12), load the page, and look for requests with a 302 status code. Click the request to see the Location header in the response. Check whether the final destination is what you expected.

Enable “Preserve log” in the Network tab before testing redirects. Without it, the browser clears the network log on each redirect and you only see the final request.

Check Nginx configuration

grep -rn "return 302\|redirect;" /etc/nginx/

This finds all 302 redirects and rewrite rules using the redirect flag across your Nginx configuration. Review each one to confirm the redirect is intentional and using the correct status code.

Check WordPress database

If a redirect is happening and you cannot find it in the server configuration or in plugin settings, it may be in the WordPress options table:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

A mismatch between siteurl and home (especially protocol or www differences) causes WordPress to issue redirects that can loop or chain with server-level redirects.

Managing redirects on Hostney#

Hostney provides redirect management through the control panel under Hosting > Redirects (301/302). You can create both 301 and 302 redirects without editing Nginx configuration files. The control panel validates the redirect to prevent loops and provides a clear overview of all active redirects for each domain.

For HTTPS enforcement and www/non-www preferences, Hostney handles these at the server level with the correct status codes (301 for permanent protocol and domain redirects). This avoids the common problem of WordPress plugins adding their own redirect layer on top of a server-level redirect, which creates unnecessary redirect chains.

If you are troubleshooting a redirect issue on Hostney, check the control panel’s redirect list first. If the redirect is not there, it is coming from WordPress (a plugin, the database settings, or .htaccess on Apache-based setups). The control panel also shows whether each redirect is a 301 or 302, making it easy to audit for incorrectly typed redirects.

Quick reference#

For redirect loops and the “too many redirects” error in WordPress, see the full troubleshooting guide. For the related issue where the WordPress login page keeps redirecting, see WordPress login page refreshing and redirecting: how to fix it. For other common WordPress errors, see How to fix the most common WordPress errors. For mixed content errors that often appear alongside HTTP-to-HTTPS redirect issues, see the dedicated guide.