Why does Google ignore your poorly formatted JavaScript links?

What does Google really see in a JavaScript link?

Googlebot handles dynamically injected links, but under a strict condition: they must adhere to classical HTML semantics. A valid link for Google is an <a> tag containing a href attribute pointing to a URL.

The catch? Many modern frameworks generate pseudo-links: <div>, <span>, or <button> styled as links, with an onClick handler that triggers navigation. For the user, it works. For Googlebot, it's empty — it does not execute event handlers attached to non-<a> elements.

Why does this technical distinction have such an SEO impact?

Because a link invisible to Google means an orphan page. If your navigation menu relies on JavaScript buttons, Googlebot won't follow those paths. The result: entire sections of your site may remain out of the index.

This is especially critical for single-page applications (SPAs) and React, Vue, or Angular apps that recreate navigation from scratch. A router.push() triggered by an onClick on a <div> leaves no trace to explore. Google doesn't guess intent: it follows what it sees in the final DOM.

In what contexts does this rule pose the most problems?

JavaScript-heavy architectures are the most affected. E-commerce sites with dynamic pagination, blogs with infinite scroll, SaaS dashboards — anywhere navigation relies on complex interactivity. A classic example: a product filter modal triggered by a button. If the links to the filtered pages are generated in this modal via JavaScript, but without <a> tags, Google will never discover them.

Another common case: mobile menus. Many hamburger menus are implemented with <button> elements that reveal <div> containing links. If these links are themselves pseudo-links, that's a double whammy: the menu is not crawled AND the destinations remain invisible.

• Google only follows <a href="URL"> tags, even if they are injected by JavaScript after the initial load.
• <button>, <span>, and <div> elements with onClick are NOT considered links, even if they trigger client-side navigation.
• A site may work perfectly for users but fail completely in crawlability if its links do not adhere to this semantics.
• Modern JavaScript frameworks require explicit configuration to generate usable <a> tags (e.g., <Link> in React Router with href or <router-link> in Vue).
• Progressive enhancement remains the safest strategy: a link must function even if JavaScript is turned off or fails.

Is this statement consistent with field observations?

Yes, and it has been documented for years. Tests with Search Console and rendering tools show that Googlebot systematically ignores onClick events on non-<a> elements. Let's be honest: Google has improved JavaScript rendering, but remains cautious. It takes no risks with ambiguous or non-standard patterns.

What is less clear — and Google remains evasive about it — is the processing delay. Is a valid JavaScript link followed as quickly as a static HTML link? [To be verified]. Observations suggest a slight delay, but no official data quantifies this differential. In production, it is observed that links injected after several seconds of rendering may slip through the cracks if the crawl budget is tight.

What nuances should be added to this rule?

The Splitt statement is binary, but reality is more nuanced. Google can theoretically discover URLs via other channels: XML sitemaps, external links, crawl history. An onClick button leading to /product-X won't transmit the link, but if /product-X is declared in the sitemap, Google will still crawl it.

The issue lies with internal PageRank. Even if the page is indexed, the lack of <a> links means zero transmission of SEO juice. A strategic product hidden behind a JavaScript button will receive no weight from the homepage. This is the blind spot of many SPA sites: the pages exist, but they are SEO-orphans, with no authority transmitted.

In what cases does this rule not apply?

There is a notable exception: links discovered via server-side rendering (SSR). If your framework (Next.js, Nuxt, Angular Universal) generates static HTML with <a> on the very first server response, Google sees them immediately, without waiting for JavaScript execution. The JavaScript can then upgrade these links to client-side navigation, but the fallback HTML remains usable.

Another edge case: Single Page Apps with prerendering. Tools like Prerender.io or Rendertron serve Googlebot a pre-rendered version with all the <a> links present. Technically compliant, but beware: Google may detect cloaking if the content served to the bot differs too much from what the user sees. The line is thin.

What should be prioritized in an audit of a JavaScript site?

Start by crawling your site with a tool that simulates Googlebot: Screaming Frog in JavaScript mode, Sitebulb, or directly the URL inspection tool in Search Console. Compare the number of links discovered with JavaScript enabled versus disabled. A significant gap signals a problem.

Next, inspect the final DOM in Chrome DevTools. Click on a suspicious navigation element and check if it's a <a> or a <button> / <div>. If you see onclick="navigateTo('/page')" without a href attribute, it's a ghost link for Google. Replace it with a real <a> tag, even if you keep a JavaScript handler for client-side routing.

How to refactor a problematic navigation component?

The technical solution depends on your framework. In React Router, use the <Link to="/page"> component which generates a <a href="/page"> while handling client-side routing. In Vue, it's <router-link :to="/page">. For Angular, <a [routerLink]="'/page'">. These components ensure HTML semantics while preserving the SPA experience.

If you cannot touch the JavaScript (legacy constraints, closed CMS), an alternative is to add static HTML links in the footer or a secondary menu. Less elegant, but it ensures crawlability. Also consider a traditional HTML sitemap, with <a> tags leading to all strategic pages. Google loves this old-school format.

What mistakes should be absolutely avoided?

Don't confuse progressive enhancement with graceful degradation. Progressive enhancement means the site works WITHOUT JavaScript, adding comfort with JS. Graceful degradation assumes JS works and provides a minimal fallback if it breaks. For SEO, only progressive enhancement guarantees crawlability.

Another frequent mistake: believing that an <a> without href but with onClick is sufficient. No. Without href, it's not a valid HTML link — even if it looks like a link. Google purely and simply ignores these elements. The href is mandatory for an <a> to be considered usable.

• Audit all navigation components (menus, paginators, filters, calls-to-action) and ensure they generate <a href="...">.
• Test the site with JavaScript disabled or via the Search Console inspection tool to identify invisible links.
• Favor server-side rendering (SSR) or static generation (SSG) for strategic pages.
• Implement a complete XML sitemap, but do not rely on it exclusively — internal linking comes first.
• Add an HTML sitemap with <a> links to all important sections of the site.
• Train development teams on HTML semantics and the importance of <a> tags for SEO.