302 Redirect

TL;DR — A 302 redirect sends visitors from one URL to another temporarily. It tells search engines “this move isn’t permanent — keep the original URL in your results.” Use it when you genuinely mean temporary (an A/B test, a sale page, a maintenance notice). Use a 301 instead when you’re moving a page for good.

What a 302 redirect is

A redirect is an instruction that sends anyone who requests one URL to a different one. When a server responds to a request, it includes an HTTP status code — a three-digit number that says what happened. A 302 is one of the redirect codes. Its official name is “302 Found,” and its whole personality is one word: temporary. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

That temporary part is the point. A 302 says: this page has moved for now, but the original URL is coming back. So search engines are supposed to keep the original URL in their results and treat the destination as a stand-in, not a replacement.

Compare that to its permanent sibling, the 301 redirect, which says “this move is forever — index the new URL instead.” Same visitor experience (both send you to the new page), opposite message to search engines.

When you’d actually use one

A 302 is the right tool whenever the move is genuinely short-lived:

• You’re running an A/B test and sending some visitors to a variation of a page.
• You’ve got a temporary sale or promo page and you’ll switch back afterward.
• A page is briefly down for maintenance and you want to show a “back soon” notice without giving up the real URL’s spot in search.
• You route visitors by location or device (say, sending people to a country- or language-specific version) and the “right” destination changes per visitor.

In all of these, you want the original URL to stay put in Google’s results — which is exactly what a 302 asks for.

The thing most people get wrong

For years, SEOs treated 302s as radioactive — “they don’t pass any link value, never use them.” That’s a myth. A 302 does pass link signals; what makes it different from a 301 is only which URL search engines prefer to show. Google’s John Mueller has said 302s “have a bad reputation among SEOs, which I think is incorrect.”

The real mistake isn’t using a 302 — it’s using a 302 for a permanent move. If you permanently retire a page but redirect it with a 302, you’re telling Google “keep the old URL indexed,” so the new page you actually want ranking may not take over for a long, unpredictable time. For a forever move, use a 301.

Want the precise mechanics — Google’s “weak signal vs. strong signal” language, why a long-lived 302 can flip and start acting like a 301, and how Bing handles it? Switch to the Advanced tab.

TL;DR — A 302 (“Found”) is a temporary redirect. Google’s precise framing has two stages, not one: crawling infrastructure calls it a weak signal that the redirect target should be processed, versus a 301’s strong signal — and, separately, Search’s indexing pipeline says it doesn’t treat a temporary redirect as a signal the target should be canonical (the target can still index via other signals). Two mechanisms get conflated constantly: link-signal/PageRank passing (Mueller and Illyes have said it isn’t zero on a 302, though that’s their public statement, not a formally published universal rule) and canonicalization/indexing preference (which is what actually differs — a 302 tells Google to keep the source URL indexed). Left in place long enough, a 302 can flip — a practitioner-observed pattern, not a documented mechanism, with no published timeline. Google recommends 302 over 301 for A/B testing. The one real mistake is using a 302 for a permanent move; never build the redirect destination from unchecked user input either.

”Moved Temporarily” → “Found” — a quick history

The 302 was born ambiguous. In HTTP/1.0 it was called “Moved Temporarily,” and the spec said clients should reuse the original request method when following it. In practice, browsers didn’t — many silently switched a POST to a GET on redirect, contrary to spec. HTTP/1.1 acknowledged reality by renaming 302 to “Found” and adding two unambiguous alternatives: 303 (See Other), which always switches to GET, and 307 (Temporary Redirect), which never changes the method. The current spec, RFC 9110 (2022), still notes that clients may change POST to GET on a 302 — which is exactly why 307 exists for cases where they must not. For everyday GET-based page redirects (the SEO use case), 302 and 307 behave the same way to search engines; the method-preservation distinction only matters for form posts and API calls. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

For search purposes, Google groups 302 (found), 303 (see other), and 307 (temporary redirect) together as “Temporary,” opposite 301 and 308 as “Permanent.”

The compact decision, if you’re choosing between them:

• 302 — a following client may change POST to GET (RFC 9110). Fine for a plain GET-based page redirect; avoid it if you can’t tolerate the method changing.
• 307 — never changes the method or resends a different request. Use it when a form submission or API call must be replayed exactly as sent.
• 303 — deliberately points at a different, non-equivalent resource, normally fetched with GET/HEAD — the classic “redirect after a POST to a confirmation page” pattern, not a like-for-like stand-in for the original request.
• Caching — a 302 is not heuristically cacheable just because of its status code (RFC 9111); it’s only stored/reused if you set explicit freshness or cache directives. Don’t assume a CDN or browser will treat a bare 302 as cacheable by default.

Weak signal vs. strong signal — Google’s precise words

Skip the folklore and read Google’s actual language. In its crawling-infrastructure docs, Google says a 302 is a weak signal:

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.”

The 301 row of the same table is identical except for one word — strong:

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.”

“Weak” does not mean “zero” — but it’s also worth being precise about what is weak. These are two different Google systems talking about two different stages, not one continuum:

• Crawling infrastructure (the “weak signal” quote above) is about whether the redirect target gets processed — essentially, does Google’s crawler bother fetching and looking at the destination.
• Search’s indexing pipeline is a separate, later stage, and it states its own rule directly: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search Google: Website testing

Read together: a 302 gives Google a weak nudge to go look at the target (crawling), but Search’s indexing pipeline doesn’t treat that same redirect as a vote for making the target canonical (indexing). The target can still end up indexed and canonical — just from other signals doing that work, not from the 302 itself. Don’t collapse these into “a 302 is a weak vote for the target being canonical” — that’s not what either doc says; they’re describing different scopes.

Two mechanisms, not one

This is where most competitor content muddles things, so keep them separate:

1. Link-signal / PageRank passing is not zero on a 302. Gary Illyes said back in 2016 that Google no longer applies PageRank dilution across 301, 302, or other 30x redirects (retiring the old “~15% loss per hop” folklore), and Mueller made the same point about 302s specifically: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” Treat this as Google’s own public statement on the question, not a formally published, universal guarantee — current primary documentation doesn’t spell out an exact link-signal transfer rule for every redirect type in every situation.
2. Canonicalization / indexing preference is the mechanism that actually differs. A 301 is a strong signal to index the destination; a 302 is a weak one, so Google’s default is to keep indexing the source.

“Does a 302 pass PageRank?” and “does a 302 change which URL ranks?” are two different questions. The answer to the first is yes; the answer to the second is “not by default.” Conflating them is how the “302 = zero equity” myth got started.

Related to this: when you redirect a URL, Google tracks both ends. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” For a 302, the source stays canonical — for now.

What happens if a 302 stays up too long — the “flip”

Here’s the part that surprises people: a temporary redirect that never gets removed can stop being treated as temporary. Mueller: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.”

Why does that happen? This is my own working explanation from my Ahrefs canonicalization guide — a practitioner’s mental model built from observed behavior, not a mechanism Google has formally published — think of it as a scale tipping. Permanent redirects send signals forward to the new URL; temporary redirects send signals backward to the original URL. But:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.”

The catch: nobody knows how long that takes. As I wrote in my redirects guide, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” And Google can act sooner if it thinks you made a mistake: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” Don’t quote a specific day-count for this — there isn’t a published one, and any figure you see (including the “2 days” number that circulates in Bing folklore) is not something Google has confirmed.

How Bing treats a 302 — it watches behavior, not just the header

Bing reaches the same place by a slightly different road, and it said so explicitly. In its longstanding explainer on redirects, Bing describes watching the observed pattern of a redirect over repeated crawls rather than trusting the status code alone: redirects that keep changing destination get treated more like 302s even if they’re labeled 301, and redirects that always point to the same place get treated more like 301s even if they’re labeled 302 — Bing’s system starts to “think about them more like 301s as we continue to crawl them again and again.” That’s the same convergence Google describes, arrived at independently: given enough consistent behavior over time, both engines trust what a redirect does over what its header claims.

Bing’s older guidance also leaned harder on “use 302 sparingly” than Google does today, warning that a misused 302 can leave value stranded on the original URLs. The practical takeaway is identical to Google’s: match the redirect type to your actual intent.

When a 302 is the right call

Google doesn’t just tolerate 302s — for one use case it recommends them. From its A/B testing guidance:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.”

The legitimate use cases (all genuinely temporary):

• A/B testing — Google’s explicit recommendation, above. But don’t overstay it: Google warns that “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” Run it as long as you need for significance, then remove it.
• Geo, device, and language routing — where the “right” destination depends on the visitor, and no single URL should permanently replace the source. This one needs more than picking a status code, though: confirm what Googlebot itself gets routed to (it typically won’t carry a real visitor’s location/device signals, so check what your rule serves it), whether the routing relies on cookies or headers that a crawler won’t send, whether your cache keys and Vary header correctly separate the variants (so a cache doesn’t serve one country’s page to another), that a screen-reader or no-JS visitor can still reach the content, and that a visitor can override the automatic routing rather than get stuck on a redirect loop. Pair it with proper hreflang on the localized versions — the redirect and hreflang should agree, not fight each other.
• Temporary maintenance / service-unavailable pages — Google’s own example: “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” Think about which of these two situations you actually have. If the URL itself simply can’t be served right now (the backend is down, you’re mid-deploy), a 503 Service Unavailable with a Retry-After header on the same URL is often the more accurate response — it says “temporarily can’t fulfill this request, try again later” without redirecting anywhere. Reach for a 302 when you’re deliberately routing visitors to a different, genuinely useful explanatory URL (a status page, a “we’ll be back” page with more detail) rather than just marking the original as unavailable.
• Time-limited promotions — send visitors to a campaign page for its run, then revert.
• Load balancing / failover — routing traffic elsewhere when an origin or data center is temporarily unavailable.

See the Examples tab for these annotated side by side, and the Checklists tab for a pre-flight pass.

The one real mistake

Using a 302 when you mean a permanent move. You’re telling Google to keep the old URL indexed, so the new page you want ranking may not take over for an indefinite, unpredictable stretch — a real cost in lost visibility, not a theoretical one. If a page is gone for good, use a 301 (or 308). Related sibling mistakes: mixing 301s and 302s inconsistently inside a redirect chain, and — the failure mode of any redirect — accidentally pointing two URLs at each other and creating a redirect loop.

Implementing a 302

The header is what matters — status line 302 Found plus a Location. Google’s own PHP example:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess) — the R=302 flag is what makes it temporary (an R=301 or a bare R would default to permanent):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx — redirect issues a 302 (permanent would issue a 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Whatever the stack (WordPress redirect plugins, a CDN/edge rule, an application-level handler), the rule is the same: server-side redirects are preferred, and you must deliberately choose the temporary code — most tools default to 301, so a 302 is usually an explicit setting.

One security note that applies to any redirect, not just 302s: if the destination in your Location header is ever built from user-controlled input (a ?next= or ?returnUrl= query parameter, for example), you’ve got the ingredients for an open redirect — an attacker crafts a link on your domain that actually bounces visitors somewhere malicious. Don’t send visitors to whatever URL shows up in a request parameter; allowlist the destinations you’ll actually redirect to (a fixed set of known-safe paths or origins), and test how your redirect logic handles encoded and scheme-relative inputs (//evil.example, %2F%2Fevil.example, and similar tricks) before trusting it in production. Review each platform’s exact snippet syntax against its current version before shipping — the examples above are illustrative, not a substitute for testing against your own server/CDN.

For the permanent-move counterpart and the full head-to-head, see the sibling articles on the 301 redirect, 301 vs 302, and 302 vs 307 in this cluster.

AI summary

A condensed take on the Advanced version:

• A 302 (“Found”) is a temporary redirect (HTTP status 302). It forwards users to a new URL while signaling that the original URL should stay in search results.
• Google’s precise framing splits into two stages, not one continuum. Crawling infrastructure calls a 302 a weak signal that the target should be processed (crawled/looked at) — versus a 301’s strong signal. Separately, Search’s indexing pipeline says it doesn’t use a temporary redirect as a signal that the target should be canonical — though the target can still get indexed via other signals. Weak ≠ zero, and “processed” ≠ “made canonical.”
• 302 vs. 303 vs. 307, compactly: 302 may have its method changed POST→GET by the client; 307 never changes the method; 303 intentionally points at a different, non-equivalent resource. None of them is heuristically cacheable by default — caching requires explicit directives.
• Link-signal passing isn’t zero on a 302 — Mueller and Illyes have both said so — but that’s their public statement, not a formally published universal transfer rule for every redirect scenario. Canonicalization/indexing preference is the mechanism that actually differs: a 301 pushes indexing to the destination; a 302 keeps it on the source by default.
• Long-lived 302s can “flip.” This is a practitioner-observed pattern (Mueller, Patrick’s own experience), not a documented mechanism with a published timeline — “days, weeks, or months,” no fixed number.
• Bing watches behavior, not just the header: redirects that behave consistently over repeated crawls get reclassified regardless of the status code — the same convergence Google describes.
• Google recommends 302 (not 301) for A/B tests. Other legit uses: geo/device/ language routing (check Googlebot’s actual treatment, cookies, Vary/cache behavior, accessibility, and pair with hreflang), temporary maintenance pages (compare against a 503 + Retry-After when the same URL just can’t be served right now), time-limited promos, and load-balancing/failover. Don’t run an A/B test “an unnecessarily long time” — Google may read that as deceptive.
• Security: never build a Location destination straight from user input — allowlist destinations to avoid open-redirect abuse.
• The one real mistake: using a 302 for a permanent move — it can leave the old URL ranking instead of the new one indefinitely. Use a 301 for forever moves.

Official documentation

Primary-source documentation from the search engines and the HTTP spec.

Google

• Redirects and Google Search — the redirect-types table (permanent vs. temporary), the “keep the old URL in Search results” recommendation, alternate-URL tracking, and the PHP implementation example.
• How HTTP Status Codes Affect Google’s Crawlers — the 3xx table with the exact “weak signal” (302) vs. “strong signal” (301) language.
• A/B Testing Best Practices for Search — Google’s explicit “use a 302, not a 301” recommendation for tests, plus the warning about running one for an “unnecessarily long time.”

Bing / Microsoft

• Managing redirects — 301s, 302s and canonicals (Bing Webmaster Blog) — Bing’s explainer on the 301/302 distinction and its “we watch the behavior, not just the header” position. (The live post is JavaScript-rendered; the verbatim text is preserved in the Wayback Machine archive.)

HTTP spec / reference

• MDN — 302 Found and 307 Temporary Redirect — the method-preservation nuance and why 303/307 exist.
• RFC 9110 §15.4.3 (302 Found) — the current HTTP Semantics spec; notes clients may still change POST→GET on a 302.

Quotes from the source

On-the-record statements from Google and Bing. Each search-doc link is a deep link that jumps to the quoted passage on the source page.

Google — the weak-vs-strong distinction (the accuracy spine)

• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” — on 302. Jump to quote
• “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” — the contrasting 301 row, same table. Jump to quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” Jump to quote

Google — when to use a temporary redirect

• “If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google isn’t influenced by the redirect which may help keep the old URL in its Search results.” Jump to quote
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” Jump to quote

Google — A/B testing (302 recommended, but don’t overstay it)

• “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” Jump to quote
• “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” Jump to quote

John Mueller, Google — defusing the “302 is bad” myth

• “302 redirects have a bad reputation among SEOs, which I think is incorrect. Because they do work the same as normal redirects as well. It’s not that they don’t pass any PageRank or anything like that. And if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” Read the transcription

Bing / Microsoft — watching behavior, not just the header

• Bing has said it reclassifies redirects by observed pattern over repeated crawls: 301s whose destination keeps changing get viewed more like 302s, and 302s that always point to the same place get treated more like 301s “as we continue to crawl them again and again.” Archived source

301 or 302? — a pre-flight checklist

Run this before you ship any redirect, to make sure the code matches your intent:

• Is the move permanent? If the old URL is never coming back → 301 (or 308), not a 302.
• Is it genuinely temporary? (A/B test, promo, maintenance, geo/device routing, failover) → 302 is correct.
• Did you explicitly set the code? Most tools default to 301 — confirm the 302 is intentional, not an accident, and vice versa.
• A/B test? Use 302 (Google’s recommendation), and plan to remove it once the test reaches significance — don’t leave it running “an unnecessarily long time.”
• Temporary outage on the same URL? Consider a 503 instead; use a 302 when you’re routing to a different explanatory page.
• No redirect chains mixing 301s and 302s inconsistently — redirect straight to the final destination.
• No loops — double-check two URLs aren’t redirecting to each other.
• If a “temporary” 302 has quietly become permanent, swap it to a 301 so the signal matches reality (and don’t rely on Google’s undefined-timeline “flip”).
• Verify the actual status code returned (curl -I, browser dev tools, or a redirect checker) — a redirect plugin’s label isn’t proof of the header it sends.

Legitimate 302 use cases, annotated

Five situations where a 302 is the right call — and why the “temporary” signal matters in each.

1. A/B test

GET /pricing/           → 302 → /pricing/variant-b/

You’re sending a slice of traffic to a variation to measure it. You want /pricing/ — the original — to stay indexed and keep ranking; the variant is throwaway. This is the case Google explicitly recommends a 302 for. Remove it as soon as the test concludes; a test left running indefinitely can read as deceptive.

2. Temporary sale / promotion

GET /shoes/             → 302 → /promo/summer-sale-shoes/

For the length of a campaign, visitors land on the sale page — but /shoes/ is your evergreen URL and should reclaim its spot the moment the promo ends. A 301 here would be a mistake: you’d hand /shoes/’s ranking to a page you’re about to delete.

3. Maintenance / temporarily unavailable

GET /booking/           → 302 → /status/booking-back-soon/

A service is briefly down and you’re routing users to an explainer. Google’s own example use case. The original URL keeps its position in results while you fix things. (If the same URL is simply offline rather than routing elsewhere, a 503 Service Unavailable is often the cleaner signal.)

4. Geo / device / language routing

GET /               → 302 → /us/     (visitor in the US)
GET /               → 302 → /de/     (visitor in Germany)

The destination depends on who’s asking, so no single target should permanently replace the source URL. A temporary redirect fits because the “right” answer changes per request. (Pair with proper hreflang for the localized versions.)

5. Load balancing / failover

GET /app/               → 302 → /app-eu-west/     (primary origin down)

When an origin or data center is temporarily unavailable, traffic fails over elsewhere — but that rerouting is meant to end when the primary recovers. Temporary by definition.

The anti-pattern, for contrast:

GET /old-product/       → 302 → /new-product/     ❌ (permanent move!)

This one’s a permanent retirement dressed up as temporary. The result: Google may keep /old-product/ indexed and ranking instead of consolidating onto /new-product/, for an unpredictable stretch. This should be a 301.

Two mechanisms, not one

Use this framework to keep redirect myths from mixing separate questions.

Apply it in three steps:

1. State the intent. A 302 says the move is temporary and the original URL should remain the stable address.
2. Inspect the canonical signals. Internal links, sitemap entries, canonicals, external links, and the redirect’s duration can reinforce the source or cause the target to win.
3. Interpret a long-lived 302 correctly. If Google begins treating it like a permanent move, the redirect did not suddenly start “passing value.” The balance of canonical signals changed which URL owns the bucket.

The diagnostic question is not “does a 302 pass PageRank?” It is “which URL should be canonical, and do the redirect plus our other signals say the same thing?”

Tools for checking temporary redirects

Patrick’s free tools

• Redirect Checker — verify that the first hop is really 302, inspect the Location, and catch a chain that mixes temporary and permanent codes.
• Bulk HTTP Status Code Checker — audit up to 500 test, promotion, routing, or maintenance URLs and export any response that does not match the planned temporary behavior.

Check canonical behavior and duration

• Google Search Console URL Inspection — compare the source and variation URLs and review which one Google selected as canonical.
• Server/CDN logs — prove the redirect is limited to the intended audience and period, and that Googlebot is not receiving a different path accidentally.
• Experiment platform logs/configuration — record the test start/end, allocation, and redirect rule so a temporary response does not become forgotten infrastructure.

Prove a temporary redirect stayed temporary

Test 1 — The experiment emits a real 302

• Test to run — Check the original URL with the Redirect Checker while assigned to the redirecting variant; repeat from a clean session if allocation is cookie-based. Run this as a real GET, not just a HEAD request — server, CDN, or application handling can differ between the two, so a HEAD check alone isn’t proof of what a real visitor (or Googlebot) gets. Capture the raw status line, the exact Location value, and any cache-control headers on the response, not just “it redirected.”
• Expected result — The source returns 302 with the intended variation in Location, and the variation resolves without a loop or unrelated extra hop.
• Failure interpretation — 301/308 sends a permanent signal; 200 followed by a navigation indicates a client-side redirect rather than the planned server response; a HEAD and GET returning different status codes for the same URL means your server or CDN is handling the two methods inconsistently and needs a closer look.
• Monitoring window — Immediate after the test is enabled, then once per deployment or routing change.
• Rollback trigger — The original returns a permanent code, the destination is wrong, or any cohort enters a loop.

Test 2 — The original remains the canonical URL

• Test to run — Inspect both original and variation URLs in Google Search Console and verify that internal links, sitemap entries, and canonical tags continue to favor the original.
• Expected result — The original remains the intended canonical; the variation does not replace it as a separately indexed test page.
• Failure interpretation — Conflicting canonicalization signals or an unnecessarily long-running redirect are pushing Google toward the variation.
• Monitoring window — Check after Google recrawls the URLs and again during a long test; there is no fixed day on which a 302 flips.
• Rollback trigger — The variation becomes Google-selected canonical or begins surfacing independently for the original page’s queries.

Test 3 — The temporary rule is removed when the test ends

• Test to run — After shutdown, request the original URL in a clean session and run it through the Redirect Checker.
• Expected result — The original again returns its normal 200 content and no test allocation redirects to the variation.
• Failure interpretation — A stale CDN, edge, application, or experiment rule remains.
• Monitoring window — Immediate after shutdown, plus one check after cache expiry.
• Rollback trigger — Any production cohort continues reaching the retired variation; disable the stale rule and purge the relevant cache.

Test 4 — The full chain, method behavior, and edge cases are covered

• Test to run — Trace the entire redirect chain end to end (not just the first hop) and confirm the final destination returns a healthy response; re-run any test with a query parameter attached and confirm it’s preserved (or intentionally stripped) rather than silently dropped; try requests with a POST body if the route can receive one, to see whether the method survives or gets changed; and if the redirect target ever comes from user input, confirm it’s checked against an allowlist rather than accepting an arbitrary destination.
• Expected result — The chain resolves in a small, predictable number of hops to a working page; parameters and method behave the way your application intends; destinations outside the allowlist are rejected, not redirected to.
• Failure interpretation — A long or looping chain, a dropped parameter that breaks the destination page, a method that silently changed when it shouldn’t have, or a redirect that will follow an arbitrary ?next=-style parameter (an open-redirect risk) are all shippable-blocking findings, not cosmetic ones.
• Monitoring window — Before launch, and again after any change to the rule/CDN/framework version handling the redirect.
• Rollback trigger — Any of the above failures in production traffic.
• A caveat on tooling — Search Console’s URL Inspection tool has its own limitations for this kind of check (it reflects Google’s own crawl and doesn’t necessarily show live raw headers) — treat it as a signal about what Google saw, not a substitute for checking the actual HTTP response yourself.

Test yourself: 302 redirects

Five quick questions on what a 302 is and when to use it. Pick an answer for each, then check.

302 redirect

A 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.

Related: 301 redirect

302 redirect

A 302 redirect (HTTP status “302 Found,” originally “Moved Temporarily”) tells browsers and search engines that a resource has moved temporarily — so the original URL, not the destination, should keep its place in search results. Google treats it as a weak signal for which URL to process, versus the strong signal a 301 sends. The old “302 passes zero equity” myth is wrong: a 302 still passes link signals, and a long-lived one can eventually get treated like a 301 and consolidate onto the target. It’s the correct choice for genuinely temporary situations — A/B tests (Google recommends 302 over 301 here), geo/device routing, and maintenance pages — but the wrong choice for a permanent move.

Related: 301 redirect

Changelog