HTTP Redirects Explained: 301, 302, 307, 308 and Fixing Loops

A redirect tells the browser or crawler that the thing it asked for lives somewhere else. Used well, redirects preserve links through a migration and force one canonical version of your site. Used carelessly, they create chains that slow pages and loops that make a site unreachable. This guide explains which status code to pick, how to configure it in common servers, and how to test and debug what you deploy.

The four codes that matter

All redirect responses carry a Location header with the target URL. They differ in two ways: whether the move is permanent or temporary, and whether the request method is preserved when the client follows it.

A fifth, 303 See Other, explicitly tells the client to fetch the target with GET, which is the correct response after a successful form POST (the post/redirect/get pattern).

Why method preservation matters

Historically, browsers turned a POST into a GET when following 301 and 302, even though the original specification did not intend that. The specification later codified the behavior as permitted, and introduced 307 and 308 to guarantee that the method and body are kept. So:

• Redirecting a normal page for browsing: 301 or 302 is fine, since it is a GET anyway.
• Redirecting an API endpoint or form handler that receives POST, PUT or DELETE: use 307 or 308, or the payload can be lost or the method changed.

Permanent versus temporary

Use permanent codes when the old URL should be replaced everywhere, and temporary codes when you will bring the original back. Be aware of caching: browsers can cache 301 and 308 responses for a long time with no revalidation, and it is hard to undo a wrong permanent redirect for users who already received it. When testing a new rule, start with a temporary redirect, confirm it behaves, and then switch to permanent. Also test in a private window or with curl, so you do not fight your own browser cache.

What redirects mean for SEO

Described carefully: search engines follow redirects and generally consolidate signals from the old URL to the new one. Google has stated that both permanent and temporary redirects can pass ranking signals, but that permanent redirects are a stronger hint that the target should be the canonical, indexed URL. In practice:

• Use a permanent redirect when a URL has moved for good, and keep it in place long term rather than for a few weeks.
• Redirect to the most relevant equivalent page, not everything to the homepage. Blanket redirects to the homepage are often treated like soft 404s.
• Keep redirects one hop where possible. Each additional hop adds latency and risk.
• Update internal links, canonical tags and sitemaps to point to the final URL, so crawlers do not rely on the redirect at all.
• Do not expect redirects to rescue content that has no equivalent; return 404 or 410 for pages that are really gone.

Search engines follow only a limited number of hops in a chain (Google documents following a limited number, around ten, before giving up), but long before that point users and crawl efficiency suffer.

Canonical redirects: HTTPS and www

Your site can often be reached in four ways: http://example.com, http://www.example.com, https://example.com, https://www.example.com. Pick one canonical form and redirect the other three to it in one hop each.

nginx

# Redirect all HTTP traffic (both hostnames) to canonical HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

# Redirect HTTPS www to apex (certificate must cover www)
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

Prefer return over rewrite for whole-host redirects; it is simpler and faster. Note that $request_uri keeps the original path and query string. Remember to keep the ACME challenge reachable on port 80 if you use HTTP-01 validation: a redirect on the same host is fine, as the CA follows it.

Apache (.htaccess or vhost)

RewriteEngine On

# HTTP to HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com%{REQUEST_URI} [R=301,L]

# www to apex
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com%{REQUEST_URI} [R=301,L]

Without the R=301 flag, RewriteRule defaults to a 302. In a virtual host, the simpler Redirect permanent / https://example.com/ or Redirect 301 /old-page /new-page also works for static paths. Behind a proxy or load balancer terminating TLS, %{HTTPS} is always off at the origin; check X-Forwarded-Proto instead (see the loop section below).

Express (Node.js)

app.use((req, res, next) => {
  if (req.headers['x-forwarded-proto'] === 'http') {
    return res.redirect(308, 'https://' + req.headers.host + req.originalUrl);
  }
  next();
});

Set app.set('trust proxy', true) if you use req.secure behind a proxy. Express defaults to 302 when you omit the status.

Cloudflare

Cloudflare offers dashboard-based Redirect Rules, Bulk Redirects and the "Always Use HTTPS" setting, all of which run at the edge before your origin sees the request. A single-redirect rule can match a hostname and respond with a static or dynamic target URL and a chosen status (301, 302, 307 or 308), preserving the query string if you enable it. Edge redirects are fast and independent of your origin, but remember they stack with any redirects your origin also sends; make sure only one layer owns each decision.

Redirect chains

A chain is A -> B -> C, such as http://example.com/page to https://example.com/page to https://www.example.com/page/. Each hop costs a round trip and TLS setup may repeat. Chains usually appear because rules were added one at a time over the years: HTTPS first, then www, then trailing slash, then a page move.

Fix by making every rule target the final canonical URL directly. The three combined redirects above deliver that for the host and scheme; for path changes, point old URLs straight to the current destination and update the old rules when the destination changes again.

Redirect loops

A loop is A -> B -> A. The browser gives up with ERR_TOO_MANY_REDIRECTS or "redirected you too many times". Common causes:

• CDN "Flexible" SSL with an origin that forces HTTPS. With Cloudflare's Flexible mode, the visitor connects to the edge over HTTPS but the edge talks to your origin over plain HTTP. If the origin (or the CMS) sees HTTP and redirects to HTTPS, the edge retries over HTTP again, forever. Fix by installing a certificate at the origin and switching to Full (strict), or by teaching the origin to trust the forwarded protocol header. Also compare with Cloudflare 520-526 errors explained, since Full modes add their own failure modes if the origin certificate is invalid.
• Origin cannot see the original scheme. Behind any TLS-terminating proxy, check X-Forwarded-Proto rather than the connection's own scheme. In nginx: if ($http_x_forwarded_proto = "http") { return 301 https://$host$request_uri; }. In WordPress, set $_SERVER['HTTPS'] = 'on' when that header says https, or use the platform's documented fix.
• Conflicting canonical rules, such as one layer forcing www while another forces the apex.
• WordPress home and siteurl values that disagree with the server's redirect rules.
• Trailing-slash rules that add a slash in one place and remove it in another.
• Cached 301s in the browser from a previous bad rule. Test with curl or clear cache.
• Login or maintenance redirects that redirect to a page which itself is protected. See also website maintenance mode done right.

Testing redirects with curl

curl -IL follows redirects and shows only headers for each hop:

curl -sIL http://example.com/some/page | grep -iE '^(HTTP/|location:)'

Typical healthy output for a canonical redirect:

HTTP/1.1 301 Moved Permanently
location: https://example.com/some/page
HTTP/2 200

Tips:

• Add -o /dev/null -s -w '%{url_effective} %{num_redirects}\n' -L to print the final URL and the number of hops.
• Use --max-redirs 5 to stop quickly on a loop.
• Test all four variants (http and https, with and without www), as well as a URL with a query string and a deep path, to verify that parameters survive.
• Test POST when it matters: curl -i -X POST -d 'a=1' http://example.com/api and confirm you receive 307 or 308 and not 301.

The रीडायरेक्ट चेकर traces each hop with status codes and timing, and the रीडायरेक्ट डिबगर helps find where in the chain a loop or an unexpected target is introduced. The HTTP स्टेटस चेकर confirms the final response.

अगले कदम

• Trace a URL with the रीडायरेक्ट चेकर
• Pinpoint a loop using the रीडायरेक्ट डिबगर
• Confirm final codes with the HTTP स्टेटस चेकर
• Verify HTTPS with the SSL Checker
• Read the robots.txt and sitemap guide to keep crawlers aligned with canonical URLs

सामान्य प्रश्न

Should I use 301 or 302 for HTTP to HTTPS?

Use a permanent redirect, 301 or 308. 308 is stricter about preserving POST requests, which matters for APIs; for ordinary page traffic, 301 is universally supported and fine.

Do 301 redirects lose link equity?

Search engines generally consolidate signals through redirects, and Google has said that ranking signals can pass through them. It is still best to keep chains short and to redirect to the closest equivalent page, because irrelevant targets may be treated as soft errors.

How long should I keep a 301 in place?

As long as the old URL might still be linked to or bookmarked. In practice that means at least a year, and often indefinitely, since the cost of keeping a redirect is tiny.

Why does my site work in one browser but show too many redirects in another?

Browsers cache permanent redirects and may hold an old rule, or cookies may influence redirect logic. Clear site data, try a private window, and compare curl results with no cookies.

Is a meta refresh or JavaScript redirect equivalent?

No. They happen after the page loads, are slower, and are weaker signals for crawlers. Use server-side status code redirects whenever you can.

What is the difference between 302 and 307?

Both are temporary. A 302 allows clients to switch POST to GET when following, while a 307 requires that the same method and body be reused. Choose 307 when you are redirecting non-GET requests.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.