Do JavaScript-generated links truly pass ranking signals like traditional HTML links?

How does this statement change the game for JavaScript crawling?

For years, the SEO community has debated the actual capability of Google to process JavaScript links similarly to raw HTML links. The primary concern: that these links might not pass ranking signals or could simply be ignored. Martin Splitt puts this uncertainty to rest by asserting that signal transmission works normally, without loss.

The raw HTML is parsed first — this is the standard behavior of any browser. Then, Google executes the JavaScript and discovers the dynamically generated links. This two-step process creates a temporal delay in discovery, but once the link is detected, it is treated just like a link present in the initial HTML.

What is the real impact of this "slight delay" in discovery?

The word "slight" deserves clarification. Google provides no numbers — it's a qualitative statement. In practice, this delay depends on several factors: crawl budget prioritization, the bot's visit frequency, and the complexity of the JavaScript execution on the source page.

For a site with a low crawl budget, this delay can postpone the discovery of a new page linked solely via JavaScript by several days — even weeks. For a site with a comfortable crawl budget, the impact becomes negligible. However, "negligible" does not mean "none": if you’re launching a real-time campaign, every day counts.

Does this claim apply to all types of JS links?

Martin Splitt refers to "links added in JavaScript after the raw HTML", a phrasing that theoretically encompasses all cases: links generated by frameworks (React, Vue, Angular), links injected via AJAX, and conditional links displayed after user interaction. But beware: the claim does not cover links blocked by robots.txt, nor those added after events that Googlebot does not trigger (infinite scrolling without fallback, specific clicks, etc.).

The devil lies in the implementation details. A link present in the DOM after standard JS execution? OK. A link that only appears after a simulated scroll that Google does not consistently reproduce? Gray area. Splitt's assertion presumes executable JavaScript and a link actually rendered in the final DOM.

• JS links convey ranking signals in the same manner as native HTML links — no loss of value once detected.
• The only confirmed drawback: a delay in discovery, not in processing for SEO.
• This delay varies based on crawl budget and bot visit frequency — the smaller or rarer your site, the more tangible the impact.
• The claim does not cover inaccessible links for technical reasons (robots.txt, untriggered events, blocked JS).
• No quantified data on the "slight delay" — Google remains deliberately vague on the exact timing.

Is this statement consistent with on-the-ground observations?

Yes and no. Tests conducted by various SEO experts confirm that Google follows and indexes JavaScript links on well-crawled sites. Frameworks like React or Vue do not pose a PageRank transmission issue if the implementation is clean. But in real life, many JS sites generate complex architectures where links are not always rendered predictably.

The observed "slight delay" can range from a few hours to several weeks depending on the case. On an e-commerce site with thousands of products and a tight crawl budget, this delay becomes critical. Splitt's assertion is theoretically valid, but does not always reflect operational reality.

What nuances should be added to this claim?

The first nuance: "no problem for signal transmission" assumes that the link is indeed discovered. However, not all JavaScript links are rendered equally. A conditional link depending on an application state not reproduced by Googlebot will never be discovered, hence never processed. The statement does not distinguish between a "well-implemented JS link" and a "flaky JS link".

The second nuance: the discovery delay can disrupt real-time SEO strategies. If you publish hot content and the internal linking is generated client-side, you could potentially lose 48-72 hours of visibility. This is not "no impact"; it is an impact on indexing velocity. [To be verified]: Google does not provide any metrics on this average delay.

In which cases does this rule not fully apply?

There are numerous edge cases. A SPA (Single Page Application) without server-side pre-rendering may see certain URLs orphaned for days if the crawl budget is low. A site that employs aggressive lazy-loading without HTML fallback is exposed to the same risks. And importantly: a site with blocking JavaScript errors will never be crawled correctly, regardless of Google's assurances.

Another case: links added after user interaction (hover, click, scroll) are not systematically detected. Google simulates a certain level of interaction, but not all. If your navigation relies on a complex dropdown menu or a carousel without basic HTML markup, you fall outside the scope of this statement.

Should you still prioritize native HTML links for SEO?

Yes, without hesitation. Even if Google processes JavaScript links correctly, the delay in discovery remains a measurable handicap. For strategic pages — homepage, main categories, priority landing pages — the native HTML link remains the best guarantee of quick indexing and immediate PageRank transmission. JavaScript should remain a complement, not the foundation of internal linking.

Concretely: if you're developing a site in React or Vue, ensure that the critical internal linking is pre-rendered on the server (SSR) or generated statically (SSG). Secondary links can be JS, but not the main navigation. This is a pragmatic compromise between modern user experience and SEO robustness.

How can you verify that your JavaScript links are being discovered by Google?

First method: Google Search Console. Check the crawl logs and ensure that URLs solely linked via JavaScript are being crawled properly. If pages remain orphaned several weeks after publication, that’s a warning signal. Second method: test the URL via the URL inspection tool and examine the final rendered DOM — links should appear in the source code as seen by Googlebot.

Third method: analyze your server log files. If Googlebot visits Page A but never discovers Page B linked only via JS, you have a rendering issue. Compare with a crawler like Screaming Frog with JavaScript rendering mode enabled: if you see the links but Google is not following them, there is a gap between theory and practice.

What mistakes should you absolutely avoid with JavaScript links?

Mistake number one: blocking JavaScript resources via robots.txt. If Google cannot execute the JS, it will never see the links — Splitt's assertion falls apart. Mistake two: generating conditional links without HTML fallback. A menu that only displays after a user click will never be crawled if Google does not trigger that event.

Mistake three: underestimating the crawl budget. On a large site, the discovery delay can become critical. If you add 10,000 products linked solely via JS, Google may take months to discover all of them. Mistake four: not testing. Too many sites presume that "it works" without ever checking in GSC or logs if the pages are actually crawled.

• Prioritize native HTML links for critical internal linking (main navigation, categories, strategic pages).
• Use server-side rendering (SSR) or static generation (SSG) for modern JavaScript sites.
• Regularly check in Google Search Console that pages linked via JS are being crawled and indexed.
• Test rendering with the URL inspection tool and a crawler that supports JavaScript (Screaming Frog, OnCrawl, Botify).
• Never block JavaScript resources via robots.txt — it’s detrimental to modern crawling.
• Analyze server log files to detect orphaned pages or ones not discovered by Googlebot.