Do JavaScript redirects really pass PageRank?

Why does Google differentiate JavaScript redirects from traditional redirects?

Traditional HTTP redirects (301, 302, 307, 308) are immediately understood by Googlebot during the initial crawl. They are part of the HTTP protocol itself, even before the page content is downloaded.

JavaScript redirects, on the other hand, require the engine to execute client-side code to detect that a redirect exists. This involves an additional step: rendering the page. If Googlebot does not execute the JavaScript, or if the code is poorly implemented, the redirect remains invisible.

What does it really mean by "if Googlebot can follow them"?

This phrasing conceals several technical scenarios. A link may be blocked by robots.txt, the JavaScript may be malformed or refer to external resources that are not loaded, or the execution timeout may exceed the engine's processing capabilities.

In all these cases, Googlebot considers the link to be non-existent. No PageRank is passed, no discovery of the target page, no indexing. The link becomes technically dead from an SEO perspective.

What is the difference between a "non-existent link" and a "nofollow link"?

A nofollow link remains visible in the DOM and is detected by Google, which may choose to ignore it or not based on its algorithm. A link lost in a non-executed JavaScript redirect is never seen.

This is a critical distinction. A nofollow leaves a trace, potentially allowing for URL discovery. A failed JavaScript redirect makes the link disappear from the link graph, as if it were never coded.

• JavaScript redirects require client-side rendering to be detected by Googlebot
• A nofollow link is treated as non-existent, with no PageRank passed and no page discovery
• Blocking robots.txt, a faulty JS code, or a timeout is enough to fail detection
• A nofollow remains detectable, unlike a failed JavaScript redirect that disappears completely
• The performance of JavaScript execution directly impacts Google's ability to follow these links

Is this statement consistent with practices observed in the field?

Yes, and this is the entire problem. We regularly observe sites losing internal link juice or incoming PageRank because part of their navigation relies on poorly implemented JavaScript redirects. Tools like Search Console or Screaming Frog do not always detect these losses, as they crawl differently from Googlebot.

Rendering tests via the URL inspection tool sometimes show glaring discrepancies between raw HTML and what Google actually sees after execution. When a link goes through a JS redirect that silently fails, no error message appears — the link simply disappears, that's it.

What nuances should be added to this claim from Google?

The phrasing "can pass weight and signals" remains vague. [To be verified]: Google does not specify whether the transmission is complete or subject to depreciation compared to a traditional HTML link. Field observations suggest that a link via JavaScript redirect works worse than a direct HTML link, even when it is technically followed.

Another friction point: the delay. If JavaScript rendering takes several seconds and the crawl budget is tight, Googlebot may abandon before executing the redirect. Result? A link that technically exists but remains invisible in practice.

In what contexts do these types of redirects pose the most problems?

Single Page Applications (SPA) and React/Vue/Angular sites not optimized for SSR (Server-Side Rendering) are the primary concerns. If all navigation relies on JavaScript and server-side rendering is absent, every URL change becomes a potentially ignored JS redirect.

E-commerce sites with product filters or sorting options managed in JavaScript also encounter this problem. If a filter triggers a JS redirect to an indexable URL, and Google does not execute it, a whole part of the catalog remains orphaned from a crawl perspective.

How can I check if my JavaScript redirects are properly followed by Google?

First step: use the URL inspection tool in Search Console and compare raw HTML with the rendered version. If a link with a JS redirect appears in the rendering but not in the source HTML, it depends on JavaScript execution. Then check that the target URL is indeed discovered and indexed.

Second verification: analyze the server logs to confirm that Googlebot is actually crawling the target URLs after visiting the pages containing JS redirects. If the target URLs are never crawled despite receiving links, it's a warning signal.

What mistakes should absolutely be avoided in the implementation?

Never block critical JavaScript resources via robots.txt. This seems obvious, but it's the most common mistake. If Google cannot load the JS file containing the redirect logic, everything collapses.

Avoid redirects that depend on user events (clicks, scrolls, hovers). Google does not emulate these interactions. A redirect that only triggers when clicking a button remains invisible to the bot. Favor redirects that execute automatically upon page load.

Should JavaScript redirects always be replaced by HTTP redirects?

Ideally, yes — but this is not always technically possible. If your site uses a modern framework with client-side routing, forcing HTTP redirects may break the user experience. In this case, opt for Server-Side Rendering (SSR) or static prerendering.

A hybrid solution is to use standard HTML links for main navigation, reserving JavaScript for secondary interactions. This way, the link structure remains crawlable even without JavaScript execution, and Google can follow critical redirects without depending on rendering.

• Always check JavaScript rendering via the URL inspection tool in Search Console
• Analyze server logs to confirm that Googlebot crawls the target URLs after JS redirects
• Never block critical JavaScript files via robots.txt
• Favor automatic redirects over those triggered by user interactions
• Opt for SSR or standard HTML links when technically feasible
• Monitor the crawl budget: too many JS redirects slow down rendering and create bottlenecks