How to make a website mobile-friendly: viewport, layout, text and tap targets

To make a website mobile friendly, you need five things: a viewport meta tag, a layout that shrinks to any screen without sideways scrolling, body text of about 16 px, links and buttons big enough for a thumb, and the same content on phones as on desktop, loaded fast on a mobile connection. This guide is for site owners, marketers and the developers they work with. It walks through each of those in the order that fixes the most, shows how to check your own pages now that Google's Mobile-Friendly Test is gone, and points to the detailed guide for each step.

Quick answer

• Add the viewport tag to every page: <meta name="viewport" content="width=device-width, initial-scale=1">. Without it, phones render the page at desktop width and shrink it.
• Let the layout flow. Use percentage and flexible widths, CSS grid or flexbox, and max-width: 100% on images, videos and embeds, so nothing is wider than a 360 px screen.
• Keep text readable: about 16 px for body text, and at least 16 px in form fields so iOS Safari does not zoom in when someone taps them.
• Make tap targets at least 24 × 24 px (the WCAG 2.2 minimum), 44–48 px for main buttons and menu items, with space between neighbours.
• Never disable zoom. Leave user-scalable=no and maximum-scale=1 out of the viewport tag.
• Serve phones the same content, structured data and links as desktop. Google indexes the mobile version of every site.
• Test at real widths: run the free mobile-friendly test, which renders the page at 360, 414, 768, 1024 and 1440 px, then open the page on your own phone.

What makes a website mobile friendly?

A mobile-friendly website is one a visitor can read and use on a phone without zooming, panning sideways or mis-tapping. There is no official certificate any more; since Google retired its test, "mobile friendly" simply means the page works on a small touch screen. In practice, eight properties decide it:

The first four are layout problems and are usually fixed in CSS in an afternoon. Speed and content parity take longer, because they depend on how the site is built.

Why mobile-friendliness matters

On most sites, phones bring more visitors than desktops, and those visitors decide within seconds whether a page is usable. A page they have to zoom and pan loses them to the next search result, whatever its rankings.

For Google, the mobile version is the only one that counts. Mobile-first indexing means Googlebot crawls and indexes pages with its smartphone crawler and ranks them on what it finds there. Google announced in October 2023 that the move was complete, and on its Search Central blog said that after 5 July 2024 the last sites still crawled as desktop would be crawled as mobile too, and that sites not accessible on mobile devices would no longer be indexed. Anything missing on your mobile pages is missing for Google.

Google's own tooling changed at the same time. On 1 December 2023 Google retired the Mobile-Friendly Test, its API and the Mobile Usability report in Search Console, and pointed site owners to Lighthouse instead. There is no longer a "mobile-friendly" label to win. Google's page experience documentation still asks whether "your content display[s] well on mobile devices", alongside Core Web Vitals, HTTPS and avoiding intrusive interstitials, so the question has not gone away; only the pass/fail badge has.

Is my website mobile friendly? How to check

Start with an automated render, then confirm on a real phone. The tool below loads your page once in Chromium and resizes it to five widths, from a small phone to a desktop:

At each width it takes a screenshot and measures three things: whether anything is wider than the screen (and which element), how many pieces of text are smaller than 12 px, and how many links and buttons are smaller than 24 × 24 px. The full report adds the viewport and zoom checks:

A resized desktop browser is close to a phone but not identical: it has no on-screen keyboard, no browser toolbar taking up space, and a mouse instead of a thumb. So also:

1. Open the page on your own phone, in portrait and landscape. Try the menu, a form and the checkout, not just the home page.
2. Use your browser's device mode (Chrome or Edge DevTools, Ctrl+Shift+M / Cmd+Shift+M) to see the page at 360 px and step through widths.
3. Check field data: the Core Web Vitals report in Search Console, or the Core Web Vitals checker, shows how fast the page is for real mobile visitors.

Test your templates rather than every page: the home page, one article, one product or service page, a category page and a form. Most mobile problems live in a template and repeat on every page built from it.

Step 1: Add the correct viewport meta tag

The viewport tag tells the phone to lay the page out at its own width instead of pretending to be a 980 px desktop. It is one line, and there is one right value:

<!-- in <head>, once per page -->
<meta name="viewport" content="width=device-width, initial-scale=1">

Two common additions do harm: user-scalable=no and maximum-scale=1 stop people zooming in to read small text. Chrome on Android honours them; iOS Safari ignores them. They are usually added to stop iOS zooming into form fields, and that has a better fix (Step 5).

Our guide on the viewport meta tag and why never to disable pinch-zoom covers the full tag, where WordPress themes and plugins set it, and how to test the page at 200 % and 400 % zoom. The fix pages for a missing viewport tag and disabled zoom give the short version.

Step 2: Build a responsive layout

Responsive web design means one HTML page whose layout adapts to the screen with CSS: columns stack on phones, images scale down, navigation collapses. It has been the default approach for more than a decade, and it is what Google recommends, because one URL and one version serve every device and there is nothing to keep in sync for mobile-first indexing.

The alternatives are adaptive layouts, which jump between a few fixed designs and break on the sizes nobody planned for, and a separate mobile site on m.example.com, which doubles the work and needs canonical and alternate annotations between every pair of pages. If you still run an m-dot site, moving to one responsive site is usually the best mobile project you can do.

Most of a responsive layout comes from a few lines: max-width: 100% on images, videos and embeds, a container that never exceeds the screen, and grid or flexbox that wraps by itself:

/* your main stylesheet */
img, video, iframe, svg { max-width: 100%; height: auto; }
.cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(min(16rem, 100%), 1fr)); gap: 1rem; }

Responsive web design: what it is, how it works, and responsive vs adaptive explains the five ingredients from the viewport tag to container queries, the common layout patterns with shop examples, how Google treats responsive, dynamic serving and separate mobile URLs, and how to test the result.

Step 3: Choose breakpoints from your content

Media queries switch a layout at a given width, and those widths are your breakpoints. The common mistake is to pick them from a list of devices; devices change every year, and the widths between them still exist. Set a breakpoint where your layout starts to look wrong, write the phone layout first and add to it with min-width queries, and use em or rem so breakpoints move when a visitor enlarges their default font size.

Know where real screens are, though: in StatCounter's August 2026 data most phones are 360 to 414 CSS px wide in portrait, tablets start at 768 px and the most common desktop resolution is 1920 × 1080. Whatever breakpoints you choose, test at 360 px (the narrowest width the getReport tool renders), 414, 768, 1024 and 1440 px.

Media queries and breakpoints: which screen sizes to design for covers the syntax and range syntax, the media features worth using, min-width versus max-width, px versus em, the full screen-resolution table and a step-by-step way to choose breakpoints.

Step 4: Stop sideways scrolling

A page that scrolls sideways on a phone is almost always caused by one element that is wider than the screen. The usual suspects:

• a data table or pricing table with a fixed width;
• an image, video or iframe (maps, embedded posts) without max-width: 100%;
• a long URL, email address or product code that cannot wrap;
• an element set to width: 100vw, which includes the scrollbar width on desktop;
• a negative margin or an off-screen menu that is not clipped.

The fixes are just as short. Let media shrink, wrap tables in a scrolling box, and let long strings break:

.table-wrap { overflow-x: auto; }      /* <div class="table-wrap"><table>…</table></div> */
p, li, td { overflow-wrap: anywhere; } /* long URLs and codes break instead of overflowing */

The sideways-scrolling check names the element that sticks out at each width, with the number of pixels, so you know which one to fix. The fix page on horizontal scrolling on mobile has more causes and fixes. WCAG 1.4.10 (Reflow) sets the same bar for accessibility: content must work at 320 CSS px wide without scrolling in two directions, which is also what someone zooming a desktop browser to 400 % sees.

Step 5: Make text readable on phones

Body text of 16 px is the common baseline for phones. It is also the threshold iOS Safari uses for form fields: if an input's font size is below 16 px, Safari zooms the page when the field is tapped, which is the real reason many sites disable zoom. Set inputs to 16 px and the zoom stops without taking anything away from visitors:

html { font-size: 100%; }              /* respect the visitor's setting, 16 px by default */
body { font-size: 1rem; line-height: 1.5; }
input, select, textarea { font-size: max(16px, 1rem); }

h1 { font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem); } /* fluid heading size */

clamp() gives fluid type: the heading grows with the screen but never below or above the limits you set. Keep small print (captions, footers, legal text) at 12 px or more; the getReport render counts text under 12 px at each width. Line length matters too: 45–75 characters per line reads well, which on a phone happens by itself and on a desktop needs a max-width on the text column.

Our guide to responsive font size with rem and clamp() has a size table for phones and desktops, shows how to calculate a clamp() value and build a fluid type scale, and explains how to keep fluid type zoomable so it passes WCAG 1.4.4.

Step 6: Size tap targets for thumbs

A 16 px icon is fine for a mouse and a gamble for a thumb. WCAG 2.2 success criterion 2.5.8 (Target Size, Minimum) asks for at least 24 × 24 CSS px per target, or enough spacing that a 24 px circle around each target does not overlap its neighbours. Platform guidelines go further: Apple's Human Interface Guidelines recommend 44 × 44 pt, and Material Design recommends 48 × 48 dp. Use 24 px as the floor for everything and 44–48 px for the actions that matter: menu items, Add to cart, form buttons.

Grow the tap area with padding rather than a larger font, so the design barely changes:

.icon-button { min-width: 44px; min-height: 44px; display: inline-grid; place-items: center; }
.footer-nav a { display: inline-block; padding: 0.5rem 0.25rem; }

Links inside a sentence are an exception in WCAG, and the getReport measurement skips inline links in paragraphs and list items. Our guide on the 24 × 24 pixel target-size rule and its exceptions covers the rule, the exceptions and the CSS for icon rows, pagination and social links. The target size fix page is the two-minute version.

Step 7: Make it fast on a phone

A layout that fits is only half of mobile-friendly; it also has to arrive quickly on a mid-range phone and a mobile connection. Speed tests show this bluntly: the mobile score is usually 20 to 40 points below desktop, because the mobile run simulates a slower CPU and network. Our guide on why mobile scores are lower than desktop explains what is simulated and what closes the gap.

The biggest mobile win on most sites is images. A 2,000 px hero photo sent to a 400 px screen wastes most of its bytes. srcset and sizes let the browser pick the right file for each screen; the guide to responsive images with srcset and sizes works through a real example. After images come render-blocking CSS and JavaScript, web fonts and third-party scripts.

For the numbers Google uses, Largest Contentful Paint should be 2.5 s or less, Interaction to Next Paint 200 ms or less and Cumulative Layout Shift 0.1 or less, measured for real visitors at the 75th percentile. Our guide to Core Web Vitals for site owners covers all three.

Step 8: Design mobile-first

Mobile-first design means designing the phone layout first and adding to it for bigger screens, rather than squeezing a desktop design down. It forces the right decisions early: what the one main action on the page is, which content comes first when there is room for only one column, and which elements earn their space at all.

A few rules make most mobile-first designs work:

• Put the main content and the main action in the first screen. On a phone that is about 600–700 px of height after the browser toolbar.
• Keep navigation simple: a short menu behind a clearly labelled button, with the two or three most important links visible.
• Use forms that suit thumbs: one column, labels above fields, and the right input types (type="email", type="tel", inputmode="numeric") so the phone shows the right keyboard.
• Avoid full-screen pop-ups on arrival. Google's page experience guidance asks you to avoid intrusive interstitials; a cookie banner or a small banner is fine, a newsletter overlay that hides the content on the first tap is not.

Our guide to mobile-first design: content priority, layout and speed goes through the process step by step: ranking content into the phone layout, designing the first screen and the navigation for thumbs, a phone-first stylesheet with min-width queries, and setting a speed budget before the first mockup.

Mobile-first indexing: what Google checks on your mobile pages

Google crawls and indexes every site with its smartphone crawler, and ranks each page, on desktop results too, by what the mobile version contains. That makes parity an SEO requirement: the same main content, headings, internal links, structured data, titles, meta descriptions and robots tags on mobile as on desktop. Text collapsed in tabs or accordions is indexed; text removed from the mobile HTML, or loaded only after a tap, is not.

A responsive site gets parity almost for free, because every device receives the same HTML. The risks are page builders that swap in shortened mobile sections, scripts that remove content below a breakpoint, a thinner mobile menu, and separate m-dot sites that need rel="alternate" and rel="canonical" on every pair of pages.

Our guide to mobile-first indexing and what Google reads on your mobile pages goes through each of Google's best practices, shows how to confirm which crawler fetched a page in Search Console, how to compare mobile and desktop HTML with device mode and the JavaScript rendering checker, and how to fix the common gaps.

Platform notes

• WordPress: nearly every current theme is responsive and prints the viewport tag. Problems usually come from content: tables pasted from spreadsheets, fixed-width embeds, and page-builder sections with fixed widths. Elementor, Divi and other builders have per-device settings; use them to adjust spacing and font size, and be careful with "hide on mobile", which hides a section but still loads it.
• Shopify: themes from the Theme Store are responsive. Check apps that inject pop-ups, sticky bars and chat widgets, which are the usual cause of overlapping elements and small tap targets on phones.
• Wix and Squarespace: layouts are responsive or have a dedicated mobile editor. Check the mobile view of every page you edit, since changes in one view do not always carry over as you expect.
• Custom sites and frameworks: start from the CSS in Steps 2–6, and add the five widths to your visual or end-to-end tests so a new component cannot reintroduce sideways scrolling.

How to verify your fixes

1. Re-run the mobile-friendly test on each template. The target: no sideways scroll from 360 to 1440 px, no text under 12 px, no tap targets flagged.
2. Open the same pages on a real phone, in portrait and landscape, and complete one real task: submit a form, add a product to the cart.
3. Zoom a desktop browser to 400 % at 1280 px wide; the page should reflow into one column with nothing cut off.
4. Run a speed test on the mobile setting and compare with your previous score.
5. After four weeks, check the Core Web Vitals report in Search Console for mobile URLs; field data covers the last 28 days, so improvements take that long to show fully.

Common mistakes

• Testing only the home page. Product pages, blog posts with tables and forms are where layouts break.
• Disabling zoom to stop iOS input zoom. Set form fields to 16 px instead.
• Hiding content on mobile instead of adapting it. Hidden sections still download, and removed content is not indexed.
• Building breakpoints around specific devices. Design for the widths between devices too.
• Fixing layout and ignoring weight. A page that fits the screen but loads 6 MB is not mobile friendly on a train.
• Full-screen pop-ups on the first visit. They block the content Google and your visitor came for.

Questions people ask

Is my website mobile friendly?

Your website is mobile friendly if it has a viewport tag, fits a 360 px screen without scrolling sideways, uses readable text, has tap targets of at least 24 px and loads quickly on a phone. Test it with the free getReport mobile-friendly test, which renders the page at five widths and names any element that breaks the layout, then try the menu and forms on your own phone.

What is the difference between a mobile friendly and a responsive website?

A responsive website is one way to be mobile friendly: the same page rearranges itself with CSS for every screen width. Mobile friendly describes the result, a page that is easy to read and use on a phone, however it is built. A separate mobile site can be mobile friendly without being responsive, but it is harder to maintain and to keep equal to the desktop version.

Can I make an existing website mobile friendly without rebuilding it?

Often, yes. Adding the viewport tag, making images and embeds shrink with max-width: 100%, wrapping wide tables in a scrolling box and enlarging small text and buttons can be done in the existing stylesheet. A rebuild is worth it when the layout is built on fixed-width tables or frames, or when the site runs a separate mobile version you would rather retire.

How do I make my WordPress site mobile friendly?

Start with a responsive theme; most current themes are, and they print the viewport tag for you. Then fix content: wrap wide tables, let embeds shrink, and in your page builder use the tablet and mobile settings for spacing and font size rather than hiding sections. Test the home page, a post and a product or contact page at phone widths after each change.

Why does my website look different on my phone than on my computer?

Because a phone renders the page at a width of about 360 to 430 CSS pixels, and your CSS decides what happens at that width. With a viewport tag and responsive CSS, columns stack and images shrink on purpose. Without the viewport tag, the phone shows a shrunken desktop page; with fixed widths, parts spill off the screen. Render the page at phone widths to see which element causes it.

Do I need a separate mobile site or an app to be mobile friendly?

No. One responsive website serves phones, tablets and desktops from the same URLs, and it is what Google recommends. A separate mobile site means two versions to keep equal plus extra canonical tags, and an app does not replace a website that people find in search. Build an app only for features that need one, such as offline use or push notifications.

Does a mobile friendly design have to be fast as well?

Yes. A layout that fits the screen but takes six seconds to show its main content still loses most phone visitors, and Google measures Core Web Vitals on real mobile devices. Aim for Largest Contentful Paint within 2.5 s: send images at the size the phone displays, cut unused scripts, and check the mobile score in a speed test, not only the desktop one.