How to Test a Mobile-Friendly Website: 12 Checkpoints

Opening your site on a desktop and saying “it looks good” does not show that it is mobile friendly. Most of your visitors reach your site from a phone, and they have a completely different experience there: a page with horizontal scrolling, a link too small for a finger to hit, a form covered by the keyboard or a fixed button that hides the content. Most of these problems do not appear in the design file but on the real screen.

In this article we explain how to test a mobile-friendly website with twelve checkpoints. You will see which widths to look at, with which tools, why each item matters and how to prioritize the problems you find. For the conceptual framework you can look at our responsive web design article; here the subject is the practical checklist.

Why Is a Mobile Test Incomplete Without a Real Device?

Narrowing the window in the browser is a good start, but it cannot imitate two things. The first is touch behavior: a finger is not as precise as a mouse cursor, and it is very easy to hit the link next to the one you aim for. The second is the on-screen keyboard and browser bars: on a phone the visible height of the page changes as the address bar slides, a form field can be covered when the keyboard opens, and this behavior is not visible in a desktop browser.

That is why a good mobile test has two layers. First you do a quick, repeatable scan with the device mode of a desktop browser; then you do a real touch test on at least one iPhone and one Android phone. The first layer catches most layout errors; the second catches usability problems.

A note: the standalone “Mobile-Friendly Test” tool Google used to offer was removed in 2023. Today the same job is done by Chrome’s own tools, Lighthouse and PageSpeed Insights; the page experience and Core Web Vitals reports in Search Console also show real user data. We explained these concepts in what Core Web Vitals are.

Preparation: Which Widths and Which Tools to Test With?

You cannot test every phone, but a few representative widths catch most problems. A practical set is:

• 320 pixels: Very small and old phones; the narrowest limit. If it works here, you are fine.
• 360 and 375 pixels: Common Android and iPhone widths. Make these your main test widths.
• 390-430 pixels: Newer and larger phones.
• 768 pixels: Tablet in portrait. The transition point between mobile and desktop causes problems here.
• Landscape orientation: When you turn the phone sideways, does the layout break?

As a tool, use the device mode in Chrome DevTools (Ctrl+Shift+M or Cmd+Shift+M). You can type the width you want in the box at the top and try a slow connection by throttling the network. In Safari the equivalent is Responsive Design Mode. For a real device, browse your site from start to finish with at least Safari on an iPhone and Chrome on an Android.

There is also a quick command: type document.documentElement.scrollWidth > window.innerWidth into the browser console. If the result is true, the page has horizontal overflow; this is the most common indicator of mobile problems.

Appearance Checks: Scale, Overflow, Text and Images

The first five checks look at how the page appears.

1. The viewport tag. The <head> of the page must contain a viewport meta tag with width=device-width, initial-scale=1. If it is missing, the phone draws the page at desktop width and shrinks it. Do not use settings that block zooming (user-scalable=no); visitors with low vision have a right to zoom.

2. No horizontal scrolling. At 320, 360 and 375 pixels it must not be possible to scroll the page left and right. Typical causes of overflow are fixed-width images, wide tables, long address strings and decorative elements that stick out from the edges.

3. Text size and readability. Body text should be at least around 16 pixels on a phone; small text forces the visitor to zoom. Lines should not stick to the edge of the screen; there should be space at the sides. The number of lines in headings should also stay reasonable; a heading that spreads over three lines eats the first screen.

4. Images. No image should exceed the screen width or overflow onto the text. Images should have width and height written so the page does not shift while loading. Smaller versions of large images should be served for mobile; for details on speed see speeding up your website.

5. Tables and wide content. Comparison tables, code blocks and long links overflow their box on a small screen. The solutions are to put the table into a horizontally scrollable box, to make long strings break at the end of the line, or to turn the content into a card layout for mobile.

Interaction Checks: Tap, Menu, Forms and Fixed Elements

The next four checks look at how the page is used.

6. Tap targets. Buttons and links should be big enough to hit comfortably with a finger. Platform guidelines generally recommend a target of around 44 to 48 pixels; the accessibility standard (WCAG 2.2) asks for at least a 24-pixel target and enough spacing. Look especially at the space between two small links side by side; a wrong tap is annoying. You can read the details of the standard in website accessibility (WCAG).

7. Menu and navigation. Does the mobile menu open and close? When it is open, does the page scroll behind it? Can the submenus be reached by touch? Is the close button easy to see? Does tapping the logo to return to the home page work? Try all of these on a real phone.

8. Forms. Tapping a form field should bring up the right keyboard: numeric for a phone number, one with @ for e-mail. Field labels should be visible, the active field should stay on screen when the keyboard opens, and the error message should appear next to the field. A field text smaller than 16 pixels makes the page zoom in unintentionally on some phones when the field is selected. Submit the form from end to end and see the result.

9. Fixed elements. A bottom bar, a WhatsApp button, a cookie banner and a sticky top menu can cover half the content on a small screen. Make sure the last line of the page does not stay behind a fixed button and that the form’s submit button is not squeezed between the keyboard and the bottom bar. The total height of fixed elements should not exceed a quarter of the screen.

Contact, Orientation and Speed Checks

The last three checks look at what the mobile visitor actually wants to do.

10. Contact actions. The mobile visitor most often wants to call, write on WhatsApp or get directions. The phone number should be a tel: link and start a call with one tap; the WhatsApp link can open with a ready message; the address should go to the map application. Keeping these actions reachable at all times on the page is one of the most valuable mobile improvements for conversion.

11. Landscape and small screens. When the phone is turned sideways, does the layout break or the content get squeezed in height? At 320 pixels wide, does a button overflow or text get cut? Small screens are where badly written CSS shows up first.

12. Mobile speed and a real device. Run Lighthouse in mobile mode and browse the page with the network slowed down. The effect of big images, heavy scripts and late-arriving fonts is far more visible on a phone than on a desktop. Open the site on a real phone with mobile data; if you count seconds while a page opens, your visitor is counting too.

Mobile Problems We Found on Our Own Site

Instead of giving a theoretical list, let us share our own experience. After a big change we scan the pages of our site at 375 pixels wide and measure whether the page width exceeds the screen width. In the latest scan we found horizontal overflow on two of thirty tool pages. On one, the problem was a long address string that did not break at the end of the line on a narrow screen; on the other, a three-column form row that should have fitted side by side could not shrink on a narrow screen. Neither was visible on a desktop at all.

Earlier we had also caught that on one service page, hidden texts meant for screen readers overflowed outside a scrollable table and pushed the page to about 509 pixels wide instead of 375. What the three problems had in common was that none appeared at the design stage and they only came out when we measured at a narrow width. That is why we do mobile testing not once but as a step repeated after every big change.

A 12-Item Mobile Test List

1. The viewport meta tag exists and zooming is not blocked.
2. No horizontal scrolling at 320, 360 and 375 pixels.
3. Body text is a readable size and lines do not stick to the edge.
4. Images fit the screen and their sizes are defined.
5. Tables and long strings do not overflow or can be scrolled.
6. Buttons and links are comfortably tappable with space between them.
7. The mobile menu opens and closes, submenus can be reached.
8. Form fields open the right keyboard, labels and error messages are visible.
9. Fixed elements do not cover the content or the submit button.
10. Phone, WhatsApp and map links work with one tap.
11. The page does not break in landscape or at 320 pixels.
12. Lighthouse in mobile mode is fine, and it opens fast on a real phone.

If You Find Problems: Prioritization

You cannot fix all the problems at once. First look at the ones that block conversion: a menu that does not open, a form that cannot be sent, a phone number that cannot be tapped, a fixed element covering content. Then the layout problems (overflow, cut-off text), and leave the cosmetic ones for last. After each fix, measure again at the same width.

The source of the problems often gathers in a single place: a table, a fixed bar, a fixed-width component. So when you find one bug, scan similar components too. For how mobile experience relates to overall design decisions, see UX/UI in web design and SEO and user experience.

How Does Soft Ajans Handle Mobile Compatibility?

In our web design service the site is developed to fit phone, tablet and desktop screens, and device and browser tests are done before launch. Mobile compatibility starts at the design stage: how the pages look on a phone is considered together with the desktop, and important actions (call, WhatsApp, form) are brought forward on mobile. If you want a quick look at the mobile state of your site, you can request a free pre-analysis.

If you are planning a new site, we listed which pages it should have in pages a corporate website needs.

Frequently Asked Questions

How do I know if my website is mobile friendly?

Open it on a phone and look at whether there is horizontal scrolling, whether the text reads comfortably, whether the buttons are easy to tap and whether the form works. Then run Lighthouse in mobile mode in Chrome and note the results.

Is there a difference between responsive and mobile friendly?

Responsive design is the technique of changing the page layout according to screen width. Mobile friendly is the result: the user being able to browse comfortably on a phone. Technically, a responsive site can still be unusable on mobile if it is badly designed.

What is the minimum size in pixels for tap targets?

Common platform recommendations are around 44-48 pixels. The WCAG 2.2 accessibility criterion asks for at least a 24-pixel target with enough spacing. In practice, prefer larger targets where possible, with plenty of space especially for links close to each other.

Do I need a separate site for mobile?

No. Today a single responsive site works on both phone and desktop and does not need a separate mobile site (an m. subdomain). A separate site leads to content inconsistency and a maintenance burden.

Does mobile compatibility affect SEO?

Google indexes pages based on their mobile version. A site that is missing content, slow or unusable on mobile can affect both users and search visibility negatively. Keeping the mobile experience equal in importance to the desktop is the safe approach.

How often should I repeat the test?

Do a quick scan after every major design change and after adding a new component. In regular maintenance, checking the width and testing the form once a month on the most visited pages is enough.