Mobile-first design: what it means for your site

Mobile-first design means the phone version of each page is designed first, and the tablet and desktop versions are built outward from it, instead of a desktop design squeezed down to fit. For your business it matters for two reasons. Most of your visitors arrive on a phone, and Google indexes the mobile version of your site, so anything missing on mobile is missing from search.

What does mobile-first mean in practice?

It is a decision about order, not about devices. The designer starts with a screen about 360 pixels wide and asks what the visitor needs in the first screen, the second and the third. There is no room for a hero image, three columns of features, a carousel and a sidebar, so each one has to earn its place. What survives is the content that matters: who you are, what you do, proof, and a way to contact you.

The desktop layout is then an expansion of that, with the same content and the same priority order, using the extra width for side-by-side sections and visible navigation. Nothing is added on desktop that a phone visitor would not get.

For developers it is also a way of writing CSS: base styles target the small screen and min-width media queries add the wider layouts. That is a detail you do not need to specify, but a developer who works the other way round, with max-width queries subtracting from a desktop layout, has usually designed desktop-first.

The one line of HTML every mobile-first page needs, and that older sites sometimes lack, is the viewport tag in the page head:

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

Without it a phone renders the page at desktop width and shrinks it, and no amount of CSS will fix the result. It is one of the first things we check when reviewing an existing site before a website design and development project.

Why does Google care which version you design first?

Because Google reads the mobile version. Its documentation on mobile-first indexing describes it plainly: Googlebot crawls and indexes pages with a smartphone user agent, and what it sees on mobile is what goes in the index. Google completed the move to mobile-first indexing for all sites by 2024, and since July 2024 a site that is not accessible on a mobile device at all is not indexable.

The practical consequences:

• Content hidden on mobile to save space is content Google may not count. Accordion sections are fine, since the text is in the page; a section removed by CSS on small screens is not.
• Structured data, meta tags and internal links must be the same on the mobile version. If the desktop header has twelve links and the mobile menu has four, Google sees four.
• Images need alt text and proper img tags on mobile too, not background images swapped in by CSS.

On a responsive site, where the same HTML serves every screen, all of this is automatic. The problems appear on sites with a separate mobile version or with heavy mobile-only trimming.

How is mobile-first different from responsive design?

They are usually used together and mean different things. Responsive is a technique: one page that rearranges itself to fit any screen width. Mobile-first is a priority: which screen the design starts from. You can build a responsive site desktop-first, and many are.

The second row is what you want from a new build. When we design a company site as part of a website design and development project, the phone layout of each page is approved before the desktop layout is drawn, because it is where the hard decisions about content get made.

What changes on the page when you design mobile-first?

Specific, visible things. These are what to look for in a design review.

• Shorter headlines. A headline that wraps to four lines on a phone gets cut until it wraps to two.
• One column. Sections stack. Side-by-side text and image becomes image, then text, with the order chosen deliberately.
• Bigger tap targets. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels for anything tappable; Apple's guidelines ask for 44 points. Buttons are full width or close to it, and links in text have space between them.
• Fewer form fields. Every field is a chore on a phone keyboard. Name, phone or email, message. The rest can wait for a call.
• Tap-to-call and WhatsApp. The phone number is a tel: link and the WhatsApp button is visible without scrolling. On a phone, these replace the contact form for many visitors.
• Text at 16 pixels or larger. Smaller text makes iOS zoom into form fields and makes everything else hard to read.
• No hover. Menus open on tap, tooltips become visible text, and nothing important is revealed by a mouse pointer that phones do not have.
• Tables that scroll or restack. A six-column table on a 360-pixel screen either scrolls sideways within its container or collapses into cards. Either is a design decision, not something to leave to the browser.
• Images sized for the screen. A 2,400-pixel hero image sent to a phone is wasted bandwidth. Responsive image markup from a srcset generator sends each screen a size it can use, and compressing the originals first with the image compressor often halves page weight on its own.

What should you check on your own site?

Open it on your phone, on mobile data rather than Wi-Fi, and try to do what a customer would: find a price, find the phone number, send the form. Most problems show up in that two-minute test. Then check three things with tools.

Core Web Vitals, mobile. In Search Console, the Core Web Vitals report shows real-visitor data for mobile and desktop separately. The thresholds, from Google's web vitals documentation, are LCP at or under 2.5 seconds, INP at or under 200 milliseconds and CLS at or under 0.1, measured at the 75th percentile. Mobile numbers are almost always worse than desktop, and mobile is the one that counts. The Core Web Vitals checker tells you whether a given set of numbers passes.

PageSpeed Insights on the mobile tab. It shows the same field data plus a lab run, and lists the specific images, scripts and fonts slowing the page.

Device mode in Chrome DevTools. Narrow the viewport to 360 pixels and tab through the page. Overflowing elements, text that becomes unreadable, and tap targets that overlap all show here. It is not a substitute for a real phone, which has a real keyboard, a real touch target and a real network.

When is mobile-first the wrong priority?

When your visitors are not on phones. A B2B dashboard, an internal tool, a booking back-office, a data-heavy product used at a desk: these are used on large screens all day, and designing them for a phone first produces a cramped desktop experience that nobody wanted. Check your analytics before deciding. If 80 percent of sessions are desktop, design desktop-first and make sure the phone version works, which is a different and cheaper requirement than making it the priority.

Public-facing company websites are rarely in that group. For a site whose job is to turn a search into an enquiry, the phone is where the enquiry happens, and the mobile layout is the one to get right. The website planning guide covers where that decision sits, and the accessibility basics post covers the tap target and text size rules that mobile and accessibility share.