Check website

Meta viewport tag: what it does for mobile SEO

·4 min read

The meta viewport tag tells a mobile browser to lay out your page at the width of the phone's screen instead of pretending to be a desktop monitor. Use <meta name="viewport" content="width=device-width, initial-scale=1"> in the <head> and stop there. Leave out maximum-scale, minimum-scale and user-scalable, because they exist mostly to block zoom, and blocking zoom fails people with low vision.

Without the tag, your responsive CSS never gets a chance. The phone renders a page about 980 pixels wide and shrinks it to fit, so your media queries see a desktop and your text arrives at a size nobody can read.

The correct meta viewport tag

Almost every site should ship this tag once, in the <head>.

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

Google's responsive design basics on web.dev recommend exactly this value, and Next.js adds it to every page by default. If your page has it, the viewport is done. If your page has something longer, read on, because the extra values are where the trouble starts.

What each viewport value does

Each key in content controls one part of how the browser sizes and zooms the page. MDN's viewport reference lists the allowed values.

Value What it does Use it?
width=device-width Sets the layout width to the screen width in CSS pixels Yes, always
initial-scale=1 Starts at 1:1 zoom and keeps it when the phone rotates Yes
width=500 Fixes the layout at a pixel width No, it breaks on every other screen size
maximum-scale Caps how far people can zoom in No
minimum-scale Caps how far people can zoom out No
user-scalable=no Turns pinch zoom off No
viewport-fit=cover Draws under the notch and rounded corners Only with env(safe-area-inset-*) padding
interactive-widget=resizes-content Shrinks the layout when the on-screen keyboard opens Only if fixed footers or chat inputs get covered

The two keys worth explaining are the first two. width=device-width is what makes your breakpoints fire at phone widths. initial-scale=1 fixes a quirk where some browsers keep the portrait width after rotation and zoom in to fill the wider screen instead of reflowing.

Why user-scalable=no and maximum-scale=1 hurt

Blocking zoom takes away the one tool people with low vision rely on to read your page. MDN says it directly, and the WCAG 2 success criterion 1.4.4 Resize Text requires that text can be resized up to 200 percent. Lighthouse's accessibility category runs the axe rule that fails a page when the tag sets user-scalable=no or a maximum-scale below 5.

This version turns up in old themes and app-style templates.

<!-- Don't ship this -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

Most teams add maximum-scale=1 for one reason. iOS Safari zooms into a form field when its font size is under 16 pixels, and the zoom looks like a bug. The real fix is CSS, not the viewport.

<style>
  input, select, textarea { font-size: 16px; }
</style>

MDN notes that iOS 10 and later ignore maximum-scale and user-scalable by default, so on iPhones the restriction often does nothing. Android browsers can honor it, which means the people you lock out are the ones on the devices where the tag still works. There is no SEO gain from blocking zoom to offset that.

Meta viewport and mobile-first indexing

The viewport tag is a mobile usability fix, not a ranking signal Google names on its own. Google's mobile-first indexing guide says Google indexes and ranks the version of your page crawled with the smartphone agent, and that only the content on the mobile site is used for indexing. That guide does not mention the viewport tag at all. Its concern is that the mobile HTML carries the same content, links and markup as desktop, which we cover in mobile-first indexing: what Google sees on your mobile site.

Where the tag does matter is the experience Googlebot Smartphone is crawling. A page without it is a shrunken desktop page on every phone. Google retired the Mobile-Friendly Test and the Mobile Usability report on December 1, 2023, and said in its page experience post that this does not make mobile usability unimportant. Lighthouse is now the place to check it, and phone layout problems often show up in Core Web Vitals too.

Common viewport mistakes

These are the ones we see on real sites.

  1. No tag on some templates. The theme has it, but a landing page builder, an AMP leftover or a hand-written error page does not.
  2. Two viewport tags. A plugin injects a second one with different values, and which one wins is up to the browser.
  3. Zoom blocked. user-scalable=no or maximum-scale=1 copied from an old template.
  4. A fixed width. width=1024 makes a desktop layout on every phone, which is the same failure as having no tag.
  5. Mobile and desktop disagree. A site that serves phones different HTML drops the tag from the mobile template only, so desktop source looks fine.

To see what a page ships, open DevTools on the live URL and run document.querySelectorAll('meta[name="viewport"]') in the console. More than one result is a bug.

Check the viewport on your mobile page

The Mobile Parity Checker fetches a URL with a mobile browser user agent and a desktop browser user agent and compares the HTML each one returns. It warns when the mobile HTML has no <meta name="viewport"> and gives the tag to add. In the same run it compares content word count, headings, structured data, title, meta description, robots meta, canonical, links, images and hreflang between the two versions, so it also catches the mobile-only template bugs in the list above.

It checks that the tag exists, not what values it holds, so it will not flag user-scalable=no. Use Lighthouse's accessibility audit for that. It also does not render JavaScript, measure speed or test tap targets. Each run costs 5 credits.

Keep reading