Viewport is configured for mobile

A missing or broken viewport tag means mobile visitors may never trigger scroll or click events correctly. Mobile is roughly half of global traffic (StatCounter, September 2026) — enough that mis-fired events are not a rounding error.

Why this matters

How this tool detects it

The tool checks whether a viewport meta tag exists, and if so reads the width value inside it. Anything other than device-width is treated as a failure — a fixed pixel width such as width=980 forces mobile browsers to render a desktop-width page and scale it down, which leaves click and scroll event coordinates miscalculated and many interactive elements unreliable.

The correct configuration is width=device-width, initial-scale=1, which lets the user zoom as they normally would.

Where this check can mislead you

Static analysis has limits. These are the cases where this particular check will report a result that does not match reality — worth knowing before you act on it.

The tag existing does not mean mobile works. The tool checks only the meta tag and cannot verify the layout really adapts or that interactive elements are tappable.
CSS-level responsive problems are not detected. Missing media queries, overflowing containers and similar issues are out of scope.
Accessibility impact cannot be judged. Blocking zoom does harm accessibility, but that is a human assessment.

Examples

WrongWrong: a fixed pixel width

<meta name="viewport" content="width=980">

The browser renders at 980px and then scales down. The coordinates used for click and scroll events are calculated wrong, so many interactive elements stop firing reliably.

CorrectCorrect: the standard configuration

<meta name="viewport" content="width=device-width, initial-scale=1">

Renders at the real device width. Mobile accounts for roughly half of global traffic (StatCounter, September 2026) and rather less in the US, so a wrong viewport still distorts a large part of your audience.

How to fix it

Put the viewport tag inside <head>, as the first thing in it.
Set it to width=device-width, initial-scale=1.
Do not add user-scalable=no or maximum-scale=1 — blocking zoom is an accessibility problem and fixes no tracking issue.
Open the page on a real phone and confirm the layout and interactions behave correctly.

Verify it worked

After making changes, confirm delivery rather than assuming. These steps require your Google login, which is exactly why this tool stops short of them.

Switch device emulation in Chrome DevTools and actually click through the buttons, dropdowns and forms.
Open the page once on a real phone, not just the emulator — emulation cannot reproduce real touch and zoom behaviour.
Browse in GTM Preview using a mobile device mode and confirm mobile-specific interactions such as swipes and taps fire normally.
Run Lighthouse and check the accessibility items for mobile.

Related checks

One thing static analysis cannot tell you: this page reads published code, so it shows what is installed, never what actually fires. To confirm delivery, use GTM Preview and GA4 DebugView — both require your Google login.

Check whether your site has this problem — no login required.