Mobile website testing checklist: 30 checks before launch

A mobile website test checks that a site is readable, usable and fast on phones before real visitors find the problems. The checklist below covers 30 checks in seven groups. Most take seconds in a mobile view on your desktop; a few need a real phone. Work through it before every launch or redesign, and keep the short version for regular releases.

Before you start: set up your test devices

You need three kinds of views:

1. A quick mobile view on desktop for layout checks across many pages: Chrome DevTools device mode or a mobile view extension such as Mobile View Extension. The differences are covered in mobile simulator extensions vs DevTools.
2. Real mobile engines (and the desktop browsers from the cross-browser testing checklist): iOS Safari through the Xcode Simulator or a real iPhone, and Chrome on Android. See testing on iPhone and testing on Android.
3. At least one real, mid-range phone for touch, keyboard and speed.

Test these widths at minimum (what these numbers mean is explained in what is viewport size): 360 px, 390–402 px and 430–440 px in portrait, plus one landscape size and one tablet size.

1. Layout and readability

1. No horizontal scrolling on any page. If a page scrolls sideways, find the element wider than the screen; fixed widths, long URLs and wide tables are the usual cause.
2. Body text is at least 16 px and lines are not wider than the screen.
3. Headings wrap cleanly without single words stranded on a line.
4. Images scale to the screen and keep their aspect ratio.
5. Content order makes sense when columns stack. The most important content is not pushed below a long sidebar.
6. Nothing is hidden behind the notch or the home indicator in landscape (check env(safe-area-inset-*) if you use full-bleed layouts).
7. The page has a correct viewport meta tag. Without it, phones render a zoomed-out desktop page. See the viewport meta tag explained.

2. Navigation

8. The menu opens and closes with one tap, and closes when a link is chosen.
9. Every menu item, including nested ones, is reachable without hover.
10. The logo or a home link is present on every page.
11. Sticky headers do not take more than a small share of the screen height in landscape.
12. The back button (and Android’s back gesture) returns to the expected place, including in single-page apps.

3. Touch and interaction

13. Tap targets are big enough and spaced apart. WCAG 2.2 sets a minimum of 24 × 24 CSS pixels; Apple and Google design guidelines recommend about 44–48 px.
14. Carousels and sliders work by swipe and have visible controls.
15. Pop-ups and cookie banners can be closed easily and do not cover the whole screen on arrival.
16. Links in body text are distinguishable without hover.

4. Forms

17. Each input shows the right keyboard: type="email", type="tel", inputmode="numeric".
18. Inputs use at least 16 px text, so iOS Safari does not zoom in on focus.
19. The on-screen keyboard does not cover the field being typed in, or the submit button.
20. Autofill works for name, email, address and payment fields (autocomplete attributes).
21. Error messages appear next to the field and are visible without scrolling.

5. Media and assets

22. Images are served at sizes suited to the screen (srcset and sizes), not desktop-sized files scaled down.
23. Videos do not autoplay with sound, and play inline on iPhone where intended (playsinline).
24. Icons and logos are sharp on high-density screens (SVG or 2x/3x images).

6. Speed

25. The main content appears quickly on a throttled connection. Check field data in PageSpeed Insights and run a lab test; the mobile page speed test guide explains both.
26. Layout does not jump while the page loads (Cumulative Layout Shift).
27. The page responds quickly to the first tap (Interaction to Next Paint).

7. SEO and accessibility on mobile

28. The mobile page has the same main content, headings, structured data and meta tags as desktop. Google indexes the mobile version.
29. Text can be zoomed to 200% without breaking the layout, and the page is usable with the screen reader on at least one phone.
30. A Lighthouse audit in mobile mode shows no critical accessibility or SEO issues. Steps: Lighthouse mobile audit in Chrome.

The short version for every release

You will not run 30 checks on every deploy. For routine releases:

• open the changed pages in a mobile view at 360 px and 430 px
• check for sideways scrolling and broken menus
• submit one form on a real phone
• glance at the speed report for the main landing page

That takes about ten minutes and catches most regressions.

Common mistakes in mobile testing

• Testing only by resizing the browser window. It changes the width but not the user agent, pixel ratio or input type, so some sites serve a different page to real phones. Details: how to see the mobile version of a website on desktop.
• Testing only on a new flagship phone. Most visitors have slower devices than developers.
• Ignoring landscape and tablets. Breakpoints around 768–1024 px are where many layouts fail; see how to view a website as an iPad.
• Testing logged-out pages only. Account areas and checkout often get the least mobile attention.

Frequently asked questions

How do I test my website on mobile without a phone?

Use a mobile view in desktop Chrome for layout, the Xcode Simulator for iPhone Safari on a Mac, and the Android Studio emulator for Android. Use a real phone for the final check of key flows.

What is the most common mobile website problem?

Content wider than the screen, which causes sideways scrolling. It usually comes from a fixed-width element, a wide table or an image without max-width: 100%.

Is there an official Google mobile test?

Google retired its Mobile-Friendly Test in December 2023 and points to Lighthouse instead. Alternatives are listed in Google Mobile-Friendly Test alternatives.