I was recently setting up AdSense on a client's site and kept getting flagged for "Google-served ads on screens without publisher-content." The site was extremely text-heavy, minimal images, solid content everywhere. There was no way the pages were actually empty. The only explanation that made sense was that Google's crawler wasn't seeing some of the content because of lazy loading. The site used a modern React-based framework with aggressive code splitting and deferred rendering for below-fold sections, and it clicked that the very optimizations we rely on for performance were actively working against discoverability.

It sent me down a rabbit hole I think a lot of developers and publishers are navigating right now, and the answers aren't as clean as you'd hope.

Lazy Loading Has Always Been an SEO Problem

Here's the thing. Lazy loading content has always been a bad thing for SEO. This isn't new. The entire reason server-side rendering became a thing again was because of this exact tension.

Think about the irony for a second. One of the core selling points of modern frameworks like Next.js, Nuxt, Remix, and even plain React with Suspense is the ability to only send content to the client when it's needed. Dynamic imports. Code splitting. Route-based chunking. Streaming. The whole philosophy is: don't load what the user hasn't asked for yet. That's essentially lazy loading at an architectural level.

But then Google shows up with a crawler that doesn't scroll, doesn't click, and has a limited rendering window to execute your JavaScript. Suddenly all that smart client-side optimization means your content might as well not exist.

That's why SSR made its comeback. Not because developers wanted to go back to server-rendered pages for fun, but because search engines needed to see fully-formed HTML on the first pass. Frameworks like Next.js basically exist in the gap between "we want modern client-side interactivity" and "we need Google to actually index our stuff." The getServerSideProps and server component patterns aren't performance features. They're SEO features dressed up in performance clothing.

So when people say lazy loading is bad for SEO, what they really mean is: anything that hides content from the initial render is a risk. Whether that's loading="lazy" on an image, an Intersection Observer firing on scroll, or an entire page section that only hydrates on the client.

What Google Actually Says (And What They Don't)

Google's own documentation on lazy loading is surprisingly reasonable. They acknowledge it's a performance best practice. Their guidance boils down to: make sure lazy-loaded content is visible in the viewport without requiring user interaction like scrolling or clicking.

Why? Because Googlebot doesn't scroll. It renders the page in a simulated viewport, waits a short window for JavaScript to execute, and whatever it sees at that point is what gets indexed. If your lazy loading relies on scroll events to trigger, that content is invisible to Google.

In August 2025, Martin Splitt and John Mueller addressed this directly on the Search Off the Record podcast. Splitt confirmed that the ranking impact of lazy loading is small in most cases, calling Core Web Vitals a relatively minor factor. But he also flagged a much bigger issue: custom lazy loading libraries that swap src attributes for data-src or similar custom attributes can cause real indexing failures. If Google can't find a standard src attribute on an image tag, that image doesn't exist as far as the crawler is concerned.

The safe path is using the native browser loading="lazy" attribute. It's supported in all modern browsers, WordPress applies it by default, and Google's crawler handles it correctly. The problems show up when you're using third-party libraries or custom JavaScript that gets too clever with attribute manipulation.

The AdSense Dilemma

Google is penalizing you for slow pages while simultaneously being the reason your pages are slow.

That's the core contradiction. Core Web Vitals are a ranking signal, and AdSense scripts are one of the single biggest contributors to poor page performance. They cause layout shift (CLS), they bloat load times, they block the main thread. Run your site through PageSpeed Insights and chances are AdSense is responsible for most of the red flags. Google's own ad product is tanking the metrics that Google's own search algorithm uses to rank you.

And if you try to fix it by lazy loading those ad units, the ones below the fold might never load when a user doesn't scroll that far. That means fewer impressions, fewer clicks, and lower revenue. Your Active View Viewable metric drops, which affects how much advertisers are willing to bid on your inventory.

Speed up your site by deferring ads and you lose money. Load all ads eagerly and your performance tanks, which hurts rankings, which means less traffic, which also means less money. Pick your poison.

Google's Ad Manager documentation actually recommends lazy loading for ads and says it can improve viewability when done right. But they specifically recommend using Google Publisher Tags for the implementation, because other approaches can trigger ad requests that never actually render a creative, which makes your metrics even worse.

For AdSense specifically (as opposed to Ad Manager), there's no official lazy loading support. Publishers are essentially hacking around it with Intersection Observer scripts, deferred loading, and various WordPress plugins. Some report significant PageSpeed improvements. Others report revenue drops of 20-30% because impressions tanked.

Where the Actual Tradeoff Lives

After digging through all of this, the decision framework comes down to a few concrete factors.

Never lazy load above the fold. This is the one absolute rule. Your hero image, your H1, your first ad unit, your primary CTA, all of it should load immediately. Lazy loading above-fold content delays your Largest Contentful Paint because it overrides the browser's resource scanner, which normally prioritizes images as soon as it finds them in the HTML. You're actively making the page slower for the content users see first.

Always lazy load below-fold images and video. This is the whole point of the technique. If a user has to scroll three screens to reach an image, there's no reason to load it on page init. You're burning bandwidth and blocking the main thread for content nobody's looking at yet. For content-heavy pages with 10+ images, this is basically mandatory.

For ad units, lazy load below-fold only and accept the revenue tradeoff. If you have a long article with ad units scattered throughout, the ones near the bottom are less likely to get viewed anyway. Lazy loading them means you lose some phantom impressions that weren't generating real engagement. Your viewability percentage actually goes up, which can improve CPMs on the impressions that do count. But your total impression volume goes down.

Use native loading="lazy" over custom libraries. The native attribute is understood by Google's crawler and doesn't introduce the data-src indexing problems that custom JavaScript libraries create. Unless you need something specific like low-resolution preview swapping, native is the way to go.

If you're going through AdSense approval, be conservative. This is the lesson from my client's rejection. During the approval process, Google is crawling your site and evaluating whether it can effectively serve and track ads. If significant portions of your content are deferred or lazy loaded in ways the crawler can't process, the site looks thin even if it isn't. For approval, consider temporarily loading everything eagerly, or at minimum make sure all text content is server-rendered and only images/video are lazy loaded.

The SSR Middle Ground

So what do you actually do if you need both performance and full crawlability? You stop thinking about it as an either/or and lean into the hybrid approach that modern frameworks already support. This is where the tooling has gotten good enough that you don't have to choose.

Server-render all text content, metadata, and internal links. This is non-negotiable for SEO. Google needs to see your content in the initial HTML response. Apply loading="lazy" to below-fold images and iframes. This is the low-risk optimization that gives you the performance win without the indexing risk. Load ad scripts after the critical rendering path. Use requestIdleCallback or a short setTimeout to defer ad initialization without fully lazy loading the units. This reduces the impact on LCP and Total Blocking Time while still getting your ads rendered before Google's crawler times out. Use SSR or SSG for any page you want indexed. If you're building with React, Next.js server components are your friend here. If you're on a static site generator, you're already in good shape. The pages Google sees should be complete HTML documents, not empty shells waiting for JavaScript to populate them.

The Bottom Line

Lazy loading isn't bad. Bad lazy loading is bad. The technique itself is one of the most effective performance optimizations available, and Google's own engineers recommend it. The problems come from applying it too aggressively, using implementations that break indexing, or not understanding that a search crawler experiences your site very differently than a human user does.

If you're trying to monetize with AdSense, the tension is real but manageable. Load your first ad unit eagerly, lazy load the rest, and monitor your viewability metrics to find the balance point. If you're going through the approval process, err on the side of making everything visible to the crawler and optimize after you're approved.

That client site I mentioned at the top? Once we server-rendered the text-heavy content sections and limited lazy loading to just images and below-fold media, the "screens without publisher-content" error went away. The pages hadn't changed. The content was identical. Google just couldn't see it before.

That's the whole story with lazy loading in one example. The best performing site in the world doesn't matter if Google can't see what's on it.

References