Mobile first
Mobile-first design, and the two things it keeps getting confused with.
Three terms get used as if they mean the same thing. They do not, and the difference decides whether content you wrote is seen by Google at all.
What is mobile-first design, and is it the same as mobile-first indexing?
Mobile-first design is a way of building: the small screen version is designed and built first, then expanded for larger screens, so the phone experience is the fully considered one rather than a squeezed leftover.
Mobile-first indexing is a separate thing and it belongs to Google rather than to you: Google predominantly uses the mobile version of a page for indexing and ranking, so anything that exists only in your desktop layout may not be taken into account at all.
Neither is a ranking bonus awarded for being mobile friendly, and responsive design is a third thing again, describing a layout that adapts to screen width, which you can build desktop-first and still call responsive.
Three terms, three different meanings
Most arguments about mobile design are actually people using one word for three ideas. Separating them makes the practical decisions obvious.
Responsive design is about layout. One set of pages reflows to fit whatever width it is given. It says nothing about which width was designed first, and a responsive site can still be a desktop site that collapses awkwardly.
Mobile-first design is about sequence and discipline. You start with the smallest useful screen, decide what genuinely has to be there, then add for bigger screens. Because the phone layout has the least room, designing it first forces the hard priority decisions early instead of leaving them to a last minute squeeze.
Mobile-first indexing is about Google. It is a statement of which version of your page Google predominantly uses to index and rank, and the answer is the mobile one. It is a crawling and indexing behaviour, not a reward.
The three, side by side
If a proposal or a report uses these interchangeably, this table is the question to ask back.
| The question | Mobile-first design | Mobile-first indexing | Responsive design |
|---|---|---|---|
| Whose behaviour is it | Yours, as a way of working | Google's, as a crawling and indexing behaviour | Your layout code |
| What it decides | What earns space on the smallest screen | Which version of the page gets indexed and ranked | How a layout reflows at different widths |
| What goes wrong without it | The phone layout becomes a compressed afterthought | Content only present on desktop can go unseen | The page breaks or needs pinch and zoom |
| Can you opt out | Yes, it is a choice | No, it is how Google works | Technically yes, practically no |
| Is it a ranking boost | No | No | No |
The last row is the one people find hardest to accept. None of these earn a bonus. What they do is decide whether the page you think you published is the page being judged.
How much of the traffic is actually mobile
This is a figure marketing copy routinely overstates, and the overstatement is unnecessary because the honest version makes the same point.
SourceStatCounter Global Stats: desktop versus mobile market share (live, excludes tablets)
Published figures range widely depending on whether tablets are folded in and which panel is measured, so we link the live source rather than freeze a percentage that will be wrong next quarter. For your own site the question is settled by your analytics anyway, and the split varies enormously by industry.
Mobile is measured as its own thing
Core Web Vitals are reported separately for mobile and desktop, which makes the point concrete: passing on a laptop tells you nothing about the experience your phone visitors had.
Phones do the same work with less processing power and often a worse connection. A script a laptop absorbs invisibly can cost seconds on a mid range handset, which is why passing on desktop and failing on mobile is such a common pattern.
Cumulative Layout Shift punishes phone visitors hardest as well. On a small screen a late arriving banner pushes everything down at exactly the moment a thumb is coming down on a button.
What mobile-first actually changes in a build
None of these are exotic. They are the decisions that get made differently when the phone layout is designed first rather than derived last.
- Content parity. The mobile page carries the same copy, headings, images, links and structured data as the desktop page. Hiding text behind a tab or an accordion is fine, because it is still in the page. Removing it from the mobile version entirely is not.
- One primary action per screen. A phone screen holds roughly one decision comfortably, so the ordering of what appears first becomes a real choice rather than a matter of where there was space.
- Tap targets sized and spaced for a thumb, not a cursor, with enough room between adjacent links that the wrong one is not hit by accident.
- A phone number that is a tappable link, and a form short enough to finish one handed on a moving train.
- Navigation that can be opened, used and closed with a keyboard as well as a thumb, because a collapsed menu is where accessibility most often breaks.
See the full checklist: What mobile-first actually changes in a buildHide the full checklist: What mobile-first actually changes in a build
- Images sized for the screen they appear on, rather than one desktop sized file sent to every device.
- Text that stays readable without pinching, with enough contrast to survive being read outdoors.
- Sticky elements kept honest. A sticky header, a chat bubble and a cookie banner together can leave a phone user with a small strip of actual content.
What a phone visitor is usually trying to do
Mobile visits skew towards immediate intent: find the number, check you are open, work out where you are, then act.
This is why mobile-first is a commercial discipline and not just an aesthetic one. If the fastest route to a phone call takes four taps and a pinch, the design has failed regardless of how it photographs in a portfolio.
It also changes what belongs at the top. A long brand statement above the fold is a desktop habit. On a phone the same space is better spent on what you do, where, and the one action that follows.
The mistakes that cost the most
Serving a cut down mobile page. Removing sections to make the phone version tidier means removing them from the version Google predominantly uses. Sites have quietly lost rankings this way and blamed an algorithm update.
Treating mobile as a testing step. Checking the phone layout at the end, in a browser window dragged narrow, is not the same as building for it. A narrow desktop window has a desktop processor and a fixed connection behind it.
Read the full breakdown: The mistakes that cost the mostHide the full breakdown: The mistakes that cost the most
Forgetting that structured data, page titles, meta descriptions, images and links all need to be present on the mobile version too, not only in the desktop template.
Blocking resources on mobile that are available on desktop. If a stylesheet or a script is needed to render the page properly and mobile crawling cannot reach it, the page being judged is not the page you built.
Assuming responsive means finished. A layout that technically reflows can still put the phone number below four screens of scrolling, which is a design failure that no breakpoint fixes.
Read next
The neighbouring questions worth answering at the same time.
Making a site load faster
The diagnosis order for mobile speed, and why field data settles the argument.
Making a site load fasterWhat technical SEO covers
Crawling, indexing, structure and the rest of the engineering layer.
What technical SEO coversWhat a call to action is for
The one thing a phone screen has room for, and how to word it.
What a call to action is forWhat a website costs
Why mobile work is part of the build price rather than a later phase.
What a website costsThe web design guide
How planning, building, measuring and maintaining a site fit together.
The web design guideSee what your site looks like to a phone
A free audit reports your mobile field performance, content parity issues and the tap targets that are too small or too close together.
Straight answers.
Is mobile-first design the same as responsive design?
No. Responsive describes a layout that adapts to screen width. Mobile-first describes the order you design in, starting from the smallest screen.
You can build a responsive site desktop-first, and plenty of disappointing phone experiences are exactly that.
Does being mobile friendly improve my rankings?
Not as a bonus. Mobile-first indexing means the mobile version is the one predominantly used for indexing and ranking, so a broken or reduced mobile page can hurt you.
A good one removes a problem rather than adding an advantage. The gain is that the page you wrote is the page being assessed.
Should I have a separate mobile site?
Separate mobile URLs are a legacy pattern that creates content parity problems, duplicate URL management and a second site to keep in step.
One responsive set of pages, designed from the small screen up, is far simpler to keep correct.
Can I hide content on mobile to keep the page short?
Content inside tabs, accordions or expandable sections is still in the page and is treated as part of it. Content deleted from the mobile version is not there at all.
If something matters enough to say on desktop, keep it in the markup on mobile and control how it is displayed instead.
How do I know whether my mobile version is the problem?
Compare mobile and desktop directly in your analytics and in your field performance data. Look at the mobile share of sessions against the mobile share of enquiries.
A large gap between those two shares is the clearest signal that the phone experience, not the traffic, is where you are losing people.
Does mobile-first mean the desktop site matters less?
No. It means the mobile version carries the indexing weight and usually the harder usability constraints.
Plenty of businesses still take most of their revenue from desktop visits, which is a reason to check your own analytics rather than to follow a general rule.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- Google Search Central: Mobile-first indexing best practices (opens in a new tab)
- Google Search Central: Understanding page experience in Google Search results (opens in a new tab)
- Google web.dev: Web Vitals (opens in a new tab)The current thresholds for LCP, INP and CLS, and the 75th percentile rule.
- W3C: Web Content Accessibility Guidelines (WCAG) 2.1 (opens in a new tab)
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.