Can JavaScript really hide your links from Google without destroying them?

What does Google really see when JavaScript manages navigation?

This question comes up repeatedly since JavaScript became prevalent in modern web architectures. Google analyzes the HTML code as it exists after JavaScript execution, which is known as the final rendering or rendered DOM. If an <a href="..."> link is present in this DOM, Googlebot treats it like any standard HTML link.

It doesn't matter if a JavaScript event handler (onclick, addEventListener) captures the click to trigger an animation, open a dropdown, or load content via Ajax. As long as the <a> tag with its href attribute remains in the code, Google extracts the URL and follows the link. The fact that the user never actually clicks on this link—because a JavaScript function intervenes first—doesn't affect the crawl.

When does a link become invisible to Google?

The only problematic scenario occurs when JavaScript completely removes the link from the rendered DOM. Specifically: a script removes the <a> tag, or replaces the HTML link with a <div> that is entirely managed by JavaScript. In this case, Google sees no trace of the link in the final HTML.

This typically happens with poorly configured frameworks where navigation occurs solely through DOM manipulation via JavaScript components. If no href exists at rendering time, the link does not exist for Googlebot. The target page remains orphaned, invisible to the crawl.

How does this clarification change the game for mobile menus?

Many developers use JavaScript-driven dropdown menus to enhance mobile UX: a toggle button shows/hides links via CSS or DOM, and a JavaScript listener manages the opening. The concern? That Google ignores these links because they are "hidden" or controlled by external code.

Mueller clarifies: If the HTML link remains in the rendered DOM, Google sees and follows it. Whether the menu is closed by default, whether links are hidden via CSS (display:none, visibility:hidden), or whether a JavaScript event captures the click makes no impact. Google analyzes the final HTML, not user behavior. Therefore, a well-coded mobile menu does not penalize internal linking.

• An HTML link present in the rendered DOM is crawled, even if JavaScript intercepts the user's click.
• Only the complete removal of the link from the DOM (via JavaScript) prevents Google from detecting it.
• Mobile dropdown menus with HTML links + JavaScript listeners pose no crawl issues as long as the <a href> tags remain.
• Google relies on the final rendered DOM, not on the raw source code sent from the server before JS execution.
• CSS hiding techniques (display:none, opacity:0) do not prevent Google from following a valid HTML link.

Is this statement consistent with what we observe in the field?

Yes, and it’s one of the few times when the official discourse aligns perfectly with empirical tests. Since Google improved its JavaScript rendering engine (upgrading to Chromium 109+ in 2023), HTML links present after JS execution are consistently crawled. Log audits confirm that Googlebot follows these links, even when a JavaScript event handles the click on the client side.

What changes with this clarification is that it definitively validates a common practice: using JavaScript to enhance UX without breaking the linking structure. For years, some SEOs discouraged any JavaScript listeners on navigation links, fearing a crawl impact. Let’s be honest: this fear was unfounded as long as the HTML remained clean.

What nuances should be added to this rule?

Mueller talks about the rendered DOM, meaning what Google sees after executing JavaScript. The catch? If your site relies on heavy JavaScript that takes several seconds to execute, or if the JS never loads (network error, timeout), Google may crawl an incomplete version of the DOM. In this case, a link that should appear after JS execution may remain invisible.

Another point: Mueller says "Google treats the link normally," but that doesn’t mean all links carry the same weight. A link that exists only in a mobile dropdown menu closed by default remains crawlable but potentially less valued than a link that is permanently visible in the main content. [To be verified]: no official data precisely quantifies the PageRank difference transmitted, but field observations suggest a disparity.

In what scenarios does this rule not apply?

If your site uses a full JavaScript architecture without server-side rendering (SSR) or pre-rendering, there’s a risk that Google may never see certain links. A pure client-side React/Vue/Angular site that generates the entire DOM via JS may pose issues if execution fails or if the crawl budget is exceeded before full rendering.

Another edge case: links dynamically generated after a mandatory user interaction (infinite scroll, “load more” button). If the link only exists in the DOM after a click or scroll, and that trigger is not automatic, Google may miss these links. The crawl is based on the initial rendering, not all possible DOM variations due to interactions.

What should you check on your site?

First step: inspect the rendered DOM of your key pages using the URL inspection tool in Google Search Console, or directly in Chrome DevTools after disabling the cache. Check that all navigation links (main menu, footer, breadcrumb, pagination) appear in the final HTML with a valid href attribute.

Next, compare the initial source code (CTRL+U in Chrome) with the rendered DOM (DevTools > Elements). If critical links only exist in the rendered DOM (therefore added by JavaScript), ensure that Google has the time and resources to execute your JS. A rendering time exceeding 5 seconds or a high JavaScript failure rate in Search Console signals a problem.

What mistakes should you absolutely avoid?

Never replace an <a href> tag with a <div> or <span> clickable element driven solely by JavaScript. Even if it works for the user, Google loses track of the link. The same goes for links generated by frameworks that create "pseudo-routes" without ever injecting a real href into the DOM.

Another classic trap: using href="#" or href="javascript:void(0)" while counting on JavaScript to manage all navigation. Google follows these links, but they lead nowhere. The result? A broken internal linking structure, orphaned pages, wasted crawl budget on empty anchors.

How can you ensure your mobile menu remains crawlable?

Test your mobile dropdown menus in "CSS disabled" mode: if the links remain accessible in the raw HTML, you’re good. A good mobile menu with a JavaScript listener should maintain a semantic HTML structure: <nav>, <ul>, <li>, <a href>. JavaScript should merely add/remove a CSS class to show/hide, without manipulating the DOM to remove links.

Finally, monitor the index coverage reports in Search Console. If important pages show up as "Detected but not indexed" or "Crawled but not indexed," check that the internal links pointing to them are indeed present in the rendered DOM. A log audit can also reveal if Googlebot accesses the URLs via these links or if it ignores them.

• Inspect the rendered DOM of all key pages via Search Console or DevTools
• Ensure that each navigation link has a valid href attribute in the final HTML
• Compare raw source code and rendered DOM to detect links injected by JS
• Make sure the JavaScript rendering time stays under 5 seconds
• Avoid href="#" or href="javascript:void(0)" on navigation links
• Maintain a semantic HTML structure even when managing click events via JavaScript