302 vs. 307 Redirect

TL;DR — A 302 and a 307 are both “temporary” redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. — they send visitors somewhere else for now while keeping the original URL as the one that counts. Google processes them the same way, so there’s no meaningful SEO difference. The one real difference is technical: a 307 has to keep your request the same type (so a form submission stays a form submission instead of turning into a plain page fetch), while a 302 historically let that get swapped. Use a plain 302 for normal redirects; use a 307 when you’re redirecting something like a form or an API that sends data — and don’t assume “defaulting to 307 everywhere” is automatically free.

What a 302 and a 307 actually mean

Both a 302 and a 307 are redirects: you request one URL and land on a different one. The number is the HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. the server sends back, and it carries a message for browsers and search engines.

• 302 — “FoundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.” (temporary). The original temporary redirect. It says “go here for now, but the old address is still the real one — I’ll be back.”
• 307 — “Temporary Redirect.” Same message — temporary, old URL still counts — but with one extra promise attached: the browser has to repeat your exact request, including whether it was a GET (just fetching a page) or a POST (sending data like a form).

So they’re siblings. A useful way to say it: a 307 is a 302 that also guarantees the browser won’t quietly swap your form submission for a plain page request.

Does it matter for SEO?

Not in the way most site owners worry about. Google’s own documentation lists 307 as “equivalent to 302” for how its crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. process and follow the redirect. Both are “temporary” signals, so by default Google doesn’t treat the destination as the canonical page just because you redirected to it. Google’s docs don’t spell out whether 302 and 307 pass identical or different amounts of link value — what they do say clearly is that neither code hands the destination the source’s signals the way a permanent redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. does. If someone tells you 307 “passes less value” than 302, ask for their source — Google hasn’t published one saying that.

So when do I use each?

• Use a plain 302 for everyday temporary redirects — a seasonal sale page, an A/B test, a maintenance page, sending someone to a country-specific homepage.
• Use a 307 when the thing being redirected is sending data — a form submission, an API call, a login or checkout POST. Here the 307’s promise (keep the method and data exactly as they were) actually matters, because a plain 302 could let an older browser turn a POST into a GET and drop the data.

One thing that trips people up

Sometimes you’ll open your browser’s developer tools and see a 307 you never set up. That’s usually not a real server redirect — it’s your browser upgrading an http:// link to https:// on its own (a security feature called HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.) and showing it to you as a 307. Your server never sent it. More on that in the Advanced tab.

Want the full picture — the spec history, exactly what Google and Mueller say, the HSTS “phantom 307,” and framework defaults that surprise developers? Switch to the Advanced tab.

TL;DR — 302 and 307 are both temporary redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., and Google processes them the same way — its docs say 307 is “equivalent to 302,” and Mueller has said “for SEO, it doesn’t really matter” between the temporary and permanent pairs; neither code is a signal that the destination should become canonical, and Google hasn’t published a stated PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems./link-value split between them. The real difference is method preservation: an automatic 307 follow must keep the same request method (a POST stays a POST), while a 302 lets a client convert POST to GET — exact body bytes, credentials, and cross-origin behavior still depend on the client, so verify rather than assume. Reach for 307 when losing the method breaks things — APIs, forms, POST/webhook/checkout/auth flows — but watch for non-idempotent replay (a redirected payment or order call can resubmit). A plain 302 is fine for ordinary GET redirects, including Google’s own explicit recommendation for A/B tests. Watch for the HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. “phantom 307” (a Chrome UI label, not a protocol guarantee), framework specifics (Next.js documents 303 for Server Actions and 307 elsewhere — check your version rather than generalizing to other platforms), and note that Bing has no distinct 302-vs-307 guidance. My own preferred order for temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. is 307 / 302 / 303 over meta/HTTP refresh — though defaulting to 307 isn’t cost-free, so check cache headers, legacy-client support, and idempotency safeguards first.

Both are temporary — that’s the starting point

Before anything else: 302 and 307 are in the same category. Google groups 302 (Found), 303 (See Other), and 307 (Temporary Redirect) together as “temporary redirects,” and its behavior for all of them is the same — “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. follows the redirect, but the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” In plain terms, a temporary redirect keeps the source URL as the canonical by default; it doesn’t hand the destination the source’s signals the way a permanent redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. (301/308) does.

This is exactly the permanent-tier comparison one tier down: 301/308 are the permanent pair, 302/307 are the temporary pair, and the “the higher-numbered one preserves the method” logic is identical in both.

The one real difference: method and body preservation

Here’s the distinction that actually matters, in one sentence: when a client automatically follows a 307, the current HTTP spec (RFC 9110) requires it to keep the same request method; a 302 leaves the client free to change a POST to a GET. That’s a spec-level guarantee about the method — it isn’t a blanket guarantee about every byte of the body, credentials, or cross-origin handling, which still depend on the specific client implementing the redirect. Verify those with a real request rather than assuming a 307 replays everything identically in every case.

Why the ambiguity existed is a spec-history story worth telling, because most write-ups assert the fact without explaining why. In the HTTP/1.0 era, the 302 spec text technically said clients shouldn’t change the request method when following the redirect — but early browsers (Netscape, then everyone) ignored that and silently converted non-GET methods, especially POST, into GET on a 302. That inconsistent-but-universal behavior became the de facto standard. HTTP/1.1 (RFC 2616, 1999, later folded into RFC 7231 and today’s RFC 9110) formalized the split into two explicit codes to end the confusion:

• 303 (See OtherA 303 See Other is a temporary HTTP redirect that tells the client to fetch a different URL with a GET or HEAD request, no matter what method the original request used. It's the mechanism behind the Post/Redirect/Get pattern, and search engines treat it as a weak signal like a 302 or 307.) — retrieves the redirect target with GET or HEAD (not simply “always GET” — RFC 9110 allows either safe method), the intended behavior for “POST, then redirect to a result page you can safely reload.”
• 307 (Temporary Redirect) — method strictly preserved on an automatic follow, by spec; RFC 9110 doesn’t force every client to follow the redirect at all.

MDN puts the practical upshot cleanly: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” So 307 didn’t add a new capability so much as remove an ambiguity — it’s the spec-guaranteed version of what a well-behaved 302 was supposed to do all along. Modern browsers are far more consistent than the Netscape-era chaos, but 307 removes the ambiguity by specification rather than by convention.

Side by side:

Two precision notes worth keeping straight: the RFC’s allowance to convert on a 302 names POST, not every method — don’t generalize it into “302 always breaks PUT/DELETE” without checking your specific client. And neither code is cacheable by default just because of its status: RFC 9111 doesn’t list 302 or 307 among the status codes that are heuristically cacheable from the status alone — cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. still depends on explicit Cache-Control/Expires headers, not which redirect code you chose.

My own Ahrefs definition lines up with the method-preservation piece: “A 307 redirect is the same as a 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore., except it retains the HTTP method (POST, GET) of the original request when performing the redirect.”

Does Google treat 302 and 307 differently for SEO?

No — and Google is unusually explicit about it. This is a settled, low-controversy topic, the same way 301-vs-308 is.

In Google’s HTTP status codes documentation, the 302 row says Google’s crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. follow the redirect and use it as a weak signal that the target should be processed, and the 307 row says, verbatim, “Equivalent to 302.” Google then adds the caveat that applies equally to the 302/307 and 301/308 pairs: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.”

That’s the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-processing answer. Google treats them the same way for how GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. fetches and follows the redirect, and only asks that you pick the semantically correct code so non-Google clients behave well. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

One nuance worth being precise about, because it’s a real gap in a lot of other coverage: crawler-processing equivalence is a separate claim from indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. outcome. Google’s Redirects and Google Search doc groups 302, 303, and 307 together as “temporary redirects” and states that “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” That’s a real, useful guarantee — but it isn’t a promise that your source URL keeps ranking, or that the destination can never get indexed through other signals. Treat “302 and 307 are processed the same way” and “neither is a canonical signal to the target” as two separate, both-true statements — not as a claim that the two codes pass identical PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems. or link value, which isn’t something Google’s docs state either way.

John Mueller says the same thing in his own words. On the Search Off the Record “Let’s talk redirects” episode, Martin Splitt asked directly why 307 and 308 even exist alongside 301 and 302. Mueller: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” … “And with 307, 308, it also forwards POST requests.” Then the pull-quote that settles the SEO question: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.”

Note the framing there: the entire reason to reach for 307 over 302 is a functionality question (“does it work for APIs?”), not a rankings question. There is no credible primary source claiming an SEO advantage either way.

Does Bing treat 302 and 307 differently?

Honestly: Bing hasn’t said. Its public redirect guidance (the 2011 “Managing redirects – 301s, 302s and canonicals” post and the 2020 “Website Migration with Bing” post) only discusses the 301-vs-302 permanent-vs-temporary split and never mentions 307 or 308 by name. Unlike the 301-vs-308 topic — where Fabrice Canel gave a direct statement — I couldn’t find any Bing rep statement specifically on 302 vs. 307.

So I’ll say it plainly rather than assume parity: no Bing statement specifically differentiates 302 and 307. There’s a documented Bing behavior worth knowing for the temporary-redirect discussion generally — if BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. sees the same 302 enough times in a row, it will start treating it like a 301 and consolidate forward — but Bing has not publicly confirmed that behavior extends to repeated 307s. Treat that as a genuine documentation gap, not a fact about 307.

When 307 is the technically correct choice

Any redirect where losing the original method or body would break something:

• APIs and webhook endpoints — a POST/PUT/DELETE that must arrive at the new URL with the method and payload intact.
• Form submissions (POST flows) — as Mueller put it, “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.”
• Checkout, payment, and login/auth POST handoffs — anywhere dropping the body silently fails the transaction.

One safety note worth flagging: 307’s method-preservation guarantee cuts both ways. If the original request wasn’t idempotent — a payment charge, an order submission, anything with a side effect — an automatic 307 follow replays that exact request at the new URL. That’s usually what you want, but it also means a client retry or a redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency. can resubmit a non-idempotent call more than once. Put idempotency controls (an idempotency key, a duplicate-submission check) on the receiving endpoint rather than assuming the redirect alone makes the replay safe.

A big reason developers encounter 307 without choosing it: some frameworks and edge platforms default to a method-preserving code for non-GET requests. Next.js is the clearest documented example — its redirect() function returns a 303 when called from a Server Action and a 307 in other supported contexts, per its current API reference, so check your Next.js version’s docs rather than assuming one code applies everywhere in the framework. Other frameworks, CDNs, and load balancers vary by product and version — verify the actual status code your platform returns instead of assuming it matches what a similar-looking platform does. Seeing an unexpected 307 or 303 is often the platform doing something method-aware on purpose, not a misconfiguration — but confirm it for your specific setup.

When 302 is the pragmatic default

Standard temporary redirects on plain GET requests — there’s no method to preserve, so the 307 guarantee buys you nothing:

• GeoGenerative Engine Optimization — visibility inside AI answer engines./language redirects (with the usual caveat against fully blocking content by region).
• A/B and split tests — Google’s own website-testing guidance explicitly says to use a 302, not a 301, for redirected test variations, precisely because the redirect is temporary.
• Maintenance-mode / “back soon” redirects — but only when there’s an actual resource to send visitors to; if the whole site is unavailable, Google’s own guidance points toward a 503 (service unavailable) rather than any redirect. And if what’s being redirected is a non-GET request — a checkout or API call hitting your maintenance page — a 307 will replay that request at the new URL, which isn’t automatically safe if the call has side effects, so don’t reach for 307 out of habit there without checking.
• Mobile↔desktop (m-dot) redirects — Mueller’s own example of where 302 is specifically the right code: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” The right destination depends on the visitor, so it’s not a permanent move.

The HSTS “phantom 307” — a 307 your server never sent

This deserves its own section because it’s a completely different topic from choosing a redirect code, and conflating the two causes real confusion when people debug redirect chains.

If a site sends the HSTS header (Strict-Transport-Security) over HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.', the browser remembers it and, on any later attempt to hit the http:// version, upgrades the request to https:// itself — the URI gets rewritten before the request ever touches the network. Current versions of Chrome display that internal upgrade in DevTools as a 307, but nothing on the server issued it, and the exact label, byte count, or header presentation is Chrome-version-specific UI behavior, not an HTTP or HSTS spec requirement — don’t treat “307” as a guaranteed label across every browser or every future version. John Mueller spelled this out on his personal site: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirectA 307 (\"Temporary Redirect\") is a temporary redirect that, unlike a 302, is guaranteed by the HTTP spec to preserve the original request method and body — so a POST stays a POST. For SEO, Google treats it as equivalent to a 302. Browsers/tools also sometimes represent an HSTS-driven internal scheme upgrade as a 307, though the server never actually sent it and RFC 6797 doesn't require that specific code. the next time you try to access the HTTP page.” And the key clarification: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.”

I’ve flagged the same thing in my own status-codes writing — there’s even a distinct “307 HSTS Policy” meaning (“forces the client to use HTTPS”) separate from “307 Temporary Redirect.” The SEO nuance: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” So if you spot a 307 in your Network tab that you never configured, before you go hunting for a misconfigured redirect rule, check whether it’s just HSTS doing an HTTP→HTTPS upgrade for you.

Common myths

• “307 doesn’t pass the same SEO value as 302.” Unsupported — Google’s own docs say 307 is “Equivalent to 302” for how the redirect gets processed, and neither code is treated as a signal that the destination should be canonical. But Google hasn’t published an exact PageRank/link-value formula for either code, so don’t assert a precise equal (or unequal) value transfer in either direction — the accurate claim is that Google processes them the same way, not that it has quantified the value passed.
• “302 is the safer/recommended choice because it’s clearer how search engines treat it.” Overstated. Google’s treatment of 307 is equally documented (“Equivalent to 302”) — this isn’t a case of one code being better-understood by search engines. If anything, 307 offers a functionality guarantee (method/body preservation) that 302 doesn’t. (Some third-party guides state the opposite; see the note in the resources tab.)
• “A 307 in my browser’s Network tab means my server misconfigured a redirect.” Often false — if HSTS is on and you previously loaded the HTTPS version, that 307 is Chrome’s own HTTP→HTTPS upgrade, not a server response.
• “302s always convert POST to GET, so never use a 302 for a form.” Overstated for modern browsers. The POST→GET conversion was a real, well-documented problem with older clients — it’s the reason 307 exists as the guaranteed option, not proof that every 302 today drops POST data. 302 is ambiguous, not universally broken.
• “Switch all your temporary redirects to 307 for a rankings boost.” False and needless churn — there’s no ranking upside. The only valid reason to prefer 307 is a genuine need for method/body preservation (or general future-proofing).
• “303 and 307 are basically the same.” No — 303 explicitly forces the method to GET (built for POST-then-redirect-to-a-result-page patterns), the functional opposite of 307’s preservation guarantee. They’re easy to conflate because they’re listed together.

My recommendation

For temporary redirects, my preferred implementation order is 307 / 302 / 303, above meta refresh (0) and HTTP refresh (0). Notice I actually rank 307 above 302 — not because it helps SEO (it doesn’t), but because if you always use the method-preserving code, you rarely have to remember to switch later: a plain GET redirect works fine as a 307, and the day you redirect a form or an API you’re already covered. That’s a completeness argument, not a cost-free one — a genuine 307-by-default policy still needs the same cache-control discipline as any redirect, still needs to work for whatever legacy clients you actually support, and still needs idempotency safeguards on any redirect target that isn’t a plain GET fetch. Mueller made the same completeness point: “if you always use them, then you’re always safe.” That said, a plain 302 is perfectly fine, and for the specific m-dot case 302 is technically the more correct choice.

Where this sits

302 and 307 are two of the temporary 3xx redirect codes, and each has its own deep dive in this cluster, alongside the permanent pair (301, 308), the always-GET sibling 303, and the sibling comparisons — the permanent-tier 301-vs-308 (same method-preservation logic, one tier up) and the permanent-vs-temporary 301-vs-302 — plus the operational hazards, redirect chains and redirect loopsA redirect loop is a chain of redirects that circles back on itself instead of ever reaching a live page — URL A redirects to B and B redirects back to A (or a longer cycle). No page ever returns a 200, so browsers show ERR_TOO_MANY_REDIRECTS and crawlers can't index anything.. For the whole family of server responses, see the HTTP Status Codes hubAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.; redirect type is also one of the canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. signals covered in canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it..

AI summary

A condensed take on the Advanced version:

• Both are temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.. 302 and 307 keep the source URL canonical by default — neither hands the destination the source’s signals the way a permanent 301/308 does.
• Google processes them the same way. Its docs say 307 is “equivalent to 302,” and Mueller: “for SEO, it doesn’t really matter.” But that’s a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index.-processing claim, not a stated PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems./link-value formula — Google hasn’t published one for either code, so don’t assert an exact equal (or unequal) value transfer, and don’t assume “processed the same” guarantees the source keeps ranking or that the destination can never get indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. through other signals.
• The one real difference is method preservation. An automatic 307 follow must keep the same method (a POST stays a POST); a 302 lets a client convert POST to GET. 307 was added in HTTP/1.1 (RFC 2616 → 7231 → 9110) specifically to close that ambiguity — but exact body bytes, credentials, and cross-origin behavior still depend on the client, and the RFC’s conversion allowance names POST specifically, not every non-GET method.
• Use 307 for APIs, forms, POST/webhook/checkout/auth flows — but watch for non-idempotent replay (a payment or order call can resubmit on redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.; add idempotency safeguards). Use 302 for plain GET redirects — geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO./language, Google’s own explicit recommendation for A/B tests, and (Mueller’s example) mobile↔desktop. Maintenance redirects depend on whether there’s a real resource to send visitors to; a full outage is often better served by a 503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime..
• Framework defaults are version/context-specific, not universal. Next.js documents 303 for Server Actions and 307 in other contexts — check your version rather than assuming other frameworks or CDNs behave the same way.
• HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. “phantom 307”: a 307 in your browser’s Network tab is often Chrome upgrading HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' itself (HSTS), not a server response — and the exact “307” label is a Chrome-version-specific UI choice, not an HTTP/HSTS spec requirement. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.”
• Bing: no distinct 302-vs-307 guidance exists — don’t assume parity, and don’t assume its “repeated 302 → treated as 301” behavior applies to 307.
• Neither code is cacheable by default from its status alone (RFC 9111) — cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. still depends on explicit Cache-Control/Expires headers.
• Patrick’s preferred order for temporary redirects: 307 / 302 / 303 over meta/HTTP refresh — though defaulting to 307 everywhere isn’t automatically free; check cache headers, legacy-client support, and idempotency safeguards first.

Official documentation

Primary-source documentation and specs.

Google

• HTTP status codes, network and DNS errors, and Google Search — the 302 “weak signal” row, the 307 “Equivalent to 302” row, and the “semantically different — use the appropriate code” caveat.
• Redirects and Google Search — groups 302, 303, and 307 as “temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore.” and explains how each affects canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it..
• Search Off the Record, episode 51 — “Let’s talk redirects” (John Mueller + Martin Splitt) — the on-record discussion of why 307/308 exist and when they matter.
• John Mueller — A search-engine guide to 301, 302, 307, & other redirects — 302 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. behavior (the source URL “R” tends to get indexed; the redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. isn’t cached).
• John Mueller — 307s — the HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. “phantom 307” explanation.

Bing / Microsoft

• Managing redirects – 301s, 302s and canonicals (Oct 2011) — Bing’s 301-for-permanent, 302-for-temporary framing (no 307 mention).
• Website Migration with Bing (Dec 2020) — general site-move guidance (again, no 307-specific statement).

Specs

• MDN — 307 Temporary Redirect — the method/body-preservation definition and the historical note on older clients changing the method to GET.
• RFC 9110 — HTTP Semantics — §15.4.8 “307 Temporary RedirectA 307 (\"Temporary Redirect\") is a temporary redirect that, unlike a 302, is guaranteed by the HTTP spec to preserve the original request method and body — so a POST stays a POST. For SEO, Google treats it as equivalent to a 302. Browsers/tools also sometimes represent an HSTS-driven internal scheme upgrade as a 307, though the server never actually sent it and RFC 6797 doesn't require that specific code.” and §15.4.3 “302 Found,” the current spec text for both codes.

Quotes from the source

On-the-record statements from Google, plus the spec. Where the source page supports it, each link is a deep link that jumps to the quoted passage.

Google docs — 307 is equivalent to 302

• “Equivalent to 302.” (the 307 row) — Google Search Central. Jump to quote
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. so other clients (for example, e-readers, other search engines) may benefit from it.” Jump to quote
• “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. follows the redirect, but the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore., which include 302/303/307) Jump to quote

John Mueller, Google (Search Off the Record, ep. 51 — “Let’s talk redirects”; official transcript PDF, cited by passage — there’s no HTML page with matching anchor textAnchor text is the visible, clickable text of a hyperlink. It tells readers what they'll find on the other end and gives search engines context about the linked page., so no #:~:text= deep link is possible for these)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” … “And with 307, 308, it also forwards POST requests.”
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.”
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.”
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” Transcript PDF

John Mueller, Google (johnmu.com — the HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. “phantom 307”)

• “After seeing the HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirectA 307 (\"Temporary Redirect\") is a temporary redirect that, unlike a 302, is guaranteed by the HTTP spec to preserve the original request method and body — so a POST stays a POST. For SEO, Google treats it as equivalent to a 302. Browsers/tools also sometimes represent an HSTS-driven internal scheme upgrade as a 307, though the server never actually sent it and RFC 6797 doesn't require that specific code. the next time you try to access the HTTP page.”
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” Read the post

MDN — the method-preservation difference

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” Jump to quote

Which temporary redirect: 302 or 307?

Since both are temporary and SEO-equivalent, the whole decision comes down to one question — does the request carry a method or body you must preserve?

A note on the “not sure” path: 307 is processed the same way as 302 by Google and works fine for plain GET redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. too, so defaulting to it isn’t wrong — but it isn’t automatically cost-free either. Confirm your cache headers, check that any older clients you still support handle 307 predictably, and if the redirected request has side effects (a non-GET call to an API), don’t let an automatic 307 replay it without idempotency safeguards.

Temporary-redirect mistakes to avoid

Choose 302 because 307 supposedly passes less value

Google documents 307 as equivalent to 302 for search. Choose between them for request behavior, not rankings.

Assume 302 is always safer because it is older

Older clients made 302 method handling ambiguous. If a POST, PUT, DELETE, webhook, or API body must survive, use 307 for the explicit preservation guarantee.

Treat every DevTools 307 as a server rule

Chrome can display an internal HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. upgrade as 307 even though the server never returned one. Reproduce the request with a server-side checker or curl before editing redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. configuration.

Claim every 302 converts POST to GET

The historical behavior is allowed and ambiguous, not guaranteed in every modern client. Use 307 when you need certainty; do not describe all 302 implementations as broken.

Replace every 302 with 307 for an SEO gain

There is no ranking upside. Change the code only where preserving method/body improves correctness or where a framework’s safer default is appropriate.

Confuse 303 with 307

They are functional opposites on method handling: 303 deliberately changes the follow-up to GET; 307 preserves the original method and body.

Diagnose an unexpected 307 or broken 302 flow

DevTools shows an unexplained Internal Redirect / 307

Symptom: An http:// navigation appears as 307 in Chrome, but no redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. rule exists.

Likely cause: HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. upgraded the request inside the browser before it reached the server.

Fix: Check the entry’s initiator and headers, then send a request that doesn’t auto-follow redirects directly to the HTTP URL with a server-side tool — not your browser, since even a fresh Incognito window can still apply preloaded HSTS state. Don’t treat curl as an automatically neutral baseline either — it can have its own HSTS store configured, so note how you invoked it. If the raw server response differs from what DevTools showed, do not “fix” the phantom 307; audit the actual HTTP→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' server redirect separately, and replay any non-GET request as its own controlled test — a HEAD request that auto-follows can’t prove POST/body behavior.

A POST loses its body after a temporary redirect

Symptom: A form, webhook, login, or API call reaches the target as GET or without its payload.

Likely cause: The source used 302, allowing the client to change method, or an intermediary rewrote the response.

Fix: Use 307 for the temporary move, then replay a safe test request and confirm in target logs that method, content type, and body arrived intact.

The platform emits 307 even though you selected a generic redirect

Symptom: A framework or edge platform returns 307 instead of the expected 302.

Likely cause: The platform chose the method-preserving temporary code, often for a non-GET request.

Fix: Verify that the move is truly temporary and that preserving the request is correct. If so, keep it—Google treats the codes the same. Change it only when application semantics or client compatibility require a different response.

302 vs. 307 at a glance

Rule of thumb: ordinary temporary page GET → either works; temporary non-GET request that must arrive intact → 307.

Tools for identifying the redirect you really received

Patrick’s free tool

• Bulk HTTP Status Code Checker — make server-side requests for up to 500 URLs and review the actual codes and chains. It is especially useful for separating server responses from Chrome’s HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open.-only internal 307 display.

Inspect request behavior

• Redirect Checker — trace a single source through each hop and confirm whether the server starts with 302 or 307.
• Browser DevTools Network panel — inspect the initiator and whether Chrome labels an entry as an internal redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.; do not treat that alone as proof of a server response.
• curl plus application logs — send a safe POST to staging and confirm that the target receives the same method and body; if you’ve configured curl with its own HSTS store (--hsts), account for that when interpreting the result. Status-only tools cannot prove payload arrival.

Test yourself: 302 vs. 307

Five questions on the two temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. and what actually separates them. Pick an answer for each, then check.

Resources worth your time

My related writing

• 11 Types Of Redirects & Their SEO Impact (Ahrefs, with Joshua Hardwick) — my full rundown of every redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. type. It’s where I lay out my preferred implementation order for temporary redirectsA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. — 307 / 302 / 303 > meta refreshA meta refresh redirect is a client-side redirect written as an HTML <meta http-equiv=\"refresh\"> tag (or an equivalent HTTP Refresh header) — not an HTTP status code. The server returns a normal 200, then the browser navigates after the page loads. An instant (0-second) one is read by Google as permanent; a delayed one as temporary. 0 / HTTP refresh 0 — and put the SEO verdict plainly: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.”
• HTTP Status Codes & Their SEO Impact (Ahrefs) — my reference for every status code, including the two distinct meanings of 307 (Temporary Redirect vs. the HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. Policy 307) and the note that with HSTS, “Google won’t see the 307 because it’s cached in the browser.”
• The Beginner’s Guide to Technical SEO — where redirects fit in the bigger picture.

My speaking

• Patrick Stox on SlideShare and Speaker Deck — my technical-SEO talks, several of which cover redirects and canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it.. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google — HTTP status codes, network and DNS errors — the “Equivalent to 302” line and the “semantically different, use the right code” caveat.
• Google — Redirects and Google Search — groups 302/303/307 as temporary redirects.
• Search Off the Record — “Let’s talk redirects” (Google Search Relations, ep. 51) — the Mueller/Splitt discussion the quotes above are drawn from.

From around the industry

• John Mueller — 307s — the clearest explanation anywhere of the HSTS “phantom 307”: the 307 your browser shows but your server never sent.
• MDN — 307 Temporary Redirect — the clean method/body-preservation definition and the historical note on older clients.
• An SEO’s guide to redirects (Search Engine Land, Helen Pollitt) — a solid general overview of the redirect family.
• URL Redirects For SEO: A Technical Guide (Search Engine Journal) — another good technical rundown.
• A myth to correct: Conductor’s “302 vs 307” page recommends using 302 over 307 because “it’s clear how search engines treat the 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore..” That advice contradicts Google’s own docs, which explicitly call 307 “Equivalent to 302” — 307’s treatment is equally documented. Don’t treat “302 is the safer SEO choice” as authoritative; the only real decision driver is whether you need method/body preservation.
• r/TechSEO — the community for redirect and canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. debugging.

Changelog