No mobile viewport

What a phone does without the tag

Mobile browsers were built at a time when almost no site was designed for small screens. To cope, they lay pages out on a virtual canvas roughly 980 pixels wide and then scale the result down to the physical screen. Without a viewport tag, your page still gets that treatment today.

The visible result is body text at a fraction of its intended size, buttons too small to tap accurately, and visitors pinching and panning to read anything. The less obvious result is that your responsive CSS never runs. Media queries test the layout width, which the browser reports as about 980 pixels, so the mobile breakpoints you wrote are skipped and the desktop layout renders, shrunk.

Who it hurts

On many sites, phones account for most visits, and every one of those visitors gets the shrunken page. People with reduced vision or motor control have it worst, since small text and small targets are exactly what they struggle with.

Google Search indexes the mobile rendering of a page, so the zoomed-out layout is the version it evaluates. For an agency, this is also the failure a client spots in the first minute: the first thing most owners do after launch is open the site on their own phone.

How Skewcheck checks it

Skewcheck reads meta name="viewport" from the page and checks that its content includes width=device-width. If the tag is missing, or present without that value, the check fails with high severity and deducts 8 points from the audit score, one of the larger single deductions an audit can carry. A fixed width such as width=1024 or width=980 fails too, because it pins the layout to a desktop width. Any tag whose content includes width=device-width passes.

The tag, and where frameworks put it

The standard value is width=device-width, initial-scale=1. The first part sets the layout width to the device's width in CSS pixels; the second sets the starting zoom to 100 percent. If your design draws behind the notch or rounded corners on some phones, add viewport-fit=cover and pad the content with the env(safe-area-inset-*) CSS variables.

The Next.js App Router inserts a default viewport tag with these values on every page, so a failure on a Next.js site usually means something else in the head replaced it. To customize the tag there, export a viewport object rather than adding a raw <meta> element. In the Pages Router, put the tag in a next/head block inside _app, not in _document.

import type { Viewport } from "next";

export const viewport: Viewport = {
  width: "device-width",
  initialScale: 1,
  themeColor: "#ffffff",
};

Mistakes, especially around zoom

Do not add user-scalable=no or maximum-scale=1. Both stop visitors from zooming, which locks out anyone who needs larger text and conflicts with the accessibility requirement that text can be resized to 200 percent. Some mobile browsers now ignore these values for that reason, but others still honor them.

The usual reason people disable zoom is that some phones zoom in when a form field gets focus. That happens when the input text is smaller than 16 pixels. Set font-size: 16px or larger on inputs, selects, and textareas, and the jump stops without taking zoom away from anyone.

The tag only tells the browser to use the device width; it cannot make a fixed-width layout fit. If a container is hard-coded to 1200 pixels, the page will scroll sideways after the fix. Check for horizontal overflow at 375 pixels wide. Also look for duplicate viewport tags from a theme and a plugin, since browsers generally apply the last one.

Before and after

<head>
  <meta charset="utf-8">
  <title>Example Bakery</title>
</head>

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Example Bakery</title>
</head>