URL Redirect Types Explained: 301 vs 302 vs 307

You changed a URL. You moved a domain. You forced HTTPS. Now you have to tell the browser and Google what happened — and the menu of options (301, 302, 303, 307, 308) reads like a lottery draw. Pick the wrong one and you can lose rankings, break a form submission, or quietly stack up latency. Pick the right one and nobody ever notices, which is exactly the point.

This guide explains every HTTP redirect type using the primary sources that actually define them — MDN, RFC 9110, and Google Search Central — instead of recycled SEO folklore. By the end you'll have a reference table you can bookmark and a simple rule for choosing the right code every time.

What is an HTTP redirect (and how it works under the hood)

A redirect is the server's way of saying "it's not here, go there." When a client requests a URL, the server can answer with a status code in the 3xx range plus a Location header pointing at the new address. The client then makes a fresh request to that target. The whole exchange is invisible to most users — they just land on the right page.

Every redirect code differs along two axes, and once you internalize them the rest is detail:

• Permanent vs. temporary. Is this move forever (use it for canonicalization), or just for now (the original URL should stay in place)?
• Is the HTTP method preserved? Does a POST stay a POST when the client follows the redirect, or does it silently become a GET (dropping the request body)?

Those two questions explain why we need five codes instead of one. Everything below is just the matrix of "permanent or not" times "method preserved or not," plus one code (303) whose whole job is to force a GET.

Where redirects live

Redirects can be issued in three places, and they are not equally reliable for SEO:

• Server-side (Apache .htaccess, Nginx config, a framework route, a CDN edge rule). This is the real, HTTP-level redirect — a genuine 3xx response.
• Meta refresh (<meta http-equiv="refresh"> in the HTML). Works, but slower and weaker.
• JavaScript (window.location). The least reliable, because, as Google notes, "rendering may fail."

Google is explicit on the hierarchy: server-side redirects sit at the top, followed by meta refresh, then JavaScript, and it recommends you "use a permanent server-side redirect whenever possible" (Google Search Central). The rest of this guide focuses on those real server-side 3xx codes.

The full map of URL redirect types (HTTP status codes)

Here is the reference table — the asset most people come here for. Bookmark it, then read the per-code notes below for the nuance.

Code	Name	Permanent?	Method preserved?	Google canonical signal	Typical use case
301	Moved Permanently	Yes	No (POST may become GET)	Yes (canonical)	Permanent move, HTTP→HTTPS, domain migration
302	Found	No (temporary)	No (POST may become GET)	No	Temporary move, A/B test, maintenance
303	See Other	No (temporary)	No (forces GET)	No	After a form POST (POST/Redirect/GET)
307	Temporary Redirect	No (temporary)	Yes (must not change)	No	Temporary move that must keep POST/body
308	Permanent Redirect	Yes	Yes (must not change)	Yes (canonical)	Permanent API/POST endpoint move

301 Moved Permanently

MDN: "The HTTP 301 Moved Permanently redirection response status code indicates that the requested resource has been permanently moved to the URL in the Location header." It adds that search engines "attribute links to the original URL to the redirected resource, passing the SEO ranking to the new URL" (MDN, 301).

The catch: 301 predates strict method handling. As MDN warns, "when a user agent receives a 301 in response to a POST request, it uses the GET method in the subsequent redirection request." If you need the method and body to survive, "use 308 Permanent Redirect instead."

302 Found

302 means "temporarily moved." MDN states that for a 302, search engines "will not attribute links to the original URL to the new resource, meaning no SEO value is transferred" (MDN, 302). Read carefully: this is about the canonical signal, not about PageRank — a distinction we untangle in the SEO section below, because it's the single most misunderstood point in this entire topic.

302 shares 301's legacy POST→GET quirk. MDN's guidance: "To avoid user agents modifying the request, use 307 Temporary Redirect... In cases where you want any request method to be changed to GET, use 303 See Other."

303 See Other

303 is the one code that intentionally forces a GET. RFC 9110 specifies that the user agent should issue a GET regardless of the original method. MDN describes the canonical use: it's "useful when you want to give a response to a PUT method that is not the uploaded resource but a confirmation message" (MDN, 303). This is the backbone of the POST/Redirect/GET pattern that stops "are you sure you want to resubmit this form?" double-submission dialogs.

307 Temporary Redirect

307 is "302, but it keeps its promises." MDN: "The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body... With 302, older clients incorrectly changed the method to GET." For a plain GET request, "307 and 302 responses are identical" (MDN, 307). RFC 9110 puts it in normative terms: the user agent "MUST NOT change the request method if it was not GET or HEAD."

308 Permanent Redirect

308 is the strict, modern 301. MDN: "The request method and the body will not be modified by the client in the redirected request. A 301 Moved Permanently requires the request method and the body to remain unchanged... but this is incorrectly handled by older clients to use the GET method instead" (MDN, 308). RFC 9110 is blunt: for 308, "the client MUST NOT change the request method."

Two codes that aren't redirects (but get mistaken for them)

300 Multiple Choices offers several representations of a resource and is rarely used in practice. 304 Not Modified looks like a 3xx but it's a cache response — it tells the client "your cached copy is still fresh," not "go somewhere else." There's no Location header and no redirect. If you see lots of 304s in your logs, that's caching working correctly, not a redirect chain.

301 vs 302: the SEO question, answered with sources

This is where most articles go off the rails. Let's stick to primary sources.

What Google actually says about canonicalization. Per Google Search Central, "the 301 and 308 status codes mean that a page has permanently moved to a new location," and for those permanent codes "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For temporary codes (302/303/307), "the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical" (Google Search Central). In plain English: a permanent redirect tells Google "index the new URL"; a temporary one tells Google "keep the old URL indexed, I'll be back."

The "302 loses link juice" myth, killed cleanly

For years SEOs claimed 302s leak PageRank or transfer "only 90%" of link equity. That's folklore, and Google killed it back in 2016: Gary Illyes, then a Google webmaster trends analyst, stated plainly that "30x redirects don't lose PageRank anymore," confirming there is no PageRank dilution from a 301, 302, or any other 30x hop (Search Engine Land).

PageRank is passed by all redirect types — but only permanent redirects (301/308) act as a canonicalization signal. Those are two different mechanisms, and conflating them is the root of nearly every redirect myth.

Here's the honest nuance most guides skip: "passes PageRank" does not mean "pick whichever you like." The canonical signal — which URL gets indexed and shown in the SERP — depends on choosing the correct code. If a move is genuinely permanent and you use a 302, Google keeps the old URL indexed because you told it the move was temporary. PageRank isn't the problem; the wrong signal is. Use a permanent code (301/308) for permanent moves, full stop.

What Google recommends

Google's guidance is consistent: use a permanent server-side redirect whenever the move is permanent, and keep it in place for a long time. After a site move, the recommendation is to retain 301 redirects "for at least a year" (Search Engine Journal), and Google's own site-move documentation treats redirects as a long-lived part of the migration, not a switch you flip and forget.

Which redirect should you use? A decision cheatsheet

• Permanent new URL or domain migration → 301 (or 308 if the request method must be preserved, e.g. an API endpoint).
• HTTP → HTTPS → 301 server-side, ideally paired with HSTS (see the 307 Internal Redirect note below).
• A/B test, maintenance page, temporarily relocated content → 302 (or 307 if a POST is involved).
• After a form submission (to prevent double-submits) → 303, the POST/Redirect/GET pattern.
• An API that must keep POST/PUT/PATCH and its body → 307 for a temporary move, 308 for a permanent one.

Memorize the shape, not the table: permanent = 301/308, temporary = 302/307, force-GET = 303. The 30x variants ending in 7 and 8 are the "strict" ones that never touch your request method.

Redirect gotchas that quietly hurt you

Redirect chains and loops

A redirect chain is A→B→C: every extra hop is another round trip and another chance for a signal to weaken. Googlebot will follow a chain through multiple hops, but the practical advice across the industry — and consistent with Google's own crawling guidance — is to collapse chains to the fewest hops possible and point the original URL straight at the final destination. Redirect loops (A→B→A) are worse: the browser eventually gives up with an error and the page never loads. Audit your rules so a "fix" you added last year isn't now sending traffic through three intermediaries.

Redirect latency and Core Web Vitals

Each hop adds a network round trip before the user sees anything, which directly affects perceived speed. If you're chasing performance, redirects are low-hanging fruit. We go deeper on this — including how short links fit in — in our guide on short-link best practices for marketers.

307 Internal Redirect (HSTS)

If you open DevTools on an HTTPS site and see a "307 Internal Redirect," don't panic — your server didn't send it. Browsers generate this synthetic 307 to upgrade an http:// request to https:// when a site uses HSTS (HTTP Strict Transport Security). It happens entirely inside the browser, with no network request, so it's effectively free. HSTS, including the preload list, is well documented in Troy Hunt's reference on understanding HTTP Strict Transport Security. The takeaway: this 307 is a feature, not a misconfiguration.

POST → GET surprises

The single nastiest redirect bug is a POST that silently becomes a GET, dropping the request body. This is exactly why 307 and 308 exist. Never put a 301 or 302 in front of an endpoint that must keep its request body — a payment callback, a webhook receiver, an API write. Use 307 (temporary) or 308 (permanent) and the method is guaranteed to survive, per RFC 9110's "MUST NOT change the request method" language.

Redirects in URL shorteners (why your short link is a redirect)

Here's the connection most people miss: a short link is an HTTP redirect. When someone clicks mnly.to/abc, the shortener's server answers with a 3xx and a Location header pointing at your long URL. You get the redirect without ever touching .htaccess or an Nginx config. (For the full picture, see what a URL shortener actually is.)

Different shorteners make different engineering choices here, and the code they pick is a genuine trade-off rather than a right-vs-wrong call. A 302 (or 307) is not cached by default, so the browser re-requests the shortener's server on every click — which keeps click analytics accurate, at the cost of a little extra load. A 301 is cacheable by default (MDN, 301), so after the first visit a browser can jump straight to the destination without touching the shortener again — lighter on the server, but some repeat clicks "disappear" into the cache and never get counted. That tension between analytics accuracy and caching efficiency is why you'll see both codes in the wild. We compare the products themselves neutrally in Minily vs Bitly and Minily vs TinyURL.

A managed URL shortener also lets you do things a raw server redirect can't easily do: set click analytics, schedule a link to expire, or route visitors conditionally by country or device — all without redeploying anything. If you want to try the mechanics yourself, the free plan covers 5 links with unlimited QR codes, password protection, link expiration and scheduling, geo/device-conditional redirects, a UTM builder, and CSV export. To be clear about what it is and isn't: it's a redirect-and-analytics tool, not a public API or marketing-automation platform — if you need 307/308 behavior for your own REST endpoints, that's a server-side decision on your infrastructure, not something a shortener handles for you.

Frequently Asked Questions

What are the different types of URL redirects?

The HTTP redirect codes are 301 (permanent), 302 (temporary), 303 (see other / force GET), 307 (temporary, method-preserving), and 308 (permanent, method-preserving). There are also client-side options — HTML meta refresh and JavaScript window.location — but those are weaker for SEO than a real server-side 3xx response.

What is the difference between a 301 and a 302 redirect?

A 301 is permanent and tells Google the new URL should be canonical; a 302 is temporary and keeps the original URL indexed. Both pass PageRank, per Google's Gary Illyes — the difference is the canonical signal, not link equity.

Do 301 redirects pass SEO / link equity?

Yes. MDN states that with a 301, search engines attribute the original URL's links to the new resource (MDN), and Google's Gary Illyes confirmed that 30x redirects don't dilute PageRank (Search Engine Land).

Does a 302 redirect hurt SEO?

Not in terms of PageRank — Google has confirmed 302s pass it. But a 302 is the wrong signal for a permanent move, because Google keeps the original URL indexed. If the move is permanent, use a 301 or 308 so the new URL becomes canonical.

When should I use a 307 instead of a 302?

Use a 307 when the request method and body must be preserved — for example a temporary redirect on a POST request or an API call. For a plain GET, MDN notes that 307 and 302 behave identically.

What is a 308 redirect?

A 308 is the strict version of a 301: permanent and method-preserving. RFC 9110 requires that the client "MUST NOT change the request method," making 308 ideal for permanently moving API or POST endpoints without dropping the request body.

What is a 307 Internal Redirect?

It's a synthetic redirect the browser generates (not your server) to upgrade an HTTP request to HTTPS when HSTS is enabled. It happens entirely in the browser with no network request, and it appears in DevTools labeled "307 Internal Redirect."

How long should I keep a 301 redirect in place?

Google advises keeping 301 redirects for at least a year after a site move, and ideally permanently, so the canonical signal and any inbound links continue to resolve to the right page.

Conclusion

Redirects aren't complicated once you stop reading SEO myths and start reading the spec. Two questions decide everything: is the move permanent, and must the request method survive? Permanent and method-agnostic is 301; permanent and strict is 308; temporary and method-agnostic is 302; temporary and strict is 307; and 303 exists purely to force a GET after a form submission. All of them pass PageRank — only the permanent ones (301/308) set the canonical signal.

When in doubt, go to the primary sources: the per-code MDN pages, RFC 9110 for the normative method-preservation rules, and Google's Redirects and Google Search for the indexing behavior. And remember that every short link you've ever clicked is just one of these codes, quietly doing its job.