How to Test a Website on a Phone
On this page07 sections
A site is not mobile-compatible because the desktop page fits on a phone. The person should be able to finish what they came to do. This article describes that walk. It does not name the speed scores.
Compatible means the job finishes on the phone
The walk is not over because the page opened. Can the text be read, can a thumb press the button, does the form send, can you move through the menu to an inner page and come back. If one of those snags, the page is not compatible for that job. An unbroken picture is a separate observation. Finishing the job is the one that counts.
Google describes three ways to build a mobile site: responsive design, with the same HTML at the same address; different HTML at the same address depending on the device; separate HTML at separate addresses. It names responsive design as the simplest to maintain. The walk does not ask which way was chosen. It looks at whether the job finishes on the way that was chosen.
There is no single tool left
On the Search Central blog, Google wrote that from 1 December 2023 it would retire the Mobile Usability report in Search Console, the Mobile-Friendly Test, and that test's API. The same post says mobile usability has not stopped mattering. It remains part of page experience. Looking at one tool and calling the page passed is no longer possible.
There is no ready badge to put in its place. The walk is done in the phone's own browser. The browser's device mode is a rehearsal. The two are separated below.
One phone, five jobs
You do not have to open every page. One of each kind of job is enough: the home page, one service, contact, an inner page the menu opens, and the other language if there is one. On each, try to finish a single job. Note where it snags. A note that sits with a screenshot is not argued about later.
| Page | Job to finish | What you see when it snags |
|---|---|---|
| Home | Read what the work is and press the next step | Text is small, the button is tight, the page slides sideways |
| One service | Read that service's sentence to the end | The text is cut, or left for the desktop |
| Contact | Send the form or call the number | The keyboard covers the field, the number cannot be called |
| Menu | Go to an inner page and come back | The menu will not close, back opens an unexpected page |
| Other language | If it exists, finish the same job in that language | A line overflows, alignment ignores the reading direction |
Where the eye snags
The items below are not a score sheet. They are where a thumb snags during the walk. If one is present, that page does not close for that job.
Sideways scroll
If the page slides left or right on its own, something is wider than the screen. It is often an image, a table, or a line that overflows. If a person has to move the page sideways to read, the walk stops there.
Small text
If a paragraph has to be zoomed to be read, the text is small for that screen. Try enlarging with two fingers. If the page refuses, a person who needs larger text is left out. A lock that disables zoom is not defended as a preference.
The form and the keyboard
Press each field in turn. If the keyboard covers the field you are typing in, the field is not in a visible place. If an error after sending is only a change of colour, the error is not being read. If a phone number is not a link, calling it means copying it. That leaves the contact page's job half done.
Reading direction
If the site has Arabic, the same job has to finish in that direction as well. The menu, the alignment, and an overflowing line can hold in a left-to-right walk and break in a right-to-left one. A pass in one direction does not close the other.
A thumb target is not a guessed centimetre
In WCAG 2.2 the W3C writes the AA target-size criterion this way: the target a pointer presses is at least 24 by 24 CSS pixels. A smaller target can still pass when a 24-pixel circle around it does not touch the next target. A link inside a sentence is an exception. Two small icons stuck together are not. If a thumb hits the wrong one, the walk has already snagged, before anyone checks the measure with a ruler.
This number is not memorised as the threshold of an old mobile test. That tool was retired. The number is the AA criterion the W3C writes now, and it has exceptions. A ruler does not close the walk. Icons stuck together open it.
The browser is a rehearsal, the phone is the walk
MDN describes the viewport tag as the mark that tells the browser the size and scale of the visible area. If on a phone the page looks like a shrunken desktop layout, the tag may be missing or locked to a fixed width. On a responsive page the usual value sets the width to the device width and the initial scale to 1. The rehearsal is useful for seeing that.
Chrome describes device mode as a way to try a responsive page by imitating mobile devices. The toolbar changes the width and can imitate touch. It does not reproduce the phone's keyboard, type, or network. A page that holds in a narrow window can still leave half the form under the keyboard on a phone in the hand. The rehearsal is looked at before the walk. It does not replace it.
What is missing on the phone may be missing from the index
Google writes that it uses the mobile version for indexing and ranking. A paragraph that stands on the desktop and is absent from the mobile version may not be carried by the version that is indexed. Google recommends that the mobile page's primary content be equivalent to the desktop, and writes that a deliberately thinner mobile page can be expected to lose traffic. Placing text in a tab can be a layout difference. Removing the content from the page is not equivalence.
The same document says Google will not load primary content that requires a person to swipe, click, or type before it loads. The main text sitting behind a show-more button can be absent both for the visitor and for the crawl. The causes of slowness, and the names of the measurements, sit outside this walk, in the piece on why a site opens slowly.
The sentence that should stand on the first screen of a corporate page is a separate list. If that sentence cannot be read on a phone, the list does not close. At N2 Creative we think it is right, in site and software work, to walk these five jobs on a phone before calling a page finished. That is the order of the walk, not a guarantee.
- The walk was done in a phone's own browser. A narrow window was not the only look.
- On the home page the work was read and the next step was pressed.
- One service page was read to the end. The text was not left for the desktop.
- The form was sent or the number was called. The keyboard did not cover the field.
- The menu opened, an inner page was reached, and back returned.
- The page does not slide sideways. Text can be enlarged with two fingers.
- On small icons stuck together, a thumb does not hit the wrong target.
- If Arabic exists, the same job also finished in that direction.
- No primary text remains that is on the desktop and absent from the phone.
Sources
- Mobile-first indexing best practices (Google Search Central)
Accessed October 20, 2026
- The role of page experience in creating helpful content (Google Search Central Blog)
Accessed October 20, 2026
- Understanding Success Criterion 2.5.8: Target Size (Minimum) (W3C WAI)
Accessed October 20, 2026
- Viewport meta tag (MDN)
Accessed October 20, 2026
- Simulate mobile devices with device mode (Chrome for Developers)
Accessed October 20, 2026