Do 302 redirects actually pass PageRank just like 301s?

What’s the theoretical difference between a 301 and a 302?

301 redirects indicate a permanent resource move. When Googlebot encounters this HTTP code, it understands that the source URL no longer exists and that all signals — PageRank, link history, behavioral signals — should migrate to the destination.

302 redirects, on the other hand, indicate a temporary move. In theory, the engine keeps the original URL in its index and does not transfer any signals. The destination page receives traffic, but the source URL retains its identity in search results.

Why would Google end up treating a 302 as a 301?

The problem is that many 302 redirects are never removed. A developer sets a “temporary” redirect for an A/B test or a seasonal campaign, and six months later, it’s still running in production.

Google has therefore introduced a detection logic: if a 302 persists through several consecutive crawls — we’re talking weeks or even months — the engine considers that the redirect is actually permanent. It then begins to gradually transfer SEO signals to the destination, just like a 301.

How does Google determine that a 302 is “persistent”?

Here it gets fuzzy. Google has never published a precise threshold. We know that the engine crawls pages at varying frequencies based on their importance and freshness. A 302 on a daily crawled page will be detected faster than one on a page visited once a month.

In practice, field observations suggest that a 302 maintained beyond 3-4 weeks starts to be treated differently. But there’s no strict guarantee — it’s an algorithmic heuristic, not a binary rule.

• 301s immediately transfer SEO signals to the destination
• 302s are supposed to be temporary and don’t transfer anything… in theory
• A 302 persisting for several weeks or months will gradually be treated as a 301
• Google has never communicated a specific time threshold for this switch
• Frequent crawling of a page speeds up this detection

Is this statement consistent with what we observe in the field?

Overall, yes. Tests show that 301s do indeed transfer PageRank — this has been documented since the 2010s. On the 302 side, cases of temporary redirects becoming permanent are common, and we do often see the destination URL eventually replacing the source in the SERPs after a few weeks.

That said, the timing remains opaque. I've seen poorly configured 302s linger for two months without visible transfer, and others switch in three weeks. The frequency of crawl and the authority of the source page clearly play a role, but Google doesn’t provide any usable numbers. [To be verified]: the exact impact of the delay depending on the type of site.

What nuances should we add to this rule?

First point: the transfer of a “persistent” 302 is never as clear-cut as a 301. We often observe a phase of float where both URLs coexist in the index, with ranking fluctuations. If you need a fast and clean transfer — domain migration, structural redesign — the 301 remains the only reliable choice.

Second nuance: not all 302s end up being treated as 301s. If the source page is regularly reactivated — for example, a redirect that switches between two versions depending on the day of the week — Google does not interpret that as permanence. The context of use matters.

In what cases does this logic pose a problem?

The real issue is that many CMS and web frameworks default to 302s. A non-SEO aware developer sets a redirect without questioning it, and the system sends a 302 code. Six months later, Google has transferred the signals without anyone noticing, and the original URL has disappeared from the index.

Result: if you really want a temporary redirect — A/B test, event page, scheduled maintenance — you must either remove it quickly or accept that Google will eventually consider it permanent. There’s no stable gray area.

What concrete actions should be taken to avoid mistakes?

First action: audit all active redirects on your site. Export the list from your server or CDN, identify the 302s, and check their installation date. Any 302 that exceeds four weeks should either be converted to a 301 or removed if the temporary situation is resolved.

Second point: configure your development tools to default to 301s. If your technical team must explicitly choose a 302, it prompts reflection. Most redirects in production are permanent — might as well accept that from the start.

How can I check if my redirects are correctly interpreted by Google?

Utilize Search Console to monitor indexed URLs. If a page redirected with a 302 for several weeks still appears in the index, it means Google is hesitating or hasn’t made the switch yet. If the destination URL shows up, the transfer has likely occurred.

You can also cross-reference with your server logs: if Googlebot continues to crawl the source URL despite an old 302, it still considers it temporary. If the crawl frequency drops significantly or stops, it means the engine has shifted its focus to the destination.

What mistakes should be avoided during a migration or redesign?

Classic mistake: setting 302s “as a precaution” while waiting to validate a migration. Bad idea. Either you migrate and set 301s, or you don’t migrate. A prolonged 302 creates an algorithmic uncertainty that can delay PageRank transfer by several weeks.

Another trap: mixed redirect chains. For example, a 302 pointing to a 301. Google follows these chains, but each jump dilutes signals and slows down crawling. If you must redirect, do it in one leap with the correct HTTP code.

• Regularly audit the list of active 302 redirects
• Convert any persistent 302 to a 301 or remove it
• Configure development tools to default to 301s
• Monitor the index via Search Console to detect shifts
• Avoid redirect chains — always redirect in one jump
• Document each 302 with an expected end date and an automatic reminder