Does Your Website Need a Mobile Makeover?

A website is mobile friendly when someone can arrive on a phone, read what is on the page without pinching or zooming, tap what they intend to tap, and complete what they came to do. That is the whole standard. Everything below is how you find out whether your site clears it, and what to fix in what order when it doesn't.

Two things have changed enough since most advice on this topic was written that it is worth stating them up front. Google now crawls the web with a smartphone user agent, so the mobile version of your page is the version that gets indexed. And the tools most guides tell you to use for testing no longer exist.

What "mobile friendly" means in 2026

The phrase has quietly shifted meaning. It used to describe a pass/fail state that Google reported back to you. It now describes an outcome you have to evaluate yourself, across several separate signals.

Mobile-first indexing is finished, not coming

Google indexes the mobile rendering of your pages. If content, structured data or internal links appear on your desktop layout but are stripped out or hidden on mobile, Google's view of the page is the reduced one. This is the single most consequential fact about mobile in search, and it catches out sites that treat the mobile layout as a cut-down courtesy version.

The practical rule: whatever you want ranked has to be present in the mobile HTML. Not behind a "read more" that loads on tap — that is usually fine — but genuinely present in what a phone receives. Google's mobile-first indexing documentation spells out the parity requirements.

The tools you were told to use are gone

Google retired the Mobile-Friendly Test, the Mobile Usability report in Search Console, and the Mobile-Friendly Test API on 1 December 2023. If a guide tells you to "run the Mobile-Friendly Test," that guide predates the change and its other advice is probably stale too.

Google's stated replacement is Chrome Lighthouse, which is built into Chrome DevTools. There is no longer a single green "mobile friendly" badge to chase, which is a fair reflection of reality — mobile usability was never one binary property.

How to check your site properly

Use three checks together. Each catches things the others miss.

1. Lighthouse, for the technical faults

Open your page in Chrome, open DevTools, go to the Lighthouse panel, select the Mobile device setting, and run it. Read the Performance and Accessibility sections. Lighthouse runs a simulated mid-range phone on a throttled connection, which is closer to your real audience than your own laptop on office wifi.

Lighthouse gives you lab data — a controlled test, reproducible, good for debugging. It does not tell you what real visitors experience.

2. Core Web Vitals, for what real users get

The Core Web Vitals report in Search Console draws on field data from actual Chrome users on your site. It is the closest thing to ground truth you have. Three metrics matter, and the official thresholds are:

Metric	Measures	Good
LCP — Largest Contentful Paint	Loading: when the main content appears	Under 2.5 seconds
INP — Interaction to Next Paint	Responsiveness: lag between tap and visible response	Under 200 milliseconds
CLS — Cumulative Layout Shift	Visual stability: how much the layout jumps	Under 0.1

These are assessed at the 75th percentile of page loads, segmented by device. That last detail matters: your mobile scores are reported separately from desktop, and mobile is almost always the worse of the two. A site that looks fine in aggregate can be failing badly on phones.

Note that INP replaced FID in March 2024. If your monitoring still reports First Input Delay, it is measuring something Google no longer uses.

3. An actual phone, for everything else

No tool catches a form that is impossible to complete one-handed, or a date picker that fights the native keyboard, or a cookie banner that covers the primary button. Load your key pages on a real mid-range Android device, on mobile data rather than wifi, and try to complete your main conversion. Most sites reveal their worst mobile problem within ninety seconds of this test.

Responsive, dynamic serving, or a separate mobile site

There are three ways to serve mobile, and for almost every business the choice is already settled.

Approach	How it works	Verdict
Responsive design	One URL, one HTML document, CSS adapts the layout to the viewport	Google's recommended pattern. One page to maintain, no parity risk, no redirect logic. Default choice.
Dynamic serving	One URL, server returns different HTML based on user agent	Workable but fragile. User-agent detection misfires, and you must set the Vary: User-Agent header correctly.
Separate mobile site (m.example.com)	A parallel site on its own subdomain	Legacy. Doubles maintenance, splits signals, and creates exactly the content-parity problems mobile-first indexing punishes. Migrate away from it.

If you are still running an m. subdomain, consolidating onto a responsive build is usually the highest-value change available to you. It is worth understanding what responsive design actually is before commissioning that work, because the term gets used loosely.

What to fix, in order

Work down this list. It is ordered by how often each problem is the one actually costing you visitors.

Set the viewport meta tag

Without it, mobile browsers render your page at desktop width and shrink it, producing the zoomed-out postage-stamp effect. One line in the <head>:

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

Do not add user-scalable=no or cap maximum-scale. Blocking zoom breaks the site for anyone who needs to magnify text, and it is an accessibility failure as well as a usability one.

Make text readable without zooming

Body text at 16px or larger, line height around 1.5, and line lengths that do not run edge to edge. Contrast matters more on a phone than a monitor because people read outdoors in daylight — the WCAG minimum of 4.5:1 for body text is a floor, not a target. If you are revisiting this, the same reasoning applies to your wider palette and colour and contrast choices.

Size tap targets for fingers

Interactive elements need to be large enough to hit reliably and spaced far enough apart that you do not hit the wrong one. WCAG 2.2 sets a minimum of 24 by 24 CSS pixels; 44 by 44 is the more comfortable working figure most design systems use.

The classic failure is a row of small text links stacked tightly in a footer or a table. On desktop they are fine. On a phone they are a coin toss.

Stop the layout jumping

Layout shift is the problem people feel most and diagnose least. It happens when something loads after the initial render and pushes content down — an image without dimensions, a web font swapping in, an ad slot expanding, a banner injecting itself above the fold. The reader is mid-sentence, or mid-tap, and the page moves.

The fixes are unglamorous and effective: set explicit width and height attributes on images and video so the browser reserves the space; reserve space for anything injected later; use font-display: swap with a metric-compatible fallback so text does not reflow when the web font arrives.

Serve images at mobile size

Shipping a 2,400px hero image to a 390px-wide phone wastes bandwidth and delays LCP. Use srcset and sizes so the browser picks an appropriate file, serve modern formats such as WebP or AVIF, and lazy-load anything below the fold — but never lazy-load your LCP image, which is a common own goal.

Cut the JavaScript that blocks interaction

INP is usually a JavaScript problem. Long tasks on the main thread mean a tap registers but nothing visibly happens for hundreds of milliseconds, so the user taps again, and now they have double-submitted. Audit third-party scripts hardest — chat widgets, heat-map recorders, tag managers loaded with tags nobody remembers adding. Each one is a tax paid on every mobile visit.

Fix forms before anything else on conversion pages

Forms are where mobile sites lose money. Use the correct type and inputmode on every field so phones show the right keyboard — a numeric pad for phone numbers, an email keyboard for email. Add autocomplete attributes so browsers can fill saved details. Keep fields in one column. Cut every field you do not genuinely need, because each one costs completions.

Do not cover the content

Google has treated intrusive interstitials that obscure content on mobile as a negative signal for years, and users have treated them worse. A cookie notice that occupies half the screen, a newsletter modal that fires on arrival, and a chat bubble parked over the submit button are each doing measurable damage. Legally required notices are fine — make them proportionate.

Navigation on a small screen

Navigation is where desktop thinking survives longest, because a menu that works fine as a horizontal bar gets collapsed into a hamburger and quietly stops working. Three specific problems account for most of it.

Depth that a thumb cannot reach

A three-level dropdown becomes a three-tap accordion on mobile, and each tap is an opportunity to give up. If your mobile menu requires more than two taps to reach a main service or category page, the structure is too deep for the device. Promote your highest-traffic destinations to the top level of the mobile menu even if they sit deeper on desktop — the two menus do not have to mirror each other, they have to lead to the same places.

Reach, not just size

On a large phone held one-handed, the top corners of the screen are genuinely hard to reach. Controls that people use repeatedly — search, cart, back, primary action — benefit from sitting within the lower two-thirds of the viewport. This is why persistent bottom bars have become common on ecommerce and app-like sites; it is ergonomics rather than fashion.

Search that people can actually use

If your site has more than a few dozen pages, on-device search carries a disproportionate share of mobile navigation, because scrolling a long menu is tedious on a phone. Make the search field reachable without opening the menu, ensure it triggers the correct keyboard, and check that results are usable on a narrow screen — a results page that renders as a wide table is a dead end.

Test at 360px, not just at your phone's width

Set Chrome DevTools to a 360px-wide viewport and walk the site. That width still represents a large share of Android devices in India and is narrow enough to expose horizontal overflow, cramped tables and buttons whose labels wrap awkwardly. If the site holds together at 360px, wider phones are rarely a problem.

When the tools disagree with each other

You will eventually hit a case where Lighthouse reports a healthy score and the Core Web Vitals report says the page is failing, or the reverse. This is expected, not a bug, and the resolution is always the same: field data wins.

Lighthouse runs one simulated load on a defined device and connection. Core Web Vitals aggregates real sessions across your actual audience — older phones, worse networks, cold caches, and interaction patterns no synthetic test reproduces. When they diverge, the usual explanations are that real users are on slower hardware than the simulation assumes, that the tested page differs from the templates most traffic actually lands on, or that the problem is interaction-dependent and only appears once someone starts tapping.

A related trap is that Search Console groups URLs into similar-page cohorts. A failure attributed to one URL frequently belongs to the template behind it, which means the fix is usually one template change rather than a long list of individual pages. Check whether the flagged URLs share a layout before treating them as separate problems.

A checklist you can hand to a developer

• Viewport meta tag present, zoom not disabled
• Body text 16px or larger, contrast at least 4.5:1
• Tap targets at least 24×24 CSS px, adequately spaced
• No horizontal scrolling at 360px width
• Images have explicit dimensions and responsive srcset
• LCP image not lazy-loaded
• Space reserved for late-loading elements
• Fonts loaded with font-display: swap
• Forms use correct input types, inputmode and autocomplete
• No interstitial covering content on arrival
• Same content, structured data and internal links on mobile as desktop
• Core Web Vitals passing at the 75th percentile on mobile

Mistakes that keep recurring

Hiding content on mobile to "clean up" the layout. Under mobile-first indexing, content you hide from phones is content you have hidden from Google.

Testing only on a recent iPhone. Flagship hardware on good wifi hides both performance and layout problems. Test a mid-range Android on mobile data.

Treating a passing Lighthouse score as done. Lighthouse is lab data. Real users on real networks are what Core Web Vitals reports, and the two often disagree.

Chasing a performance score instead of a bottleneck. A number going from 61 to 68 means little. Identifying that a third-party script delays interaction by 400ms means a great deal.

When patching is not the answer

Sometimes the honest diagnosis is that the site cannot be made mobile friendly at acceptable cost. The signals are fairly clear: a fixed-width layout with no responsive foundation; a separate m. site that has drifted out of sync; a theme so heavily overridden that CSS changes break unrelated pages; or a stack where every fix creates two regressions.

In those cases, incremental patching costs more over two years than a rebuild does once. If that is where you have landed, it is worth reading how to plan the redesign properly so you do not lose your existing search visibility in the process — which is the most common way a well-intentioned rebuild goes wrong.

Where a rebuild is the right call and you would rather not run it in-house, our mobile website design services cover the audit, the rebuild and the migration, with the search-visibility side handled rather than hoped for.

Frequently asked questions

How do I test if my website is mobile friendly now that Google's tool is gone?

Use Chrome Lighthouse in DevTools with the Mobile setting for technical faults, the Core Web Vitals report in Search Console for what real users experience, and a physical mid-range phone on mobile data for anything a tool cannot judge. Google retired the Mobile-Friendly Test and the Mobile Usability report on 1 December 2023 and recommends Lighthouse in their place.

Does mobile friendliness affect Google rankings?

Yes, though not as a single switch. Google indexes the mobile version of your pages, so mobile content parity determines what can rank at all. Page experience signals including Core Web Vitals are used in ranking, and intrusive mobile interstitials are treated negatively. The larger effect is usually behavioural — a site people cannot use on a phone does not earn the engagement or conversions that sustain it.

Is responsive design enough on its own?

Responsive design solves layout. It does not by itself solve performance, tap target sizing, form usability or layout shift. A fully responsive site can still fail Core Web Vitals badly. Responsive is the foundation, not the finish line.

How long does it take to make a site mobile friendly?

It depends entirely on the starting point. Viewport, text sizing, tap targets and image dimensions are typically days of work on a reasonably built site. A fixed-width legacy site or an out-of-sync separate mobile site is a rebuild, measured in weeks.

Should I build a separate mobile site?

No. Separate mobile sites double maintenance, split your signals across two URLs and create the content-parity problems that mobile-first indexing penalises. Responsive design on a single URL is Google's recommended configuration and the right default.

Where to start

If you do one thing after reading this: open your highest-value page on a real phone, on mobile data, and try to complete whatever action that page exists to produce. Note where you hesitate, mistap or wait. That list, in that order, is your actual priority list — and it will usually be shorter and more specific than anything a scanning tool hands you.