Mobile Friendly Website Design: A UK Business Guide

A mobile friendly website is one a customer can read, navigate and buy from with one thumb, on a phone, on mobile data, without pinching, zooming or waiting. For UK businesses that is now the commercial floor, and the tools most guides tell you to test it with no longer exist.

Mobile friendly is a commercial threshold, not a technical one

The majority of UK web sessions now happen on a phone, and Google has indexed the mobile version of your site by default since it completed the switch to mobile-first indexing for every site on the web. That combination changes what "mobile friendly" means. It used to be a technical box to tick at the end of a build. It is now the version of your business that Google reads and the version most of your customers ever see. A site that works on a 27-inch monitor and struggles on a 6-inch screen is not a site with a mobile problem, it is a site with a revenue problem that happens to show up on mobile first. The technical vocabulary (fluid grids, flexible media, CSS media queries) matters far less than the outcome: your site has to work the first time, on whatever device the customer happened to pick up. Our web design work treats that as a starting condition rather than a feature to quote for separately.

What mobile friendly website design actually involves

Six things separate a site that genuinely works on a phone from one that merely shrinks. They are not independent. A site can pass five and still lose the sale on the sixth, which is why "it looks fine on my phone" is not a test.

One codebase, every screen

A responsive site serves a single HTML codebase that rearranges itself according to viewport width. There is no separate "m." mobile site to maintain, no duplicate URLs splitting your ranking signals, and no risk of the mobile and desktop versions drifting out of sync. One content change lands everywhere at once.

Fluid grids and flexible media

Layouts use proportional units and modern CSS (rem, fr, clamp(), grid and flexbox) rather than fixed pixel widths. Images and embeds scale inside their containers with max-width: 100%, so text reflows and nothing forces a horizontal scrollbar. Horizontal scroll on a phone is the single most reliable sign that a site was never tested on one.

Breakpoints driven by the design, not the device

Media queries reshape the layout at defined widths. The common values sit near 480px, 768px, 1024px and 1280px, but the right breakpoints are the widths at which your own design starts to break, not a list of device categories copied from a framework. Devices change every year. Where your layout fails does not.

Mobile-first build order

The smallest-screen layout is the default and larger-screen styles are layered on top. Building in that order forces a real content hierarchy (you cannot hide a weak value proposition behind a wide hero image), keeps the initial CSS payload small, and produces faster mobile load times, which feed directly into Core Web Vitals.

Touch targets and thumb reach

Interactive elements need to be big enough to hit and far enough apart to hit accurately. WCAG 2.2 sets 24 by 24 CSS pixels as the AA minimum, while Apple's interface guidance recommends 44 by 44 points and Google's Material guidance 48 by 48. Aim at the higher figures. Also check reach: the primary action should sit where a thumb naturally lands, not in a top corner.

Performance as part of the design

Mobile friendly does not mean shipping the desktop payload to a phone. Use srcset and sizes so each device downloads a correctly sized image, lazy-load anything below the fold, inline critical CSS and defer the rest. The target is Largest Contentful Paint under 2.5 seconds on a mid-range handset over 4G, which is the threshold Google classes as good.

Google retired the Mobile-Friendly Test: what to use instead

This is the part most articles on this subject still get wrong. On 1 December 2023 Google retired Search Console's Mobile Usability report, the Mobile-Friendly Test tool and the Mobile-Friendly Test API together, noting in its announcement on the original tool's page that more capable resources had emerged in the decade since, Lighthouse among them. Google was explicit that retiring the report does not make mobile usability less important. It only means the old one-click verdict is gone.

Plenty of guides published since still tell you to "run Google's Mobile-Friendly Test", and plenty of people still search for it. If you have been sent that advice, here is the current replacement set:

• Lighthouse, in Chrome DevTools. Google's own recommended successor. Open DevTools, choose the Lighthouse panel, select the Mobile device preset and run it. You get performance, accessibility and best-practice scores plus a specific list of failures, which is considerably more useful than the pass/fail badge it replaced.
• PageSpeed Insights. The same Lighthouse engine in a web page, with the advantage that it also shows Core Web Vitals field data from real Chrome users on your site where enough traffic exists. Lab data tells you what could go wrong, field data tells you what is going wrong.
• The Core Web Vitals report in Search Console. This one was not retired. It reports real-user LCP, INP and CLS split by mobile and desktop, which is now the closest thing Search Console has to a mobile usability signal.
• Chrome DevTools device mode. Useful for quick layout checks at specific widths, but it emulates screen size only. It does not reproduce touch accuracy, real network conditions or device thermal throttling.
• Actual handsets. Still the only test that catches the things that cost you money: a form that triggers the wrong keyboard, a sticky header eating a third of the screen, a cookie banner that cannot be dismissed one-handed.

The practical upshot is that mobile-friendliness is no longer a binary. There is no badge to earn. There is a set of measurements, and a site is as mobile friendly as those measurements say it is.

How to test whether your site is genuinely mobile friendly

Run this on your own site, on a phone, on mobile data rather than office wifi. It takes about twenty minutes and it finds most of what matters.

1. Run Lighthouse in mobile mode against your homepage and your most commercially important page. Note the performance score, the Largest Contentful Paint figure and any flagged tap-target or contrast failures.
2. Check the viewport meta tag. View source and search for <meta name="viewport". It should read content="width=device-width, initial-scale=1". Missing, or set to a fixed pixel width, means the site is not responsive at all. This is a thirty-second check that still catches older builds.
3. Look for horizontal scroll. Swipe sideways on every key page. Any movement means an element is overflowing its container, usually a table, a wide image or an embedded map.
4. Complete your own enquiry or checkout form one-handed. Time it. Note every field that resisted you and whether the phone field brought up a numeric keypad and the email field an email keypad.
5. Test on three real devices. An iPhone, an Android handset and a tablet cover the overwhelming majority of a typical UK audience. Borrow them if you have to.
6. Compare mobile and desktop conversion rate in GA4. Segment by device. If mobile sessions convert at a materially lower rate than desktop on the same pages, the gap is a user-experience problem, not a traffic-quality problem.
7. Check the Core Web Vitals report in Search Console for the mobile URL group. Field data over 28 days beats any single lab test.

Mobile friendly, responsive and adaptive: the difference that matters

These three terms get used interchangeably and they are not the same thing, which matters when you are reading a quote.

• Mobile friendly is the outcome: the site is usable on a phone. It says nothing about how that was achieved.
• Responsive is the modern method: one fluid layout that flexes continuously to any viewport width. This is what you should be buying.
• Adaptive serves one of several fixed layouts chosen by detected screen size. It works, but it fails on widths nobody anticipated and it is more expensive to maintain.
• A separate mobile site (the old m.example.com pattern) splits your content across two URL sets and divides ranking signals between them. It is legacy, and if you still have one, consolidating it is usually the highest-value technical SEO job on your list.

If a proposal says "mobile friendly" without saying "responsive", ask which method is being quoted. The answer changes both the build cost and the five-year maintenance cost.

How mobile friendly design affects your Google rankings

Google crawls, evaluates and ranks the mobile version of your site, including for searches made on a desktop. If content, structured data or internal links are missing from your mobile layout, they are effectively missing from the version Google ranks. Collapsing content behind accordions is fine (Google renders it), but removing it from the mobile template entirely is not.

Beyond indexing, the compounding benefits are structural rather than mysterious. A single URL per page concentrates every backlink and authority signal on one ranking entity instead of splitting it. One optimised payload loads faster than two maintained ones. Core Web Vitals thresholds (Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1) are measured on real visits, and the mobile figures are usually the weakest, so mobile work lifts the metric that was dragging. Across the client accounts we manage, the sites that gain most from a mobile rebuild are rarely the ones with the worst content. They are the ones whose content was already good and was being read through a broken window. Responsive testing belongs as a fixed item on every website audit checklist, not as a one-off at launch.

How mobile friendly design affects conversion

The conversion case is more direct than the SEO case, and it is where the money actually is. A pinch-to-zoom layout tells a visitor the business has not thought about them. A form that will not accept thumb-typing gets abandoned at the second field. A button too small to tap accurately gets tapped twice, and the second tap often lands on something else. None of that friction has anything to do with your offer, your pricing or your reputation, which is what makes it so expensive: you are losing customers who had already decided they were interested.

The pattern we see most often is a large gap between desktop and mobile conversion rates on identical pages, and it almost always traces back to the same short list: form length, tap target size, a cookie or chat overlay covering the call to action, or a hero section that pushes the primary action below three screens of scroll. Fixing those is conversion rate optimisation work rather than design work, and it is usually cheaper than a rebuild. If you sell online, our ecommerce website redesign playbook covers mobile checkout specifics, and how web design drives conversion rates goes further into the mechanics.

When to retrofit and when to rebuild

Plenty of older sites can be made mobile friendly with targeted CSS and template work. There is a point, though, where retrofitting costs more than starting again. The signals are consistent: the site is more than five years old, it runs on a discontinued theme or page builder, its mobile Core Web Vitals are failing across most URL groups, or every fix you make breaks something else because the CSS has no coherent structure underneath it.

Treat the decision commercially rather than aesthetically. Three questions settle it. How much organic traffic is the mobile experience costing you each month, given Google ranks that version? How much conversion is it costing, measured as the gap between your mobile and desktop rates on the same pages? And how many hours a month does the current site consume simply to keep working? The first two are recoverable revenue and the third is a running cost. If recoverable revenue clears the rebuild cost inside about twelve months, rebuild. If it does not, retrofit the specific failures and spend the difference on traffic. Our roundup of common web design mistakes covers the failures worth fixing first.

What mobile friendly website design costs in the UK

For a content-led brochure site, expect £3,000 to £8,000 for a properly responsive custom build on a modern CMS such as WordPress. Lead-generation sites carrying booking systems or service-area logic sit around £6,000 to £15,000. Ecommerce builds, where mobile checkout, payment wallets and product-grid behaviour all need separate attention, typically run £8,000 to £30,000 depending on catalogue size and integrations. Our full UK website cost guide breaks down what sits in each band.

Below about £2,000 you are generally buying a template with limited device testing. It will photograph well and fail on real hardware. The question worth asking a prospective supplier is not "is it responsive" (everyone says yes) but "what will you show me at handover?" A credible answer names the evidence: Lighthouse mobile scores before and after, the devices tested on, and the Core Web Vitals figures you are being handed. That is the difference between a site that was made responsive and one that was built to perform.

Frequently asked questions