Why can't Googlebot see links revealed after a user clicks?

What’s the difference between 'visually hidden' and 'non-existent in the DOM'?

The confusion often arises from a mix-up between CSS visibility and presence in the HTML. A link can be invisible on the screen (display:none, opacity:0, absolute positioning off-screen) while still being present in the initial source code. In this case, Googlebot extracts it without any issues during HTML parsing.

Conversely, a link dynamically generated by JavaScript after a user event (onClick, onHover, infinite scroll) does not exist in the DOM before interaction. Googlebot does not simulate any user actions — it doesn't click, scroll, or hover. These links remain invisible to the crawl, even if the final JavaScript rendering displays them correctly.

How does Googlebot handle JavaScript during crawling?

Google crawls in two stages: fetching the raw HTML, then deferred JavaScript rendering. This second phase consumes a lot of server resources and is not guaranteed for every URL. The rendering allows viewing elements added by JS on initial load, but never those conditioned on interaction.

Specifically, if your framework (React, Vue, Angular) loads a complete menu via an onClick event listener, Googlebot will only see the trigger button. The menu content? Invisible. It's a black hole in your internal linking.

Why does this technical limitation pose a practical problem?

Modern sites abuse interactive UX patterns: FAQ accordions, category tabs, conditional mega menus. These components enhance the user experience but fragment discoverability for bots. If your category page loads 50 additional products on clicking 'See more', these URLs will never be crawled via this page.

Result: you create structural orphans. Strategic pages that only exist in your XML sitemap or via external links, never in your crawlable internal structure. Your internal PageRank does not circulate properly, and your crawl depth skyrockets.

• Links present in the initial HTML but hidden by CSS are crawlable — use display:none without worry for mobile accessibility
• Links generated post-interaction (click, hover, scroll) are invisible to Googlebot which simulates no user action
• Google's JavaScript rendering doesn't compensate for this limitation: it displays what loads automatically, not what requires action
• This rule applies even to modern full JavaScript sites — client-side hydration isn't enough if conditioned on an event
• The solution involves Server-Side Rendering or initial HTML inclusion of strategic links, even if they are visually hidden afterwards

Is this statement consistent with field observations?

Yes, and it’s actually one of Google’s most empirically verifiable claims. Tests with Google Search Console (URL Inspection tool) consistently confirm: links added by onClick event listeners disappear from the captured rendering. Crawling tools like Screaming Frog with JavaScript enabled easily spot these black holes.

I’ve observed dozens of cases where e-commerce sites lost 30-40% of their internal linking due to product filters or infinite pagination initiated by clicks. The correlation with patchy indexing of deep pages is clear — Google crawls less, indexes less, and the organic traffic for long-tail categories collapses.

What nuances should be added to this rule?

First nuance: Google speaks of 'links' but the principle extends to any content conditioned on interaction. A text block revealed by clicking a 'Read more' button will not be indexed. A data table loaded after selecting a filter? Same. You lose semantic potential and ranking opportunities on long-tail queries.

Second nuance: some modern frameworks (Next.js, Nuxt) implement static pre-rendering that sidesteps the problem. If your links are generated server-side before being sent to the client, they exist in the initial HTML even if the user interaction hides/shows them later. This is the winning strategy — but it requires a real technical overhaul. [To be verified]: Google communicates little about its ability to crawl links present in the Shadow DOM or custom Web Components.

Under what circumstances does this limitation really impact SEO?

Three critical situations. First, the conditional mega menus of e-commerce sites: if your level 2-3 categories only show on hover (and are loaded via AJAX), Googlebot doesn't see them. Your thematic siloing collapses. Next, poorly implemented FAQ accordions: if each answer is in a separate div loaded on click, you lose the SEO benefit of long-form content.

Finally, the infinite pagination like 'scroll to load more'. If the button 'Load 20 more products' dynamically generates URLs on click, these pages remain orphaned. You need to either implement classic pagination alongside (often hidden) or use the rel="next"/"prev" attribute server-side to signal the series to Google.

How to audit your hidden links and detect black holes?

First step: crawl your site with Screaming Frog in JavaScript disabled, then with it enabled. Compare the two exports of internal links. Any link present only in the JS crawl is suspect — check if it requires interaction or if it loads automatically. Gaps of 15-20% are common; beyond 30%, you have a structural issue.

Second step: use the URL Inspection tool from Google Search Console on your strategic pages. Check the 'Rendered HTML' tab and compare it with your live page. If entire sections are missing (FAQs, product grids, sub-menus), it’s because they are conditioned on interaction. Also test with curl in the command line to see the raw HTML — that’s what Googlebot receives on the first pass.

What technical corrections to apply concretely?

Immediate solution: inject all strategic links into the initial HTML, even if you mask them visually with display:none or aria-hidden. For a FAQ accordion, the complete content must be present on load, and the JavaScript merely toggles visibility. It’s compatible with accessibility (screen readers) and the crawl.

Sustainable solution: switch to Server-Side Rendering (SSR) or Static Site Generation (SSG). Frameworks like Next.js (React), Nuxt (Vue), or SvelteKit handle this natively. Your pages are pre-rendered server-side with all links, then interactivity is added client-side (hydration). Googlebot receives complete HTML on the first request, without waiting for JS rendering.

For complex cases (product filters, infinite pagination), implement a crawlable alternative navigation: a classic HTML sitemap, numbered pagination at the bottom of the page, complete breadcrumbs. This dual navigation (interactive UX + crawlable fallback) is the norm on large e-commerce sites. It's more code, but it’s the price paid to reconcile modern UX with SEO discoverability.

• Crawl your site with JavaScript disabled to identify invisible links to the initial crawl
• Check via Google Search Console (URL Inspection) that your strategic links appear in the rendered HTML
• Refactor interactive components (accordions, tabs) to include content in the initial DOM, masked in CSS
• Implement SSR/SSG if your tech stack allows, otherwise plan a crawlable alternative navigation
• Systematically test each deployment with a crawl bot to detect internal link regressions
• Document in your dev guidelines the rule 'no strategic links conditioned on an onClick/onHover'