How to Make a Website Mobile Friendly

A mobile-friendly site loads fast on a phone, fits the screen without zooming, has tap targets a thumb can hit, and lets a visitor call, book or buy in two taps; those four outcomes are the whole job. The 15-item checklist below gives each a pass mark, a one-minute test and a fix.

A site built for a desktop monitor can lose a phone visitor within seconds. The text needs pinching, the menu button is too small to hit, the phone number will not dial, and a pop-up covers the one thing they came to find. Each failure costs an enquiry, and your analytics rarely shows which one did it.

The timing matters. Google indexes and ranks the mobile version of your pages, and the Core Web Vitals now measure responsiveness with Interaction to Next Paint, so speed advice still built around First Input Delay is out of date.

The checklist below breaks the work into 15 checks across four phases: layout basics, mobile site speed, the path to a call or booking, and how Google sees your mobile version. Each item has a pass mark, a test you can run on your own phone in under a minute, and the fix. After the checklist come platform notes for Webflow, WordPress and Shopify, the signs that a site needs a rebuild instead of more patches, and a summary table you can copy.

How do I check the mobile basics in ten minutes?

Five layout checks catch the problems a phone visitor notices first, and you only need your phone and a desktop browser to run them. Fix any failure here before moving on to speed, because a fast page that does not fit the screen still loses the visitor.

For the desktop checks, open Chrome DevTools and switch on device mode (the device toolbar), which lets you view the page at a phone's width. Keep your own phone beside you for the rest.

1. The viewport meta tag is present.
   • Why: Without it, a phone renders the page at desktop width and shrinks it, so everything looks tiny.
   • Check: View the page source on desktop and search for "viewport". The tag should set the width to device-width.
   • Fix: Add the standard viewport meta tag inside the head. Webflow, Shopify and current WordPress themes include it, so if it is missing, an old theme or a custom template has dropped it.
2. Body text reads without zooming, at 16px minimum.
   • Why: Text below that size makes visitors pinch to read, and Safari on iPhone zooms into form fields set below 16px.
   • Check: Read a paragraph on your phone at a normal distance. In device mode, inspect a paragraph and read its computed font size.
   • Fix: Set the base body size to 16px in the theme or style settings and size headings from it. Check form inputs and buttons too, since they often carry their own font size.
3. Tap targets are at least 44 by 44 pixels, with space between them.
   • Why: Links packed close together cause missed taps and wrong pages, especially in menus and footers.
   • Check: Tap every menu item, button and footer link with your thumb, one-handed. In device mode, inspect a button to see its box size.
   • Fix: Add padding so the tappable area reaches 44 by 44 pixels even when the label is small, and add a gap between neighbouring links. Stacked footer links and inline text links are the usual offenders.
4. No horizontal scroll at 375 pixels wide.
   • Why: Sideways scroll means one element is wider than the screen, and the whole page looks broken.
   • Check: In device mode, set the width to 375 and try to scroll right. On your phone, swipe left across the middle of the page.
   • Fix: Find the element pushing past the edge: usually a fixed pixel width, a wide table, an embedded map or video, or a long unbroken URL. Swap fixed widths for fluid ones that cannot exceed their container, put wide tables in their own scrollable container, and let long words wrap.
5. Images are sized, compressed and lazy loaded below the fold.
   • Why: Full-size uploads waste a phone's data and slow down the first screen.
   • Check: Run the page through PageSpeed Insights on the Mobile tab and read the image diagnostics. In DevTools, the Network tab filtered to images shows each file's weight.
   • Fix: Export images at the size they display, serve WebP or AVIF, and use responsive image markup (srcset) so a phone gets a file sized for its screen. Add native lazy loading to images below the fold, but never to the hero image, because that delays the main content.

How do I fix mobile speed and Core Web Vitals?

Mobile site speed comes down to three Core Web Vitals plus the way your fonts load. Google publishes a pass mark for each metric, and you can verify all of them in PageSpeed Insights and Search Console.

Google's web.dev guidance defines the three metrics as loading (Largest Contentful Paint), interactivity (Interaction to Next Paint) and visual stability (Cumulative Layout Shift), with the thresholds listed in the steps below. PageSpeed Insights shows field data from real Chrome users for a single URL when the page has enough traffic, plus a lab test. The Core Web Vitals report in Search Console groups your URLs as Good, Needs improvement or Poor, with separate mobile and desktop views, so you can see which page types fail.

6. Largest Contentful Paint (LCP) within 2.5 seconds on mobile.
   • Why: LCP marks when the main content, usually the hero image or headline, appears. It is the moment a visitor feels the page has loaded.
   • Check: In PageSpeed Insights, on the Mobile tab, read LCP in the field data. The diagnostics name the element that counts as the LCP.
   • Fix: Compress and correctly size the hero image, take lazy loading off it, and give it a high fetch priority. Defer scripts that block rendering, and serve the site through a CDN.
7. Interaction to Next Paint (INP) of 200 milliseconds or less.
   • Why: INP measures how quickly the page responds to taps, and a menu that hangs after a tap feels broken.
   • Check: Read INP in the PageSpeed Insights field data or the Search Console report. Lab tests cannot measure it directly, so treat Total Blocking Time in the lab report as a stand-in.
   • Fix: Remove third-party scripts you no longer use (old chat widgets, heatmaps, duplicate trackers), defer the rest, and break long JavaScript tasks into chunks.
8. Cumulative Layout Shift (CLS) of 0.1 or less.
   • Why: When content jumps during load, the button under a visitor's thumb moves and they tap the wrong thing.
   • Check: Reload the page on your phone and watch the first screen. PageSpeed Insights reports CLS and names the elements that shifted.
   • Fix: Give every image, video and embed width and height attributes or an aspect ratio so the browser reserves space. Load cookie notices and promo banners as overlays pinned to the bottom, never injected above content after the page draws.
9. Fonts load with font-display: swap.
   • Why: Without it, a browser can hide text while a web font downloads, which leaves a phone on a weak signal looking at a blank page.
   • Check: Search your CSS @font-face rules for font-display, or look for a font-display warning in PageSpeed Insights.
   • Fix: Add font-display: swap to each @font-face rule, or add the display=swap parameter to a Google Fonts link. Load only the weights you use, and pick a fallback font with similar proportions so the swap itself does not shift the layout.

Scores drift as scripts, plugins and images pile up. Re-test after every major content change, or make these checks part of a regular website care plan.

How do I make a phone visitor actually call or book?

Put the next step one tap away from any screen: a phone number that dials, a call or book button that stays in reach, and a form that takes seconds. Then clear away anything that covers the page, starting with full-screen pop-ups.

The goal is a two-tap path from landing to enquiry. Our mobile-first Webflow build for CLG Injury Law, a firm with six offices, was designed around mobile intake. The four steps below are the parts of that path you can audit on any site.

10. Click-to-call phone number and a sticky call or book button.
    • Why: A visitor ready to act wants to dial or book from where they are, not scroll back up to hunt for a number.
    • Check: On your phone, tap the number in the header and footer; each should open the dialler. Scroll to the bottom of a long page and confirm a call or book button is still on screen.
    • Fix: Wrap every phone number in a tel: link that includes the country code, and list each office's number if you have several locations. Add a slim bar pinned to the bottom of the screen with Call and Book buttons, inside the thumb zone and small enough to leave the content readable.
11. Forms use the right keyboards and have no more than five fields.
    • Why: A phone field that opens a full keyboard, or a form that asks for everything at once, loses enquiries.
    • Check: Fill in your own form on your phone. The phone field should open a number pad and the email field should show the @ key.
    • Fix: Use type="tel" for phone, type="email" for email, and inputmode="numeric" only for digit-only fields. Canadian postal codes mix letters and digits, so leave that field as text. Add autocomplete attributes so the phone can fill in name, email and phone, and cut to five fields by asking the rest after first contact.
12. Navigation works with a thumb.
    • Why: Long menus, nested dropdowns and hover-only menus are hard to use one-handed, and touch screens have no hover.
    • Check: Holding the phone in one hand, reach your main service page and your contact page from the home page using only your thumb.
    • Fix: Trim the menu to the top-level pages people actually use, keep the main action near the bottom of the screen, and make dropdowns open on tap. Add site search if the site has many pages or a large resource library.
13. Pop-ups do not cover the screen.
    • Why: Google's guidance on intrusive interstitials says elements that obstruct the view of content can frustrate users and may lead to poor search performance.
    • Check: Open the page in a private tab on your phone. You should be able to read the content immediately without closing anything.
    • Fix: Replace full-page interstitials with banners that take up only a small fraction of the screen, the option Google's guidance recommends. That applies to newsletter sign-ups and app install prompts too.

How do I confirm Google sees the mobile version correctly?

Google indexes and ranks the mobile version of your pages, so content missing on mobile is missing from search. Confirm the two versions match, then sign off on real phones instead of relying on an emulator alone.

Google's mobile-first indexing documentation says Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. With responsive design, the content and metadata are the same on mobile and desktop. The risk sits with sites that serve a separate mobile template or separate mobile URLs.

14. Same content on mobile and desktop.
    • Why: Anything dropped from the mobile version is dropped from what Google indexes.
    • Check: Open a key page on your phone and on desktop side by side. Compare headings, body copy, images and their alt text, and internal links.
    • Fix: Bring a separate mobile template up to parity, or move to responsive design. Use the same robots meta tags on both versions, as Google's documentation advises.
15. Test on a real iPhone and a real Android phone.
    • Why: Device mode copies screen sizes, but not real touch, real keyboards, the browser's own toolbars or a cellular connection. BrowserStack's testing guide also lists testing on real mobile devices as one of its core steps.
    • Check: On each phone, load the home page and a service page on cellular data. Complete the call path and submit a test form.
    • Fix: Log each issue with the device and browser, fix it, then re-run the check on both phones.

Which tools should I use to test mobile friendliness?

Tool	What it shows	Use it for
PageSpeed Insights	Field and lab Core Web Vitals for one URL, with diagnostics	Checking a single page before and after a fix
Search Console Core Web Vitals report	Site-wide field data, grouped by status, for mobile and desktop	Finding which page groups fail
Chrome DevTools device mode	Emulated phone widths and throttled network	Quick layout checks at 375 pixels
A real iPhone and a real Android phone	Touch, keyboards, browser toolbars, cellular speed	Final sign-off on every release

Where do mobile problems come from on Webflow, WordPress and Shopify?

All three platforms can produce a fully mobile-friendly site, but the trouble starts in different places on each. On Webflow, look at breakpoint styling first; on WordPress, the theme and plugins; on Shopify, app scripts and product images.

Webflow

Webflow styles cascade down from the desktop breakpoint, so a fixed pixel width or a large margin set on desktop carries into tablet and phone views unless someone overrides it at each breakpoint. The other usual causes are oversized hero videos and background images, elements hidden on mobile that still load, and heavy interactions that slow responses to taps. Meet Chaudhari, our partner and visual designer, works mobile-first on Webflow. The Hopscotch Whisky Bar build is a menu-driven site the owners update themselves, and a site owners edit needs a layout that holds up on a phone whatever they add.

WordPress

WordPress mobile problems usually trace back to the theme and the plugins. Themes built before responsive design rarely adapt cleanly, and page builders can output deeply nested markup with separate device settings that drift apart over time. Each plugin can load its own CSS and JavaScript on every page, whether that page uses it or not, which drags on LCP and INP. Pop-up and slider plugins are frequent sources of layout shift and screen-covering overlays.

Shopify

On Shopify, look at app scripts and product imagery first. Apps can inject JavaScript into the storefront, and some leave code in the theme after they are uninstalled, so an app removed months ago can still weigh on the page. Product photos uploaded at full camera resolution, and older themes without responsive image markup, hurt LCP on collection and product pages. Custom sections coded with fixed widths are a common cause of the sideways scroll in step 4.

When does a site need a rebuild instead of more mobile fixes?

Rebuild when the mobile problems live in the structure of the site, not its settings. If each fix on this checklist breaks something else, the budget is going into keeping an old layout alive instead of into a site that passes.

These are the signs a desktop-era site is past patching:

• Fixed-width layouts throughout. The page was built at one desktop width, and the mobile view is a stack of overrides.
• A duplicated mobile template or separate mobile URLs. Every content change has to be made twice, and the two versions drift apart, which is exactly what step 14 checks.
• An unmaintained theme or page builder. No updates means no fixes for new browser behaviour, and every plugin update risks a conflict.
• Every fix breaks something else. Repairing the menu shifts the header, and compressing images breaks the slider.
• Core Web Vitals stay in Poor after the image and script fixes. At that point the theme's own code is the weight.
• No room for the path to enquiry. Adding a sticky call button or a short form needs custom code the theme fights.

If several of those describe your site, read our guide on how to redesign a website before spending more on patches. If you would rather hand the work over, our conversion-focused web design service builds sites mobile-first, and our piece on whether it is worth hiring a web designer sets out the trade-offs of doing it yourself.

What does the full mobile-friendly website checklist look like?

The table lists all 15 steps with the check that shows whether each one passes. Copy it into a document or spreadsheet and mark each row pass or fail for your own site.

Step	Check
1. Viewport meta tag present	View source and find the viewport tag with width set to device-width
2. Body text at 16px minimum	Inspect a paragraph's computed font size
3. Tap targets at least 44 by 44 pixels, with spacing	Inspect a button's box size; thumb-test the menu and footer
4. No horizontal scroll at 375 pixels wide	Device mode at 375 wide, then try to scroll right
5. Images sized, compressed, lazy loaded below the fold	PageSpeed Insights image diagnostics and the DevTools Network tab
6. LCP within 2.5 seconds on mobile	PageSpeed Insights Mobile tab, field data
7. INP of 200 milliseconds or less	PageSpeed Insights field data or the Search Console report
8. CLS of 0.1 or less	Reload on your phone and watch for jumps; read CLS in PageSpeed Insights
9. Fonts use font-display: swap	Search the @font-face rules in your CSS
10. Click-to-call number and sticky call or book button	Tap the number; scroll to the bottom of a long page
11. Right keyboard types, no more than five fields	Fill in the form on your phone
12. Thumb-friendly navigation	Reach key pages one-handed from the home page
13. No screen-covering pop-ups	Load in a private tab; content readable at once
14. Same content on mobile and desktop	Compare a key page side by side
15. Tested on a real iPhone and Android phone	Call path and test form on cellular data

Wrapping Up

A mobile-friendly site is the sum of small, testable decisions: a viewport tag, readable text, thumb-sized targets, a page that fits the screen, fast and stable loading, and a two-tap path to a call or booking. Work through the 15 checks in order, starting with layout, since a fast page that scrolls sideways still loses the visitor. Re-test whenever you add scripts, apps or a new page template, and finish every round on real phones. If fixes keep breaking each other, take that as the signal to rebuild instead of patching again. If you would like an expert to run the checklist on your own site and tell you which route makes sense, book a free consultation with our team in Saint John.