Content Exceeds Viewport

Element Code: HT-023

What this issue actually is

The viewport is the visible area of the browser window. On a phone that is typically 360 to 430 CSS pixels wide. "Content exceeds viewport" means at least one element on the page renders wider than that, so the browser grows the horizontal scroll area and users have to pan sideways to read or, worse, the layout just looks broken with text running off the edge.

This is a layout defect, not a content problem. The page has a responsive design that mostly works, and then one element ignores it: a 1200px product comparison table, an infographic exported at fixed width, an iframe embed with hardcoded dimensions, or a CSS rule someone wrote at a desk on a 27 inch monitor. The rest of the page squeezes down politely and this one element blows out the layout for everyone on a phone.

Lighthouse tests for this directly with its "content is sized correctly for the viewport" audit, which compares the width of the rendered content against the viewport size. If window.innerWidth and the document's scrollWidth disagree, you fail.

Why it matters for SEO

Google has indexed the mobile rendering of your pages since mobile-first indexing rolled out to effectively all sites (Google completed the transition in 2023). Googlebot smartphone renders your page at a mobile viewport, so an overflow problem exists in the exact rendering Google evaluates. Mobile usability sits inside the broader page experience picture, and while nobody can show you a dial that says "horizontal scroll costs X positions," the second-order effects are real: users bounce off pages they have to pan sideways to read, and engagement signals on a page like that are ugly.

Worth knowing: Google retired the standalone Mobile-Friendly Test tool and the Mobile Usability report in Search Console in late 2023. Plenty of older articles still tell you to check those. They are gone. Lighthouse and Chrome DevTools are the replacements, and honestly they were always better because they show you the offending element instead of just waving a flag.

There is also a pure rendering-budget argument. A page that lays out cleanly at mobile width is a page where Google's renderer, your CSS, and your users all agree on what the page looks like. Every divergence between what you built and what renders is a place for bugs to hide.

What overflow looks like

How to find the offending element

The fastest diagnostic is a two-line console check. Open the page on a mobile viewport in Chrome DevTools (device toolbar, pick any phone preset) and run:

document.documentElement.scrollWidth > window.innerWidth
// true means something overflows. Then hunt it:
[...document.querySelectorAll('*')].filter(el => el.scrollWidth > document.documentElement.clientWidth)

That second line lists every element wider than the viewport. The outermost one in the list is usually your culprit; everything inside it is collateral.

For coverage at scale:

• Lighthouse: run it mobile, check the "content is sized correctly for the viewport" audit under SEO or Best Practices depending on version.
• Screaming Frog with Lighthouse integration: connect the PageSpeed Insights API under Config, crawl the site, and filter for viewport failures. This is how you find out the problem lives in one template rather than one page.
• Real devices: emulators miss scrollbar-width quirks. A quick pass on an actual phone, or BrowserStack if you need specific models, catches the 100vw class of bugs that only appear when a scrollbar consumes width.

The usual suspects and their fixes

One thing I want to flag because I see the lazy version constantly: slapping overflow-x:hidden on the body. Yes, it kills the scrollbar and the audit passes. It also means the overflowing element is now clipped, with whatever content lived in that zone amputated for mobile users. Fix the element, not the symptom. Hidden overflow on the body is the CSS equivalent of putting tape over the check engine light.

Also confirm the basics before touching CSS: the page needs <meta name="viewport" content="width=device-width, initial-scale=1"> in the head. Without it, mobile browsers render the page at a fake desktop width and zoom out, which produces a related but different failure.

What good looks like

At any viewport from 320px up, the document's scrollWidth equals the window's innerWidth. No element in the DOM is wider than the screen. Tables and code blocks that are legitimately wide scroll inside their own container while the page itself stays put. Text wraps, images scale, and nothing requires sideways panning to read. Run the console check above on your key templates at 360px and 320px; when both return false, ship it.

FAQ