Direct answer

Lazy-load noncritical content when it approaches the viewport, not only after a click or scroll event. Keep important above-the-fold content eager, expose final resource URLs in rendered HTML, provide stable page URLs for distinct content, and test the rendered output with clean sessions and Google’s inspection tools.

What to remember
  • Google does not interact with a page like a user, so content that requires clicking or manual scrolling may remain undiscovered.
  • Native browser lazy loading or IntersectionObserver-based loading is generally safer than event handlers tied only to user actions.
  • Primary content and likely above-the-fold images should not be delayed merely to improve a synthetic performance score.
  • The final rendered HTML should contain usable image, video, iframe, link, and text references rather than loading shells with no final references.

01

Preconditions

Lazy loading defers noncritical content until it is likely to be needed. It can reduce initial transfer, browser work, and application load. It can also hide important content when the implementation assumes that every crawler clicks, scrolls, grants permission, preserves state, and waits indefinitely.

Before changing code, classify what is being deferred:

Decorative image
Primary article image
Product image
Embedded video
Advertisement
Comment thread
Review list
Related articles
Product cards
Map
Iframe
Entire article section

Then record how each item becomes available:

Present in initial HTML
Loaded by native lazy loading
Loaded by IntersectionObserver
Loaded after scroll event
Loaded after click
Loaded after consent
Loaded after API response
Loaded only with cookie or local storage

Google recommends loading relevant content when it becomes visible in the viewport and warns against relying on user actions such as scrolling or clicking. Google’s crawlers do not interact with controls as a person would. [1]

Establish a baseline with:

  • initial HTML
  • rendered HTML
  • network requests
  • final resource URLs
  • JavaScript errors
  • status codes
  • robots rules
  • mobile and desktop layouts
  • clean sessions without stored state

02

Ordered process

  1. Keep critical content eager.

Do not lazy-load content likely to be visible when the page opens. The primary heading, direct answer, core product information, and principal above-the-fold image should arrive without waiting for viewport calculations.

Lazy loading is a prioritization tool, not a ritual applied to every image because a library exposes one attribute. Delaying the largest visible image can make the page slower for users even if fewer bytes begin immediately.

  1. Prefer browser-native loading for ordinary media.

For suitable below-the-fold images and iframes, native lazy loading reduces custom JavaScript dependencies.

Conceptually:

image source + loading=lazy
iframe source + loading=lazy

The final implementation must still provide a real source URL. A temporary image element with the actual URL hidden in an undocumented custom attribute may not be processed until a script rewrites the element.

  1. Use viewport observation instead of interaction events.

When content requires custom behavior, use a viewport-aware mechanism such as IntersectionObserver and provide a fallback where necessary.

The important distinction is:

Good trigger: content approaches the viewport
Fragile trigger: user performs a particular gesture

A scroll handler can fail when the crawler does not simulate scrolling, when the container scrolls independently, or when an overlay prevents the event. A “Load images” button is even more explicit: the content does not exist until a user acts.

  1. Expose stable resource URLs.

After rendering, image and video elements should contain usable source references. Google’s lazy-loading guidance recommends checking that the final URLs appear in the rendered src attributes. [1]

Inspect:

img src
img srcset
picture source srcset
video src
video poster
iframe src
anchor href

Do not rely on CSS background images for every meaningful image. When the image carries content value, use semantic image markup with descriptive alternative text.

  1. Separate loading from visibility.

A page may download a resource successfully while keeping the content hidden through CSS, collapsed components, or failed state transitions. Inspect the rendered page, not merely the network panel.

Check for:

  • display: none
  • zero-height containers
  • transparent overlays
  • offscreen transforms
  • inaccessible accordions
  • skeleton loaders that never clear
  • duplicate loading shells
  • content inserted into a detached DOM node
  1. Handle API failure explicitly.

Deferred content often arrives from an API. Define what the page does when the request times out, returns an error, or returns an empty response.

A resilient page should not leave an eternal spinner. Depending on the content, it may:

  • show server-rendered fallback content
  • retry with bounded logic
  • display a meaningful error
  • preserve direct links to separate pages
  • return an accurate page-level status when the whole resource is missing

Do not convert every failed component into a page-level noindex. Decide whether the page remains useful without that component.

  1. Do not require durable browser state.

Google’s rendering system does not preserve cookies, local storage, or session storage as a durable sequence across page loads. [2]

If the review section appears only after a user previously accepted a setting on another page, a clean renderer may never receive it. Public content should be reachable from the current URL and response.

  1. Keep metadata independent of deferred widgets.

The canonical, robots directives, title, and primary structured data should not wait for a below-the-fold component unless those values genuinely depend on it.

If JavaScript injects markup after an API call, test that it appears in rendered HTML and remains synchronized with visible content. Fast-changing product data deserves special caution because stale markup can outlive the interface.

  1. Give distinct content stable URLs.

Lazy loading within one page is appropriate when later content belongs to that page. When the implementation loads distinct products, articles, reviews, or archive chunks, each meaningful chunk may need its own stable URL and crawlable pagination.

Do not attempt to make one endless page serve as the only identity for thousands of independent items.

  1. Test more than the happy path.

Run tests with:

  • JavaScript enabled
  • JavaScript failure
  • slow network
  • API timeout
  • no cookies
  • no local storage
  • mobile viewport
  • desktop viewport
  • reduced browser features
  • blocked nonessential resources
  • clean cache
  • repeated navigation

Use URL Inspection or the Rich Results Test to inspect rendered HTML. Search for exact content strings and final media URLs rather than trusting a green status alone.

03

Failure cases

Every image is lazy-loaded. The hero image and above-the-fold content appear late, harming users while producing no meaningful crawl benefit.

Content loads only after scrolling. Google does not perform the required interaction, so later sections never enter rendered HTML.

Real URLs live only in custom attributes. The page contains temporary elements using attributes such as data-src, but the rewrite script fails.

A button reveals the only crawl path. Product cards or articles exist only after “Load more” is clicked, with no anchor links or page URLs.

Consent blocks all content. The page requires a permission or tracking decision before public editorial content appears.

Skeletons are indexable output. A failed API leaves “Loading…” as the main rendered content under a 200 response.

Client state is mandatory. A clean session has no stored preference and therefore receives no content.

Lazy loading hides internal links. Related pages and pagination destinations are inserted only after interaction, reducing discovery.

Media is accessible but the page is blocked. Googlebot-Image can request the file, but the page containing its context cannot be crawled.

04

Completion criteria

The implementation is complete when all critical above-the-fold content loads eagerly, deferred content becomes available through viewport-based logic without clicks, final resource URLs appear in rendered HTML, and public content does not depend on prior browser state.

Representative templates should pass rendered-output checks on mobile and desktop. API failures should produce bounded, understandable behavior. Important internal links should remain crawlable. Distinct content chunks should have stable URLs rather than existing only inside one interaction stream.

Production monitoring should track JavaScript errors, failed resource requests, empty content containers, and unexpectedly low rendered-content counts after releases.

Continue with Infinite Scroll SEO when deferred items form a collection, JavaScript SEO Rendering for complete render diagnosis, and JavaScript Structured Data when markup is injected after loading.

References

Sources behind this record

  1. Fix lazy-loaded content — Google Search Central (accessed August 2, 2026)
  2. Fix Search-related JavaScript problems — Google Search Central (accessed August 2, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.

Claim limit

Search-friendly lazy loading improves content availability but does not guarantee image indexing, rich results, rankings, or successful rendering when underlying resources are blocked, slow, or invalid.