Are JavaScript links really being tracked by Google?

Why does Google insist on JavaScript rendering?

Googlebot no longer just reads the raw HTML source code. For several years, it has been executing JavaScript to see the page as it actually appears to users. This rendering step allows for identifying dynamically generated links, content loaded via Ajax, and all elements that do not exist in the initial HTML.

But this approach has a cost: the processing time is much longer than a simple HTML crawl. Google must render the page, wait for the JS to execute, and then extract the links from the final DOM. If your site generates links asynchronously or conditionally, the risk of failure increases significantly.

What does Google consider a “real link”?

A real link is a <a> tag with an href attribute present in the DOM after rendering. It doesn't matter if it's created via JavaScript or directly in the initial HTML—if it’s in the final DOM, Google can follow it. The problem arises with pseudo-links:

Is this statement consistent with real-world observations?

Yes, and this is even one of the few topics where Google's narrative aligns well with technical reality. We regularly observe poorly implemented React or Vue sites where certain sections are never crawled because links are simulated via JavaScript. Server logs show that Googlebot doesn’t even request these URLs—logically, since it has never discovered them.

However, what Mueller doesn't specify here is the timing of rendering. Google does not wait indefinitely for your JS to execute. If your links take 10 seconds to appear because you're chaining three asynchronous API calls, they might not be in the DOM when Googlebot takes its snapshot. This variable delay is rarely documented and varies based on the crawler's load.

What nuances should be considered regarding this rule?

First, not all links need to be crawlable. If you're dynamically generating facet filters with thousands of possible combinations, you may not want Google to follow them all. In this case, using pseudo-links or buttons with JS events could even be a deliberate crawling control strategy—provided you manage it properly with canonicals and robots directives.

Additionally, there are hybrid solutions that work well: you can have a classic <a href="..."> AND intercept the click in JavaScript to load content via Ajax. The user enjoys a smooth SPA experience, while Google sees a standard link. Many high-performing e-commerce sites do this—the best of both worlds.

When does this rule become problematic?

Highly interactive applications—dashboards, SaaS tools, configurators—pose a real problem. Sometimes, navigation isn’t even linear: it depends on user actions, session states, permissions. Asking Google to crawl this exhaustively makes no sense. [To be checked] Mueller provides no guidance on how to manage these edge cases.

Another gray area is infinite scrolls and lazy loading of content. Technically, they do not generate new navigation links, but additional content. Google states that it can handle them, but on high-volume sites, we regularly see that late-loaded elements are indexed late—or not at all. Again, the official discourse remains vague on the real limits of the system.

How can I check if my links are crawlable?

The first step is to inspect the rendered DOM, not the source code. Open your browser's console, right-click > Inspect on your navigation links, and check that they are indeed <a> tags with a valid href attribute. If you see <div>, <span> or <button>, you have a problem—even if everything works visually.

Then, use the "Inspect URL" tool in Google Search Console. It shows you the rendered HTML as Googlebot sees it after executing JavaScript. Compare it with what your browser displays: if links are missing, it's because Google wasn't able to capture them. You can also crawl your site with Screaming Frog in JavaScript mode activated—the discrepancies between standard crawl and JS crawl are often revealing.

What mistakes should be avoided in the implementation?

The first classic mistake: using onClick without href. A link like <a onClick="navigateTo('/page')"> without an href attribute is invisible to Googlebot. The same goes for buttons styled as links—if it's not an <a> tag, it won't work. The href must point to a real URL, not to "#" or "javascript:void(0)".

The second error: links generated too late. If your main menu or footer are built via asynchronous API calls that take several seconds, Google might take its snapshot before they appear. Prefer server-side rendering for critical navigation elements—even if it means loading secondary content later.

What should be done concretely to comply?

If you are using a modern JavaScript framework, adopt the native navigation components. For React, it's <Link> from React Router or Next.js. For Vue, <router-link>. For Angular, routerLink. These components automatically generate valid <a> tags while managing SPA navigation. Don't reinvent the wheel with custom solutions.

For existing sites, set up a regular monitoring strategy via Search Console: watch the ratio of discovered pages to indexed pages, and check that new sections are being crawled in the days following their launch. A gradually widening gap is often a sign of a discoverability issue related to links.

• Audit the rendered DOM with DevTools to check for the presence of <a href="..."> tags
• Test key pages with the "Inspect URL" tool in Search Console
• Crawl the site with Screaming Frog in JavaScript mode enabled and compare with a standard crawl
• Replace pseudo-links (div, button onClick) with real <a> tags or framework components
• Implement SSR or static generation for critical navigation elements
• Regularly monitor discovery and indexation rates in Search Console