Is it true that Googlebot really ignores all content loaded after user interaction?

Does Googlebot behave like a real user?

No, and this is a crucial distinction. Unlike a human browser, Googlebot clicks on nothing, does not scroll, and does not send any geolocation data. It accesses a URL, waits for the JavaScript to execute to generate the initially rendered HTML, and then considers the job complete.

This behavior has massive implications for modern architectures that load content on demand. Interactive tabs, accordions that reveal their content on click, infinite scrolls, modals — anything requiring user interaction remains invisible. Google only sees what appears in the DOM after the first rendering pass.

Why does this technical limitation exist?

Google must crawl billions of pages daily with a limited crawl budget. Simulating clicks and scrolls would exponentially increase the time and resources required. Rather than guessing which interactions are relevant, Google has made a pragmatic choice: to index only the content that is frictionlessly accessible.

This approach also reflects a philosophy of accessibility. If content requires a user action to be visible, it may pose problems for screen readers and other assistive technologies. Therefore, Google prioritizes content that is immediately available.

What exactly is the “initially rendered HTML”?

The initially rendered HTML is the state of the DOM after the JavaScript has run for the first time but before any user interaction. Google loads the page, waits a few seconds for the scripts to execute (generally a maximum of 5 seconds, although this delay is not officially documented), and then captures what is visible.

Any content dynamically added during this initial phase will be indexed. On the other hand, anything requiring an onclick, onscroll, or onchange event will remain out of reach. The distinction is binary: either the content appears without action, or it does not exist for Google.

• Googlebot simulates no interactions: no clicks, scrolls, hovers, or keyboard input.
• Only the initially rendered HTML counts for indexing, which excludes post-interaction conditional content.
• Geolocation data is not provided, so dynamically geolocated content may not be crawled.
• Lazy-load on scroll does not work for Googlebot — prioritize the native loading="lazy" attribute which still loads the content in the DOM.
• Modern SPA architectures must ensure critical content appears on first render without waiting for user events.

Does this statement match real-world observations?

Yes, and in a brutally consistent manner. Tests consistently show that Google does not index content hidden behind interactive tabs or accordions that require a click. Across thousands of audits, the pattern is the same: if content does not appear in the “View Rendered Source” of the Search Console, it is not indexed.

However, one nuance deserves attention: some content loaded in lazy-load via Intersection Observer is sometimes indexed, probably because Google simulates a sufficiently large viewport that triggers loading without scrolling. But this behavior is not guaranteed and not documented — relying on it is a gamble. [To verify] if Google adjusts the size of its viewport based on the simulated device.

What are the gray areas of this statement?

The definition of “initially rendered HTML” remains intentionally vague. Google does not communicate the exact timeout before capturing the DOM. Observations suggest about 5 seconds, but on slow servers or with blocking scripts, this timeout may be insufficient. As a result, technically accessible content that loads too slowly disappears from the index.

Another gray area is geolocation. Google claims that Googlebot does not provide GPS coordinates, but what about sites that display different content based on the crawl IP? Do US Googlebots see the same content as EU Googlebots? The documentation remains vague on this point. [To verify] via tests with geo-differentiated content by IP.

Should current UX practices be reconsidered?

Let's be honest: the conflict between modern UX and indexability is front and center. Accordions allow for condensing information without visually overloading the page — great for the user, disastrous for SEO if the content remains hidden. Infinite scrolls improve engagement but fragment indexing across dozens of paginated pages.

The solution is not to abandon these patterns but to implement them intelligently. An accordion can be open by default on the server side and close via JavaScript on the client side. An infinite scroll can load the next contents into the DOM immediately, then visually hide them until scrolling. The principle: ensure that the content exists in the rendered HTML without interaction, then adjust the display afterward.

How to audit your site to identify invisible content?

The first step: use the URL Inspection Tool in the Search Console and compare the “raw HTML” to the “rendered HTML”. Any element present only in the raw HTML but absent from the rendered HTML indicates a JavaScript execution problem. Conversely, any content that appears neither in one nor the other but exists visually after a click signals content post-interaction invisible to Google.

Next, simulate a crawl with Screaming Frog in JavaScript mode. Set a rendering timeout of 5 seconds maximum to replicate Googlebot's conditions. Extract the visible text and compare it to the actual content of your pages: discrepancies reveal blind spots. For geolocated content, test from multiple IPs or use VPNs to verify crawl consistency.

What technical modifications should be prioritized?

For accordions and tabs, switch to an HTML-first implementation: the complete content is present in the initial markup with `hidden` attributes or CSS classes to hide it. JavaScript merely adds/removes these classes on click. Googlebot sees everything, and users enjoy a condensed interface.

For lazy-load, abandon scripts that load on scroll. Use the native `loading="lazy"` attribute on images and iframes — the browser manages deferred loading, but the content remains in the DOM. For text blocks, load them immediately in the HTML but apply `opacity: 0` or `visibility: hidden` until scrolling, then reveal them progressively. Google indexes, and the user does not suffer from the initial visual weight.

What to do for geolocated content?

If your site displays different content based on location, implement a universal fallback system. When no geolocation is detected (the case for Googlebot), display a neutral version or a default representative content. Avoid blank pages or redirects to a region selection page — Google may index nothing.

For international e-commerce stores, use proper hreflang tags and ensure that each language/regional version is accessible via a distinct URL. Do not rely on automatic IP detection to serve the right content to Googlebot — each URL must be standalone and complete.

• Systematically compare raw HTML and rendered HTML via Search Console for each type of strategic page.
• Refactor accordions and tabs so that the content is present in the initial DOM, hidden via CSS rather than loaded by JavaScript.
• Replace lazy-load on scroll with the native `loading="lazy"` attribute or immediate visually hidden loading.
• Implement a neutral fallback for geolocated content, accessible without IP or GPS coordinate detection.
• Crawl your site with Screaming Frog in JavaScript mode and short timeout to replicate Googlebot's conditions.
• Check that product descriptions, technical specifications, and customer reviews are not hidden in non-crawlable tabs.