Are hidden mobile links really counted by Google in mobile-first indexing?

John Mueller's statement clarifies a frequently confusing point: the difference between a link present in HTML but visually hidden (display:none, position:absolute off-screen, etc.) and a link completely absent from the mobile DOM.

With widespread mobile-first indexing, Googlebot first crawls the mobile version of your site. If a link exists only in the desktop template and is not injected into mobile HTML at all, it disappears from Google's radar.

What is the difference between a hidden link and an absent link?

A hidden link is a link that is present in the HTML source code but is hidden from the user by CSS (display:none, visibility:hidden, opacity:0, off-viewport position). This link remains in the DOM, so Google can crawl and count it for internal PageRank.

An absent link is a link that does not exist at all in mobile HTML: it may be loaded only on desktop through a different server template, it may be injected by JavaScript only under certain conditions, or it may be part of a menu that only displays on wide screens and whose code is not even sent to mobile.

The distinction is critical: if you hide a link with CSS on mobile but it remains in the HTML, Google sees and counts it. If you completely remove it from the mobile HTML, Google no longer sees it.

Why does this distinction impact crawling and PageRank?

The crawl budget and PageRank distribution directly depend on the link structure that Google detects. If strategic links (to deep categories, important landing pages, priority content) are not present in mobile HTML, Googlebot will not discover them through that path.

In practical terms, this can mean that important pages become orphaned or poorly crawled because the links leading to them from the menu or footer no longer exist in the mobile version. Internal PageRank no longer flows in the same way, and pages that were ranking well may lose weight.

This is especially true for sites that have adopted a simplified mobile design by removing links considered non-priority for mobile UX, without thinking about SEO consequences.

How does Google handle JavaScript-loaded links on mobile?

Mueller does not detail this point in his statement, but we know that Googlebot executes JavaScript. If a link is injected into the DOM by JS after the initial load, theoretically Google can see it… but with a delay, and not always reliably.

The problem is that if the link is conditionally loaded (for example, only on button click, or after infinite scroll), Google may miss it. It’s better for critical links to be present from the initial HTML, even if they are hidden by default.

• Links present in mobile HTML but hidden by CSS are counted by Google.
• Links absent from mobile HTML (only on desktop) are ignored in mobile-first.
• Links injected by JS may be seen, but with risks of delay or being missed.
• The mobile link structure now determines the crawl and PageRank of the entire site.
• A simplified mobile menu can create orphan pages if strategic links disappear from the DOM.

Does this statement align with field observations?

Yes, and it’s even a welcome confirmation. Since the rollout of mobile-first indexing, sites that have radically simplified their internal linking on mobile have seen some pages lose traffic or crawl. The causal link was not always obvious, but Mueller's statement makes it explicit.

On the other hand, the clarification about links hidden by CSS is reassuring. Many SEOs thought that Google penalized or ignored links with display:none, which is not the case. Google counts them, period. The real issue is the complete absence of the link in mobile HTML.

What is missing from this statement: not any indication of the relative weight of these hidden links. Does Google count them with the same weight as a visible link? Is there a threshold of tolerance (for example, if 80% of your links are hidden, it becomes suspicious)? [To be verified]

What nuances should be added?

First nuance: Mueller talks about "hidden links on mobile", but he does not differentiate the various hiding techniques. A link set to display:none doesn’t have the same history as a link with position:absolute; left:-9999px (a method historically associated with spam). Google could theoretically make a distinction, even though nothing indicates that it does today.

Second nuance: the issue of semantic context. If you hide a link in a burger menu that appears on click, it’s a standard and legitimate practice. If you hide hundreds of links in the footer solely for crawling purposes, without any UX utility, it looks like over-optimization. Google does not clearly specify where it draws the line.

Third nuance: Mueller doesn’t mention links in iframes, nor links in content loaded via AJAX after user interaction. These borderline cases remain unclear. [To be validated] in specific tests.

In what cases does this rule not apply?

If your site has an identical desktop and mobile rendering (pure responsive with no content differentiation), this statement changes nothing for you: all links are present in the same HTML, so Google sees them.

Another exception: sites using dynamic serving (different server code based on user-agent) but that have been careful to maintain the same link structure on mobile and desktop. If your internal linking is consistent between both versions, there’s no problem.

Finally, AMP sites: AMP has its own validation rules that prohibit certain types of hidden links. If you adhere to the AMP standard, you should normally be safe from this issue, but watch out for links in non-AMP components that may disappear.

How to ensure that strategic links are present in mobile HTML?

First reflex: use the Google Mobile-Friendly Test and look at the rendered source code. Compare it with the desktop code. Check that priority links (main menu, categories, pagination, contextual internal links) are present in both versions.

Second tool: the Coverage report in Search Console can alert you to pages that have become orphaned or less crawled. If you see a drop in crawl on certain sections after transitioning to mobile-first, it's likely a missing links issue.

Third technique: perform a crawl with Screaming Frog in mobile mode (smartphone user-agent). Compare the number of discovered links with a desktop crawl. If you find significant discrepancies, dig into it page by page to identify missing links.

What mistakes should be avoided priority?

Classic error: removing the entire menu on mobile and replacing it with a simple "Return" button or an icon without an underlying HTML link. If your burger menu does not contain links in HTML (even if hidden), Google does not see them.

Another trap: rich link footers on desktop that completely disappear on mobile to lighten the page. If these links served to distribute PageRank to deep pages, their removal creates gaps in the linking.

A third error: using poorly configured lazy loading for menus or link blocks. If lazy loading is triggered only on scroll or interaction, and the initial HTML contains nothing, Google is likely to miss these links.

What concrete actions should be taken to ensure optimal internal linking?

Start with a mobile-desktop parity audit: identify all links present on desktop but absent on mobile. For each missing link, ask yourself: does it have SEO value (crawl, PageRank) or just desktop UX?

If the link has SEO value, integrate it into mobile HTML, even if it is hidden by CSS. For example, you can include a full footer menu on mobile but hide it by default with a "See more" button that reveals the links on click. The important thing is that the HTML contains the links from the initial load.

Then, check that your burger menu or mobile menu really contains all critical links in the DOM, not just injected by JavaScript after interaction. Use a native HTML menu with display:none by default, revealed on click by a simple CSS or JS toggle.

• Audit link parity between mobile and desktop versions with a comparative crawl
• Ensure that strategic links (menu, categories, pagination) are in the initial mobile HTML
• Test the mobile rendering with the Mobile-Friendly Test and inspect the source code
• Avoid completely removing link blocks on mobile: hide them with CSS if needed
• Monitor the coverage report and crawl budget in Search Console after any mobile changes
• Document mobile linking choices to ensure consistency during future site updates