Responsive design vs a separate mobile site

Running two separate versions of a website used to be common: a full desktop site and a stripped-down mobile subdomain, back when mobile browsers and connections were genuinely limited. That is now, for almost every small business, the wrong default. It doubles the maintenance burden, and creates exactly the content-parity risk that mobile-first indexing penalises.

What responsive web design, responsive sites, and a separate mobile website actually are

Responsive design is one set of content and one codebase that changes its layout using CSS — column widths, font sizes, navigation pattern — based on the screen size viewing it. The underlying content is identical regardless of device. Only the presentation adapts.

A separate mobile site (historically often served from an m. subdomain) is a genuinely different set of templates. Sometimes it is a genuinely different, reduced set of content, served specifically to mobile user agents. Two sites means two things to update every time content changes, and a real risk that the two drift out of sync over time.

Why responsive, not adaptive, design is now the standard default

Mobile-first indexing evaluates the mobile version of a page for indexing purposes — covered on why mobile-first matters for an Australian small business. A responsive site has no separate mobile version to fall behind. There is only one version, presented differently. A separate mobile site structurally recreates the exact risk mobile-first indexing exposed: if the mobile templates lag behind the desktop ones in content, links or structured data, that gap is what Google actually sees.

Beyond the indexing question, a separate mobile site is simply more to build and maintain. Every new page, every content update, every structural change has to be implemented and tested twice rather than once. That is a genuine, ongoing cost with no offsetting benefit for the overwhelming majority of small-business use cases.

Where a separate approach was historically used, and why it is now narrow

A small number of legitimate historical reasons existed for a separate mobile site. They included very early mobile networks with genuinely limited bandwidth, older feature-phone browsers that could not render modern CSS at all, or an application with a fundamentally different job on mobile versus desktop — a native-app-like tool, rather than an informational site. None of these apply to an ordinary small-business informational or service website built on a current platform in 2026. The remaining genuine case is an old, unmaintained website on a legacy platform that cannot support a responsive front end without substantial rework. In that case, the honest comparison is between retrofitting responsiveness and a fuller rebuild. It is not between “responsive” and “separate mobile site” as two equally live current options.

The viewport tag is the specific, checkable requirement responsive design depends on

A responsive layout only actually works correctly on a mobile browser if the page includes a viewport meta tag. That tag tells the browser to render the page at the device’s actual width, rather than a default desktop-width assumption scaled down and zoomed out. A site missing this single line of markup can have a fully built, technically correct responsive CSS layout that never actually displays correctly on a phone. This happens because the browser renders it as a shrunken desktop page, instead of applying the responsive rules at the device’s real width. This is one of the fastest things to check on an existing site. It is also one of the most common causes of “the responsive design isn’t working” turning out to be a missing tag, not a design problem.

Breakpoints should follow content across screen sizes and devices, not a fixed device width

A responsive layout adapts at defined screen-width breakpoints. The more durable approach chooses these breakpoints based on where the actual content genuinely stops looking right — where a row of items starts feeling cramped, or where text starts wrapping awkwardly — rather than targeting the exact pixel width of specific popular phone models. Device screen sizes vary continuously. A new device released after the site was built will not necessarily match any breakpoint chosen around today’s specific popular models. Content-based breakpoints stay correct as the device landscape shifts, in a way that device-specific breakpoints do not.

Testing needs to cover more screens than just “phone” and “desktop”

A responsive layout that has only been checked at a phone width and a desktop width can still have a genuinely broken middle ground. That middle ground includes a tablet held in portrait, a phone held in landscape, or a browser window resized to an in-between width on a laptop. Content can overlap, wrap unexpectedly, or a navigation menu can misbehave at these sizes. Testing at a small number of in-between widths, not just the two extremes, catches this category of failure that a phone-versus-desktop-only test misses entirely.

A short comparison: responsive websites, mobile websites, and mobile sites

	Responsive design	Separate mobile site
Content parity risk	Low — one content source	Real — two templates can drift apart
Ongoing maintenance	Update once	Update twice
Mobile-first indexing exposure	Minimal, if implemented correctly	Higher — the separate mobile version is what gets indexed
Standard for a new small-business build in 2026	Yes	No — narrow legacy cases only

What to do next

If an existing site still runs on a separate mobile subdomain or template set, that is worth flagging as a priority before addressing any of the more granular issues elsewhere in this cluster. It is the structural cause several other problems trace back to. For where this decision sits inside a broader build, website design services covers the service this kind of consolidation is scoped under.