How to Reduce Excessive Iframes on Your Site
This notice fires when your audit counts more than 10 iframes across the pages it crawled, typically maps, videos, ads, or third-party widgets. Each iframe loads a separate document with its own bandwidth and main-thread cost, and content rendered inside one is generally invisible to AI crawlers reading your raw HTML. The fix is lazy-loading, click-to-load facades, and cutting embeds that aren't earning their keep.
What this means
An <iframe> embeds an entire separate HTML document inside your page: a Google Map, a YouTube video, a chat widget, an ad unit, a review carousel, a booking form. This audit's excessive_iframes check counts every iframe found across all the pages it crawled and flags the site once that total passes 10. It's a notice, the lowest severity level, and it's a site-wide count rather than a per-page one, so this can fire even if no single page looks obviously overloaded; it's the cumulative total across your crawled pages that trips it.
Each iframe is not a lightweight embed. The browser has to fetch and parse an entire additional document, often with its own scripts, stylesheets, and network requests, layered on top of your page's own load. A handful of iframes is normal and fine; a page or a site stacking many of them is asking the browser to do many pages' worth of work to render one.
There's a specific angle for AI crawlers and answer engines worth knowing. Most crawlers, including the bots behind AI answer engines, read your page's raw HTML and generally don't execute the JavaScript needed to load and render iframe contents, and even when they do fetch the iframe's own document separately, they typically don't treat that content as part of your page. Anything meaningful you've placed inside an iframe, an FAQ widget, review content, key information, is effectively invisible to whatever's reading your HTML to decide what your page is about.
To be fair to iframes: they exist for good reasons, and a map embed or an embedded video isn't a mistake. This flag is about excess, not about iframes being inherently bad. A page with two or three purposeful embeds is normal. A site with dozens accumulated across templates, often from widgets nobody remembers adding, is the pattern this notice is catching.
Why it matters
For performance, each iframe adds real, measurable weight: its own DOM, its own render tree, and often its own JavaScript execution, all inside a browser tab that's also trying to render your actual content. That work competes for the main thread, which can delay Largest Contentful Paint if an iframe loads early and blocks rendering, and can hurt Interaction to Next Paint if an iframe's scripts, a chat widget, an ad script, a comment embed, run long tasks that make your page slower to respond to clicks and taps.
For SEO, content inside an iframe is generally not counted as part of your page's own content for indexing purposes; search engines treat it as a reference to a separate document, not text on your page. If you've put meaningful copy, an FAQ section, or product information inside an iframe expecting it to help your page rank, it largely isn't contributing the way body text would.
For AI visibility, the same separation applies and matters more, not less. When ChatGPT, Perplexity, or Google's AI Overviews summarize a page, they're working from the HTML and text they can extract directly. Content sealed inside an iframe is opaque to that process in the same way it's opaque to a classic search crawler, so an iframe is a reasonable place for a genuinely third-party widget, a map, a video, a review platform's carousel, but a poor place for anything you want an AI answer engine to read, cite, or quote.
Being fair to the other side: not every iframe is worth removing, and this check doesn't distinguish a load-bearing embed from a forgotten one. Two iframes doing real work, a map on a contact page, an embedded product video, cost you almost nothing and shouldn't be ripped out just to satisfy a notice. The fix here is about the pattern of excess and the ones that load eagerly for no reason, not a mandate to hit zero.
How to fix it
- 1
Audit what's actually embedded and why
List every iframe across your site and what it's for: maps, videos, ad units, chat widgets, review platforms, booking calendars, social embeds. It's common to find duplicates (the same map embedded on every location page when one linked page would do), abandoned widgets nobody uses anymore, or third-party scripts a past redesign left behind. Removing the embeds that aren't earning their keep is the cheapest fix available and needs no code changes beyond deleting a snippet.
- 2
Lazy-load the iframes you keep
Add
loading="lazy"to iframe tags that sit below the fold; modern browsers then defer fetching that iframe's document until it's about to scroll into view, instead of loading it immediately with the rest of the page. This is a one-attribute change with no functional downside for embeds users have to scroll to reach, like a map near the footer or a video partway down a long article. - 3
Use a click-to-load facade for video and maps
For heavy embeds like YouTube videos or Google Maps, load a lightweight placeholder, a static thumbnail image styled to look like the player, with a play button overlay, and only load the real iframe after the visitor clicks it. This defers the entire cost, the network requests, the third-party scripts, the render work, until there's actual user intent to view it. Libraries like lite-youtube-embed implement this pattern for video specifically, and the same idea works hand-rolled for maps and other heavy widgets.
- 4
Consolidate or link out instead of embedding
For content that doesn't need to be interactive on your page, a static image, a screenshot, or a plain link often serves the same purpose as an iframe at a fraction of the cost. A map can be a static image linking to Google Maps; a single social post can be a screenshot with a link; a review badge can be a summary line with a link to the review platform. Reserve real iframes for embeds where the interactivity genuinely matters.
- 5
Re-run the audit and check Core Web Vitals
After trimming and lazy-loading, re-crawl your site to confirm the count drops below the threshold. Also check PageSpeed Insights or your browser's Performance panel on a page that used to have several iframes; you should see fewer early network requests and less main-thread work before first paint. If a heavy iframe is still loading eagerly, confirm the loading="lazy" attribute survived any CMS or page-builder re-save, since some builders strip custom attributes on embeds.
Example
<!-- Before: eager-loaded map iframe, loads immediately on page load -->
<iframe src="https://www.google.com/maps/embed?..." width="600" height="450"></iframe>
<!-- After: lazy-loaded, defers until near the viewport -->
<iframe src="https://www.google.com/maps/embed?..."
width="600" height="450"
loading="lazy"
title="Store location map"></iframe>
<!-- Better for heavy embeds: click-to-load facade -->
<div class="map-facade" onclick="this.replaceWith(loadRealMapIframe())">
<img src="/map-thumbnail.jpg" alt="Map preview, click to load interactive map">
</div>Adding loading="lazy" is a one-line fix; a click-to-load facade removes the cost entirely until a visitor asks for it.
Platform-specific steps
Check widgets and blocks added via the Custom HTML block, older shortcodes from plugins (review widgets, booking calendars, chat plugins), and theme-bundled sections that embed Google Maps by default. Many form and calendar plugins default to an iframe-based embed; check plugin settings for a lazy-load or 'load on interaction' option before hand-rolling a facade.
Third-party apps (reviews, live chat, upsells, size guides) frequently inject an iframe into every product or theme page regardless of whether that page needs it. Audit installed apps under Settings > Apps, disable ones you're not using, and check whether the apps you keep offer a lazy-load or defer setting in their own configuration.
Embed blocks (HTML embed, video embed, custom code) are the usual source on these platforms. Both site editors let you delete an embed block directly from the page; for video, prefer the platform's native video block over a raw iframe embed where possible, since native blocks are more likely to lazy-load by default.
Frequently asked
This audit flags a site once the total count across all crawled pages passes 10. That's a practical threshold, not a hard technical limit; a single page with 3-4 purposeful embeds is generally fine, while a site that's accumulated dozens across templates, often from forgotten widgets, is the pattern worth cleaning up.
No. Maps, videos, and genuinely interactive third-party tools are legitimate uses of an iframe, and removing functional embeds just to chase a lower count would make your site worse. Focus on lazy-loading what you keep, removing duplicates and abandoned widgets, and using click-to-load facades for the heaviest embeds like video.
They can, depending on how they're loaded. An iframe that loads eagerly above the fold, especially one running its own JavaScript (ads, chat widgets, comment systems), adds main-thread work that can delay Largest Contentful Paint and Interaction to Next Paint. An iframe that's lazy-loaded and sits below the fold has much less impact, since the browser defers it until the visitor scrolls near it.
Generally, no. Crawlers that extract your page's text, including the bots behind AI answer engines, work from your page's own HTML and typically don't treat an iframe's separate document as part of your content. If you want an AI answer engine to be able to cite or quote something, put it in your page's own HTML rather than inside an embedded iframe.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.