October 08, 2026
Our own Search Console says it plainly: over the last 90 days, when our site appeared in a Google result on a phone, 2.3 percent of people clicked. On a desktop, 8.4 percent did. Same pages, same rankings, a third of the click rate on the device most Indians search from. That gap is what mobile friendly website design is actually about, and it is why we open with a number that does not flatter us.
Mobile friendly website design means a site that is built for the phone first: it is read by Google's mobile crawler as the real version of the site, it loads within a few seconds on a mid range Android on a mobile connection, and every button, form and menu can be used with a thumb without zooming. Responsive design is the technique that gets you there; mobile friendly is the result the customer feels.
Since 2023 Google indexes the mobile version of nearly every site, and only that version. Whatever your desktop site says is irrelevant to ranking if the mobile page hides it.
Three checks follow from that. Content parity: headings, text, images, structured data and links on the mobile page must match the desktop. A site that collapses a specification table on mobile into "tap to view" is fine if the table is still in the HTML; a site that removes it for phones has removed it from Google. Crawlability: the mobile page must not block resources, must serve the same URLs, and must not need a tap to reveal the main content. Speed and stability: the Core Web Vitals, measured in the field on mobile. A page that passes on desktop and fails on mobile fails.
The old Mobile Friendly Test tool was retired in late 2023. Its checks now live in Lighthouse and in the page experience signals: viewport tag present, text readable without zoom, tap targets not too close, no horizontal scroll. They are minimums, not goals. A page can pass all of them and still be a poor experience.
Responsive web design is a method: one HTML page, one set of content, with layout rules in CSS that rearrange it for the width of the screen. Three columns become one, the menu folds into a button, images scale. About 880 people a month in India search for "mobile responsive web design", and it is the right thing to ask a developer for, because the alternatives (a separate mobile site, or a desktop site scaled down) are worse in every way that matters.
Mobile friendly is an outcome. A responsive site can still be mobile unfriendly: a hero image sized for a 27 inch monitor that takes six seconds to load on a phone, a form with tap targets designed for a mouse, a menu with 30 items that folds into a scrolling list nobody reads. Responsive gets the layout to fit. Mobile friendly gets the page to work.
The way we hold ourselves to the second one is to design the phone screen first in Figma, then widen it. When the mobile layout is designed last, as a squashed version of a desktop layout, every compromise lands on the phone. When it is designed first, the desktop version is the one that gets extra room, which is the easy direction.
Every web case study on our site has an image of the build across three phone screens for this reason. It is not decoration; it is the version of the site that most visitors will ever see.
Text size. Body text under 16 pixels on a phone is read by zooming or not read at all. Line length matters too: a paragraph that runs edge to edge in a small font reads as a wall. We set the base size for the phone and let the desktop inherit it, not the other way round.
Tap targets. A thumb is about 10 millimetres wide. Buttons and links need at least 44 pixels of height with space between them, or people tap the wrong one and leave. The place this fails most is the footer, where a dozen links are stacked in 12 pixel type. The second place is the product listing, where the "enquire" button sits next to a "compare" link that nobody wants.
Forms. A phone form is typed on a keyboard that covers half the screen. So: fewer fields, the right keyboard for each field (numeric for phone, email keyboard for email), labels that stay visible, and error messages written next to the field they belong to, not in a red line at the top. Placeholder text is not a label, because it disappears the moment someone starts typing.
Images. Customers notice slowness before they notice quality. A product photo served at the size the phone needs (we generate WebP variants at four widths and let the browser pick) loads in a fraction of the time of the original. Customers also notice when the image they need, the specification label on a solar module or the close up of a switch, is missing on the phone version because someone decided phones did not need it.
Menus. A menu that works on a phone has few items, a clear close button, and does not trap the visitor. The back gesture should close it. If the site has 40 pages, the phone menu shows the six that matter and the rest live one level down.
The click rate gap we opened with is not caused by any one of these on our own site; it is a combination of which queries show on which device and what the result looks like on a phone. But every one of the five is something we check on client sites before launch, on a real phone, with the person who will run the site watching.
Do it on a real phone before any tool. Open the site on a mid range Android, not the newest iPhone in the office, on mobile data with WiFi off. Then work through the list: can you read the body text without zooming, can you tap every button in the header with a thumb, does the menu open and close cleanly, can you fill the contact form and see what went wrong if you leave a field empty, does the page jump while it loads, does the main image appear within a few seconds.
Then the tools. Lighthouse in Chrome DevTools, mobile mode, gives you the viewport, tap target and text size checks plus the Core Web Vitals lab numbers. PageSpeed Insights gives the field data for mobile, which is what Google actually uses. Search Console's Core Web Vitals report tells you which templates are failing across the whole site. And the device report in Search Console, under Performance, will show you your own version of our 2.3 against 8.4.
That last one is the check most owners skip. If your mobile click rate is far below desktop for the same queries, the mobile result is unattractive: the title is truncated on a narrow screen, the description does not answer the question, or the site has a reputation on that device. It is a design problem visible from the search results page, before the visitor has arrived.
Ask to see the phone version first. If a company presents a desktop mock up and says the mobile version will follow, the mobile version will be the squashed one. A company that designs mobile first will show you the phone screen and be glad you asked.
Ask how images are handled. The answer should mention WebP, several sizes per image, and the browser choosing. If the answer is "we compress them", the phone will download the desktop image.
Ask what they measure before launch. The answer should include Core Web Vitals on mobile and a test on a real phone on a throttled connection. Ask for the numbers from their last two launches.
Ask about forms. How are errors shown, which keyboard opens for the phone field, what happens after submit. Small questions, but they separate companies that have watched a customer use a form on a phone from companies that have not.
Ask who owns it. The design files, the code, the hosting account, in your name, so a different developer can maintain the mobile version later. This is how we hand over, and it is a fair thing to expect from anyone.
Nothing, if it is done from the start. A focused 5 to 10 page site at our studio is 2 to 4 weeks of design and a similar stretch of development, and the phone layout is part of that, not an add on. It adds time only when it is retrofitted to a site designed for desktop, because then every page needs its layout reconsidered and its images regenerated.
Three builds show what "the same site on a phone" has to cover. A solar module manufacturer's site carries a full electrical and mechanical specification for every product series, a datasheet download centre and a calculator, all of it usable on a phone because that is where installers look things up on site. A tile exporter's site runs in seven languages from one codebase, including an Arabic edition mirrored right to left, and the mirroring holds on a phone. A smart switch maker's product pages show the physical switch and the app together, which on a phone means stacking them in the right order. None of these were mobile versions of a desktop site.
No. A mobile friendly website runs in the phone's browser and needs no installation, which is what most businesses need. An app is installed from a store and makes sense only when the customer will use it repeatedly or needs the phone's hardware. Most companies asking for an app need a fast mobile website.
Google indexes the mobile version and uses mobile page experience as a signal, so a site that is unusable on a phone is at a disadvantage. But content still decides most of a ranking. A mobile friendly site with a thin page will not outrank a slower site with the better answer.
Sometimes. If the site is already responsive and the problems are images, fonts and tap targets, a few days of work fixes it. If the site was built for desktop with fixed widths, or on a page builder that generates heavy pages, a rebuild is usually cheaper than patching, and it is the moment to design the phone version first.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.