Official statement
Other statements from this video 32 ▾
- 1:07 How does Google actually determine which pages to crawl first on your site?
- 2:07 Are category pages really crawled more by Google?
- 5:21 Should you really optimize product page titles for Google or for users?
- 5:22 Can multiple pages really share the same H1 without risking SEO?
- 6:54 Are mouseover links truly crawlable by Google?
- 10:53 Should you block JavaScript scripts in your robots.txt?
- 13:07 How can you make the most of Search Console to optimize your mobile SEO strategy?
- 16:01 Should you really make your JavaScript files accessible to Googlebot?
- 18:06 Should you really keep your Disavow file even with dead domains?
- 21:00 Can Google Really Handle JavaScript Indexing Effectively?
- 21:45 How can you isolate SEO traffic from a subdomain or mobile version in Search Console?
- 23:24 How many articles should you display per category page for optimal SEO?
- 23:32 Does the canonical tag really transfer as much signal as a 301 redirect?
- 29:00 Is duplicate content really a top SEO concern we should address?
- 29:12 Does the Disavow file really nullify all disavowed backlinks?
- 29:32 Do canonical tags really transmit SEO signals like a 301 redirect?
- 30:26 Should you really clean your Disavow file of dead and redirected URLs?
- 33:21 Is JavaScript really a challenge for Google’s crawling?
- 36:20 Should you really set noindex on sparsely populated category pages?
- 40:50 Is it really necessary to switch your site to HTTPS for SEO?
- 41:30 Does HTTPS really enhance your SEO, or is it just a Google myth?
- 45:25 Does Google really remove misleading pages or does it simply downgrade them?
- 46:12 Should you really avoid using canonical tags on paginated pages?
- 47:32 How can you speed up the deindexing of orphan pages that drag down your Google index?
- 48:06 Does duplicate content really affect your site's crawl budget?
- 53:30 Do Google spam reports really trigger actions?
- 57:26 Does descriptive content on category pages really solve the indexing issue?
- 59:12 Do empty category pages really harm indexing?
- 63:20 Should you really rewrite all product descriptions to rank in e-commerce?
- 70:51 Can Google merge your international sites if the content is too similar?
- 77:06 Should you really avoid canonicals pointing to page 1 on paginated series?
- 80:32 Should you really rely on 404 errors to clean up Google’s index of orphaned URLs?
Google confirms that Googlebot follows internal links even if they only appear on hover, as long as they are present in the initial HTML. This clarification addresses a common doubt regarding dropdowns and mega menus built with CSS/JS. Ultimately, what's important is not immediate visibility but effective presence in the DOM at the time the page loads.
What you need to understand
What does "present in the initial HTML" really mean?
The distinction is crucial: Googlebot reads the HTML code returned by the server before any JavaScript is executed. If your internal links already exist in this raw HTML, even if hidden by CSS (display:none, opacity:0, transform, position:absolute off-screen), the bot can see and follow them.
Conversely, if your links are dynamically injected by JavaScript after the initial load (e.g., a click or hover event listener generating the link through DOM manipulation), Googlebot may not discover them immediately. You then have to rely on JavaScript rendering, which occurs later and is not guaranteed for all URLs.
Why is there a distinction between CSS and JavaScript?
Google clearly differentiates between structural accessibility (is the link in the HTML?) and visual accessibility (is the link displayed?). A link hidden by CSS remains technically crawlable because it exists in the DOM. A link added in JS afterward requires an additional rendering step that Googlebot does not consistently perform on all pages.
This approach is explained by the resource cost of JavaScript rendering: Google cannot execute JS across the entire web in real-time. The initial crawl is based on raw HTML, with JS rendering occurring afterward in a separate queue.
In what scenarios does this statement actually apply?
The architectures concerned are primarily CSS-only dropdowns, mega menus that display on hover via :hover, or sidebars where sections unfold through CSS transitions. As long as the <a href> tags are present from the start, Googlebot will crawl them.
However, be cautious with modern frameworks (React, Vue, Angular) that generate all the DOM client-side: if your navigation does not exist in the HTML served by the server (which can be verified by disabling JavaScript in the browser), you are entirely reliant on Google’s JavaScript rendering. This is not optimal for crawl budget or quick discovery guarantee.
- Links in the initial HTML + hidden by CSS: normally crawled by Googlebot
- Links injected via JavaScript after loading: deferred crawl, not immediately guaranteed
- CSS-only dropdowns: no documented crawl problem
- SPAs without SSR/pre-rendering: total reliance on JavaScript rendering, risk of late discovery
- Simple check: View Source (Ctrl+U) vs Inspect Element to compare raw HTML and rendered DOM
SEO Expert opinion
Is this statement consistent with real-world observations?
Yes, it aligns with empirical tests conducted on high-traffic sites. Server logs show that Googlebot indeed follows links hidden in pure CSS, including those visible only on hover. Discovery delays are similar to links that are permanently visible.
However, [To be verified] the crawl speed of links generated in client-side JS: Google claims to discover them through JavaScript rendering, but real-world feedback indicates variable delays (from a few hours to several weeks depending on crawl budget). On niche sites with low authority, some JS-only links are never crawled. Mueller's statement, therefore, remains optimistic for sites with low crawl budgets.
What nuances should be added to this assertion?
Mueller does not specify the timing of JavaScript rendering or its prioritization. A link that is present only after JS execution may be discovered, but when? The JS rendering queue is opaque and not publicly documented. On massive sites (e-commerce, marketplaces), relying on JS rendering for critical URL discovery is a risky strategy.
Another point: the phrasing "present in the initial HTML code" remains vague. What about links loaded via an iframe or a shadow DOM? What about links in data- attributes retrieved by JS? Google does not provide technical details. When in doubt, the safe rule remains: direct link in the <body> of the HTML served by the server.
In what scenarios does this rule not apply fully?
Single-page applications (SPAs) without Server-Side Rendering or pre-rendering are edge cases. If your initial HTML contains only an empty <div id="app"></div>, all your links depend on JS rendering. Google indicates it will crawl them, but observations show slower and incomplete discovery compared to standard HTML.
Another exception: links in modals or overlays loaded via AJAX on click. If the loading trigger is a user event (clicking a non-link button), Googlebot will not simulate that click. The final link remains invisible to the bot even if it could technically be rendered in JS. This is a common blind spot on e-commerce sites with dynamic filters.
Practical impact and recommendations
What actionable steps should be taken to optimize the crawl of internal links?
Always prioritize traditional HTML links in the initial source code. If you use dropdown menus, implement them in pure CSS (transitions, :hover) instead of JavaScript. This ensures that all navigation links are crawlable from the first pass by Googlebot, without relying on JS rendering.
For sites under modern frameworks (Next.js, Nuxt, SvelteKit), always enable Server-Side Rendering (SSR) or Static Site Generation (SSG) for strategic pages. This injects your links into the initial HTML. If SSR is too costly, targeted pre-rendering of pages with high SEO potential (categories, landing pages) is an acceptable compromise.
What common mistakes should absolutely be avoided?
Never hide critical links using display:none or visibility:hidden permanently. Even if Google can technically follow them, this sends a negative signal: why hide content that is supposed to be important? Google may interpret this as an attempt to manipulate if the link is never visible to a real user.
Avoid links generated solely on-click via JavaScript event listeners (e.g., addEventListener('click', () => { location.href = '...' })). These pseudo-links are not <a> tags, and Googlebot does not follow them. Always use real <a href="..."> tags, even if you override the behavior with JS.
How can I check that my architecture complies with the recommendations?
Test by disabling JavaScript in Chrome (DevTools > Settings > Debugger > Disable JavaScript) and navigate your site. If your navigation links disappear, you have a problem: they are not in the initial HTML. Use Google's Mobile-Friendly Test (which shows the final rendering) and compare that with a raw View Source.
Analyze your server logs to identify the URLs that Googlebot visits. If some strategic pages never receive visits despite internal links, this is a symptom of non-crawlable links. Cross-reference with Google Search Console (Coverage > Detected - currently not indexed) to identify URLs discovered but never indexed.
- Check the raw HTML (Ctrl+U) to confirm the presence of links before any JavaScript
- Implement dropdown menus in pure CSS rather than dynamic JS
- Enable SSR or pre-rendering on strategic pages of SPAs
- Use actual
<a href>tags, never clickable divs with event listeners - Review Googlebot logs to verify the effective crawl of linked pages
- Test the site with JavaScript disabled to simulate the initial crawl
❓ Frequently Asked Questions
Googlebot suit-il les liens masqués par display:none en CSS ?
Les menus déroulants en pur CSS posent-ils un problème pour le crawl ?
Que se passe-t-il si mes liens sont générés uniquement en JavaScript côté client ?
Comment savoir si mes liens sont dans le HTML initial ou ajoutés en JS ?
Les Single Page Applications (SPAs) sont-elles pénalisées pour le crawl des liens internes ?
🎥 From the same video 32
Other SEO insights extracted from this same Google Search Central video · duration 54 min · published on 24/08/2017
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.