One site that adapts beats two that drift

How each one works

A responsive site serves the same markup to every device and changes the layout with styling rules based on the width available.

A separate mobile site detects the device and sends phones to a different address with its own pages, usually a reduced version.

The first is one thing that adapts. The second is two things that must be kept in agreement, by people, forever.

Put that way the choice answers itself, and it is worth remembering that the second approach was invented when phones could not handle a normal page.

One thing that adapts, or two things that must be kept in agreement by people, forever. Put that way the choice answers itself.

Why separate sites lost

Maintenance. Every content change has to be made twice, and within months one version is ahead of the other.

Indexing. The mobile version is the one evaluated, so anything only on the desktop version is effectively missing, and the desktop version is usually the one that gets updated.

Addresses. Two addresses for the same content means duplication, canonical tags to manage, and links that arrive at the wrong version.

The mobile version is the one evaluated, so anything only on desktop is effectively missing — and desktop is usually the one that gets updated.

What responsive actually requires

Flexible widths rather than fixed ones, images that scale, and a small number of points where the layout rearranges.

A viewport declaration so phones render at the correct scale rather than shrinking a desktop page.

Testing at several widths, including the awkward ones between phone and tablet, where layouts most often break.

It also requires tap targets large enough to hit and spaced far enough apart, which is a layout decision rather than a styling afterthought.

• Flexible widths rather than fixed ones
• Images with a maximum width so they scale
• A viewport declaration
• A small number of points where the layout rearranges
• Tap targets large enough and far enough apart
• Testing at the awkward widths between phone and tablet

The trap in responsive layouts

Hiding content at small widths to keep the design tidy. This is the responsive equivalent of the separate site problem, because hidden means removed from what a phone visitor gets.

If content is worth having on desktop, it is worth having on a phone, possibly collapsed but present.

The other trap is horizontal scrolling, usually caused by one fixed width element such as a table or an embedded frame.

Hiding content at small widths is the responsive equivalent of the same problem, as covered in mobile first indexing.

If you have inherited one

Audit what differs between the two versions first. That list is usually longer than anybody expects and it is the real scope of the work.

Build one responsive site carrying everything, then redirect the mobile addresses permanently to their equivalents.

Keep those redirects indefinitely, because links to the mobile version exist in messages, bookmarks and other people's pages.

Expect the audit to take longer than the build. Finding out what the two versions actually say is the hard part; writing one version is comparatively simple.

Audit what differs between the two versions first. That list is usually longer than anybody expects and it is the real scope of the work.

Dynamic serving

A middle approach serves different markup from the same address depending on the device. It avoids the duplicate address problem and keeps the double maintenance one.

It also requires telling caches and crawlers that the response varies, which is easy to get wrong in ways that are hard to notice.

For a small business site there is rarely a reason to choose it over a straightforward responsive layout.

How ours are built

Sites here are a single responsive layout with one address per page, so the phone and desktop versions cannot disagree about anything.

Layouts are checked for horizontal overflow at a range of widths before anything publishes, which catches the fixed width element that breaks a phone view.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards.