What Is Responsive Design?

The term was coined by designer Ethan Marcotte in an article published on May 25, 2010, on A List Apart, where he laid out its three technical pillars: flexible grids, flexible images, and media queries. Each of those techniques existed on its own before that article. Marcotte was the one who combined them into a single design approach built for a web already viewed on many different devices.

Responsive design is a development technique: the same HTML document, with no duplicated code and no separate version per device, changes how it's presented depending on screen width through CSS rules. The browser loads the identical page whether it's opened on a phone or a desktop computer. What changes is how that content is arranged, not the content itself.

The central mechanism is media queries, CSS rules that apply a block of styles only when a condition is met, almost always the width of the viewport. The points where the layout switches from one arrangement to another are called breakpoints. Alongside media queries sit flexible grids (using flexbox or CSS grid, which distribute available space in proportions instead of fixed pixels) and fluid images, which scale without overflowing their container.

Setting breakpoints based on the content rather than specific devices usually works better than targeting particular phone or tablet widths: a device lineup that changes every year makes any breakpoint tied to a specific model outdated fast, while a breakpoint placed exactly where the layout itself starts to break down, a menu that crowds together or text that gets too narrow to read, keeps working no matter what devices are on the market.

A simple example: a full-width image on mobile and a horizontal menu from tablet width up, both defined in the same stylesheet.

<style>
  .menu {
    display: block; /* stacked by default, for mobile */
  }
  img {
    max-width: 100%;
    height: auto;
  }

  @media screen and (min-width: 768px) {
    .menu {
      display: flex; /* horizontal from tablet/desktop up */
    }
  }
</style>

For a mobile browser to actually honor this behavior, the document also needs the viewport meta tag in the head. It's a common thing to forget, and without it the phone renders the page at desktop scale and shrinks it down afterward, which cancels out the effect of the media queries.

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

The tag itself didn't originate from a formal web standard. Apple introduced it in Safari on the original iPhone, so that sites built for desktop widths would still display in a usable way on a much smaller screen. Other mobile browsers later adopted the same syntax as a de facto standard, which is why it still works today even though it was never formally written into a W3C specification.

These two concepts get mixed up often, and they operate at different levels. Responsive design is a development technique: it decides how a page looks on each screen, and the team that builds the site controls it. Mobile-first indexing is a Google process: it decides which version of a page Google uses as the source for crawling it, storing it in the index, and calculating its ranking, and that decision is Google's to make, not the developer's.

A responsive site makes it much easier to satisfy mobile-first requirements, because the HTML is identical in both versions and nothing gets lost switching between them. Even so, the two aren't synonyms: a site can be responsive and still fail mobile-first if, say, CSS hides a text block on small screens and that block never becomes part of what Google crawls.

An example makes the difference concrete. If an online store restyles its product page with CSS so it looks right on any screen, that's responsive design work, decided entirely by the development team, with no input from Google. If Google instead starts showing, in the search result, the price or description that appears on that same page's mobile version rather than its desktop one, that's mobile-first indexing, and no CSS decision changes it: what matters is which content ends up, in the final HTML, in the version Googlebot Smartphone crawls.

The full detail of what Google actually checks in that process, and how to verify it with URL Inspection, lives in the dedicated article on mobile-first indexing.

Before responsive design became the norm, the usual solution was to publish two separate sites: one on the main domain for desktop and one on a subdomain like m.mysite.com for mobile, each with its own HTML and, often, trimmed-down content on the mobile side. This pattern, known as separate URLs, still shows up on older sites, but it's now considered outdated.

The problem wasn't technical, it was maintenance and SEO. Every piece of content existed twice, under two different URLs, which risked duplicate content unless canonical and alternate tags were managed carefully between both versions. Every visit also needed a redirect: a mobile user landing on the desktop URL had to be sent to the m. version, and vice versa if someone shared a link from their phone. And any change to content, pricing, or structure had to be applied twice, across two independent templates, with the constant risk that one version got updated and the other fell behind.

There was also a third, in-between option, dynamic serving: a single URL for both versions, where the server detected the visitor's user agent and returned different HTML depending on whether it was mobile or desktop, flagged with the HTTP Vary header so crawlers knew the content varied by device. It solved the two-URLs problem but still left two templates to keep in sync, and it added a risk of its own: if the server misdetected the user agent, it could serve the wrong version to Googlebot.

Google recommends responsive design precisely because it solves all three problems at once: one URL per piece of content, no redirect needed between versions because there are no two versions to redirect between, and a single template to maintain. In the words of Google's own Search Central documentation, it's the pattern that's "easiest to implement and maintain" among the options available for serving content across devices. For most new projects today, there's barely a reason left to choose separate URLs or dynamic serving, except under very specific technical constraints that call for a completely different mobile frontend.

• Always include <meta name="viewport" content="width=device-width, initial-scale=1"> in the head; without it, media queries don't behave as expected on mobile.
• Design for mobile first and add complexity through media queries as screen width grows (mobile-first design), rather than starting from the desktop version and trimming it down afterward.
• Use relative units (%, rem, vw) instead of fixed pixels for widths, margins, and typography, and cap images with max-width: 100% so they never overflow their container.
• Test the layout at several real widths, not only at the standard breakpoints; many problems only show up at in-between widths that no breakpoint covers.
• Keep the same HTML across all screens: if secondary content needs hiding on mobile, do it with CSS that still leaves it present in the markup, rather than removing it from the document.

• Forgetting the viewport tag, which makes mobile browsers render the page at desktop scale and shrink it afterward, canceling out the media queries.
• Hiding content with display: none on mobile assuming it only affects the view, without accounting for the fact that it can stop counting for ranking if Google never crawls it.
• Confusing responsive design with mobile-first indexing and assuming that an adaptable site automatically satisfies whatever Google evaluates when indexing.
• Defining breakpoints only for today's most common screen sizes, with no margin for future devices at different widths.
• Serving unoptimized, high-resolution images at the same size on mobile and desktop, which hurts load time on mobile networks even when the layout itself looks correct.