Is a separate mobile site ever better?

Rarely. It creates two URLs and two places for content to diverge. Google's guidance is that a responsive site is the simplest configuration to maintain.

Where should breakpoints go?

Where the content stops working, found by resizing the window, rather than at the widths of particular devices.

What do container queries add?

They let a component respond to the width of its own container rather than the viewport, which is what makes a component reusable in different layouts.

Glossary

Responsive web design

Responsive web design is the approach of serving one document that adapts its layout to the width of whatever is displaying it, rather than maintaining separate versions for separate devices. It rests on three things: fluid layouts sized in relative units, flexible images that scale within their containers, and media queries that change the layout at chosen breakpoints. It is now the default approach, and Google's mobile-first indexing assumes it.

What it replaced

Separate mobile sites on their own hostname, usually `m.example.com`, with content that diverged from the main site over time.

Server-side device detection, which required a list of devices that was out of date the day it shipped.

Both created two URLs for one page, which needed canonical tags and alternate annotations to resolve, and both created two places for content to be updated and one place where it was forgotten.

One document at one URL removes all of that, and it is why the approach became universal rather than merely popular.

The pieces it is built from

The viewport meta tag, without which a phone lays out at desktop width and the rest is irrelevant.

Fluid layout: percentages, viewport units, flexbox and grid, rather than fixed pixel widths.

Media queries changing the layout at breakpoints chosen from where the content stops working, not from a list of device sizes.

Responsive images, through `srcset` and `sizes`, so a phone does not download a file sized for a desktop.

Container queries, now supported in current browsers, which let a component adapt to its own container's width rather than to the viewport — the piece the original approach lacked.

Where it commonly breaks

A fixed-width element — a table, a wide image, a code block, an embedded video — overflowing the viewport and producing horizontal scrolling on the whole page.

Text sized so small on mobile that it cannot be read without zooming.

Navigation that becomes a collapsible menu without the keyboard and screen reader behaviour the new pattern requires.

Layouts tested at the common device widths only, leaving the widths between them broken.

Hiding content on small screens with `display: none`, which is a decision that it does not matter — sometimes right, and frequently made by accident.

How to check it

Resize the browser window continuously from wide to narrow and watch for the width where the layout breaks. It is rarely at a named breakpoint.

Check for horizontal overflow at a narrow viewport, which is the single most common and most visible failure.

Check the rendered font sizes on mobile, and the touch target sizes at the same time.

Test the mobile navigation with a keyboard, since it is a different widget from the desktop one and usually a newer one.

Frequently asked questions

Is a separate mobile site ever better?: Rarely. It creates two URLs and two places for content to diverge. Google's guidance is that a responsive site is the simplest configuration to maintain.
Where should breakpoints go?: Where the content stops working, found by resizing the window, rather than at the widths of particular devices.
What do container queries add?: They let a component respond to the width of its own container rather than the viewport, which is what makes a component reusable in different layouts.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website