How to fix a missing viewport meta tag
Add <meta name="viewport" content="width=device-width, initial-scale=1"> to the <head> of every page. Without it, mobile browsers assume a ~980px desktop layout and scale the whole page down, making text unreadable and failing Google's mobile-friendly requirements.
Last updated 2026-07-28
What does the viewport meta tag do?
It tells a mobile browser to lay the page out at the device's actual width rather than at a pretend desktop width. width=device-width sets the layout viewport to match the screen, and initial-scale=1 sets the starting zoom so one CSS pixel maps to one device-independent pixel.
Without that instruction, your CSS media queries never fire. A breakpoint written as max-width: 768px will not match, because as far as the browser is concerned the viewport is about 980 pixels wide — so the phone gets the desktop layout no matter how carefully the responsive styles were written.
It is a browser directive, not a search engine one. Search engines care because they render pages the same way a phone does.
What actually happens to a page that has no viewport tag?
The browser falls back to a virtual viewport of roughly 980 pixels, renders the desktop layout into it, then scales the whole thing down to fit the screen. The result is text at around a third of its intended size, tap targets too small to hit reliably, and horizontal scrolling on a page that was never meant to scroll sideways.
This fallback exists for a reason: it was added so that desktop-only sites from before responsive design remained usable on the first smartphones. Two decades later it is a trap rather than a courtesy, and it fires on any page that forgets one line of HTML.
The search consequence follows automatically. Google now indexes the mobile rendering of every site, so a page that fails on mobile fails everywhere — there is no desktop version of the index to fall back on. Lighthouse flags the missing tag in its SEO category, and the same page will usually pick up matching failures for tap target size and font legibility.
What is the correct viewport tag?
One line: <meta name="viewport" content="width=device-width, initial-scale=1"> in the <head>. That covers essentially every responsive site, and the extra directives people add on top are usually either redundant or harmful.
Put it high in the head, before stylesheets, so the browser knows the layout width before it starts computing styles. Two additions are legitimate in specific cases: viewport-fit=cover on sites that draw into the notch or home-indicator areas on modern phones (paired with the env(safe-area-inset-*) CSS variables), and interactive-widget to control how the layout responds when the on-screen keyboard appears.
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!-- Legitimate addition: drawing into the notch / safe areas -->
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
<!-- Avoid: blocking zoom is an accessibility failure -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" />Why should you never set user-scalable=no?
Because it removes pinch-zoom, and pinch-zoom is how people with low vision read your site. Blocking it fails WCAG 2.1 success criterion 1.4.4 Resize Text at Level AA, and both axe-core and Lighthouse report it as an accessibility violation.
maximum-scale=1 has the same effect by a different route: it permits zooming in principle and then caps it at no zoom at all. Anything below maximum-scale=2 will be flagged.
There is also a practical argument. Safari on iOS has ignored user-scalable=no since iOS 10 precisely because Apple judged it too harmful to honour, so on a large share of mobile traffic the directive does nothing except sit in your markup failing an audit. The reason it gets added is almost always to stop accidental zoom on form inputs — the real fix there is a font-size of 16px or larger on inputs, which prevents iOS auto-zoom without taking the control away from anyone.
Does the viewport tag affect Core Web Vitals?
Yes, mostly through layout stability and interaction sizing. A page rendered at 980px and scaled down still loads every desktop-sized asset, so the largest element is bigger than it needs to be and Largest Contentful Paint suffers accordingly.
The bigger effect is on shifting content. When the layout is computed against the wrong width, late-loading elements reflow at the wrong scale and push content around, which is exactly what Cumulative Layout Shift measures. Adding the tag does not by itself make a slow page fast, but it removes a whole class of mobile-only regressions from your Core Web Vitals field data.
How do I confirm every page has it?
Check the rendered <head> of every URL in a crawl, not just the homepage. The tag normally lives in one shared layout, so coverage tends to be all or nothing — but the exceptions are the dangerous part: standalone landing pages, legacy templates, error pages and print views are the URLs most likely to have been built outside the main layout.
Audra checks for the presence and content of the viewport meta tag on every crawled page, and its Lighthouse pass independently penalises pages that are not mobile-optimised. Both land in the same report, so you can see a missing tag next to the performance and accessibility cost it is producing rather than as an isolated warning. Performance carries 30% of the Audra Score and accessibility 25%, so this one line moves both.
The fix, step by step
- 1Open the shared site template that produces the <head>.
- 2Add <meta name="viewport" content="width=device-width, initial-scale=1"> near the top, before stylesheets.
- 3Remove any maximum-scale or user-scalable=no directives you find.
- 4If form inputs were the reason zoom was blocked, set inputs to a 16px minimum font size instead.
- 5Re-crawl and confirm the tag appears on every page, including error pages and standalone landing pages.
Frequently asked questions
Where does the viewport tag go?
In the <head>, ideally near the top and before stylesheets, so the browser knows the layout width before it begins computing styles and rendering.
Does the viewport tag affect SEO?
Indirectly but significantly. Google indexes the mobile rendering of every page, so a page that lays out at desktop width on a phone fails mobile usability and is judged on that broken rendering.
Should I disable pinch zoom?
No. Blocking zoom fails WCAG 2.1 criterion 1.4.4 and is flagged by every accessibility audit. Safari on iOS has ignored the directive since iOS 10 anyway, so it mostly just fails audits without achieving anything.
Why do my media queries not work on mobile?
A missing viewport tag is the most common cause. Without it the browser reports a layout viewport of roughly 980 pixels, so width-based breakpoints below that never match and the desktop layout is served to every phone.